Hey Aral,
I'm a little bit confused by this thread. _javascript_ to Flash communication is possible and nothing in the SCORM spec would prevent an LMS from being written in ActionScript (I believe this has actually been done--just trying to recall who did it).
You can't manage state in Flash??? Sure you can manage
your state in Flash. I typically create a single shell in Flash and load
modules into that shell. Each separate swf module is assigned a SCORM objective
ID and when I'm done with a particular module I use the SCORM RTE (using
fscommand, JS / Flash Integration Kit, etc.) to tell the LMS that I've completed
that particular objective. This allows you to quit a "session" and
return, query the LMS, and pick up where you left off. All state in "session"
is handled client side. You can change "content" or modules without
the "page turn" (I'm reading this as screen refresh) as much as you
like. Objectives can be scored as well which allows for quite a bit of power
and flexibility and when you combine them with prerequisites I'm not sure what
you lose with SCORM that you gain otherwise.
The same goes for quizzing--I manage all state on the
client-side (I'll typically jump through 25-30 questions randomly pulled from
an xml document. Each question is assigned an interaction id by me in
ActionScript and I pass my interaction results back to the LMS on the fly
without a "page turn". If I'm categorizing the type of interaction I
am limited by the spec to the following:
true-false
choice
fill-in
matching
performance
sequencing
likert
numeric
In my view these pretty much cover the gamut of questions
types (fancy interactions often boil down to one of these core types in the
end). The larger issue is not the limitation of the spec, but the limitations of
the organization and users you are delivering training to--trying to teach the
average end user who doesn't hang out on the osflash mailing list how to
"drag and drop" is a tech support nightmare.
As another example, I've worked in the airline industry
for the last year and a half and gotten to know quite a bit about most of the US based
majors. It may shock you to know that the world's largest airline still is
Windows 98 based and they are not the exception, but rather the rule.
In my thinking, trying to manage "state" with
the RTE is the absolute wrong way to approach Flash based SCOs. Instead, try
thinking of the LMS as your database and JS as the means of pushing and
retrieving data. SCORM does impose restrictions--every spec or API will, but it
does achieve the goal of being interoperable and reusable across platforms. The
worst problem with the SCORM spec is the lack of documentation and therefore
how poorly its understood.
Ok, jumping off the soap box and feeling a bit winded....
Is _javascript_ to LMS clunky--absolutely; I'm a Flash guy
not a AJAX guy
after all. Is the SCORM governing body slow to make changes to the spec? Definitely--imagine
what would happen if the IEEE were to change many of its existing hardware
standards. Finally, do I appreciate the many amazing people involved in the open
source Flash community--hell ya, you guys rock!
Just my two cents,
Brooks Andrus
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Aral Balkan
Sent: Friday, August 19, 2005 4:13 AM
To: Open Source Flash Mailing List
Subject: Re: [osflash] Open Source Interaction Components
Hi Aaron,
> What is it that SCORM *doesn't* allow as far as the "asynchronous,
> non-traditional interface that is the strength of Flash?"
You can't build a Flash LMS (ie., modules can't talk to a SWF using
_javascript_.) Thus you are limited to the page model and having the
controller be in HTML (or other technology that supports _javascript_.)
The opportunity to manage the learning experience using two of the
greatest advantages of Flash (maintaining state, lack of refreshes) are
lost.
> Yes, SCORM content developers must adhere to _javascript_.
This is SCORM's fundamental flaw. It should have been an XML protocol
*not* a scripting language. What is being exchanged is data -- who cares
*how* that data exchange occurs as long as the various parts know how to
deal with a well-defined schema.
To put things into perspective somewhat, we work in an industry in which
there's a ~70% failure rate for projects. (Thus, the overwhelming
majority of software that gets produced does not meet end-user needs and
is rejected.) Unfortunately, with the government support that SCORM has,
it will continue to live on, flawed as it is, without change because
that is how large bureaucracies (and their products) operate (ie.,
inefficiently.) If you work on government e-learning projects, then you
have no other choice but to bite the bullet and use SCORM. Otherwise, I
don't see any reason to adhere to such a flawed specification.
All this just reminds me why I love the open source world with its lack
of bureaucracy, dynamic nature, steely pragmatism and boundless energy! :)
Aral
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
