Form and Function

This happened.

It was a big job, and Florian deserves major congratulations for getting it ready (just!) in time.

Credit also needs to go to Jon McCann. If you’ve read my previous posts on the notifications redesign, you’ll know that we’ve gone through a number of different design concepts. In the end, it was Jon who was instrumental in helping us to identify the best approach. He has an amazing clarity of vision, which proved crucial in helping us to give the design a solid conceptual foundation.

The various concepts we have explored as a part of the notifications redesign makes me confident that the approach we have settled on is the right one. It was only with the final design that everything clicked into place, and we were left with a design which effectively avoided the problems found in each of the others.

In the rest of this post, I’ll outline the design’s key features.

“What’s happening?”

One of the key goals for the notifications redesign was to provide an effective way to review previous notifications. In this way, notifications can be used to find out about what has happened in the past, as well as what is happening right now.

With this ability, notifications can be used in an exploratory manner, to get an overview of recent events. This is particularly useful as a way to inform decisions about what to do next. As such, notifications can be a tool for directing our own personal activity.

This recognition informs the new calendar and notifications design. It indicates that notifications have an affinity with other activity-related information – at the moment we ask “what’s happening?”, we are also often implicitly asking, “what should I be doing?”

The new calendar design aims to answer that question in the most effective way possible. It provides a single place where you can find out what has happened, what is happening, and what is about to happen. In concrete terms, this means showing notifications, event and birthday reminders, world clocks and weather information. Notifications take centre stage, while the other information is available for you to fortuitously stumble upon.

All this information is contained in a single view, which means that it is immediately accessible and gives an effective overview.

It’s a time machine

Since they tell us about what has happened in the past, and help us decide what to do in the future, notifications are closely related to time. In accordance with this framing, the new design makes notifications accessible through the time and day indicator in the top bar [1]. All the other information found in the new date and time menu also relates to time – event reminders, birthdays, world times, and the calendar.

The world times section of the date and time menu works through integration with the GNOME Clocks application.

Taking action

Just like the current GNOME 3 notifications design, the new design incorporates pop up banners that include notification actions. These enable you to quickly respond to a notification in a convenient manner. Built in chat replies have been retained.

The position and appearance of banners has changed though – they now appear towards the top of the screen. This gives them a close relationship with the date and time menu. It also helps to ensure that pop up banners don’t get in the way, which was an issue when banners where at the bottom of the screen.

Keeping it simple

A major goal for the notifications redesign has been to simplify as much as possible. There’s quite a bit of complexity to notifications right now, including different notification types (such as resident and transient notifications), special cases (like music and hot plug notifications), notification properties (including images, action buttons), as well as stacking of notifications within different sources.

This complexity comes at a cost, increasing both the number of bugs and the maintenance burden. With the new design, we are clearing the decks and trying to stick to a single, simple API for virtually all notifications. This will lead to a much lower bug count, as well as easier maintenance.

Plans for the future

The main thing that has still to land for 3.16 is status icon support. We’re still finalising our plans for this, but it will definitely happen, and I’m sure that it will be better than what was in 3.14.

Looking forward to 3.18, there are a number of elements to the design that didn’t make it for 3.16, including music controls (probably based on MPRIS), Weather integration and birthday reminders. These additional elements will make the new design increasingly useful and cohesive, so there is a lot to look forward to. If you want to work on any of these features, just get in touch.

How you can help

The new notifications and calender design landed late in the development cycle, which makes testing vital. If you want to help, the best thing you can do is use GNOME Shell master, and report any bugs that you find.

This is also a good moment to pay attention to the actual notifications themselves. There’s a lot of poor notification usage out there right now [2], as well as obvious examples of things that should have notifications and don’t (completed downloads, anyone?).

If you are responsible for a module or application, take a moment to read over the notifications guidelines, and take a second to check if there are any untapped opportunities for effective notification usage in your software.

The new notifications design will be released next month, as a part of GNOME 3.16. If you want more details about the design or future plans, check out the design page.

[1] This also has some practical advantages, such as communicating that notifications are provided by the system, clearly delineating each section of the top bar, and providing an effective click-target.

[2] Things to look out for: notifications not being dismissed when they are replaced by a new one, application notifications that don’t use the application’s icon, default actions that don’t raise the sender application, notification actions that duplicate the default action (“View” or “Open” buttons are a warning sign of this), notifications being shown by applications while you are using them.

I recently put the finishing touches to the GNOME 3.14 release notes, which means that the next GNOME release is getting pretty close now. I never cease to be excited by new GNOME releases, nor to be amazed by our community’s ability to discernibly improve the GNOME 3 user experience release on release. I’m definitely at the point where I want to be running 3.14 all the time – it’s obviously a lot better than the previous version.

You’ll have to wait for the release notes to get all the details about what’s in the new release. Nevertheless, I thought I’d give a sneak peek at some of my personal favourite features.

