I'm responding to Jamie's question about why I thought the SCORM
solution suggested here might make it unnecessary for us to worry about
creating an additional interface between Moodle and Flash.
I'm now
feeling a little colder towards the SCORM approach due to the problems
I'm experiencing when trying to put together SCORM packages that work
within Moodle and to the issues Jamie mentions in his last posting
concerning the use Flash makes of some non-mandatory parts of the SCORM
data model not supported in Moodle. If these issues were solved, though, and
building SCORM packages were made easier for the average user, this
would be the ideal solution to integrate Flash with Moodle. I'm going
to try to explain why I think so.
As I see it, the main challenges for integrating Flash with Moodle are the following:
1) Have Flash communicate with the Moodle data base (Jamie appears to have solved this problem)
2) Finding an easy way for the average user to incorporate a Flash applet as a Moodle activity.
Problem 2) in turn can be subdivided into two different problems:
a)
The problem of inserting the Flash applet in one of the courses just as
now we can insert a forum, a quiz, etc. without having to write any
scripts or having to modify any pre-existing code by hand.
b)
The problem of being able to reuse (wasn't the current buzzword
'repurpose'?) the same basic applet for different activities (i.e. same
applet with different "contents").
Problem (b) needs a little
explaining since it hasn't been specifically discussed before as far as
I know. Let me give you an example to illustrate what I mean a bit more
clearly. Say I create a Flash applet where the user sees a text
and
s/he is asked to click on or mark in some way all the words related to
emotions, or all the words that have to do with human behavior or all
the words that have negative connotations and so on. As everybody that
has worked with Flash knows, creating an applet is a very time
consuming and painstaking process. So if I create an applet like the
one I'm describing, I would want to do it in a way that allows me to
reuse it to repeat the same basic type of activity in however many
courses I need it.
If I do it this way, I will need to work very hard
only when I design and implement the basic structure and objects that
make up the applet. After the basic applet is created, though, 80% of
the work is done: I will simply have to change the words from the texts
and reassign the correct and incorrect answers every time I want to
produce a new version of the activity. But, crucially, if I want to
create new instances of the same basic type of activity,
i.e. one that follows the same or a similar kind of pattern, I won't
have to rebuilt the applet from scratch again.
Here's
where the Flash 'components' I mentioned before come in to play and
where the issue of SCORM vs. additional 'interface' becomes relevant.
If we want to reuse or repurpose Flash applets within Moodle in the way
I have described, one of the two following conditions would have to be
met: either i) we can have an interface* between Moodle and the Flash
applet that allows the course creator to easily change the contents of
each specific type of applet and thus be able to add new instances of
the same type of Flash-based activity to the courses or ii) we do not
have any additional interface between Moodle and Flash but instead we
have a more or less easy way to change the contents of the applets
outside Moodle. That is, in order to create a new activity in Moodle
based on a particular type of applet, we would simply have to
manipulate the basic applet outside Moodle to change its contents and
then insert the new instance of the applet into Moodle. As you might
have guessed, a way to insert applets into Moodle without having to
worry about writing or modifying code (problem 2.a) is doing it via
SCORM.
* In order to avoid confusion, perhaps it would be useful
here to be a bit more precise about what we mean by interface. When I
talk about interface I mean some kind of input form that enables the
creator of the activity to give 'content' to the Flash applet. Thus the
interface for the quiz module would be the two input forms the quiz
creator has to fill out in order to insert a quiz in a course: the one
with fields like 'name', 'introduction', 'open quiz', 'close quiz'
etc., and the one for each specific type of quiz with fields like (in
the case of a 'multiple choice' type quiz): 'choice 1' : 'feedback',
'choice 2' : 'feedback' and so on.
Alternative ii), as I said,
would be the one that can be implemented via SCORM and the one that
would leverage the so-called Flash components (
http://www.macromedia.com/devnet/mx/flash/articles/components.html).
As I mentioned in my earlier post, with the new feature in the MX
version of Macromedia Flash called 'components' it appears to be fairly
easy for the average user to customize applets to meet his/her needs
and recycle the same applet to create many different instances of the
same basic type of activity. With components applets can be built using
a modular architecture (each one of the 'objects' that makes up a
particular applet can be a highly and easily customizable independent
"movie clip") and thus working with a particular applet becomes a
little bit like working with templates when creating web pages.
As
I said, alternative ii) avoids the problem of having to create an
additional interface between Flash and Moodle. This is more important
than it appears at first sight because, if you think about it, the
problem with the interface approach is that we need the interface to be
flexible enough to keep pace with the enormous range of possibilities
one has when building Flash applets. If we were to restrict ourselves
to reproduce the typical quiz modalities (multiple choice, True/False
and cloze) in Flash format, building an interface similar to the one we
now have for quizzes would perhaps not be all that difficult and
probably would be the way to go. But once we get to be more imaginative
with Flash, being able to build an interface for each new type of
applet could become a daunting task. If we can "feed the contents" to
the applet outside Moodle and then integrate the applet simply by
adding it as an activity (via SCORM or whatever other method) we solve
parts a) and b) of problem (2) at the same time. People who build the
Flash applets can even create Flash interfaces for data input in their
own applets as you can see in:
http://www.roothouse.com/RootAll
this being said, though, I go back to the concerns I expressed at the
beginning. From my own experience and from the discussions in the SCORM
module forums, I have reached the conclusion that the integration of
SCORM
into Moodle is still rather problematic. Building SCORM
packages is not the most intuitive and easy task, either. So, what we
gain on one side we lose on the other.
Josep M.
