All 20 demo types

01One or many — there is no cap

The most common mistake is to treat these twenty types as a menu where you order exactly one dish. They are not. They are a paint palette. A lesson is a painting, and you pick up as many colours as the canvas asks for — sometimes one bold stroke, sometimes a dozen blended. A thin idea may need a single diagram. A rich, multi-beat lesson can stack a slide deck to set the scene, an annotated SVG to show the anatomy, a simulator for the reader to drive, a state panel to read the situation, and a quiz to check it stuck. All of that, in one lesson, is not too much — it is precisely the point.

• One is fine. A single well-chosen flowchart can carry a whole lesson about a branching process.
• Many is fine — and encouraged. Chain several in section order; each gets its own plain-language intro.
• Merging is fine. Fuse two exemplars into one widget — a flowchart whose nodes drive a state panel, say.
• Reusing across lessons is fine. The same type, framed for a different teaching job, teaches better than forcing a fresh one.
• There is no maximum. Fit before count — never pad a thin beat, never starve a rich one. Use as many as the teaching genuinely asks for: one, or forty.

Build a lesson's demo set

Below is the feature-flags format (type 19) rewired to this page's idea. Each switch turns on a demo type for an imagined lesson. Some types depend on another being present first — a quiz to "check it stuck" only makes sense after something has been shown; a worked example needs the concept explained. Flip one on without its support and a warning slides in. The summary tells you how many demos your lesson uses now — and notice it never stops you for using too many. There is no cap.

const requires = {
  g19_explain:    [],                 // base beat
  g19_show:       ['g19_explain'],     // show needs the concept first
  g19_try:        ['g19_show'],        // drive what was shown
  g19_check:      ['g19_try'],         // check what they tried
  g19_summarise:  []                  // independent — add anytime
};
// no rule caps the size of the set — only consistency is enforced.

02The choice is a per-beat debate

So if it isn't "always tabs" and it isn't "always one", how do you choose? You break the lesson into its beats and debate each beat on its own. A beat is a teaching move: explain how it works, then show it, then let them try, then check it stuck. Each beat has exactly one teaching job, and each job has a small short-list of types that do it well. The debate is short and explicit, and you record the verdict so the next person sees the reasoning, not just the result.

The debate has four moves. Run it once per beat:

• Name the job in one sentence — explain how something works, compare options, show a process over time, read the current state, teach through a failure, let the reader drive, summarise, narrate a change, or tune parameters.
• List two or three candidates from the job→type map for that sentence.
• Pick the best fit with a one-line reason — and name the runner-up you rejected and why. The reason is the debate.
• Decide how many. One beat is one demo; a multi-beat lesson chains several; two tightly-coupled jobs can fuse into one widget.

Walk the choice, one question at a time

Here is the flowchart format (type 13) rewired as the chooser itself. Pick a teaching job at the top, then press Next to watch the decision descend through the gates to the best-fit demo type. Each "yes" commits a family; a clean run lands on a specific type. This is move-3 "pick" of the debate, made mechanical.

The job → candidate-type map

The flowchart commits fast; the real short-list is richer. This is the full map every "list candidates" move pulls from — the runner-up you name will usually be the second row of the same job.

Name the job, reach the type

One more rewiring of the same idea, this time as the state-machine format (type 08). Each button is a teaching job; pressing it moves the highlighted node to the family that does that job, and the readout names the exact type plus its runner-up. It's a tiny machine: (start, job) → type. Reach a type, then reset to try another job.

03Which demo at which loop moment

This is a course about the loop LEARN → ANALYZE → EXECUTE → VERIFY, so the most useful way to read the palette is by where in the loop each type does its work. A demo is not decoration; it makes a specific moment of the loop seen and felt. The captions on each card below name that moment exactly. Here is the shape of it:

Read it as a rough assignment, not a law: exploration and research types tend to feed LEARN and ANALYZE (see the real state, weigh options); design, prototype and code types feed EXECUTE (build the one bounded unit); report and editor types feed VERIFY and the gates (prove, read state, tune). Many types serve more than one moment — which is why the per-beat debate, not a lookup table, gets the final word.

Cover the palette — a coverage tracker

A complete course exercises most or all twenty types; collapsing to one or two is a bad smell — the reader stops engaging. Here is the status-report format (type 11) rewired to track palette coverage across this very course. Press Build next lesson to fold in a lesson's demo set and watch the tiles climb, or flip Auto-build to watch the eight lessons assemble. The table shows, per type, how many lessons reached for it.

04The whole idea in seven slides

Before the catalogue itself, here is this page's argument compressed into a deck — one idea per slide. Click forward, or use the keyboard arrows.

05The catalogue, grouped by family

The twenty types split into seven families by the kind of work they do. Inside each card: the number and name, a one- or two-line note on when and how to use it in the loop, a dark-safe thumbnail of its format, and an Open link to the full standalone demo. A star (★) marks the highest-value types.

06Quick check

Five questions on the one rule and the debate. Pick an answer to grade it on the spot; the right one turns olive and a short note explains why.