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
