Comments on dialog proposal

[Maciej Stachowiak <mjs noisehavoc org>]

Hey guys,

I just read over the dialog proposal on the web, and a couple of
comments came to mind. Here they are for your viewing pleasure. I'm
willing to provide a bit more explanation/justification for any of
these points that are unclear, but I don't really want to get into a
huge debate on any of them.



* Button order: nice logic, but may confuse windows users and users of
older versions of gnome - habits + reversing order of OK and Cancel
can lead to some bad oopses. Is it worth the change?

* Pervasive "Help" buttons lead to button clutter. Maybe we can figure
out a way to have a help button on the title bar, or on the panel
somewhere, and an appropriate protocol to use it. Once you get to four
buttons the dialog becomes significantly harder to grasp at one go.

* If preference dialogs instant-apply settings, they should have only a
Close button, not OK or Cancel. 

* Also, the button for settings that are slow to apply should perhaps
be "Apply" rather than "Try" (the latter makes it sound too
temporary).

* An Apply button is also justifiable in cases where changing the
setting should for some reason be a bit harder to change carelessly.
This may be the case if the setting in question has some or all of the
following properties:
   o this setting has or may have "wrong" values which can harm
   operation of the uer's computer
   o the setting may be hard to restore from memory if changed to
   something the user doesn't like
   o the setting goes through invalid intermediate states while editing
   it

An example where all three of these are the case would be the system's
IP address. An example where only the first applies but it may still
be worthwhile having an Apply button is changing the default system
boot volume (assuming it is done by graphically picking from a list -
if you did it by typing in the raw device name, all three would apply,
although that is pretty clearly bad UI).

* Finally, if you do have settings that require non-instant apply,
consider isolating them on one page of the dialog and having one apply
button for that whole page.

* Keybindings - don't forget "Enter" activating the default action.

* On Mac OS X there is generally extra spacing between the alternative
action button and the negative response button. I think this is an
improvement because it lets the user focus more on the two main
buttons, which are expected to be the common action.

* The dialog button ordering is subtly different on the Mac than
described in the document. (At least in Aqua). The ordering is like
this:

[Alternative Action] [Negative or Cancel] [Affirmative or Primary Action] 

So the old familiar quit with unsaved changes dialog looks like this:

----------------------------------------------------
File such and such has unsaved changes. Save before
exiting?

<smaller font>If you don't save, changes to file such and
such will be lost.</smaller font>

[Don't Save]     [Cancel] [Save]
----------------------------------------------------

The [Save] button saves the file and quits. [Cancel] cancels the
operation that brought up the dialog - namely, the user's attempt to
quit. [Don't Save] is the alternative action, and it quits without
saving. 

The nice thing about this ordering is that it puts the two safe
options near each other and in the position of most focus, and keeps
the one dangerous option separated and in the position of less
prominence.

The "Don't Quit" "Don't Save" "Quit and Save" ordering, by contrast,
puts the dangerous option between the two safe ones.

The naming of the buttons is debatable. "Don't Quit" "Don't Save"
"Quit and Save" is more precise, but I think it may actually be less
clear because the button names are all kind of similar. They are all
fairly distinctive in the OS X style.

* We definitely shouldn't have an example of the "Don't Save" / "Don't
Quit" / "Save and Quit" dialog with a help button. This is a stock
dialog so the help button will rarely be useful, but it will always
make the dialog harder to read.

* I think we should suggest have special advice for message boxes.

* In particular, let's discourage message boxes with only one button,
especially only an affirmative button. If it's worth warning the user
about it's worth letting him or her cancel it. 

* Let's have a special section on druids and other multi-step
sequential dialogs, and how to lay out the buttons for those