Undo

"Redo" redirects here. Not to be confused with Do over (disambiguation).

For how to "undo" an edit in Wikipedia, see Wikipedia:Undo.For other uses, see Undo (disambiguation).

Undo is an interaction technique which is implemented in many computer programs. It erases the last change done to the document, reverting it to an older state. In some more advanced programs, such as graphic processing, undo will negate the last command done to the file being edited. With the possibility of undo, users can explore and work without fear of making mistakes, because they can easily be undone.

The expectations for undo are easy to understand: to have a predictable functionality, and to include all "undoable" commands. ^[1] Usually undo is available until the user undoes all executed operations. But there are some actions which are not stored in the undo list, and thus they cannot be undone. For example, save file is not undoable, but is queued in the list to show that it was executed. Another action which is usually not stored, and thus not undoable, is scrolling or selection. ^[2]

The opposite of undo is redo. The redo command reverses the undo or advances the buffer to a more recent state.

The common components of undo functionality are the commands which were executed of the user, the history buffer(s) which stores the completed actions, the undo/redo manager for controlling the history buffer, and the user interface for interacting with the user. ^[3]

In most Microsoft Windows applications, the keyboard shortcut for the undo command is Ctrl+Z or Alt+Backspace, and the shortcut for redo is Ctrl+Y or Ctrl+Shift+Z.

In most Apple Macintosh applications, the shortcut for the undo command is Command-Z, and the shortcut for redo is Command-Shift-Z.

On all platforms, the undo/redo functions can also be accessed via the Edit menu.

History

The ability to undo an operation on a computer was independently invented multiple times, in response to how people used computers. ^[4]

The File Retrieval and Editing System, developed starting in 1968 at Brown University, is reported to be the first computer-based system to have had an "undo" feature. ^{[5] [6]}

Warren Teitelman developed a Programmer's Assistant as part of BBN-LISP with an Undo function, by 1971. ^[7]

The Xerox PARC Bravo text editor had an Undo command in 1974. ^[8] A 1976 research report by Lance A. Miller and John C. Thomas of IBM, Behavioral Issues in the Use of Interactive Systems, ^[9] noted that "it would be quite useful to permit users to 'take back' at least the immediately preceding command (by issuing some special 'undo' command)." ^[10] The programmers at the Xerox PARC research center assigned the keyboard shortcut Ctrl-Z to the undo command, which became a crucial feature of text editors and word processors in the personal computer era. ^[11] In 1980, Larry Tesler of Xerox PARC began working at Apple Computer. There, he and Bill Atkinson advocated for the presence of an undo command as a standard fixture on the Apple Lisa. Atkinson was able to convince the individual developers of the Lisa's application software to include a single level of undo and redo, but was unsuccessful in lobbying for multiple levels.^{[ citation needed ]} When Apple introduced the Lisa's successor, the Macintosh, it stipulated that all standard applications should include an “Undo” as the first command in the “Edit” menu, ^[12] which has remained the standard on macOS and Windows to this day.

Multi-level undo commands were introduced in the 1980s, allowing the users to take back a series of actions, not just the most recent one. ^[11] EMACS and other timeshared screen editors had it before personal computer software. CygnusEd was the first Amiga text editor with an unlimited undo/redo feature. AtariWriter, a word-processing application introduced in 1982, featured undo. NewWord, another word-processing program released by NewStar in 1984, had an unerase command. ^[11] IBM's VisiWord also had an undelete command.

Undo and redo models

Undo models can be categorized as linear or non-linear. The non-linear undo model can be sub-classified in script model, us&r model, triadic model, and selective undo. ^[1]

Some common properties of models are:

• stable execution property: A state is represented as an ordered list of commands. This means that a command "is always undone in the state that was reached after the original execution." ^[3]
• weakened stable execution: This means that if undo is executed all commands which depend on the undone command are undone dependent on the command.
• stable result property: This property has the similar meaning like the stable execution property except for the list. The ordered list of commands includes that they were executed instead of only the commands.
• commutative: That means that the reached state after undo and redo two different commands is the same when they are executed in the converse order.
• minimalistic undo property: It describes that "undo operation of command C undoes only command C and all commands younger than C which are dependent on C." ^[3]

Linear undo

Linear undo is implemented with a stack (last in first out (LIFO) data structure) that stores a history of all executed commands. When a new command is executed it is added to the top of stack. Therefore, only the last executed command can be undone and removed from the history. Undo can be repeated as long as the history is not empty. ^[1]

Restricted linear model

The restricted linear model is an augmentation of the linear undo model. It satisfies the above described stable execution property for linear undo, because this model does not keep the property if a command is done while the history list includes other commands. The restricted linear model clears the history list before a new command is added. But other restrictions are available, too. For example, the size of the history list can be restricted or when a defined size is reached, the first executed command is deleted from the list. ^[1]

