Author: Allan

In recent weeks, I’ve been working on a major update to the GNOME Human Interface Guidelines (HIG). The motivations for this work were varied. The HIG is fairly out of date, both in relation to contemporary design practice, as well as GNOME platform capabilities, and so needed updating. But we also wanted to improve the quality of the design guidance that we offer, and do a much better job at integrating our design docs with the rest of the developer platform.

As part of these changes, large parts of HIG have been restructured, and the vast majority of the content has been rewritten to some extent. It has also been expanded to cover a greater range of topics, including app naming, app icons, UI styling, accessibility and tooltips.

We’ve also changed how the HIG is hosted. It now has its own project on Gitlab, uses a lightweight markup language, and has its own website which is automatically updated to reflect the latest changes. This makes it a much more attractive proposition for contributors, and we’re already seeing the number of contributors increase.

A New Era

The new HIG comes at an exciting time for the GNOME platform — there have been some truly amazing developments recently!

First, GNOME design conventions have matured significantly and, I think, are in a really strong place. In the past we maybe didn’t have all the pieces in place, but now it feels like we do, and have a much more comprehensive, integrated and consistent design system.

Second, the platform itself has seen some major improvements, with the release of GTK 4 and the development of libadwaita and libhandy. These include a big set of features that designers and developers can take advantage of, like new widgets for tabs and drop-down lists, a new widget for placeholders, and GTK 4’s high-performance list and grid views.

Third, thanks to Bilal and Zander, we now have a whole collection fantastic design apps, including App Icon Preview, Symbolic Preview, Icon Library, Color Palette and Typography.

Finally, we also have new tooling for API documentation, thanks to Emmanuele and gi-docgen.

If you put all of this together, I think you’ve got a recipe for a really great developer experience. The new HIG aims to bring all these different pieces together: it documents the current state of the design system, references all the latest widgets, tells you when to use the design apps, and links to the correct places in the new developer docs.

Design >< Code

The old HIG documents design conventions which require developers to either use cut and paste widgets, or to write their own custom UI. Often it isn’t clear how this can be done. Not a great developer experience.

The new version does away with this, and has a closer relationship with the developer platform. Every design pattern has a corresponding widget which is included in the developer platform, which the HIG explicitly references. This means that, if you’re using the HIG, you can be confident that everything it describes can be easily implemented.

As part of this effort to bring the HIG closer to the platform, there have been a few terminology changes. For example, “grids” are now “flow boxes”, and “presentation dialogs” have become “secondary windows”. This will hopefully help to ensure that designers and developers are talk the same language.

There’s also been a lot of back and forth with platform developers, to ensure that the design guidelines are in tune with technical reality (which hasn’t always been the case, historically).

Notable Changes

Most of the changes in the new HIG shouldn’t be disruptive: most of them are additions or restructuring of existing advice. However, if you are responsible for an app, there are some changes which it’s worth being aware of.

Widget Updates

As mentioned, the HIG contains advice on using new widgets, and there are a number of places where it recommends using a new widget in place of an old one:

Design Pattern	Old Widget	New Widget
View switchers	Linked toggle buttons	AdwSwitcherBar/HdySwitcherBar
Drop-down lists	GtkComboBox, or custom-build your own	GtkDropDown
Tabs	GtkNoteBook	AdwTabBar / HdyTabBar

There’s also a number of new widgets that we recommend where none previously existed. This includes:

• AdwStatusPage and HdyStatusPage for placeholders
• AdwPreferencesWindow and HdyPreferencesWindow for preferences windows
• GtkPasswordEntry for text entries containing secrets
• GtkListView, GtkColumnView, and GtkGridView for large and/or dynamic lists and grids

Utility Panes

Utility panes is a new term for an old concept: a sidebar which includes navigation, information or settings for the current view. It has been introduced to differentiate between sidebars which contain supplementary content for the view, as opposed to sidebars that act as the top-level navigation of a window (the latter being what we actually call a sidebar).

