Rustici - Sensible Sequencing

In creating Sensible Sequencing, I tried to ignore everything I know about existing specifications and design a solution from the ground up. Sensible Sequencing is how I would approach the problem as a developer starting from scratch. Here are some thoughts as to why I think Sensible Sequencing is better than Simple Sequencing.

• This foundation is easily extensible to new behaviors simply be adding new rules (conditions or actions). It is also easilyabstractable by tools.

• Everything is laid out explicitly for the content developer. The content developer has absolute full control of what the LMS will do and doesn't need to understand or rely on default behaviors that may or may not be intuitive. Despite this control, the content developer has very little work to do because of the predefined (yet changeable) rules that will be provided to content developers.

• Everything is intuitive and straight-forward (well, it is to ME at any rate!) - no hidden dependencies, overloaded terms, or important behaviors buried in subtleties

• Sensible Sequencing is congruent with the existing SCORM data model. Once you understand the other parts of the SCORM books understanding Sensible Sequencing should be fairly easy.

• Easy to implement. As a direct consequence of being intuitive and straight-forward, Sensible Sequencing should be easy for both content and LMS developers to implement.

• The ability of SCOs and items to know about and reference one another directly. In SCORM 2004, one has to make convoluted use of global objectives to achieve any knowledge of other items. This old method is both limiting and poor practice. Sensible Sequencing removes the need to use global objectives and instead replaces that capability with a clean solution for sharing data.

• Fewer interdependencies. In Sensible Sequencing, elements don't have implicit interdependencies between each other like they do in SCORM 2004.

• Fewer ambiguities. Since there are fewer interdependecies, there are dramatically fewer possible combinations of state for which behavior needs to be defined. This reduction will allow us to more completely specify all required behaviors in a succinct manner.

• While designed for SCORM 2004, this specification could actually be retrofitted to work with SCORM 1.2 or even AICC. It could even be used with existing SCORM 2004 packages in a "conformant" manner by defining Sensible Sequencing rules in a metadataextension.

• Rules Only, No Attributes. Attributes describe a property, they say "it is like this". In SCORM 2004, sequencing extrapolates an attribute into an assumption, they say "because it is like this, we should behave this way". Behaviors and attributes are really two distinct concepts and should remain separate. While attributes can lead to behaviors, this causation should not be defined statically and arbitrarily by the specification. It should be up to the content developer to determine what behavior is desired based on a number of factors, which may or may not be attributes. Separating behaviors from attributes leads to both much more powerful abilities and also drastically simpler ease of use and understandability. This is an important point of distinction for Sensible Sequencing and is perhaps best explained with an example:In IMS Simple Sequencing / SCORM 2004 Sequencing and Navigation, there is an attribute called "objective set by content". If that attribute has a value of false, then there is an implicit rule (behavior) that gets executed by the LMS which is "if the SCO exits with a cmi.success_status of unknown, set the value of cmi.success_status to passed". If the "objective set by content" setting is true, then no implicit rule is executed by the LMS.

Now, what is clearer and more straight-forward for a content developer seeking to achieve this behavior?

• Finding the "objective set by content" attribute, realizing that it might have something to with changing a SCO's status on exit, looking up and then understanding the implicit rule that is executed
• OR, writing a rule that says "if cmi.succcess_status is unknown, then set cmi.success_status to passed"

Furthermore, what is more powerful for the content developer?

• Having the choice to either execute the rule "if cmi.succcess_status is unknown, then set cmi.success_status to passed" or not execute it
• OR, having the ability to change the rule or write any replacement rule, such as "if cmi.success_status is unknown then does not participate in satisfaction rollup"This is in contrast to IMS Simple Sequencing / SCORM 2004 Sequencing and Navigation which is laden with implicit and conflicting behaviors caused by a mix of attributes and rules (some implicit some explicit).

I like Sensible Sequencing a lot.  It solves many of the issues involved with Simple Sequencing today.

Hi Mike,

I think your paper is exploring a way to make XML-encoded sequencing easier to understand (I am refering to SCORM 2004 simple sequencing as XML -encoded sequencing). I think the primary advantage is to call out all sequencing behavior instead of building in the hard to see default behavior. I like your approach.

