see
also the talk outline
short paper for HCI'96, Imperial College, London
see
also the talk outline
Powerful interfaces are dangerous interfaces. Small mistakes can cause large amounts of damage. Undo appears to reduce the risk of interaction, but does it really? The presence of undo encourages exploratory (risky) behaviour. This is fine so long as undo always works, but systems can be inconsistent in the way undo is implemented. Risky users will make more mistakes, which may not be undoable. Recent systems such as Word 6 implement undo more uniformly and allow multi-step undo. Even whole sequences of mistakes can be rectified. Surely this undo really does reduce the risk of interaction - or does it?
Keywords: undo, redo, history, risk
Undo is an important part of virtually all good interactive systems and has been studied in many articles and books, e.g. (Archer, Conway et al. 1984; Yang 1988; Thimbleby 1990; Abowd and Dix 1992; Berlage 1994). Some study how undo works, others ways to implement it. But what is undo for?
An obvious answer is to allow you to return to a previous state. However, that is really what undo does. A deeper answer is that undo, rather than being a system function, is instead the user's intention (Abowd and Dix 1992). That is, the purpose of undo is to help the user recover from errors. However, even this begs the question - why does the user need help in recovering from errors, especially help in the form of a button or menu option. We argue that the real reason for undo is to reduce risk
In Shneiderman's original definition of direct manipulation the ability to undo was central (Shneiderman 1982), but the emphasis in direct manipulation is upon implicit undo, where the user uses ordinary actions to undo the effects of others. For example, a mistyped character can be deleted, an object which has been moved can be moved back. This relies on proportionate effort: small actions give rise to small effects. Of course, if one kept strictly to this, applications would be pedestrian affairs only allowing slow progress to be made.
Really the whole purpose of using a computer is to use its power to obtain leverage on your task. You want to get a lot done quickly, large effects from small actions. But power always brings with it danger and risk: you select the whole document ready to change the font of the text and accidentally press the delete key (or indeed any key on an 'overtype selection' system such as the Macintosh). You do not want this disallowed as there are occasions when you really do want to delete large chunks of text, but the effect is to increase the risk of interaction. Hence the need for undo.
Undo should reduce the risk in an interface as it is possible to put things right when they go wrong, to start to go down dangerous or disastrous routes and then be able to back-up if it turns out to be wrong. But does it really work?
In fact, undo is extremely useful, even in its more rudimentary forms. However, we find that there are times when the presence of undo can make a system more risky! We will demonstrate this using examples from two generations of Microsoft Word (5.1 & 6). The issues highlighted by these two examples are not limited to Word, and similar problems can be found in other systems.
In the past many systems have implemented undo in a very incomplete fashion, perhaps because it is very difficult to program as an afterthought. This has improved significantly and Word 5.1 is a good example of the last generation of system with a comprehensive single-step undo mechanism. Studies on Word 5.1 have shown that users cannot predict what exactly undo will do under all circumstances (Wright, Monk et al. 1992), but nevertheless they find it a useful mechanism, perhaps partly because it often 'does it right'.
Like many undo systems Word 5.1 has two main classes of commands:
In general, when the undo command is invoked (from the menu or using the command
key '
') the last active action is undone and
any intervening passive actions are effectively skipped. Because it is only
a single-step undo mechanism, only the last active action can be undone,
but Word 5.1 clumps together certain sequences of active actions and treats
them as one, in particular most dialogue box interactions are treated as a single
action as are short sequences of uninterrupted typing. It is precisely this
clumping that users found difficult to predict in Wright et al's experiments,
but does appear 'right' in most circumstances. In particular, earlier versions
of Word treated each typed character separately for undo circumstances, which
proved disastrous when you accidentally overtyped a selection: by the time you
realised it was too late as several keystrokes had been typed and only the last
one could be undone! The current clumping, which is similar in Word 6, is much
better at getting the idea of the 'last thing' you did.
Figure 1. changes to/from outline mode disable undo
In addition to these active and passive commands, there are some other types of commands. First of all there are commands to save files. These operate at a different level to normal editing and are not able to be 'undone' within Word. This is not surprising (to a non-novice!) and we would expect to have to use file level features, backups etc., to deal with this. Also there are commands which change the view of the document. There are four such viewing modes: print preview mode, 'normal' or galley mode, page layout mode and outline mode. In print preview mode you cannot edit the text and it has the feel of a major transition (like saving) and so it is perhaps not surprising that you cannot undo the previous command after using print preview. In normal, page layout and outline modes it is possible to edit text, scroll and undo active actions. The exact functioning of selection and the presentation differ, but these are all 'editing' modes. While you are within any of these modes undo operates uniformly and consistently. However, when you switch between modes the story is more complex.
These mode-changes between views of the document are also passive in the sense that they do not modify the document itself. It would be natural to assume that undo would 'skip' these in the same way as it does other passive commands. This is effectively what happens when one moves between normal and page view mode. Imagine you are in normal mode and have just accidentally deleted some text, but before noticing the mistake you change to page view mode. No problem! You can simply undo the last active command. Unfortunately, the move to outline mode is more problematic. In the same scenario, if you switched instead to outline mode and then tried to undo, you would find that the undo command is greyed out at the menu. Changes to and from outline mode block undo. There are some similar odd effects with changes to styles and the hiding/showing of 'hidden' text
So, the behaviour is a bit inconsistent. But does it matter? For 99% of the time undo works, this is better than systems where undo was either absent or frequently didn't work. Or is it? If undo works almost all the time, then users may become used to it. Indeed, one of the advantages of having undo is that users can take a more exploratory approach to their interaction, trying out possible courses of action, but then retracing their steps if it doesn't work. That is they become more risky in their behaviour. But if they become more risky then they are more likely to do things that need undo, and if undo doesn't uniformly work then they will have problems which would never have occurred if they had been more careful.
So although a 99% effective undo may not be overall less good than no undo at all, there will be errors that occur when you have undo which would not have happened if you had never had undo at all.
Happily, the problems in the previous version have been corrected in Word 6. Switches to and from outline mode no longer 'block' undo. Furthermore Word 6 allows up to 100 steps of undo. Probably the two are not unconnected, the benefit of multi-step undo would be seriously compromised if the history were effectively cut off every time you changed to outline mode!
Figure 2. Menu for multi-step undo in Word 6
So, this is good news - now you can make a whole series of big mistakes and have confidence that you can undo them all! The risks associated with mistakes have been reduced still further. Or have they?
Let's look at how the multi-step undo works at the interface. Word 6 keeps two lists, one a history list of up to the last 100 commands, the other a redo list (note 1) of the commands that have just been undone. As you undo a command the last command is moved from the history list to the redo list and the state of the document is moved back to the previous state. Redo does the opposite. In addition you can pull down a menu of the history or redo list and directly select the command you want to undo or redo to. Of course, a menu of 100 commands is too long to fit on most (!) screens, and so the menu is a scrolling one.
If you are undoing a long way it may be difficult to remember exactly which command represents the state of the system you wish to recover. You really need to examine the state and see if it is the one you want. For this reason, Word 6 allows you to freely scroll and perform other passive actions on the document while you are in the middle of an undo/redo cycle.
So long as you do nothing else but undo and redo, the system behaves rather like a 'current state' cursor moving back and forwards through the history. As we noted passive actions do not interfere with this. However, as soon as you perform any active command you effectively create a 'branch' in the history of commands. From a past state there are now two 'next states', the one you originally got to, and the one resulting from your new command. Some systems directly support such a branched history (Berlage 1994). However, the complexity of representing this at the user interface (as well as the cost of implementing it) is high.
Figure 3. Phases of normal and undo activity
Figure 4. Phases as a state transition network
Rather than attempting to represent a branching history in the user interface, Word 6 adopts a simpler approach: it commits the undo/redo sub-dialogue after any active command. That is, the redo list is chopped off and redo is no longer possible. This means you can regard the dialogue as a number of phases: 'ordinary' phases consisting of a mixture of active (a) and passive (p) commands and 'undo' phases consisting of a mixture of passive, undo (u) and redo (r) commands (figs 3 & 4). The transition between these phases is implicit, triggered by the first undo or active action.
Now, consider another scenario. You have been editing a new document for some time, then discover that you have done something wrong. You reach for the undo menu. You're not sure quite how far to back-up to and so start to scroll the menu down, the commands whirl past and when you release the mouse you realise you haven undone right back to the beginning, a blank screen! No problem, you can simply redo the command. So you reach for the redo button ... but as you do so, your hand accidentally touches the space-bar - oops!
So, let's recap. Undo is needed because a small action can cause a lot of damage. That is because the interface is risky. Undo reduces this risk. But users may respond to it with more risky behaviour, and so if undo does not work 100% of the time, non-undoable errors may occur which wouldn't have happened if there had never been an undo. The undo mechanism in Word 6 was comprehensive and furthermore allowed multi-step undo. However, we saw that a small slip during and undo/redo phase can lead to the irrevocable loss of up to the last 100 commands. Very risky indeed! Furthermore, the more undo steps you allow, the more risk.
One resolution to this is to recognise that multi-step undo is risky and so, following the general principle of confirmation before commitment, one should ask for explicit confirmation as with other dangerous actions, such as saving. This could take the form of a dialogue box after 'big' undos, or an explicit 'this is it' button. Of course, if one chose the latter option the button would have to be positioned to make it difficult to press by accident!
1. This 'redo list' is called the 'pending script' in the Archer, Conway Schneider model (Archer, Conway et al. 1984).