ScormBuilder
A tool that lets a customer's LMS administrator build and ship a course out of documents, video, and a quiz, without learning an authoring suite or the standard underneath it. It also gives the customers still on our retired authoring feature a way off it.
- Video watched before a screen unlocks
- 95% 100 is unreachable in a browser
The problem, from both ends at once
Our course authoring feature was closed to new customers several years ago. We'd like to retire it. We can't, because a handful of existing customers still use it, and you don't get to sunset something people depend on until they have somewhere to go.
Around the same time, prospects started asking for two things we didn't sell. A way to run policy acknowledgements, and a way to put together basic content without buying an authoring suite.
One tool answers both. It's the exit door for the feature we want to retire and the front door for the one people keep asking to buy. Building either one alone would have been harder to justify than building the thing that does both.
That framing changed what I built. A straight replacement would have come out shaped like the old tool. Something aimed only at new demand would have skipped the migration and left the old feature sitting there.
What it does
It accepts the three kinds of file a course might need. PDFs, MP4s, and a CSV of quiz questions. Each PDF becomes a screen, any screen can carry attachments including video, and the CSV becomes the assessment. Out the other end comes a SCORM 2004 3rd Edition package.
Choosing those inputs was the first real decision, and it follows from who this is for. The intended user is an LMS administrator at one of our customers, who may or may not know what SCORM is and shouldn't have to. They already have documents, they can record a video, and they can fill in a spreadsheet. Anything they can express in those three things, they can ship as a course.
What it isn't is an authoring suite. Three input types is the entire surface, and that constraint is what makes it usable by someone who isn't a course developer. It won't produce what we build as a custom course and doesn't try to. Within the limit, what the content actually is stays their call. Policy documents with an acknowledgement quiz, internal systems training, whatever they need.
Two decisions about completion
Completion is always explicit
A course reports complete on one of two rules, chosen by whoever built it. Either a passing score they set in the interface, or having viewed every screen. No implicit default, no third state. If a learner doesn't get credit, somebody is going to ask why, and the answer needs to have been decided before the course shipped.
Video gates at 95 percent, not 100
A learner can't move past a screen with a video until the video is 95 percent watched. The obvious number is 100, and 100 is the wrong answer.
Between buffering, seeking, and rounding in the browser's own reported position, a video will frequently never report 100 percent complete. A gate at 100 doesn't enforce attention. It traps the learner on a screen with no way out and no explanation, and it generates a support ticket instead of a completion.
Ninety-five percent is far enough in that skipping the content isn't possible, and forgiving enough that the mechanism doesn't become the obstacle. Small number, real QA argument behind it.
The migration piece
Alongside the builder I wrote a local-only converter that turns existing customer content out of the old feature and into SCORM packages. This is the unglamorous half, and it's the half the whole plan rests on. Every month those customers stay put is a month the old feature has to keep being supported, and the conversion is the only thing standing between wanting to retire it and actually retiring it.
Local-only was deliberate. It processes client course content, so it runs on one machine under supervision instead of becoming a service with an upload endpoint and a queue and a fresh set of questions about where customer material is sitting.
Why the integration work came last
Building it as a prototype first was a sequencing decision rather than the ambition. Authentication, file scanning, and the rest of the platform integration all mean porting legacy methodology across. That's expensive to do once and wasted entirely if the core turns out not to be viable. So the parts that could have killed it went first.
It's now waiting on peer review, which happens after the next milestone on our flagship product.