Re: UI Guidelines: Dialogs

[Calum Benson <calum benson ireland sun com>]

colin z robertson wrote:

>           Informational dialog boxes are those which do not require the user
>           to enter any data or make choices; they are merely for notification
>           purposes. 

Actually, in most well-designed interactive applications, there are very
few cases where a dialog offering *no* choices should appear, as they
are generally just a nuisance.  (The About box is one of the few valid
examples I can think of, and it's valid because you've explicitly asked
for it to appear.)  

Information dialogs indicating the completion of a task are an
acceptable option if the task takes so long that you might reasonably be
expected to go and do something else until it completes, but otherwise
there are usually better, less-intrusive ways of showing this (progress
indicators etc.)

Even informational dialogs indicating some sort of fatal application
error should preferably at least have a Help button so you can find out
more about the error (assuming the system is still responsive enough to
open a Help window, of course!)

> These dialogs typically only need a label for the user to
> read and a button to close the dialog.

And the wording on that button should be chosen carefully-- there's
nothing worse than having a message box pop up that says "you've just
lost all your data", with a single button labelled "OK"... (or even
"Cancel", for that matter!)

>           Action buttons: Most dialogs will have buttons to perform some kind of
>           action. These should be labelled with a verb to describe the action
>           (they should not be labeled "OK") and positioned to the left of other
>           buttons on the bottom row.
>
>           "Cancel" button: Where possible, this button should be used on modal
>           dialogs to dismiss the dialog and return the application the the state
>           it was in before the dialog was shown. It should be the rightmost
>           button in the bottom row.

Need to be somewhat careful about specifying the positions (relative or
absolute) of buttons, as the rules will not necessarily hold true for
all locales.  The Mac HI guidelines have an Arabic example of this:

http://devworld.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-37.html

Also, the 'leftmost' (I'm doing it now!) action button should generally
be the default (operated by the Enter keyboard shortcut, unless there
are textfields in the dialog), and Cancel should always be operated by
the Esc keyboard shortcut.

>           "Close" button: Where possible, this button should be used on modeless
>           dialogs to dismiss the dialog without making any further changes to
>           the state of the application. It should be the rightmost button in the
>           bottom row.

There's always some debate about whether Esc should be the keyboard
shortcut for the "Close" button, too; my own preference is no, "Close"
should have a mnemonic instead (e.g. underline the "C").  I suspect
that's one we could argue about for a while, though...

>           "Previous" and "Next" buttons: If the dialog contains a sequence of
>           steps (as in a wizard, for example), they should be navigable with
>           buttons labelled "Previous" and "Next".

These too should have standard mnemonic shortcuts (probably P and N, for
the English version).

>          FIXME: Wizards require a section to themselves. Should there be a
>          principle that dialogs should not be dismissed by controls external to
>          the dialog?

Hmm, I'm not sure you can necessarily generalise that far.  It would
only apply to modeless dialogs anyway, but it's quite reasonable for
modeless palette-style dialogs to be turned on and off from a View or
Window menu, for example.  You could argue that palettes (and toolbars)
and modeless dialogs are not the same thing, but every time I have that
argument I find it increasingly hard to draw the line or even justify
the need for them to be treated differently anyway... but it's something
to think about, I guess.

Cheeri,
Calum.

-- 
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson ireland sun com    Desktop Engineering Group
http://www.sun.ie                      +353 1 819 9771