Re: [Usability] What happened to Undo?

["Blad, John Erling" <john erling blad aftenposten no>]

Argh, should just write a short comment..
Sorry for terrorizing the angloamerican language!

> 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.

Revert should be used as an alternative for Undo because it is much
simpler to implement.

Undo without Redo isn't much useful so a simple stack don't hold. It
must be a double linked list of undo-redo action pairs. As I recall from
some years back, it seems like undo-redo actions can be spawned by the
widgets involved. Still, sometimes you have to set "breakpoints" in the
list because changes are irreversible.

A breakpoint will drop previous parts of the list when the user traverse
beyond that point. Typically you will have something like

action -> action -> action -> irreversible action -> action -> action
(un/re)   (un/re)   (un/re)   (bp)               (un/re)   (un/re)
                              ^
                              Here there is an irreversible action and
                              previous undo-redo pairs must be dropped

As I recall I dropped the previous part of the list if it was
unreachable, that is, each time I inserted an undo function I checked if
it was a null pointer. 

Now, when a user traverse the undo list a really funny situation could
emerge, he could access an undo function which sets some state and a
redo would then make the system unstable. It seems like undo and redo
actions must be able to set breakpoints themselves, although this
happens rather seldom. A fix to this was an utility to drop the list in
forward and reverse direction.

If the user undo some actions, then makes a change, the undo-redo pairs
forward in time from that point should be dropped. That is the simplest
thing to do. If not there should be an action to test if the forward
list of actions should be kept or dropped. If it is not dropped actions
would be inserted until a state exist where the forward (redo) list is
dropped.

I assumed that a similar test should exist due to symmetry but I never
found anyone.

It is also possible to undo specific actions. To do this you must have
some sort of gui, typically a list of actions and the state on that
particular point in time. It seems like the user associate "undo" with
the specific action and then "redo" with that single action he/she has
undone. When the user has undone an action the previous action should be
replaced with the new one. This model generates a lot of problems,
mostly what to do if the old state is unreachable or illegal from
present state.

This undo model generates a sort of "click to undo" interface, typically
a single drop down undo list.

If the undo-redo list accept insert actions, that is forwards and
reverse dropping of the list is implemented, then it is possible to
traverse back to some point in time through the undo list. At that point
the user can do what he/she wants, jump over some actions and traverse
forward. Conseptually this is simpler except for what to do with the
actions left out. It seems like it is simplest to drop actions forward
from an insert point and to the first "redo" action. To move forward
from that point the user can singelstep.

This undo model generates a sort of "traverse to undo" interface,
typically drop down lists for both undo and redo.

In a gui with Revert a breakpoint just creates a snapshot of present
states. This is much simpler to implement.

John