Explorable Deck

Explorable deck

Build a Quarto reveal.js deck that teaches the way a good explorable does, but inside the frame a talk imposes: linear, timed, driven by a presenter, 1280×720 with no scrolling. The explorable's non-linear tree becomes a spine of counted slides plus an appendix of side rooms. Its playables become stages the presenter operates while talking. Its "static read must work" becomes: the printed PDF must carry the argument on its own.

The sibling skill explorable-explanations builds the website version. This one produces a deck, and it reuses the website's models and numbers when one already exists for the topic.

What you produce

One folder per deck, rendered with quarto render index.qmd:

<deck>/
  index.qmd            the deck: YAML header, one `##` per slide, `::: {.notes}` on every slide
  theme/deck.scss      tokens, faces, layouts, the stage, controls, figure frames
  theme/fonts.html     the three web fonts (system fallbacks in the theme)
  js/lib.js            drawing helpers and L.DATA, the single home of every number a chart uses
  js/deck-charts.js    the stages: CH['name'] = (el, {animate}) => cleanup
  js/include.html      the script tags Quarto appends to the body
  figs/*.svg           the source's figures, converted from PDF and recoloured (build output)
  figs/convert_figs.sh, figs/restyle_figs.py
  shoot_chrome.py      screenshots every slide, prints console messages
  README.md            how to render, check, present; where the numbers come from
  plan.md              the talk script (see below)

scripts/new_deck.sh <path> copies the template in assets/template/ and the scripts into place. Start every new deck from it: the template already solves the reveal.js traps listed in the notes reference.

Read first

1. The Explorable Explanations Playbook: Nicky Case, Bret Victor, Steven Strogatz. Read §1–4 and §10 closely and skim the rest once per project. It explains why the craft rules exist so you can apply them with judgment. Its three-act arc, ladder of abstraction, empathy for the perplexed reader, and message → mechanics apply to a talk unchanged. Its §6 (interaction craft) and §9 (the frontier) describe the website; for a talk, the interaction section of deck-craft.md overrides them.
2. Deck craft: how the explorable craft translates to slides, and what goes wrong. Read before planning, and again when reviewing.
3. Quarto and reveal.js notes: the template's layout vocabulary, the stage API, the figure pipeline, rendering, screenshots, PDF export, and the traps. Read before building.
4. Look at the four screenshots in references/example-deck/ of a finished deck built this way (a hook with two characters, an animated reveal stage, a paper figure beside prose, a coefficient plot), and at Case's Evolution of Trust for the broader vibe. The example deck is a housing-returns paper (Bäckman, D'Lima and Khorunzhina, "Anna and Bo"); if the source is that paper or a neighbour of it, borrow nothing from the examples but the register. For any topic, take the register, not the content: the topic decides the colours, the characters and the shapes.

Working rhythm

1. Read the source. The paper, notes, or codebase, and any existing explorable for the topic. If one exists, its lib.js data object and chart code are the deck's starting material: copy them rather than redrawing, so the two never disagree on a number.

2. Fix the frame before writing a slide: the audience (Strogatz's traumatized, perplexed or naturals, and which one the slide text is written for), the length in minutes, the venue. When the user has not said, assume a 20-minute conference talk for a mixed academic room, and say so. Length changes the shape, not just the count:

   slot	counted slides	stages	build-ins	bets	literature slide
   12 min	8–10	1	1	1	no, one sentence on the hook
   20 min	13–16	2–3	1–2	1–2	one slide
   45+ min	25–35	3–5	2	one before each BUT	one slide, plus recap slides as cognitive gates

   Everything a questioner might want goes in the appendix; in a long lecture the rooms move into the spine.

3. Write plan.md as a scriptwriter: the one big thing in a sentence, the cause → effect chain with its THEREFORE and BUT turns, then slide by slide what the room sees, what the presenter does with each stage, what they should notice, and which appendix room each question opens. Name the characters and the four semantic colours here.

4. Scaffold with scripts/new_deck.sh. Give each of the four colour tokens a topic alias in theme/deck.scss (--gain: var(--primary);) and paint the charts with the aliases; never rename the generic tokens, because the classes and the notes reference depend on them. Fill L.DATA and convert the source figures you will use. If a dataviz skill is available, its rules on marks and colour apply inside the palette; the palette itself comes from this theme.

5. Build the hook and the first section, render, screenshot, and look at every screenshot yourself before going on. In an interactive session, show this batch to the user before building the rest.

6. Build the rest. Every stage has a caption that says whether it is measured or stylised, a finished state for ?static and print, and a speaker note that says what to do with it. Every evidence slide has a source line. Titles are assertions.

7. Check: quarto render index.qmd, then python shoot_chrome.py. Fix every console message and every slide whose content reaches the bottom edge of the frame, where the progress bar and menu button sit. Read all the screenshots, not just the ones you changed.

8. Adversarial review with independent subagents, using the prompts below. Then fix what they found.

9. Creative director pass, prompt below, and apply the ideas that survive the craft rules.

10. Write the deck's README and tell the user where the deck is, how to present it (S speaker view, F fullscreen, O overview, E print view then print to PDF), and which stages are live.