Visible state should survive a session close
Aliases: session restore · still there tomorrow · keep the place
What it is
A person quits the app, locks the computer, opens it the next night, and the world they last saw should still be there: a half-written draft, a filtered list, a place half-read, a few panels they had open. Cross-session persistence keeps state whose perceptual cost has already been paid, not state that happened to still be in a living process. If a session end zeros that layer, tomorrow’s arrival pays the same cost again. The product has amnesia.
“User-visible” draws a line: seen, depended on, still seeable next time. Internal caches, a temporary token, the inertia of one scroll, are not this obligation. How far privacy reaches, and how to clear, are other ledgers.
Why it happens
A session is a process lifetime; a task is a person’s lifetime. People carry an edit, a filter, a page of reading as an unfinished task overnight; the process dies on lock or a background kill. If state lives only in memory, the task boundary is cut by the process boundary, and tomorrow’s face is blank. They must rebuild from recollection. Recollection is costlier than another glance, and it lies.
Visible state is the layer already in the model: draft text, the current filter, a scroll anchor, whether the sidebar was open. Its acquisition cost is already paid. Persistence moves that layer from process to disk (or account) so the next process can load the model back. Load-back has to be fast enough to feel like “never closed”, or people assume loss and write a second copy. No load-back is deterministic loss: not a sync conflict — the product threw yesterday away.
Where it stops holding
A login page, a card number at checkout, a one-time code should not remain as plaintext visible state across sessions — that is privacy and safety, not “visible therefore keep”. A deliberate “start a new one” (new document, new search, sign out) must be able to start blank; persistence must not become inescapable stickiness. On a public terminal or a borrowed device, cross-session keep becomes a leak; the default can still keep until an explicit sign-out or a lock-screen policy fires. Scroll position on read-only content helps in a very long list and can pin someone to yesterday in a daily feed; then keep an anchor to “which item”, not a pixel offset. Crash recovery needs persistence more than a clean quit: a quit was at least voluntary; a crash cut the task mid-sentence.
Applying it
- List visible state whose acquisition is expensive: drafts, filters, read position, unfinished multi-step, open objects. These survive a process kill.
- Write before the process is likely to die (pause in typing, going to background). Do not wait for a Save button.
- The first frame on next open should be recognisable as “yesterday’s”, not a blank flash then an async fill — blank is read as loss.
- How to check: half a draft, a filter, scroll to the middle, force-quit, reopen. All three should be there without doing the work again. Contrast: kill one tab and return; the same keep should hold, proving it was not “the process happened to live”.