This distinction becomes particularly relevant when it comes to responsive behaviour since, when the window becomes narrow, a sidebar needs to collapse to become the top-level view you go back to, whereas a utility pane needs to behave so that it’s secondary to the main view.

Tooltips

The previous HIG was silent on the subject of tooltips, which led to a fair amount of inconsistency. This has been corrected with the new version. The advice boils down to: show tooltips for all the controls in header bars. Otherwise, use them with restraint, but do so consistently.

Tooltip labels should be similar to button labels (for example, "Fullscreen") as opposed to being written as descriptions (for example, "Press to switch to fullscreen").

Placeholders

The old HIG documents two types of placeholders: initial state placeholders, and empty state placeholders. The former were colourful and engaging, and intended to support onboarding, while the latter were muted and non-distracting, and for cases when a view was, well, empty.

The previous advice was a bit on the complicated side: it said to use both types of placeholder in the same view, depending on circumstances. A user would see the initial state placeholder on first run, but if they populated the app and then removed all the content, they’d get the empty placeholder.

For the new HIG, we’ve simplified the advice. We still have two types of placeholder, but we advise to just use one for each view. So, if you have a main view which uses a more engaging placeholder, then that’s what should be shown whenever that view is empty.

Accessibility

As part of the rewrite, I’ve reviewed GNOME’s old accessibility UI design guide, and incorporated any relevant material directly into the HIG. This means that we’ll be able to retire the UI section of the accessibility guide, and accessibility will be integrated into a standard design guidelines, as it should be. If you happen to still use the old accessibility guide, it’s recommended that you switch to the HIG instead.

Next Steps

The new version of the HIG is yet to officially replace the old one, and is being hosted in a temporary location. Some of us are going to be working on an updated developer.gnome.org site in the near future; once that’s done we’ll publish the new HIG alongside it.

There are a few critical pieces that the HIG will need in order to shine. First, it will need a stable libadwaita release, since the HIG is primarily targeting GTK 4. Second, it needs a demo app, with examples of the key design patterns. Neither of these are likely to be ready for the initial publication of the new HIG, but they are both in progress and hopefully won’t be too far behind.

The 2020 elections for the GNOME Foundation Board of Directors are underway, so it’s a good time to look back over the past 12 months and see what the current board has been up to. This is intended as a general update for members of the GNOME project, as well as a potential motivator for those who might be interested in running in the election!

Who’s on the board?

This year, the board has been Britt Yazel, Tristan Van Berkom, Philip Chimento, Rob McQueen, Carlos Soriano, Federico Mena Quintero, and myself.

Rob’s been president, I’ve been the vice-president and chair, Carlos has been treasurer, Philip has been secretary, and Federico has been vice-secretary.

In addition to these formal roles, each of our board members has brought their existing expertise and areas of interest: Britt has brought a concern with marketing and engagement, Federico has been our code of conduct expert, Rob has brought his knowledge of all things Flatpak and Flathub, Carlos knows everything Gitlab, and Philip and Tristan have both been able to articulate the needs and interests of the GNOME developer community.

Meetings and general organisation

The board has been meeting for 1 hour a week, according to a schedule which we’ve been using for a little while: we have a monthly Executive Director’s report, a monthly working session, and standard meetings in the gaps in-between.

This year we made greater use of our Gitlab issue tracker for planning meeting agendas. A good portion of the issues there are private, but anyone can interact with the public ones.

Making the board into a board

Historically, the GNOME Foundation Board has performed a mix of different roles, some operational and some strategic. We’ve done everything from planning and approving events, to running fundraisers, to negotiating contracts.

Much of this work has been important and valuable, but it’s not really the kind of thing that a Board of Directors is supposed to do. In addition to basic legal responsibilities such as compliance, annual filings, etc, a Board of Directors is really supposed to focus on governance, oversight and long-term planning, and we have been making a concerted effort to shift to this type of role over the past couple of years.

