This is the second of a series of posts on the design of GNOME Shell, as part of an ongoing initiative to improve the core shell experience. In the previous post of the series, Allan gave a general introduction to that initiative. This post is meant to provide some more context and touch on longer-term ideas we’re thinking about. It’s worth noting that many of these are still at an early stage, and subject to change.
It’s hard to believe, but we’re coming up on 10 years of GNOME Shell. Though GNOME 3.0 wasn’t released until April of 2011, design and development were in full swing in mid-2010, and had been for some time.
Of course, the shell has not been standing still since then. Many important areas have been refined and iterated on since those early days, including the notifications, the app grid, and the system status area.
However, other parts of the interface haven’t changed much since the early days, and we know that some aspects of these old designs could be improved. There are a number of core elements of the shell that we’ve wanted to refresh for some time now, and as the previous blog post discussed we’re hoping to move forward with some of it in the near future.
Given that background, this post is meant to provide an overview of where we see the strengths and weaknesses of the existing design, as well as areas that we’re interested in improving. This includes the areas highlighted in Allan’s post, but also expands the list to cover other initiatives that are either ongoing, or which we would like to see happen.
One of the core ideas behind the original design of the shell was getting out of your way, and reducing distractions as much as possible. While you’re using apps there are no colorful icons, applets, or other clutter on the screen: It’s just you and the thing you’re working on.
Long before big tech started talking about giving people back control over their attention, “digital wellbeing”, and “time well spent”, GNOME Shell was built around helping people deal with distractions and focus on what really matters. Needless to say, this is more relevant than ever, and something we want to continue to focus on.
If you’re curious, here’s some further reading on the thinking behind the initial 3.0 shell design:
Single Entry Point
The GNOME Shell overview is a single place to go for app launching and switching, window management, and system-wide search. It’s the center of the shell experience, the place to see what’s happening on the system at a glance, switch activities, or start new ones.
No other desktop OS has a core workflow this simple and straightforward, and many people really really love it. This is another core strength we want to build on.
Most operating systems have some kind of system-wide unified search nowadays, but the GNOME Shell one is especially great because it’s seamlessly integrated with the “single entry point” workflow. This means there’s no extra button to click, or separate keyboard shortcut to learn. Just hit Super and type.
Switching > Launching
Most of the time when leaving the current activity you don’t start a new one (e.g. by opening a new app), but switch to another running activity. GNOME Shell optimizes for this by putting multitasking front and center in the overview, ahead of launching new apps.
A key reason for the success of the “single entry point” workflow is how easy it is to open the overview across input devices (most of them anyway, but more on that later).
With a mouse you just flick your cursor up to the top left corner. This is very ergonomic because you don’t have to aim, you just move the mouse in that general direction.
If your hands are on the keyboard you can hit a single key, conveniently located in the bottom left of the keyboard, to enter the overview.
These methods quickly become second nature, so much so that people report feeling a visceral lack of control when using other systems. Windows and macOS have equivalents to many of GNOME Shell’s individual features, but there’s no way to do it all from one place in such an ergonomic way.
Areas for Improvement
While there’s a lot to like about the status quo, we’re aware that there are also a number of issues with it, both structurally and usability-wise, and there are a lot of things that work well today, but we think could be even better.
Launching & Initial State
One of the most visible shortcomings of the current shell layout is the bootup experience. After login you’re greeted by an empty desktop, and when you open the overview it’s also empty, since there are no open windows. Though this is not something you encounter very often, it’s definitely not a good first impression.
There are also issues with launching apps from the app grid more generally: It’s not very prominent or easy to get to, and it’s split into two separate views, each with its own problems. Apps don’t have fixed positions in either view, because the All view is alphabetical, so things move around when you install or remove apps, and the Frequent view constantly changes depending on usage.
In improving the app grid, we’d like to move towards something that allows people to develop spatial memory for where certain apps are, and organize them in a semantic way.
Our current multitasking model consists of two levels: workspaces, which are laid out next to each other in a vertical row, and windows, which are stacked behind one another. This two-level system can be quite powerful, but there’s no automatic onramp to the workflow. By default, if you launch apps they all just pile up on the same workspace.
It’s possible to use GNOME Shell with just a single workspace, but it can be awkward, e.g when there are too many windows for the overview to be an effective way of switching because the thumbnails are so small. All windows stacking up behind one another also makes it hard to do things that involve multiple windows at the same time, such as keeping two windows side by side.
People often mention that once they were shown the workspace feature (e.g. by a friend or coworker), it “clicked” for them and they started using and loving it. Of course, this kind of discovery doesn’t scale, and there’s clearly a gap in the learning curve.
This issue isn’t new for workspaces (across all implementations, not just ours): You need to know about the feature, actively decide to use it, and put in some manual work. In our case this is made worse by the fact that the system isn’t able to “remember” open windows and workspaces across reboots.
Ideally we’d like to make multitasking and window management feel more organic than the current two-level system, and reduce the amount of work people have to do to keep things organized and easy to navigate.
Gestures & Spatial Model
Some parts of GNOME Shell have a clear, simple spatial model which makes navigation feel effortless. For example, workspaces are arranged in a vertical row, which you can cycle through via touchpad gestures or directional keyboard shortcuts.
However, this isn’t the case for everything, which is why parts of the shell can feel disconnected and difficult to navigate. A good example of this is the app grid: The first page opens with a “swarm” animation from the app grid icon, but then additional pages appear from outside the viewport.
Ideally the shell should have a clear, unified spatial model, so you always instinctively know where things are (even when they’re off-screen), and how to get to them, across input methods and form factors.
In order to enable that we need a more comprehensive set of gestures for navigating the core parts of the shell, as well as more intuitive and discoverable keyboard shortcuts. The same thing largely applies to touchscreens as well. Some gestures there are quite nice, but others are not “stick-to-finger”, or physically difficult to perform (e.g. pinch to open the overview).
One of the nice things about having a simpler spatial model and directional gestures to navigate the shell is that it also helps keyboard navigation. This is because it allows for directional shortcuts (e.g. Super + PgUp to move to the workspace above) which are more intuitive than non-directional ones (e.g. Super + M to open the notification popover).
Notifications & Agenda
The calendar popover contains a lot of different features (notifications, calendar, world clocks, weather). This can result in it feeling a bit large and unwieldy. Seeing as not everyone uses all the features in the popover we’re interested in giving people a way to customize which ones they want.
Ideally we’d like the features in this popover to be grouped in a more semantic way and easier to navigate to, especially with touchpads and touchscreens.
In addition to structural changes, we also want to make the notifications themselves better, for example by making notification actions accessible in the popover and grouping notifications by app. Mariana Pícolo is working on some of this as part of this year’s GSoC.
System Status Area
The system status area works well for the most part, but there are some parts we’d like to improve. For example, taking actions on individual items (e.g. toggling Bluetooth) always requires expanding the item’s sub-menu. Other items (e.g. Night Light) are only available in the menu when they’re enabled, which can feel unpredictable.
Our current search works well overall, but there are still areas where we think it could be better.
For the most part, search is currently just a portal to things inside apps (e.g. files, settings panels, contacts). However, we’ve found that search is often most interesting when it gives you something directly–launching an app, performing a calculation, looking up the weather, etc.
Having more such integrations and richer ways to interact with content from search is something we’re interested in exploring, along with generally expanding the kinds of things you can search for, e.g. your currently open windows.
Based on the above analysis, here are some tentative high-level goals for where we want to take the shell over the next few years:
- Distraction free
- Single entry point
- Feels quick & easy to navigate
- Structurally and visually elegant
In order to achieve these goals, these are some more concrete things we want to focus over the next few cycles (the previous blog post discusses these plans in more detail):
- Better onboarding and bootup experience
- Easier app launching
- Simpler, unified spatial model
- Better touchpad and touchscreen gestures
- Richer notifications
More medium-term, we’d also like to look at these:
- More organic workspace workflows
- Streamlined window management
- Remember open apps across reboots
- Improved system status area and search
Of course, some of these goals are much easier to achieve than others. Some of them may take years of work and multiple iterations to get right. That said, we think it’s important not to think about these ideas in isolation, but as part of a more comprehensive vision for the future.
The previous blog post lays out a fairly clear roadmap for the first few things we want to address. As that work becomes more concrete, we look forward to sharing and discussing it with the wider community. We hope this post will help provide context to that discussion.
These are exciting times, and we can’t wait to share more. Stay tuned!