Screen Dressing · Journal · 5 min read

How We Build a Screen Dressing Prop (Behind the Scenes)

An interactive screen prop looks simple from the audience's seat — a glowing terminal, a trading desk, a face scanner doing its thing in the background of a shot. Under the hood, the constraints are unusually strict and weirdly fun to work within. This is a behind-the-scenes look at how a fake UI prop is actually made: one self-contained web page that fills a 16:9 screen, animates forever, and has to stay believable through hours of unattended filming without a single network call.

If you build interfaces for a living, the interesting part is the inversion of normal goals. We're not optimising for usability, conversion, or accessibility. We're optimising for being convincing on camera for a long time with nobody touching it. That changes every decision.

The hard constraint: one self-contained page

Every prop is a single index.html — HTML, CSS, and JavaScript in one file. No build step, no framework, no bundler, no npm, no CDN, no external fonts, no APIs. You can save the file, double-click it, and it runs.

Why be that strict? Because the deployment target is a stranger's laptop in a location truck with no reliable internet. A React app that needs a dev server, or a page that pulls a font from a CDN, is a page that can fail in front of a crew. The only thing worse than no screen is a screen showing a loading spinner or a 404 when the camera rolls. Self-contained means it cannot fail for those reasons.

This rules out a lot of modern conveniences and forces a return to fundamentals: vanilla JS, hand-rolled CSS, and a single requestAnimationFrame loop doing the work. It's oddly liberating.

Fill the frame, behave like a kiosk

A prop is designed for 16:9, fills the entire viewport, and never scrolls. There's no navigation, no scroll bar, no responsive mobile breakpoint — it behaves like dedicated kiosk software bolted to a wall. Layouts are built to flex to the screen so the same page reads well on a 24-inch monitor or a projector, but the assumption is always "this is the whole world, edge to edge."

Hiding every trace of "this is a browser" is part of the craft: no cursor, no chrome, no OS furniture. The illusion only holds if nothing on screen admits it's a web page.

Engineering believability

This is where most of the actual work goes. Believability isn't one feature; it's a stack of small truths.

• Always moving. A static screen reads as a screenshot. Real software is never still — cursors blink, logs scroll, gauges drift, numbers tick. There's always something in motion.
• Procedurally generated, never looping. The content is generated on the fly so it doesn't repeat on a noticeable cycle. A short loop is the fastest way to break the spell when a take runs long, so values, names, and events are produced continuously from randomised pools.
• The right kind of imperfection. Real systems have latency, errors, retries, and ugly monospaced fonts. Polished, perfectly aligned UI reads as fake. The hacker terminal intrusion suite, for instance, leans into stutter, dense logs, and the satisfying march toward ACCESS GRANTED — because that's the texture audiences expect.
• Plausible data. A Bloomberg-style trading desk needs tickers that move like real markets — correlated, volatile but bounded, with the odd spike — not random noise. A facial recognition scanner needs scanning landmarks, confidence scores, and a match that lands with a beat. The believability is in the behaviour, not just the look.
• Tone. Everything is subtly satirical — fictional agencies, absurd departments, ridiculous project names — kept just plausible enough that it never winks at the camera but rewards anyone who reads the fine print.

Believable for hours, unattended

The brutal test is the long, locked-off shot where the screen runs for an hour with nobody touching it. That demands two things most web apps never worry about:

1. No memory leaks. A page that slowly eats RAM will stutter or crash three hours into a shoot day. Animations have to recycle DOM nodes, cap their buffers (a scrolling log can't grow forever), and keep the loop lean. We build for the marathon, not the demo.
2. No obvious loops. Tied to the point above — anything that repeats on a fixed cadence gets noticed when the footage is slowed or held. Timing is jittered, sequences are shuffled, and "events" fire on randomised intervals.

Get those two wrong and the prop fails exactly when it matters most. Get them right and it can run all day.

No network, by design

The only network call any prop makes is a tiny analytics tracker, and even that is non-blocking — if it can't reach the internet, the screen doesn't notice. Beyond that, zero requests. No fonts, no APIs, no telemetry, no "phoning home." This isn't just a reliability choice; it's a trust choice. A prop on a closed set should never depend on, or leak to, the outside world.

When the catalogue doesn't have it

The catalogue covers the common beats — terminals, surveillance, vitals, mission control, finance — but productions always have specific needs: a particular interface, a fictional brand built to your world, a hero readout that has to hit an exact line of dialogue. That's the custom-build service. Same constraints, same polish, tailored to the script.

If you're a developer, the constraints above are basically the whole spec, and they make for a genuinely fun weekend project. If you're a production, you get the result without the weekend.

Browse the full catalogue of interactive screen props to see the approach in action, or request a custom build for a screen that doesn't exist yet. Either way, the promise is the same: open it in a browser, point the camera, roll.

← All Journal posts