This professionalising trend has continued over the past year, and we even had a special training session about it in January 2020, when we all met in Brussels. Concrete steps that we have taken in this direction include developing high-level goals for the organisation, and passing more operational duties over to our fantastic staff.

This work is already having benefits, and we are now performing a more effective scrutiny role. Over the next year, the goal is to bring this work to its logical conclusion, with a schedule for board meetings which better-reflects its high-level governance and oversight role. As part of this, the hope is that, when the new board is confirmed, we’ll switch from weekly to monthly meetings.

This is also the reason behind our change to the bylaws last year, which is taking effect for the first time in this election. As a result of this, directors will have a term of two years. This will provide more consistency from one year to the next, and will better enable the Foundation and staff to make long-term plans. There has been a concern people would be unwilling to sit as a Director for a two year period, but we have significantly reduced the time commitment required of board members, and hope that this will mitigate any concerns prospective candidates might have.

Notable events

The GNOME Foundation has had a lot going on over the last 12 months! Much of this has been “operational”, in the sense that the board has been consulted and has provided oversight, but hasn’t actually been doing the work. These things include hiring new staff, the coding education challenge that was recently launched, and the Rothschild patent case which was settled only last week.

In each case the board has been kept informed, has given its view and has had to give formal approval when necessary. However, the areas where we’ve been most actively working have, in some respects, been more prosaic. This includes things like:

Code of conduct. The board was involved with the review and drafting of the new GNOME code of conduct, which we subsequently unanimously approved in September 2019. We also set up the new Code of Conduct Committee, which is responsible for administering the code of conduct.

Linux App Summit 2019, which happened in Barcelona. This event happened due to the joint support of the GNOME Foundation and KDE e.V, and the board was active in drafting the agreement that allowed this joint support to take place.

Guidelines for committees. As the board takes a more strategic oversight role, we want our committees to be run and report more consistently (and to operate according to the bylaws), so we’ve created new guidelines.

2020 budget. The foundation has had a lot going on (the coding challenge, patent case, etc) and all of this impacted the budget, and made financial scrutiny particularly important.

GNOME software definition and “Circle” proposal. This is a board-led initiative which addresses a long-standing confusion around which projects should be included within GNOME and make use of our infrastructure, branding and whether the teams involved were eligible for Foundation membership. The initiative was announced on Discourse last week for initial community feedback.

Updated conference policy. This primarily involved passing responsibility for conference approvals to our staff, but we have also clarified the rules for conference bidding processes (see the policy page).

In addition to this, the board has been involved with its usual events and workload, including meeting with our advisory board, the AGM, and voting on any issues which require an OK from the board.

Phew.

2020 Elections

As I mentioned at the beginning of this post, the 2020 board elections are currently happening. Candidates have until Friday to announce their interest. As someone who has served on the board for a while, it’s definitely something that I’d recommend! If you’re interested and want more information, don’t hesitate to reach out. Or, if you’re feeling confident, just throw your hat in the ring.

A little while ago, I wrote about using data-driven design approaches in GNOME. For the 3.36 development cycle we successfully used one these techniques to improve the Settings app, and I wanted to share the story of what we did, and how the testing we’ve conducted is feeding into the GNOME user experience.

Starting out

The inspiration for the testing initiative came from several sources of feedback. A number of our own contributors had complained that, in the Settings app, they struggled to remember which settings were in each of the two sub-sections (called Devices and Details). Then, last GUADEC, Deb Nicholson ran a SpinachCon (a kind of usability testing event) and a number people were observed having trouble finding some of the settings, particularly the Date & Time settings.

Suspecting that there might be an issue around settings navigation, we experimented with some ideas for how the structure of the Settings app could be improved.

Hypothesis testing

