[HIG] Justification for the button order change - the long version

[Seth Nickell <snickell stanford edu>]

> Actually, it won't be.  While my planning up to this point has been to
> use Gnome/GTK I will now be switching to KDE.  I don't really want to
> but a consistent UI and a developer team that doesn't change things by
> 180 degrees are more important than my preference for GTK.

Hey, wait a minute, won't you be using some GTK/GNOME apps, so your
desktop will still be inconsistent *wink*. Seriously though, very nice
rhetorical gesture. Tell you what, lets raise the stakes: if we change
to the "KDE/Windows" button ordering I'll quit GNOME and switch to KDE.
;-)

==The Basics==

Some reasons its good to have a standardized button
ordering/positioning:

1) Improve scanning speed
2) Reduce errors
3) Improve acquisition speed ("muscle memory")

-------------------------------------------------------------------------
Why its not a problem to be different in button ordering
-------------------------------------------------------------------------

The concern seems to be that if GNOME's button ordering is different
from "the rest of the world", muscle memory and expectations will cause
errors. That is, people will either be so used to GNOME2 that they use a
GNOME1/KDE/Windows/Java application or vice versa, and will make either
a serious error, or a number of non-serious errors, because they
sub-consciously click the affirmative on a dialog they wished to cancel.
This would be a very serious issue.

==Yes/No examples==

This is really important. If Yes/No dialogues were kosher for GNOME 2
applications, the usability issue would be more serious. Its a lot
easier to get otherwise identical dialogues with switched buttons messed
up than two semantically similar dialogues that *appear* quite
different. Which leads to the next point...

==Context and confusion==

Given adequate cues, humans make contextual changes very quickly and
naturally. People tend to have a lot more trouble adapting to
fundamental interaction differences than surface level changes, such as
button locations. (people also learn this sort of change very quickly,
but that is another matter). It is significant that GNOME 2 dialogues
appear (visually, even aside from different widget sets and window
border themes), and in terms of dialog text) substantially different
from, say, Windows dialogues. Humans are very good at making this sort
of contextual shift.

(Fundamental interaction differences are much more problematic. For
example, Maciej notes that he has had much more trouble with: in MacOS/X
clicking an application launcher when the application is already open
doesn't launch a new instance, vs. GNOME where it launches a new
instance, than with changes like the window button changes or the
dialogue button ordering, which he says he hasn't really noticed. This
was my experience as a new user of MacOS about 2.5 years ago too.)

==GNOME 1==

Since it appears most similar to GNOME 2 of all systems (and hence has
the least contextual change), the transition for existing GNOME 1 users
could be seen to be the most immediately troublesome problem. Here's the
thing though, there's no "change": GNOME 1 didn't have a dialogue
ordering. Dialogues were *way* too inconsistent for muscle memory to be
an issue. Worse, they often had reversed wording from eachother, meaning
that affirmative in one did exactly the opposite of affirmative in the
other. So you couldn't even predict in something as common as a "save"
dialog whether clicking the affirmative button would quit without
saving, or whether the affirmative would save and then quit.
http://developer.gnome.org/projects/gup/articles/why_care/ contains a
few shots of various "save" or "exit" related GNOME dialogues if you
need verification of this. 

Additionally, the wording of most dialogues has changed since we moved
to instant apply, and changed a lot of the stock dialogue's wording.
This increases the contextual difference between GNOME 1 and GNOME 2 a
lot.

==Other systems==

So my biggest concern is "external to GNOME" interactions, such as with
KDE or Windows users. I think context here is more than sufficient for
there not to be a problem though, since we use a different phrasing for
most things, avoid "Yes/No", and look rather different. But you be the
judge, I've included three shots of three standard types of dialogue in
GNOME 1, GNOME2, and KDE. I think, particularly between GNOME 2 and KDE
2, there is essentially no problem with confusion (esp. if the GNOME 2
open dialogue used "Open" instead of "OK", like it should).


==GNOME1 -> GNOME2 transition==

Is there going to be some transition confusion? Yes probably. For
example:

GNOME 1 open dialog:
http://beauty.stanford.edu/gnome1-file.png

GNOME 2 open dialog (actually, this is not right, "OK/Cancel" is almost
as bad as "Yes/No", but its what pretty much all apps are using since
that's what GTK provides right now by default, so this is a transition
area):
http://beauty.stanford.edu/gnome2-file.png

KDE 2 open dialog:
http://beauty.stanford.edu/kde2-file.png


But I don't think most dialogues will be an issue. Even in the above
case people pick up on context pretty darn fast. Most people will
probably make this mistake no more than a few times.

==Save Dialog==

"GNOME 1" save dialog, gedit1:
http://beauty.stanford.edu/gnome1.png

GNOME 2 save dialog, gedit2 (actually, its worth mentioning this
dialogue isn't quite right, but it's close enough in the respects we
care about)
http://beauty.stanford.edu/gnome2.png

KDE 2 save dialog, kword:
http://beauty.stanford.edu/kde2.png

==Settings Dialog==

GNOME 1 settings dialog:
http://beauty.stanford.edu/gnome1-mouse.png