But, I think it is better to eliminate XML-encoded sequencing entirely as I proposed in my white paper on SCO-based Sequencing. Here is one way to compare XML-encoded sequencing with SCO-based sequencing. Consider the cluster in SCORM 2004. The cluster's job is to receive the important information from the children. The logic of the cluster is implemented by the LMS. I am proposing we replace the cluster with a parent SCO. The parent SCO can directly launch and get SCORM data from child SCOs. The parent SCO provides the SCORM Runtime API to the child SCOs which allows the parent SCO to see when the child has sent important information such as completion status, success status, a score, etc. The parent-SCO can now implement sequencing, navigation and roll-up of the child SCOs.

Mike, I am very pleased to see your proposal. It is clear and straightforward. If sequencing is desirable at all, as you question Rustici - Reuse and Sequencing, and if it should vaguely resemble the XML-based structure of today (yet actually work and be simple), then this solution seems like the way to go.

I hope it doesn't face legal problems like being considered a "derivative work" of IMS Simple Sequencing. That would be a shame because your method is so superior.

I believe this is a good proposal for a sequencing mechanism, and certainly an excellent update to the existing Simple Sequencing set with what appears to be some observations that come from a lot of experience.

Rules on the current SCO are evaluated first, followed by the rules on the SCO's prent then it's parent: This seemed like a reversed order to me.  This is making the SCO the least significant set of rules.  I would think that you would want the SCO to be able to override something set at the parent, especially when it would come to navigation control and default values.

Every Item has a rule container:  If the item does not have  any sequencing is the container still needed, or is it simply empty?

Default Rules:  I was wondering why there is a need to mandate a default rule set.  Wouldn't there be packages that are simple enough that they don't use any sequencing rules?

 Interstitial Resources: I don't quite understand why these elements are being formally defined.  I understand their role, but if they are technically just SCOs or Assets, I don't understand why they would receive specific rule allowances as you indicated in the Navigation requests section.

Rule actions: Is there any method for creating action sets like condition sets.  I'm assuming that you are allowing them, but I didn't see that aspect specifically mentioned like you had defined the the condition sets.

 I think this is a good candidate for consideration and I like the specifications you put into it for rule evaluation and flow control.  The control system seems similar to the one I was thinking of in the paper that I submitted (here).  I don't really like the concept of roll-ups as they become restrictive on sequencing, you can't easily jump from one a node in one cluster to a node in another cluster, as may be usefull at times for review or scaffolding purposes.  To me clusters serve a better purpose as organizational units, not as data / logic containers that become non-communicating, restrictive micro-sites within a course.

Just yesterday someone was asking me if it were possible after every SCO to provide a screen that would provide the learner context and give them clear and precise navigation options.  I mentioned that I could do this now, but keep in mind that it would be a SCO and treated as such by the LMS and possibly clutter up some reports or progress pages.  Even with something like tracked=false, who knows what the UI will do.  This same person also had complaints about the progress page of his LMS being too confusing, with too many elements (scos) displayed.

Interstitial SCOs to the rescue?  It would be nice to have a well-defined, clean way to add contextual glue to the "standalone" activities of a course.

I have not studied the details of this proposal well enough to compare it fully to the existing Sequencing "book" in SCORM, but I believe it does not address the fundamental flaw in existing sequencing: Mike's sensible sequencing proposal still is based on a model of progressing through activities based on what the learner has done rather than on what the learner knows and needs.  

For example, the statement that "whenever possible, the data used by Sensible Sequencing is taken straight from the CMI runtime data held by a SCO" implies that data about learners is somehow tied to SCOs. It is not. It should be global and not tied to an LMS, let alone a SCO. Similarly, the "if-then" rules (which are absolutely the right approach IMHO) reference the status of items, but the status of items does not address the status of the learner.

I like the idea of every item participating in sequencing, and in thinking about that it struck me that entire problem of sequencing could be made even easier (and more sensible) by using a similar approach that includes

• Data on what the learner knows: The (global or temporary) status of learning objectives (or competencies)
• Data on what a learner has done: - within the current "course" or within any other course. In other words, why not simply attach the status of content to the content and not worry about when and where the content was seen?

I am also bewildered by the seeming complexity of  "roll-up" rules, and in thinking about this believe we might be looking at the wrong problem. The problem is not how to relate one object or one objective to others. That is simply done through a standard set of rules  of the type we use now or just by defining one to be a function of the other. (See Vlad's "maps" and Ostyn's "maps.")

