“I already know this is hard, just tell me how to fix it, please.”
In an interoperability standard like SCORM (or the Tin Can API, or AICC), success comes down to three things. Compatibility, compatibility, and compatibility. If the content and the LMS/LRS don’t work together right away, nobody is happy. The SCORM Driver addresses this in three ways:
- Support for multiple standards, accessed via a single set of function calls (method overloading, of a sort). From within the content, all the complexity of the standards is abstracted, the developer doesn’t even have to know which standard is in use. The SCORM Driver manages the proper method of communication in each case.
- A proven codebase. Literally tens of thousands of courses have been delivered via the SCORM Driver code. Every time that we hear about a way we could improve the SCORM Driver, we do that. This leads to a set of code that knows its way around various LMSs far better than any person developing SCORM content. Check out some of the vendors who deploy content using the SCORM Driver.
- Debugging tools. It is impossible to know how every LMS will function (especially given that many of them are not technically conformant). When these situations arise, debugging tools like SCORM Cloud and the SCORM Driver Debug Logs are invaluable, as is our expertise in understanding them.
- More control over your content. Keep your content on your servers, and deliver it to LMSs. SCORM Driver Cross Domain (SDXD) lets you maintain much more control over your content. Read more here.
“How difficult can this really be? Seriously.”
Those who have tried to produce SCORM content know just how difficult it is. Anyone who has tried to deploy content in more than one LMS has discovered just how different those systems can be. Put most simply, SCORM and AICC aren’t perfect. Every LMS interprets the standards slightly differently, and this has a major effect on content and its ability to function right away.