Captivate-JavaScript limitations

Captivate SWFs can communicate with the host HTML file via JavaScript, but the scripting options suffer from severe limitations imposed by the Captivate authoring environment.

For starters, this communication is (generally) a one-way street: the JavaScript goes out of Captivate to the HTML file, but the JavaScript in the HTML can’t really ‘talk’ to the Captivate SWF.

Here’s a simple example of a Captivate SWF calling a function located in the HTML host. Once the JavaScript in the HTML file receives the function call, it executes it. In this case, the function identify() will manipulate DOM elements to display a message. [ Download the source files. ]

The ability to send JavaScript calls from Captivate SWFs should open up a number of possibilities, even if we’re limited to one-way calls. A few ideas off the top of my head:

• Use JavaScript to track a user’s choices or actions while interacting with a scenario-based (branching) Captivate SWF.
• Use JavaScript to control the SWF’s navigation.
• Use JavaScript to relay SWF data (such as current slide number, clicked items, etc.) to the HTML container for an AJAX-like user experience.

However, Captivate’s JavaScript capabilities suffer from three severe limitations:

1. The aforementioned one-way-street issue
2. Only static hard-coded calls can be made
3. JavaScript can only be executed in limited circumstances, and at the expense of other Captivate functionality

The first item is pretty obvious, so I won’t go into it here.

The second item is absolutely painful. Captivate’s JavaScript capabilities are limited to static hard-coded calls; Captivate doesn’t allow dynamic JavaScript variables, such as a dynamic call based on the slide number. This eliminates the ability to use easy-to-maintain dynamic code, which means you’d have to spend hours hand-coding every little JavaScript call in the SWF. This can get very complex very quickly, and is a royal pain in the buttocks.

Matter-of-fact, Captivate makes it hard to do ANY kind of dynamic scripting, whether it’s JavaScript or ActionScript; ActionScript is the native language for Captivate SWFs, but is strangely — and strictly — off-limits to Captivate users.

(I don’t know what the folks at Macromedia/Adobe were thinking when they implemented such poor scripting functionality into Captivate… they have a proud history of making their applications scriptable — Authorware, Director, and Flash were all astounding successes — but they really dropped the ball with Captivate.)

The third item is when/where JavaScript can be executed from Captivate. Captivate’s developers took an odd approach and decided that JavaScript can be executed:

• When something is clicked
• At the end of a slide
• At the end of the movie

To complicate things further, only ONE action can be taken per event. This means you can either choose to execute JavaScript, OR you can jump to another slide OR you can send e-mail, etc. If you want to execute a single line of JavaScript, you will be forced to give up any navigation option other than allowing the movie to progress to the next slide (playing the SWF linearly).

This eliminates the ability to use JavaScript when working with branching or other non-linear navigation in Captivate, unless you implement crazy workarounds, such as building empty slides that execute JavaScript a split second before transitioning to the intended slide.

Summary

When I started this journal entry, I had no intention of writing a rant. However, while trying to come up with useful examples of Captivate-JavaScript functionality, I was reminded just how ugly Captivate’s JavaScript support is. C’mon Adobe… you’ve created ActionScript 3.0, Flex, Flash, Acrobat, Acrobat Connect, Apollo, the Spry framework, and more… why can’t you give us a little more control over JavaScript and/or ActionScript in Captivate? It’s peanuts in comparison to your other projects!