Re: Comments on dialog proposal

[Maciej Stachowiak <mjs noisehavoc org>]

On 06Sep2001 01:18PM (+0100), colin z robertson wrote:
> 
> > > Furthermore, Apple are not infallible. I can see plenty of potential
> > > problems with instant-apply dialogs, and not a whole lot of
> > > advantages. So why do we want them to become the norm?
> >  
> > What problems do you see with them?
> 
> Places where they will cause problems:
> 
> Time and date settings: Mail and files are being timestamped
> constantly on my system, and cron relies on knowing the the time.
> Having the time set to an incorrect value is dangerous.

I agree, although I think it's useful to think about the setting
vs. preference distinction here. (Side note: in the MacOS X system
preferences, the pane to set the data and time has "Revert" and "Save"
buttons so obviously they agree with you; however, when you are using
a network time server, time setting is disabled and the buttons are
replaced by text that tells you you can't set the time when using a
network time server).
 
> Things which require a lot of processing: Even changing GTK+ themes is
> slow enough that I wouldn't want it to happen every time I look
> through a list. It's not difficult to imagine situations in graphics
> and audio programs where this would be highly undesirable.

Such preferences are hopefully rare.
 
> File permissions: Any time at which a file has its permissions set
> wrong is time at which it's vulnerable. Furthermore, it's not obvious
> whether permissions have been applied or not.

The Nautilus file permissions dialog applies settings instantly, yet I
don't think it has this risk. You have a separate checkbox for each
individual read / write / execute permission, so you don't go through
invalid states in the middle.
 
> Network settings: If someone were to create a GUI to a procmail-like
> system, all the time I spent entering a new filter would be time in
> which mail would be getting filtered to the wrong place.

I think you could design a UI that prevents you from ever having a
"wrong" half-entered filter setting. Usually UIs that deal with lists
of items, each of which requires complex setup, have a list and a
button used to add a new entry or edit an existing one which pops up a
separate dialog. However, once you're done with the item-specific
dialog, the changes apply instantly. In fact, we see dialogs that work
like this all the time even on systems where instant-apply is not the
norm.

I can also imagine an argument for inhibiting filtering entirely while
you are changing filter settings, and filtering the backlog when done.

The thing about these kinds of issues is that you need to take it on a
case-by-case basis rather than assuming there is one best solution for
every situation.

> > I imagined a whole lot before
> > trying it, but having used them in Nautilus and OS X I think they work
> > great. Have you tried out any programs that have instant-apply
> > preference dialogs?
> 
> Not many. I was rather disorientated when I encountered them in the
> panel. (I don't use Nautilus.)
> 

Did you get used to it over time?
 
> > The advantage to instant-apply is that it makes it really easy to
> > tweak multiple settings to taste. It also removes unnecessary
> > complexity - there is no real reason why it should take an extra
> > button press in addition to just changing the control to make the
> > setting take effect.
> 
> hmm. Personally I see an increase in complexity. As I have shown
> above, there will be situations in which we can instant-apply and
> situations in which we can't. Now a user is going to have to work out
> for every dialog individually whether it will instant-apply or not.

First off, such situations are not the norm. Second, they can be very
clearly flagged with buttons that have labels like "Apply", "Save", or
"Apply Now". In fact, I think "Save" "Revert" "Close" is a better set
of buttons for non-instant dialogs than "OK" "Cancel" - it's super
clear what button to press to save your settings, and you can still
make multiple changes and see the effect without closing the dialog.

For the user who is not used to computers, the concept of "applying"
settings they have made will be a foreign one. For instance, when you
toggle a light switch, you don't have to press an "Apply" or "OK"
button to make it take effect. If you change the volume or the station
on your radio you don't have to press an "Apply" button. 

> I'm fairly fearless about what I do in dialogs because I know that
> nothing will happen until I press a button. An extra button press is
> no great price to pay to give the user an impression of safety.

For most preferences, you shouldn't have any fear anyway, because
there should be no "wrong" values. Are you ever scared to use a light
switch, or twist a knob on your radio?

> Imagine the following situation: A user who frequently changes the
> image on his desktop or the font in his documents (and sees that they
> apply instantly) finds himself in a situation where he has to change
> something like file permissions, for example, which is something that
> he barely understands but knows that it has important security
> implications. 

For most users, file permissions are largely unimportant because their
system is single-user or has relatively few users who are all known to
him. I think it's foolish to think most users will ever think file
permissions are such a big deal.

> Let's assume that we've decided that file permissions shouldn't be
> applied instantly (because of the security implications).

I definitely don't think we should do that. Accidentally making a file
world-readable or even world-writable for a moment is really not a big
deal and is easily reversible.

> Our user may not realise that these settings won't be instantly
> applied (or perhaps won't be sure) and will be too scared to even
> touch any of the settings for fear of breaking something. Having a
> user be cautious about pressing an Apply button is one thing, having
> them too scared to touch anything is another.

I don't think most users are gripped with fear about file permissions.
But in more realistic cases of this (say, setting your IP address), I
think the presence of an "Apply" or "Save" button will make it very
clear the settings need to be saved to take effect.
 
> > Imagine, for instance, a font selection drop down
> > in a word processing program's toolbar. It would be crazy if you had
> > to press an Apply or OK button to get that font selection to take
> > effect, wouldn't it?
> 
> The fact that it is in the toolbar rather than in a dialog conveys to
> me a message that it will instant-apply. The Apply button in a dialog
> serves two purposes: Applying the changes, and allowing the user to
> delay applying the changes until they want to.

I don't see why a font list in a dialog should be any different.

It's already easy to delay applying changes by not changing the
control itself.

To me, instant apply settings derive from the same principle as
WYSIWYG word processing. Why should I have to pick "Print Preview" to
see what my document will really look like? Why should I have to hit
"Apply" to see what my font change will _really_ do?

Anyway, this argument is a bit of a waste of time. GNOME is generally
going with the instant-apply approach, so we should figure out how to
make that work best for the user. In the words of Kosh, "The avalanche
has started, it is too late for the pebbles to vote."

Regards,

Maciej