Demo type · 02

Show variants of one thing

Use this when you want to put several versions of the same idea side by side — layouts, deployments, plans — and let the reader switch between them to feel the trade-offs.

Exemplar This page is a copyable pattern. To use it in a course, lift the demo block below into a lesson built from assets/lesson-template.html — keep the design tokens and the .tech-toggle pattern intact.
1

The idea


Imagine the same small web app — a booking page for a yoga studio. There is no single right way to run it. You can put it on one rented computer, on three computers behind a traffic cop, or hand it off to a cloud that conjures computers only when someone visits. Each choice trades money against safety and effort in a different way.

The switcher below lets the reader try on each option. Click a card and the picture changes, and a short note explains what you just gained and what you gave up.

Think of it like… choosing how to get to work. A single bike is cheap but if it breaks you are stranded. A small car fleet keeps you moving if one breaks down. A ride-hailing app means you never own a vehicle — you pay only per trip, but you are at the mercy of the service.

What this format is for

An exploration / variant gallery presents N versions of a single subject so the reader can compare them in place rather than scrolling between separate diagrams. The core UI is a switcher: a tablist of variant buttons that swaps one inline SVG plus a trade-off panel. State lives in JS and is mirrored with aria-selected so the active variant is announced.

When to reach for it

Use it whenever the teaching job is "here are the shapes the same thing can take" — deployment topologies, page layouts, data-model options, pricing tiers. Avoid it for sequential steps (use a flow) or for a single canonical answer (just draw it once).

2

Three ways to deploy the same app


Pick a deployment layout. The diagram and the trade-off note update together.

Visitor browser App server 1 VM · app + web DB single point of failure Load balancer app server #1 app server #2 app server #3 DB API gateway fn() on demand fn() on demand fn() on demand managed DB
Read left → right: visitor reaches one app server, which talks to the database.

Single VM

Everything — web, app, files — lives on one rented machine. Cheapest to start, simplest to reason about.

+Lowest cost; one bill, one machine to learn.
+Easy to deploy: copy files, restart the service.
If that machine dies, the whole site is down.
A traffic spike has nowhere to overflow.
Monthly costlow
Resilienceweak
Ops effortlow

Anatomy

The controls are a role="tablist" of real <button> elements. Clicking one sets aria-selected="true" on it (and false on the rest), shows the matching role="tabpanel", swaps which SVG <g data-diagram> group is displayed, and rewrites the SVG's aria-label + the figcaption so screen-reader and sighted users stay in sync.

Keyboard

Arrow keys move between tabs and activate them (roving focus), matching the WAI-ARIA tabs pattern. Home/End jump to the first/last variant. All three diagrams ship in one inline SVG so switching is instant and needs no network.