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

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


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