GNOME Shell user research goings on

It’s been a while since we last blogged about the GNOME Shell design work that’s been happening. While we might not have blogged in a bit, there’s been a lot going on behind the scenes, particularly on the research side, and it’s about time that we told everyone about what we’ve been up to.

As a side note: a great team has developed around this initiative. The existing design team of Jakub, Tobias and myself has been joined by Maria Komarova from System76. Maria has a particularly strong research background and was immensely helpful in running interviews. The development side has also been fully engaged with the process, particularly through Georges and Florian.

Research and goals

In addition to thinking and discussing the design goals that we outlined previously (here and here), the design team has conducted two research exercises over the past six months. The main research exercise was a series of interviews with existing GNOME users. We also ran a small survey, to get some baseline numbers on user behaviour. I’ll mostly be talking about the interviews here.

The goals of the interviews was to a) get general information on how the shell gets used, b) evaluate how the existing shell design is performing, and c) identify ways in which the shell could be improved for our users. In addition to these fairly specific goals, we also wanted to develop a deeper understanding of our users: how they use their computers, their concerns, predispositions, interests and attitudes.

Interview-based research is a classic research approach for answering these kinds of questions, which are particularly appropriate to ask early on in a design process, when the emphasis is on exploration, insight and understanding. (Some readers might be more familiar with usability testing as the means through which data-driven design gets done, and that is a useful approach, but it typically happens later in the process.)

The survey

The survey element of our research was a smaller exercise than the interviews, so I won’t go into it in much detail. It was solely conducted within the confines of Red Hat’s Desktop Team, purely for convenience’s sake, and was able to provide some initial numbers for use by the design team.

The survey was an opportunity to ask users about their number of running apps, open windows, workspace usage, and a number of other behavioural factors. The key goal of the exercise was to identify typical workloads as well as the extremes, in order to inform our design requirements around the shell and the overview.

For example, through this exercise, we found out that the modal number of open windows was 8, and the highest number was 28. We also found that most people (63%) were using a single workspace, and that the largest number of workspaces in use was 10.

Clearly, such a limited exercise has to be treated with a high degree of caution, but some quick preliminary numbers were a useful frame of reference and are something that we hope to build upon in the future.

The interviews

The rest of this post will be devoted to the interview exercise that we conducted. Here’s what we did…

We conducted seven interviews in total, each conducted remotely. Interviewees were recruited from through the team’s professional contacts. We avoided talking to anyone who is directly involved in desktop development, and we tried to recruit research participants with a range of roles and technical backgrounds. We had some developers, but we also had people who work in sales, marketing and support.

During each interview, we got general background information about the interviewee and their computing activities. Then we conducted a screen sharing exercise in which the interviewee showed us how their desktop was set up. Then we ran through some exercises to see how they performed basic tasks.

We also used the interviews to ask evaluative questions, to see what the interviewee thought about the current shell design, and how it compares to other desktops.

We took notes on each interview. We mapped out the responses we got. We identified themes and patterns.

Research results

Let’s start by talking about the user behaviours that we observed. A quick summary:

  • The number of apps in use was generally low, 3-5 being the common range, both in the interviews and the survey.
  • Search was prominent as a way of launching apps, but we also observed occasional pointer-driven app launching (curiously, this seemed common when launching some apps and not others).
  • Engagement with the app grid was very low.
  • About half the interviewees had customised the favourites in the dash.
  • Workspace usage was quite mixed: some used workspaces extensively, while others never touched them [1, 2].

These findings have direct relevance to the design areas that the team are investigating. For example, they imply that our designs need to cater both to users who use workspaces extensively, and those who don’t.

The results also posed some conundrums. For instance, is lack of engagement with the current app grid an indication that its design needs to be improved, or that the feature should be demoted or relegated, somehow?

Likes and dislikes

While much of the research findings related to observed behaviours, the interviews also allowed us to ask evaluative research questions. We wanted to know how the existing GNOME Shell design is performing, and how it can be improved.

