History must be browsable and comparable

What it is

Once content has changed, past states that can still be opened make version history. Browsable means a time-ordered list of snapshots, with who left each and when. Comparable means two of them can be shown together so the difference is visible, not two isolated full texts. This is whether the past still exists and can be checked against. Swapping the live document for a snapshot (and whether that swap itself undoes), and how long snapshots are kept, sit beside it in the group. Handling unsynced collaborator edits on rollback, how fine a diff is, marks for autosave versus explicit save, and compacting a long list belong to rollback mechanics.

Why it happens

People remember “the version that still worked yesterday,” not a number. History that can only be downloaded by ID cannot be matched to that memory. A list without comparison forces them to alternate two full texts; working memory will not hold the difference in a long piece, so restore becomes a guess from timestamps. Comparison compresses two states into a visible delta: added, removed, by whom. Without author and time, snapshots are meaningless filenames. Browse also needs a stable entry: “Versions” three levels down a file menu is, for most people, no history. In collaboration, history answers “who broke this”; failed comparison turns into blame instead of looking at the text.

Studying it

On a document several people have changed, ask someone to find “the edit that changed the due date” and state how it differs from now. Compare list-only, open-one-at-a-time, and side-by-side with highlights.

Independent variables: author and time on each row, whether comparison shows a delta or only tab switching, where the entry lives. Dependent variables: time to the right version, completeness of the difference description, opening the live draft by mistake.

Short lab documents let people scan the whole text. Use material longer than a screen, with scattered edits. Opening the history pane is not success. Exclude live conflicts (two people changing one sentence at once) so the task does not become a collaboration-conflict test.

Where it stops holding

Immutable issued records (invoices, signed contracts) should not offer a restore that rewrites legal effect; a read-only audit log is enough. Tiny one-shot fields (a toggle, a tag) are clearer as an action log than as full-document versions. A local unsynced draft is not a history row yet; mixing it with saved versions makes people think it has landed. Viewers without edit permission may browse and compare, but must not write a new version from the comparison view.

Applying it

• Put a History entry beside the content. Each row has time, author, a one-line summary; opening it shows that snapshot.
• Any two rows can be compared with insert/delete marks, not two tabs to stare at.
• Comparison can return to the live draft; the live draft is labeled in the list so an old snapshot is not mistaken for the one being edited.
• Verify: change a key field and something else in the body. Someone who did not watch the process should use history to find that field change and name the delta. If they can only do it by reading two full texts, comparison is not yet usable.

Related

• Within the group: H8.06.2 Restoring an old version must itself be undoable · H8.06.3 Retention policy must be stated
• Adjacent: H8.11 Version History and Rollback · H8.07 Collaborative Edit Conflicts · V4.04 Versions, Changesets, and Diffs
• Search terms: version history · revision comparison · document snapshot