Often with new releases we focus on the big new features – obvious bits of new UI that do cool stuff. One of the interesting things about this release, though, is that many of the most significant changes are also the most subtle. There’s a lot of polish in 3.14, and it makes a big different to the overall user experience.

New Animations

https://youtube.com/watch?v=ZOiLFx_LQBM

It’s quite a while since Jakub first posted his motion mockups for the applications view. Since then we’ve been steadily and progressively iterating towards those mockups. With 3.14 we’ve finally got there, and it was worth the wait. The most noticeable effect is the new “swarm” animation, but also a lot of other subtle touches, such as when you browse application folders, or when you launch applications. We’ve also reworked the animations for when windows are opened and closed.

Animations might seem like unimportant window dressing, but it’s surprising how significant they can be for the user experience. They are the glue which binds the different parts of the UX together. By smoothing the transition between views, windows and applications, they make the entire experience feel responsive, fluid and more pleasurable to use. (And they actually make everything feel a lot faster, too. But don’t tell anyone.)

Google Images in Photos

GNOME’s Photos app has been steadily maturing over the past couple of releases, and it is turning into the dependable core app that we want it to be. The big news for 3.14 is that Photos will now pick up your Google photos, so any images you’ve uploaded with Picasa, Android, or posted on Google+ will be immediately available there. This is obviously incredibly convenient for users of Google services, and I know I’m looking forward to being able to quickly browse my online photos from within GNOME 3.

Rewritten Adwaita

Jakub and Lapo have been tireless during the 3.14 cycle, and have completely rewritten Adwaita (the GNOME 3 GTK+ theme). This was a huge undertaking – around 8,000 lines of CSS have been reduced to about 3,300 lines of SASS. This was primarily intended to improve the maintainability of the theme. As such, there hasn’t been a dramatic change in the theme. What has happened, though, is that every aspect of the theme has been gone over with a fine-toothed comb.

There are some more noticeable changes. Progress bars have got thinner. Spinners look different (so much better). Switches are a bit different. However, the more exciting thing for me is that pretty much every part of the theme has changed in a subtle way. Everything feels crisper, sharper, and a bit lighter. There’s also a lot of subtle animations now (thanks to CSS animation support in GTK+), adding to the feeling of polish.

Search More Things

System search has been one of the most successful parts of GNOME 3, in my opinion. The number of applications that are feeding results to system search has continued to increase with 3.14, with two really useful new additions. The first is Clocks, which will return search results for world cities. Search is all you need to do to find the time in a place throughout the world.

The second new search provider in 3.14 comes from the Calculator. As you might expect, this allows you to perform simple calculations straight from the search box. It’s pretty exciting to see system search in GNOME 3 become so versatile, and the great thing about it is that it’s always a single keystroke away.

Go Go GTK+ Inspector

I don’t usually write about developer-focused features when I preview GNOME releases, but I can’t talk about 3.14 without mentioning GTK+ Inspector. If you work with GNOME technologies – as I do – this tool is something of a revelation. It’s amazing how quickly it becomes a core part of how you work. I’m already wondering how I ever lived without it.

The inspector isn’t just useful. It is also a lot of fun, and makes it easy to experiment. if you’re not a developer, or you don’t regularly work on GTK+ apps, I’d still recommend trying it out. Just hit Ctrl+Shift+I and have a play around.

Waiting Time

This is just a small selection of the features that are coming in the new release. To learn about everything else that’s coming, you’ll have to wait for the release notes. 3.14 should be out next week.

One of the pieces of feedback I often get about GNOME 3 concerns the use of space. People repeatedly say to me that GNOME 3 apps use too much space, particularly in terms of header bars and their buttons.

I find these comments about wasted spacing to be perplexing, because they seem contrary to one of the major themes of GNOME design over the past five years or so. It’s incisive to look at GNOME’s history in this area, and to count some pixels along the way.

Back during the tail-end of the GNOME 2.x days, those of us who were involved in GNOME design were strongly advocating for applications that had less chrome, and gave more space to content. We were particularly concerned about apps like Nautilus, and this kind of screenshot was the kind of thing we wanted to eradicate:

David Siegal wrote a great blog post about it at the time. The proportion of the window that was devoted to content rather than chrome was laugably small, as Andreas Nilsson artfully demonstrated:

Starting with this as a baseline, we can measure how space usage has changed in GNOME in the past four or five years. Back then, a Nautilus window used 171 vertical pixels for chrome (24 pixels each for the title bar, menu bar, and status bar, 55 for the tool bar, and 44 for the path bar).

By the time 3.0 came around, we had managed to reduce the amount of wasted space considerably. The stacked toolbar and path bar were gone, and the permanent status bar was replaced by a floating element. I count 63 pixels for the title bar and menu bar, and 53 pixels for the toolbar – that’s a space saving of 55 pixels.

