On Thu, Sep 06, 2001 at 10:57:58AM -0700, Adam Elman wrote: > 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. I disagree about the button names (see my dialog guidelines for some rules about those) but Adam is right: we should worry about that later. The principle that this is stuff that shouldn't instant-apply is, of course, correct. > 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. I'm curious as to whether we can let this go beyond purely visual properties. What about, for example, the property window in Glade, which is currently instant-apply and has a number of non-visual properties? I'm actually willing to allow that, as long as we can indicate the instant-apply nature of the dialog. > 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, Ok, the real question here is how do we create a visual indicator that a dialog is instant-apply? And I think this may be something that the user has to learn. Actually I quite like the suggestion of having no buttons along the bottom. To me that indicates that there is no next stage. But as others have pointed out, this brings its own problems. > 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'm not sure how we would fit such an Undo button into the dialog and still appear to be an instant-apply dialog. But that depends on what we decide is our indicator. (see below) > 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. I'm actually not so concerned with making rules about which things should or shouldn't be instant-apply. I think there'll be a lot of cases where it'll be up to the developers own judgement whether it's appropriate or not, and while we can give some guidance I don't think our guidelines can be anywhere near comprehensive enough to cover this area adequately. The problem, therefore, is not to create classes of settings which users can expect to be instant-apply and classes which they can expect to be delayed-apply (for want of a better term), but to create a means by which when a user sees the dialog they will know instantly what to expect will happen when they toggle a checkbox. I guess what we're looking to do is create (or rather, formalise) a class of dialogs which we might call "toolboxes" or "property sheets" or something like that. So... What options do we have for indicating that a dialog's settings will apply instantly? (I'm assuming that delayed-apply dialogs will remain pretty much as they are. I don't really want to try retro-fitting some indicator onto those.) 1) Remove the bottom row of buttons. This is probably my current favourite. I don't personally believe that the problems are too serious. 2) Change the bottom row of buttons to just contain "Close", or perhaps "Revert"/"Close". I don't think this is sufficient. One of the principles of dialog layout is that the user can work from the top left to the bottom right. This disrupts that by forcing them to look at the bottom right to discover the effect of controls in the main area. (More likely, they won't look, and will be surprised when things happen, or fail to happen, unexpectedly.) There must be more ideas than this. I'm curious to hear them. One other random point: Settings which apply instantly and those which are delayed should not appear on the same dialog unless, perhaps, they are given their own Apply button inside the main area of the dialog. colin _____________________________ ____ rtnl http://rational.cjb.net c z robertson ndirect co uk icq 13294163
Attachment:
pgpoSPG7S7I0V.pgp
Description: PGP signature