Ask which functions must survive
“Works offline” is too broad to approve an event application. A local video can continue while an online form fails. A form may accept an entry on the device while the central team still cannot see it. A login or licence check may prevent a restart even though an already running session appears fine.
List each function and the result visitors expect. Agree what should continue, what should pause and what message should appear. Then ask the developer to demonstrate those behaviours on the device and browser that will actually be used.
Build a function-by-function agreement
| Function | Possible offline design | What still needs verification |
|---|---|---|
| Product text and images | Prepared local content | All required products, languages and media are present |
| Video | Approved files stored on the device | Playback, storage space and rights for that use |
| Contact form | Local pending records with later transmission | Persistence, privacy, recovery and duplicate handling |
| Live inventory or appointments | A clearly labelled last-known view, if appropriate | Which decisions require current server confirmation |
| Email or media delivery | A request queued for later | Actual delivery status and how staff handle failures |
A business process may require an online confirmation. For example, two disconnected stations cannot safely assume that the same remaining appointment is available unless the system includes an agreed conflict-handling design. Decide the acceptable behaviour with the process owner.
Prepared content is different from accidental browser history
MDN's offline application tutorial shows how service workers can store application resources and serve them without a network. That capability has to be implemented and the required content made available. Merely visiting the first page earlier does not establish that every later screen or video will work.
Ask for a visible content version and a preparation check. After an update, confirm that the complete new package is ready before removing the old one. Include a fresh launch with connectivity disabled in the rehearsal; do not test only an application that has already loaded everything during an online session.
Worked example: an outage during lead collection
Assume a hypothetical two-station catalogue is designed to store contact requests locally. During a rehearsal outage, the team creates five test records on station A and three on station B. One of the eight is submitted while the connection is disappearing, so its server acknowledgment is uncertain.
On reconnection, the operator checks that the receiving system contains exactly the expected eight logical requests. The developer demonstrates how retrying the uncertain request avoids creating a second copy. The team also checks the local pending count, a failed record and the procedure for reconciling differences.
Repeat with an application restart before reconnection. If pending data disappears or the application cannot launch, the promised workflow has not passed. Eight is simply a manageable test set; the final test volume should reflect the project's expected workload and interruption scenario.
Make status clear to both visitors and staff
Use different messages for a request saved on this station and a request confirmed by the receiving system. Do not show “email sent” when only the intention to send has been stored. Decide what the visitor should do if confirmation cannot be obtained, including an assisted alternative.
MDN documents background synchronisation as a way to defer work until connectivity returns, with limited browser availability. Ask how the chosen platform handles retries and what staff must do if automatic synchronisation is unavailable. A browser feature name is not a replacement for an operating procedure.
Rehearse the uncomfortable cases
Disconnect before launch, during browsing and immediately after submission.
Test a slow or unreliable connection as well as a completely disconnected device.
Restart with pending records and inspect the recovery result.
Reconnect two stations and reconcile expected records in the destination system.
Confirm who can view or export pending data and who clears it after verified transfer.
Common mistakes are treating the Wi-Fi icon as proof of server access, forgetting externally hosted fonts or media, promising immediate delivery during an outage and clearing devices before reconciliation. Keep the data-handling and retention plan specific to the event.
Send the function matrix and acceptable fallback behaviour with an event application brief. Include the intended touchscreen or tablet setup and network arrangement so the offline test matches the eventual station.