Restoring an old version must itself be undoable
Aliases: undo revert · restore undo · recoverable restore
What it is
Making a historical snapshot into the live document is restore. Restore overwrites the draft in use. If that step cannot be walked back, history turns from a comparable past into a one-shot gamble. Restore itself must be undoable means the overwritten version still exists, and people can return to the pre-restore state at once, rather than hunting the list by luck. This is not how the list is browsed or compared, and not how many days snapshots live. What to do with collaborators’ still-unsynced edits is a rollback mechanic, not “can I take back the restore I just tapped.”
Why it happens
Choosing which snapshot to restore is done under incomplete information: a timestamp and a summary, not every field. The wrong row, too early, the wrong author, and a good live draft becomes an old one. If restore is an irreversible overwrite, the cost is close to wiping the library, and people will not use history. Undo lowers restore to a reversible act: the live draft is captured as a new history row instead of destroyed. The window has to last long enough to notice “this is not the one”—open it, see a field gone, walk back. If undo exists only as a keyboard shortcut with no on-screen entry, it is irreversible for some people. A confirm that still cannot be undone only moves anxiety earlier; it does not lower the consequence.
Studying it
Have people restore to a named old version, then discover the choice was wrong (a key field missing), and see whether they can return to the pre-restore draft. Compare irreversible restore, a short toast undo, and restore that writes a new history row and can restore again to the previous live state.
Independent variables: whether the overwritten draft becomes a snapshot automatically, where undo lives and how long the window is, whether confirm is forced before restore. Dependent variables: recovery after a wrong restore, rate of refusing to use restore, habitual confirms.
Lab participants know this is a restore task and become unusually careful. Nest restore inside a repair job, and plant a snapshot whose summary looks right and whose body is not. Do not mix with undo-of-delete—the object differs.
Where it stops holding
Records that law forbids tampering may ban restore; history is then read-only and undo-of-restore does not apply. Restoring a empty or corrupt snapshot must still undo to the intact pre-restore draft, not restore the damage again. When several people are live, your undo must not silently erase sentences they wrote after your restore—that is a collaborative rollback boundary; a solo local draft may rewind as a whole. If autosave writes another snapshot inside the undo window, “undo the restore” and “undo that autosave” must not share one unlabeled stack.
Applying it
- On restore, write the live draft as a new history row, then copy the old snapshot into current. Offer “undo that restore” on the surface, not only a confirm dialog.
- Put the undo entry on the screen where restore just happened. The window is measured in minutes; after it ends, the overwritten row is still in history.
- Do not replace undoable restore with irreversible confirm. If confirm remains, the copy must say the live draft will stay in history.
- Verify: restore the wrong version, then get the previous draft back immediately. If the only method is remembering a timestamp in the list, or the live draft is gone, restore is not undoable. Watch whether people refuse restore for fear of a wrong tap.