After a little experimentation, we came up with an updated design for settings navigation, which we hoped would solve the issue with the sub-categories. But would it work? I wanted to put the new design to the test, rather than assuming that the new design would be successful. Happily, the nature of the design – shuffling settings categories around – made it relatively easy to test. A simple paper prototype would do.

Paper prototyping is great if you can do it: it’s quick and easy to do and, most importantly, it allows different changes to be tested before developers spend time implementing them. The initial prototype consisted of a set of cards, each one representing one of the settings panels. These were laid out in front of the test participant, who was asked to pick a card where they thought a particular setting might be found.

After running a pilot test, I realised that the cards weren’t necessary and that a simple rendering of the list of settings panels would be more accurate, as well as being easier to produce (no more cutting up pieces of paper). The lesson: always run a pilot test!

With zero setup for the testing arrangements, the paper prototypes raised the possibility of drafting in volunteers from the GNOME community to help run the tests. To help standardise the tests, I wrote a testing script for the test facilitators to read out. The script included the list of test scenarios, for example:

You are in a cafe with your laptop, and you have connected to the wi-fi. A friend joins you and asks for the wi-fi password. Where would you go to look it up?

Each of these scenarios was designed to test a different aspect of the design, and we managed to test 16 separate scenarios over the entire exercise.

Test, redesign, test

In the first round of testing, we conducted the test with four people. Generally you would test with more people than this, but some issues with the design were already becoming clear. Improving the design and running tests on the new version seemed like a better use of our time, rather than re-confirming obvious problems.

We updated the design to try and resolve the issues that we saw in the first round of testing, and then we conducted tests on the new version. This design, test, redesign, retest is a powerful way to iteratively improve UX designs.

The results from the second round showed that the updated design had resolved a number of the issues we’d seen in the first round of testing. The main UI changes we were planning – grouping the networking settings, removing the sub-categories, moving default apps and removable media under apps – had all performed well. These results gave us the confidence to move ahead with the design changes.

The upcoming GNOME 3.36 includes some of these UI changes. Most noticably, the Devices and Details subsections have been removed (the settings they contained are now all visible on the top level). We’re confident that these changes will make it easier for users to find their way around the Settings app.

Further changes are planned for future releases: we want to consolidate the list of settings panels into fewer items, by merging the Wi-Fi and Network panels, and moving Default Applications and Removable Media inside the Applications section. These changes have been tested and, we think, validated from a navigation perspective.

New discoveries

The tests that we ran did their job, and allowed us to validate the updated Settings design prior to it being implemented. At the same time, we also discovered a number of other separate issues with Settings navigation. These varied in terms of their scale, and included issues in both the existing version and future changes that we have planned.

In some cases we’ve already been able to make improvements based on these new discoveries. For example, we’ve improved the icons for a number of the settings categories, to make it more obvious what they are. In other cases, we are still working on design solutions to the issues we observed. This includes things like:

• Making it easier to find the keyboard layout settings
• Helping people to get to the screen lock settings
• Reducing confusion around what Universal Access means

These are all small papercut issues which it will be great to try and make progress on over the upcoming 3.38 release cycle.

The additional issues that we discovered are a good example of how exploratory testing can have a role alongside validation of existing proposals. I think it also shows how research needs to be regular and ongoing: once we’ve figured out designs to fix these new issues, we should really do more tests to see if they really have been resolved.

Summary

Hopefully this initiative is a good example of how lightweight testing can improve quality and reduce design and development overhead by identifying design issues early in the development process.

The exercise enabled us to test a design, reject some aspects of it, and then test a revised version, without having to write a single line of code. Without this out-of-band testing, the same process would have required implementing the design, releasing it, (maybe) getting feedback, then redesigning it and implementing the new design.

The other really nice thing about this process is that it enabled a whole array of contributors to participate in the design process. By the end, we’d had 11 tests conducted by five contributors, located in four different countries. That’s pretty cool!

Speaking of contributors: many thanks to António Fernandez, Vojtech Stanek, Philip Withnall and Clarissa Borges, all of whom conducted tests and made this initiative possible.