The main thing that came across here is that overall, the existing design appeared to be working well for the users we spoke to. With one exception, all the interviewees thought that the design compared favourably with other desktops they’d used. (Of course, this insight needs to be taken with a touch of salt [3].)

Most of the interviewees identified things that they like about the current shell design. They seemed to really like the search feature, in particular its speed, but also that it’s just a single keystroke away. The overview also received regular praise (one interviewee described it as “fantastic”).

The other thing that repeatedly came up as a positive aspect of the existing design is its none-distracting nature. Interviewees paid the shell compliments by saying things like “it’s not cluttered” and “it gets out of my way”.

The main issues with the current design that came out of the research was the frequent lack of engagement with the dash and app grid. We also got a hint that onboarding might be a struggle for some, and we got a clear message that touchpad gestures need to be improved (confirming one of our initial hypotheses).

What’s next?

We are already planning additional rounds of research (which we will endeavour to blog about in a more timely fashion!) Some of these will be open to wider participation so, if you are interested, we would love to have you involved!

The design team is also exploring various concepts for the shell, which we hope to present in the not too distant future. Indeed, one of the reasons for all this research work is to help us be confident about the designs before we present them to the world! Watch this space.

Footnotes

[1] There was also behavioural variation within the group of workspace users: some had developed systems for themselves, with certain workspaces dedicated to particular activities, while others allowed their workspace usage to evolve organically as they worked.

[2] Workspace usage did not appear to be positively related to technical expertise. If anything, the opposite was true, with the less technically-expert making more use of workspaces rather than less.

[3] Some notes on: representativeness and generalisability. How can only seven users provide useful results? Won’t we have missed critical user types? Won’t the sample be unrepresentative?

The first thing to say here is that small-N studies (those with a small number of participants) are valuable and can deliver significant insights, and have important advantages over large-N surveys. In particular, they allow accurate observations to be made, without making assumptions about what’s going to be seen.

Second, small-N studies like this allow relationships to be identified, and these can be used to infer qualities of a wider population. For example, if you observe that technically expert users tend to use the keyboard more, and you know that you have a lot of technically expert users, you can make a guess that keyboard use is important for the population as a whole.

Third and finally, experience tells us that small research studies can and do pick up on general trends and behaviours with remarkable speed (such as with the rule of five in user testing).

That said, we certainly do need to acknowledge the non-representative nature of our interview sample. We did include some relatively non-technical users, but the sample as a whole was skewed towards the more technical/professional end of the spectrum, and was taken from organisations that are invested in the Linux/GNOME desktop to varying degrees.

This doesn’t mean that the results we got are invalid. We are confident that our research findings are accurate with regards to the people we spoke to, and that those people are indicative of a larger section of the GNOME user population. The only question is is whether there are other types of user who we didn’t include.

GNOME Shell UX Plans

With GNOME 3.36 out the door, it’s time to start thinking about what comes next. Those of us who work on GNOME UX are really proud of the latest GNOME shell release. It includes some major updates, particular the new lock screen and updated visuals, as well as a host of smaller improvements. 3.36 feels really nice to use, and has got a great response.

The new lock screen in GNOME 3.36

The lock screen work that we landed in 3.36 was the outcome of a long-running programme of UX work, which we first put together at the GNOME UX hackfest in London, back in 2017. There are still some outstanding pieces of the login/unlock experience that need to be filled in, and this is something that we hope to work on over the coming development cycle. However, we are also turning our attention to other aspects of the shell, which we have wanted to update for some time.

In the rest of this post, I’ll describe some of the areas that we’re hoping to improve, before going on to talk about how we’re going to do it.

Focus areas

The areas that we are looking at mainly relate to the overview, although in places they touch other areas of the experience. They are:

Application launching

One thing we’ve wanted to improve for some time is the reliance on the alphabetical grid of launchers. This alphabetical organisation is mostly useful for finding applications by name, rather than presenting the apps that are most important or most likely to be used. This is something that the grid of frequent apps attempts to compensate for, but the overall experience doesn’t fit together as well as we’d like.

