[osflash] Open Source Interaction Components

[Aaron Silvers]

Tim,

Obviously I'm somewhat biased because I make my living teaching other  
developers about how SCORM works.  But if you consider that I have a  
lot of knowledge on the subject, and a competitively broad knowledge  
of Flash and ActionScript development, let me posit this:

What is it that SCORM *doesn't* allow as far as the "asynchronous,  
non-traditional interface that is the strength of Flash?"

I'm not trying to be glib (I'm not Tom Cruise), but honestly, the  
strength and weakness of Flash lies almost completely with the  
creativity and ingenuity of the designer/developer -- not the  
platform Flash runs on.  That's like an ASP developer saying that he/ 
she can't make compelling RIAs because PHP is so __________.

That's not to say SCORM doesn't have a part to play.  Yes, it imposes  
constraints.  As does any other technical framework you'd have to  
work in.  Want 508 compliance?  Guess what, that imposes constraints.

I agree with you that I have yet to see something truly visionary or  
compelling in Flash-based E-Learning content.  But I'd have to say  
that I've yet to see any E-learning content that wasn't, at the core,  
some kind of page turner.  And that's not a limitation that SCORM  
imposes.  Even without SCORM, this is the content I've seen in the  
past six years of developing E-learning content.

What you're seeing is an important niche that's still in the toddler  
ages.  The cool stuff will come when there's a reason to build it.   
And in a market that values efficiency over effectiveness (or  
research, or experimentation), you're not going to break out of the  
box overnight.  You're going to only see slow moves.

But let me address the technical myths about SCORM.

Yes, SCORM content developers must adhere to JavaScript.  Deal with  
it.  The universal "player" for SCORM content is the web browser.   
Why?  Because it's ubiquitous.  Linux, Mac, PC, Solaris, your phone,  
your PSP (any hour now) -- these all have web browsers, and because  
of that, your content that is viewable in a browser has the best  
chance of being experienced by everyone without having to port it  
specifically for any one system.

Almost every browser under the sun supports JavaScript.  Yes that's a  
sweeping generalization.  You can nitpick it all you want.  If you're  
decent (not an expert) at writing JavaScript, you can make it so your  
product works on Safari, Firefox and IE.  Maybe your PSP, your PDA  
and/or your phone will support JS, too (eventually).  The point is,  
the browser is ubiquitous as is its support for JS.

.Net, C#, C++ -- great technologies, but platform dependent. SCORM  
doesn't say you can't use them.  It just says that if you're going to  
build content, you need to use JavaSCript to access the LMS's API.   
And if you're an LMS, you have to display content in a browser window.

The next complaint I hear a lot (and I've raised it myself) is the  
fact that I can't build my own Flash "player" .swf and rely on the  
manifest I create to sequence other .swfs in and out of that  
player .swf.  Net-G does something very similar to that in Java, and  
that kind of support would be awesome for Flash, because then you can  
also control the entire user experience.  I understand that side of  
it.  I hate having to load and unload content and that lag as the LMS  
serves up another content object.

But there are some "design" issues that we have to consider, too.   
Pedagogically and Androgogically speaking, why would we want our  
learners to have to learn how to navigate a brand new interface, with  
all its metaphors, every time they launch into new content.  Maybe we  
need to go simpler, not heavier into the UI, and rely on Flash for  
what, as you say, it does most often -- eye candy.  Things that add  
to the learning.

As for user interactions, there are a lot of choices in SCORM.  Sure,  
you have the classics, but they also supply you with an "other"  
interaction.  What's "other?"  Whatever you want it to be.  It  
accepts a 4,000 character string.  Drop in some XML, your mother's  
address, your ex-girlfriend's phone number -- whatever you want in  
whatever format of string you want to share.

Now the API confines you to seven simple commands, with a data-model  
that supports about 26 different elements, most of which have several  
parameters.  Three of the API commands are definitely debugging/ 
troubleshooting methods.  Some of the Run-Time Data Model elements  
are pretty banal (learner_id, learner_name) and some very powerful  
(objectives, interactions, score, completion_status,  
success_status).  I would love it if there was an existence of a  
global data storage space that could be accessed from any SCO in the  
content package.  It doesn't exist... yet.  There is a model for  
Shared State Persistence (SSP) that may be rolled into SCORM into the  
future.  When, I don't know.

I could go on, but you get my point.  I'm biased since this is how I  
pay my bills, but because this is how I pay my bills, I know a lot  
about it.  Take this for what you will.

-a-

On Aug 18, 2005, at 4:48 PM, Tim Beynart wrote:

> While I laud the effort to standardize eLearning transactions using  
> SCORM, I just can't sign on to a system that is (in my view) so  
> fundamentaly flawed. Perhaps I am misunderstanding, so correct me  
> if I am wrong, but SCORM requires a page-turning interface with  
> content, with a round-trip each time a "learning object" is loaded  
> and used. It also requires very specific scoring syntax, correct? I  
> did some research into it a year ago, and was mortified by the  
> adherence to JavaScript. Beyond that shortsighted spec, I found the  
> API confining from an architecture standpoint.
> During my research, all of the work done using Flash was based on  
> the paging model of traditional web pages. Flash was pretty much  
> simple eye candy (Did someone say FutureSplash?) in every example I  
> found. On top of that, the user interactions were the classic,  
> boring checkboxes, radio buttons, etc. SCORM doesn't appear to be  
> designed for an asynchronous, non-"traditional" interface that is  
> the strength of Flash.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/osflash_osflash.org/attachments/20050819/a4b6d3d8/attachment.htm