[osflash] Open Source Interaction Components
aaron.silvers at gmail.com
Thu Aug 18 21:07:52 PDT 2005
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.
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.
sweeping generalization. You can nitpick it all you want. If you're
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
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.
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
> 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...
More information about the osflash