This post is part of my blog series on GNOME UX strategy. The other parts in the series covered background research and analysis for the strategy, then outlined some high-level goals and principles, followed by an outline of recent design work which fits within the strategy. This can all be thought of as answering “what” and “why” questions: what should GNOME be doing, and why?

In this, the final post in the series, I’m turning to the question of “how”: how can the GNOME project can deliver all this? For me, this how question is just as important as the what and the why. Having an effective strategy means nothing if we can’t successfully deliver it.

This post is primarily about design and development process. I’m going to draw on my experiences working on the GNOME project, as well as methodologies from the wider software industry, and recent experiments that have taken place in the GNOME project. Agile is clearly present, but it’s just one element, and has necessarily been adapted to an upstream, open source context.

While these reflections on development process are an important part of the strategy I’m laying out, they hopefully have more general relevance to our work in the GNOME project and beyond.

The process matters

The naive view is that software quality is primarily determined by the character and skills of the individuals who have worked on that software. While these individual capabilities are undoubtedly important, they are only one part of the story. Indeed, I would argue that the design and development process is just as important as the skillset of those doing the work.

One reason for this is that UX work is never a solitary endeavour – it involves multiple people with different specialisms. How we work together is critical to success, because each of those specialisms don’t just need to be aligned, but also need to feed into one another.

In my time working on GNOME, I’ve been involved in some really successful UX initiatives, where we’ve delivered new features or updated versions of our software, in a way that has pleased and even delighted our users. I’ve also worked on initiatives that haven’t been successful. I’ve reflected on these, and have identified a number of recurrent issues. These include:

• New features that have been delivered in an incomplete state
• Implementations that have significantly deviated from the intended design and UX vision
• Usability or design issues which have been identified post-implementation, and have been subsequently unaddressed
• Designs whose ambitions have surpassed our engineers’ abilities to deliver them
• Rough and ready designs that have gone on to be implemented before they have sufficiently matured
• Designs which have been incompatible or out of alignment with the technical plumbing that they’re built on top of

I’ve previously argued that driving up UX quality is critical to the future success of the GNOME project. If we are to do this, issues like these have to be eliminated from our development practices. We can’t succeed if they occur in core development initiatives.

The good news is that all of these issues stem from the design and development process, and can therefore be avoided. This is also a real opportunity to learn from the wealth of experience that we have in the GNOME project, and develop best practice approaches.

What we need to do

There are three main things that I think we can do to improve our design and development processes.

1. Embrace iteration

A great man once taught me that design is all about iteration. He wasn’t wrong: designs that have passed through a lot of revisions are usually superior to those that haven’t. The same is true for software development.

Many of the issues that I identified above are a result of a failure to incorporate iteration into the development process. Iteration is key to eliminating bugs, but it is often also critical to ironing out larger design issues. Despite all our expertise and experience, it is impossible to anticipate every potential UX issue, or fully understand how a design will perform in practice. We therefore have to assume that many implemented features will contain issues that have to be addressed.

The first and most important step in embracing iteration is to change the way we think about the design and development process. Iteration has to be treated as being essential and non-negotiable. The time and resources that are required for iteration must be accounted for at the outset, with the first implementation being seen as just one step in the process.

If you, as a designer or a developer, don’t have the time to iterate on a piece of work, you probably shouldn’t be doing it in the first place. I’ve been guilty of this is the past, and it can be a hard habit to break. It’s so tempting to make drive-by design recommendations, or quickly implement a new feature that you’ve been wanting for ages. We must all resist that urge. High-quality software takes time and care.

The other way to embrace iteration is to build user testing and feedback into the design and development process. This isn’t hard to do, and has been successfully done in the GNOME project. For example, earlier this year, Clarissa Borges successfully ran user tests on a development snapshot of Files, which allowed us to refine design changes prior to release. Another example: right now, we are using paper prototypes to get real-world feedback on potential Settings changes. These tests can take mere hours to design and conduct, and can save weeks of developer time.

