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



On Thu, 2001-09-06 at 13:57, Adam Elman wrote:
> 
> 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.


I agree completely here. 

Real quick, since I don't know if it's been explicitly stated here
before, I'm gonna give this little glossary of terms:

setting:  any value that can be modified that can possibly be wrong
preference:  any value that can be modified that cannot be wrong

--moving on now......


I'll admit that for legacy reasons, it might be a bit safer to use "Ok"
rather than "Apply & Close" but the latter is a far more descriptive way
to let users know what's going to happen.

Especially since there is obvoiusly going to be a split, and some
dialogs are going to be instant apply, and some are not, this lets users
know, by a quick glance, that their settings are not going to change
until they hit that "apply and close" button.  

The average user isn't going to look at a preference or settings dialog
and immediately discern the difference between the two.  By explicitly
stating that the changes are to be applied once you hit the button to
exit that dialog, we let the user know that until they hit that button,
nothing has been modified.


> 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).


I agree...mostly.

The user should not have to rely on the window manager for all the
reasons that have been stated several times already in this thread.

An "undo" button should not be present under any circumstances.  If the
application does not have a reasonable undo feature and needs one, than
it should be a part of the application.  We shouldn't have to make-up
for poor work on the programmer's part.


> 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]".

agreed.  I don't much like revert...but it might be useful in these
cases.....


Brian






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]