Multi-step undo follows last-in, first-out

What it is

After several steps, undo should unwrap the last step first, then the one before. That is last-in, first-out. If undo skips the recent step to touch an earlier one, or folds several steps into one, the model of “where the world is now” collapses. This entry is about order across consecutive acts. It is not about how many seconds remain in one window, and not about whether items inside one batch undo as a whole or in parts.

Why it happens

Consecutive acts sit on a timeline in working memory: the last is the clearest, and the one most often regretted. LIFO makes each undo correspond to the nearest node on that timeline, so the result is predictable. Breaking the order digs a hole in the middle of the timeline; later steps lose their premises, and interface state cannot be described as “how many times I undid.” Folding several steps into one “undo all” over-kills when the person only wanted the last stroke reversed. The stack also has to be intelligible: the undo name should be the step just taken (“Undo delete heading”), not a nameless “Undo.”

Studying it

Have people take three reversible steps, then ask them to change only the last, or to return to the first. Compare LIFO, click-any-step, and clearing all three at once.

Independent variables: stack order, whether each step is named, whether skip-ahead undo is allowed. Dependent variables: steps to the target state, whether intermediate steps are collateral, whether they can later restate “which edits remain.”

Experts will want skip-ahead; that is a history list, not the immediate stack this entry discusses. When measuring the immediate stack, do not offer a full history panel, or the study measures history.

Where it stops holding

In collaboration, someone else’s steps interleave with yours; LIFO on “my stack” versus global time conflicts, and the surface must say whose most recent step is being undone. Some editors use tree-shaped undo (a new act after undo forks a branch); the immediate button should still take the nearest node on the current branch. An irreversible step cuts the stack: later undos cannot pretend to walk through that cut.

Applying it

• Push consecutive reversible acts onto one stack; the undo button’s label names the step on top.
• Repeated undo walks backward in time; do not clear the whole stretch at once unless the person explicitly chooses “revert to this checkpoint.”
• A new forward act after undo enters the stack; the undone step is no longer the top.
• Verify by doing A, B, then C, and pressing undo once. If C is still there and A or B is gone, the order is not last-in, first-out.

Related

• Within the group: H3.12.1 The undo window needs a visible countdown · H3.12.2 Batch undo must say whether it is all-or-nothing · H3.12.4 When the window closes, irreversibility must be explicit
• Adjacent: H8.06 Version history · C6.16 Undo in text input · H3.04 Undo over confirm
• Search terms: undo stack · LIFO · command history