Designing Web Apps for Hootboard Portrait Kiosks

A complete design and development guide for building web experiences that shine on 49" and 55" portrait kiosks running at 1080×1920.

Kiosks are not phones. They are not tablets. They are not desktop monitors tipped on their side. They are a distinct medium: a large-format touch display that the user has deliberately engaged — they have walked up, they have tapped to open your app, they are standing right in front of the screen. A web app that is merely "responsive" will feel awkward on a kiosk, while an app that is purpose-built for the portrait kiosk canvas will feel effortless and inviting.

This article walks through everything you need to design, build, and ship a web app for Hootboard kiosks: the exact viewport dimensions you get, the typography and touch-target rules that actually work on a 55" portrait display at arm's length, and a concrete side-by-side comparison against the Jackson Weather app — a reference implementation that gets kiosk design right.

An important scoping note. This guide is about web apps that are launched from the Hootboard shell — Weather, News, Guide, Events, and so on. These apps are only ever seen by a user who is already engaged with the kiosk: they walked up, they tapped a tile, they are now standing directly in front of the display. Your job is not to pull people in from across the lobby — that is the job of Hootboard's home screen and attract loop. Your job is to be effortless to read, understand, and interact with for someone whose hand is already on the glass.

1. The Hootboard kiosk hardware at a glance

Hootboard portrait kiosks are freestanding touch displays deployed in public or semi-public spaces — town halls, lobbies, libraries, campuses, hospitals, transit hubs. The hardware your web app needs to target is:

Display size	Native resolution	Orientation
49" or 55"	1080 × 1920	Portrait

The kiosk is fixed in place, and your web app only runs once a user has already walked up, tapped, and engaged with it. By the time your code is on screen, the user is standing directly in front of a 49" or 55" display, roughly 40–80 cm away— close enough to tap, close enough that the screen fills most of their field of view. That is the context you are designing for.

Design for the engaged user. By the time your web app is on screen, the person has walked up, tapped into it, and is standing at arm's length — not glancing from across the lobby.

2. The canvas you actually get: 1080×1650

Here's the most important thing to internalize before you write a single line of CSS: your web app does not get the full 1080×1920 screen. The Hootboard shell wraps every web app with a navigation header (home, guide, events, more) and a footer ticker (date/time, event promos, "End Session" button). What's left for you is a fixed, reliable canvas:

Width	Height	Aspect ratio
1080 px	1650 px	1 : 1.53

The Hootboard shell reserves space for navigation and the footer ticker. Design for the dashed orange area: 1080×1650.

Design target: Always build and test your web app against a 1080 × 1650 viewport. Do not assume you have 1920 pixels of height — anything you place in the outer 270 pixels will be covered by Hootboard chrome.

CSS starting point

Use absolute pixel dimensions rather than viewport units for the outer container. This guarantees your layout does not drift if the shell resizes the iframe slightly during transitions:

html, body {
  margin: 0;
  padding: 0;
  width: 1080px;
  height: 1650px;
  overflow: hidden;           /* no scrollbars on a kiosk */
  font-family: system-ui, -apple-system, sans-serif;
  -webkit-user-select: none;  /* no text selection */
  user-select: none;
  -webkit-tap-highlight-color: transparent;
}
* { box-sizing: border-box; }

3. Seven golden rules of kiosk design

Every recommendation in the rest of this guide flows from these seven rules. If you remember nothing else, remember these.

Design for a standing, engaged user at arm's length. Not a laptop user at a desk, not a phone user on the couch. The user is on their feet, reaching out, looking at a 55" screen that fills most of their field of view.
Go big or go home. Body text starts at 32 px. Headlines start at 72 px. Small desktop type is painful on a 55" display — even up close — because a kiosk user cannot pull the screen toward their face.
One screen, one job. Kiosks are not SaaS dashboards. Each screen should have one primary action or one message. Split, don't cram.
Make touch targets fat. 88 px minimum, 120 px for anything primary. Spacing between targets matters as much as the targets themselves — standing users are less precise than seated users.
Assume the user just walked up. No onboarding, no logged-in state, no "welcome back." Every session starts from zero.
Respect the chrome. The Hootboard header and footer already provide navigation and "End Session." Do not duplicate them.
Fail gracefully. Kiosks live on public Wi-Fi. Plan for slow networks, timeouts, and offline states.

4. Typography: build for a 55" screen at arm's length

Type size is the single biggest difference between a kiosk app and a desktop app. On a 55" portrait display, the pixel pitch is roughly 0.63 mm — almost twice as coarse as a 15" laptop. A 16 px body (the web default) physically measures about 10 mm tall, and the user cannot lean in or shrink their face closer to the screen the way they would on a phone. The result: desktop-sized type on a kiosk looks loose and feels uncomfortable to read, even for an engaged user standing right at the glass.

Use this scale as your starting point. You can deviate, but deviate up, not down.

