Re: Comments on dialog proposal

[Christian Rose <menthos menthos com>]

Michael Rogers wrote:
> > Yes, and that's my point. "OK" implies "apply these changes and close
> > the dialog". But they have already been applied, so what does "OK" in
> > this case really do? That may not be entirely clear to the user.
>
> What difference would it make if the button *did* apply the settings and
> close the dialog, instead of just closing the dialog? Absolutely none,
> since those settings are already in force. Perhaps User A is aware that
> the settings are already in force, and User B is not. There is no
> difference between what User A would expect the OK button to do
> (settings already applied, just close the dialog) and what User B would
> expect it to do (apply the settings, close the dialog). Either way, you
> end up with the same settings. So who is going to be confused?
>
> Let me put it this way: in a dialog that doesn't instantly apply
> changes, there is often an Apply button and an OK button.
>
> Q: If you hit Apply and then OK, does the OK button apply the settings
> again before it closes the dialog?
> A: Who cares? What difference does it make?

In most cases, the net result would be no different, no. What I'm worried
about is the cases where it would be, and that we would change existing
conventions regarding what "OK" means into something very different.


First of all, I'd argue that the amount of time a user spends in a dialog
by no means has to be negligable in all cases. Some preference dialogs are
complex with many settings and require some tweaking, even for experienced
users (a good example would be the amount of time I spend configuring my
mailer the first time I run it).
Also, not all settings are obvious, the user might need some time reading
the help or even leave the computer for a while to ask for help with some
of the settings, all while leaving the dialog open. In addition to that,
not all users can the parse all the information as fast (think
disabilities, low vision, etc.) as you or me.

Second, many settings are not relevant to time, but some are. By that I
mean that the question if settings are applied instantly or when "OK" is
pressed becomes really important. The most obvious example would of course
be setting the clock. I think I'm not the only one who usually sets a
system clock (when not using NTP) by setting it a minute before actual
time and then hit "OK" in the moment that time comes. Tweaking the meaning
of "OK" in an instant-apply dialog in this case is very unfortunate.

But there are lots of other examples where time is important. Consider me
changing my mail forward address in the preference dialog of my mailer,
then waiting with hitting "OK" and first searching the systems
administrator in the office because I want to ask him if what I've entered
in the dialog is correct. Maybe he's already out for lunch and I'll have
to wait. When he comes back he says "no, that's a non-existing address".
My mail was pointing to a non-existant address during that time, and my
mail has been bouncing, even though I never touched "OK" to apply the
settings.

These may be stupid examples but I'm sure you can come up with better ones
yourselves. When you hit "Apply" in a dialog with "Apply" and "OK"
buttons, you're probably aware that you are applying settings, due to the
nature of the label on that button.
That's not always the case with instant-apply dialogs, and labelling
something "OK" in that case makes that problem worse in that the user is
even more mislead to beleive that the settings will be applied only when
he or she presses the button. And knowing when something is applied
is important information. We should help the user understand when
something is applied, not mislead them into beleiving something that is
never true.


Christian