SCORM 2.0: The Lucas Proposal - SCO-based Sequencing

Interesting.  One of the problems we are dealing with is the inability of a SCO to access the data relating to other SCOs.  In your recommended system, would it be possible for one SCO to get/set data from another SCO without displaying that SCO?

I completely agree that we need to do something about sequencing. For the sake of full disclosure, I wrote my own paper about a potential replacement for sequencing.

I also wrote another paper that questions the need for sequencing. In that paper, I propose that sequencing is only necessary if either:

• Sequencing can be simplified so that it is easier than creating your own alternative.

• Adaptive learning is a reality with an LMS taking inputs from external systems that content does not have knowledge of or access to. Only in the case where the LMS knows more than the content does it make sense for the LMS to
control sequencing and navigation. Or,

• Repositorites of reusable content are available and practical from both a technical and business perspective.

(before taking these for granted, please read and comment on that paper, it is definitely meant to be more of a discussion starter than something which draws definitive conclusions) 

If we consider those as the valid reasons for wanting sequencing, I don't know that this architecture best fulfills those needs.

-Is this easier than sequencing yourself? No, you are pretty much doing it yourself so it's the same.

-Does it facilitate adaptive learning initiated by the LMS? Not really, but nor does it prevent it either?

-Does it facilitate reuse? This certainly allows SCOs to be reused, but only if they don't have an inherent dependencies on other SCOs built in to their hard wired sequencing.

Another point would be to look at what Allyn Radford terms "True Interoperability"...

"In the case of 'true interoperability' it should be possible for content to be both interoperable at the level where courses are consumed 'as is' by LMS-type applications and yet are also adaptable by tools other than those used in the original creation."

The later part of "True interoperabilitiy" (the adaptability) would be hindered by this architecture since all of the navigation mechanisms would be proprietary.

