Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[storm@cua.dk (Kim F. Storm)]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Kim Storm wrote:

I wrote, you wrote, Lennart wrote, RMS wrote, bla bla bla :-)

Seriously, we seem to _completely_ disagree what an ordinary (novice) user
would expect from a customization interface.

My claim is that he is familiar with an interface where a page has:

 - N different options (N > 1)

 - an "Apply" button  which saves and activates the changes,
   but keep the page open.

 - an "Ok", "Save" or "Finish" button which saves and activates the
   changes, and closes the page

 - a "Cancel" button which closes the page without saving or activating.

 - a "Reset to Defaults" button which removes all user customizations
   and activates some "factory" determined set of defaults.


 - he may expect to see buttons which open sub-panels for customizing
   a related group of options, or does some specific action.


IMO, any significant deviation from that scheme is for _experts only_.

Specifically, no matter how useful it might be, an ordinary user does
not expect to see a "checkbox" or "save" button for each option, and
he will quickly be lost is a maze of tiny little passages.

>
>    IMHO, this is _expert_ behaviour.
>
>    I think that most novice users will very rarely mix and match setting
>    some options and saving others.
>
> Rarely, but sometimes.  Why confuse them badly if they do?  Moreover,
> it is not just setting and saving.  It is also about looking at
> possibilities and saving.  Especially with the more complex "Value Menu"
> buttons.

There is NOTHING confusing if you can only "save all options".

The confusion arises when you have the option to "set but not save"
some options, and later on you do "save" -- that will save all options
including those you only "set".

But that's not a big obstackle.  If the user has used "set", then
changes some more options, and hit "save", emacs could just warn
him that

    Warning: This will save parameters which you have previously
             set for this session only.  Continue?

If he doesn't like that (because he has been experimenting with
various settings), he can say "no", do "Cancel unsaved changes",
and redo the changes he actually wants to save.

Maybe not 100% satisfactory, but there's nothing strange about it.


>
>    If he is satisfied with the current settings, he will save them ALL.
>
> But the problem is exactly that he may _not_ be satisfied with all the
> current "settings" (widget values).  He may just have wanted to set
> them, or even more likely, just has been looking at them.

I don't think this is _typical_ usage.

Suppose the user is playing with some feature, e.g. ido-mode, which
has many options.  He tries to "Set" some parameters to see the
effect.

If he doesn't like the effect, he will "Reset" to set it back to what
it was.

If he likes the effect, he should "Save" before starting to play
with the next option.  If he doesn't -- well, he will quickly
learn that is the proper thing to do if he is playing with things.


For this specific purpose, it might be useful (and not too obscure) if
each parameter had a single "Undo" button which could be used to reset
that specific parameter to the last saved value.  But I doubt it will
be used much.

>
>    If accidentally, he saves some option which he forgot he had only set
>    and really didn't want to set, he can EASILY revert the change, either
>    in the same emacs run or next time he runs emacs.
>
> Why force users to go to that trouble if it can easily be avoided?
> Moreover, if you save options that you do not want, you do
> not even know which one you saved.  The user will have to scan his
> custom-set-variables or custom-set-faces forms.  We are supposedly
> talking about a novice user.

Again, you expect a specific user behaviour -- which I think is uncommon.

>
>    Why don't we simply introduce a "customize-expert" option that is off
>    by default, but can be turned on when the user gains more experience.
>
> I believe that we should introduce a "customize-expert" option, off by
> default, and only enable the all whole buffer buttons if it is on.

Amusing :-)

> Personally, I would not turn it on.  I do not come even remotely close
> to being enough of a Custom expert to be able to handle the complexity
> of whole button buffers.  I always am careful to set custom-file to a
> junk file when I play with them.  (I never use them "for real".  Much
> too dangerous.)

Really ?  

If customize is so dangerous, it should really be off-limits for
everybody...

But seriously, I bet a novice user can make greater disasters with a
few lines of bad Lisp in .emacs that he will ever do with Customize.

>
>    When off, it can limit the features of the customize interface to 
>    those features most novice users will be familiar to from other
>    interfaces.
>
> Custom _is_ not exactly like other interfaces and _can_ not be.  Other
> interfaces are not trying to handle an underlying customization system
> that is anywhere as complex and extensive as Emacs'.  

Huh?  

Just because some dialogue box in some other application is
written in C++ or java or a combination of HTML, javascript, and Perl
doesn't mean that the underlaying functionality isn't as complex
as emacs'.

If you think there is a problem here, it might be that customize is
still a "low-level" interface, giving you access to too much of
emacs' functionality in a "lispy" way.

>                                                       The average
> Custom buffer is a lot longer and contains a lot more options than the
> average customization "page" (or whatever they call it).  The choices
> you have for an individual option can be a lot more complex.  Complex
> types like `choice' force a concept of a `widget' value.  Very
> importantly, other interfaces do not have to deal with the tremendous
> complexity of options that can be changed by _both_ the user and programs.

In the applications I work with, customization is combination of
several different management interfaces, XML import/export of
configuration files, automatically generated configurations, and
factory installed customer specific configurations.  

Configuring Emacs isn't nearly as complex as that!!!

>
> What makes the whole button buttons dangerous are, among others, the
> concept of a separate widget value, the difference between Set and
> Save, bugs in Custom, the length of Custom buffers, 

That's a generic issue -- and we should improve that if we can -- it
has nothing to do with how to set/save values.

>                                                     options changed
> by programs behind the user's back, and user absent-mindedness.  We
> are never going to be able to do something about the latter, 

True.

>                                                              even if
> we do something about everything else, which would be highly
> non-trivial and would involve removing present features, which people
> actually use.

I don't suggest to remove anything -- just hide things that is confusing
to the novice user.

>
> The concept of saving options one by one is not a difficult concept,
> whether the user is used to it or not.  One should not equate "novice"
> with "stupid".

So why do you do that ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk