Principles behind the Button ordering

First of all, I'd encourage people to scan the guidelines. They're a
little crufty and we've realized some minor things about them we'd like
to change, or things that need to be specified or clearer, but the
principles are similar. The dialogue document talks about more than just
button ordering, it also addresses the use of generic button names such
as [OK] and [Cancel], basically they shouldn't be used unless there's
really no other option. For example in a save dialogue [Save] is
preferable to [OK] because it makes it very clear to the user what
ACTION they are performing. They aren't saying "yeah, do what's in the
text" they actually give the computer a verb to do. The text explains in
greater detail exactly what the situation is, and perhaps nuances what
the button will do, but the button itself contains the most important

> This is Mac style with the "action" button at the lower right
> hand corner, as opposed to what we've done in the past - Windows style
> with the default button at the left.
> So, 
>   [ Help ]                 [ Cancel ] [   OK   ]
> Not:
>   [ Help ]                 [   OK   ] [ Cancel ]

GNOME doesn't really follow this. See the bottom of this message for a
listing of the most common GNOME button orderings.

> While I'm willing to be told that this is the better ordering (the
> fact that Windows and Mac disagree probably mean that there is no
> "right" ordering), I have two reservations about the change:

Both Windows and Macintosh have made *wrong* choices, so that they
disagree doesn't necessarily mean there's no right way. In this case I
don't think its *bad* usability to do it the Windows way, I don't think
it will confuse anyone, or whatever. But the Macintosh is more
convenient and faster in the long run.

The usability project does not simply copy the Macintosh way for
everything ;-) Often it seems like after endless and painful discussions
we do end up going with something similar to the Mac way, but "Mac does
it this way, they probably had a reason" is just about the worst
argument you can bring to the usability list.

Here's some of the reasons I support the Mac style button orderings,
there are other reasons other people have but these are my reasons ;-):

1) For a left to right reader, your eyes are on the right of the
dialogue after you finish reading the text. This has a surprisingly
large effect.

2) The MacOS layout is more conducive to adding new alternatives. New
alternatives are added to the left of the Cancel button (see the
dialogue proposal for more details). The user knows where to find the
two most important alternatives and can progressively move to
discovering the others. Look at the Control center for why this can be
important (though I don't agree with the existence of the particular
alternatives in the CC, there are many legitimate cases to provide
alternatives to affirmative and negative). The OK button is sandwiched
between other buttons and sort of gets lost in noise.
>  * Familiarity is important; I'm feeling quite disoriented by
>    the change and other of our users will probably be disoriented
>    too, both existing GNOME users and users coming from Windows.

Yes. We were of course concerned about this... If GNOME consistently
followed the "Windows style" you show above, we probably would not have
proposed switching. However, GNOME users really don't have anything they
can expect from dialogues as it is. So while it may look weird to you,
other than the somewhat exceptional dialogue that actually *follows* the
windows-style (such as the evo find dialogue) it won't be any slower. In
fact, I bet if all GNOME programs switched today it would be faster for
you as a user everywhere within a very short timeframe because there
*WOULD* be something consistent to expect.

>  * With this change we'll have inconsistency in all apps until
>    they are fixed.

Ha ha, funny you should mention this. Actually, GNOME has almost no
consistency at the moment at all. The only consistent thing is that the
affirmative is *somewhere* to the left of the negative in the ordering.
This is why we decided it was important to do the dialogue guidelines in
the first place.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]