Content design

A signage webpage isn't a website with bigger text. The viewing context, the duration of attention, the lighting, the lack of any input device — all of it changes the design rules. This page is a starting-point distillation of those rules.

The viewing-distance rule

Web design assumes one person, 18 inches from a 13" screen. Signage assumes a passerby, 20-30 feet from a 55-65" screen.

A useful approximation: scale your design for a 4× viewing distance. Whatever font size you'd use on a website, multiply by 4. Whatever element density you'd accept, divide by 4.

Concretely:

• Body text: 48-72 px minimum on 1080p displays. (Web body is typically 16-18 px.)
• Headings: 100-200 px. Yes, really.
• Logos / hero imagery: sized as if they need to read across a room.
• Margins: generous. Don't crowd the edges.

Less, slower

A passerby gets 2-3 seconds of attention while walking past. Information density that works for a website overwhelms in that window.

Rules of thumb:

• One main message per "slide." If you're tempted to put a bullet list, pull it out into separate frames.
• Long dwell times. If your content rotates between frames, give each at least 8-10 seconds. Faster cycles look harried.
• No inline scrolling text. Scrolling tickers were popular in 90s signage; they're hard to read in passing and look dated. Static frames win.

The exception: dense agenda displays in dedicated areas (a registration kiosk, a session schedule next to a coffee station) — the audience is stationary, dwelling, and looking specifically at the content. Higher density is fine there. Match design density to the viewer's posture.

Contrast, color, brightness

Signage runs in bright, busy environments. Subtle color choices that work on a designer's monitor disappear at the venue.

• High contrast. Dark text on light, or light on dark. Avoid mid-tone-on-mid-tone combinations.
• Limited palette. 2-3 colors plus neutrals. The visual hierarchy works only when restraint forces it to.
• Avoid pure white backgrounds at high brightness — they fatigue the eye and bloom in lobby lighting. A soft off-white or a brand background color reads better.
• Test under bright light. What looks great on your office monitor washes out in a window-lit lobby. See Display selection → Brightness.

Animation

Movement on signage attracts attention but quickly becomes annoying. The right amount is "barely any."

• Slow, subtle transitions between frames — fades, gentle slides. Never fast cuts.
• No bouncing, blinking, or attention-getting motion in the body content. People can't read while their eye is being yanked around.
• Looped video is fine but no autoplay audio — see Audio / volume strategy.
• Performance matters. The kiosk renders in Chromium on a low-power CPU. Heavy CSS animations or WebGL can drop frames. Test on the actual hardware.

Autoplay rules

The desktop sign starts in autoplay-allowed mode (no user-gesture required). Most browser autoplay restrictions don't apply.

• Video autoplay works. Set autoplay muted loop playsinline on <video> and it'll just go.
• Web Audio API works but only after loadedmetadata or similar. If you must have audio, gate it on a content event, not page load.

Audio / volume strategy

Default DisplaySync deployments have speakers physically disconnected — event audio is a separate AV system, and most signage is intentionally silent. If you do need audio:

• Belt-and-suspenders mute. OS-level mute plus a muted attribute on every <video> element. Don't trust either alone.
• Chromium auto-mutes for autoplay. Rely on the browser behavior AND the explicit mute attribute — they're additive, not redundant.
• Captions over audio. Bilingual audiences benefit; venue acoustics rarely cooperate with signage audio anyway.
• Fall back gracefully. If an <audio> element fails to load, the page should not block content rendering. A silent slide is better than a blank wall.

Mixed content (HTTPS / HTTP)

The kiosk loads URLs in Chromium with normal mixed-content rules:

• HTTPS pages can't load HTTP subresources. Images, scripts, stylesheets — all must be HTTPS.
• HTTP pages can load HTTPS subresources fine, but you should serve everything over HTTPS anyway.

If your content origin is on HTTP today (rare, but happens with venue-internal pages), either upgrade the origin or front it with a CDN that does TLS termination. See Content not loading → Mixed content.

Designing for offline survival

The desktop sign relies on Chromium's standard HTTP cache for webpages. When the network drops, the kiosk keeps rendering whatever's already in the cache — so the page can keep working as long as its assets were cache-friendly to begin with. To take advantage of this, design for the page to keep working when fetches fail.

Patterns that survive offline:

• Static HTML + cached assets. The simplest case — Chromium's cache holds it; the page keeps rendering.
• Service workers for offline-first behavior. The signage equivalent of a PWA. When network fails, fall back to cached state.
• Time-aware rendering. If your content shows "now" — current time, current session — use the kiosk's clock, not a network-derived time. new Date() works without network; an API call doesn't.

Patterns that break offline:

• Live API fetches in render path. Page shows "Loading..." forever when the network drops.
• Time-since-last-update timers that depend on a server poll.
• Embedded third-party widgets (chat, social feeds) that fail to a default error state.

A content origin that produces correct HTML on every request and includes its assets via cache-friendly URLs is the right answer for almost every signage use case. Avoid SPA architectures unless you have a specific reason — they trade simplicity for offline fragility.

Cache control

The kiosk respects standard HTTP cache headers. To control how aggressive the cache is:

• For HTML: Cache-Control: no-cache or max-age=0. Forces a re-validation on every load. The kiosk still falls back to cache when offline; this just makes online updates immediate.
• For static assets (CSS, JS, images): use fingerprinted filenames (app.a8f3e2.css) with Cache-Control: max-age=31536000. Long-cached, safe-to-evict by name.
• For semi-dynamic content: Cache-Control: max-age=60 or so. Updates appear within a minute; offline still works for an hour.

The default — no cache headers — usually works, but you'll get less control over update timing.

URL stability

The URL you assign to a sign should be stable across content edits. If your CMS regenerates URLs every time you publish, you're forcing a re-assign on every change.

Patterns:

• Pretty URLs: https://signage.example.com/main-lobby rather than ?id=8294.
• Server-side routing: the URL stays constant; the content underneath updates via your publish flow.
• One URL per "wall position," not per piece of content. The wall is "main lobby"; what's on it changes over time.

This way, your DisplaySync side is set-and-forget — the content team controls what appears on each wall by editing the page their URL serves.

Iframe-friendly: not required

The kiosk doesn't iframe your content — it loads it as the top-level document. So X-Frame-Options: DENY and frame-ancestors CSP directives don't apply.

But if you embed third-party widgets inside your content, those widgets see iframe-related restrictions normally. A page that embeds an iframe pointing at a service that returns frame-ancestors: 'none' will fail to render the embed.

Testing

Always test on actual signage hardware, in approximate venue lighting, at realistic viewing distance before deploying.

A useful workflow:

1. Author the content
2. Open it in Chrome on your laptop, zoom out to make the laptop screen approximate a 65" at 20 ft (around 25-33% zoom)
3. Read it from across the room. Can you?
4. Load it on a real test kiosk at the same distance. The lighting and the panel will affect it; budget for this.

If something looks weak in step 3, it'll look worse in step 4.

Common patterns

• Pre-show splash: brand mark + "Welcome" + start time. Static, slow fade between two backgrounds.
• Sponsor loop: sponsor logos rotating with 8-10s dwell each. One color per sponsor, one logo at a time.
• Schedule display: dense (passersby dwell), portrait orientation, large typography for the next session.
• Wayfinding: static unless the venue is unusual; an arrow + "Hall B →" reads in 1 second.
• Live data display: session attendance, social feed, score — refresh once per minute, never more.

A combined "sign loop" page that auto-rotates through these patterns is a great default — see Assigning content for the assignment workflow.

V1 content-rotation playbook

DisplaySync V1 displays one URL per sign. Rotating content across the day requires one of two operator patterns:

Pattern A — URL with time-of-day branching

• The customer's content team writes a single page that checks the current time on load and renders the right view for the current hour
• Pros: single URL, no operator action during the show
• Cons: customer owns the rotation logic; can't be changed without a redeploy

Pattern B — Per-session reassignment

• Operator opens Sign detail → Content tab → updates URL → saves
• Sign refreshes within a few seconds
• Pros: DisplaySync-side; ad-hoc changes are immediate
• Cons: needs an operator at the dashboard during run-of-show; OK for 1-2 rotations per day, painful at 10+

Which to use when

• Pattern A for predictable schedules with more than ~5 transitions per day
• Pattern B for ad-hoc swaps (panel runs long; sponsor wants to add a screen)
• Mix freely — a single fleet can use Pattern A on some signs and Pattern B on others

See Dashboard tour → Sign detail (click any sign card) for the Content tab walkthrough.

See also

• Display selection — the hardware side of the same trade-offs
• Network resilience — why offline-survivable design matters
• Content not loading — when content goes wrong on the wall
• Stability over features — why static beats dynamic for signage