Re: Comments on dialog proposal

[Calum Benson <calum benson sun com>]

Maciej Stachowiak wrote:

> * 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?

And another argument against it (which I'll state again for the record,
although I'm sure you've all heard me say it before): any non-GNOME apps
(such as KDE, Motif, Java or OpenOffice apps) that you run on your
desktop will almost certainly use the Windows/pre-GNOME-2.0 button
ordering.  So it will be impossible to avoid inconsistencies on your
desktop unless you run a "pure" GNOME desktop.

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

Well, I wouldn't expect it to appear in every dialog (it never did in
Windows 3.1 when it was in their guidelines), so I don't know how
"pervasive" it would really be.  

It could certainly be made less obtrusive if it didn't have a text
label, though, and was just a small graphical button with a question
mark icon (for example)-- this shouldn't cause any accessibility
problems, as Help already has as standard shortcut (F1), just as OK and
Cancel are operated by Return and Escape.

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

Personally, I'd be happier if we could recommend that instant and
non-instant items were never mixed in the same dialog.  If there are any
non-instant items, then everything in the dialog should be made
non-instant, and applied with Apply, OK, or whatever mechanism we decide
we like best.

The disadvantage of this is that you might end up having to explicitly
Apply the same setting in one app that took effect immediately in
another, because that setting happened to share a dialog with some other
non-instant settings in the first app.  I still think that might be less
confusing than the mixed approach, though, and I suspect that with
careful design it would be possible to avoid mixed dialogs in most cases
anyway.

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

Well, possibly... the jury's still out on that one over on the
accessibility list  :)

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

Something else that Windows 3.1 used to recommend, and then got dropped
for Win95... talk about turning full circle  :)

It might work okay if we weren't recommending a left-justified Help
button as well, but assuming we still are, we'd end up with two
different widths of spacing for dialog buttons, which could end up
looking a bit amateurish, i.e.:

[?]  <--Big space-->  [Button1]<-weespace->[Button2][Button3]

But I could be wrong, ASCII art doesn't really do it justice...

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

I think we're planning a separate section in the HIG for message boxes
and writing error messages-- if not in the mini-HIG we're doing first,
then certainly in the full-scale version.

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

Yep, I think that's in the plan too.

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

Any opinions are personal and not necessarily those of Sun Microsystems