Continuing my ongoing series about the implementation of the SCORM standard in a LMS, this entry discusses some of the standard’s advantages and disadvantages. The entry limits itself to presenting the difficulties found in the implementation without detailing how they were solved. So it’s more of an introduction to the issues involved in the implementation. In the next entries I will explain specific details about the solutions I devised for some of those problems.
Advantages
-
The standard makes it possible to integrate learning objects from different sources in a common environment.
This is the greatest advantage of implementing SCORM, and consists in making possible the use and reuse of courses in different formats and coming from different sources inside of the same LMS. This is achieved through a common API and a common distribution format that allows courses to register and retrieve data in a relatively generic way, making them auto-configurable and extensible.
-
The standard provides a common data model.
This common data model has obvious benefits for both the courses, which can be developed in a manner independent of the LMS under which they will run, and the LMS itself, which can gather and manage data from the courses in a uniform way.
-
The standard provides a common packaging format.
This common packaging format allows for the simple distribution of courses since they can be created and stored in the way their creator needs. A standardized manifest file describes their structures and makes their manipulation easy.
Disadvantages
-
The standard is somewhat immature.
Although it’s in its second revision (1.2), the changes made in each release show that the standard has yet to achieve a stable state. The changes planned for the next revisions further corroborate this point.
Such instability may mean drastic changes in future versions that can partially invalidate the investment in the standard at a given time. (This condition is comparable to the implementation of the XSL standard by Internet Explorer, which was based on a draft that radically changed in the final version.)
An area in which the standard’s immaturity can be easily seem is in the issue of navigation between the various objects that may make up a course: the current release has no provisions whatsoever for such navigation, although it’s generally necessary in any LMS.
-
The standard is completely based on a Web environment (mostly browsers).
This limitation causes a certain dependence over some conditions and technologies that get in the way of more sophisticated solutions. An example of this problem is the reliance on a JavaScript-based API, which limits the use of the standard to environments where such technology exists.
Also, because of the need of insuring maximum compatibility between platforms, the formats that can be used to create a course are restricted to a minimum common denominator (HTML and Flash, in a general way). The use of server-side technologies is effectively impossible.
-
The standard puts a great emphasis in the client-side of the learning process.
Two problems arise from this fact. Firstly, the possibility of security breaches in the API. Secondly, the impossibility of using server-side resources since all learning objects must be independent from the LMS in which they will be used, as previously mentioned.
-
The standard relies on current technology not currently widespread.
In fact, implementing a generic API today is a big challenge since there’s no uniform way to do it. Since the API needs to communicate with a server from within a browser, there’s a need to resort to multiple communication mechanisms, which complicates and weakens the implementation.
-
The security of the API can only be guaranteed in a very limited way since it must be accessed from JavaScript and consequently can also be manipulated externally.
-
The standard has only incipient provisions for tests and assessments. Also, the fact that they are primarily based on client-side implementation raises many questions about the security of such approach. There is no indication of the way such questions will be addressed in future versions of the standard.
Conclusion
Even though SCORM seems to have more disadvantages than advantages, its implementation has ample benefits for any LMS. The problems can be solved if some concessions are made in the implementation, and even if they limit what can be achieved with the standard, they don’t nullify the investment. On the contrary, just the first advantage listed above is more than worth the investment for many companies.
In the next entries I will look at some specific aspects of the implementation, exploring the solutions I found to some of the issues listed above.
