Read status and progress are expected to sync before content
Aliases: read receipt sync · playback position · Kindle progress · unread badge
What it is
Mail marked read on the phone lights up again on the computer; a book left at page 120 on the tablet reopens at 80 on the phone. The body can arrive late. Read marks, playback position, reading progress—this metadata, once behind, is immediately felt as “this device does not acknowledge what I just did.” Tolerance for stale progress is lower than for a missing chapter, attachment, or cover image. Kindle and podcasts treat progress as the primary sync object not because content is unimportant, but because wrong progress forces repeated labor or missed updates.
Why it happens
When content lags, people see “not here yet”: a missing chapter, a missing image. Waiting is intelligible. When metadata lags, they see the system denying the last action: heard, read, triaged—and the other device treats it as never happened. That breaks the loop those actions exist for. Marking unread, finishing an episode, dragging a playhead are meant to change the to-do on every later device. Metadata is small and frequent, so it should outrun large attachments; if the queue is ordered by file size or by “fetch content on open,” progress is pushed back. People switch devices in order to keep reading or listening. Progress is the reason for the switch; arriving late makes the switch pointless.
Where it stops holding
Single-device use, never opening the same inbox or book elsewhere, never exposes stale progress. Shared progress (a household continuing a show, a communal mailbox) must not silently write one person’s “read” onto everyone else’s—that is identity, not delay. A device kept on purpose with its own place (a child’s lesson tablet, a pad used to rewatch) needs a separate setting and must not be overwritten by global progress. After finishing an episode offline, write progress back before the file is re-uploaded, or the online device will nudge the old position again.
Applying it
- Split read/unread, playhead, and page number from the attachment queue and push those fields first on a device-switch path.
- While another device still shows old progress, do not interrupt with “you have new mail / resume playback” for an item just handled on the source.
- Let people see which device last wrote progress and when; when two positions disagree and order is unclear, ask rather than jumping back to the older page.
- Verify: mark a mail read on the phone, turn a chapter in an ebook, drag a podcast to mid-episode, then open the computer client immediately. While the body or audio may still be buffering, the unread lamp, chapter position, and playhead must already agree; missing content must not roll progress backward.