Last week GNOME decided to get a bunch of interface and interaction designers together into one place so we could revolutionise the desktop, or at least carve a path toward a ubiquitous GNOME desktop. Held at Canonical’s offices in Millbank tower the hackfest was a bustling affair with the attendees growing every day.
Initially there was an intention to create a structured approach to the process, unfortunately as is often the way in open source this ended up being an exercise in hearding cats. Sporadic groups broke off the work on specific issues more or less on an adhoc basis. I tended to join groups that interested me, so please forgive the fact that this writeup is a little single minded.
The first day was spent opening up the floor to issues that were of interest to individuals in the group, noting down what could be worked on and what should be worked on, specifically of interest to myself was the state of nautilus, the GNOME Human Interface Guidelines and a bunch of minor issues that popped up. I’ll cover each of the topics in some sort of order.
A great deal of discussion was held on nautilus, between many of the individuals involved, bringing a conclusive solution to the nautilus problem is a difficult one. Firstly, Garrett mentioned a very important point, the word “Manage” is terrible for the user, so maybe we should consider renaming the GenericName of nautilus to Document Organiser. Personally I like this idea, it removes an obvious barrier to the user, that barrier is the fear of the word “manage”, this also makes sense when considering in my /usr/share/applications/ folder I have an entry for File Manager, File Management and File Browser… *sigh* who knows why we tend to overuse the word manage but we should bear in mind the common user fear of words which sound like they lead to complicated or difficult things.
Breadcrumbs were also an important topic, firstly GTK+ has a terrible breadcrumb trail which doesn’t adequately explain where the user is. Sometimes I’ll view a folder, go back to the previous folder then delete the folder I was in. Currently this will leave a button in the forward direction which doesn’t exist. Clicking on this button will then generate an error. We looked upon the nautilus-elementary design for the Nautilus UI with favour, in this UI the breadcrumb bar has been moved into the titlebar, changed to match a canonical developed breadcrumb bar used in the ubuntu software store, some redundant buttons removed, or improved (combined stop/reload button) and the sidepane has been updated to have a greater space between the places.
All together nautilus-elementary is a very good design, although may suffer from some accessibility issues at present those issues will be easy to fix.
We all considered the new “extra pane” feature extra pain, the tabs in conjunction with the extra pane especially bad, the brainstorming session on Nautilus that included myself, Garrett LeSage, Jakub Steiner, Mairin Duffy, Hylke Bons and Allan Day was extremely productive. We came up with the idea of having a button bar at the bottom of the nautilus window, offering contextual options for modifying selected objects also all were agreed that increasing the spacing between places to increase the size of the drop target would be a good thing, and a general redesign and removal of useless features a positive thing. Specific features we considered to be useless are;
- Notes – We’re not sure if these are persistent or how and where they are stored
- Information – What information? The number of items in a folder, some basic stats about a file?
- Tree – Duplicated functionality in the main view, the sidepane is not wide enough for a decent tree browse
- History – Duplicated functionality from the back button
- Tabs – This will cause some flaming I’m sure, but really, we should be looking at better window management for nautilus rather than tacking on a fashionable feature to the UI. I’ve used tabs, and have found them usable, but I’d much rather have my windows organise in a better way without the need for tabs.
Even emblems has failed to become as useful as it could be, so this leaves us with the proposition of should we just remove the sidepane view selector and instead concentrate on improving the general appearance and usability of the places sidepane? I think we should, how much code would be removed from nautilus? Answers on a blog comment
So the emblems feature is useful however it isn’t positioned well and we didn’t come up with any specific solution to this. My personal opinion is that we should find some way of integrating this functionality into our bottom button bar concept at the same time integrating tracker metadata features and functionality in much the same way in the same place. In fact wouldn’t it be nice if there was a Nepomuk ontology for dealing with emblems…
GNOME Guidelines for being human
The GNOME HIG has fallen into a state of duplicated information, overly information dense and out of date. Matthew Paul Thomas of Canonical has the opportunity to update the HIG and do the actual work, but we all wanted to make sure our thoughts were included. We produced an adhoc document to voice our gripes in the most up to date version can be found here.
The main focus of the HIG as discussed should be to help developers make the right UI decisions early on, and to help developers adjust their application towards compliance, this is especially evident by the proposed smoke testing pages. The concept of introducing a pattern library was discussed in some ways also, and the eventual outcome of the new HIG will probably be based on this concept with a few common UI layout concepts which are described in detail dealing with alignments and layouts moved over into its own section and consolidating shortcut and accessible keys into a single topic, along with many other elements of the HIG discussed I think we formed at least a starting path toward our ideal HIG.
The GNOME Shell
There was lots and lots of discussion regarding the shell, and I don’t think I can give an overview here of the eventual outcome of these discussions. Seth created a great write up about the shell, and I’ll be following up soonish with a path to implementing some of his specific ideas using tracker and zeitgeist.
Things I’d like to mention regarding the shell;
- Supporting NVidia and binary drivers *must* be a priority for the development of Mutter, currently the performance is apparently unbearable. Ignoring binary driver support and a lack of cooperation with device manufacturers makes the GNOME desktop worse not better*.
- Changing the whole screen in order to launch an application makes me a bit queesy.
- Having a top panel rather than a bottom panel inhibits direct access to my Chrome tabs, and in the future may get in the way of other UI design experiments like this. Seth tried to emphasise this and suggest the use of a global menu, which I think should happen in place of the titlebar for maximised windows and therefore sit at the top of the screen. However I’m not convinced it’s an ideal solution for unmaximised windows as you then have to click at the window you want to access the menu, then click on the menu when it appears.
Grandma we love you, grandma we do?
Seth put great empasis on the fact we’re designing our desktop for our grandmas, and while my grandmother would love to use a computer this is unfortunately impossible as she’s been dead for some years, and the unfortunate fact is that if we keep designing for an aged population eventually we may get more users with the rate of medical breakthroughs prolonging our grandma’s lives but this isn’t really the market we should be trying to get into, more a market we meander into as a result of good use of paisly and chintz in the themes**.
It was mentioned by Seth that we should design our desktops for ourselves as we have the same goals as most of our users, but I disagree, I think designing for ourselves makes things far too short sighted and far too narrow. We as engineers have specific needs we may focus on (see Extra Pain), and by doing this we may introduce new confusing UI features for our userbase. In my opinion we should do a Nintendo, instead of designing for a certain age group as Nintendo did for so many years, targetting each platform at very young children, we should look at their approach for the Wii, as one Wii designer put it “Design for the ages 3 to 93″ creating the everyman desktop – where we don’t confuse users with dramatic language, clustered user interfaces with a billion options but at the same time we want to make it beautiful and usable by everyone.
- Our GTK+ popup menus should have a little arrow pointing to where the click occurred, with compositing enabled this should be the default of the design.
- Relying on contextual popup menus for major operations is also a bad thing, and part of the reasoning behind our bottom button bar idea for nautilus.
- Near screen edges, combo boxes leave a block of empty space in order to try and ensure that the previous item is selected when a user clicks and clicks again immediately after. However leaving a scrolling space which is empty is not an ideal solution, in fact it’s a horrific flaw in usability. Recently I’ve noticed that Pidgin fixes this issue by moving the combobox directly out of the way of both the button and the encroaching screen edge. This is a better way of dealing with this issue, and should be adopted into the toolkit.
- Our combobox and combo entry is inconsistent, if we’re going to use a specific design for combo box that design should be *identical* in the combo entry. There’s no specific need for them to be different as far as I can tell, and therefore these widgets should be brought into a single consistent design.
* The better/worse distinction here isn’t any overblown ideological distinction, it’s a matter of user experience the user wants fast graphics, so they can play games like Enemy Territory: Quake Wars without being turned off to our desktop by bad general support for binary drivers. The user doesn’t care about a free software philosophy they care about free software to help them get their work or play done.
** Yes, this is a joke.