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

[Oliver Logghe <oliver logghe org>]

Hi. I thought I would add another voice to the din, so here goes.

On Thu, 2001-09-06 at 11:40, Adam Elman wrote:
> 
> My main point: I think it's more important to discuss the behavior at 
> this point than the button labels.  Please don't get caught up in the 
> labeling just yet; we need to make a recommendation for _behavior_ 
> above all, and secondarily what the buttons should actually say. 
> Specifically, we need to decide where to draw the line between dialog 
> boxes which should be instant-apply, and dialog boxes which should 
> _not_ be instant-apply.
> 
> I probably should've just left button labels out, but then much of 
> this wouldn't make sense.  But please keep that in mind.

Heh, finding just the right (English) word seems to be an ongoing
problem here, but it often clouds the real issues. Is there an English
language translation group? Maybe there ought to be, obviously it would
not function quite the same as other translation groups, but something
like that would really be the best place to decide the best wording for
buttons and the like. Debates about wording have cropped up from time to
time, but since it is really tied to English localization and also needs
to be done on an app by app basis for application specific strings, it
seems like such a group would be a more appropriate venue.

> By "object property dialog" I mean a dialog box which affects an 
> object which is part of a document.  My point here is that the "Undo" 
> function associated with the _document_ -- in the Edit menu on the 
> document window, for instance -- should suffice to undo changes made 
> by this kind of dialog.

I was confused by this too, though I think I got it with a second
reading. Perhaps "floating palette" or something would be a better term,
since these are not really dialogs at all (tell me if I'm still not
quite getting this).

If the implication is that *every* such edit operation use a floating
palette type window (i.e., object->properties brings up not a dialog but
a persistent palette type window for changing the properties of the
selected object), I think there is at least one reason why that might
not be such a great idea. On the face it is fairly seductive, and
already some programs do this for certain things. For instance, last I
looked Glade used such a window for object properties (which includes
just about everything about an object: name, slot bindings, everything).

The problem is that when a new object/bit of text/whatever is selected,
this sort of palette must bind to that (or else it is of little use: if
it is only able to edit the object with which it was invoked, why make
it a floating palette?). So what happens if you want to copy several
values from object A's properties into object B's? Or maybe just
reference A's values while editing B's? (In my experience these are
pretty commom occurences with property pages of even moderate
complexity.) The answer is you will probably end up doing a lot of
clicking back and forth (alternately selecting the two objects) with
this sort of setup. If you are editing the properties for multiple
objects, or strings within a text document, it is even more of a chore.
(The same argument applies double to complex modal dialogs of this
sort.)

I do think these sorts of palettes are quite nice, but in moderation. I
would not make a blanket prescription for their use. Maybe if there was
an accompanying prescription for an alternate way to access these kinds
of properties, like menu items for both "view->properties palette",
which showed the persistent palette window (which would automatically
update to reflect the selected object), and "object->properties" or
whatnot, which showed a new object specific instance of a regular
instant apply dialog (non-modal!). 
> 
> I think that program preferences which are _not_ associated with 
> objects in documents (and which therefore might have an "Undo" 
> button) actually belong under category #3, and might therefore belong 
> as non-instant-apply dialogs for consistency's sake, unless we can 
> come up with a better place to draw the line between the two.

For instant-apply *preference* dialogs I do not think undo is necessary.
Most of these are fairly simple with easily remembered or manually
reverted (and always non-critical) values, the few that do not quite
match those criteria probably do not justify an extra button (and the
requesite increase in complexity, not just for users but also for coders
who have to implement some kind of multi-level undo in all their dialog
boxes). [Ok/Accept] and [Cancel] will suffice.

> [#3]
> 
> >I propose that the buttons in this case should be "[Revert] [Apply] 
> >[Apply & Close]".  If "Apply" is clicked, "[Apply & Close]" should 
> >change to "[Close]".
> 
> Seth hates "[Revert]" for legitimate reasons; an appropriate 
> alternative would be "[Cancel]", although Cancel also has the side 
> effect of closing the dialog box.  Anyway, the point is to figure out 
> which dialogs should or should not be instant-apply; we can figure 
> out the details of the button labels later.  I just wanted to mention 
> it in case some folks get hung up on it.
> 
> Adam

I would vote for "Cancel", "Apply", and "Apply and Close"/"Close" (I
would think that "OK" is better, maybe "Accept" if you really want to
use a verb, but see above about language debates...). I think opening
the dialog/control-panel/etc and deciding you did not want these options
at all is more common than editing values and getting off course so
badly that you need to start over. In the former case you just want a
safe cancel button to hit so you can get out safely (especially if you
edited a couple values before you decided you were in the wrong place),
you definitely do not want to have to hit "revert" and then "close"
(which, up until right before you figured out to hit "revert", said the
very unsafe sounding "apply and close" and appeared to be the only way
to leave the dialog). In the latter case (messing up so badly you need
to start over) it is still not a big deal to hit cancel and re-open the
dialog. Of course, this is conjecture since I am just guessing about the
use pattern.

As for where to use instant-apply, I think the whole idea of using it in
preference dialogs breaks consistency. It would obviously be better to
have every dialog - settings or preferences - work the same. Since it is
fairly clear that there are definitely a few situations where
instant-apply is not practical, it has to be taken on a case by case
basis, and unfortunately the corner cases throw consistency out the
window.I suppose that there remains an element of consistency if
non-instant apply could be confined to "settings" type dialogs, and the
distinction between "settings" and "preferences" can be adequately
communicated to the user, of course that is a big "if". Like it or not
there are at least a few cases even in the "preferences" category where
instant-apply may be more of a hassle than it is worth, and the subtle
difference that has been made between a "preference" and a "setting" is
still a source of confusion even on this list.

There are also some preferences cases where it is actually nice to have
a small preview. Specifically I am thinking of the GTK+ theme selection
dialog: the preview box has a nice selection of checkboxes and listboxes
and so on, some of which otherwise might not happen to be visible just
then on the users screen. Instant-apply would work just fine, but it
would still be a good idea to have some kind of preview pane in this
case (and other cases where the changes may not be immediately visible
in their entirety).