ELEARNING DEVELOPMENT
The way to keep learners engaged
No slop. No surprises.
Most eLearning is a slideshow with a completion flag — tracked, but nobody is paying attention. We rebuild the same material as something that branches, scores and holds people, then package it to SCORM or xAPI so it drops into your LMS unchanged.
A converter wraps your slides. We rebuild them.
A free converter takes your deck and produces a clickable slideshow with a completion flag. Same passive content, now trackable. Nothing about what the learner can do has changed.
We take the same material and rebuild it as an experience that branches on what the learner has already done, scores real decisions, and reports data worth reading. That is a different deliverable, and it is the one worth paying for.
The clearest measure we have: the USGA's Rules of the Game existed as a YouTube series. Rebuilt as an interactive experience with the same content, the numbers moved.
Wherever your content is
Raw assets, no course yet
A deck, a manual, an SME recording, a pile of SOPs. We work out the structure with you and build the course.
A course that underperforms
The content is right and the completion rate is not. We rebuild the interaction layer without starting over.
Finished content that needs to ship
Packaging, manifest, and validation against the LMS it actually has to run in.
Nothing is bounded by the tool
Authoring tools are good at what they were designed for and immovable everywhere else. When a client asks for an interaction the tool does not support, a tool-bound shop says no.
- Logic that branches on accumulated state, not just the last click
- Interactions built for the requirement rather than chosen from a template library
- No player chrome, no runtime bloat, no vendor lock on the source
- Runs on any device with a browser, including the ones IT has locked down
- Integrates with whatever else the client is running
- You own the code we hand back
When the requirement is that a course live in your Articulate or iSpring account so your team can maintain it, we build it there instead. That is a constraint we work inside, not a limit on what we can make.
SCORM and xAPI, written properly
Publishing to SCORM is a checkbox in an authoring tool until the package fails validation in a client's LMS. Then it is an engineering problem, and most vendors are out of road.
- SCORM 1.2
- The version most LMS platforms still run
- SCORM 2004
- Including sequencing and navigation rules
- Manifests
- Hand-written when the spec requires something a publish dialog will not produce
- xAPI
- Statement design and LRS configuration — deciding what is worth tracking before anything is tracked
- Validation
- Tested in the LMS it has to run in, before handoff
No surprises between scope and ship
Scope
You send what you have. We tell you what we would build, what we would not, and what it will take.
Build
Built against the spec. You see it working before it is finished, not after.
Validate
Tested in your LMS. Tracking confirmed reporting correctly, not assumed.
Ship
Package and source handed over. No dependency on us to make the next change.
What projects look like
Small projects — a single module rebuilt from existing material — start around $5,000. Multi-module courses with branching, scored interactions and LMS validation typically run $15,000 to $60,000. We have delivered programs at $150,000 and above.
A pharma client came to us with a SCORM package from an offshore vendor that would not meet US regulatory requirements. We took it apart and rebuilt it to comply. That project ran $35,000.
We would rather tell you a project is wrong for us than take it. Usually it is the other way around — the scope is bigger than the budget, and that is worth knowing before anyone commits.
People who build interactive systems
We have been building interactive systems since before Flash, and doing it with compound logic — experiences that respond to everything a user has done, not just the last thing they clicked — before there was much demand for it.
We build to web standards rather than inside an authoring tool, which is why nothing we make is bounded by what a tool supports. See principles for how we work as a subcontractor, and work for the rest.
Before we scope a project
Can you rebuild an existing course?
Yes. We can keep the content and replace the interaction layer, or start from the source material if that is cheaper than working around what is there.
Can you package PowerPoint, video, or other finished content?
Yes, though a wrapper around a deck is the least valuable thing we do. We will tell you if that is all your project needs.
Do you support SCORM 1.2 and SCORM 2004?
Both, including 2004 sequencing. We write manifests directly when the requirement calls for it.
Do you do xAPI, or only SCORM?
Both. xAPI takes more design work up front, because deciding what is worth recording is the hard part.
Can you build in our Articulate or iSpring account?
Yes, when your team needs to maintain it afterward.
Can you test the package in our LMS?
Yes. We would rather find the problem there than have you find it in production.
Send us the deck
Tell us what you have and what it has to do. We will tell you what we would build and whether we can hit your date.
Contact Click-Video