Re: [Usability] Re: Button ordering

[Seth Nickell <snickell stanford edu>]

> 	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.

Actually, this doesn't really connect to non-hacker vs. hacker users.
Mouse coordination really levels off at some point in user experience. I
doubt "hackers" are any more coordinated than, say, a graphic artist, an
architect, or a secretary. These users quite likely use the mouse as
much as any hacker.

But other than the *real* edge of the screen ("infinitely" large), the
reason you put things near borders isn't a physical coordination issue.
The reason you put things near the corners of window borders is it
allows the eyes to lock on faster. If the location is consistent you can
start moving the mouse as you lock on, you can move your mouse there a
lot faster. Also, this decreases hesitation because you are sure that
the affirmative is in the lower right. I wouldn't suspect this ability
increases in users who understand the workings of their computer better.

(side note: another useful thing for decreasing hesitation is to make
the affirmative more descriptive than "OK", so the user doesn't have to
think carefully about the negatives, e.g. as soon as the concept is
communicated they know which button to click on rather than having to
consider nots and such)

> 	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.

Of course it would be *better* if applications didn't need "help", but
the truth is that some questions can't be easily answered without more
information or background. The help button provides this. For example,
dialogue text should be kept quite short so it is easy to understand and
quick to recognize. But sometimes the user *really does* need more
information about an operation, and is willing to look for it. We can't
always know when a user is working with something that is really
important to them and wishes to excercise more caution. Its a compromise
between making things quick to read and answer usually, and providing a
safety net when the user is hesitant or unsure.

-Seth