An alternative proposal for instant-apply vs. non-instant-apply

[Adam Elman <aelman users sourceforge net>]

Hi, folks.

I'm moving this into a new thread because I think we've shifted the 
discussion somewhat, and I think we need to have some consensus on 
this before the HI Guidelines are finalized.  Since Colin is 
responsible for writing the dialog section of the guidelines, and is 
also firmly on one side of the debate, I think it's vital that we 
discuss this and come up with a recommendation that most of us can at 
least grudgingly agree to within the next week and a half or so. 
Hence, I'm making this an explicit proposal which we can 
debate/amend/etc. for a few days.

The question: should Preferences/Options dialog boxes in GNOME 
applications (including the GNOME Control Center preferences/options 
for the overall environment) instantly apply user changes, or should 
they wait for the user to click an "Apply" or "OK" button?

Here's my proposal.  I think #1 and #2 are relatively 
uncontroversial; #3 is the heart of the debate we're having.

1) System settings dialog boxes which can have incorrect settings 
should never be instant-apply.  These include network settings dialog 
boxes (where an intermediate setting in, say, an IP address field 
could be totally incorrect and dangerous).  These dialog boxes should 
have at least the following buttons:

[Cancel] [Apply & Close]

possibly plus "[Help]" if help is appropriate.  (I'm proposing "Apply 
& Close" here rather than "OK" because I think it's clearer, but I 
could be convinced otherwise.)  These dialogs shouldn't need a 
preview or "Apply" button in general, but it should be easy within 
the surrounding application (Setup Tools or whatever) to see the 
effect that the changes had and return to the dialog to make further 
changes.

2) Object property dialogs which have immediate visual effects (say, 
a style editor in a GNOME word processor or an object properties 
dialog in GIMP or Dia) should be instant-apply.  They should not have 
any buttons controlling the window: instead, the user should simply 
use the standard WM close box or a "close window" menu option to 
close the dialog, and the standard Undo command to undo actions 
(which ideally should have an infinite chain).  If there is no Edit 
menu with Undo available in the application, an "Undo" button should 
probably be present, although only if it has a reasonable number of 
Undo levels (i.e. more than 1).

3) User preference dialogs which might have immediate visual effects, 
but also might take time to apply across the whole desktop, should 
_not_ in general be instant-apply.  (This is where we run into a real 
source for debate.)  This includes desktop/WM themes.  The problem is 
that while it'd be nice to have the immediate feedback, the time the 
computer spends processing the change actually gets in the way of 
using the system.  If you're on a slow machine, even if the settings 
change is not dangerous, the time wasted in waiting ~5 seconds for 
the theme to change can feel dangerous enough to prevent users from 
wanting to explore different settings.

If there is a way to set the preference via drag & drop (for 
instance, dragging a background thumbnail to the desktop, or dragging 
a color/theme chip to a receptacle) the result of that drag/drop 
should indeed be instant; however, dialog control settings should 
wait for a button click.

I propose that the buttons in this case should be "[Revert] [Apply] 
[Apply & Close]".  If "Apply" is clicked, "[Apply & Close]" should 
change to "[Close]".

There are, I think, two major sources of debate on #3: a) whether or 
not dialogs which affect visual preferences but take a long time to 
process requests should in fact be instant-apply, and b) if not, what 
the button labels should be.  Let's discuss (a) before getting back 
into (b).

Thanks,
Adam
--