| Home | About LETSI | Calendar & Events | Join LETSI | Contact LETSI |
| Architecture | Runtime Web Services | Strategic Communications | Technical Roadmap | [Joint CMI Study Group] |
| Content as a Service | Namesets | [LET Activity Description] | Orchestration | SCORM 2.0 |
"SCORM: The Baby and the Bathwater"
SCORM: The Baby and the Bathwater
*Author: Mike Rustici*
Summary
Discussion of what SCORM has done really well over the years that should be maintained (the baby) and where SCORM has come up short and needs cleaning up, or perhaps cleaning out (the bathwater).
The Babies
- It Works
- Basic Interoperability
- Clearly Defined Design Goals and Direction
- Appropriately Allocated "Burden of Complexity"
- Granulated Complexity
- Well Written Specification Documents
The Bathwater
- Sequencing
- Sometimes Forgetting the Basics
- Ignoring the Learner's Experience
- Reference Model
Requirements/Needs Outlined
Hoping to stimulate some discussion about the general vision for SCORM 2.0 and how we should best architect it.
Recommendations
Keep the babies and throw out the bathwater.
Comments (3)
Aug 13, 2008
John Campbell says:
I'm glad you listed interoperability as chief. I think somewhere along the...I'm glad you listed interoperability as chief. I think somewhere along the way, "reusability" was sold as the main "ility". The challenges related to actually reusing something (not all SCORM issues) have really left a bad taste in some.
However, I think it's important to note that, as you said, interoperability is working. Most of the interop "issues" that we have are either related to LMS bugs or something UI related which was originally outside of scope. However, by and large, those LMSes who implement the spec correctly are interoperable in 3rd Ed. This is a huge win and imperative to achieve prior to reuse being feasible at all.
You are spot on with the comments about "Graduated Complexity". Defaults for sequencing, etc should be made so that usable simple SCOs can be created by anyone.
Even though we have had quite a bit of success implementing sequencing, I also agree that it needs a major rework. I have read a draft of Sensible Sequencing and look forward to the final!'
Overall, Mike, I think this paper is very important. We can't lose what we have today that is working well. Even though some of that might just be the "intent" that didn't get fully implemented or marketed correctly. A lot of hard and solid work went into the past that we can't leave behind.
Aug 13, 2008
Mike Rustici says:
I agree that in the past we've oversold resusablity. There are people who will c...I agree that in the past we've oversold resusablity. There are people who will content that SCORM is a failure because it doesn't perfectly address all of the ilities. But, when I look at people using SCORM in the real world all they want is interoperability. In my mind, the ilities where/are a road map and a set of design goals. There is a huge contingent that just wants plain simple interoperability and they are baffled as to why SCORM is so complex.
Sep 02, 2008
Gareth Farrington says:
I like the notion of instructor evaluation. I could see that rolled in with the ...I like the notion of instructor evaluation. I could see that rolled in with the secure test questions stuff we are proposing. For questions that cant be automatically evaluated the LMS can provide an interface for the instructor to grade responses.
Its petty clear that we need interoperability to be our primary goal. Simply specifiying the interface (SCORM API) without talking about how that gets implemented leads to interoperability. The reality is there are several implementation choices and they do not all give the same results. We are proposing that any future reference implementation be written entierly in JavaScript. SCORM should have zero plug-in dependencies itself.
Because the web browser environment is so constrained some discussion of "how" needs to go on.