For many involved in the SCORM 2.0 project, the hope is that we can transform the SCORM 1.x caterpillar into a SCORM 2.x butterfly; that the gestation period of SCORM 1.x has ended, and soon SCORM 2.0 will emerge from its cocoon and dazzle the world with its beauty and agility.
What’s worrisome is that there appears to be a divide in the SCORM 2.0 community between the pro-aggregators and the non-aggregators, and from the looks of it, this divide will ultimately leave one side of the aisle unhappy.
If there’s one thing I’m learning by reviewing the SCORM 2.0 white papers submitted to LETSI, it’s that the SCORM community is full of hope and ambition when it comes to truly reusable course objects. There are some really interesting ideas being proposed for SCORM 2.0 — especially as relates to social networking and Web 2.0 technology — and some folks are swinging for the fences. The biggest fear I sense from this group is that SCORM 2.0 won’t be aggressive enough when it comes incorporating new ideas or fixing the aggregation issues in SCORM 1.x, most notably sequencing and navigation.
The SCORM community is also full of e-learning developers who do not use aggregation, and are really in no hurry to try it. Yes, I’m one of them.
Hi, my name is Philip, and I don’t use content aggregation for my e-learning courses.
My SCORM 2.0 white paper [link no longer available] focused on the notion of keeping things simple, easy to use, and accessible. Content aggregation and the related issues of sequencing and navigation are by nature complicated and difficult to manage.
From my vantage point, it appears the vast majority of e-learning developers producing SCORM-enabled courses do not use aggregation, and choose to package their courses as all-in-one SCOs. I believe this is largely for two reasons:
1. Most commercial e-learning development software (Adobe Captivate, Articulate Presenter, Rapid Intake ProForm, Trivantis Lectora, etc.) do not natively support multi-SCO courses; they publish courses as self-contained non-shareable packages.
2. Most e-learning developers do not have the infrastructure, time, funding, management support, etc. to develop courses that use/reuse shareable content objects. This has no bearing on whether they think SCOs are a good idea — almost everyone sees the value in a true SCO world — it just means it isn’t practical for them at this point in time.
So if non-aggregators don’t use SCOs, what’s the point in using SCORM in their courseware? Simple: it’s the easiest way to guarantee basic course functionality and interoperability. They want to know their course will work in any LMS and has a standardized data repository for course data, including quiz results and bookmarking.
He’s not heavy, he’s my brother
Judging by the topics in the SCORM 2.0 white paper submissions, the pro-aggregators are currently the most vocal members of the fledgling SCORM 2.0 community. Non-aggregators are the (somewhat) silent majority. This is bound to cause some angst. I think there’s a way to keep both sides happy: spin off the communication element of SCORM (the SCORM RTE API) as a standalone standard.
Again, we must remember that SCO stands for shareable content object. If a course is not built to be shareable, it isn’t really a SCO, even if it uses SCORM for packaging. Spinning the communication element off into its own standard — without the name SCORM — would free SCORM to truly be a Shareable Content Object Reference Model, and would free non-aggregators from having to deal with the complexities of SCORM.
This would also allow the group responsible for the new communication standard to really dig in to the communication methodologies (ECMAScript API versus web service, etc.) without having to spend resources on other topics, such as content sequencing.
The biggest question would be: What should we call the new communication standard? I think we should use the name Course Content Communication Protocol (CCCP). That way the original sponsors of SCORM — the American government and military-industrial complex — would have to officially endorse the CCCP!
[Link for those who don’t get the joke.]
All kidding aside, I do believe we should consider removing the burden of the communication protocols from the SCORM 2.0 workgroup and let the discussions about SCORM 2.0 focus on aggregation. I’m sure I’m not the only one who feels this is a viable option; if anything, I imagine the companies that produce rapid e-learning development tools would be very interested in freeing themselves from SCORM while maintaining a high level of course interoperability.