Role	Size	Weight	When to use it
Display / Hero number	120 – 180 px	700 – 900	The single most important piece of data on the screen (temperature, time, headline number)
H1 / Screen title	72 – 96 px	700	Top of a screen, answer to "what am I looking at?"
H2 / Section	48 – 64 px	600	Grouping content within a screen
H3 / Card title	36 – 44 px	600	Labels on list items, forecast rows
Body	32 – 40 px	400 – 500	Sentences, descriptions, paragraph text
Caption / Meta	24 – 28 px	400	Timestamps, footnotes, secondary info. Never smaller.

The kiosk type scale, shown at relative size. Notice how the hero number dwarfs everything else — that's the point.

A quick sanity check: view your design at 100% on a large external monitor and stand at arm's length from it. If the body text makes you lean in, it's too small for a kiosk — a kiosk user cannot lean in without getting awkwardly close to a 55" screen.

Font choices

Pick a font with generous x-height and open counters. Humanist sans-serifs hold up best on large displays. Good starting points: Inter, Roboto, Source Sans 3, Work Sans, IBM Plex Sans, System UI. Avoid thin weights (100, 200) entirely — at 55" they render as wispy hairlines that disappear against any textured background. Start at 400 for body and 600+ for titles.

5. Touch targets and spacing

Apple's iOS guideline (44 pt), Google's Material guideline (48 dp), and Microsoft's Fluent guideline (40 px) are all designed for handheld devices held steady in a user's palm. On a fixed kiosk, the user is reaching out, often standing, often with a gloved hand, sometimes with a child in tow. You need much bigger targets.

The minimum for anything tappable is 88 px. Primary actions and home-screen tiles should be 120 px or larger.

Spacing between targets

Big buttons packed tightly together cause as many mis-taps as small buttons. Leave at least 24 px of clear space between adjacent touch targets, and 32 px where users might be scanning quickly.

Element	Minimum	Recommended
Tappable minimum (hit area)	88 × 88 px	120 × 120 px
Primary action button	120 × 88 px	200 × 120 px
Home tile / category card	240 × 240 px	320 × 320 px
Spacing between targets	24 px	32 – 48 px
Screen-edge padding	40 px	64 – 80 px

6. Layout, hierarchy, and the safe zone

Portrait kiosks reward strong vertical hierarchy. Users scan from top to bottom, and they do not scroll — the kiosk shell typically locks scroll to prevent accidental gestures. Design as if you have one fold, and plan what goes above it carefully.

The three-band layout

Most successful kiosk screens divide the 1650-pixel canvas into three horizontal bands:

The three-band layout: hero at top, content in the middle, primary action at the bottom — exactly where a standing user's hand naturally lands.

The ergonomic sweet spot

On a 49" or 55" portrait kiosk, the comfortable tap zone for an average-height adult sits roughly between 900 px and 1500 px from the top of your canvas. Anything above 400 px requires reaching up; anything below 1550 px requires stooping. Put your primary CTAs in the bottom band, and reserve the top band for identity, branding, and at-a-glance information.

⚠️ Never put primary tappable controls in the top 300 px. The Hootboard header already lives in that vertical region of the screen, and the physical top of a 55" portrait kiosk is uncomfortably high. Users will ignore your button and reach for the shell nav instead.

7. Color and contrast in public environments

Kiosks live under fluorescent ceiling lights, in sun-lit lobbies, in dim hallways — often all within the same deployment. Design for the worst case.

