Autosave versions and explicit saves need distinct marks

What it is

Snapshots in history come from two sources. Autosave drops on a timer or a keystroke: dense, weak intent. Explicit save is someone tapping save, publish, or “save as version”: sparse, strong intent. The list must split them at a glance—icon, Auto versus You saved, a writable title—or people treat ten autosaves as ten milestones, or cannot find the version they just stored. This is not how fine the diff is, and not how a long list is folded. Whether draft autosave shows a status is a forms issue. Here it is identity in the history list.

Why it happens

Autosave exists to prevent loss, not to erect a monument. People remember “the version before I sent it to the client,” “the moment I hit save.” Mixed into one row of timestamps, memory cannot land: autosaves crowd explicit ones off the first screen, or an autosave is mistaken for a publish. Marks write intent back into the list: browse can filter autosaves out; compare can use explicit points as anchors. Autosaves must still open, because crash recovery may live in one of them; they simply carry less default weight. If explicit save cannot be named, people still will not recognize it later, and the mark is only half done. An autosave that failed but still draws an empty row makes people think that minute already entered history.

Studying it

An editing stretch with many autosaves and two explicit saves. Ask people to retrieve “the version you saved” and “the last minute before the crash.” Compare no distinction, autosaves down-weighted, explicit saves nameable.

Independent variables: whether the two kinds are marked, whether autosaves can be filtered, whether explicit save can take a title. Dependent variables: time to the explicit point, autosave mistaken for publish, inability to open a recent autosave for recovery.

If the lab pauses on every autosave to inspect the list, you are measuring a checklist, not later recognition. Reopen history after a gap. Do not mix in retention—both kinds are still there.

Where it stops holding

A product with only manual checkpoints need not draw an Auto class. A document that syncs every key without independent snapshots may have only named versions in history, with loss-prevention on another draft channel. When compliance requires every change equally on the record, the two kinds should still split visually, but autosaves cannot be made unauditable. Someone else’s autosave must not look like “you saved.”

Applying it

• Explicit saves get a solid mark and an optional title. Autosaves get a gray Auto mark and collapse by default.
• Offer a “only what I saved” filter; expand autosaves when recovering from a crash.
• Do not write empty rows for failed autosaves. Successful ones must be recent enough to recover the last minute.
• Verify: people can point at the row they explicitly saved without opening every autosave. Simulate a crash; the latest autosave still opens and is marked Auto.

Related

• Within the group: H8.11.1 Rollback must account for unsynced collaborator edits · H8.11.2 Diffs must show the actual change, not a whole-block swap · H8.11.4 Overgrown history needs a merge policy so the list stays readable
• Adjacent: H8.06 Version History · H1.08 Draft Autosave · I4.02 Autosave Frequency
• Search terms: named version · autosave revision · checkpoint