Redo

Problem Context

• The product supports reversible editing, ordering, formatting, drawing, document, layout, or configuration actions.
• Users can issue repeated undo commands and may need to recover from undoing one step too many.
• The system can store enough operation and target state to replay the undone action accurately.
• New edits after undo create a divergent state unless the product has an explicit branching history model.

Selection Rules

• Choose redo when the user has just undone a reversible operation and may need to reapply it.
• Expose redo next to undo in editor toolbars, menus, command palettes, or keyboard help when editing workflows are central.
• Disable or hide redo when no undone operation exists, but keep the availability discoverable in command-rich desktop-style products.
• Clear the redo stack when the user makes a new edit after undo unless the product provides explicit branch history.
• Replay the latest undone action in last-in-first-out order and preserve target identity, ordering, selection, and scope.
• Use a history panel, revision history, restore from trash, or draft state when users need long-lived recovery across sessions rather than immediate redo.
• Do not offer redo for operations whose external effects, permissions, payments, emails, or webhooks cannot be safely replayed or recalled.
• Do not make keyboard shortcuts the only redo path in interfaces that also support mouse, touch, or assistive technology workflows.

Required States

• No-redo state before any undo has happened.
• Undo-available state after a reversible edit.
• Redo-available state after the user undoes an operation.
• Redone state after the latest undone operation is reapplied.
• Branch-cleared state after a new edit while redo was available.
• Multi-step redo state where repeated Redo replays the redo stack in order.
• Target-invalid state when the original object, selection, or collaborator context can no longer accept replay.

Interaction Contract

• Redo is unavailable until an undo places an operation on the redo stack.
• Activating Redo replays the most recent undone operation and returns that operation to the undo stack.
• The command label, tooltip, menu item, status row, or history panel identifies the operation when ambiguity is possible.
• A new edit after undo clears redo or creates an explicit branch that users can see and choose.
• Keyboard shortcuts, toolbar controls, menus, and command palette entries reflect the same enabled or disabled state.
• If the original target is deleted, locked, changed by another user, or otherwise invalid, Redo explains why replay is unavailable.
• Redo does not silently repeat unrelated commands or destructive external effects.

Implementation Checklist

• Represent undo and redo as separate stacks or equivalent operation history with target identity and scope.
• Push operations from undo to redo only after a successful undo, and push them back to undo after successful redo.
• Clear redo on new edits unless the product intentionally supports visible history branches.
• Keep visible controls, menu labels, command palette rows, shortcut help, and disabled states synchronized with the stack.
• Store enough object, ordering, selection, and collaborator context to reject stale redo rather than applying it to the wrong target.
• Announce redo availability, redone outcomes, cleared branch state, and invalid replay states in a status region.
• Test repeated undo and redo, target deletion, route changes, collaboration updates, keyboard shortcuts, and disabled states.

Common Generated-UI Mistakes

• Leaving redo enabled after a new edit invalidates the undone future.
• Applying redo to the current selection instead of the original operation target.
• Treating redo as persistent restore or version rollback without showing durable history.
• Hiding redo behind a shortcut with no visible command state.
• Using Redo to mean repeat last command even when users expect reapply undone change.
• Offering redo for external side effects that cannot be safely replayed.

Critique Questions

• What operation enters the redo stack when the user undoes this action?
• What exact event clears redo, and how does the interface tell users that the branch changed?
• Can Redo identify the original target if selection, ordering, permissions, or collaboration state changed?
• Do visible controls and keyboard shortcuts expose the same availability?
• Does Redo reapply an undone action, or is it actually repeat last command, restore from trash, or version rollback?