Three releases later, and more space saving improvements had landed. The menu bar was gone, which had been replaced by a single toolbar. Chrome stood at a height of 70 pixels – a saving of 46 pixels since 3.0, and a whopping 101 pixels since GNOME 2.

Finally, to bring the story up to date, in GNOME 3.12 we introduced header bars, which again resulted in a space saving. Nautilus today has 48 pixels of vertical chrome, less than a third of what it had in 2.22.

This history makes quite a nifty table…

Nautilus Version	Vertical Chrome
2.22	171
3.0	116
3.6	70
3.12	48

You get a similar result for other GNOME applications. At the end of GNOME 2, gedit had 127 vertical pixels of chrome. Nowadays it is down to 72 pixels.

What’s more, today’s Nautilus compares favourably with file managers from other operating systems/desktop environments. KDE’s Dolphin uses 109 vertical pixels of chrome compared with Nautilus’s 48. Finder in the upcoming OS X version seems to have around 75 pixels.

So I am puzzled. In GNOME we have greatly reduced our use of chrome, to the point where we seem to use less than obvious alternatives. And yet, we still get repeated comments that we use too much chrome.

You could argue that there is still extraneous chrome that can be shaved off, of course. I’ve looked into the possibility myself, and what I found is that the potential savings really are negligible – in the region of four or six pixels or so. Compared with the dramatic savings we’ve seen in the past years, this is trivial stuff.

Besides, I don’t think that shaving four or six pixels is really the answer to why we get comments about space usage. It’s hard to know exactly what is going on, but I suspect that it is more down to the visual presentation of header bars [1], and something about how some people expect buttons to look. For some reason, buttons like this seem to hit a nerve:

It might well be something to do with shape, rather than size.

GNOME is actually using space better than it ever has done before, and is more efficient in this respect than at least some major rivals. This isn’t to say that there aren’t real issues behind the feedback we’ve got about space usage – obviously something is going on. It’s more of a subtle issue than many give credit for, though, and it’s certainly not because we are worse at using space than in the past.

[1] Perhaps in combination with their position. On a small laptop screen that is below eye level, something at the top is more noticeable, closer, and appears bigger.

I’ve recently been hard at work on a new and updated version of the GNOME Human Interface Guidelines, and am pleased to announce that this will be ready for the upcoming 3.14 release.

Over recent years, application design has evolved a huge amount. The web and native applications have become increasingly similar, and new design patterns have become the norm. During that period, those of us in the GNOME Design Team have worked with developers to expand the range of GTK+’s capabilities, and the result is a much more modern toolkit.

It has been a long road, in which we have done a lot of testing and prototyping before incorporating new features into GTK+. As a result of that work, GTK+ provides a contemporary lexicon to draw on when designing and implementing applications, including header bars, popovers, switches, view switchers, linked and specially styled buttons, and much more.

There is a downside to all the experimentation that has been happening in software design in recent years, of course – it can often be a bewildering space to navigate. This is where the HIG comes in. Its goal is to help developers and designers take advantage of the new abilities at their disposal, without losing their way in the process. This is reflected in the structure of the new HIG: the guidelines don’t enforce a single template on which applications have to be based, but presents a series of patterns and elements which can be drawn upon. Each of these is accompanied by advice on when each pattern is appropriate, as well as alternatives that can be considered.

The HIG is also designed so that it can grow and evolve over time. The initial version that I have been working on covers the essentials, and there is a lot more ground to be covered. We want to assist people in finding the design that best fits their needs, and we want to make a whole range of creative solutions available.

In writing the HIG, I’ve made an effort to produce a document that is as useful to as many people as possible. While there is an emphasis on integration with GNOME 3, there should be useful material for anyone using GTK+ to create applications. It includes guidelines on creating more traditional desktop applications as well as newfangled ones, and includes advice for those who are responsible for GNOME 2 style apps. Likewise, the new HIG includes guidance on how to design effective cross-platform applications.

The new HIG wouldn’t have been possible without the help and hard work of many individuals. It incorporates updated material from the previous version, which was written by Seth Nickell, Calum Benson, Bryan Clark, Adam Elman, and Colin Robertson, many of whom recently helped us to relicense the original HIG.

Credit also has to go to those people who designed and developed all the new capabilities that are documented in the new HIG, including Jon McCann and Jakub Steiner on the design side, as well as the developer/designers who helped to test new patterns and add new capabilities to GTK+ – Cosimo Cecchi, Matthias Clasen, Carlos Garnacho, Alexander Larsson, Benjamin Otte, and many others.

I’d also like to thank the GNOME Documentation Team for their advice and assistance with proofreading.

This being the initial release, I’d love to hear feedback, and I’m sure that there’s plenty to be improved. If you’re interested, you can clone gnome-devel-docs and read the development version using Yelp.