Being an idealist, I eagerly bought into what was being covered in grad school. I believed (and still do, to a point) that every project should follow ADDIE or a similar model. C’mon, it makes sense, doesn’t it? The line in the sand had been drawn: skip these principles at your own peril. Now that I’ve spent a few years working full-time as an instructional designer-slash-e-learning developer, I’ve learned first-hand that the instructional design ideals taught in grad school are quickly thrown out the window when you get a “real” job.
You may be familiar with the famous “Captivate variables” (see page 201 in PDF link), but did you know about “rdcmndHidePlaybar”? It isn’t mentioned by Adobe in their documentation, but it’s a handy one to know about.
Adobe has a short but useful article detailing how to make your Adobe Captivate movies more accessible.
These are pretty simple (borderline “no-brainer”) steps a Captivate author can easily implement.
I researched the different methods available for AVM1 to AVM2 communication, and discovered there are a few workarounds that can enable the AS3 SWF to communicate with the AS2 SWF. I spent the entire day whipping up a Captivate-specific proof-of-concept.
Today was the day… I gave a presentation at the eLearning Guild’s DevLearn 2007 conference in San Jose. Topic? Captivate-to-Flash ActionScript Communication.
Here are my first impressions of Captivate 3’s improvements and new features.
Captivate 2.0 doesn’t include the ability directly manipulate Actionscript. This has been problematic for people like myself who have Flash-based ‘players’ that load and unload both Captivate SWFs and Flash SWFs; we often need the Captivate SWF to perform some kind of action when it reaches its end.