Last week I presented some personal rules for SCORM content providers. This time I’ll continue with some things you shouldn’t do as provider of a learning managment system (LMS):
You shall not ask the user for the correct version of SCORM
Many learning management systems ask the user which version of SCORM (or any other standard) he likes to upload. Most users don’t know and actually don’t care about SCORM et al. and so this is a usability issue! Maybe I miss something, but each version of SCORM, AICC as well as cmi5 have different course structure files, that means you can detect the correct version automatic! So, don’t ask your user which version of SCORM he is going to provide, just check the files!
You shall provide only one API
One source of interoperability problems occurs when a learning content is integrated with one SCORM version (e.g. 2004) but also provides everything to talk to the other version (here: 1.2) and your learning management system is doing the same: Since this is out of scope of any SCORM specification, the content may search for the API object first and find it although he should use the API_1484_11 object. That sounds confusing right? – So, provide only the correct API as requested during the content integration!
You shall not change the href
Most of the time a learning content provides a simple entry point url like index.html or sco1/a001.htm, but sometimes the url also contains a query string, e.g. index.html?lang=de&unit=3. Albeit there is the parameter attribute for items, you shouldn’t cut these urls or worse extend them! First of all, if you remove these parameters, the content might stop working or misbehave and is part of your job as system developer to build a robust environment. Secondly the specification does not forbid it. Actually SCORM1.2 already allows “external fully-qualified URIs”. Finally if you add further parameters you might change the behaviour of the content. So don’t change or remove the entry point of a learning unit!
You shall not sync ajax to get and write your cmi
There is an infinite number of ways how you can load and store the cmi data model. Especially since libraries like jquery made the developer life so easy, people use ajax to get and set the values. Unfortunately the SCORM API doesn’t work if you do (normal) asynchronous calls, because the value is not returned immediately. One obvious solution is using synchronous remote calls: each time a value is stored or retrieved the client opens a HTTP connection to the server, waits for the response and returns it. This is fine if the learning content is doing one or two API calls per second. But there are contents that do multiple calls per second, like storing interactions and objectives or updating the session timer regularly. Such a synchronous LMS and such an aggressive learning content will freeze the browser until all communication is done. So, don’t use synchronous remote calls! Indeed the best thing you can do, is loading the whole cmi data model on page load and writing data using (grouped) asynchronous calls. You can do one synchronous request on commit.
You shall not only write on finish
This is one of my favourites. Because it only occurs if you have the right combination of system, content, browser, user and timing: You can implement your LMS such that it only writes back the cmi data model at the end of the learner’s session, i.e. LMSFinish or Terminate is called. This will save many redundant communication during the session. And it might not work: If the user closes his session by closing the browser, or if the content doesn’t send a termination properly or if the learner loses his connection during his session, all progress is gone. So, don’t expect that everything works great, always consider the worst: Store the learning state regularly, provide a real implementation for commit and try to save the state if something goes wrong.