The tricky part are the "business rules" associated with precedence. From a programming perspective, we can be sloppy about defining relationships if we are precise about avoiding conflicts and infinite recursions. From a more natural perspective, we need to worry about what happens when a mentor goes into the system and says "Mike is competent in X" and later Mike takes a course on X, blows it off, and fails it. My sense is that this is the area that needs some careful thought (and for which some relevant standards probably exist, since this is not a new problem, just a new context for a very common problem.)

Mike,

once again, awesome work. Your approach would definately simplify things, however, I also agree in principle to Leo's approach of bringing sequencing down to the SCO level.  Currently, there is such a heavy load on the LMS, and as we all know, hit or miss interpretation of how calls are being handled. With the welcome addition of much more robust support of XML within the ECMAscript/Javascript standard we have the capability to bring this down into content which would have to help alleviate some of the current bottleneck that can be created by the interdependancies as you pointed out.

As stated in another post, a SCO is such a nebulous, and contentious definition to some folks, why not propose to further define this through having external, Internal and Template-driven content aggregation SCOs, which ties well into Leo's idea.  I think about going one step further in terms of intra-SCO sequencing, to include the ability to incorporate SMIL so that entities defined within XML to be sequenced as a group of assets could use SMIL to define asset layout and timing. By using a simple template architecture for SCO aggregations, the sequencing and layout integrity could be maintained, but different organizations could reuse this aggregation while wrapping it into their own organizational template. This is already widely done using Flash+XML, but there is certainly no reason that this could not be extended to HTML/XHTL through Javascript and AJAX. But, with the variety of different content being discussed for support in terms of web 2.0/3.0 and gaming/HLA sims, would a tiered approach for SCORM make more sense?  I know that initially with SCORM this happened not through design, but through allowing vendors to choose what CMI elements they would support.  Similar to documented interactivity levels in various services ISD regs and DoD handbooks, why not have levels 1 though 4 which denote just how much CMI data is going to be worked with/available. This way both vendors and consumers have some type of "yardstick" to know what level of SCORM support is expected.

I know that both you and Rob see the difficulties with the whole issue of competencies, but I think with the metaextensions you mentioned could allow enough flexibility to provide various industries the ability to create these competency models.

Again, excellent work Mike.

Hi Mike,

This seems to me to be a very logical approach to a Simple Sequencing type requirement - but I wonder if we didn't take a wrong turn futher back - and we need to go chuck some of the underlying assumptions of Simple Sequencing.

What I mean is that the assumption that the item tree structure represents an organization of a couse - showing e.g. chapters, sections, pages, with each parent "containing" the material within it (with implications for rollup etc.) and that the student, in navigating the structure is browsing the course. The default requirement for SS becomes to manage which bits of the course are visible to the student and which bits aren't.

Shouldn't the "organization" node be thought of as a "presentation" and the item tree being about program flow, rather than course structure?

I think the student browser metaphor works OK for expositive assets, but raises all sorts of questions when you move to immersive SCOs. What happens when the student navigates away from a SCO - did he really mean to "finish" it or just take a look around?

I think the whole sequencing issue would be simplified if you started from the presumption that it was not about "what can the student see" but "what comes next". That means that we can start from the presumption that the student is running one thing at a time, that all navigation decisions occur after the SCO has called Terminate, and that there is therefore no requirement for any LMS interface at all to be presented while the student is running the SCO. I think that would solve a lot of problems that recur in these papers.

In the interests of preserving the rather dubious "SS" acronym, I'll call it "Synchronous Sequencing", even though you could add in asynchronous bits (such as multiple SCO toolsets and browsable arrays if you wanted).

I think you highlight a crucial issue with your "interstitial resources". I think the simplest approach would be to call them "messages" and allow formatted text (HTML maybe, but no links) including embedded variables (any CMI element for any SCO, or aggregated variables for the whole sequence) or conditionally displaying sections. That keeps a clear distinction between the reusable bricks and the easily applied, but discardable mortar.

Look forward to meeting you later,

Crispin.

There have been a couple papers and comments which cite this paper and give me credit for proposing Interstitial Resources. This credit is not due to me. I first heard of this idea through Claude Ostyn and am merely continuing to advocate for something he (and perhaps others) proposed long ago.