Re: [Usability] Re: RFE - API change from GtkMessageDialog to GtkAlert

[Matthew Thomas <mpt mailandnews com>]

Maciej Stachowiak wrote:
> 
> On 27Nov2001 12:21AM (-0600), Gregory Merchan wrote:
> >
> > The response from the user is "OK, I'm done reading."
> >
> > From mpt's Improving GNOME 2.0 for humans
> > (http://geocities.com/mpt_nz/ig2h.html)
> > |
> > | Always label the button OK. Giving it a different label (such as
> > | Continue) would only slow down a user by misleading him into
> > | thinking that the button itself was useful to read.
> 
> I don't buy it. "OK" in the UI normally indicates acceptance.

As it does in this case.

>                                                               Seeing
> it with no other buttons makes me think "What am I accepting here,

The message in the alert, of course.

>                                                                    and
> why is it asking me, if I don't have the choice not to accept?"

It's not asking you. It's telling you. That's why there's no question
mark anywhere. And that's why the button just says `OK', instead of
falsely implying that your response will be a meaningful action (as it
would if it said `Close' or `Continue' or whatever).

> > Also, for an error message, "Close" might be misinterpreted as
> > "Close this document or application".
> 
> I really doubt it. It's pretty clear from common practice that it
> means "close the window this button is on", not "close some other
> window".

It does indeed mean `close some other window' in alerts in the QuickTime
Player. (I know QuickTime's UI has sucked for quite a while, but still,
it's a fairly popular multi-platform counter-example to your `common
practice' claim.)

>...
> > > "Cancel" is often ambiguous; we should not enforce it.
> >
> > Cancel is not ambiguous. It always cancels the action which caused
> > the alert.
> 
> Since, as you pointed out in your earlier message, alerts are never
> requested by the user but rather interrupt his workflow, it may not be
> clear what user action caused the alert, and so it may not be clear
> what the user is cancelling. I sometimes get confused about what I
> would be cancelling when I see a Cancel button.

If it's not clear what action caused an alert, the program shouldn't be
using an alert in the first place. For example, when you close a
document and you get the save-changes alert, it's obvious that the alert
appeared immediately as a result of your clicking the close button, so
that `Cancel' cancels the closure. In that case using an alert is ok --
with the usual caveat that over time you should aim to reduce the number
of alerts in your software to zero. (The successor to save-changes
alerts, in case you're wondering, is ubiquitous auto-save combined with
saved undo history.)

However, where a problem occurs that is not the direct result of a user
action, you should use a floating window instead of an alert. For
example, when at university I used a system which would (on occasion)
put up a stream of dozens of error alerts about a Netware server flaking
out -- not the direct result of any action of mine, and intensely
aggravating as a result. During my last year at university the system
was upgraded; the server flakiness problem persisted, but this time the
errors were displayed in floating windows in the corner of the screen.
Because the floating windows didn't obstruct my work or take keyboard
focus, they were much less annoying.

> > Escape is also bound to the Cancel button; changing the name would
> > make the binding of Escape unclear.
> 
> A valid point, but I think binding Escape to the Don't Quit button in
> this case wouldn't be all that bad (it's the least potentially
> destructive choice).

The problem is not that it would be `all that bad', but that it wouldn't
be at all obvious. There would be no visual indication that `Don't Quit'
*was* bound to Escape, since -- unlike the Enter key -- the Escape key
does not bestow any special border or decoration on a push button. It
would appear that there was no immediate keyboard access to the button
at all. And the next thing you know, someone would be suggesting adding
an additional access key to the button to `solve' that problem, slowing
users down still further.

>...
> > This results in two similarly labelled buttons thus forcing the user
> > read 5 words instead of 4. "Don't Quit" and "Don't Save" are so
> > similar in form that the user would probably spend extra time
> > ensuring that he's got the correct one.
> 
> But since Cancel is presented as the alternative to Saving, it may
> appear that pressing Cancel cancels the save, rather than the quit.

It *does* cancel the save *and* the quit. :-)

> I think there are arguments either way here. I would be glad to
> subject it to user testing.

Be my guest. I've watched people in the cafe interact with alerts for
enough months that I'm confident of the outcome.

> > From mpt's Improving GNOME 2.0 for humans
> > (http://geocities.com/mpt_nz/ig2h.html)
> > |
> > | Because the effect of this button is always the same, giving it a
> > | context-specific label would be more confusing than useful, so it
> > | should
> > | always be labelled Cancel.
> 
> I think it's pretty obvious that in this case the maning of Cancel is
> _not_ clear to users, even if it is, in some abstract sense, "the
> same" as at other times. Does it cancel the save or the quit?

In a word, yes.

> The abysmal results seen in user testing "Yes/No/Cancel" type dialogs
> leads me to believe that users are not clear on this.
>...

The abysmal results are the result of using `Yes' and `No', not the
result of using `Cancel'. Your reading for today is
<http://mpt.phrasewise.com/stories/storyReader$4>.

-- 
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/>