Re: Comments on dialog proposal

[Julian Missig <julian jabber org>]

I'll leave it up to others to answer the rest... but with instant-apply 
dialogs, "Cancel" cancels any actions you did in the dialog since you 
opened it, thus acting similarly to how "Revert" acts now - except it 
also closes the dialog. This way the user can try settings, see their 
effect immdediately, and just Cancel if they don't like them.

And for the record, I like the Mac OS X button ordering and spacing. ;)

Julian

Maciej Stachowiak wrote:

> 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
>
>
> _______________________________________________
> Usability mailing list
> Usability gnome org
> http://mail.gnome.org/mailman/listinfo/usability


--
email: julian jabber org
jabber:julian jabber org