Captivate 3, JavaScript and Actionscript

I just got Captivate 3, and eagerly installed it to see if any improvements have been made regarding JavaScript and Actionscript handling. Short answer: nope.

Javascript

According to Captivate’s ‘Help’:

You can add JavaScript to click boxes, text entry boxes, and buttons in Adobe Captivate projects. The JavaScript can run when a user clicks inside or outside the box or button. Using JavaScript gives you the opportunity to extend projects in numerous ways while adding interactivity.

Same as before.

Actionscript

Absolutely zero changes from what I can tell.

Unfortunately, this means my previous comments regarding using JavaScript and Actionscript in Captivate movies still stand.

I plan to post a brief review of Captivate 3 shortly.

Advertisements

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!

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.’

Navigation options in Captivate

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?

Making Actionscript calls from Adobe Captivate

Diagram of languages spoken by each document

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.

In my case, I usually need the loaded Captivate SWF to tell the Flash container — an e-learning course interface — that a simulation has been successfully completed.

The figure on the right illustrates the problem: Captivate only allows developers to make Javascript calls, even though Captivate SWFs are running Actionscript under-the-hood!

Flash SWFs, on the other hand, traditionally use Actionscript. Granted, there’s a long history of Flash-Javascript tricks, but most of them have been very ‘hacky’ and not very robust.

The HTML container doesn’t recognize Actionscript at all; it only speaks Javascript.

The old solution: embedded SWFs

Diagram of languages spoken by each document (includes embedded SWF)

For a long time, the only reliable workaround had been to import a Flash SWF containing Actionscript into Captivate, and carefully place it on a Captivate slide. It works like this:

  1. Create a blank Flash SWF, then type a small amount of Actionscript into a frame script (such as calling function “doSomething()” on frame 1).
  2. In order for the imported SWF’s Actionscript to properly communicate with the Flash container, it must be prefixed with “_root.”; this corrects a scope issue and forces the Captivate movie to send the Actionscript call to its parent. The full line of Actionscript in the blank Flash SWF looks like this:
    _root.doSomething();
  3. The container SWF must contain the corresponding function. Something like this:
    
    function doSomething() {
       //do something
    }
    
  4. When the Captivate SWF’s play head reaches the frame containing the embedded SWF, any Actionscript contained in that embedded SWF is executed.

Click here to see a functioning sample. You can download a ZIP containing the source files here.

This is a simple solution, but it suffers from scope creep and is difficult to maintain. Who really wants to import a SWF every time they need to make an Actionscript call? I sure don’t. And if you ever want to change your Actionscript code, you need to re-export the SWF from Flash, and update the imported SWF in Captivate. Yuck.

Isn’t there a better way?

What about Javascript?

I got to thinking about it, and wondered (again) “Isn’t there a better way to do this?” Then I remembered two things: That Captivate supports Javascript calls, and that SWFObject — arguably the best way to embed Flash SWFs onto a web page — supports passing Javascript variables to a Flash SWF. What if I could make the Captivate SWF communicate with the Flash container SWF via Javascript and SWFObject?

Sad to say, no dice! SWFObject only passes variables when the Flash container SWF loads. I need to pass variables at various times, not just at ‘onload.’

Even though SWFObject was quickly shot down as a communication method, it got me thinking about Javascript as an alternative. Versions of Flash prior to Flash 8 could handle small snippets of Javascript via GetURL, but the GetURL hack is clumsy at best. I knew I didn’t want to go that route. But hang on a minute… what about Flash 8’s ExternalInterface class? It was designed to make Javascript-to-Actionscript communication a breeze! Having never really used it — it’s only supported in Flash Player 8+ and we’re still stuck supporting Flash Player 7 at the office — I decided to give it a whirl. I quickly created this example using Adobe’s tutorial [link no longer available]. First thoughts: Very intriguing and easy to get up and running, but can this be applied to Captivate SWFs loaded into Flash?

The short answer is… YES!

The new solution: Flash’s ExternalInterface class (Actionscript 2.0)

