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.
Pro-aggregators
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.
Non-aggregators
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.
SCO what?
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.
“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.”
Strangely I feel the contrary, it seems to me that there a huge demand for the second option, although this demand has not been really envisaged by the LETSI for white papers submissions.
Before reading you’re post, I was somewhat divided on how to meet the needs of both parties.
“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 not sure to understand what you want to say. Basing on what you’ve written, I would advocate for focusing on interoperability and reduce the scope of Scorm 2.0 to a communication protocole so the content developers are able to create the content the way they want ?
Regards,
Goulwen
@Goulwen
Your comment “I would advocate for focusing on interoperability and reduce the scope of Scorm 2.0 to a communication protocole so the content developers are able to create the content the way they want” is precisely the issue: many developers don’t care about aggregation. The problem is that aggregation is at the heart of SCORM.
The original concept of SCORM was to turn bits of electronic media (content) into shareable objects that could be imported into any course (SCOs: shareable content objects). To achieve this objective, SCORM’s creators decided to use existing standards where feasible (ECMAScript, IMS manifest, cmi data model) and write new standards where needed (sequencing and navigation). This collection of standards is the RM of SCORM: Reference Model.
Over the years, SCORM has been deemed a success largely because of the void it filled in terms of standardizing course interoperability — in spite of its mission of supporting content aggregation.
Although interoperability is all most developers use SCORM for, it’s SCORM’s primary mission. It wouldn’t be fair to convert SCORM into a simple communication protocol. However, I think it would be completely reasonable to extract the communication protocol element of SCORM and use it to create a new standard for communication/basic interoperability.
SCORM will always need a communication standard for course-SCO communication; this new standard could be folded into SCORM as a supporting element, just like the cmi data model or IMS manifest.
Does SCORM need to be responsible for creating and maintaining that communication standard? I don’t think so, as it ultimately distracts from the primary goal of SCORM: enable developers to reuse content through aggregation.
If communication/interoperability is split into a new standard, most developers could simply use that new standard and wipe their hands of SCORM. The pro-aggregators could then intensify their work on aggregation and related issues, making SCORM a stronger standard.
Philip,
Thanks for your response, I better understand what you want to say. So, content developers should create another organization like LETSI to create the CCCP !
Mr Pip,
Your links to both submitted white papers and your own are broken.
Cheers and thanks for all the good werk,
dmorgorg
@dmorgorg thanks for the head’s up… the LETSI site has undergone some changes, breaking some links. i’ll put this on my to-do list. 😉