Re: [Usability] Re: Button ordering

[Joel Becker <jlbec evilplan org>]

On Fri, Nov 02, 2001 at 07:21:51PM -0500, Alan Cox wrote:
> If apple did the work, presumably the research is out there, otherwise
> perhaps Apple just guessed too. Or perhaps they picked one because it didnt
> seem to matter much.
	
	Ok, we've been knocking this around by me, and I have to say,
I've come to a conclusion I "hate".  Here are our options:

(a) The current Windows/GTK+ Style

|                                                              |
|                                        [   OK   ] [ Cancel ] | 
`--------------------------------------------------------------'

(b) The Mac Style

|                                                              |
|                                        [ Cancel ] [   OK   ] | 
`--------------------------------------------------------------'

(c) The OS/2 style (reverse Mac)

|                                                              |
| [   OK   ] [ Cancel ]                                        | 
`--------------------------------------------------------------'

	Before we tackle the "is the change worth it?" question, let's
explore the UI principles we're looking at.
	One of the problems non-hacker users have is hitting things with
the mouse.  That's why UI design always specifies having mouse-able
things near the edge, if possible.  In the case of these buttons, the
default button, which the user is most likely to want, should be near
the edge.  This is the most damning argument against (a), the Windows
style.  The "OK" button is somewhere in the middle of the dialog.  This
doesn't lend to a user finding or using it.
	Add to that the fact that as buttons are added, the "OK" button
*moves*!  This is terrible even for "power" users, who often put their
mouse in the right place before the dialog is done drawing.  If the "OK"
button is in the same place, this works fine.  In style (a), the "OK"
button could be anywhere from the left edge to the second from the
right, depending on how many buttons there are.
	Both (b) and (c) have the default button on the edge, so they
satisfy that condition.  Instinctively, I prefer the left-justified (c).
I'm not sure why.  I think it has to do with my language-oriented
left-to-right bias.  I feel the most important item is on the left (the
"first" item), so I prefer my button on the left.
	The proponents of (b) point out that we read top-left to
bottom-right, so the eye naturally travels to the button in (b).  I
don't find myself doing that, but I'm a hacker, not a casual user.  But
*I* do find (b) very disconcerting.  As stated before, (b) and (c)
satisfy the edge rule, so which to pick?
	We argued this a bunch, and came up with an example that
convinced me.  The entire point is to make the default button the one
the eye hunts out and finds.  For "OK", my left-is-first bias is
possibly just as valid as the eye-travels-to-bottom-right theory.  I
can't say without actual user testing :-)  However, for a "next" button
that changes a page or such, *everyone* would think of next in the
bottom right, where you could turn the page.  Compare:

|                                                              |
| [   Next   ] [ Previous ]                                    | 
`--------------------------------------------------------------'

|                                                              |
|                                    [ Previous ] [   Next   ] | 
`--------------------------------------------------------------'

	I think you'd have to argue a pretty roundabout case to prove
that the top example is more intuitive.  The second, (b) style
environment is what I would prefer for these buttons.
	Given that consistency is the most important thing, if the
default "Next" button is in the bottom right, putting the default "OK"
button on the bottom left would be terrible.  Hence, I decided to side
with the (b) style environment.
	The bottom-right environment is one my mind is convinced I
"hate", but I will try to learn it, because I can't think of a better
arangement.

	The other issue brought up is that of change and inconsistency.
Alan is properly worried about switching things out from under folks.
So is it worth it?
	My first thought is that GTK+/GNOME 2.0 are an unparalleled
oppourtunity for change.  We're going to be stuck with their API and
guidelines for 2-5 years.  Of course, we can keep these longer if we do
it right.
	In our current methodology, we can have:

|                                                              |
|                             [   OK   ] [ Apply  ] [ Cancel ] | 
`--------------------------------------------------------------'

|                                                              |
|                                        [   OK   ] [ Cancel ] | 
`--------------------------------------------------------------'

	I'm sorry, but that isn't consistent even now.  With the
proposed change to style (b), the default button (here "OK") is *always
in the same place*.  This is a huge win for the folks that have mousing
issues.  If you think "folks can learn to mouse", you haven't met my
mother, my coworker kurt's father-in-law, or various other folks who
have been computing for years but still overshoot the button 10 times.
	Alan points out the QWERTY problem, but I disagree with him.
If every computer started shipping with DVORAK keyboards, folks would
learn to adjust.  People learned to accept Windows crashing, didn't
they?  If do our very best to ensure that future GTK+/GNOME dialogs
follow the "proper" semantic (whichever is chosen), people will get over
the transition period.

	In the end, the best situation for the user is consistency and
ease of use.  I feel that style (b) provides that best for users.
After a transition period (which we will have to have someday unless we
stick with our current, impossible to make consistent style (a)), folks
will just *expect* the default button on the right.  They will be much
happier for it.

	As an aside, you will note that I removed the "opposite side
Help button" from Owen's example.  My coworker pointed out that if you
need a massive help, you've already lost.  The point of a dialog is to
make things easy and quick to understand.  Instead of "Help", make the
dialog simpler.  If you have a bunch of options, either reduce that
number, or make more dialogs.
	I am always on the side of flexibility.  I'm a power user
through and through.  But if you are targeting the "Desktop User", who
merely wants to get his application started, you only make them confused
and upset with complex, busy dialogs.  Nautilus went a great way towards
this problem with their 'ski slope' user levels.

Joel

-- 

"Nearly all men can stand adversity, but if you really want to
 test a man's character, give him power."
	- Abraham Lincoln

			http://www.jlbec.org/
			jlbec evilplan org