Choose what must continue without a connection
Imagine a fictional warehouse where someone counts boxes using a phone. In aisles without coverage, they need to read a prepared list and record quantities. Final confirmation happens when the shared system receives the work. For this initial case, we can leave new product records and photo uploads outside scope.
Web apps can prepare resources and data for offline use. Installing a PWA does not automatically implement that behaviour: it needs development and testing. Ask which information must be downloaded before entering the area without coverage, and how the app shows when that information was last updated.
Distinguish a local record from confirmation
A quantity entered on a phone is not yet available to colleagues. The person should understand that difference. For this example, we propose three visible outcomes:
| Outcome | Meaning for the person doing the work |
|---|---|
| Saved on this device | The count is recorded locally; colleagues have not received it. |
| Needs checking | Delivery or a conflict needs review; avoid entering the same count again. |
| Confirmed | The shared system has accepted the operation under the agreed rules. |
Write the conflict rule before development
At 10:05, someone counts twelve boxes while offline. At 10:12, a colleague records ten boxes in the online system. When the first phone reconnects, treating the last submission as authoritative could replace newer information with an earlier observation.
For this scenario, we could retain both observations, including who counted and when, and ask the responsible person to reconcile them. The shared quantity changes only after that decision. This is a workflow choice, not a universal rule. Agree which operations can coexist and which must wait for review.
Provide recovery when the app is reopened
MDN documents limits on the retries and duration of background operations. Background Sync is also unavailable in some widely used browsers. The workflow therefore needs more than automatic delivery while the app is closed.
Ask for a visible list of pending work and recovery when the app is reopened. In the warehouse example, another attempt must refer to the same count rather than creating a fresh one. If the session has expired, the interface should explain how to sign in and resume the work still awaiting submission.
Decide what may remain on the device
Browser storage has capacity limits and retention conditions, and locally stored data can be removed, including by the user. Ask how failed saves are detected. If a record has not been stored, the interface must not describe it as safely saved.
For a shared device, define what the next user can see and how pending work is handled before switching accounts. Explain the effect of clearing browser data: a record that exists only on the device cannot be recovered from the server. These decisions affect the working procedure too.
Test the result on the agreed devices
List the browsers, devices and offline tasks. Inspect the final quantity in the shared system during testing. Before commissioning development, prepare this sequence with invented data:
- Open the prepared list with the network already unavailable.
- Record a count, close the app and reopen it.
- Interrupt delivery and retry without producing duplicate records.
- Synchronise conflicting observations and resolve them using the chosen rule.
- Handle insufficient storage or an expired session without showing false confirmation.
Explore an example
ServiceBot is a synthetic example for discussing states and outcomes. It does not implement this warehouse scenario and is not presented as evidence of offline synchronisation.
Explore request states ↗Prepare your project brief
A reusable text template: objectives, users, features, materials and acceptance checks. Download it without registration and edit it with your team.
Download the project brief (.txt) ↓Technical references
Published by Ospivia Studio, prepared with AI assistance and checked against the linked technical sources. Examples are illustrative and are not customer results.