[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-look
Subject:    Re: Standard questions and answers
From:       Derek <fountai () hursley ! ibm ! com>
Date:       1999-09-16 13:13:11
[Download RAW message or body]

Read this to the bottom... It's not a complete knock back!

> Imagine you just hit the little X to close a window, and up pops a dialog
> with *no text* and just two buttons.  If the buttons are 'OK' and 'Cancel',
> you can fairly safely make an assumption of what will happen: OK will
> continue with possible ill effects, and 'Cancel' will prevent *anything*
> from happening, it's that simple.  If the buttons are 'Yes' and 'No', you
> really can't make an assumption.  Here are too possible texts that prove the
> point: "This document has changed.  Do you want to save your changes?" and
> "This document has changed.  Are you sure you want to quit?"

I see your point now, but I'm not convinced by it. When you say "you can
fairly safely make an assumption of what will happen" you are assuming
that other people's minds work like yours does. You are assuming that
the invisible text of your example reads "This document has changed. You
will loose your changes if you continue." Alternatively, I (or someone
else) might assume that it says "This document has changed.  Changes
will be saved before exiting", or maybe "You have unsaved data. Please
save it before exiting". Different, but perfectly possible results, and
I could probably think of a couple more. I know from long experience
that any argument in HCI which contains the words "assumption" and
"simple" is bound to be flawed.

> OK, you say, any self-respecting dialog has text on it.  Sure, but people
> barely read those things anyway.  It's like pulling teeth getting people to
> tell me what an error dialog says when something goes wrong with my
> software.  But they sure do know what the buttons say!

We cannot try to guess what the user thinks the dialog will say. I've
never seen evidence that says users don't read dialog messages, but I'm
prepared to accept that you might be right. We cannot try to guess what
assumptions they will put on the words in the buttons. If anything, the
fact the buttons say "yes" or "no" will actively prevent them from
guessing what the dialog says. They will *have* to read it. The best way
to deal with that is to make what they have to read simple and
unambiguous, and the responses likewise.

> That's why I think it makes more sense to make the buttons fit the context
> of the situation, and if you have to reword the question a little, fine.

I do understand this point, but it still suffers from assuming that the
user interprets the context in the same  way the programmer does. If the
user has hit a button accidentally, or is experimenting with a new piece
of software, this is a dangerous assumption.

If you read the draft of what I proposed you'll see that I didn't rule
out using OK/Cancel where appropriate, but that I said we should use
Yes/No in the first instance and something else if that's not
appropriate. To be honest, you've swayed me a little bit. I do see the
benefit of a quick confirmation, and the natural gravity of an "OK"
option to someone who knows what they are doing in familiar situations.
I'm not sure how it relates to an inexperienced user though, and that
doubt tells me it's the experience in me that is identifying with a
familiar concept. That doesn't mean it's a good idea, just that it is
familiar!

If you would like to draft another rule which says when OK/Cancel is a
better alternative for programmers to use to Yes/No, please do so and
put it up for discussion. I'll use it if it gets the nod.

[prev in list] [next in list] [prev in thread] [next in thread]