Assigning content

In v1, "content" means a webpage URL. You assign a URL to a sign (or a set of signs); the kiosk loads it in a fullscreen browser and keeps it there. Change the URL, and the sign changes within ~5 seconds. Take the URL down, and DisplaySync notices and notifies you before the wall goes blank.

This page covers the assignment workflows, what reachability monitoring actually checks, and how the desktop sign's offline cache keeps the wall correct when the URL is briefly unreachable.

How content assignment works

Each Sign record has a settings.url field. Set it, and the kiosk loads it on the next sync. The kiosk also persists the assigned URL locally, so the sign keeps showing the correct content across reboots and network outages.

Two places to set the URL:

Both call the same backend endpoint and emit the same sign:display_content event over the WebSocket.

Assigning from the dashboard

1. Dashboard → Events → [your event] → Signs → click a sign to open its detail page.
2. Assigned URL field → paste the URL → Save.
3. The kiosk on the wall updates within ~5 seconds.

What the kiosk actually loads

The kiosk renders the URL in a Chromium-based fullscreen browser (Electron's BrowserWindow). The page loads with:

• Cursor hidden (always hidden via CSS injection)
• Scrollbars suppressed unless the page explicitly enables them
• Basic auth supported via the URL form https://user:pass@host/path (avoid where possible — credentials are visible in the dashboard)
• Cookies + localStorage persisted on the kiosk between reloads (lets your page implement its own state)

Behaviors to be aware of when designing content:

• X-Frame-Options: DENY on the content origin doesn't matter — the kiosk doesn't iframe the URL, it loads it as the top-level document.
• Mixed-content rules apply: HTTPS pages can't load HTTP subresources. Serve everything over HTTPS.
• Audio autoplay is subject to Chromium's standard autoplay policy (muted-only by default). Most signage is silent by design.
• Navigation is allowed within the origin; cross-origin top-level navigation is blocked and triggers a return to the assigned URL.

For deeper detail on what holds up in production, see Best practices → Content design.

Reachability monitoring

The desktop sign does an HTTP HEAD request to the assigned URL every 60 seconds. The result is reported back via the WebSocket as either a healthy or unreachable signal.

On unreachable (request fails, returns 5xx, or times out):

1. After two consecutive failures (a single failed check is treated as transient), the sign emits sign:content_unreachable to the backend.
2. Dashboard immediately marks the sign's content as Unreachable with a red indicator.
3. The backend defers notifications by 60 seconds, giving the content origin a chance to recover before paging anyone. If reachability comes back inside the window, no notification fires at all.
4. After the deferred window, notifications go out to subscribed users (in-app, push, email — see Notifications).
5. The sign keeps displaying the cached version of the content, if it has one. The wall doesn't go blank.

On recovery (HEAD succeeds again):

1. Sign emits sign:content_recovered.
2. Dashboard clears the Unreachable indicator.
3. A "content recovered" notification fires.
4. The sign reloads the URL to pick up any changes.

The 60-second cadence is deliberate: tight enough to catch failures within ~2 minutes, loose enough not to look like a DDoS to your content origin. Don't reach for a custom interval; if the default doesn't work, your content origin probably has a rate limit or caching problem worth fixing.

Offline cache

When a sign loses network connectivity, anything already loaded into the kiosk keeps rendering. The kiosk relies on Chromium's standard HTTP cache for webpages — there is no DisplaySync-specific cache layer for live content.

What this means in practice:

• Brief outages (under a few minutes): invisible. The wall looks the same. The dashboard shows the sign as Offline; the wall keeps working.
• Long outages (hours): the cache continues to display correctly if the page works without network calls. If your content does live API fetches, those will fail — design for it.

For content design tips that maximize offline survival, see Best practices → Content design.

Changing content during an event

A few practical patterns:

• Pre-show vs in-session swap: assign the pre-show splash URL across the fleet, then swap to the in-session URL when the session starts. Each wall picks up the new URL within ~5 seconds.
• A/B test: assign URL A to half the walls, URL B to the other half. Compare engagement, then flip everyone to the winner.
• Emergency override: for "venue is evacuating, show emergency notice" scenarios, point each wall at the same emergency-notice URL. A single sign-loop page can also serve here so a content-side change propagates instantly.

Verifying assignment

After assigning, confirm the change took:

• Dashboard: the sign's detail page shows Assigned URL matching what you just set, and Last content update within the last few seconds.
• Heartbeat card shows reachable status.
• On the wall: the URL is displayed.

If the dashboard reports the URL changed but the wall hasn't updated, the kiosk may have lost its WebSocket connection — check Sign shows offline.

What's next

• Monitoring — how to interpret heartbeat, uptime, and device-info cards once content is live
• Notifications — channels for the unreachable / recovered alerts that come out of reachability monitoring
• Best practices → Content design — how to build pages that hold up on a wall