Cry of Jelicuon — Interactive Physics Platform

I was contracted to build the whole platform solo — a Next.js e-learning site that turns his thesis into something a 13-year-old can click through. It ended up at 45 lessons across 6 modules, mapped to 15 specific DepEd competency codes the panel would check by hand. The decision I'm most glad I made early was to make everything data-driven. Every lesson — video, reading, or interactive simulator — is just a JSON object in data/modules. That meant the curriculum content was the researcher's to shape without touching React, and I could keep the rendering logic in a handful of components: a ConceptVisualizer that branches on the formula string to compute live outputs, a video player that pauses at timestamps to quiz you, cloze inputs embedded mid-paragraph so reading stays active. The piece I'm proudest of is the scene system — eight hand-built animated SVG scenes, registered by key, where the physics literally plays out in the festival's own imagery: a runner doing laps to show distance versus displacement, a cart hauled at an angle to decompose force, a jumper falling off a riser as the potential-to-kinetic energy bars trade places. Every lesson follows the same five-step rhythm — festival hook, competency code, the physics, an interactive sandbox, a discussion prompt — so the structure itself was defensible when the panel asked why it's organised that way.

The hardest lesson wasn't technical difficulty — it was realising what 'bug' even means in a teaching tool. The Stage Path Explorer is the simulator whose entire reason to exist is teaching that distance ≠ displacement. You set the laps, the runner runs, and you read off the two numbers. When the panel feedback came back, one comment stopped me cold: with decimal laps — say 2.5 laps on a 100 m track — displacement was reporting roughly zero. It should have been about 50 m, because the runner didn't return to start. I traced it to one line. At the end of the animation I was force-snapping the runner back to the start point regardless of fractional laps, then computing displacement from that snapped position. Trivial fix. But the implication wasn't trivial: my simulator had been confidently teaching the exact opposite of the concept it existed to teach. In an ordinary app, that's a cosmetic glitch you'd shrug at. In an instructional tool, it's the worst kind of bug there is — and any evaluator testing the distinction would hit it in the first thirty seconds. That reframed how I read the whole feedback document: a self-revealing quiz answer, a label overlapping on a sim, an animation that finishes faster than the eye can track — those aren't polish issues. Each one quietly teaches something wrong.

I'd build the standards coverage matrix before writing a single lesson, not after. I mapped the site to competency codes — S9FE-IIb-17 and the rest — and assumed that was alignment. It wasn't. Each DepEd competency carries a content standard (what students must know) and a performance standard (what they must be able to do), and the panel's real yardstick was those, not the codes. Mapping to codes got me a platform that looked complete and was quietly thin: no worked examples, no performance tasks, discussions only a paragraph or two deep. If I'd laid the standards out as a grid first and hung every lesson on it, that second wave of authoring work would have been the plan from day one instead of a correction.