SCORM and the Whole 2.0 Thing Again.....
I recently posted about the SCORM 2.0 Call for Papers and how I feel this is a very important moment for SCORM and that I think it would be great if the papers came back with big,hairy audacious goals that really sought to move the industry forward and so forth.
As if so often the case, I am merely following what Tom King has also already thought about:
"I think this is important, as we could be at the cusp of a make-or-break situation for evolution (or revolution) of learning and training infrastructure. Much of the current e-learning and LMS infrastructure is grounded in the learning and training approaches of the 1990s ('80s? '70s??). By comparison, today's technical and learning environment is much more “read-write”, collaborative, social and nomadic-- all while being more personal and individualized." [I added the bold]
Evidently Brooks Andrus REALLY feel strongly about this as well:
"I’m not sure I’ve ever met anyone, outside the DOD / ADL who doesn’t think SCORM and AICC are over engineered pieces of junk. And the LMS / LCMS products and vendors engender pure hate at every contact point whether purchaser, content develoeprs, admins or end users. Do a couple of white-papers do anything to help remedy the situation?"
I do think that there are very serious issues here and I would say that if LETSI and or the authors of the white papers fail to appreciate the degree to which the marketplace in general has moved away from both the pedagogical and technological models that were dominant when ADL started - and by that failure do not push forward far and/or fast enough...there is a real possibility that even DOD dollars will not be able to sustain the effort. Make no mistake, I still think there is a role to be filled here but it is a role that focuses on pedagogy, design, design, design, and to a small degree any unique, technical requirements that are not being met by existing and emerging market standards. Its a different role but its there.


You folks might want to check out how IMS is now supporting functionality mash-ups for learning.
See:
http://simplelti.appspot.com/
It's part of IMS's new work - that does not include the ADL or DoD - called Common Cartridge:
http://www.imsglobal.org/cc/ccfaqs.html
http://www.imsglobal.org/cc/index.html
http://www.imsglobal.org/commoncartridge.html
Posted by: Rob Abel | August 19, 2008 at 02:57 PM
I agree with Mark. Look back at the complete interoperability problems with courseware 8 - 12 years ago.
To judge SCORM by today's practical state is a bit unfair. Rewind the Web 12 years, where were we? Certainly not a standards based affair, certainly pretty primitive architecture wise, it was a different world. The goals of SCORM were pretty lofty.
I agree with Brooks that we have built an overcomplex soup for the benefits we get from SCORM. It works pretty well as a protocol for communication with backends. Beyond that, I'm not convinced that the packaging or perspective of reusability are well spent energy.
Like any professional group, we will have a tendency to lay the blame wherever we can for the failures of our community. I don't think the problems with eLearning failing to live up to its potential (there are some great successes) can be laid directly in SCORMs lap.
We all share the blame for a lack of accelerated progression and thousands of hours of lackluster content. I like to focus my blame the tool vendors (LMS vendors in particular):)
Bottom line, in my opinion, SCORM 1.x was a (largely healthy) step in the evolution of the learning content and distribution architectures of 2015+. What we do from here on is up to us, if we allow a group of engineers to over-engineer another standard and steer us down a path of continued mechanized compartmentalization -- shame on us.
Posted by: Steve | August 01, 2008 at 09:00 AM
A good clarification, Mark, and I agree on the stupidity of agency- or service-specific "lockout." I worked on a group of courses for federal civilians. One was on the process for filing EEO discrimination complaints.
As you probably know, the two main routes for a complaint (within in agency, outside the agency) are essentially identical; the main difference is who within your agency might be your first contact.
The lessons were SCORM-ified to a fare-thee-well because (of course) the contract said they had to be. Here on earth, though, the way the courses would be customized for a given agency had nothing to do with SCORM. You'd go through the storyboards and turn the example with, say, a Border Patrol agent into an example with a wage and hour claims examiner.
Given an expert in typical agency jobs and a fast typist, you could "repurpose" the whole course in a day -- with or without the SCORM manifest.
I grant that there was probably a lot of eletronic filing/tracking/reporting going on thanks to the standards, but the re-usability argument (put forward by the agency and by the contractor management) was, to use a technical term, codswallop.
Posted by: Dave Ferguson | July 18, 2008 at 09:27 AM
I hear you Dave. Let me just say this in defense of SCORM. I was there and by 'there', I mean I worked in support of the Pentagon office that created SCORM and working on that and ADL was my daily gig for about the first 5 years of its life. The initial research we did across some 30,000 DOD courses was that we had a 4% technology insertion rate in those courses. When we pulled the curtain back on that data and asked "why?" we found systems that were would not talk to each other in either a student record way or a content way. We literally had each of the Services buying the same course because of proprietary lock-in. We don't even need to get into the pain and cost of migration not just from one system to another but sometimes from one iteration to the next major release. SCORM was meant to bridge that lack of interoperability among other things. So the intent was good. SCORM was also never meant to limit what people could do, not a ceiling but more of a floor - standards aren't a bad thing but I do think that a lot of the perception of SCORM stems from people writing bad RFPs and the like which made SCORM appear Draconian and worse.
All that being said, I'll repeat that I think that there is a potential role here but that the window for successfully hitting that role is a small one.
Posted by: mark oehlert | July 17, 2008 at 08:49 AM
Mark, I have to agree completely with Brooks. Like you, I'm in the D.C. area, so I run into government and military people often. I've also been in the training/learning field for decades.
I don't know much about the theory of SCORM, but in practice it seems designed to frustrate creativity and innovation on the off-chance that someone somewhere might want to reuse that one image of a white guy in a suit, talking on a cell phone while looking at a screen.
John Tierney wrote in the Science section of Tuesday's NYTimes about the tendency of folks in IT to enjoy "manipulating objects and machines."
I have turned down the opportunity to work on projects
infected withrelying heavily on SCORM, though it does feel good when you escape them.Posted by: Dave Ferguson | July 17, 2008 at 07:48 AM