The application grid

For application launching, the main goal is to make the apps space more useful – it needs to be easier to find the app that you want to launch. However, we also want to make it a more engaging and personal part of the experience, so the apps space feels like it belongs to you.

Overview spatial organization

We are all familiar with the organisation of the overview: window thumbnails in the middle, dash on the left, search up top, workspaces on the right. Functionally this works fairly well. However, the layout could be better in terms of how the pieces fit together. In particular, the arrangement of the different elements could do a better job of communicating how they relate to one another, especially in terms of navigation.

The Activities Overview

Boot and empty states

Boot into GNOME 3 and you’re presented with an empty desktop. Open the Activities Overview, and you’re again presented with an empty space in the middle of the screen. This experience isn’t particularly helpful, and doesn’t draw or guide the user into the experience.

Overview initial state

We’ve been aware of these disadvantages of the current design for almost the entire history of GNOME 3, and we have experimented with a few different solutions, but never managed to get them to a usable state. Now, as we take another look at how the overview is arranged, we’d like to have another attempt at getting this right.

Touchpad navigation

Right now, the touchpad gestures to move between workspaces are fairly straightforward: 4 finger swipe up and down. However, we currently don’t have an easy gesture to go in and out of the overview and, once you’re in it, we don’t have an easy way to navigate between the different areas (app launching and search in particular).

Being able to scoot around different areas of the desktop using a touchpad (or, indeed, a touchscreen) would be a big win and is something we are keen to allow. In order to do this, we need a simple model that people can use to navigate around, rather than having to learn multiple sets of gestures.

How we’re going to do it

Work in this area is already ongoing, and we’ve put a lot of thought into how to organise it in order to achieve a good result.

Research & design

Some of the functionality that is under review is a prominent part of GNOME 3, so it’s important that any changes we make are a genuine improvement. When it’s a core part of the desktop, even a small regression can be a significant issue for some users.

User research is going to be a key part of this process, both in order to ensure that we have a good understanding of user needs and requirements, as well as to test the outcome of design and development work, and modify it as necessary.

We have already done some initial, limited research, to find out how many windows, apps and workspaces are typically in use. The next research phase is currently being planned, and will involve a series of show and tell exercises, combined with semi-structured interviews, to get a better sense of how people use their desktops, and how the design can be improved for them.

Looking further ahead, we’ll conduct testing on any changes that we make, in order to evaluate how successful they are and ensure that users experience them as a genuine improvement over what came before.

At each stage, we hope to share the results of our findings.

Testing and iteration

Wherever possible, we are planning on landing UI changes incrementally, with an emphasis on maintaining a releasable product. This will allow us to pace our work and do testing and refinement throughout the development cycle, rather than just at the end.

When it isn’t possible to compartmentalise UI changes, we are planning on making development builds available early, in order to carry out testing and iteration over a longer period. This is likely to be the case for the bulk of any changes, due to the interconnected nature of the overview.

Watch this space

Design changes to GNOME Shell can generate both speculation and uncertainty. We’d like to mitigate this as much as we can, so that people understand what changes are coming, why they are being made, and why they can be confident that they are a real improvement.

Currently, there are a variety of experimental designs. However, we haven’t settled on a single proposal and don’t want to create false expectations by presenting them at this early stage. Hopefully once we have done more rounds of research we will be in a position to do this, and give a better idea of what UI changes might be coming further down the line. Until then, we ask you to be patient!

We also hope that the research, testing and feedback opportunities that we are planning will provide reassurance that any changes we eventually make will be positive. We are committed to make changes based on these data gathering exercises, if it turns out that the designs don’t perform as well as we’d hoped.

We will endeavour to provide progress reports on this work as it progreses, so watch this space for news!

Login and unlock in GNOME Shell 3.36