GNOME 2 settings dialog:
http://beauty.stanford.edu/gnome2-mouse.png

KDE 2 settings dialog:
http://beauty.stanford.edu/kde2-mouse.png

--------------------------------------------------------------------
Why the GNOME 2 button ordering is more usable
--------------------------------------------------------------------

That's quite enough about why I believe its not problematic to be
different in this area. So why is the GNOME2 button ordering better?

==Reading direction==

This one is contentious, but its the main point MacOS HIG uses to
justify the dialogue ordering. From my anecdotal experience and
observations, I think this they are right on this issue, but I don't
have the time or resources to do testing on such an issue, and you don't
have to buy into this argument to believe in the button ordering as a
whole though, because there are other good reasons for the GNOME 2
button ordering.

The argument basically is that with left-right, top-bottom readers, your
eye is left resting on the lower right corner of a window when you are
done reading text. That makes the lower right corner the first thing you
read when you are done with a block of text. Thus it is the most quickly
acquired option, *AND* is conceptually first in your list of choices
even if you scan the other buttons. This effect is particularly
important when you start only glancing through the text to recognize the
type of dialogue it is (rather than actually reading), which is where
this shaves off irritation and inconvenience (that is, when you don't
have to read all the choices because of familiarity, its nice to have
the most common choice presented first).

==Heirarchical organization of space==

People tend to organize spatial information using some sort of
heirarchy. That is, you might spatially orient Las Vegas by knowing it
is in Nevada, by knowing Nevada is in the U.S., by knowing the U.S. is
in the American Continent. This has suprising effects on things like
scanning speeds. Things that are 30 pixels apart but in the same "parent
region" can seem closer than things that are 20 pixels apart but in a
different parent region. But I digress.

We assume that the window is the parent region for the buttons. Thus
your information about the button's position largely follows from the
position of the dialogue window. It turns out that some areas of the
parent region are "hotter" than others, that is it is easier to retain a
strong sense of their relationship to the parent. Things in the corners
have the strongest retainable relationship to the parent, followed by
something in the exact center, followed by things on the edges. For a
left-right, top-bottom reader, the hottest part of the window is the
upper left corner (where we put the titlebar, which needs to be scanned
very quickly when dealing with multiple windows), followed by the lower
right corner. (note this is not Fitt's law, it is much weaker than
Fitt's law which impacts actual "pointer" motion, not just scanning, but
its still a significant effect)

What does this mean? Even ignoring reading direction and all that
muddle, the corners of a window are the easiest places for your eye to
find (because your brain has already disected the space into windows,
and it understands the relationship of corners best), and the lower
right corner is a really great place to put something you want to be
very easy to pick out. Its really important to shave off as much time
and irritation from popups, because pop-up dialogues are a somewhat
invasive entity and we hence want to minimize their impact (this is
doubly true of alerts where the popup wasn't even requested).

==KDE/Windows button ordering guaruntees internal inconsistencies==

"Right" has been associated in most l-to-r reading cultures with "moving
forward". This is another minor reason why the affirmative button is
nice to have on the right. But this manifests itself in a more important
way. A number of dialogues are based on this physical move forward
construct. 

For example, assistants (aka "wizards"). Its much better to have the
"Next" button on the right hand side of the dialogue. So you create an
exception to the dialogue ordering (for the primary button no less!).
"Dialogues will have the affirmative button on the left of the buttons,
unless it is a wizard, in which case it will go on the right". Look
through the Windows styleguide areas about button ordering. They've had
to riddle it with exceptions to make everything work out right. 

This is bad, because you jepardize the chance that the user will
sub-consciously learn the "affirmative button is always in position X"
rule. Rules with lots of exceptions tend not to be learned very well,
and hence tend not to be as useful to users. Instead users will learn a
rule for each major kind of dialogue they use... "the save confirmation
rule", the "file dialogue rule", the "password alert rule", the "wizard
rule", etc.

With the GNOME 2 ordering they learn one rule: "the GNOME2 dialogue
rule". I grant you that they will have to learn it, since they're
already likely to be most familiar with Windows, but once they've
learned it they can rely upon it in GNOME applications (go back to the
section on context switching before you talk about heterogenous
environments).

==Conclusion==

If its important enough to follow windows in this area, I don't see much
reason we shouldn't follow it in most other areas, so we might as well
just adopt the Windows style-guide and decide to be a KDE/Windows clone
(its even more important for compatibility if we clone them at a
conceptual level, see Maciej's comment about MacOS/X, but I don't see
anyone proposing that).

Why can't we make these same arguments for title formats, or widget
alignment, or menu structure, or hell, all of LNF?

That is to say, I don't find this situation any more convincing than the
numerous other areas we differ from KDE/Windows(*). Why shouldn't we
just do exactly what Windows does in every respect? (if you think we
should follow windows exactly, I disagree with you, but that's the topic
of a message even longer than this one ;-) 

cheers,

-Seth (gnome usability project lead)

* This is not to say that I don't think there are areas where its worth
doing something just because Windows does it that way, I do, but I don't
think this is one of them.