Unpublished Captivate variables
A recent post in the e-learning development forum reminded me that I forgot to post some unpublished Captivate variables I dug up a while back.
Short posts containing helpful code snippets and general advice.
A recent post in the e-learning development forum reminded me that I forgot to post some unpublished Captivate variables I dug up a while back.
Ok, I just had to write a quick blurb about this one: in about 3.5 years of using SCORM in my own course code, I had never used cmi.core.exit
(SCORM 1.2) or cmi.exit
(SCORM 2004). Seems incredibly daft of me now that I’ve taken a few minutes to review the documentation.
When I designed the LegacyCaptivateLoader, I was focused on giving the ActionScript 3 SWF the ability to control the ActionScript 2-based Captivate SWF; I hadn’t given much thought to how the situation affects Captivate SWFs using one of the workarounds I just described. Can the embedded SWFs still work? Will JavaScript calls from Captivate still work with ActionScript 3’s ExternalInterface system? The short answer is yes, but it may take some tweaking on your part.
I read not one, but three great blog posts today regarding what kinds of questions you should asking yourself when working on a project. Two of the blogs were not specific to the e-learning industry, but they apply nonetheless.
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.
There are a great set links for free development tools (validation services, browser toolbars and plugins) posted on the Web Access Centre Blog today:
Here’s a simple example of how the SCORM AS3 class can be utilized. (This example uses SCORM 2004 calls.)
My attempt at outlining standards and best practices throughout the e-learning development cycle.
In the new HTML 5 proposal, the strong element is being modified to represent “importance rather than strong emphasis.”