Non-linear undo

The main difference between linear undo and non-linear undo is the possibility of the user to undo the executed commands in an arbitrary order. They have the chance to undo not the most recently command but rather choose a command from the list. ^[3] For non linear model there are subclasses which implement this model.

Script model

The script model handles user actions as editing a script of commands. The history list of the executed commands are interpreted "as a script, the effect of an undo is defined to be the same as if the undone action had never occurred in the first place." ^[1] As the result of undo the state has to be the way as if the undone command was never executed. A disadvantage of this model is that the user has to know the connection between undone command and the current state to avoid side effects. One of this can be for example duplication. Other problems are that if "subsequent commands are redone in a different state that they were originally executed in direct manipulation interfaces, this reinterpretation of the original user action is not always obvious or well defined". ^[1]

US&R model

The special feature of this model is that it has the option of skipping a command. This means that redoing a command can be skipped. The command which is skipped is marked as skipped but not deleted. When new commands are executed, the history list is retained, so the order of the executed commands can be reproducible with that. The order can be described through a history tree which is a directed graph, "because it is possible to continue redoing commands from another branch creating a link in the graph". ^[1] Even though the set of commands is simple and easy to understand, the complex structure with skipping and linking branches is hard to comprehend and to remember, when the user wants to undo more than one step. ^[1]

Triadic model

This non-linear undo model has besides undo and redo the possibility to rotate. It has the same data structure as the above-mentioned models with a history list and a separated redo list which includes the redo operations. The rotate operation sets the last command of the redo list in front of it. On one hand this means that the next command to be redone can be selected by placing it in front. On the other hand, rotation can be used "to select the place in the redo list where the next undo operation will put the command". ^[1] The list of redo is therefore unordered. "To undo an isolated command, the user has to undo a number of steps, rotate the redo list, and then redo a number of steps". ^[1] For redo the list has to be rotated until the wanted command is above.

Selective undo

Jakubec et al. say that selective undo is a feature which a model can offer but for selective undo there is no clear definition. ^[3] The authors selected functions which a model should have when it supports selective undo. It should be possible to "undo any executed action in the history buffer. Actions independent of the action being undone should be left untouched". ^[3] Just like that redo has to be possible to any undone command. The third function for selective undo is that "no command can be automatically discarded from history buffer without direct user’s request." ^[3] For selective undo applies that undo and redo is executable outside of any context. There are three main issues. The first is that undone commands can be outside of the originally context. Through this there can be dead references which have to be handled. The second issue that modified commands can be undone and so it has to be solved which state after undo will be presented. The third issue is discarding command problems. Selective undo has no pointer in the lists, so this means that no command should be discarded of the stack. ^[3]

Direct selective undo

Direct selective undo is an extension of restricted linear undo with a history tree. The operation creates a copy of the selected command, executes this and add it to the history list. There two non-linear operations selective undo and selective redo are defined, so it is more symmetric. ^[1]

Multiuser application

When multiple users can edit the same document simultaneously, a multi-user undo is needed. Global multi-user undo reverts the latest action made to the document, regardless of who performed the edit. Local multi-user undo only reverts actions done by the local user, which requires a non-linear undo implementation.

Where undo can be used to backtrack through multiple edits, the redo command goes forward through the action history. Making a new edit usually clears the redo list. If a branching redo model is used, the new edit branches the action history.

The number of previous actions that can be undone varies by program, version, and hardware or software capabilities. For example, the default undo/redo stack size in Adobe Photoshop is 20 but can be changed by the user. As another example, earlier^{[ when? ]} versions of Microsoft Paint only allowed up to three edits to be undone; the version introduced in Windows 7 increased this limit to 50.

Simplistic, single-edit undo features sometimes do away with "redo" by treating the undo command itself as an action that can be undone. This is known as the flip undo model, because the user can flip between two program states using the undo command. ^[13] This was the standard model prior to the widespread adoption of multiple-level undo in the early 1990s.

Undo implementation

Undo can be implemented through different patterns. The most common patterns are command pattern and memento pattern.

Command pattern

The command pattern is a software design pattern which encapsulates information from the operation into command objects. This means that every action is stored in an object. The abstract command class implements an abstract execute operation, so every command object has an execute operation. For undo there also have to be unexecuted operation, which undoes the effect of the executed command, which are stored in a history list. Undo and redo are implemented so that the list is run through forwards and backwards when the execute or unexecute command is called. ^[14]

For single undo only the executed command is stored. In contrast to the multi level undo where not only the history list with the commands is saved but also the number of undo levels can be determined of the maximum length of the list. ^[14]

Memento pattern

With memento pattern the internal state of an object is stored. The object in which the state is saved, is called memento and is organized through the memento originator. This returns a memento, initialized with information of the current state, when undo is executed, so that the state can be checked. The memento is only visible for the originator.

