Constructive Distractions
Living Presentation
A skill for turning raw content — a Confluence page, a data pull, a rough narrative — into an interactive web presentation.
Built for leadership communication, where the medium usually defaults to a deck. A browser isn't a deck.
↓ Download skill fileSee it in action
Two examples — both single self-contained HTML files.
Why not slides
Slides force every story into the same vehicle: a horizontal sequence of static rectangles. That format works for some things and fights against others. When the story has data worth exploring, or a model worth poking, or a product experience worth showing — slides describe it. A browser can do the thing itself.
Animated data
Charts that draw themselves on scroll, counters that count up when they enter view. The data reveals instead of sitting static.
Interactive exploration
Parameter sliders that let the audience drag through assumptions. Carousels for stepping through a set of ideas. Click-to-expand cards for optional depth.
Live demos
Actual working component behavior in the presentation itself — not a screenshot of what it would do. A notification that fires and auto-dismisses. A side panel that slides in.
The process
Six steps, in order. Skipping the intake is the most expensive mistake.
Intake
Nail the ask, the audience, and the raw material before touching the layout. What single decision or belief does this need to create? Who is in the room? How are they consuming it — presented live or read async?
Shape
Pick a narrative structure. For leadership: SCQA (Situation → Complication → Question → Answer), answer-first. For vision or change: Sparkline (oscillate between what-is and what-could-be). For walkthroughs: 3-act. The throughline — the one sentence the audience repeats afterward — gets written before anything is built.
Layout
Pick the spatial grammar based on how it'll be consumed. Vertical scroll for async reads and data-rich stories. Horizontal sequence for live, controlled delivery. Spine-and-ribs when there's a clear arc with sections that reward exploration — a vertical scroll carries the story, horizontal and expandable "ribs" hold detail and interactive sections, then return to the spine.
Propose
Write a short treatment — one paragraph naming each section's narrative beat and layout pattern. Surface 2–3 real choices, not open questions. The user decides what matters; everything else gets built.
Render
Build a single self-contained HTML file. React + Tailwind via CDN, no build step, opens on double-click. Patterns are copied in from the storybook, not imported — so the file stays portable and self-contained.
Self-check
Can a stranger state the throughline after one pass? Is the ask visible early? One idea per view? Does every section move the throughline, or does something need to be cut? Opens and runs from a double-click at presentation size?
Choosing the layout
Narrative first, layout second. The spatial grammar serves the story — it isn't picked for novelty.
Situation
Layout
Why
Presented live, tight time, one idea at a time
Horizontal sequence
Discrete beats you control; big type; feels like slides but cleaner
Sent to read async, data-rich, making a complex thing simple
Vertical scroll
Reader controls pace; progressive disclosure; numbers reveal as they scroll
You need them to believe a model, tradeoff, or number
Interactive explorable
Let them drag the assumptions — belief beats assertion
Demonstrating an actual product experience
Demo / embedded UI
Show the real thing, don't describe it
A narrative spine with optional deep-dives
Spine-and-ribs
Vertical scroll carries the arc; horizontal and expandable ribs hold detail
The output is always a single file that opens on double-click and presents at whatever size it'll be shown. No build step, no dependencies, no deploy. If the team wants to take it into a production stack, the component structure ports cleanly into any React + Tailwind setup.