GNOME design: saving space since 2009 (or so)

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:

Nautilus 2.22

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.

Nautilus 3.0

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.

Nautilus 3.6

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.

Nautilus 3.10

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:

square-button

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.

New Human Interface Guidelines for GNOME and GTK+

hig-graphic-940

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.

GUADEC Highlights

I learnt that Lapo is a real-life human being, and not a robot.

Meeting awesome new contributors.

Hanging out with old friends.

Matthias’s slides – who needs presentation software, when you can write a GTK+ app to do the job?

All the keynotes, especially Matthew Garrett’s.

Getting to meet Timm Bäder, who’s behind the awesome Corebird. I even got around to sending him some patches.

GNOME’s new privacy team.

Jan’s talk on design in ownCloud was great, as usual.

The lightning talks were a lot of fun this year.

Jim Hall.

Working on the design of Clocks with Lasse.

The picnic.

Font hilarity.

Christian’s plans for Builder.

Lots of enthusiasm around application sandboxing.

Great stuff from Benjamin on GTK+ CSS. There was a small group of us designers applauding from the back.

Le Snooker.

Working on the new Weather design with Giovanni.

Arnel gave me lovely dried mangos.

Finally, someone blew the whistle on The Swedish Conspiracy.