Thx Aaron, this was all
very clear. I have started to implement SCORM in our Flash-Player, and it looks
great.
Another challenge will be
to let our LMS read SCORM-packages. It seems more difficult. How do other
companies do this? I’ve seen some open-source SCORM-players. Can you plug
these in your LMS or do you need to implement your LMS to read the packages.
I’ll keep you
updated on my efforts.
lieven cardoen
indiegroup
interactive
digital experience
engelse
wandeling 2
k18
b8500 kortrijk
T +32
(0)56/361 197
//
communicatie bij voorkeur op [EMAIL PROTECTED].be
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Aaron Silvers
Sent: zondag 30 april 2006 14:29
To: Open
Source Flash Mailing List
Subject: Re: [osflash] SCORM
All good questions. My responses are in-line
So I understand that it's better to leave my
'flash player' as one. But won't my 'flash player' (which can contain hundreds
of exercises) be threated as one item by the LMS?
It will be treated as one SCO by the LMS. That SCO will have hundreds
of files listed in its resource inside your imsmanifest.xml
Or is it possible to pass to the LMS a score for
each exercise in my 'flash player'. The scorm-manifest will have one item, but
my manifest will have hundreds of items.
You can only record one "cmi.score" per SCO, but each SCO can
have hundreds upon hundreds of interactions (check out "interactions"
in the RTE document in Chapter 4: Run Time Data Model), and each interaction
can have its own score recorded by the LMS. This score isn't related on
the LMS side to the overall cmi.score of the whole of the content, but you as a
developer can tie the two together, just as you would to produce an overall
score for the content anyway. The difference is that you have a mechanism
for recording a score for each exercise, and that is in the cmi.interaction.
You can also tie each exercise to a cmi.objective, and each objective can have
its own cmi.objective.score. This is the method I would advise as
instructionally it makes more sense to tie activities to learning objectives
than recording each question of an exercise for its own merit.
Some very major differences. The Plug-In Technology Example from
ADLnet.org was created almost a full year before the Flash/JS Integration Kit
came out and relies on ASBroadcaster and a series of callback functions in
order to communicate with the _javascript_ layer of your content. Also, to
make things easier on the communication side of things, we had better luck
internalizing the SCORM APIWrapper _javascript_ functions inside of ActionScript.
Now this worked GREAT -- Alan was able to queue our SCORM calls and not rely on
FSCommand, which were my two main goals. But from a maintenance
standpoint, it's a pain... mostly because of internalizing the APIWrapper
inside of ActionScript. If I'm creating a content package with only this
Flash file -- sure, this is a fine solution. But if I were to create a
larger content package with other SCOs, and mix up the technologies -- now I
have APIWrapping functions in a _javascript_ file AND nested inside of
Flash. Two places where I have to maintain the same code -- it's
sloppy. With the Flash/JS Integration Kit, everything in my entire
content package can use the same methods in the same file. It's better
coding. Plus... the Flash/JS Integration Kit is actively maintained,
which is more than anyone can say for the SCORM2004Obj.as class. There is
currently no Flash developer on ADL or employed by CTC (who staffs the ADL
Technology Center) tasked to maintain this code.
Thirdly, there's one thing I don't seem to
understand. How does the _javascript_ communicate with the LMS? Does it go and
search for an API and how? If I deliver a SCORM-package, I can't know how
another company calls it's API…
This will sound pretty silly, but if you look at that APIWrapper code,
all it's doing is searching the chain of parents for an instance of the API
object, and after 500 levels of searching (or some other silly arbitrary number
like that), if it does't find the API, it just fails. The good news as you
don't have to worry how another company calls the SCORM API. By nature of
the fact that an LMS passes the SCORM conformance test, it means that they will
provide an API that conforms to whatever version of SCORM it's using ( 1.2 or
2004).
the things you really need to worry about are things that are very hard to test
for. Cross Domain scripting issues are a huge pain in the butt for me
(and I'd like to think I know quite a bit about SCORM development).
--
-a-
Aaron E. Silvers
[EMAIL PROTECTED]
http://flashforlearning.com
------------------------------------------
"Whoso would be a man must be a nonconformist." - Ralph Waldo Emerson
|
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
