Math Demonstrator
“Pick a concept, type the operation, watch it solved with virtual manipulatives.”
openIllustrative team — open seats are real invitations.
- Build mode
- adopt-and-extend
- Built on
- apps/math-demonstrator + @k12vls/math-demonstrators
- Output
- interactive web app
The brief
What it is, and why a teacher says yes
The pain point
Some operations are far easier to show worked than to narrate — regrouping when you “carry the one,” unbundling a ten to subtract, building a/b from unit fractions. A teacher at the board wants the operation itself to move: enter the numbers, watch the manipulatives do the work. A marker and a static whiteboard can't animate the regroup; building that animation per operation is out of reach mid-lesson.
What it does
A web app where a teacher (or a student at the board) picks a concept from the demonstrator selector → enters the specific operation inside that demonstrator (e.g. 27 + 15 in Base-10 Blocks) → a shared playback engine animates the steps → it's projected live and stepped through at the teacher's pace. Twenty-three demonstrators are wired in today (base-10, fraction bars, number lines, unit circle, …), so one URL covers a wide span of K-8 concepts. The app today is concept-pick-first — the selector is the front door, and the operation input lives inside each demonstrator; a typed-operation-routes-itself front door would be a builder extension.
Why it's adoptable
It serves a real, projector-friendly teaching moment — regrouping and unbundling demos — grounded in the virtual-manipulatives and video-based-instruction research. And unusually for a Tier 2: the build already exists. The shipped concept-pick-then-type app is real and runnable, so an AI Champion can pilot it now rather than waiting on a build-then-pilot cycle — the rarest thing to find at this tier. What a builder would extend is polish like operation-first routing, not the core experience, which already works.
What the teacher receives — a synthetic example
blocks combine → regroup ten ones into one ten ↑
One URL, 23 demonstrators · projected · students never log in.
The operation input — “the whole app” — vs. starter #8's single embedded demonstrator.
Illustrative mockup. All example data is synthetic — no real student data.
The graduation signal
“Built” doesn't count — real, repeated use does. Here's the ladder.
- 1
Pilot
A teacher opens it on the board the first time an operation is hard to draw and steps through a live demo. (teacher-side)
- 2
Active use
The teacher reaches for it again — a second and third time, a different unit, a different concept — at “show, don't tell” moments. (teacher-side)
- 3
Sustained MAU
Sustained teacher-side MAU during instruction across multiple lessons and units, not a one-off classroom demo. Students never log in, so graduation is teacher-side MAU; the student participants — which the program counts separately, not as logins — are estimated from the classes served. (teacher-side)
Tier 2
Why this is Tier 2
It isn't assembled from blocks, and it costs more to take to a classroom. Naming both burdens honestly.
- Net-new, not assembled. It is its own Next.js app with an animation/playback surface — not a thin wrapper that picks a standard and prints a packet. There is no “assemble these two blocks into a PDF” path here; the app is a real product with its own UI, routing, and deploy.
- Interactive, not paper. Because the teaching is the animation, the output has to be a live screen — which means a URL, a projector, and possibly school IT to reach the projected device. That forgoes the zero-IT / zero-login / zero-data advantage the PDF starters lean on. The artifact can't be handed over on paper; it has to run.
- The lesson it models. When an idea genuinely needs interactivity — when the animation is the teaching and a printable can't carry it — the heavier path can be worth it. But “heavier” only changes the support and review path, not the adoption bar: the AI Champion still secures a sponsoring teacher and still clears safeguarding before anyone deploys. Tier 2 is not a license to skip the gate; it's a flag that the gate has more to check.
- Two ways to use the same components — and they are different tiers. Adopt the whole app (this doc) → Tier 2: you deploy apps/math-demonstrator as a standalone product with its selector, per-demonstrator operation inputs, and the full 23-demonstrator catalog (net-new surface, Low–med load, zero student-data exposure; the margin over Lowest is the net-new re-confirmation burden, not stored data). Embed one demonstrator via the @k12vls/math-demonstrators block in your own thin solution → Tier 1: that lighter on-ramp is starter #8 Animated Concept Coach, inheriting the block's no-data contract. Same components, two tiers — set by what you adopt (app vs. block), not by the animations themselves.
For the AI Builder
How you build it
The honest build path — what it builds on, the rough assembly, the data flow, and the gaps the blocks don't give you for free.
Blocks it builds on
- apps/math-demonstrator (sibling repo) — a Next.js app whose home page renders a demonstrator selector (“Choose a visualization to explore”); picking a concept routes to ?demo=<code> and mounts that demonstrator's component, which carries its own operation input. This is the thing you adopt — a thin shell over the block, mostly selector, routing, and mount glue (app/page.tsx imports DEMONSTRATORS, DemonstratorSelector, getDemonstratorByCode, registerAllDemonstrators).
- @k12vls/math-demonstrators — the extracted block the shell renders. 23 demonstrators ship today (area-model, base10, fraction-bars, fraction-operations, integer-number-line, unit-circle, number-bonds, ten-frame-filler, …), each a per-demonstrator subpath export owning its own input — e.g. base-10's Base10OperationInput feeds parseOperation, which reads strings like 27 + 15 or 42 − 17.
- @k12vls/math-demonstrators/engine — the shared playback engine and Controls (next/previous step, play/pause, restart, speed, plus optional sound/music toggles). Demonstrators render through this; you drive animation here, never by hand.
- @k12vls/math-demonstrators/registry + registerAllDemonstrators() — the catalog/registration the selector reads. It registers all 23 demonstrators (a catalog for the picker, not a lightweight router) — there is no operation-string-to-demonstrator matching in what ships.
Rough assembly
- 1Clone the shell. Stand up apps/math-demonstrator and confirm it builds against the published @k12vls/math-demonstrators block. The app is the shell; the block is the substance.
- 2Selector → demonstrator. The shell calls registerAllDemonstrators() and renders DemonstratorSelector over DEMONSTRATORS; picking one routes to ?demo=<code> and mounts its component. The teacher then enters the operation inside that demonstrator (base-10 parses it via parseOperation).
- 3Animate via the engine. Each demonstrator renders through /engine in a large, projector-friendly area, surfacing the shared Controls (next/previous step, play/pause, restart, speed).
- 4Extend, if needed. Two honest paths: (a) to cover a new operation type, add or improve a demonstrator in the block (and its registry entry) — the shell picks it up; (b) to offer the slicker “type the operation and the app picks the demonstrator” front door the tagline gestures at, build that routing yourself over the registry — it doesn't ship.
- 5Deploy. Ship the app at a URL the teacher can open on the projected device.
The data flow
/engine animates the steps.Caveats — the honest gaps
Scope boundaries
It's a projected demonstrator, not a student tool — it doesn't add logins, save or replay student sessions, or track who watched what; the moment it does, it stops being this Tier 2 starter (product creep) and breaks the no-data contract that holds the Low–med rating (safeguarding creep).
For the AI Champion
Taking it to a teacher
The adoption kit — the pitch, the pain it lands on, the objections you'll hear, and what a real pilot looks like.
The 30-second pitch
“You know when you're at the board and you want to show why we carry the one, not just say it? Open this, tap Base-10 Blocks, type 27 + 15, and the blocks combine, then ten ones bundle into a ten and slide up — live, at your pace. Same deal for fractions, number lines, the unit circle — 20-some concepts to pick from. It's a web page you open on the projector; students never log in.”
The pain it lands on
The mid-lesson moment a teacher already reaches for — wanting the operation itself to move (the regroup, the unbundle, building a fraction) and having only a marker and a static board.
Objections → responses
“Is this a whole thing IT has to install?”
No install — it's a web page. The one honest catch is opening the URL on your projected device; we confirm that works before you rely on it. (This is the Tier 2 reality; we don't paper over it.)
“Is it just a video I can't control?”
No — you type the operation and step through the animation live, at your pace, while you talk. You're driving it.
“Where does my students' data go?”
Nowhere. No student logs in, no student data is saved or sent — it's a projected animation. (The app remembers only a sound on/off toggle on that device; nothing about a student.) We verify the deployed app collects nothing before you pilot.
What a pilot looks like
Because the build already exists, the teacher can try it this week — no build-then-pilot wait. They use it the first time an operation is hard to draw. The real signal is the second and third time, a different unit, a different concept — it became a reflex at “show, don't tell” moments. Success = sustained use across lessons, not a single demo.
The bar
Safeguarding & the pilot gate
The minimum conditions before any classroom use, and the data posture that keeps the solution honest.
Pilot gate
- Sponsoring adult
- A classroom teacher (or the adult leading the school / after-school / community venue where real learners are served).
- Minimum version
- The deployed app opening at a URL the teacher can actually load on the projected device, where they can pick the demonstrator they need (e.g. base-10), enter an operation, and have it animate via /engine — not a localhost demo.
- Pilot setting
- A class period, used live at the board the first time an operation is hard to draw.
- Success evidence
- The teacher opens it on the board and steps through a live demo during instruction (the Pilot rung) — observed, not a one-off rehearsal.
- Stop condition
- The teacher can't open the URL on the projected device (the Tier 2 IT friction), or the deployed app is found to make network calls / collect anything — either would pause the pilot until resolved.
Safeguarding
Low–med loadData touched
No student data (intended) — the teacher picks a concept and types the operation, which drives that demonstrator through the /engine; no student login, no PII, no telemetry, no network I/O. No student data is persisted. (The block does write two device-local sound/music UI preferences to localStorage — not student data, never transmitted.) But “intended” is the operative word: this is your app, so the claim must be verified on the deployed build — confirmed to collect no student data — not assumed from the block.
Checklist
- Sponsoring teacher ✓ (required program-wide, unchanged by tier).
- Data-handling review applicable — confirm no student data is collected by the deployed app (not n/a here, because it's net-new code).
- Consent n/a if the no-data claim holds.
- Supervision = ordinary teacher-led classroom use (a single demonstrator on the board, students don't touch it).
One thing to verify
That the deployed app makes no network calls and stores nothing during use — no analytics snippet, no “save session,” no sign-in — so the “no student data” claim holds in practice, not just intent. This is the single check that keeps the rating from drifting higher.
What would change the load
The Low–med profile holds only while the app stays a thin, no-data shell over the block. Any analytics/telemetry snippet breaks the no-telemetry posture even before it touches student data — don't add one. What actually raises the data load is tying anything to student/class identity — a sign-in, analytics or saved sessions keyed to a class/student/roster, student uploads, work captured per child, parent contact, or personalized feedback. Those turn intended-none into actual student data and push the data load higher. The current profile is conditional on none of these being added.
Want to build Math Demonstrator?
Tell us this starter caught your eye — or browse the others first.