HotManifestsTrackingxAPIAuthoringTestingLongevity
Latest A standard is an agreement about what two systems will assume about each other. Most bugs are a broken assumption.
The interoperability promise

What a packaging standard was actually meant to solve

E-learning standards exist because organisations discovered they had bought content they could not move. Everything awkward about them follows from that original problem.

In the late nineties an organisation that bought training content discovered an unpleasant fact. The content ran inside the vendor's delivery system and could not be moved out of it. Change the delivery system and you lost the library. Buy from two vendors and you ran two systems. The content was not really yours in any practical sense, because the thing that made it work was the coupling between the material and the software that presented it, and that coupling belonged to somebody else.

The response was a set of agreements about how a package of learning content should be laid out, what file describes its contents, and how the content talks to whatever system is showing it. If everybody follows the agreement, a package built in one authoring tool can be dropped into any conforming delivery system and will run, report completion, and record a score. That is the whole ambition. It is a modest one, and it was and remains genuinely valuable, because it converts content from a rental into an asset.

Continue reading

When it breaks

Completion, passed, and the difference nobody agrees on

Two systems can both be right and still disagree about whether somebody finished.

The suspend data problem

Resuming where you left off is the feature that quietly breaks first.

Building it

Test on the system it will actually run on

A preview inside the authoring tool proves almost nothing.

Accessibility does not come from the standard

A conforming package can be completely unusable.

The longer view

Content outlives the tool that made it

Plan for the day the authoring licence lapses.

Buying content without being locked in

Ask the questions before the invoice, because afterwards you have no leverage.

Practice

Version your packages like software

Because that is what they are.

When not to package at all

A great deal of material is worse for being made into a module.

About SCORM Experts

SCORM Experts covers e-learning packaging and tracking standards from the practical end: importing, testing, troubleshooting and buying, rather than specification advocacy. The intended reader is somebody who has a package that will not behave and an afternoon in which to fix it.

The editorial position is that these standards are useful, unglamorous infrastructure that were created to solve a commercial problem rather than a pedagogical one, and that most disappointment with them comes from expecting them to solve the second.

This publication is independent. It is not affiliated with any standards body, authoring tool vendor, content supplier or delivery platform, and it does not accept payment for coverage. Where a category of tool behaves in a particular way, that behaviour is described as a pattern rather than as an endorsement.

Technical descriptions are written to explain how a mechanism works and where it typically fails. They are not a substitute for the published specification, which is the authority, and behaviour varies between versions and implementations in ways an article cannot fully anticipate.