2. A closer relationship between design & development

Design and development aren’t separate domains. Designs need to reflect technical realities. Developers need to be familiar with the UX vision that they’re implementing. Designers need to be involved in the development of the underlying technologies and platforms. This requires shared understanding between designers and developers, at all stages of the process.

A good number of the issues I identified earlier in this post are what happens when that shared understanding is missing. This leads to all kinds of problems, like designers over-estimating what developers can achieve, or not fully understanding the technological constraints, or developers implementing something different from the UX vision.

It has become my firm belief that the more interconnected that design and development are, the better our software will be. A close relationship between these two specialisms prevents problems, helps shared understanding, and increases efficiency.

I’m going to describe four things that we can do to bring design and development more closely together.

First, we need to ensure high-bandwidth communication between design and development, throughout the process. This communication doesn’t have to be talking or messaging – it can be sharing of mockups, screenshots and screencasts, and testing of development code – but it does need to happen frequently.

Second, designers need to treat developer resources as a design constraint. Design work has to be speculative sometimes. However, when it comes to sitting down and implementing features or changes, it is vital to fit the design to the amount of developer time that’s available.

Third, we need to champion transparent design. Transparent designs reflect how the underlying technologies work, and don’t try to present a different picture. They are good for all the reasons that reducing technical complexity is good, plus the fact that they avoid leaky abstractions. Transparent designs sometimes expose issues with the underlying technical architecture, which can be painful, but also exerts pressure in the right place.

Fourth, designers need to get their hands dirty, and touch the code. This can take many forms, including using GTK for prototyping, editing CSS or GtkBuilder files, or making simple code changes. This is hugely beneficial! It’s vastly more efficient for designers to make simple changes themselves, rather than having to go back and forth with developers to make them on their behalf. In turn, these efficiency savings enable a higher level of precision and quality, since they allow designers to be far more specific and wide-ranging in their polish work. Having designers directly involved in development is also a fantastic way to improve the platform, since it makes us aware of how it works, and makes us even more invested in improving it.

To make this last point happen, designers need to push themselves to get involved in development (I have a rule for myself: don’t ask someone to make changes you couldn’t have a go at making yourself). However, we also need developers to make their projects designer-friendly. This means using things like CSS, GtkBuilder, and high-level languages.

3. Time-Based Coordination

The third and final thing that we can do to improve our design and development processes is to coordinate around blocks of time. Coordination for upstream projects is tricky. However, for many of the things that I’ve described above, we need to have shared expectations for how and when work will be done. It is only then that we can do things like testing of in-progress software, or have conversations about how much developer time is available for a particular initiative.

One possibility here is to organise ourselves around sprints, and Georges has spearheaded some really successful experiments in this area. It’s a simple idea: he divides his time into blocks, and gives the design team advance notice of what he will be working on and for how long. We can then ensure that he has the designs he needs. We can also ensure that those designs can be implemented in the time he has available, and even arrange testing to happen in the periods between time blocks.

It would be great if more developers embraced this approach!

Conclusion

It’s taken a while, but we’ve got to the end! If you’ve stuck with me for the entire blog series, well done, and thank you. I hope you’ve found it interesting, and maybe even useful.

For me the best outcome of this series would be if some of these ideas could be taken up more widely by the GNOME project (or other Free Software projects), and I’d love to discuss strategy or development process with other contributors.

This last post has been especially important to me, because it reflects my own developing practice and concern with successful UX delivery. I genuinely think that these techniques could revolutionise how we work, and am already seeing some major improvements through their adoption.

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.

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.

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:

• Unlock/login designs – mockups
• Calendar and notification list – Gitlab issue
• System menu improvement – Gitlab issue
• System dialog improvement – Gitlab issue, mockups
• Document viewer – design page
• Image viewer – design page
• Development platform – design pattern review page