The GNOME design team has recently been working on GNOME’s application development platform, and I thought that it might be interesting for people to hear about what we’ve been up to.
The following is an overview of our recent platform design activities, particularly libadwaita. It will give an idea of what is currently going into the GNOME platform from a UXD perspective, as well as some of things that people might expect from the platform in the future.
If you follow GNOME development, you’ll know that GTK 4 was released back in December 2020. You’ll also maybe know about libhandy, which can be used in conjunction with GTK 3 to add additional widgets and capabilities. And you might know that libadwaita is being worked on as the libhandy successor for GTK 4.
Adrien Plazas did a great post announcing libadwaita, and Alexander Mikhaylenko has been posting detailed updates. libadwaita still isn’t stable, but the hope is to have a stable 1.0 release in the not too distant future.
One of the central goals of libadwaita is to make it easy to make great apps, using the components and design practices that make up GNOME’s app design approach. Needless to say, the GNOME design team has been on board with this initiative from the start! It has also required quite a bit of work from us, both to document and systematise the design conventions we’ve been using, as well as to design missing platform pieces.
The first major step in this work was completed last development cycle, with the rewritten HIG. The new version is synchronized with GTK 4 and libadwaita, so its design advice is an accurate portrayal of what can be done with the emerging new version of the GNOME platform.
The updated HIG will be an important part of the application developer experience, and we are now focused on delivering the other key elements.
The following describes some of the areas of platform design work that the design team are currently involved with, particularly in the run up to libadwaita 1.0. As such, it covers work that is unfinished and is in various states of flux.
One of the first things that people will notice about apps that are using GTK 4 and libadwaita is their look, which is noticeably different from GTK 3 apps.
Header bar buttons are generally plain icons without outline or background. Other buttons have a flat colour. The background colours of container widgets are lighter in light mode, and darker in dark mode. Many of these changes in appearance are driven by technical changes: libadwaita’s support for dark mode and recolouring has knock-on effects for how widgets can be styled.
However, the design team is also keen to use the opportunity of libadwaita 1.0 to update the style of GNOME apps. The last time GTK had a style update was for GNOME 3.32, back in March 2019, and it could be several years before we get another opportunity to make changes.
On top of that, we do feel that the current GTK 3 look could be improved when compared to what’s being done on other platforms.
We are actively testing the style changes that have been made so far, using both in mockups and actual apps, and there could be adjustments before libadwaita 1.0. We also have a few other relatively minor style changes planned.
The new dark style preference is probably the main “feature” to come out of libadwaita — see Alexander’s recent post about it, if you haven’t already.
A properly supported dark style isn’t just a simple switch between two alternate CSS stylesheets, and the design team is currently working through a list of work items to make it into an excellent experience. This includes adjusting application-specific styling to work in both light and dark styles, modifying any full-colour icons we use to have adequate contrast in both modes, and creating light and dark versions of the GNOME wallpapers.
We have also, obviously, been working on designs for how to expose the dark preference itself.
Another ongoing initiative is the design and development of Patterns. This is a demo app which is intended to accompany libadwaita and the HIG.
One explicit goal of Patterns is to demonstrate those design patterns which we recommend app developers as part of the HIG, as opposed to demonstrating every possible UI that the platform is technically capable of producing.
There is plenty of work yet to do on Patterns, so if you’d like to help out with this effort, just head over to its Gitlab project.
There isn’t much scope to add new widgets prior to libadwaita 1.0, but there are a few which the design team is hoping to sneak in. One of these is an updated about window design. The goal is to have a simple, refined design, which works on a variety of form factors.
Looking to the future
In addition to supporting development work that is currently ongoing, the design team is also working on designs which will hopefully happen in future versions of libadwaita, after 1.0, and I’ll give an overview of these so you can see what’s coming down the tracks. That said, all of these designs are speculative, so there is no guarantee that they will happen, or that they will happen in the form that’s described here. Also, note that the images here are mockups which aren’t a fully realistic representation of what any final UI might look like.
Boxed lists are a common design pattern in our apps, and libadwaita includes a number of convenience widgets to make it easy to create common types of lists and rows (currently, AdwActionRow, AdwComboRow, and AdwExpanderRow). One thing that’s missing here is a dedicated widget for rows which contain a text entry, and this is something that we’ve been actively exploring. It’s a tricky design problem but is something that we’re determined to resolve.
In-app notifications are the bars that appear below the header bars of some GNOME apps, to show transient messages. They have been used for some time, and play a key role in a number of core apps. However, despite their centrality, they have never really been supported by the platform, having been provided as cut and paste code from libgd, which has meant that they’ve often been out of reach for many app developers.
Toasts are planned to be a new widget which will be provided by libadwaita, and which will effectively replace in-app notifications. We plan on avoiding some of the issues that can be seen with the existing in-app notifications, by providing a simple API which takes care of the tricky aspects of showing message popups, such as message queing.
Another widget which we hope to provide an alternative to is GtkInfoBars. These have been around for a very long time, and are used in many apps to show a coloured strip below the header containing text and controls.
Info bars require developers to pack the content of the bar themselves, which results in consistency and quality issues, as well as more work for developers. Also, they aren’t adaptive. So we are planning to introduce a new widget – banners – which are simpler to use, adaptive, and which take care of their own internal layout. This will avoid the info bar issues of the past, and be less work to use.
Another area of design development has been selection mode. This is found in some of the GNOME core apps, but is not currently covered by the HIG. Recent design exploration has sought to refine and update the design pattern, in order to allow us to recommend it to developers.
A good next step here will be to try the updated design in a core app, so we get an opportunity to validate it.
Putting it into practice
Over the past few weeks, I’ve been updating a number of GNOME’s core app designs, to put our updating styling and design patterns into practice, and make sure that they work together.
Here, you can see what Contacts, Photos and Clocks might look like once ported to GTK 4 and libadwaita. Obviously, these are just experiments, but they are a helpful way of exploring our new direction.
I have to say that, applying the new style to existing apps has been extremely refreshing from a design perspective, and the new approach has been working even better than I’d expected. The simplified visual style feels lighter, and a number of awkward old designs clicked into place when using the new list and button patterns.
Many of the things that are being done for the GNOME platform right now have been a dream for many years, so the fact that they are now happening is incredibly exciting. Having fully supported design patterns, with integrated documentation and demos will be huge win for anyone creating apps for the GNOME platform.
Alexander Mikhaylenko deserves special thanks for his work on libadwaita, which is making all this possible. Tobias Bernard, Adrien Plazas, Chris Davis, Jakub Steiner, and Maximiliano are all also playing key roles.
While phenomenal progress is being made in this area, resources are tight and there’s a lot of work falling on the shoulders of a few contributors. A good number of things we would like to implement for libadwaita 1.0 won’t make it because of these constraints. Which is my way of saying: help would be welcome!