Coming UNDOne

[John Walker <acad!throop!kelvin>]

It's been a while since I butted into the middle of a discussion
I largely don't understand, but hey, after all the discussions of
revert, pervert, undo, redo, etc., I just wanted to inject one design
goal based on experience.  Whether it's at all relevant to the decisions
you're making in the current front-end work, I'll leave for you to
decide.

One of AutoCAD's most unusual features, as applications go, is its
UNDO facility.  Every single AutoCAD command, other than those which
write external files or exit the program, can be UNDOne.  The
UNDO history is maintained back to the start of the user's editing
session on that document.  The user can, at any time, walk back the
UNDO history either command-by-command or in larger steps, reversing
operations which were performed and precisely restoring the status
quo ante--and I mean precisely: all mode settings, transparent commands,
database handles, etc. are preserved.  In addition, applications which
implement macro commands can cause an arbitrarily large set of primitive
commands to be considered as one item for UNDO.  Hence, a complex
application-implemented command can be UNDOne by the user with one
UNDO, just as if it were built-in.  In addition, there is a REDO which
rolls back operations in the other direction.  In AutoCAD, REDO can
reverse only the most recent UNDO; in retrospect we've concluded this was
an unfortunate restriction, and in AutoSketch you can walk up and down the
chain of past operations with UNDO and REDO with total freedom.  At the
point you perform the first normal (e.g. UNDOable) operation after a
sequence of UNDOs and REDOs, any UNDOne commands are chopped off the
history and replaced by a new thread that starts with the new command,
preserving the ability to later UNDO it and the commands that came before
it.

We've found that having this completely general, N-command UNDO is not
just a nice feature: it is a major component of our user interface and
significantly changes the way the product is used.  A user who never
lives in the fear of a disaster and the horrible mocking leer of the
greyed-out "Can't Undo" is far more likely to explore and experiment
on his own, rather than spend hours pawing through a manual or repeating
inefficient and clumsy, but known-safe ways of doing things.  (For
users who run with limited disc space, we do provide a one-command
option for UNDO; I know of no users who run that way.)

As to collapsing the admittedly large intermediate UNDO trace, our
convention is that when the document is finally closed its UNDO history
is discarded.  Closing a document is a user act of volition, and generally
means the user is happy with its state.  At that point reversion to the
backup file is the only form of UNDO that remains.  Note, however, that
the act of periodically saving a document in the middle of an editing
session does NOT truncate the UNDO history; you can UNDO past such
points with total freedom (but since such operations write external
files, they are not UNDOne when you cross them).

How do you implement such a general UNDO?  The same way a CODASYL DBMS
does--every time you change the state of something at the user command
level, you write a transaction to the UNDO file that records the old and
new state of everything that command changed.  UNDO rolls this file back,
replacing new with old, and REDO rolls it forward, replacing old with new.

Is this a minor point?  I think not.  Whenever I use a Macintosh application,
and I use Excel and FreeHand frequently and Word occasionally, it seems
that whenever I want to use Undo I'm either at a "Can't Undo" state or
the thing I want to undo is one or two commands back from the operation it
will let me undo.  Thus Undo becomes a tantalising frustration, not the
means of salvation for the fumblefingered.

Given the Xanadu back-end's unique strengths in preservation of information
and maintenance of historical traces and accountability, shouldn't the
front-end go the extra kilometre to provide the user a similarly robust
and friendly environment in which to access Xanadu?

This issue is, as far as I'm aware, totally unrelated to the holy wars
over user interfaces.  It does, in my opinion, belong as the third plank
of the Computer Users' Bill Of Rights.