On the button order of Gnome 2

Created 18. March 2004.

Disclaimer

This is a purely subjective column. The author is not, and has never been a member of any UI design group or notable Free software development group. I personally hate the Gnome button order violently, so consider this document extremely biased.

Background

In the early 1980s Apple created the Macintosh line of computers. They had a revolutionary graphical user interface, consisting of windows, buttons and so on. In the late 1980s Microsoft created an equivalent GUI for the PC called Windows, which went on to sell hundreds of millions of copies. There were some differences between these two UIs. Among them was the fact that the locations of the Ok and Cancel buttons was exchanged. This caused problems to people who had to use both systems. Luckily Macs were not very common so very few people had to deal with this.

Fast forward to 1997 or so, and we find a group of Linux/Unix users getting annoyed over the fact that every GUI program they had worked totally different. These people formed groups, who attempted to bring order to chaos by defining a common framework for programs running on the X windowing system. The two most known efforts are Gnome and KDE.

The problems described in this document arised when the Gnome team released version 2.0. One of the features that annoyed people was the change to the Mac style order of cancel/ok. Here is an example taken from Gnome's human interface guidelines.

Here's how KDE's UI guide recommends to do the same thing.

Notice how the command button lies in a different place. The headaches arise from the fact that a lot of X users mix programs from Gnome and KDE. An example is the great GTK-based Gimp, which is used by lots of KDE people. This mixing leads to the extremely frustrating dilemma that you cannot predict how a given dialog window will work, because it varies from program to program. This violates grossly the ten usability heuristics of Nielsen.

Which one is the correct order, then?

To my knowledge there is not a single religion in the world whose sacred texts contain a chapter in UI design. Therefore there can not be One True Answer, only different opinions. The main reasons for supporting either one can be neatly summarized as follows.

Gnome button orderApple uses it
KDE button orderThe de-facto standard in computing world (i.e. Windows uses it)

These reasons can even be nicely combined to "what [the person] is used to". All other reasons are pretty much just expalanations thrown in to support one's pre-chosen opinion. Let's examine some of these.

Gnome point of view

If you tell a Gnome developer that they are just copying Apple, you'll most likely receive a nasty flame-letter questioning your intelligence. The sad part about this is that their reasoning is totally wrong. The only reason Gnome people could even suggest their current button order is because Apple already did it. If Apple used the same button order as Windows, requests on changing the button order would carry as much weight as moving window titles to the bottom of the window, or having the buttons above the text.

The scientific rationale used by people supporting the Apple/Gnome button order is the following: "People's eyes tend towards the upper-left and lower-right corners. Therefore the action button should be located there." This seems like a reasonable thought process. However, it requires a leap of faith. Even if we assume that the first sentence is true (which it most likely is), the conclusion does not follow directly.

The only large scale research I know of that supports the above argument is made by, you guessed it, Apple. This research was done in-house by Apple personnel (some of it in the early 80s) and has never been publicly reviewed. This means that the methodology and motives of the research are largely unknown. For all we know some manager could have chosen the button order during lunch and then cherry-picked the data to reach the desired conclusion. This kind of thing is not at all uncommon in corporate america (or anywhere, really).

Note that I am not accusing anyone of falsifying data. I'm just pointing out that the above mentioned conclusion has not been proven scientifically, it is just an assumption (or opinion). Verifying or falsifying it would require a massive transparent usability test. This probably won't be happening any time soon due to money constraints.

Why the Gnome button order is erroneous

Surprisingly one of the best reasons why the Gnome button order is not very good can be found on the first page of Gnome Human Interface Guidelines, which lists some benefits of following the HIG:

The unfortunate fact is that over 95% of existing programs do not behave the way Gnome HIG recommends, so most users are not used to the Gnome button order. This inconsistency sticks out like a sore thumb. I'm quite willing to admit that this is the eat sh*t, 100 million flies can't be wrong defense. But there are cases when the popular opinion is, in fact, the right one. Whether this is one of those cases remains to be seen.

A slightly more serious reason not to use the Gnome button order is the fact that it violates one of the Nielsen's usability heuristics mentioned above. The second heuristic says: "Follow real-world conventions, making information appear in a natural and logical order." To see how this is violated, see the following table.

left/rightright/left
up/downdown/up
yes/nono/yes
ok/cancelcancel/ok

For every row, choose which ordering of the words seems more natural to you. My (very unscientific) estimate is that most people choose the left column every time (or at least most of the time). The yes/no ordering is especially strong. Just listen to people around you. The speech pattern is always the same: "Did you do X? Yes or no?". Yes always becomes before no, so correspondingly in dialogs yes should be to the left of no. If you follow this reasoning, having cancel to the left of ok is inconsistent.

Here is a simple example. Check them yourself and decide which one seems more natural to you.

Conclusions

The most depressing part about writing this document is knowing that it does not make a bit of difference. This whole debacle is a lot like discussions on art, politics or creationism. People have made up their minds and refuse to budge an inch, no matter what evidence is brought before them. (Yes, that includes me.)

I don't expect the Gnome people to change their button order. Most likely this text gets labeled as an uninformed rant of a windows loser. That doesn't bother me at all. What does bother is that all people who use a mixture Gnome/non-Gnome programs suffer. You might try uninstalling Gnome to attain consistency on your desktop. Unfortunately that is not the answer either. In addition to not being able to use a lot of nice programs, the button ordering has started leaking to non-Gnome programs.

Random comments

This part lists various related musings which did not fit in the main text.

The Gnome HIG says you should not have ok/cancel dialogs, but rather ok should be replaced by the command verb. This is actually a good thing, but does not affect the main discussion.

Gnome uses, among other things, the GTK+ toolkit. Its dialogs conform to the HIG, and you can't change the button order without modifying the source. GTK+ is a multiplatform toolkit, and therefore GTK programs look totally out of whack on Windows.

Some extremist people have even labeled the button ordering choice as arrogance on Gnome people's part. The reasoning is that the Gnome way would be feasible if X equaled Gnome, that is, all graphical Unix applications were made with Gnome libraries. Obviously that is not the case, and will most likely never be. This is a big enough reason that Gnome should have adopted a button order that conforms with other X apps. They specifically chose not to do it, and the result is mass annoyment.

Apple's research justifying their button order was done in the early 80s, probably on total computer neophytes. Doing the tests now using test subjects that have at least basic computer skills would most likely yield very different results.


(C) 2004 by Mr Shrap. All rights reserverd.

Back to front page.

Hosted by www.Geocities.ws

1