Wayfinding kiosk software: build the map, run it locked

The short answer

Build it yourself until one of two things happens: a second kiosk, or content that changes without you. A single wayfinding kiosk is a web page with links. Any small PC or Android box that runs a browser can run it, the pages keep working with the network unplugged, and nothing renews. A touch-first wayfinding CMS buys central editing, per-screen management and built-in live feeds, and asks a subscription quoted per screen to do it. On one screen that buys almost nothing. On six screens across a campus it buys your afternoons back.

Side by side

Where a self-built kiosk wins

Everything that matters on screen is yours to set. The touch targets, the label sizes and the idle reset are lines in your own files, not options in someone's console. The pages load from the kiosk, so the map keeps working with the network down. And the hardware is whatever you have: a small x86 panel PC or an Android box with a browser.

The build is short:

1. Draw the overview once. SVG keeps the walls crisp while the browser resizes it; if the map comes up broken inside the kiosk browser, fixing fragmented SVG rendering in a kiosk browser names the causes and the cures.
2. Cut the floor plan into zones and link each zone to its destination page. The touchscreen feeds the browser mouse clicks, so a plain page is already interactive.
3. Give every destination page the same furniture: a you-are-here dot, the walk path, and a Home button the size of a touch target, in the same corner every time.
4. Open the first page in the browser's full-screen kiosk mode. If it fills the window at the wrong size, diagnosing kiosk browser sizing in an HMI window walks the checks.
5. Set the idle reset and lock the box down, covered below.
6. Test with a fingertip: every zone, then the Home button, then a full power cycle.

Where a touch CMS wins

Content that changes weekly, more than one or two screens, or data that moves. A CMS gives you one web console: fix a room name once and every kiosk picks it up. It pulls live schedules and event feeds, which a static page cannot do without your own code. It also runs the set of screens: playlists per screen, an emergency notice that overrides every map at once. The trade is a subscription and a platform to learn. Whether the CMS's server has to be reachable from the kiosk is its own question; does an on-premise signage CMS need internet separates the cases.

The numbers that make a touch map usable

Two rules carry the layout.

Touch targets. Android's accessibility guidance sets the floor at 48 x 48 dp, which lands at about 9 mm of glass, and calls 7 to 10 mm the comfortable band. Every tappable zone gets at least that, Home button included. A zone may be wider than it is tall; 9 mm is the smallest dimension, not the shape.

Label size. Text follows the same distance rule as any sign, set out in screen size and viewing distance: the FHWA planning figure is 30 ft of viewing distance per 1 in of capital letter height, and 20 ft per inch when the visitor reads at a glance. Line spacing is 1.7 x capital height. Measure from where a visitor actually stands, which at a lobby kiosk is a few feet back, not from the glass.

The panel behind the map is a separate choice; touch wayfinding kiosk screen sizing and picking covers it.

Example: a 10-inch lobby map with 12 destinations

The case: one lobby kiosk, say 12 destinations on the ground floor. Say the panel is a 10-inch touch screen in landscape in the common 16:9 shape. The glass area follows from the diagonal: 254 mm split 16 to 9 gives 254 x 16 ÷ 18.36 = 221 mm wide and 254 x 9 ÷ 18.36 = 124 mm tall, so 4.9 in of height to work with. Assume the overview has to read from 5 ft, about where a visitor stops to take the map in before walking up to touch. The rules come from the two sources above: zones at the 9 mm floor from Android's accessibility guidance, labels at the FHWA fast-read figure.

Count the tap zones first. Zones across: 221 ÷ 9 = 24.6, so 24. Zones down: 124 ÷ 9 = 13.8, so 13. Total: 24 x 13 = 312 zones at minimum size. Touch is never the limit on a screen this big.

Count the labels next. Fast-read capitals at 5 ft: 5 ÷ 20 = 0.25 in, which is 6.4 mm. Line pitch: 1.7 x 0.25 in = 0.425 in per labeled row. Rows that fit: 4.9 ÷ 0.425 = 11.5, so 11 labeled rows. Twelve destinations need 12 x 0.425 in = 5.1 in of label column, and the panel has 4.9 in. One row short.

Decision: above 11 destinations at this panel size, split the map. Keep the places people ask for most as labeled rows on the overview and put the rest one tap away on a second page. If all 12 must sit on one overview, drop the labels to the leisure figure: 5 ÷ 30 = 0.17 in capitals (4.2 mm), pitch 1.7 x 0.17 = 0.28 in, and 4.9 ÷ 0.28 = 17 rows, which carries all 12 at the cost of glanceability from the door. Either way the zones stay at 9 mm; the 6.4 mm capitals sit comfortably inside a 9 mm-tall zone.

Run it locked, and reset it

Full-screen kiosk mode is a built-in browser feature: it hides the address bar, ignores stray keys and loads one start page. A walkthrough of full-screen kiosk mode configured for a dashboard page shows the shape of it. Start the browser at power-on so the map is up before anyone touches anything.

On an Android box, add the security setting that pins one app to the screen, so the home and recents buttons do nothing while the map runs. On a small PC, the kiosk browser plus an autostart entry covers a public corner.

Set the idle reset to about 60 seconds: long enough to read a short route, short enough that the next visitor starts on the overview. That is far tighter than an operator screen, where returning an HMI screen to home after 10 minutes idle is the normal setting; an operator may walk back to a half-finished task, a visitor will not.

The same structure runs in slide software if you would rather not touch HTML: an overview slide, one slide per destination, a Home button on each, deck run full screen. Fine for one kiosk; you give up the idle timer and any live data.

Check it worked: fingertip every zone, wait out the idle reset and confirm the overview returns, then pull the power and confirm the map comes back up on its own.

The decision for your building

One kiosk, a map that changes a few times a year: build the pages and run them locked. The layout afternoon is the whole cost, and nothing renews.

Two or more kiosks, weekly content changes, or live schedules: take a touch CMS. One edit reaching every screen is the thing you are buying.

Touch nobody uses: drop the touch layer. The same maps cycle on a timer; some control-room packages ship exactly that, pages configured to rotate every 30 seconds. On our side, our player software loops images and MP4 from a microSD card or USB stick with no subscription and daily on and off times; the lobby displays section is where that lives.

Recommendation: for one kiosk showing a building map, build linked pages and run them in a locked kiosk browser, with every touch target at 48 x 48 dp, about 9 mm, and a 60-second idle reset. Take a paid touch CMS only when a second kiosk goes in, the content changes weekly, or the map needs to pull live schedules.

Questions