Re: Simple Yes/No dialog

[rk-list koebler com]

hi,

> In general, though, if you're writing an application, blocking yes/no
> dialogues are often a stumbling block in the user interface -- i.e.
> they can suck :-)
yes, definitely. yes-no-dialogs are _bad_.

it slows down the work _a lot_, because you have to read the question
very carfully, and think what the buttons now mean. and nearly every
yes-no-dialog exists with the yes-no-answers "swapped"; and there are many
users, who even lost data because of these dialogs...

it's generally better to ask: "what do you want to do ? [A] [B] [C] ...",
because the user usually _knows_ what he wants to do, and then he can
click on the appr. button. he actually knows the answer before the dialog
is displayed. that's simple and intuitive.

(compare this with yes/no-dialogs: the user does _not_ know whether he
 want's to click on [yes] or [no], before he has read the question
 carefully.)

> One problem is that the user can often think of other responses they'd
> prefer to make:
>    The file blacksock already exists.
>    Replace it? [yes] [no]
it's even worse. every yes-no-question can be asked with yes and no "swapped".
here are some bad examples of a simple "close dialog":

- The file ... was modified. Continue ?
  [yes] [no] [cancel]
- The file ... was modified. Do you want to save it before quitting ?
  [yes] [no] [cancel]
- The file ... was modified. Do you still want to quit ?
  [yes] [no] [cancel]

and the questions are often much longer and more complicated than
these simple examples. and it even isn't clear what "cancel" does
in the above dialogs...

> could better be
>    The file blacksock already exists
>    [don't save] [choose a new name] [overwrite]
> but even there the user might want to look at the file first.
yeah. here it's enough to look at the buttons.
and it's not necessary to search if there's a negation in the
question or not. and you don't need to think what this "yes" or
"no" might mean, because the button already explicitly tells you.

in my example above:
- The file ... was modified.
  [save] [discard (or "don't save")] [don't quit]

this is _much_ better.
and some programs already behave like this (i.e. gimp). and the default
save-dialogs in gtk (or glade) also have "save"/"cancel"-buttons
instead of yes/no.

> But if the dialogue is blocking, and they move the yes/no window,
> they won't be able to interact with your program e.g. to load
> the other file and see whether they want it.
>
> Whenever you find yourself making a blocking dialogue, ask
> yourself whether there's a better way.  Of course the other
> ways are often a lot more work, and you probably already did
> ask yourself this.
some programs even display both file-metadata (size,mtime,...), and some
display both files (i.e. images) in these cases.

but blocking dialogs definitely make sense, and you shouldn't make a
blocking dialog non-blocking, without knowing the consequences and without
examining the program according to this.

if you want to make non-blocking dialogs, you have to take care i.e. that:
- a lot of non-blocking-dialogs may be opened, and stay open.
- the program works well although a lot of non-blocking-dialogs are open.
- either a dialog blocks some functionality, or there may be several
  identical dialogs, doing/asking the same.
  (in the 2nd case: what happens with i.e. 2 identical save-dialogs ?
   or: what happens to the 1st save-dialog when a 2nd was used to
   save the file)
- these non-blocking-dialogs may hide behind i.e. the main-program-window.
  and if the non-blocking-dialogs "blocks" some action, you may drive the
  user crazy :(
  (example: non-blocking save-dialog. it blocks the save-button, so that
   there's only 1 save-dialog for this file. now, this save-dialog hides
   behind the main-window, and the users tries to save the file...)

cu,
Roland