GNOME 3.10 isn’t far off, and there’s a lot of cool new stuff coming. One of the most visible changes in this release is the new System Status Area. For 3.10 we have reworked this part of the shell, and in this post I’m going to give a bit of background on the process involved in designing and implementing it.
The System Status Area is our term for the section on the right hand side of the GNOME 3 top bar. This is the place where icons indicate how much battery you have left and the strength of your wi-fi network, and so on. It is here that you can also perform basic system-level actions, like powering off. One of the long-standing design goals for this part of the top bar is to consistently use it for system-level status and actions. This makes the area predictable and ensures a clean separation between applications and system.
During the 3.x GNOME series, the System Status Area received quite a lot of work as we sought to refine and mature the original design that was introduced in 3.0. These iterative changes definitely improved this part of GNOME 3. At the same time, the basic design didn’t change a huge amount and was quite similar to what we had in the GNOME 2 days: a series of small icons, each with a menu attached to them. Each icon represented a different aspect of system status (battery, wi-fi-, bluetooth, etc), and the corresponding menu provided actions that you could take in that area.
Over time, we realised that there were some limitations with this model. There were some relatively isolated issues, like the row of small icons being difficult click targets, not having a good place for a screen brightness control, and the network menu being overloaded with a lot of items. We also encountered issues with having the user’s name in the top bar. This created privacy concerns: the prominence of the name on the screen was uncomfortable for people using their machines in public places. It also presented layout difficulties in cases where people had long names.
There were also structural limitations with the old model. As we sought to refine the System Status Area, we started looking to more dynamic models for indicating system status, which would reflect user intent more closely. Bluetooth is a good example here: in the old model, a bluetooth icon would always be present, even if bluetooth wasn’t being used (or had never been used, for that matter). You might not be interested in ever using bluetooth, and yet this icon would always be visible.
The old design resulted in a status area that wasn’t as focused on the user as it could be. To improve on this, we wanted to only show status icons when a hardware capability is active or in use. This approach is also a much better fit for modes that involve multiple aspects of system status. Aeroplane mode is a good example here, since it can affect bluetooth, wi-fi and mobile broadband simultaneously. Having separate menus for each of these areas prevented us from having an elegant presentation system status.
As we encountered these issues, those of us who work on GNOME design started to think about possible solutions, and the idea of having a single aggregated menu for system status emerged. In January of this year, some early concepts were thrown around. Most of these were rejected, but as time went on we started to hone in on a solution that we liked.
It should be said that, since this posed a major redesign of a core part of GNOME 3, we didn’t rush into pushing for changes. Informal discussions took place over three or four months before we decided to take the plan forward, and we only did this after we were confident that the new approach would both work and be an improvement.
Once we were confident about the overall design approach it was time to get stuck into the details. Since we were redesigning how to handle the multitude of possible system states, this was a highly complex design task. I personally wanted to make sure that we had all the bases covered, and I embarked on creating a series of detailed wireframes that sought to cover the full range of possible system states that might be encountered. These detailed each aspect of system status, including the way each one varies. They also included a set of example scenarios which enabled us to see how the design would play out in practice. These detailed investigations revealed issues with the original designs and allowed them to be improved.
It was around this time that Jasper St Pierre – one of the main GNOME Shell developers – took interest in the proposal, and this enabled us to put the proposal to the rest of the GNOME community. In April we proposed the new menu design as a GNOME 3.10 feature, and asked for comments and feedback on the GNOME Desktop Development List. There was a lot of discussion about the feature, and we got a lot of feedback. Jon, Jakub and I discussed the issues that were brought up and made changes to the design to address them (we subsequently updated the desktop list about these updates).
Over the course of this detailed phase of the design process, a total of four major iterations of the mockups were produced. Each one was quite detailed, and marked an improvement in the design. If you are interested in this, you can browse the series of iterations in our design repository.
And then we were into implementation territory. I think we underestimated the amount of work involved in implementing the new design, and Jasper had to move mountains to make it happen. However, thanks to his hard work we are going into 3.10 with the new System Status Area as one of the new GNOME features that we’ll be introducing. As implementation took place we inevitably encountered design issues, and Jakub and I have been working with Jasper to resolve these as we encounter them. We are now testing the implementation and are busy tracking the bugs that need fixing before the release.
Having spent a while using the new feature, I have to say that I’m very happy with the way it has turned out. The System Status Area is now much more focused, and only contains information about things I care about. It is also really nice to be able to open the menu and get an overview of system status. The new menu is also much easier to use with a pointer. Before, you would have to consciously target one of the small icons as you moved the pointer towards it. With the new design, you can move towards the top corner without even having to look (it feels very similar to the Activities Overview hot corner in this respect). It is very Fittsy.
I’m also confident that the new System Status Area will serve as a good platform for making further improvements in the future. Now that we are able to deal with system status in a more dynamic manner, I think there will be interesting opportunties for innovation in this area.
As with any new feature, we will be closely monitoring the feedback that we get over the coming weeks and months, and I’m sure that there will be adjustments that need to be made. For anyone who does encounter issues with the System Status design, we have a new component you can file bugs against (called “system-status” – it can be found in the “gnome-shell” product). We’ll be keeping a close eye and are happy to talk through any issues you might encounter.
The process involved in developing this new feature has lasted about eight months, and we have put a lot of work into it. We think that the new System Status Area enhances the GNOME 3 experience, and we hope that you like it. We’ll also keep working on it in future releases, so that it gets better and better.