Re: [Usability] What happened to Undo?

[Gregory Merchan <merchan phys lsu edu>]

On Fri, Jun 06, 2003 at 06:47:04PM +0100, Calum Benson wrote:
> On Fri, 2003-06-06 at 18:21, Gregory Merchan wrote:
> > On Fri, Jun 06, 2003 at 12:37:08PM -0400, Havoc Pennington wrote:
> > > On Fri, Jun 06, 2003 at 11:31:21AM -0500, Gregory Merchan wrote:
> > > > Once upon a time GNOME was supposed to change to instant-apply control
> > > > panels with the forgiving feature Undo and possibly a way to restore
> > > > system defaults.
> > > > 
> > > > What happened?
> 
> Not a lot... the relevant bugs are still open, and I don't recall any
> clear agreement on whether we should have Undo (last micro-change),
> Revert (which is to Cancel as Apply is to OK), or (Reset to) Defaults. 
> I think the majority vote was for Undo, though, even though it has more
> potential to leave settings in an unstable state than the other two, so
> I'm prepared to accept defeat on that one :) 

Describing what Undo affects as a "micro-change" gives me cause to worry.
Do we not have a better description of what Undo and Redo should do?
The HIG has scattered references to Undo, but it never defines an undoable
action. Indeed, we seem to be missing an entire section on user interaction
where the definition would naturally fit. I don't know off-hand what else
would be in that section, but a precise description of Undo seems a class
apart from the existing sections.

I think we should have Undo and maybe Defaults, but not Revert.


As I recall, we shouldn't have any unstable setting states. I'm at a loss
to think of how they might occur. We have three basic types of settings:
numerics, booleans, and strings. (GConf has a finer division, but that's
not important here.) Because numerics should be bounded, an independent
numeric should never cause instability. A fortiori, independent booleans
shouldn't. When types depend on each other, stability is at risk. However,
that risk should be mitigated using inconsistent or insensitive widget
states. String types may be unavoidably dangerous when they have no natural
boundaries. (A color value stored as a string is naturally bounded and the
graphical interface can constrain input to those bounds.) I have trouble
imagining a state that cannot be stabilized before irrevocable harm is done.
Although a filename or a hostname is almost free-form, character restrictions
not being very limiting compared to numerics, these are still bound by
accessibility. That a named file does not exist or is not readable can be
detected and the user notified. The only danger I can imagine is from a
configuration that invokes a script.

All of that is to say that the danger from Undo leaving settings in an
unstable state is almost non-existent.


Both Defaults and Revert can change many settings at once. These may number
beyond what the user can recall. It would be disheartening to have changed
many settings and then eliminated those changes by accidentally pressing
Defaults or Revert. Given either, Undo is not just desirable, it is necessary.
Because pressing Revert is the same as pressing Undo many times, it would
be almost redundant; a click saver, nothing more. If we are to have either
Revert or Defaults, we should have Defaults as it provides a unique function.

And I believe we should have Defaults for more reasons than its trivial
implementation. As someone working on GNOME, I want it to check defaults.
As a help desk worker, I would want it as a bail-out measure. As a naive
user, I might think that the developers know their stuff and have chosen
good defaults. As an office worker who is sick and tired of not finding
my own tweaks on every coworker's desk, I might chose to be less frustrated
when they ask me for help.


Cheers,
Greg