New Simple Scan designs

Simple Scan is a great app and there’s a lot of love for it. It’s one of those reliable, indispensable tools that it would be hard to live without. Just because it’s great doesn’t mean that it can’t be improved, of course, and it was recently suggested that I take a look at its design.

Most of the improvements can be described as refinements. Right now there are a bunch of operations which can be a bit tricky to find, or which aren’t as obvious as they could be. There are also a few actions that are well and truly buried!

Let’s look at the mockups. First, the initial “ready to scan” state:

How it could look when scanning:

Finally, what a scanned document could look like:

The primary changes are the introduction of a sidebar for selecting a page and the use of an action bar at the bottom for performing page actions. This makes it much clearer which page is selected, which is important when you want to perform edits. It also helps to communicate the purpose of the edit buttons – right now crop and rotate are a little ambiguous, largely due to their placement.

There are some other smaller improvements. The scan button now communicates the image/text and single page/document feeder modes, which means that you don’t have to dig into the UI to find out what will happen when you click the button. Some options, like reorder pages, have been rescued from the relative obscurity of the app menu. The current “new document” action has been rebranded as “start again”, in order to communicate that it’s how you clear the current scan as well as start a new one.

I’ve also reworked the settings:

This uses an experimental approach to the brightness and contrast settings here. To be able to use these, someone really needs feedback on what the different settings look like in practice. To enable this, I’ve sketched out a test scan mode which produces samples using a range of settings. This allows the user to specify the settings by selecting the best sample.

Observant readers will notice a crop of new controls for features that don’t currently exist. This includes OCR text reading and editing, a zoom control, and a magic enhancement feature. These are mostly placeholders for features that Robert Ancell, the Simple Scan maintainer, would like to add at some point in the future.

As far as I’m aware, no one is lined up to implement these changes, so if anyone fancies taking a shot at them, that would be great. The initial changes are described in a couple of bug reports. For more details, you can also see the full mockups in all their warty glory.

Improving notifications in GNOME

Like a lot of people, I was really happy with the big notification redesign that landed in 3.16. However, I’ve been itching to return to notifications for a little while, in order to improve what we have there. Prompted by some conversations we had during the Core Apps Hackfest last month, I finally got around to spending a bit of time on this.

One of the main goals for this is to focus the UI – to improve the signal to noise ratio, by refining and focusing the interface. This can be seen in the new mockups that have been posted for the shell’s calendar drop down – the number of extraneous visual elements is dramatically reduced, making it much easier to pick out interesting information.

The other aspect of my recent work on notifications is to improve the quality of the notifications themselves. Notification for events that aren’t of interest, or which stick around for longer than necessary, can undermine the entire notifications experience.

This is why, aside from updating the shell’s UI for presenting notifications, the other aspect of this effort is to ensure that applications are using notifications effectively. This includes making sure that applications:

  • Only show notifications that are actually interesting to the user.
  • Revoke notifications once they have outlived their usefulness.
  • Give every notification a useful title and body text.

I’ve recently reviewed a bunch of GNOME applications to ensure that they are using notifications correctly, and have created a wiki page to track the issues that I found.

If you spot any GNOME applications not using notifications effectively, it would be great if you could help by filing bugs and add them to the wiki page. Likewise, if you work on an application that uses notifications, make sure to check that you’re following the guidelines. It would be really great if GNOME could achieve across the board improvements in this area for the next release!

Core Apps Hackfest

Last weekend I attended the Core Apps hackfest in Berlin. This was a reboot of the Content Apps hackfest we held last year around the same time of year, with a slightly broader focus. One motivation behind these events was to try and make sure that GNOME has a UX focused event in Europe at the beginning of the Autumn/Spring development cycle, since this is a really good time to come together and plan what we want to work on for the next GNOME version.

The format of the hackfest worked extremely well this year (something that everyone who attended seemed to agree on). The scope of the event felt just right – it allowed a good level of participation, with slightly over 20 attendees, a mixed agenda, and also opportunities for collaboration and cross-cutting discussion.

We had three designers in attendance, in the form of Jakub, Andreas and myself. This felt extremely helpful, as we were able to both work on tricky design tasks together as well as split up in order to support groups of hackers in parallel. We worked non-stop over the course of the event and pumped out a serious amount of design work.

In all the event felt extremely productive and is something I would love to repeat in the future.

What we worked on

One of the main design areas at the hackfest was how to allow the content applications (Documents, Music, Photos and Videos) the ability to open items in the Files application. This is something that has been on the cards for a while and we had already had designs for. However, reviewing the plan we had, we realised that it needed improvement, and we spent a good chunk of the hackfest evaluating different options before settling on an improved design.


View the complete wireframes

Software was another focus for the hackfest, as we had several Software hackers in attendance. On the design side, we worked on how to better integrate shell extensions. We also worked on improving the UI for browsing categories of applications and add-ons. The result was some fairly detailed mockups for changes we hope to make this cycle.


View the full wireframes

Towards the end of the event, Cosimo, Andreas, Jakub, Joaquim and I discussed plans for “content selection”. This is the idea of being able to open content items that are provided by sandboxed applications, in a similar method to the existing file chooser dialog, but without actually interacting with the file system. This way, applications will be able to make content available that isn’t stored in a shared home directory or might not even be stored locally on the device. It’s a tricky design problem that will require more work, but we made a good start on establishing the parameters of the design.

In addition to these main areas, there were lots of other smaller design tasks and discussions. We worked a bit on Music, talked a bit about Usage and even had a bit of time for GTK+ Inspector.


These events only happen due to the work of community members and support from GNOME’s partners and donors. Special thanks has to go to Carlos Soriano for organising the event. Also a big thank you to Kinvolk for hosting and providing snacks and to Chris Kühl and Joaquim Rocha for acting as our local guides. Finally, thank you to Collabora for helping to feed and water everyone!

Kinvolk Logo

Collabora Logo

Maple syrup

Last week I attended the GTK+ hackfest in Toronto. We had a really good group of people for the event, which lasted 4 days in total, and felt really productive.


There were a number of interesting discussion and planning sessions, from a design point of view, including a session on Flatpak “portals” and another on responsive design patterns.


I also got to spend a bunch of time talking about developer documentation with Christian and the two Philips and did a bunch of work on a series of designs for a web front end for Hotdoc (work on these is ongoing).


Finally, after the *ahem* online discussion around GTK+ versioning and lifecycles, I helped to document what’s being proposed in order to clear up any confusion. And I drew some diagrams, because diagrams are important.


Thanks to Matthias for organising the event, Red Hat Toronto for hosting, and Allison Lortie for being a great guide!

Diggin’ the crates

For a small team, GNOME design generates a huge amount of work. While we try to publicise as much of it as possible, not everything gets blogged about. In this post, I’m going to present design material from our archives that hasn’t featured in a blog post previously, and which you might not have encountered before. A lot of it is for less critical applications which, while interesting and important, aren’t the core focus of our activities.

The mockups that I’m including here are the raw wireframes that we’ve had sitting around in our design repository – they haven’t been finessed or polished for public consumption, so don’t be surprised if there’s the odd mistake or unfinished pieces here and there. The aim is to give an insight into the work, warts and all.


Usage is the name us designers have for a revamped System Monitor application. The name reflects the fact that we don’t want the app to be just about what your computer is doing right now – we also want it to be a place where you can get historical information about usage of resources like battery power or network.

We’ve had some designs sitting around for the Usage application for a while. Not so long ago I decided to update them a bit. In doing so, I added a section for disk usage, which is probably the worst part of the existing System Monitor app, and is loosely based on our Disk Usage Analyzer (aka Baobab).

Open to view the full wireframes
Open to view the full wireframes

Tweak Tool

Ah the trusty Tweak Tool! Some people seem to think that us designers don’t like it, which is quite the opposite of the truth: we’re the ones that conceived it in the first place! Anyway, the Tweak Tool could use a bit of love in some areas, so some time ago I produced a complete set of updated wireframes for it.

The new designs are primarily intended as a polish exercise: a lot of the UI has been refined to be nicer looking and easier to use.

Open to view the full wireframes
Open to view the full wireframes

Passwords & Keys

Yes, GNOME’s trusty passwords app has had a redesign! This one is further advanced than some of the others: Daiki Ueno has been working on the new version. The aim is to update the app to use modern design patterns, so it is consistent with the rest of GNOME 3. The current application exposes a lot of technical details about how passwords are stored, which isn’t helpful in a lot of cases, so we’re trying to only show those unless they are needed.

Open to view the full wireframes
Open to view the full wireframes


The world seems to have moved on from open chat protocols, unfortunately, and demand for chat clients that support them isn’t what it used to be. Nevertheless, there are still cases where they get used. With that in mind, we have some basic initial wireframes for a GNOME 3 chat application. These primarily exist in case anyone fancies having a go at writing a replacement for Empathy. They are intentionally incomplete, and are supposed to be just enough to get a developer started.

Open to view the full wireframes
Open to view the full wireframes


gitg, the GNOME Git client, had a few nice improvements last release. One or two of them were a result of a batch of mockups I did early in the last development cycle; there’s a lot more to these which it would be great to have implemented in the future, though.

The mockups make the toggle for switching between the history and staging/commit views much more prominent, which is appropriate considering how fundamental they are to the design, and subsequently makes key functions easier to discover. They also aim to make it really quick to stage, commit and stash changes, since these are some of the most frequent operations that people do with Git: it’s one click to stage a file and another to commit it (well, once you’ve written a commit message).

These designs are currently being discussing these with the gitg maintainers, and may well evolve in the near future.

Open to view the full wireframes
Open to view the full wireframes

That’s not all

This is just a summary of some of the things that we haven’t got around to publicising in the past, and they aren’t the main priorities that us designers are focusing on. In fact, we are already busy with the 3.20 cycle, working on Software, Nautilus, Polari, Settings, Web, Photos, Music and more, and there is plenty that needs doing in those areas. Nevertheless, if any of these designs do resonate with you, then you should definitely get in touch to help out.