[HIG] REVIEW - 3: Dialogs

[Calum Benson <calum benson sun com>]

3.1 General Principles

3.1.1 Types of Dialog Boxes

3.1.1.1 Modal and Modeless

How do/could/should modal and modeless dialogs differ in appearance, so
the user can tell which they are dealing with?

3.1.1.2 Informational Dialog Boxes

Perhaps this should be in a section about Message Dialogs generally
(including how to write good messages, probably in the Feedback chapter
that I reckoned was missing)?  Informational dialogs are probably the
least important of the Message Box types, and there's nothing at all
about the others here.

3.1.1.3 Druids

Need more detail on these, covering layout, what tasks are appropriate
to be druid-ised, guidelines on number of steps and wording (which is
typically more conversational than a 'normal' dialog) etc.  E.g:

- Always say on the first page what the druid is going to do.
- Indicate how many steps are involved in the druid, and how far through
the process you are (if possible).
- Minimize the number of druid pages that require the display of a
secondary window.
- Don't design the druid so that user has to leave the druid to complete
the task.
- Include default values or settings for all controls that, wherever
possible, would lead to a sensible default result even if the user
clicked right through the druid without changing anything.
- Make the "Finish" button available on any pages where the druid has
enough information to complete the task without further input.

3.1.2 Dialog box layout

(Thinking out loud) Help button... should this be icon+text, or
graphical only?  Latter would be less intrusive, and there's already a
"context sensitive help" keyboard shortcut (currently proposed as
Shift+F1) so it wouldn't be an accessibility problem.  Unless we're
offering context sensitive help down to the level of individual controls
rather than just the whole dialog...

Should there be a separator between the top part of the dialog and the
strip of main buttons at the bottom?  I assume this is handled by the
toolkit anyway, but are we happy with what the toolkit does?  :)

3.1.3 Dialog box behaviour

"If changes are made to the state of the application while the dialog is
on the screen then these changes should be immediately visible in the
dialog".  What if you're typing into a field as the system tries to
change it?  Should the whole dialog be locked while you're typing, or
just the field you're typing into, or should it just change under your
nose?  (I remember having this problem many years ago when implementing
a dialog in a 3D animation package that let you change the XYZ co-ords
of an object while it was moving... we went for the middle of those
three options, in that case).

Another guideline to consider: in general, a dialog should open in the
same state and position as the user last accessed it.  E.g. a dialog
containing a notebook should open with the same notebook tab frontmost
as they were last viewing when they closed the dialog.

3.1.4 Dialog box buttons

Overall, have to say I found this section very hard to follow-- if I was
a developer I doubt if I'd know what buttons to use for my dialog and
where to put them without having to read it a few times.

I think the main confusion was caused by too many abstract terms
(action, navigation, closing buttons) with no concrete examples, and too
many different cases for different types of dialog.  Perhaps it would be
better to put (or summarise) some of this information in a table?

We perhaps also need a table listing some standard buttons, their
preferred mnemonic, and their meaning in a dialog, e.g. OK, Cancel,
Close, Apply, Stop, Help, Add>>, <<Remove, Back, Next (or Previous,
Next, or Back, Forward, as we see fit...)

3.1.4.1  Action buttons

"The leftmost action button should be the default button".  Is this
correct?  I thought the point of laying things out this way was that the
rightmost button was usually the default.

Perhaps also worth mentioning that I think we agreed (primarily for
accessibility reasons) that it's best to keep the same default button
for the dialog's on-screen lifetime-- I assume there's nothing in the
toolkit to enforce this, so it's worth making it a guideline if this is
the behaviour we want to encourage.

"Labels such as OK... are discouraged".  I don't disagree, but
nonetheless I expect many (most?) dialogs will probably end up with an
OK button for lack of a more suitable alternative, so maybe we need to
be slightly less dismissive of it here.  The mention of "Yes" and "No"
here threw me a bit too, as I'd expect "No" at least to be a closing
button rather than an action button, and I wouldn't expect to see them
in the sort of dialog box we're talking about here anyway.  (But yes, I
know message/warning/alert boxes are dialog boxes too.)

3.1.4.2  Closing buttons

"OK will often be more appropriate for unrequested alerts".  I think
it's worth saying that OK definitely isn't appropriate for unrequested
alerts that tell you something untoward has just happened and there's
little or nothing you can do about it, however.  (Maybe this belongs in
the feedback/message boxes section again?)

3.1.4.3  Navigation buttons

What sort of dialog would have navigation buttons other than a druid?  I
can't think of one, but if there are any we should provide concrete
examples here.

3.1.5  Dialog Window Titles

The advice given here is slightly different from the traditional "dialog
title should just match the name of the menu item that opened it".  Can
we decide on a standard format for dialog titles, rather than the
proposed "something like..."?

3.2 Standard Dialogs

I know we don't yet have standard dialogs for things like Print, Page
Setup, Find/Replace Text, but it would be nice to mock up some models
for people to follow when they're implementing their own, even if we
just rip off the Mac/Windoze ones for now.

Are we considering a tabbed Properties dialog to be a standard dialog? 
Even if we're not, perhaps want to say somewhere how to handle
properties dialogs when multiple objects are selected, or when a
user-created group of objects is selected (e.g. where you've chosen to
group a number of objects in a drawing app).