Aim for WCAG AAA contrast (7:1 minimum) for all body text, not just AA. The extra margin pays for itself the first time the sun hits the screen at 3 pm.
Avoid pure white (#FFFFFF) as a full-screen background. At 55" it becomes a lightbulb. Use a soft off-white (#F5F7FA) or, better, a dark background with bright foreground text.
Prefer dark themes on large displays. Dark backgrounds with orange or white type (like the Jackson Weather example) reduce glare from overhead lighting, are easier on a standing user's eyes, and age gracefully as the panel ages.
Never rely on color alone to convey meaning. Pair color with icons, text labels, or shape.
Test with simulated sunlight. Crank your monitor to max brightness and view your design from 6 feet. If a color disappears, it will disappear on the kiosk.

8. Navigation patterns for kiosks

Kiosks work best with shallow, hub-and-spoke navigation. One home screen with big tiles, one tap to a topic, one more tap to a detail. Beyond that, users get lost and abandon the session.

Use the Hootboard shell, don't fight it

The header provides: Home, Guide, Selfie Wall, News, Events, More. The footer provides: Date/Time, Event ticker, End Session. Do not duplicate any of these in your web app. If your app is "Weather," your job is weather — the shell takes the user back home when they're done.

Session timeout and reset

The Hootboard shell resets the session automatically after a period of inactivity. Your web app should:

Start every session from a clean state — no memory of the previous user.
Never write to localStorage or cookies with personally identifiable information.
Listen for a blur or visibility-change event and reset UI state to the default screen.
Never assume the same user is still present after 60 seconds of inactivity.

Back behavior

Browser back buttons and browser history are hidden on the kiosk. If your app has internal navigation, provide your own large, labeled back control — with text, not just an arrow icon — and place it in the bottom band, never the top-right corner.

9. Performance, offline, and idle states

Kiosks are often deployed on congested public Wi-Fi or cellular backhauls. A slow app feels broken faster on a kiosk than anywhere else, because there is no "pull to refresh" and no patient user.

First contentful paint under 1 second is the goal. Preload critical assets. Inline critical CSS.
Ship a meaningful loading state — never a blank screen or a spinner alone. Show the app frame with skeleton content so the user knows they're in the right place.
Cache aggressively. Use a service worker to keep the last-known-good data on screen if the network drops.
Design an inactivity reset. If the user stops tapping for 30–60 seconds, reset your UI to its default state so the next person who walks up to the kiosk finds the app in a clean, welcoming starting position — not mid-flow where the previous user left it.
No modal dialogs and no confirmations unless absolutely required. Every extra tap is a chance for the user to walk away.
No video autoplay with sound. Kiosks are public spaces — assume sound is muted or disabled.

10. Do's and don'ts

✅ DO: One hero fact, clean hierarchy, dark theme

One big number that the user can absorb instantly
Dark background reduces glare on a large display
Three-band layout with clear hierarchy
No decoration competing with the data

❌ DON'T: Desktop-style cramming, tiny type

Type is painful to read even from arm's length on a 55" screen
Duplicates the Hootboard nav in its own header
Crams 3 screens worth of info onto one
White background becomes a lightbulb at 55"

✅ DO: Big, labeled home-screen tiles

Four big tiles, one tap to any section
Clear labels, generous spacing
High-contrast orange on navy

❌ DON'T: Tiny nav bars and hamburger menus

Hamburger menus are a mystery on a kiosk
Tiny text nav strip at top is unreachable
Breadcrumbs mean nothing to a first-time user

11. Case study: Jackson Weather

The Jackson Weather web app is a reference implementation for Hootboard kiosks. It is a good example because everything on screen earns its place.

What it does right

One hero fact. The 49° F is the single thing a user came for, and it dominates the screen. Everything else is subordinate.
Three clean bands. Identity (Jackson Township) + hero conditions at top, the visibility/wind/humidity row in the middle as a glassmorphism card, the 5-day forecast as the tertiary content — in that exact order of importance.
No duplicated navigation. The app trusts the Hootboard shell for Home, Guide, News, Events, and End Session. Its own canvas contains zero navigation chrome.
Dark, ambient background. The blurred dusk photograph gives the screen warmth without fighting the foreground text, and it holds up under both fluorescent office lighting and sun-lit lobbies.
Generous forecast rows. Each day of the 5-day forecast is easily 100+ pixels tall with plenty of horizontal padding. Nothing is crammed.
Localized to the place. "Jackson Township" appears prominently. The kiosk user instantly knows they're looking at their town's weather, not a generic feed.

If you were building it from scratch

Use Jackson Weather as your mental template for a single-purpose, ambient kiosk app:

Pick the one number or headline your audience cares about.
Give it the top ~450 pixels and render it at 120–180 px type.
Give the next ~600 pixels to 3–5 supporting facts, arranged in a single card or row.
Give the remaining space to a list of ≤ 5 items of secondary context.
Add a subtle branded background. Let the shell handle navigation.
Ship it.

12. Pre-launch testing checklist

Before you deploy to a kiosk in the field, walk through this list. Most issues that show up in production are caught here.

[ ] Viewport is locked to 1080 × 1650, no scrollbars, no horizontal overflow.
[ ] All body text is at least 32 px; no caption is smaller than 24 px.
[ ] All tappable elements are at least 88 × 88 px with 24 px of clear spacing.
[ ] No primary action is in the top 300 px of the canvas.
[ ] Primary CTAs sit between 900 px and 1500 px from the top.
[ ] Contrast ratio is 7:1 or better for all text (checked with a tool, not eyeballed).
[ ] App renders a meaningful state within 1 second on a throttled 3G profile.
[ ] A loading skeleton appears before real data, not a blank page.
[ ] Offline state is handled gracefully with cached data or a clear message.
[ ] App resets to its default screen after 60 seconds of inactivity.
[ ] No localStorage or cookies store personally identifiable information.
[ ] No browser dialogs (alert, confirm, prompt) anywhere in the code.
[ ] No window.open or links that navigate away from the app origin.
[ ] No autoplaying audio or video with sound.
[ ] App does not duplicate the Hootboard header or footer (Home, Events, End Session, clock, date).
[ ] Tested on the actual kiosk hardware — or at minimum, in a 1080×1650 iframe at the target device's DPR.
[ ] Tested at arm's length on a large external monitor: body text is comfortable to read without leaning in.
[ ] Tested at arm's length: every tap target is easy to hit while standing.
[ ] Tested with simulated sunlight (monitor at maximum brightness) — nothing disappears.
[ ] Tested with a cold cache and a warm cache; both paint quickly.

One last thing. The best kiosk apps feel inevitable — as if no other design could possibly work. That's not because their designers were cleverer; it's because they ruthlessly removed everything that wasn't essential. When in doubt, cut. The kiosk rewards restraint.

Hootboard • Kiosk Design Guide • Updated April 2026

01-engaged-user.png
60 KB Download

In this article

1. The Hootboard kiosk hardware at a glance