SCORM Experts / Building it

Authoring tools have opinions and they leak

The tool you choose shapes what the finished package can do.

Rapid authoring tools are designed to let a subject expert produce a package without writing code, and they achieve that by making a great many decisions on your behalf. Those decisions are invisible while things work and become very visible when they do not, because troubleshooting requires understanding what the tool generated rather than what you designed.

The differences that matter in practice are not the ones on the comparison chart. They are how the tool handles the tracking vocabulary, whether it produces one large file or many small ones, how it behaves when a course is republished over an existing version, and whether the output can be read at all by a human. That last one sounds academic and matters enormously the first time something breaks.

Republishing deserves particular attention. Some tools regenerate identifiers on every publish, which means an updated package can appear to a delivery system as an entirely new course, disconnecting it from existing learner records. Whether that is acceptable depends on whether anybody is midway through. It is a question to answer before the update, not after.

None of this is an argument for hand-built content, which trades one set of problems for a larger set. It is an argument for knowing your tool's behaviour on these four points, once, and writing it down where the next person will find it.

The last consideration is organisational rather than technical. Whoever chooses the authoring tool is usually not whoever will troubleshoot its output, and the two have different criteria. A tool that produces beautiful modules and opaque packages is a good purchase for the first person and a long-term cost to the second. Having the person who will support the output present in the evaluation is a small procedural change that prevents a category of complaint that otherwise recurs for years.