This post is part of a series on UX strategy. In my previous two posts, I described what I hope are the beginnings of a UX strategy for GNOME. In the first post, I described some background research and analysis. In the second post, I introduced what I think ought to be the high-level goals and principles for the UX strategy.
Now it’s time for the fun bit! For this instalment, I’m going to go over recent work that the GNOME design team has been doing. I’m doing this for two reasons. First: I want to show off some of the great work that the design team has been doing! Second, I want to show this design work fits into the strategic approach that I’ve previously described. A key element of that plan was to prioritise on areas which will have the biggest impact, and I’m going to be using the prioritisation word a lot in what follows.
This post is intended as an overview and, as such, I’m not going to go into the designs in great detail. However, there are detailed designs behind everything I’m presenting, and there’s a list of links at the end of the post, for those who want to learn more.
Core System
In my previous post, I argued that prioritisation ought to be a key part of our UX strategy. This is intended to help us drive up quality, as well as deliver impactful improvements. One way that we can prioritise is by focusing on those parts of GNOME that people use all the time.
The obvious place to start with this is the core elements of the GNOME system: those parts of the software that make up the most basic and common interactions, like login, app launching, window switching, notifications, and so on. I believe that improving the level of polish of these basic features would go a long way to elevating the standing of the entire platform.
Unlock and Login
The design team has longstanding ambitions to update GNOME’s unlock and login experience. The designs have continued to evolve since I last blogged about them, and we continue to return to and improve them.
System unlock is a classic example of a touchstone experience. People unlock their computers all the time and, as the entry point to the system, it comes to define the overall experience. It’s the face of the system. It is therefore critical that unlock and login leave a good impression.
The new designs are intended to reduce the amount of friction that people experience when they unlock. They require users to take fewer steps and involve going through fewer transitions, so that people can get to their session faster and more seamlessly. This will in turn make the experience feel more comfortable.
The designs are also intended to be beautiful! As an emblematic part of the GNOME UX, we want unlock and login to look and feel fantastic.
Notifications
The design team has been systematically reviewing almost all parts of the core GNOME system, with a view to polish and refine them. Some of this work has already landed in GNOME 3.34, where you will see a collection of visual style improvements.
One area where we want to develop this work is the calendar and notifictions list. The improvements here are mostly visual – nicer layout, better typography, and so on – but there are functional improvements too. Our latest designs include a switch for do not disturb mode, for example.
There are other functional improvements that we’d like to see in subsequent iterations to the notification list, such as grouping notifications by application, and allowing notification actions to be accessed from the list.
Notifications are another great example where we can deliver clear value for our users: they’re something that users encounter all the time, and which are almost always relevant, irrespective of the apps that someone uses.
System Polish
Our core system polish and refinement drive knows no bounds! We have designs for an updated system menu, which are primarily intended to resolve some long-standing discoverability issues. We’ve also systematically gone through all of the system dialogs, in order to ensure that each one is consistent and beautiful (something that is sadly lacking at the moment).
These aren’t the only parts of the core system that the design team is interested in improving. One key area that we are planning on working on in the near future is application launching. We’ve already done some experimental work in this area, and are planning on building on the drag and drop work that Georges Stavracas landed for GNOME 3.34.
Apps
The principle of prioritisation can also be applied to GNOME’s applications. The design team already spends a lot of time on the most essential applications, like Settings, Software and Files. Following the principle of prioritisation, we’ve also been taking a fresh look at some of the really basic apps that people use every day.
Two key examples of this are the document and image viewers. These are essential utilities that everyone uses. Such basic features ought to look and feel great and be firmly part of the GNOME experience. If we can’t get them right, then people won’t get a great impression.
Today our document and image viewers do their jobs reasonably well, but they lack refinement in some areas and they don’t always feel like they belong to the rest of the system. They also lack a few critical features.
<figure aria-describedby="caption-attachment-7193" class="wp-caption alignnone" id="attachment_7193" style="width: 1280px">
<figcaption class="wp-caption-text" id="caption-attachment-7193">Document viewer mockup</figcaption></figure>
<figure aria-describedby="caption-attachment-7190" class="wp-caption alignnone" id="attachment_7190" style="width: 1280px">
<figcaption class="wp-caption-text" id="caption-attachment-7190">Image viewer mockup</figcaption></figure>
This is why the design team has created updated designs for both the document and image viewers. These use the same design patterns, so they will feel like they belong together (as well as to the rest of the system). They also include some additional important features, like basic image editing (from talking to GNOME users, we know that this is a sorely missed feature).
It would be great to extend this work to look at some of the other basic, frequently-used apps, like the Text Editor and Videos.
There’s a lot of other great application design work that I could share here, but am not going to, because I do think that focusing on these core apps first makes the most strategic sense.
Development Platform
Another way that we can prioritise is by working on the app development platform. Improvements in this area make it easier for developers to create apps. They also have the potential to make every GNOME app look and behave better, and can therefore be an extremely effective way to improve the GNOME UX.
Again, this is an area where the design team has already been doing a lot of work, particularly around our icon system. This is part of the application platform, and a lot of work has recently gone into making it easier than ever to create new icons as well as consume the ones that GNOME provides out of the box. If you’re interested in this topic, I’d recommend Jakub’s GUADEC talk on the subject.
<figure aria-describedby="caption-attachment-7187" class="wp-caption alignnone" id="attachment_7187" style="width: 1280px">
<figcaption class="wp-caption-text" id="caption-attachment-7187">Mockups for menus, dropdown lists, reorderable lists, and in-app notifications</figcaption></figure>
Aside from the icon system, we have also been working to ensure that all the key design patterns are fully supported by the application development platform. The story here is patchy: not all of the design patterns have corresponding widgets in GTK and, in some cases it can be a lot of work to implement standard GNOME application designs. The result can also lack the quality that we’d like to see.
This is why the design team has been reviewing each of our design patterns, with a view to ensuring that each one is both great quality, and is fully supported. We want each pattern to look great, function really well, and be easy for application developers to use. So far, we have new designs for menus, dropdown lists, listboxes and in-app notifications, and there’s more to come. This initiative is ongoing, and we need help from platform and toolkit developers to drive it to completion.
What Next?
UX is more than UI: it is everything that makes up the user’s experience. As such, what I’ve presented here only represents a fraction of what would need to be included in a comprehensive UX strategy. That said, I do think that the work I’ve described above is of critical importance. It represents a programme to drive up the quality of the experience we provide, in a way that I believe would really resonate with users, because it focuses on features that people use every day, and aims to deliver tangible improvements.
As an open, upstream project, GNOME doesn’t have direct control over who works on what. However, it is able to informally influence where resources go, whether it’s by advertising priorities, encouraging contributions in particular areas, or tracking progress towards goals. If we are serious about wanting to compete in the marketplace, then doing this for the kind of UX programme that I’ve described seems like it could be an important step forward.
If there’s one thing I’d like to see come out of this series, it would be a serious conversation about how GNOME can be more strategic in its outlook and organisation.
This post marks the end of the “what” part of the series. In the next and final part, I’ll be moving onto the “how”: rather than talking about what we should be working on and what our priorities should be, I’ll set out how we ought to be working. This “how” part of the equation is critical: you can have the best strategy in the world, but still fail due to poor processes. So, in the final instalment, we’ll be discussing development process and methodology!
Further Reading
More information about the designs mentioned in this post:
PHP version 7.1 is now in security mode only, so no more RC will be released.
<figcaption> GNOME 3.34 desktop environment at work</figcaption></figure>
</figure>
<figcaption>OpenWrt stats in Grafana</figcaption></figure>
</figure>
</figure>
</figure>
