Re: property dialogs

[Bruce Dodson <bruce_d istar ca>]

Dirk Luetjens wrote (of auto-apply):

> 
> I don't like this behavoir in general, because:  you will never know if
> the action bound to this entry is rather time consuming or not. Consider a
> vector based drawing application and a property dialog to change the style
> of an object. Sure it will be a good feedback if the object changes its
> properties immediatly, but when the object gets larger and the object will
> be redrawn all the time when toggle through a list...
> 
> This happens to me in Khoros all the time, when want to change two
> paramters of an image filter. First the filter runs directly after i hit
> return in the first entry and second, due to the run of the changed filter
> a lot of other actions are started afterwards.
> 


The items on a dialog or property page are together there because they
are logically grouped and perhaps interrelated.  The user can think
about them more easily as a group.  Similary, the developer could think
about them more easily as a group; therefore the code will be simpler
and more efficient if the changes are applied all at once.  (Dirk's
illustration of a vector drawing application is a perfect example for
this.)

Furthermore, there will sometimes be changes that simply cannot be
undone.  Maybe the dialog is a front-end to RPM, or maybe it is for
formatting hard disk partitions.

Consistency is important.  If there are some changes that cannot be
undone (e.g. an RPM uninstall), or if there are some changes that cannot
be efficiently applied incrementally (e.g. the drawing program), then
these should not be auto-applied.  Therefore, for consistency, _nothing_
should be auto-applied.

If something like a checkbox sometimes auto-applies and sometimes does
not, the user will have to stop and think about what is going to happen
whenever he/she clicks on a check box.  For me, the "stopping and
thinking" would waste far more time than the auto-apply would ever
save.  Even for others, who aren't such slow thinkers ;) the auto-apply
is more compute-intensive and is bound to slow the user down a little,
especially for borderline cases where it's not clear whether the change
should be auto-applied or not (e.g. the system color scheme).



In a related matter:
Refering to the User Interface Hall Of Fame/Shame (the link is on the
GNOME home page), I see a very reasoned argument against Microsoft's
Apply button.  Basically, it says that the most common use of the Apply
button is for previewing, and it is useless for that because, once you
hit apply, the changes can't be undone (except manually).  This matches
my own usage of that button.  I also remember an early Windows 95
tutorial, published in a prominent magazine, which said that if you
"Apply" but then "Cancel" your changes _are_ undone.  This was
incorrect, but it does support the Shame/Fame peoples' assertion, which
is that the intuitive action for the button between "OK" and "Cancel" is
for previewing your changes.

Therefore, I suggest that GNOME should use something like this:

<OK/Accept> <Preview/Test> <Cancel>

*The first button applies any changes and closes the dialog.
*The second attempts to show the user what would happen if the changes
were applied. Sometimes that will not be possible, in which case this
button will not be present.
*The third button cancels any changes and closes the dialog.

I used multiple words because the words don't really matter.  However,
it is important that, if you use a word that is likely to be familiar to
the user (e.g. one that comes from Windows 95 or from Motif interface
standards), it should have the action that users are used to getting
from it.  But that discussion is best left for next time.

Sincerely,
Bruce Dodson