I love SCORM. I hate SCORM. This might sound crazy, but during the last few years I saw the good and the bad you can do with SCORM in a dozen of learning management systems and in hundreds of learning contents. Since it is so much easier to talk about the bad stuff, I decided to write about things you can do with SCORM which are maybe not violating the specification but which are breaking the intended interoperability ‐ at least in my opinion. I’d like to present two times five trouble maker and my personal rules what you shouldn’t do. In this post I will start with content implementation:
You shall not mix versions
Obviously authoring tools and content providers implement a wrapper around both SCORM standards to simplify the export process. But sometimes you’ll find contents that mix some nice SCORM 2004 features into 1.2, especially the missing completion_status. Of course, this is a bad idea if you relay on this information later, because the LMS might not store it! So, this is a simple one: Don’t do it!
You shall not use the local storage*
One of the biggest disadvantages of SCORM is the tiny space it provides to store the state. The designated data field suspend_data is limited to 64000 (or 4096) characters! So you start to look for other places. Of course you can heavily abuse comments or objectives. But a worse idea is using the local storage of your browser: If your learner switches from one device to another he will lose his state or worse produce an illegal one! So, if you need more space, you might think about compression?
* Of course you can use the local storage for dispensable data.
You shall not close the window
You might disagree with this one. But from my experience calling window.close() from within the learning unit can break the user experience in many learning management systems: Not all of them use a second browser window to display the course by default and additionally I think this should be the preferred mode. But if you design your content with the expectation to have your own window and provide an “exit” button, that class window.close(), people will assume their browser crashed when they close their (only) window. So in my opinion, you shouldn’t put an “exit” or “logout” button within your content.
You shall not re-initialize
As far as I understand the SCORM specification, to re-initialize is a real violation, but people tend to think differently. By re-initialize I mean that your learning unit calls (LMS)Initialize a second time after it called LMSFinish/Terminate. This breaks the most learning management systems I know, since they close the window or clean up your session at the moment they receive the termination. So once again, please don’t do it!
You shall not use top
The fifth and last one is maybe a special one. Look at the following two cases:
- The LMS or a part of it is enclosed within an iframe of another system residing in another domain.
- Your content and the LMS are hosted on different domains and there is a wrapper organizing the cross-domain SCORM communication.
So if your content is using the top property you’ll get a cross-domain error and it won’t work. So except from finding the API object do not look across the frame border!