In memento pattern the undo mechanism is called caretaker. It is responsible for the safekeeping of the mementos but never change the contents of these. For undo the caretaker requests a memento of the originator and then applying the undo. ^[14]

The most part of undo mechanism can implemented without dependency to specific applications or command classes. This includes "the management of history list, the history scroller, menu entries for undo and redo and update of the menu entries depending on the name of the next available command." ^[1]

Every command class has a do method which is called when a command is executed. The undo-method implements the reverse operation of the do-method. To implement the reverse, there are several different strategies.

• full checkpoint: That means that the complete state is saved after a command is executed. This is the easiest implementation, but is not highly efficient and therefore not often used.
• complete rerun: Therefore, the initial state is saved and every state in the history list can be reached through "starting with the initial state and redoing all commands from the beginning of the history." ^[1]
• partial checkpoint: This is the most used strategy. The changed application state is saved and with undo the part of the state is set back to the forward value.
• inverse function: Inverse function needs no saved state information. "For example, moving can be reversed by moving the object back by relative amount." ^[1] For selective undo there is not enough information for saving the state.

See also

• Reversible computing
• Rollback (data management)
• Undeletion
• Version control (native file format)

References

1. Berlage, Thomas (1994-09-01). "A selective undo mechanism for graphical user interfaces based on command objects". ACM Transactions on Computer-Human Interaction. 1 (3): 269–294. doi:10.1145/196699.196721. ISSN   1073-0516. S2CID   11848679.
2. Myers, Brad A.; Kosbie, David S. (1996-04-13). "Reusable hierarchical command objects". Proceedings of the SIGCHI conference on Human factors in computing systems common ground - CHI '96. ACM. pp.  260–267. doi:10.1145/238386.238526. ISBN   0897917774. S2CID   17033810.
3. Jakubec, Karel; Polák, Marek; Nečaský, Martin; Holubová, Irena (2014). "Undo/Redo Operations in Complex Environments". Procedia Computer Science. 32: 561–570. doi: 10.1016/j.procs.2014.05.461 . ISSN   1877-0509.
4. Moran, Chuktropolis Welling (2013-01-01). Interactive Time (Ph.D.). La Jolla: University of California, San Diego. ISBN   9781303194450. Archived from the original on 2021-04-28. Retrieved 2016-07-07.
5. Barnet, Belinda (2014-12-01). Memory Machines: The Evolution of Hypertext. Anthem Press. p. 108. ISBN   9781783083442. But the most popular development for novice users in FRESS was not its capacity to accommodate multiple displays and users; it was the 'undo' feature – the feature of which van Dam is most proud (van Dam 2011). FRESS pioneered a single-level undo for both word processing and hypertext. Every edit to a file was saved in a shadow version of the data structure, which allowed for both an 'autosave' and an undo. Brown staff and students understood immediately the importance and usefulness of this feature (van Dam 1999).
6. Barnet, Belinda (2010-01-01). "Crafting the User-Centered Document Interface: The Hypertext Editing System (HES) and the File Retrieval and Editing System (FRESS)". Digital Humanities Quarterly. 4 (1). Archived from the original on 2021-05-01. Retrieved 2016-05-27.
7. Teitelman, Warren (1972-01-01). "Automated programmering: The programmer's assistant". Proceedings of the December 5-7, 1972, fall joint computer conference, Part II on - AFIPS '72 (Fall, part II). New York, NY, USA: ACM. pp. 917–921. doi:10.1145/1480083.1480119. S2CID   1276566.
8. "Bravo Manual in Alto Non-Programmers Guide, p. 52" (PDF). Archived (PDF) from the original on 2015-05-05. Retrieved 2014-03-29.
9. Miller, Lance A.; Thomas, John C. (1977-09-01). "Behavioral issues in the use of interactive systems". International Journal of Man-Machine Studies. 9 (5): 509–536. doi:10.1016/S0020-7373(77)80002-3. ISSN   0020-7373.
10. Miller, Lance A.; John C. Thomas Jr. (December 1976). "Behavioral Issues in the Use of Interactive Systems". Archived from the original (PDF) on May 27, 2012. Retrieved 2011-05-21.
11. Ben Zimmer (2009-09-15). "The Age of Undoing". New York Times. Archived from the original on 2013-06-17. Retrieved 2013-06-02.
12. Apple Computer, Inc. (1984). "User Interface". Inside Macintosh, Volume I.
13. Roberta Mancini, Alan Dix and Stefano Levialdi. 2006. "Reflections on Undo"
14. Design patterns : elements of reusable object-oriented software . Gamma, Erich. Reading, Mass.: Addison-Wesley. 1995. ISBN   0201633612. OCLC   31171684.

External links

• The Age of Undoing - Article about the linguistic history of Undo at The New York Times Magazine.
• Cascading undo control - a paper focused on what is cascading undo and how it might be presented to users