Example
The Discount Decoder
A short, interactive course for school-age learners on percentage change, discounts, tax, and the traps that catch almost everyone.
Every price tag, every sale sign, every tax-inclusive receipt is doing the same maths under the hood, but percentages trip people up in exactly the same places, over and over. This course doesn't try to explain percentages. It hands the numbers to the learner and lets them play, break things, and discover the pattern for themselves.
Fully accessible — keyboard nav, swipe, ARIA states, reduced-motion opt-out, mute toggle for the narration.
For those interested, here's how it was built -
The short answer; it's a single self-contained HTML file dropped into a Rise code block. The longer answer is that 'single HTML file' hides quite a lot of learning-design decisions I've refined across a dozen or so of these builds. Here are the ones I think are most portable.
The whole thing is one file
No frameworks. No build step. No CDN. One index.html, two background JPGs, nine short MP3s. Drop the folder into a Rise code block and it works. Vanilla HTML/CSS/JS is boringly reliable!
Each screen is a "scene," and only one is on at a time
Every section is a <section class="scene"> stacked absolutely on top of the others. A single class, .on controls which one is visible. Navigating means fading out the old scene and fading in the new one, with the new one entering from a slightly different starting position depending on whether you're going forward or backward.
This is the same pattern you'd find in a native iOS or Android app: a stack of screens, one active. Learners find it intuitive because they've been using apps built this way for a decade or more.
The nav rail is deliberately simple
A row of small pill segments, one per section, with a persistent Next arrow and a persistent Previous arrow. Learners can jump anywhere by clicking a segment, arrow-key their way through, or swipe on mobile. The Next arrow pulses in a warm gradient the whole time it's active, because I noticed in testing that it wasn't obvious there was a way forward unless you were shown.
The rail counts up: 01 / 10, 02 / 10. That number matters more than you'd think, it turns "how much of this am I in for?" into something the learner can see at a glance, without a progress bar dominating the screen.
Content-driven interactivity, in small doses
Every section has one main interactive idea. Not four. Not seven. One. The temptation is to pile more into each screen. Resist it. Learners can only pay attention to one thing at a time, and a single interactive done well outperforms three done half-heartedly every time.
Learners drive the pace, not a timer
Nothing in this course auto-advances. Not the step reveals. Not the chain animation. Not the "we've spent long enough here" fade to the next section. Every reveal, every animation, every transition is driven by a click, tap, keyboard press or swipe from the learner.
This matters more for maths than for example policy training. Someone reading a data-protection policy can skim; someone learning the multiplier trick genuinely needs a moment to think. If your content moves without them, you've lost the room.
What I'd tell someone starting out
Copy the pattern before you copy the code. The pattern is: scenes, rail, one-idea-per-section, learner-paced reveals, tolerant feedback, in-context reward, accessible controls. That pattern works for policy training, safety courses, product onboarding, and, as this build hopefully shows, maths.
Interactive doesn't mean "click to reveal." Click-to-reveal is the low bar. Aim for: change a number and see what happens. Commit to an answer before the explanation. Type your own working. Make a mistake and get specific feedback on why it was tempting.
Small courses are better than big ones. This lesson is 10 sections and ~ 8 minutes. Nobody has been dragged through it against their will. That's a good bar.
Happy to answer specific questions in the thread. If enough of you want a follow-up on any particular piece shout out!
