Form and Function

This week I participated in the Parental Controls and Metered Data Hackfest, which was held at Red Hat’s London office.

Parental controls and metered data already exist in Endless and/or elementary OS in some shape or form. The goal of the hackfest was to plan how to upstream the features to GNOME. It’s great to see this kind of activity from downstreams so I was very happy to contribute in my capacity as an upstream UX designer.

There have been a fair few blog posts about the event already, so I’m going to try and avoid repeating what’s already been written…

Parental controls

Parental controls sound like a niche feature, but they actually have wider applicability than limiting what the kids can do with your laptop. This is because the same features that are used by parental controls can be useful for other types of functionality, particularly around “digital well-being”. For example, a parent might want to limit how much time their child spends using the computer, but someone might want to self-impose this same limit on themselves, in order to try and lead a healthier lifestyle.

Furthermore, outside of parental controls, the same functionality can be pitched in different ways. A feature like limiting the use of particular apps to certain times of the day could either be presented as a “digital well-being” feature, where the goal is to be happier and healthier, or as a “productivity” feature, where the goal is to help someone get more out of their time in front of the screen.

There are some interesting user experience questions that need to be answered here, such as to what extent we should focus on particular use cases, as well as what those use cases should be.

We discussed these questions a bit during the hackfest, but more thought is going to be necessary. The other next step will be to figure out what the initial MVP should be for these features, since they could potentially be quite extensive.

Metered data

Metered network connections are those that either have usage limits attached to them, or those which have financial costs for usage. In both cases this requires that we limit automatic/background network usage, as well as potentially showing warnings if the user is doing something that could result in high data usage.

My main interest in this area is to ensure that GNOME behaves correctly when people use mobile broadband, either by tethering their phone or when using a dedicated mobile broadband connection. (There’s nothing more frustrating than your laptop silently chewing through your data plan.)

The first target for this work is to make sure that automatic software updates behave well, but there’s some other interesting work that could come out of it, particularly around controls for whether unfocused or backgrounded apps are allowed to use the network.

Philip Withnall has created a survey to find out about peoples’ experiences using metered data. Please fill it out if you haven’t already!

Credits

The hackfest was a great event, and I’d like to thank the following people and organisations for making it possible:

• Philip Withnall for organising the event
• The GNOME Foundation for sponsoring me to attend
• Red Hat for providing the venue

If you follow Planet GNOME, you’ll know about Jim Hall’s fantastic usability testing work. For years Jim has spearheaded usability testing on GNOME, both by running tests himself and mentoring usability testing internships offered through Outreachy.

This Autumn, Jim will once again be mentoring usability testing internships. However, this time round, we’re planning on running the internships a bit differently.

In previous rounds of usability testing, the tests have typically been performed on released software: that is, apps and features that are already in the hands of users. This is great and has flagged up issues that we’ve gone on to fix, but it has some drawbacks.

Most obviously, it means that users are exposed to the software prior to usability testing takes place. However, it also means that test results can take a long time to be corrected: active development of the software in question might have been paused by the time the tests are conducted, and it can sometimes take a while until a developer is able to correct any usability issues that have been identified.

Therefore, for this round of the Outreachy internships, we are only going to test UX changes that are actively being worked on. Instead of testing finished features, the tests will be on two things:

1. Mockups or prototypes of changes that we hope to implement soon (this can include static mockups and paper or software prototypes)
2. Features or UI changes that are being actively worked on, but haven’t been released to users yet

One goal is to increase the number of cycles of data-driven iteration that our UX work goes through. Ideally there should be multiple rounds of testing and design changes prior to coding even taking place! This will reduce the amount of UI changes that have to be made, and in turn reduce the amount of work for our developers.

Organising the tests in this way, we’re drawing on ideas from agile and lean. The plan is to have a predefined schedule of tests. When test day rolls around, we’ll figure out what we want to test. This will force a routine to our practice and ensure that we keep the exercise light and iterative.

There’s lots of work in progress UX work in GNOME right now, all of which would benefit from testing. This includes the new menu arrangements that are replacing app menus, new sound settings, new design patterns for lists, new application permission settings, the new lock screen design, and more.

One thing I’d actually love to see is design initiatives rejected outright because of testing feedback.