At a recent ADL Technical Working Group meeting, I participated in a sidebar discussion with a few folks where we were all intrigued by allowing a content author to define sequencing in the manifest simply as a set of ECMAScript that could be executed between SCOs. That feels like a similar solution to what Leo proposes here but with the added benefit of separating the sequencing logic from the content.  (I head a rumor that somebody submitted a similar solution in a white paper, but I haven't made it down the list that far yet so my apologies for lack of attribution).

There is a common request that seems to be surfacing in this proposal, it's comments and in other place that SCOs be less isolated and more able to query each other's data. That seems nice on the surface, but in practice does it hinder reusability? How can we have our cake (give SCOs access to one another) and eat it to (still maintain reusability)?

I like the idea of sco-based sequencing AND the option of using monolithic scos which "do it all", which essentially what we do now.

In our corporate environment, it's rare that we can reuse the entire sco without some kind of customization. We tend to build scos that do their own internal branching and rule-based presentation of content, but that does require some knowledge to use.

The ability to combine SCO's that were created with different tools, track them, let them share data, and control rollup rules and branching between them without involving the LMS is an interesting one.

 In our system, reusability is almost never drag and drop, and I doubt anyone would miss it if it were gone. The structure is usually the thing we want to re-use.

I like the idea of SCO-based sequencing. It is entirely compatible with my Content Aggregation Model with Recursive Manifest. As you can see in my paper, the Recursive Manifest requires each SCO to be referenced to its direct parent SCO(s) as well as to define specific contribution of this SCO completion in achieving its parent SCO's objective(s).

Because the Recursive Manifest allows also establishing enabling relations among Objectives of parent SCO, RTI can use these relations to generate Intelligent Sequencing of SCOs and its siblings of the same parent SCO.

The Recursive Manifest allows also mapping all pre-requisite sibling SCO(s) into the SCO under the same parent. By this way it supports traditional branching and simple sequencing of all SCOs of the same parent.

Both are examples of SCO-based sequencing.

In my paper you can find some graphical illustrations of such SCO as well as interface of the authoring tool for designing such nesting SCOs.

I think this is an interesting idea that underscores the need for a better data model that is more accessible, as pointed out by John above.  I think that there should be more allowance for SCO's to preform their own Sequencing/ navigation as you pointed out in the discussion about "engines."

 I think that there are definately points when what you want to display is simple and straight forward, at these times I would think that allowing the LMS to provide the navigation is much simpler, than having to create your own.  An example would be just a simple set of documents on policy changes that you just need to provide evidence that they have been read by users.  A simple SCO of multiple documents could just be presented, and allow the standard reporting just report if each page as been viewed or not.

I would be concerned about content organization as well, if you put all of your SCOs in separate folders, wouldn't you then have to duplicate css/ images/ logos... for each sco.  I realize that this isn't necessarily a big deal for space, but it becomes a bigger problem in keeping them all in sync.

I would also be concerned about SCOs awareness about other SCOs.  You need to either go into each SCO and create an "index" of the other scos, as well as where they are in the heirarchy, or you need something else to define it (parent SCO?)  This would effect both data sharing between SCOs and navigation interfaces.

 I think that SCORM 2 should allow for both an LMS based sequencing and display control, but also allow for SCOS to control navigation display and self sequence as well, which would require an update to the data model, which may not be too significant of an update.

Thanks

Chris

This propsoal is very similar to Mark Ewer's "How to make SCORM Simple Sequencing Model Simple Again".

REPEATED FROM A COMMENT ON ONE OF MIKE RUSTICI'S PAPER:

To me sequencing is portable instructional strategy (thanks Avron!) and the purpose of a "sequencing" specification or standard is to separate content from instructional strategy in the same way that other standards separate content from presentation. By specifying instructional strategy separately and independently of the underlying content, each can be changed independently and each can be successfully interpreted and delivered in multiple contexts.

I don't believe this is accomplished by "SCO-based sequencing." In fact, it appears to embed sequencing even further into the content.

The problem may not so much with a SCO launching another SCO but with the fact that the proposed change is to allow a SCO to launch aspecificSCO rather than make request for content that is potentially dependendent on the status of learning objectives and the context of the learner (e.g. where and with what device the learner is interacting). 

If I understood the Lucas (and some other) proposals correctly, there is the fundamental dichotomy in approaches.Either you hardwire sequencing into the content or you divorce it from content.Of course, once you divorce sequencing from content, the question becomes "who computes the value of the target SCO (or content object, even if it is not a "SCO")?" The current answer is that the RTE does that computation based on a set of rules prescribed by the content designer. It the future, sequencing might be considered as an isolatable service that is currently part of an RTE. Regardless, the fundamental approach of having an external rule- and context-based sequencing service makes sense to me, and hard wiring sequencing into content does not. That's my two cents. 

We have tackled the problem of SCO driven navigation by doing two level of navigation.  At the SCO level we define a lesson resource (a Flash SWF).  This lesson entry point acts as a controller for the different sections within the lesson.  The different sections of the lesson (different SWFs) communicate with entry/controller SWF that launched them.  The controller SWF saves state back to the LMS via normal cmi data variables.  The LMS launches the lesson and the lesson reports back to the LMS.  What else happens withn the lesson is known only to the lesson.   The SCO has full control over the UI and navigation within the lesson. All well and good.

We tried to go to the next step and add a custom table on contents to the course so that we could give the user a consistent UI that was LMS independent.  We built a simple SCO that parses a copy of the manifest to display the table of contents for the course.  When the student makes a selection, the SCO does a "adl.nav.request" to have the selected lesson launched.  This works well on most LMS platforms.  Again, the LMS is launching all SCOs.  The SCOs all communicate back to the LMS only.

The problem we ran into was having our custom table of contents SCO reflect the status of a lesson.  Did the student start a particular lesson?  Did the student pass a lesson? Etc.  The only way we thought that we could accomplish what we needed was to add a lot of global objectives to the course.  Messy, messy.  It would be simpler if one SCO could access (read only) the cmi data vales set by another SCO in the same course.  If that simple change were made to the standard, then implementing SCO based navigation would be very easyt.

I actually experimented with something very similar to this a few years ago.  One of the early releases of the SCORM 2004 documentation had a diagram in it that shows one SCO launching another.  I attempted to build a "parent sco" that would implement my own sequencing and launch the "child scos" in the order I wanted.  I ran into two problems:

1.  I ran out of data storage space.  SCORM limits you to 250 interactions and 1000 characters of suspend data. I hit that limit pretty quick when I made all the content into "child scos".

2.  The LMS didn't understand my content structure and could not display any kind of completion menu to the learner.  The LMS was essentially not able to produce adequate learner progress reports because I had hidden all the "child scos" from the system.

Richard suggested that we let one SCO see the runtime data of another.  This will get really messy because we break the encapsualtion of each SCO and make them less portable.  The paper I submitted and this one are both trying to solve the same problem.  Perhaps we should get together in Pensacola and try to marry up our ideas into a single solution?