Thoughts on using JavaScript in Adobe Captivate

Having just finished my Making Actionscript calls from Adobe Captivate tutorial, I’ve been looking at Captivate 2.0 a lot the last few days. Specifically, I’ve been looking for ways to use JavaScript in Captivate. I’m a bit disappointed to report that JavaScript can only be used in very limited instances.

From what I can gather, JavaScript calls can be made in the following instances:

1. At the end of a slide
2. At the end of the movie
3. When a clickbox or button is clicked
4. When a text input field is used

“That sounds like plenty of ways to use JavaScript,” you say? Well, the major shortcoming is this: if you choose to execute JavaScript in any of those cases, you’re giving up the ability to use the other ‘Navigation’ options, such as ‘go to next slide,’ ‘go to previous slide,’ ‘jump to slide,’ ‘open URL or file,’ and ‘open other project.’

As you can see in the image above, Captivate only allows you to choose ONE ‘navigation’ option. You can’t execute JavaScript and jump to a slide.

In some cases this may be fine, but what if your Captivate movie is a scenario with branching? A button click or other interaction must occur to tell the movie to jump to the appropriate scenario slide. If you choose to execute JavaScript instead of using a ‘jump to slide’ action, your scenario is toast… you will not be able to navigate to any slide other than the next slide in the timeline.

Johnny doesn’t play well with others

The bottom line is that Captivate is being developed as a stand-alone solution, and is not really meant to integrate with any other course development tools.

A Captivate SWF can be embedded in an HTML-based course interface, but doing so will render the built-in interaction tracking system practically useless. The tracking system is designed to deliver data in a limited, pre-packaged capacity; there is no obvious way to access to the raw tracking data. For instance, if you want to get SCORM calls such as lesson_location from the Captivate SWF, there’s no clear, easy solution for doing so. And there’s no way to set up the Captivate file as a component of a SCORM course… it’s meant to be a be-all-end-all solution (for example it will do ‘LMS initialize’ calls, which is a no-no in the middle of a course).

A Captivate SWF can be loaded into a Flash-based course interface, but because there is no easy access to the Captivate SWF’s Actionscript code, it’s a huge challenge — though not impossible — to extract Actionscript variables from a Captivate SWF. This includes tasks such as controlling the Captivate SWF’s playback using your own Flash playback controls; The sheer number of Captivate ‘help’ sites dedicated to this normally simple exercise is proof enough.

Have you ever tried decompiling a Captivate-generated SWF and inspecting its Actionscript? It’s very enlightening and utterly confusing! (FYI SoThink SWF Decompiler has a limited trial version you can use if you’re curious).

And NO, asking us to export the Captivate movies as FLAs and then customizing in Flash is NOT an appropriate solution. Big chunks of functionality and settings get lost in the conversion, and you can’t send the FLA back to Captivate. It’s a path of no return. The whole point of Captivate was to make things quick and easy and avoid having to do heavy lifting in Flash.

In many ways, Captivate is a great product. It’s the best software I’ve ever used for creating software simulations, and the SWFs it creates are much smaller than video-based tools such as Camtasia.

However, until the Captivate design team starts acknowledging the needs of course developers who use Captivate as a small part of their development toolbox, we will be stuck pulling our hair out and spending hours on end searching for workarounds. And that kinda sucks, don’t you think?