Autosave should fire between bursts, not mid-keystroke
Aliases: save at pause · breakpoint save · idle then persist · avoid mid-burst write
What it is
The clock having ticked does not mean this instant is fit to write. Avoiding mid-input means aligning the save with a seam in the burst: between phrases, on field blur, after a paste finishes — not while letters are still arriving, a selection is still being dragged, or an IME is still composing. Interval decides how wide the unsaved window is. Timing decides whether this cut lands inside the action in progress.
Why it happens
Keystrokes, drag-select and composition all occupy the same foreground path: document tree, caret, compose window. Even a background write can lock the document, relayout, fire validation, or pull focus to a status region. Dropped inside a burst, those disturbances are coded as “I was typing and the interface moved”. Dropped in the seam after a burst, the same write often goes unnoticed — the person was already taking a breath.
Seams are not just any quiet. Tasks have natural breakpoints: a phrase finished, a field left, a block selected before the next move. An outside chore inserted at a breakpoint is cheap to resume; inserted mid-word, the half-word in working memory has to be rebuilt. A save is one such chore. During IME composition the document value is still unstable; writing then can persist pinyin fragments as body text, or knock the compose window down.
Studying it
The classic interruption-timing move is to insert an equal-load chore into a decomposable task and compare placement inside a subtask versus on a subtask boundary. Iqbal and Bailey used mental workload to predict “is now a good moment”: load is lower at boundaries, and the same interruption costs less time and less annoyance. Autosave can be tested as a tiny system-initiated interruption.
Independent variables: how writes are aligned (fixed metronome / delay after last key / blur / explicit breakpoint), whether a write touches focus or layout. Dependent variables: input errors near a save, caret or compose-window disruption count, ratings of “I was interrupted”, effective characters per unit time.
Lab “type this specified passage” has cleaner pauses than real writing. Include IME composition and drag-select, or the most painful mid-cut is missed. Do not substitute “successful save count” for “did it cut into the action”.
Where it stops holding
Some people type for minutes without a seam (a deadline sprint, dictation-speed notes). Waiting forever for a breakpoint lets the unsaved window exceed the safety budget; a maximum wait must still flush, even mid-burst — but that flush should not steal focus or reflow the caret. For discrete controls (a switch, a select), every change is already a breakpoint; there is no keystroke gap to wait for. Collaborative carets and remote follow are more sensitive to “currently typing”; local writes should still yield, but remote sync can be sparser and need not share the local breakpoint beat.
Applying it
- Default to writing after a burst settles, on blur, or after a paste completes. Use a maximum wait as a floor so a save cannot be postponed forever.
- Do not persist body text while composition is uncommitted. Do not let a save redraw drop a selection that is still being dragged.
- A write must not steal focus, jump the caret to the top, or raise a dialog that blocks typing.
- How to check: keep typing mid-sentence; a save must not make the caret, selection or IME candidates vanish. Confirm the draft updates after a pause or blur. Type through the maximum wait and confirm a flush still happens without taking focus.