Start by separating the experience into three parts: what can run locally, what needs a live connection, and what happens to work in progress when the connection fails. A screen that still displays a title is not necessarily an offline experience. The visitor must be able to finish the promised task, or receive a clear alternative that staff can deliver.
Map each dependency to the visitor's task
An installation may download its interface, images, video, product information, live scores, account data, and form submissions from different services. Mark each dependency as essential, optional, or replaceable. A locally stored product comparison might still work without internet; a live social feed cannot be fresh while disconnected. A form that merely appears to submit is worse than an honest message saying the team will take the details another way.
For browser-based experiences, MDN's guidance on offline operation explains that a service worker can serve cached resources after a network failure. It also notes the freshness trade-off: a cache-first approach may show stale information, while a network-first approach can fall back to a saved copy. This is a capability to design and test, not a guarantee that any website or kiosk already works offline.
Write the fallback in visitor language. If live event scores are unavailable, the screen might offer the last verified result with a timestamp, a locally playable challenge without scores, or a staff-led demonstration. If the core value of the experience is a live comparison, it may be more honest to pause the station until connectivity returns. Decide this before the event, rather than letting a browser error become the message.
Decide how inputs and recovery work
Ask what happens when a visitor is halfway through a session. Can they finish locally? Does a queued action wait for reconnection? Is an unfinished entry deleted at reset? If personal information is involved, the organizer must know exactly where it is stored, how long it remains, and how a visitor can avoid entering it into an uncertain state. Do not promise automatic later delivery unless that path has been built and tested.
The US National Institute of Standards and Technology describes contingency planning as coordinated procedures and technical measures that allow operations to recover after disruption. Its guidance includes alternate equipment and, where appropriate, temporary manual processes. Those principles are broader than an event kiosk, but they suggest a useful handoff: name who detects a failure, who can switch modes, and what staff will tell visitors. NIST, contingency planning overview.
Run a failure rehearsal before doors open
Test the built installation on the actual hardware with the network disconnected. Do this after a fresh launch, during a visitor turn, and during a content update. A warm browser cache may hide a missing file that a newly restarted device still needs. Check whether video, fonts, and alternative-language content were loaded, whether a reset clears the right data, and whether an operator can restore the normal state without a developer present.
Record the version and timestamp of local content. A fallback that shows an old price, event schedule, or product claim can create a different failure. MDN's caching guide stresses that different resources need different caching strategies because offline access and freshness can conflict. For claims that must always be current, define a safe “unavailable” state instead of serving an undated old answer.
This is an operational decision as much as a software one. Include the power source, device restart procedure, spare hardware, and a short staff script in the event runbook. Archv's interactive experiences combine a visitor-facing tool with a real place; the commissioning review should demonstrate both the ideal path and the disconnected path.