Cross-device resume stores position on the account, not in local state
Aliases: reading position sync · account-side position · continue on another device
What it is
“How far I got” in a long article, a course, a series, an ebook travels with the person, not with this phone’s tab. Cross-device resume writes that place as progress on the account: object id, paragraph or timestamp, updated-at. Local scrollTop, sessionStorage, player state on this machine vanish on another device. Returning to a list on the same device is in-session restore. Another device is a different event, and the storage layer has to change with it.
Why it happens
People treat an unfinished object as a task that spans situations: a commute stretch, then a desk stretch. The task’s identity is that book on the account, not a browsing context. Local state is bound to a device, a browser profile, sometimes a tab; changing device is a blank memory. Reading-system work (ebooks, video continue-watching) repeatedly shows that when progress lives only on the device, the cross-situation task splits into two starts-from-the-beginning, and it is the second sitting whose completion drops.
Account-side position also conflicts: two devices each moved while offline, then come online and must decide who is newer. Last-write-wins is often enough, but the older end must not silently jump backward—believing you just reached chapter 12 and being yanked to 9 is worse than no resume. The grain of the coordinate has to survive layout: pixels and type size change across ends; paragraph ids, page numbers, media timestamps are portable. Logged out, there is no account layer; cross-device resume does not apply. “This browser still remembers” is not a substitute.
Studying it
Have people read to a known place on device A, then open the same object on a logged-in device B. Compare local-only storage with account sync.
- Independent variables: storage layer, conflict policy (last write / newer progress / ask), sync after an offline fork.
- Dependent variables: whether B lands at A’s place, whether a backward jump occurs, whether people can say “where I was.”
- Methodological note: opening both almost at once on the same Wi-Fi hides sync delay; pause a few seconds on A before opening B. Both ends with different layout (phone / desktop) must be run; pixel sync will “miss that paragraph” on desktop. Do not run this leaf on two logged-out devices—that measures local storage and the conclusion will be wrong.
Where it stops holding
A one-screen piece has no cross-device progress to store. Privacy-sensitive reading (anonymous, private browsing) should not write the account. A shared account will have positions stepping on each other; that needs profiles, not “one account, one place.” Local draft-like scroll (where a filtered list had stopped) should not default-sync to the account; that is a different, short-lived kind of state.
Applying it
- On pause, leave, and a periodic heartbeat for long content, write a portable coordinate (paragraph id, media time) to the account. Do not write
scrollTop. - Opening the same object on the other end reads account progress and aligns. If the older end would jump a long way to newer progress, confirm before jumping; never silently jump backward.
- Logged out, offer only on-device in-session restore, and after login ask whether to merge this machine’s progress into the account.
- Verify: on A, read to a paragraph you can point at; wait for sync; open on B. The first screen is that paragraph. Read further on B, return to A; A must not fall back. Turn account sync off as a counter-example; B should start at the beginning or at this machine’s blank.
Related
- Within the group: G4.07.1 When a list mutates while away, restore the item, not the pixel offset · G4.07.2 Infinite-scroll restore depends on how much was loaded; returning too deep retriggers fetch · G4.07.3 Unsubmitted input drafts should survive leaving by navigation, not be cleared · G4.07.4 When position restore fails, say why—deleted or reordered
- Adjacent: G4.05 Resume from interruption · I3.06 State persistence · I3.04 Sync conflicts
- Search terms:
cross-device resume·reading position·progress sync
Cards in the same group
- G4.07.1When a list mutates while away, restore the item, not the pixel offset
- G4.07.2Infinite-scroll restore depends on how much was loaded; returning too deep retriggers fetch
- G4.07.3Unsubmitted input drafts should survive leaving by navigation, not be cleared
- G4.07.4When position restore fails, say why—deleted or reordered