G4.03.3persisted navigation state has a TTLdesignresearch

Persisted state expires, and expiry must be explained

Aliases: explain expired state · session TTL · stale filters · persistence lifetime

What it is

Scroll position, filters, and sort are kept to serve this still-unfinished browsing pass, not to permanently rewrite the person’s relationship with the collection. Persisted state has a lifetime: when the session ends, too much time has passed, or the login changes, the snapshot should die. On death the user must be told “your last narrowing has expired; you are looking at the default collection,” not handed a silent fragment that is neither the default nor the memory.

Why it happens

“I filtered to unread” lives in short-term memory and decays after the task is left. Opening the same list the next day, people plan against the default collection; if yesterday’s facets still apply, the result set fails the plan, and they infer broken data or changed permissions. sessionStorage dies with the tab; localStorage and account preferences outlive this intent. Writing a one-pass browsing cut as a long-lived preference lets an expired intent ghost into a new task.

Expiry without explanation fails silently: controls may have gone dark while the request still carries old params, or controls stay lit while the data is the new default. Either inconsistency is harder to diagnose than “we reset.” TTL is the task’s half-life: shopping a catalogue may be this tab; filtering tickets may be this shift; “only my drafts” may belong on the account. Persistence with no declared lifetime turns a storage implementation into product behaviour.

Studying it

Have people set a non-default filter, then reopen the same list after three intervals: immediate return, hours after closing the tab, after switching device or clearing the session. Compare TTL-with-notice, TTL-without-notice, and remember-forever.

  • Dependent variables: whether the current collection is taken as “still what I set,” time to notice inconsistency, false beliefs that data was lost or filters broke.
  • Independent variables: storage layer (session / local / account), whether expiry is explained in one sentence, interval length.
  • Methodological note: a lab “long time later” often uses a sped-up clock; human memory decay does not speed with it. A harder probe is a next-day remote session, not a same-hour pretence of overnight. Do not mix “account-level default sort” and “this-pass filters” into one TTL—their reasonable lifetimes differ, and a mixed test yields “persist everything forever” or “drop everything immediately.”

Where it stops holding

A filter the user just clicked, even if a nominal TTL has crossed, must not be stolen on the next paint; TTL governs silent restore after leaving, not an in-progress action. An explicitly saved “my view” is a long-lived object of user intent and does not take the round-trip expiry rule. When law or safety requires every entry to start unfiltered (a shared counter, a patient list), nothing should persist, and the copy is not “expired” but “this place does not remember filters.”

Applying it

  • Give scroll, filters, and sort separate lifetimes: scroll with this session; filters with the tab or login session by default; only conditions the user saved as default go on the account.
  • After expiry, return to the product default and give a one-shot notice on the list (“Filters expired; showing all”). Do not leave half-lit chips.
  • Do not write a temporary facet from the session into localStorage with no prompt.
  • Verify: set a filter, close the tab past the TTL, reopen. The collection should be the default, and the expiry notice should be visible. Immediate round-trip inside the same session should still keep the filter. As a counter-example, persist forever in localStorage; opening the next day should catch the ghost filter—that is the behaviour this leaf exists to kill.

Related

  • Within the group: G4.03.1 Back to a list should restore where the user had scrolled · G4.03.2 Filters and sort must survive a round-trip
  • Adjacent: G4.05 Resume from interruption · I3.06 State persistence · G4.07 State persistence and position restoration
  • Search terms: TTL · stale persisted state · sessionStorage

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/G4.03.3