First I laid out the objectives for my experiment:

  • Make the Captivate SWF call the Actionscript function unload() (located in the Flash SWF) via Javascript
  • No variables would be passed… I wanted to keep things as simple as possible

I began editing the code from the aforementioned Adobe example, and in a few short minutes my proof-of-concept was up and running! I was amazed at how quick and easy it was… ExternalInterface was much easier to use than I anticipated.

Here’s what I did:

Step one: Add two lines of Actionscript code to the Flash container


import flash.external.ExternalInterface;
ExternalInterface.addCallback("unload", this, unloadSWF);

Step two: Add two small Javascript functions to the HTML page


//Detect Flash container movie
function getFlashMovie(movieName) {
   if (navigator.appName.indexOf("Microsoft") != -1) {
      return window[movieName];
   }
   else {
      return document[movieName];
   }
}

//Function to be called by Captivate
function captivateUnload() {
   //Calls "unload" method established in ExternalInterface Actionscript code
   getFlashMovie("simpleSwfLoader").unload();
}

Update: In my subsequent testing, using document.getElementById() works fine in place of the getFlashMovie() function. While some developers warn against using getElementById for grabbing Flash SWFs, my tests — using SWFObject as the embed method — were successful in the following environments: WinXP (FF2, FF3, IE6, IE7, Safari 3) and Mac OS X (Safari 3, FF3, Opera 9.5). You can still use getFlashMovie if you prefer.

Step three: Add the Javascript call captivateUnload() to the Captivate button.

That’s it! Really simple, huh? I must admit I was expecting it to be much more complicated.

How it works

As I mentioned earlier, I’m no expert on the ExternalInterface class, but I’ll try and explain what’s going on here. Let’s work backwards and start with the Javascript call in Captivate. Here are the source files if you’d like to use them.

The Captivate file

Captivate Button OptionsIn my example, I’m using a button to call a Javascript function named captivateUnload(). This Javascript function is located in the HTML file.

The HTML file

Moving to the HTML file, we see two functions. The first function, getFlashMovie(movieName), returns the Flash SWF as a Javascript object. This allows us to add functions to the SWF object. This is critical because Flash’s ExternalInterface class will listen for functions attached to the SWF object.

In my example, the Javascript function captivateUnload() attaches the Javascript function unload() to a SWF named simpleSwfLoader:


function captivateUnload() {
   getFlashMovie(simpleSwfLoader).unload();
}

By itself, this script won’t do much. In fact, it will throw an error in your browser if it doesn’t detect the accompanying ExternalInterface Actionscript code in your Flash SWF.

The Flash file

In the Flash file, the first line of Actionscript simply tells Flash to import the ExternalInterface class.

import flash.external.ExternalInterface;

The second line is where the action’s at (no pun intended… well, maybe a little!).


ExternalInterface.addCallback("unload", this, unloadSWF);

ExternalInterface’s addCallback method basically tells Actionscript to start listening for Javascript functions that have been attached to the SWF object. In our scenario, the unload() function has been attached to the SWF object.

The three parameters ("unload", this, unloadSWF) specify exactly what to listen for (a function named “unload”), where to listen (“this” SWF), and what to do when the SWF hears the correct bit o’ Javascript (execute a function named “unloadSWF”).

So for this example, the Flash SWF will execute function unloadSWF() when it hears Javascript call a function named unload() that is attached to a SWF named simpleSwfLoader.

Got all that? I know it sounds confusing (it still makes my head spin a little), but it’s actually pretty straightforward. Here’s a diagram for you visual learners:

Flow of scripting calls

And that’s the whole enchilada.

Let me remind you that this is a very simple example, and I’m sure this technique can be harnessed to do much more! Also, this example uses ExternalInterface for Actionscript 2.0. Flash CS3’s new Actionscript 3.0 uses slightly different code, but the concept is the same.

If any of you find this tutorial useful, or think of new ways to utilize this technique, please let me know by adding a comment.

Thanks, and good luck!

Embedded SWF technique source files  |  ExternalInterface technique source files