This approach to testing is an experiment and we’ll have to see how well it works in practice. However, if it does go well, I’m hopeful that we can incorporate it into our design and development practice more generally.

Jim and the rest of the design team will be looking for help from the rest of the GNOME community as we approach the test days. If anyone wants to help make prototypes or make sure that development branches can be easily run by our interns, your help would be extremely welcome. Likewise, we’d love to hear from anyone who has development work that they would like to have tested.

Application menus – or app menus, as they are often called – are the menu that you see in the GNOME 3 top bar, with the name and icon for the current app. These menus have been with us since the beginning of the GNOME 3.0 series, but we’re planning on retiring them for the next GNOME release (version 3.32). This post is intended to provide some background on this change, as well as information on how the transition will happen.

Background

When app menus were first introduced, they were intended to play two main roles. First, they were supposed to contain application-level menu items, like Preferences, About and Quit. Secondly, they were supposed to indicate which app was focused.

Unfortunately, we’ve seen app menus not performing well over the years, despite efforts to improve them. People don’t always engage with them. Often, they haven’t realised that the menus are interactive, or they haven’t remembered that they’re there.

My feeling is that this hasn’t been helped by the fact that we’ve had a split between app menus and the menus in application windows. With two different locations for menu items, it becomes easy to look in the wrong place, particularly when one menu is more frequently visited than the other.

One of the other issues we’ve had with application menus is that adoption by third-party applications has been limited. This has meant that they’re often empty, other than the default quit item, and people have learned to ignore them.

As a result of these issues, there’s a consensus that they should be removed.

The plan

We are planning on removing application menus from GNOME in time for the next release, version 3.32. The application menu will no longer be shown in the top bar (neither the menu or the application name and icon will be shown). Each GNOME application will move the items from its app menu to a menu inside the application window (more detailed design guidelines are on the GNOME Gitlab instance).

If an application fails to remove its app menu by 3.32, it will be shown in the app’s header bar, using the fallback UI that is already provided by GTK. This means that there’s no danger of menu items not being accessible, if an app fails to migrate in time.

We are aiming to complete the entire migration away from app menus in time for GNOME 3.32, and to avoid being in an awkward in-between state for the next release. The new menu arrangement should feel natural to existing GNOME users, and they hopefully shouldn’t experience any difficulties.

The technical changes involved in removing app menus are quite simple, but there are a lot of apps to convert (so far we’ve
fixed 11 out of 63!) Therefore, help with this initiative would be most welcome, and it’s a great opportunity for new contributors to get involved.

App menus, it was nice knowing you…

Last November we had a small hackfest in London, focused on GNOME Shell design. We explored various themes during the hackfest and came up with a bunch of initial designs, which we’ve subsequently been developing. The main area of recent work has been the login and unlock experience. The rest of this post gives an overview of the design that we’ve come up with.

Background

Unlocking and logging into a device is something that people do a lot. Since people do it a lot, it’s important that the experience is smooth and doesn’t get in the way. However, it’s also important for it to look and feel really good. Login/unlock is the gateway to the rest of the experience. It is the public face of the product. It therefore needs to make a good impression and reinforce a positive relationship with the user.

This is one of the reasons why we’ve spent a fair bit of time on the design for login and unlock, as well as why we’ve involved a larger design team than usual. The hackfest that we had last year allowed us to bring extra designers in – people like Robin Tafel (Endless) and Cassidy James (System76/elementary OS) – as well as to work more closely with new regular participants, like Tobias Bernard.

When we originally discussed login/unlock at the hackfest, we came up with a long list goals and objectives for the new design. Chief amongst these was the idea of making the lock screen frictionless, so that people can get to their session easily. We also wanted to add a little joy and delight to an experience that can sometimes feel a bit flat, and we wanted to improve the navigational aspects of the design, with a clear spatial model.

Finally, we wanted to improve how the login/unlock UI performs in different scenarios. the current design works reasonably well for a small number of users, but doesn’t perform great on single user machines, or on those with many users. We wanted to make sure that it scales.

The lock screen

Without further ado, mockups! Here’s what we currently have for the lock screen:

Key press or mouse click then reveals the password entry:

This motion mockup shows what the transitions would look like, going from the session, to a locked screen, and back to the session again:

As you can see, the existing “shield” concept has been retained – when you lock the device, a layer appears to slide down over the content. This slides up when the system is unlocked. We’ve tried to hold on to some of the character of the existing design, particularly with the centered time and date, so it is identifiably the same product as before.

So what’s changed? Here are some of the main things:

1. The grey background is gone – the password field appears with the same background as the rest of the lock screen. This reduces the amount of friction the user experiences when logging in, and makes the process a lot smoother.
2. Notifications are more minimal, have been moved to the side of the screen, and continue to be shown while the user authenticates (they’re currently hidden once the password field is visible) – giving users more time to register what’s been happening while the device has been locked.
3. We’re going straight to user login from boot. This is an obvious win for single-user systems, since it’s less work to start using the machine. However, it’s also usually the right thing to do for multi-user systems too, since there is often one person who uses the machine more than others.
4. We’re using a blurred version of the regular desktop background for the lock screen wallpaper, rather than a separate user-defined lock screen wallpaper. This is suggestive of a semi-transparent film or sheet that’s been placed over the session, but it also ties in with the user selection screen (described below).

There are a number of other smaller changes too, which I won’t go into here, although I’m obviously happy to answer questions, and there’s also more information on the design page.

User selection

The other major part of the design is the user selection screen. This can be accessed from the lock screen as well as the session, and is used when switching user. The existing implementation uses a fairly simple list of users. We’ve given this a fairly thorough overhaul as part of the new design:

There’s also a motion mockup, which shows the transition from boot to login to user selection:

As you can see, the new design uses a grid of tiles, each of which features a blurred version of the user’s wallpaper. These are a key part of the spatial model for login. This allows users to orient themselves and contextualises navigation.

The user grid is designed to scale, so that it works well with large numbers of users. There’s also a simple username entry screen that can be used on deployments where a grid of user accounts might not be appropriate.

Next steps

We’re hoping that work on implementing the designs will start soon, and it would be great if anyone wants to help make them a reality. That said, the designs aren’t set in stone, and we expect them to continue to evolve as we get feedback and as implementation takes place. Hopefully we’ll get chance to do some user testing on them too, before they land in a stable version.

Questions and comments are welcome.

GNOME Shell has made significant improvements over the years since GNOME 3.0 was first released. This has included overhauling notifications, introducing a unified system status area, and refining how window selection and application launching works. Additionally, a huge amount of work has gone into polishing the experience through many many small improvements.

At the same time, some of the core elements of the GNOME Shell experience haven’t significantly changed for some time, and I have started to feel that a round of improvements is due, both to address long-standing issues and to ensure that the shell continues to develop in ways that our users value.

GNOME is also in the fantastic position of having new partners who we are developing working relationships with, particularly around the shell. Nowadays there are a variety of derivatives who are using the shell, including Endless, Ubuntu and Pop!_OS, and there’s a real desire to collaborate over the future of the shell and share in any benefits that might result.

Last week, these twin desires coalesced as a user experience hackfest which aimed to improve the design of the shell.

The hackfest was deliberately small, in order to provide a conducive environment for design work. Participants included Robin Tafel, Cosimo Cecchi, Jakub Steiner, Tobias Bernard, Florian Müllner, Cassidy James Blaede, Mario Sanchez Prada and myself (Nick Richards also called in). These individuals had affiliations with Endless, Red Hat, System76 and elementary OS, and they included both experienced GNOME designers and fresh perspectives.

While there wasn’t anyone from Ubuntu at the hackfest, we are in contact and I’ll be working to ensure that they are included in the process that the hackfest has initiated.

Overall, I was extremely happy with the event, and we came away with some exciting plans, which we think will result in major improvements to the GNOME Shell user experience.

Turning the ideas we’ve generated into viable designs will be a lot of work, and I’ll provide more details once some of the details have been filled in. In the mean time, Cassidy has written up a detailed account of the hackfest, which includes some more specifics for those who are especially interested.

I’d like to thank the GNOME Foundation for sponsoring my attendance at the hackfest, as well as Endless and Red Hat for providing the space for the event. I’d also like to offer my heartfelt gratitude to all the attendees, every one of whom made valuable and talented contributions over the four days.

Photo courtesy of Jakub Steiner (CC-BY-SA 2.0).