The upcoming GNOME 3.36 release includes a major update to the system login and unlock experience. The new design has been anticipated for a long time, and we’re excited that it has finally arrived!

Some history

The lock screen in GNOME 3.6

GNOME’s existing login and unlock design has been largely unaltered since it was first introduced in GNOME 3.6, back in September 2012. That’s seven and a half years ago! It’s therefore no surprise that we’ve wanted to update the design for some time.

The initial round of design work for the new lock screen took place in 2017, at the GNOME UX hackfest in London. There, the GNOME design team, along with GNOME Shell developers, reviewed the goals and requirements, as well as the issues with the existing design, including the main areas of feedback that we’ve had.

Lock screen planning at the 2017 UX hackfest

The design concept that we came up with during that event has undergone significant refinement since 2017, but the basic principles and goals remain the same. These can be summarised in three words: smooth, beautiful and personal.

Reducing friction

Unlocking the system is something that people do over and over, so it’s important that it doesn’t feel frustrating, and it needs to get you from A to B as quickly as possible. One of the goals of the design update was therefore to reduce the amount of friction involved in unlocking (or logging in for that matter).

From this perspective, the most obvious change in the lock screen is that the grey login screen is now gone. Rather than removing the “shield” to show the password field, the password field is shown right on the lock screen itself. This doesn’t necessarily change how many keystrokes or clicks are required to unlock, but it does reduce how many distinct visual steps are involved, and makes the whole experience feel faster and more direct.

We’ve also incorporated other changes which are intended to make it quicker and easier to unlock. There are more methods to show the password field than before: you can click with a mouse or touchpad button. You can also scroll with a mouse, or swipe with a touchpad or touchscreen. Small changes like this add an extra degree of convenience in many situations.

Other changes in this area are planned for the future. One of the biggest is to jump straight to the last-logged in user after boot, rather than requiring a user account to be selected every time. In most situations, this will take an extra step out of logging in: all you’ll have to do is boot, then enter your password, and off you’ll go.

More happy times

If getting to your work more easily is one of the big themes for the updated design, then the other is having a more joyful experience along the way. Unlocking is a chore, but it shouldn’t have to feel like one. It can and should be pleasurable.

With the new design, we wanted unlocking to be beautiful, and we’ve put a lot of work into visuals. The most obvious change is the use of the blurred background, which we love. Not only does it look great, but it also serves as an effective background for legible, light-weight typography, so it’s possible to have elegant text, without the need for heavy type or drop-shadows.

There’s also been lots attention to detail throughout design and development process, which we hope will make the login and unlock experience feel delightful to use. This includes things like the updated layout of the authentication elements, the subtle use of animation to communicate incorrect authentication attempts, and the transition from the clock to the password field.

Making it personal

A final, and perhaps more subtle, aspect of the updated design is the effort to make it feel personal. We want to connect the login and unlock with the user’s desktop experience, so the user gets a hint of their session even when they are logged out or the system is locked. The main way we’re doing this is the use of the blurred wallpaper, which is intended to communicate what lies on the other side of login/unlock.

Mockup for the redesigned user selection screen

The use of strong personal elements, like the user avatar and blurred background image, is also something that we intend to build on in future versions, by bringing them into the user selection screen itself. The goal here is to bring user selection alive: to make it more expressive and indicative of the person to which each account belongs.

Getting to this point

On the development side, the login/unlock redesign has primarily been carried forward by Georges Stavracas, with significant assistance from Umang Jain and Florian Müllner. It has been a significant amount of work and we owe them a lot of gratitude for the time and effort they have invested in this project.

Next steps

The login/unlock redesign was merged slightly late in the GNOME development cycle. To compensate for this, it is undergoing an intensive testing and bug fixing effort. Help is needed with this, and there is a test plan available for those who would like to try the new design and report any issues they find.

As mentioned above, looking beyond GNOME 3.36, there are a number of aspects of the design which are yet to be implemented and which we hope to have for the next release, version 3.38, so there is hopefully plenty more to look forward to in this area.