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.
Extra Pain
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…
Wireframe by Allan Day, Visual improvements added by myself
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.
Personal Gripes
- 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.
Terrible way of dealing with combobox items near screen edges
- 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.
I commented on my blog [1] about the “Extra pane” (and a few other things concerning Nautilus), and why I don’t think that this is an engineers-only feature.
[1] http://berndth.blogspot.com/2010/02/nautilus-in-stress-field-between-design.html
This is an excellent article, and you make some very solid points about the UI of Gnome-Shell and Nautilus. On the Nautilus front, I noted that your wireframe mockup of the Nautilus redesign (which I enjoy) takes some inspiration from DanRabbit’s excellent Elementary-Nautilus UI design. I also took his redesign as an inspiration point for my Nautilus Redesign solution as well, which you can see here: http://www.design-by-izo.com/2010/02/27/deconstructing-nautilus-and-rebuilding-it-better/
I also proposed the integration of the Zeitgeist Chronological Event Logging engine into Nautilus.
Hopefully these ideas of mine may be of some interest to yourself.
I think Gnome3 should make bold moves. More natural animation. Once I select a file in Nautilus the buttons/menus should morph into what I can do with that file etc. (Not unlike Office2007, but much more advanced) Remove all the ridgit static old crust.
You only ever need Reload/Stop for network resources etc. I hope you get the idea.
Try to envision a desktop for 2015 and not one for 1995.
The screenshot is really promising! Looking forward to next steps…
Everything you write here is spot on. I’m especially happy to see people are starting to think about Nautilus. I was beginning to worry that Gnome 3.0 would come around and we would still be stuck with the same crappy file browser.
You raise no useful points regarding the extra pain, instead think of a window manager which doesn’t cascade by default file management windows but tiles them, and a window manager which allows you to move windows into a tiled form, this is a far more suitable use of a GUI where a split pane view is only useful on fixed, non-window-managed terminals which is why midnight commander and similar terminal apps are useful.
Essentially the feature was added because of a failure in window management, and was added in such a way as a ordinary user would never understand exactly what the “Extra Pane” option means. The text is meaningless and the feature is a throwback to the days of terminals.
@Karl: You clearly didn’t read the link I posted above. That’s fine, it’s a long article and all, and you seem to be happier joking about your “pain”s than to actually communicate.
And I am pretty aware of the motives behind split-view being written. I wrote most of it.
@hb, I did read the article I just thought it brought nothing of value, accusing someone of not reading your article is called making an assumption. I read it, I disagree, deal with it.
You’re obviously stuck in the defending your own code loop.
@Karl: Well, then you are aware that a simple tiling/snapping/paning WM cannot accomplish what split-view does. If you claim that, you should elaborate on how you manage to get the source/target connection.
Also, I am not defending code, because I have not yet read anything worth to defend against. I just read random ranting.
Anyways, I am dealing with it fine, happily using split-view right now.
@hb, there is no connection with a source/target here, there’s only one pathbar and only one set of controls, if you’re talking about the fact that they’re next to each other you’re really thinking in the wrong terms.
Try reading designing interactions, or about face, both are very good books on not making mistakes like this.
It’s a silly feature, and if you wanted to defend your code you should have made a point of coming to the hackfest.
@Karl:
> It’s a silly feature, and if you wanted to defend your
> code you should have made a point of coming to the
> hackfest.
Now, that’s a very funny comment. I’d have said, if you guys want to make a point about Nautilus interface, contact Nautilus folks over normal communication channels, instead of ranting on random blog posts. A Nautilus guy not reading pgo still wouldn’t even know about it. You call that designer-developer-communication?
Actually, these blog comments are equally improperly suited for a discussion, so I’m outa here. Have a nice day, and may your pains be eased.
Re the Nautilus button bar, I can’t say I like the idea of adding buttons across the bottom… too much clutter, with user’s attention now being dragged to all sides of the window.
This isn’t a new idea by any means; the Microsoft Windows file manager has been doing this since Windows XP (or was it Windows 98?), and it just puts contextual actions in the sidebar, which seems like a much better idea.
Nice points about gnome-shell, especially pretty evident stuff like that “whole screen changes to switch app”.
I always like rational thoughts about it being presented. I would appreciate more discussion about the shell concept and verification of it’s overall UI design decisions.
It appears the UX Hackfest wasn’t that focused on the shell. A bit surprising, considering it is the biggest “forced” UI change for GNOME.
[...] is, as has been previously mentioned due an overhaul. In order to allow Tracker+Fster to exist on GNOME nicely, and be used in Nautilus I propose we [...]