Save status must be visible
Aliases: save status · last saved · autosave indicator
What it is
If autosave only happens in the background, people cannot tell whether closing now will lose work. Visible save status means the interface keeps saying which beat the draft is on: writing, written at what time, failed. It is not a success toast that vanishes. It is state that can be read again while the task is still open. This entry assumes a draft is already being written and only asks whether that state must show. It is not whether long forms should save, and not which fields must stay out of the draft.
Why it happens
Without external evidence, people decide with “I think I clicked save” or “I dare not close.” Autosave moves the decision from “I click” to “the system clicks.” If the system shows no evidence, the decision becomes a guess. A second layer is that three states do not mean the same thing. “Saving” forbids leaving or refreshing on this beat (the write has not settled). “Saved · 14:32” permits leaving. “Save failed” forbids closing and offers a retry. One sentence, “Saved,” covering failure, makes people leave during failure. Status also has to survive scroll: if it only lives at the top of the page and disappears on scroll, it is invisible on the lower half of a long form. A timestamp is more checkable than the word “Saved”—people can compare it with their last edit and notice “I just changed this but the time did not move,” which means the write did not happen.
Studying it
Have people on an autosaving form decide whether they can close now. Compare no indicator, a brief toast only, a persistent timestamp, and failure still showing Saved.
Independent variables: status form (none / toast / persistent timestamp), whether failure has its own presentation, whether status stays fixed while scrolling. Dependent variables: leaves during “Saving,” closes during failure, ability to name the last saved time, noticing “I just edited but status did not move.”
The lab will not actually lose data, so risk feels weak. In the failure condition, actually drop an unsaved edit, or you will not see whether visible status changed the leave decision. A small checkmark is not a timestamp—a check has no checkable moment.
Where it stops holding
When the save interval is under a second, “Saving” will flicker; collapse it to a quiet “Saved” and change only on failure. Read-only review has no draft being written; status should vanish or become “Read-only,” not pretend another write is coming. On multi-editor forms, “Saved” must say whose version, or visible status hides conflict. Offline, show “will save when back online”; do not keep showing a success time that is going stale.
Applying it
- Put status on the form that does not scroll away with the body: saving, saved plus a local time, failed plus retry.
- Failure must not keep showing the last success sentence. If the timestamp does not move after an edit, treat it as failure and say so, rather than leaving the old success up.
- A toast may supplement; it cannot be the only status. People looking up from the lower half of a long form must still see the current beat.
- Verify by editing a field and checking the timestamp updates inside the promised interval. Disconnect, edit again, and confirm it becomes “Failed” or “will save when online,” not the old time. Make status a two-second toast only, scroll to the end, and ask whether it saved; no answer is failure.