Despite the growth and excitement around the xAPI (TinCan) spec, SCORM remains the most popular and supported method of ensuring a standardized communication between an online course and the LMS. While SCORM 2004 is dated by its very name, it has gone through several revisions and absolutely remains (at this time) a viable solution for tracking your courseware.
However, many LMS products still lack in full SCORM 2004 support, various tools interpret the spec differently, and it does add a bit more complexity to the overall setup of the course.
So is there really an advantage to using the ‘newer’ SCORM 2004 spec over the older SCORM 1.2?
It depends!
There are three significant changes in SCORM 2004; ‘Status’ Separation, read-write Interactions, and Sequencing.
- ‘Status’ Separation: In SCORM 1.2, there’s one “data model element” (value) to hold the status of the lesson; ‘lesson_status’ can be passed, failed, completed, incomplete, browsed, or not attempted. This wasn’t ideal as instructors wanted to know, for example, if the learner had gotten through the entire lesson (completed) but not passed the quiz (failed).
SCORM 2004 addressed those issues by splitting lesson_status into ‘completion_status’ (completed/incomplete) and ‘success_status’ (passed/failed).
- R/W Interactions: In SCORM 1.2, ‘interaction data’ is write-only, which never made much sense (why ‘write’ something you can’t later ‘read’?). SCORM 2004 specifies interactions to be read/write, which is especially helpful not only for reporting but your lesson can now query the status of a previous interaction, get the result, and act accordingly (i.e. ‘user answered this question in the last launch, so they don’t get another chance to answer it again’).
- Sequencing: SCORM 2004 attempted to improve the author’s control over the content via the ‘sequencing’ part of the spec, but it’s very complex and few LMS and authoring products support it, or support fully. The sequencing spec itself isn’t even usably defined until the ‘2nd Edition’ of SCORM 2004 and further refined through the 3rd and 4th editions of SCORM 2004. It’s a neat concept but overall few find it usable.
So…do you find any of the above improvements a critical need for your courseware?
The first may well be the most helpful…however many LMS products have supported split-status reporting for a while anyway. If your LMS already allows combined statuses (i.e. passed/incomplete), then you may have this requirement already satisfied.
Read/Write interactions could be very helpful if your authoring software (or manual skills) allow a course to use such behaviors…and frankly most tools got around this restriction for SCORM 1.2 simply by writing interaction data to the suspend_data field anyway.
The third, Sequencing, may be the most helpful…if your LMS and software support it.
Oh, and there is another improvement in SCORM 2004 – the suspend_data field was expanded from 4k to 64k…probably since tools need a place to read/write interaction data! So you can stuff a lot more custom info into the suspend_data field with the 2004 spec.
Overall, there’s a reason most eLearning content is still built for SCORM 1.2…it simply works and generally satisfies the tracking requirements many organizations require.
Of course, if your LMS and authoring software supports xAPI, that may just be the better way to go (considering privacy concerns). xAPi is in active development whereas SCORM has pretty much halted, though it surely has a good bit of longevity with a large installed base and cross LMS/tool implementations.
You expressed that effectively.