| Tim, 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. Yes, SCORM content developers must adhere to _javascript_. Deal with 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. Almost every browser under the sun supports _javascript_. Yes that's a sweeping generalization. You can nitpick it all you want. If you're decent (not an expert) at writing _javascript_, you can make it so your 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 build content, you need to use _javascript_ to access the LMS's API. 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. -a- On Aug 18, 2005, at 4:48 PM, Tim Beynart wrote:
|
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
