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

[Maciej Stachowiak <mjs noisehavoc org>]

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. Seeing
it with no other buttons makes me think "What am I accepting here, and
why is it asking me, if I don't have the choice not to accept?"

> 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".
 
> > > >    - Confirmation alerts would have Cancel (as such) and an OK-equivalent
> > > >       button labeled to indicate what is okayed. When appropriate they
> > > >       would also have an alternative action button.
> > 
> > "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.

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

> > 
> > Here I would name the cancel button "Don't Quit" for
> > clarity. Otherwise I wouldn't be sure how "Cancel" is different from
> > "Don't Save".
> 
> 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.

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

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

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


Regards,

Maciej