Abstract

Undo is among the most fundamental affordances in interactive computing: a reversibility guarantee that lets users explore actions without permanent commitment. In single-user applications, undo is a well-understood sequential stack. In collaborative real-time editing environments, the model breaks down. When multiple authors edit concurrently, a single user’s undo stack intersects with changes made by others, and naive stack reversal corrupts the shared document state. The operational transformation and CRDT (conflict-free replicated data type) literature has addressed the algebraic question of how to merge concurrent edits; the HCI question of how to present undo semantics to users in a way that is comprehensible and trustworthy has received less systematic attention.

Why Linear Undo Fails in Collaborative Contexts

In a single-user text editor, Ctrl+Z walks backward through a linear history: the last action is undone, then the second-to-last, and so on. The model is simple because history is globally ordered and causally linear. In a collaborative editor where two authors are editing simultaneously, each user’s action history is a partial order, not a total order. User A’s edits are interleaved with User B’s in wall-clock time, but A cannot undo B’s changes, and B’s subsequent edits may have built on A’s text in ways that make A’s undo semantically ambiguous.

Google Docs handles this by restricting undo to the current user’s own actions in the server-canonical ordering, skipping over interleaved changes by others. This is operationally correct but produces visible weirdness: undoing “your last change” may visually jump over many other changes that happened in the meantime, making the undo result hard to predict. Notion’s collaborative editor and Figma’s multiplayer mode use similar approaches with minor variations in how they present the undo history to users.

Selective and Scoped Undo Models

Research on collaborative undo has proposed alternatives to the per-user sequential model. Selective undo, developed theoretically by Prakash and Knister in the 1990s and revisited in more recent CSCW work, allows a user to undo any specific past action regardless of its position in the history, with the system computing what the document state would look like without that action. This requires solving a non-trivial algebraic inverse problem and can produce results that are hard to predict from the user’s perspective.

A more tractable approach is scoped undo, where undo boundaries are defined by semantic units (a paragraph, a table, a named section) rather than individual actions. Users undo within a scope, and changes outside that scope are preserved. This matches how people mentally model document editing more closely than per-keystroke undo. Quill, an open-source rich text editor used as a base by several collaborative platforms, has been extended with scope-based history management in research prototypes, though production implementations remain rare.

A third model, version snapshot undo, exposes named checkpoints that users can explicitly create and revert to. Git’s branching model applied to document editing. Dropbox Paper and Notion both expose coarse-grained version history, but the granularity is typically too coarse for within-session reversal and the interface is presented as a version browser rather than an undo control, which affects user mental model and usage frequency.

Presenting Undo State to Users

The interface for communicating undo state in collaborative contexts is underdeveloped. Most collaborative editors show either no undo history visualization or a flat chronological list that mixes all users’ actions without clearly indicating which are undoable by the current user or what their effect would be. A 2025 CHI paper from researchers at the University of Michigan’s School of Information studied how users form expectations about undo behavior in collaborative editors and found that 68 percent of participants held incorrect mental models of what would be affected by Ctrl+Z in a Google Docs session, and that incorrect expectations were associated with reluctance to make exploratory edits.

The paper proposed a hover-preview affordance: holding Ctrl before pressing Z displays a visual diff of what would be undone, highlighted in the document, before the action is committed. A simple mechanism, but it directly addresses the expectation mismatch. Implementing hover-preview requires that the undo computation be fast enough to run on keydown without introducing latency, which is feasible for document editors using CRDT-based conflict resolution.

Design Principles for Trustworthy Collaborative Undo

Three principles emerge from the research. First, undo scope should be legible before the action - users should be able to see what will change before committing. Second, per-user history should be visually distinguished from shared history in any history interface. Third, destructive undo operations (those that would remove content another user created) should require explicit confirmation rather than executing on a single keystroke. Collaborative editing environments that implement these principles create the conditions for users to treat the document as an exploratory workspace rather than a fragile shared artifact where every action carries irreversibility risk.