Re: UI Guidelines: Dialogs

[colin z robertson <c z robertson ndirect co uk>]

On Mon, Feb 12, 2001 at 07:32:00PM +0000, Calum Benson wrote:
> 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!)

Yes, I think I agree with all of this. I'll try to incorporate it.


> > 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!)

Yes. I'm really not sure what that should be. "OK" is inappropriate
for something that's not really ok. "Cancel" is misleading. "Close"
implies modeless, which may or may not be the case... hmm... Actually,
is there any reason why such a dialog couldn't be modeless? And given
that it could be modeless, should it be modeless?

Another alternative would be "Dismiss"...

Then this all has to be localised...


> 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

What facilities does gtk offer for this sort of thing? If it provides
adequate facilities then it's a matter of getting developers to use
those facilities. Otherwise I guess we'll have to try to pick
something internationaly acceptable.

As an aside, I'd be quite happy if the buttons were the other way
round from what I've just suggested. My approach at the moment is to
describe common behaviour so as not to make every Gnome developer into
an enemy. My preference would be to have action buttons on the right,
to maintain consistency with previous and next positions.


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

I'm sure we could. Personally, I disagree with you here. I think
there's enough correspondence between "Cancel" and "Close" for them to
have the same shortcut. I think that's what would users would expect.


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

I think you're right. See my previous post to the list.

colin

  _____________________________                            ____
  rtnl  http://rational.cjb.net     c z robertson ndirect co uk
  ak    http://kitching.cjb.net                    icq 13294163