Skip to content

Kiosk mode

The dashboard for a wall — ?kiosk, what stops rendering, why the display signs in as a viewer, and why this is not a security boundary.

Switching it on

The same dashboard with ?kiosk on the end of the address:

https://app.runjet.dev/your-slug/?kiosk

It is not a second screen but three switches over the same five bands:

  • density — type, spacing and radii all grow at once, because it is one rule at the root of the page and everything is derived from it,
  • overflow — on a desk you scroll; kiosk caps each band and says +12 more,
  • chrome — the navigation column, the account menu and every link from a row all disappear.

The parameter applies to the dashboard only and does not travel to the other screens: it would follow an operator everywhere, and it would leave a wall one stray click away from a state nobody is there to undo.

What stops working, and what does not

Data keeps refreshing even in a tab the browser considers hidden — otherwise the display would freeze mid-countdown, which reads as data rather than as a pause. The session does not sign itself out: it lasts thirty days and is extended by use.

Sign the display in as a viewer

A wall deserves an account of its own with the viewer role (roles): it reads everything and changes nothing. Invite it like any other account (invitations), sign in on the display, and never touch it again. That the display can change nothing is a property of that role, not of kiosk mode.

It is not a security boundary

Kiosk removes controls, not rights. The session keeps everything it had: were the display signed in as an admin, a passer-by with a keyboard would delete a job — they would only have to edit the address to do it. Which is why the boundary is in the account and not in the parameter, and why the paragraph above is not a recommendation but a procedure.