Community Forums

Community Discussions

Three Problems with SCORM


You must be signed-in to post.

AuthorSubject
 
Page: 1
greg

Avatar for greg
Subject: Three Problems with SCORMQuote this post in your reply
[In response to Rafaeldff www.atutor.ca/view/7/2758/1.html ]


First, everything we develop at our centre is required to conform with accessibility specifications (WCAG), so people with disabilities are able to participate equally in all learning activities. One of the accessibility rules is that if client side scripting is used (namely Javascript), it must also function effectively without scripting. Because SCORM SCOs rely on scripting and will not function otherwise, they fail this rule.

Second, from both accessibility and engineering perspectives, content, presentation, and controls need to be separated. In SCO's the javascript navigation controls are not separable from the content in which they are embedded, thus limiting how an LMS might choose to display navigation elements.

Third, because I am required to use Javascript to present SCO controls, I am limited as a developer in how I can choose to implement the SCORM specification. The SCORM specification has become technology dependent. This should not be.

We have a better way to implement SCORM to meet our accessibility requirements, but we can not implement it and be compatible with current SCOs. We can make current SCO's work, but they would not be fully accessible. We're suggesting moving all the sequencing rules, currently contained in the embedded scripting, into an xml file and letting the LMS decide how to present to navigation elements, whether through Javascript or through some other means.

What we would like to propose is the eventual removal of the embedded javascript buttons in favour of an XML based strategy for defining sequencing rules in SCOs. There is much resistance to this from SCORM folk. It would be a major shift in the specification that would effectively make all current SCOs obsolete. They would be right to say that such a proposal would unlikely be adopted. Over the long term however, shifting from a specification that requires client side scripting, to one that can support client side and server side methods simultaneously, would make the specification more robust, and more compatible with accessibility specifications.

It's a longer story than that, but you get the idea...
Posted: 2004-10-15 18:48:41
petervb
Subject: XML based strategy ?Quote this post in your reply
Hi Greg,

If you say XML based strategy for SCORM. What about the last version of the Reload Editor? Did I understand correct that he does make a content package where the navigation is in the XML-file (manifest)?
Posted: 2004-10-18 08:43:18
petervb
Subject: XML based strategy ?Quote this post in your reply
Hi Greg,

If you say XML based strategy for SCORM. What about the last version of the Reload Editor? Did I understand correct that he does make a content package where the navigation is in the XML-file (manifest)?

Regards,

Peter
Posted: 2004-10-18 08:43:31
Rafaeldff
Subject: XML manifests and SCORM 2004Quote this post in your reply
Hi Greg,
Weren\'t these problems you related mitigated by SCORM 2004? I have yet to dig deeper on the spec documents, but doesn\'t the implementation of IMS Simple Sequencing as part of the xml manifests acompaning content packages enables the creation of non-communicative content with sofisticated sequencing behaviour? Or is the dependency from the SN book on the RTE bigger than I\'m imagining?
BTW, you\'ve been very helpful, I didn\'t think of accessibility considations regarding client-side code before you brought it up.
Thanks.
Posted: 2004-10-18 13:06:21
greg

Avatar for greg
Subject: Reload javascirpt-less SCOs?Quote this post in your reply
I haven't played with the most recent Reload, but I would be happy to hear that it allows Javascript-less SCOs. Can anyone confirm this?

In reply to:
Hi Greg,

If you say XML based strategy for SCORM. What about the last version of the Reload Editor? Did I understand correct that he does make a content package where the navigation is in the XML-f...

Posted: 2004-10-18 15:13:54
greg

Avatar for greg
Subject: ECMAScript References.Quote this post in your reply
The current RTE specification makes references to ECMAScript usage throughout, and no reference to any other means of communicating between SCO and LMS.

Every SCO I have come across has had embedded Javascript, which as you know, compromises accessibility.

Implementing the IMS SS spec is exactly what we want to do, but without having to use Javascript to allow SCOs to communicate with the LMS. Its not the SCORM implementation of SS thats the problem. It's SCORM's reliance on Javascript or ECMAScript, that's a problem for us.

We may just end up implementing our own technology independant SCO authoring tool and RTE, but our SCO's would not work in any other system, which all expect embedded javascript controls to do the communicating.

I would like nothing more than to have another system implementing javascriptless SCOs, like Reload as suggested above (though not confirmed), so we could work off each others efforts to correct the current SCORM roadblock.

In reply to:
Hi Greg,
Weren\'t these problems you related mitigated by SCORM 2004? I have yet to dig deeper on the spec documents, but doesn\'t the implementation of IMS Simple Sequencing as part of the xml ...

Posted: 2004-10-18 16:19:20
 
Page: 1

You must be signed-in to post.

Related Articles