Kiosk requirements
What a kiosk has to support — browser, scanner, on-screen keyboard and screen controls — before it can run an OmniLab experience.
Check these before you order hardware or sign off a provider's proposal. Send this page to your kiosk provider and ask them to confirm each point in writing.
Browser, WebView or frame
Whatever the experience opens in must behave like a modern browser, not a stripped-down viewer.
- A current Chrome-based engine. Older embedded browsers fail on animations, and the failure often looks like a blank screen rather than an error.
- JavaScript enabled. The experience doesn't load at all without it.
- A way to run the kiosk's own code beside the experience. The idle signal arrives as a browser message. A kiosk web page listens for it; a WebView needs an injected script and a bridge to the app.
- Touches passed through to the experience. If the kiosk swallows them, games look responsive but nothing registers.
- Full screen. An address bar or browser controls invite visitors to leave the experience.
How the experience is loaded
Ask your provider early: does the kiosk load the experience as the page, in a WebView, or in a frame inside its own page?
A WebView is simpler, and the one to prefer. A frame only works under a domain rule: see Choose how the kiosk loads the experience. If the rule is missed, everything works until you test a real loyalty card on site. Settle it before the build, not during acceptance testing.
Scanner
- 1D barcodes cover loyalty cards and printed vouchers. This is the minimum.
- QR codes are optional. Ask for them if you might switch to QR invitations later.
- Fast scan response. A visitor who has to hold a card still for several seconds walks away.
Agree exactly what the scanner outputs. The experience receives the scanned value as text, so the kiosk must strip any prefix, checksum or leading zeros the scanner adds. Otherwise, the values you issue must include them.
On-screen keyboard
This only matters if new participants fill in the acquisition form at the kiosk. When it does, it's the biggest single cause of drop-off: a cramped or laggy keyboard loses the sign-up. Ask your provider to confirm:
- large, touch-friendly keys, sized for people standing in a public space;
- full alphanumeric entry;
- easy access to the at sign, dot, hyphen and underscore, without hunting through symbol pages;
- the keyboard opens when the visitor taps a field, and closes when they finish;
- autocapitalisation and correction, which reduce typos in names and email addresses.
Keep the form short: every extra field is another keyboard interaction in public. See Set up an acquisition form.
Screen controls the kiosk provides
OmniLab doesn't draw any of these. They belong to the kiosk.
- 1Background image and your branding
- 2“Touch the screen to start”, sized to be read standing up
- 3Animated pointer towards the scanner
- 4Session bar with the Home button — the visitor’s way out at any moment
- 5The experience stays loaded behind the modal
- 6“Are you still there?” message
- 7Visible countdown
- 8Stay — returns to the experience
- 9Return home — ends the session
The welcome screen opens the frame; the inactivity modal closes it. Both are yours to design.
| Control | What it does |
|---|---|
| Welcome screen | Invites the visitor to scan, ideally with an animated pointer towards the scanner |
| Home button | Ends the session and returns to the welcome screen, from anywhere |
| On-screen keyboard | Lets the visitor complete the acquisition form |
Network
The kiosk needs outbound internet access, and more than your experience domain. The experience also loads fonts, media and 3D viewers from other addresses. A loyalty card scan passes through sign-in addresses too. The first is <subdomain>.api.topage.co, or <subdomain>.api.uat.topage.co on Staging, with the subdomain of your default address, such as lindenhall. Then come your identity provider's pages.
On a restricted venue network, run a test session on an open connection first, and list every address it contacts. Give that list to venue IT early: allowlisting is slow, and a common launch-day blocker. If the kiosk only lets its browser open approved addresses, add the sign-in addresses there as well: see Keep sign-in inside the WebView.
Screen size
Give OmniLab the kiosk's screen resolution and orientation before testing starts. Kiosk screens are often tall portrait panels, so check the layout on the real device rather than in a browser window.