Skip to main content

Features

What the app does, from the visitor's side and from yours.

PageWhat it covers
ScreensEvery screen a visitor can reach, and the library pages the default app does not use
AudioPlayback, listening progress, background play and lock-screen controls
OfflineThe service worker, what gets cached, and how updates reach a cached device
PWAInstalling to the home screen, the manifest, dark mode
EmbeddingThe postMessage API for driving the app inside an iframe

At a glance​

FeatureConfigured byDefault
Station playbackYour data.jsonon
Several languageslanguages in your dataone language, screen skipped
Station picturesimages per station — the default app needs twoon
Number keypadAlways availableon
Listening progressAlways onon
PIN gatepins in your dataoff
Share sheetshare in your dataoff
Offline cachingoffline_support variableoff
Home-screen installmanifest.json, always presenton
Dark modeFollows the deviceon
Runtime theming from a host pagemessaging_support variableoff once you apply a values file
Tours, map, multi-track stationsLibrary pages, routed in a forkoff

What it deliberately does not do​

  • No backend, and so no analytics of its own. Visitor numbers come from your web server's logs, or from whatever you add yourself.
  • No visitor accounts. Progress is kept on the device and does not follow a person to another device.
  • No content editing in the app. Content is a JSON file you publish. A CMS on top of that is what the managed plan provides.
  • No push notifications, beacons or indoor positioning. Stations are reached by number or from the list.
  • No feedback or ratings. Nothing is sent anywhere from the app.

That last group follows from the architecture: static files plus a JSON document, with nothing to talk to. It is also why data protection for a self-hosted deployment is simple to reason about — the app requests your content and nothing else.