Continuation must keep task state, not merely open the same page

What it is

A half-written mail on the phone that becomes an empty inbox on the computer is the right app and the wrong activity. Task continuity carries the in-progress activity—body, caret, attachments, recipients—not just the same entry page. Handoff that hands Safari’s reading position, a live Maps route, or a Mail draft to a nearby Mac is continuation. Shipping the same URL is not: the person still has to scroll back. Continuation is a one-shot handoff of “how far I got” when the device changes. It is not two devices keeping a long-lived replica of the same data.

Why it happens

Working memory for a task holds intermediates: typed text, scroll offset, uncommitted choices, a route already underway. Changing devices wipes that memory because hands and eyes have left the source screen. A deep link rebuilds the kind of task, not this instance halfway through, so the switch feels like starting over. Granularity decides whether thought continues: mail must include the draft body, not a blank composer; a page must include scroll offset and unsaved fields, not just the host. Any missing layer forces a pause to reconstruct “what was I doing,” and that pause eats the continuation window.

Studying it

Use a device-switch resumption task: take the activity on device A to a point that depends on intermediate state (three sentences of a draft, mid-article scroll, a navigation already off-route), then force a switch to device B. Compare handing over only the same entry with reconstituting the full activity.

Independent variables: granularity of transferred state (app only, document only, plus scroll/caret/draft), whether the switch happens under the same account and near-field conditions. Dependent variables: time to a point where work can continue, number of dropped state items, repeated labor, a judgment that “this is still the same thing.”

Diaries of multi-device ecologies show when people actually switch, but they confound missing state with a missing entry. Lab switches control granularity and lower ecological validity: participants know a switch is coming; real continuation is often interrupt-driven. “The file is already in the cloud” is not success—the file existing is not the activity existing.

Where it stops holding

Read-only glances with no intermediate state (weather, a completed order) only need the same page. Different accounts or a missing app on the target block the handoff before any state model matters. After a long absence the person no longer remembers the stopping point; restoring everything can feel like an expired draft, and offering a choice of where to resume beats forcing the old scroll. Long-lived replicas of the same notes or tabs are synchronization, not a one-shot activity handoff.

Applying it

• Define a minimum continuity payload: beyond a document id, include scroll position, insertion point, uncommitted input, and the in-progress mode (editing, preview, navigating).
• Land the target device where work can resume immediately, not on the app’s default home or the document’s first screen.
• Do not treat “the same site opened on the computer” as continuation; check that scroll position and form contents survived.
• Verify by scrolling a long article to mid-page and selecting a sentence on the phone, then using system continuation onto a computer. The computer should show that offset and selection, not the top of the article. Repeat with a half-written mail; the computer must open the draft body, not a blank composer.

Related

• Within the group: K8.01.2 The continuation entry must be findable on the target device · K8.01.3 When continuation fails, the reason must be stated
• Adjacent: K8.02 Multi-device state sync · K1.08 App switching and background reclamation
• Search terms: task continuity · Handoff · activity continuation