Thursday, March 02, 2006
SCORM SCO Presentation Engine (S2PE)
Here is an interesting article by Kraig Mentor on using SCORM with Director, SCORM SCO Presentation Engine. I like how this technique can greatly reduce the HTML page clutter that can build-up in manifests that use simple OBJECT tags. I like how much of the content can be externalized. It seems like a very similar technique could be used with Flash. I do have some hesitations about what this means for bookmarking, obscuring the programming for experts, and securing the content (DRM or otherwise).
I recall a cross-product/platform strategy like this from Wicat that was referred to as "Nemesis". The idea was that a database (or in the S2PE case, XML) contains the guts of a the elearning presentation. Then an "engine" reads that data and renders the elearning.
In the Wicat case, this provided flexibility to deliver training in a customer's preferred format-- they could write an engine in Authorware, IconAuthor, ToolBook, or virtually anything that coul "play" the presentation database.
The challenge with a presentation engine approach is that you lose many of the benefits of the host system or language-- Director Lingo or ActionScript idioms and optimizations are often lost in the database representation, and an individual developer's proficiency becomes less valuable. Conversely, that de-valuing of AS or Lingo expertise, can make it much easier to do automation, mass production, or farm things out to non-experts. Ironically, it can also make things much harder for a host system expert who comes in to a project later; their hands are tied to the data structures in what seems like unexpected ways.Labels: SCORM
Comments:
I'll have to spend more time going over this in detail, but on the surface it doesn't look like anything terribly revolutionary, unless it aims to be player-agnostic.
Right now, we use a system (all-Flash), wherein there's a SWF responsible for LMS interaction and course navigation. What's loaded into that SWF can be a static SWF, or other SWF apps that rely on their own XML data. This blended approach gives us the benefits of re-usable functionality and the ability to handle those awkward customization requests that don't quite fit into a template.
Sure, we have piles of XML files, but we use Access to create and manage them. A small price to pay to be able to package up a course that flexible without relying on an app server. We also abuse the hell out of cmi.suspend_data to give us a very granular level of tracking, but that's what it's there for.
On top of all that the framework provides an interface for tracking classes to use with it, so when we get that customer with a home-grown LMS that doesn't support any standards, we just write a new class that does the specifics, customize the JS if necessary, and send it out the door. (This works well with the swf as a dll technique listed on OSFlash.org).
Right now, we use a system (all-Flash), wherein there's a SWF responsible for LMS interaction and course navigation. What's loaded into that SWF can be a static SWF, or other SWF apps that rely on their own XML data. This blended approach gives us the benefits of re-usable functionality and the ability to handle those awkward customization requests that don't quite fit into a template.
Sure, we have piles of XML files, but we use Access to create and manage them. A small price to pay to be able to package up a course that flexible without relying on an app server. We also abuse the hell out of cmi.suspend_data to give us a very granular level of tracking, but that's what it's there for.
On top of all that the framework provides an interface for tracking classes to use with it, so when we get that customer with a home-grown LMS that doesn't support any standards, we just write a new class that does the specifics, customize the JS if necessary, and send it out the door. (This works well with the swf as a dll technique listed on OSFlash.org).
It's not revolutionary, but my hope is that it might be evolutionary in so far as enabling non-programmers to create engaging SCORM content.
Creating a WYSWYG user interface (in progress and not covered in the article) lets the graphic designer layout content and see their vision. That as opposed to the designer passing content off to the programmer.
That the designer does not have to know about whats under the hood, or understand SCORM is important. The tool isnt targeted at programmers, though the article is. As a programmer, I certainly would prefer my own implementation to anything I can currently buy off the shelf. However, as a designer, I may not have that luxury.
Off course, anyone could write a playback engine that supports the XML. That is a goal and we have Flash version underway.
Best Regards,
Kraig Mentor
Post a Comment
Creating a WYSWYG user interface (in progress and not covered in the article) lets the graphic designer layout content and see their vision. That as opposed to the designer passing content off to the programmer.
That the designer does not have to know about whats under the hood, or understand SCORM is important. The tool isnt targeted at programmers, though the article is. As a programmer, I certainly would prefer my own implementation to anything I can currently buy off the shelf. However, as a designer, I may not have that luxury.
Off course, anyone could write a playback engine that supports the XML. That is a goal and we have Flash version underway.
Best Regards,
Kraig Mentor
External links to this post:
Mobilemind RSS Feed