Long forms need autosave
Aliases: form autosave · draft save · unsubmitted persistence
What it is
Filling a long form spans minutes to days, with app switches, calls, refreshes, and killed processes in between. Autosave writes values that have not been submitted yet, on a timer or on change, into a recoverable draft so coming back does not mean starting at field one. A short sign-in does not need this layer; applications, tax, medical history, and multi-step checkout do. This entry is only about whether a long form should keep unsubmitted values. It is not about whether the save beat needs a visible “Saved,” and not about whether passwords and ID numbers belong in the draft. Whether crash recovery should ask before overwriting belongs to another family.
Why it happens
A filling session outlives a page session. The browser treats a refresh as a new document; the OS treats a memory reclaim as a dead process. If the form lives only in RAM, work zeros at those boundaries. Autosave moves values from “this page” to “this task.” A second layer is that interruptions cannot be scheduled. A call, an SMS code, fetching an ID from email—all are legitimate leaves inside the task. Without a draft, the cost of leaving equals time already spent, and people abandon the whole form at the item that required the leave. Save granularity must cover the natural cut “finish this field, go look something up,” not only a write on “Next”—Next often is never reached. A local draft survives refresh, not a device change. A server draft survives a device change if the person is still signed in. Long forms need both; one side fails at the other side’s interruption.
Studying it
Have people fill a form that takes at least eight minutes. Insert forced leaves (refresh, two minutes away, kill process). Compare no draft, local only, server only.
Independent variables: whether a draft is written automatically, trigger (timer / blur / next step), whether the draft lives locally or on the account. Dependent variables: share of fields restored after interruption, abandonment caused by the interruption, stale values after restore.
Lab interruptions are scheduled; real ones are dirtier (OS update, expired sign-in). Test separately whether the draft survives an expired session. Completion on a short task is not evidence autosave is unneeded.
Where it stops holding
Two- or three-field forms under a minute cost more in engineering and leftover-draft privacy than they return. A local draft on a public computer is a leak; use session memory only, or an explicit “this is a public device” switch. Read-only review, and forms already submitted successfully, must not write a new draft that could clobber the submitted result with an old one. On collaborative forms with simultaneous editors, autosave becomes a conflict source and needs a merge, not a silent overwrite.
Applying it
- For forms expected to take more than a few minutes or to cross steps, write unsubmitted values on field blur or a short interval. Do not wait for “Next” or a “Save draft” button.
- Keep both a local copy and a signed-in server copy; refresh uses local, another device uses server. Unsigned-in, at least keep local.
- Restore the draft when the same task is opened again, rather than discarding it for an empty form.
- Verify by filling halfway and refreshing: values remain. Kill the process and reopen: values remain. Open the same application on another signed-in device: values remain. Bind save only to “Next” as a counterexample, refresh mid-step one, and confirm that implementation loses data.