The State of Adobe Captivate’s SCORM Support

Hopefully my series on Adobe Captivate’s SCORM publishing templates has shed light on the sorry state of Captivate’s publishing templates; I know it’s easy to play critic, complaining and pointing out deficiencies, but in this case I feel it was constructive and appropriate. However, I would also like to provide some counterbalance and perspective regarding the status of Adobe Captivate and its development team.

First of all, I have met a number of the Adobe Captivate product team in person. To a man, they are all very nice people who are engaged in their work and very interested in making improvements. They are not disinterested slackers. They have reached out to the community to try and find new ways of using Captivate, and have shipped some of the suggestions they received, such as the ability to send data to a custom database, and the SCORM Aggregator.

In case you haven’t heard, Adobe has been going through many changes, and has laid off over two thousand employees in a 4-year span (600 in Dec. 2008, 680 in Dec. 2009, 750 in Nov. 2011). Today’s Adobe is not the same company some of us older folks grew to love in the early 90s; these days, Adobe’s management appears to be much more focused on profit than outstanding products. Adobe has adopted a very aggressive paid-update cycle; the Creative Suite alone has had six updates in 8 years. Captivate has had 5 paid updates in about 6 years. That’s a lot of money to re-purchase something you thought you already bought, and the new version doesn’t even guarantee bug fixes.

I have previously speculated that the Adobe Captivate team hasn’t fixed some of the product’s deficiencies because Adobe can’t sell bug fixes — Adobe focuses instead on shiny new features that are good marketing opportunities. I still stand by that sentiment. If you look around the blogosphere, it’s a common complaint across product lines — Fireworks, Photoshop, Flash, Illustrator, you name it. It’s a disease borne by management and marketing. Bug fixes aren’t sexy, new whiz-bang features are! Why waste your time on bug fixes? The new features will make the product so much easier to sell.

I have not heard a single comment from the Captivate team (or any other Adobe employee) regarding this theory, but one has to wonder if the Captivate team were forced to make concessions to this new management approach — tight deadlines and marketable new features — rather than customer satisfaction. In this environment, I can see how a SCORM publishing template — something that is creaky and old but still works most of the time — becomes a low priority.

I’ve heard rumors that the upcoming Captivate 6 will contain a completely revamped SCORM system that eliminates many of the issues I’ve covered. If this is the case, many of us will surely be elated, perhaps enough to pay for yet another upgrade. This could also help explain why Adobe hasn’t addressed the current SCORM publishing template; a complete overhaul of the existing SCORM system — including the ActionScript code inside the published SWFs — is a considerable amount of work.

I tried my hand at fixing the ActionScript code in the older CP4 projects a couple of years ago. I examined the ActionScript files that shipped with Captivate 4 and also decompiled some published Captivate SWFs (ActionScript 2) to see how they work. My biggest surprise — which makes perfect sense in hindsight — is that there’s a central tracking mechanism within Adobe Captivate that keeps track of location, score, quiz questions, etc. This tracking system has an adapter that can be used to plug in support for other tracking methods, such as SCORM , AICC, Adobe Connect, etc. In general, only the basic tracking details — the common denominators between systems, such as bookmarking and scoring — were used, all else was discarded. Hence the shallow SCORM support, missing features like cmi.interactions.

As such, any major internal changes to SCORM support would require changes to the central tracking system, and runs a high risk of breaking all other tracking (AICC, Adobe Connect, etc.). It makes sense that the Captivate team would take their time, consult with SCORM experts, and proceed with caution. Hopefully by this time next year, no one will need the cleaned up templates I just created, and Captivate 6 will provide some of the most solid SCORM support in the industry. Hopefully!

In closing, I want to reiterate that I stand by my previous criticisms, but also wanted to provide a bit of background and nuance; the world is rarely black and white, and this situation is no different. I root for the Captivate development team, and hope Adobe’s upper management gets their heads out of their wallets and lets their product teams — people who truly care about the products and end users — do what needs to be done rather than what contributes most to the bottom line.

Advertisements

Cleaning up Adobe Captivate’s SCORM Publishing Template, Part 6: Bugs & Scope Creep

For this blog post, I was going to write a summary of the changes to the template and wrap up the series. Instead, I’m looking at ways to increase the template’s flexibility and hot-rod it for some cool other stuff.

First, in case you missed it, here are the first five parts of the series:

  1. Part 1: Introduction
  2. Part 2: HTML
  3. Part 3: JavaScript
  4. Part 4: SCORM
  5. Part 5: Finishing up

This series has been an exercise in refactoring; I walked through the code and continued to refine it until I reached a point where the template performed as I felt it should have; a bare minimum of functionality was met, with a sprinkle of extra goodness.

The problem is, when it comes to refactoring code, you’re never really done! Flaws are found, ideas pop into your head when you’re trying to go to sleep, and suggestions come along, all prompting another look at your work. Bug fixes and new features (aka scope creep) rule the roost. This project is no exception.

Regarding bug fixes, as part of the cleanup process, I added a feature that displays an error message to the learner when the SCORM API isn’t found; this works great when launching the course from an LMS, but as Infosemantics’ Rod Ward pointed out, it prevents the developer from previewing the course locally. Oops. I also noticed that the code I added for centering the SWF makes the ‘no SCORM’ message look strangely off-center, in the rare cases where you’d see it. No worries, it will be fixed.

Regarding new features, there are many ways we can improve the template, or at least make it more flexible. For example:

  • We can add a debug mode that logs SCORM commands to the console; the debug mode could be toggled on or off via the CONFIG object in the HTML file.
  • Some Captivate developers like to use JavaScript with their course; the addition of the SWFObject callback function makes it trickier for developers to know where to place their extra code. We can help by providing a clearly defined space for these developers.
  • We can provide a compressed version of the template’s scorm_support.js file, which reduces file size.
  • We haven’t touched the imsmanifest.xml file, but there are probably some improvements we can make there, as well.

I’m sure there are other possibilities I’m leaving out. Improvement is an ongoing process, and I would love to hear any ideas you might have about improving Captivate’s SCORM 2004 publishing template. Post a comment below, or message me on Twitter.

(Note: I’m not a fuddy-duddy, but I will ignore and sometimes delete off-topic comments; I tend to get a lot of these, and they’re a drag to deal with. If you have general e-learning questions, please post them on the E-Learning Technology and Development Google Group, which I moderate.)

Reminder: all of this work is centered on Captivate 5.5, not older versions. Captivate versions 4 and 5 require a little bit of help from the inside (ActionScript delivered via a second SWF). I might cover that ground in a future post if I have time.

Update: I was mistaken about Captivate 5 — this revised template should work fine with both 5.0 and 5.5.

Continue to Part 7 of the series.

Cleaning up Adobe Captivate’s SCORM Publishing Template, Part 5: Finishing up

In part one of this series, we published a simple Captivate course and examined its file structure. In part two, we cleaned up the HTML file and externalized all JavaScript. In part three, we cleaned up the JavaScript. In part four, we updated the SCORM code. In this installment, we will put the finishing touches on our code and move our files into Captivate’s publishing folder.

In the first four parts of this series, we were working with actual course files; these files need to be converted into template files. Once they’re set up as templates, you can just pop them into your Captivate templates folder and never worry about it again.

Let’s take a quick look at Captivate’s template folder structure:

I’m on a Mac, but the folder structure is the same on a Windows machine.

Our files were gathered from several locations:

  • The Manifest2004 folder contains all of the SCORM 2004 XSD files. We don’t need to edit any of these files.
  • The manifest2004.xml file is the SCORM 2004 imsmanifest.xml template. We don’t need to edit this file, though there are improvements that can be made.
  • The SCORM folder contains a 2004 subfolder, which in turn contains most of the HTML and JavaScript files we’ll need to edit.
  • The standard.js file contains the SWFObject 1.5 library.

Cleanup task #1: Refactor the code to eliminate the captivate.js file

In part two of this series we externalized JavaScript by creating a new file named captivate.js. This was useful while we refactored code, because it helped separate JavaScript from HTML and gave us a clearer picture of what we needed to work on. However, now that we’re trying to insert our edits into a Captivate publishing template, were stuck with the limitations of Captivate’s template and cannot add new files to the template — we can only edit existing files. We will therefore need to make a choice: where shall we place the contents of our new captivate.js file? In the HTML file, in scorm_support.js, or in standard.js?

There’s an easy answer: the HTML file.

Yes, this goes counter to my previous argument about externalizing the JavaScript, but we’re given little choice. The standard.js file is shared with 12 other templates; if you plan to use any of the other templates that ship with Captivate, we’ll need to leave this file alone (yes, that means leaving the SWFObject 1.5 library in your course even though we won’t be using it! Thankfully it has a very small footprint.).

scorm_support.js is a decent place to put our scripts, but it has one huge drawback: Captivate will not write anything to this file when publishing… and therein lies the problem!

When publishing a Captivate project using the SCORM 2004 template, the filename and dimensions are written to the HTML file (SCORM\2004\Default.htm). In fact, Default.htm is also renamed to match your project’s name. scorm_support.js and standard.js are never touched by Captivate; they are static files. In order for our modified template to work, we have to enable Captivate to write project details (project dimensions, filename, colors, etc.) to the HTML file.

The good news is that we significantly cleaned up the JavaScript, so captivate.js only contains a tiny amount of code.

Here are the modified HTML and scorm_support.js files after we get rid of captivate.js. There is much work to be done.

View the result of task #1

Cleanup task #2: Create a configuration object

Web apps normally use configuration objects — objects that contain data about how the app works. Since we know Captivate will write project details in the HTML, it makes sense to create a ‘config’ object.

Technically we could just use global variables, but an object dedicated to configuration information is a very clean way of working.

var CONFIG = {

};

So… what shall we put into this CONFIG object? Let’s start by looking in Default.htm to see what Captivate makes available to us. Anything prefixed with @ is a variable that gets written to the page by Captivate during the publishing process. A quick scan through the page reveals the following:

  • @MOVIETITLE (used in the HTML title element)
  • @MOVIENAME (the SWF filepath)
  • @IsRightClickFunctionalityRequired (an attribute placed in the HTML body element)
  • @SKINCOLOR (an attribute placed in the HTML body element)
  • @FlashPlayerVersion
  • @MOVIEWIDTH
  • @MOVIEHEIGHT
  • @WMODEVALUE (specifies what wmode should be used by Flash Player)

The whole IsRightClickFunctionalityRequired thing is problematic, we’ll get back to that later.

Here’s what we can put into our CONFIG object. I’m renaming a few of them for clarity and/or simplicity:

var CONFIG = {
    MOVIETITLE: "@MOVIETITLE",
    FILEPATH: "@MOVIENAME",
    BGCOLOR: "@SKINCOLOR",
    FPVERSION: "@FlashPlayerVersion",
    WIDTH: "@MOVIEWIDTH",
    HEIGHT: "@MOVIEHEIGHT",
    WMODE: "@WMODEVALUE"
};

We should also specify the name of the element that SWFObject will use to embed the SWF. Captivate normally names this file “CaptivateContent”, but it would be good to list it in the CONFIG object in case we ever need to edit it. (Spoiler: we will be editing it later.)

If you recall, we also have an if/else clause that displays a message to the learner if the SCORM API fails to load. We should place that message in our CONFIG object as well. This way you can quickly and easily reconfigure the message to suit your needs without digging through all of the template files.

var CONFIG = {
    TITLE: "@MOVIETITLE",
    FILEPATH: "@MOVIENAME",
    BGCOLOR: "@SKINCOLOR",
    FPVERSION: "@FlashPlayerVersion",
    WIDTH: "@MOVIEWIDTH",
    HEIGHT: "@MOVIEHEIGHT",
    WMODE: "@WMODEVALUE",
    TARGET: "CaptivateContent",
    NOSCORM: "Sorry, but the course is not available at this time (SCORM API not found). Please try again. If you continue to encounter problems, please contact the course administrator."
};

Cleanup task #3: Refactor the code using the CONFIG object

Now that our CONFIG object is ready to go, we need to replace all of the hard-coded values from our sample course with these configuration items. (Make a backup copy first!)

While we’re at it, we’ll place @MOVIETITLE into the title element, and @SKINCOLOR into our style element. Because of a quirk of the Captivate system, @SKINCOLOR can’t be followed by a semicolon in the CSS.

This will fail (semicolon after SKINCOLOR):

body { background: @SKINCOLOR; text-align: center; }

This will work (no semicolon):

body { text-align: center; background: @SKINCOLOR }

This configuration object enables us to move all other JavaScript out of the HTML and into scorm_support.js; the only JavaScript remaining on the HTML page are user-defined configuration items. Way cool. We have to be careful to reorder the script elements, so that the CONFIG object is created before scorm_support .js loads.

View the result of task #3

Cleanup task #4: Tidy up the HTML file a bit more

There are a few items that need attention in the HTML.

1. Quirks mode. Adobe placed two HTML comments above the doctype, which will trigger Internet Explorer to display the page in quirks mode. Since our page layout is so simple, quirks mode shouldn’t affect us, but it’s still a good practice to avoid placing comments above the doctype.

Current code:

<!-- Copyright [2008] Adobe Systems Incorporated.  All rights reserved -->
<!-- saved from url=(0013)about:internet -->

Before we move the comments, let’s stop and ask: are these comments even necessary? Are they useful? Well, the first comment is an Adobe copyright notice, which is questionable at best. What, exactly, is being copyrighted? The content of the page? Does that include your Captivate handiwork? Is the HTML being copyrighted? I’m not a lawyer, but I’m pretty sure you can’t copyright HTML markup. There is no clarity. Since I’ve competely obliterated what was provided by Adobe, anyway, I’m going to remove the copyright notice. Feel free to put it back if it makes you nervous, just place it *under* the doctype.

The second comment is what’s affectionately called “the mark of the web” (MOTW). Another reason to thank Microsoft. The short explanation is that MOTW enables you to view your Captivate file locally in Internet Explorer by forcing Internet Explorer to treat the page as if it were loading from the internet instead of your hard drive. If you intend to do any local testing with Internet Explorer, you should keep the MOTW in your template. I’m going to cut and paste the version recommended by Microsoft:


<!-- saved from url=(0014)about:internet -->

2. Remove page margins and padding. By default, all HTML pages have padding around the edges of the document, as well as a slight margin. Let’s remove all padding and margins to ensure the SWF comes up to the edge of the browser window. This will remove unsightly gaps when launching the course in the LMS’s popup window.

* { margin: 0; padding: 0; }

You may be asking: “What happens if the window is bigger than the SWF?” Currently, the SWF will be aligned to the top left corner. Centering the SWF is tricky, we’ll come back to that later.

3. Place the noscript block inside CaptivateContent. This isn’t necessary, but it’s a clean way of working. SWFObject will replace fallback content — content that only displays if something isn’t supported, such as JavaScript or Flash Player — with the SWF upon successful embed, leaving just the bare minimum markup in the HTML.

HTML before embed:


<div id="CaptivateContent"><noscript>
      This course requires JavaScript to be enabled in your browser. Please enable JavaScript, then relaunch the course.
      </noscript></div>

HTML after embed:

<div id="CaptivateContent"></div>

View the result of task #4

Cleanup task #5: Fix the right-click issue

As I mentioned earlier, Captivate has a variable named @IsRightClickFunctionalityRequired. This variable is located in the opening body tag.

Here’s how it looks in the HTML template:

If the Captivate SWF requires right-click functionality at any point, @IsRightClickFunctionalityRequired will add an onload event to the body element:

This is problematic for many reasons. First of all, adding an onload event directly to the body is considered a bad practice; inline JavaScript should be avoided whenever possible. It’s also a bad idea because the onload event is likely to overrule any window.onload events we might have in the external JavaScript.

After digging further into the IsRightClickFunctionalityRequired system, I have two additional concerns:

  1. Using this right-click functionality requires disabling accessibility in the Captivate preferences.
  2. The codebase for this functionality comes from a project named RightClick for Flash Player. It was developed before SWFObject 2.x existed, and therefore requires SWFObject 1.5 unless we make some modifications to our code.

Regarding the first concern, unfortunately, there’s nothing we can do about this in the template. It’s a choice you’ll need to make when authoring your Capivate projects. If you don’t like disabling Captivate’s accessibility features, please let Adobe know.

To understand the second concern, I must quickly explain a key difference bewteen SWFObject 1.x and SWFObject 2.x:

In SWFObject 1.5 — the version being used by Captivate — the SWF gets embedded inside the element you specify. For Captivate projects, the HTML winds up looking like this:

SWFObject JavaScript:

var so = new SWFObject("mymovie.swf", "Captivate", "550", "400", "10", "#CCCCCC");
//options here
so.write("CaptivateContent");

HTML before embed:

HTML after embed:

<div id="CaptivateContent"></div>

SWFObject 2.x changes this behavior. It replaces the target element, taking the ID of the element it replaces, unless a new ID is specified in the attributes object.

SWFObject JavaScript:

//SWFObject optional variables
var flashvars = {};
var params = {};
var attributes = { id: "Captivate" };
var callback = function (){ };

swfobject.embedSWF("mymovie.swf", 
                   "CaptivateContent", 
                   "550", 
                   "400", 
                   "10", 
                   false, 
                   flashvars, 
                   params, 
                   attributes, 
                   callback);

HTML before embed:

After embed:

To summarize: SWFObject 1.5 embeds the SWF inside your element, leaving the original element as a wrapper around your SWF, while SWFObject 2.x replaces the original element, leaving no wrapper.

The RightClick for Flash Player codebase requires the SWF to be located inside a wrapper element.

Normally, I’d edit the RightClick for Flash Player codebase to work with SWFObject 2. Unfortunately for me, it’s located in standard.js, which is used by all 13 Captivate publishing templates; if I update the code there, I’d need to replace ALL Captivate publishing templates. Not interested!

The solution is to write a function that creates a new wrapper div in our template before SWFObject is invoked. Of course, we only want to create this extra wrapper if right-click functionality is required.

Add a “rightClickRequired” property to our CONFIG object and populate it with the output of Captivate’s @IsRightClickFunctionalityRequired:

CONFIG.RIGHTCLICKENABLED = '@IsRightClickFunctionalityRequired';

When right-click functionality is required, Captivate will populate CONFIG.RIGHTCLICKENABLED for us:

//Note the use of single quotes
CONFIG.RIGHTCLICKENABLED = 'onload="RightClick.init();"  ';

When right-click functionality is not required, CONFIG.RIGHTCLICKENABLED will contain an empty string.

All we need to do is check to see if CONFIG.RIGHTCLICKENABLED is an empty string; if yes, create a wrapper div, embed the SWF, then initialize the right-click codebase. If no, just embed the SWF as usual.

View the result of task #5

Cleanup task #6: Center the SWF

Oh boy, this one is rough. Centering an element should be achievable through CSS alone, but unfortunately, we have some crazy restrictions and exceptions to deal with.

If you know the dimensions of the element, it’s easy to center it. We know the dimensions of our SWF — it’s provided via @MOVIEWIDTH and @MOVIEHEIGHT — so we’re on easy street, right? Wrong.

As I mentioned earlier when discussing the CSS code for the body background color, Captivate will not write a variable to the page if the variable name is adjoining any other text.

Consider the following CSS:

#Captivate { width: @MOVIEWIDTHpx; height: @MOVIEHEIGHTpx; }

It fails because “px” can’t be adjoining the @MOVIEWIDTH variable. Unfortunately CSS doesn’t allow us to place a space between the number value and the unit type. Assume @MOVIEWIDTH outputs 550 and @MOVIEHEIGHT outputs 400; if a space is provided between the value and the unit, the code is invalid and will fail:

#Captivate { width: 550 px; height: 400 px; }

Captivate is forcing us to use JavaScript to write the CSS values. Uuuuuugly, but there’s no getting around it.

Normally, if you’d like to center an element horizontally, you can just define the width (which we’ll have to do with JS), then set margin as follows:

#Captivate { display: block; margin: 0 auto; }

But to center an element vertically, we have more hoops to jump through, and it prevents us from being able to use the margin: 0 auto approach for horizontal centering. While there are some nice simple technquies out there for new browsers, they fail in older browsers. Most older sites use tables for layout because tables provides an easy and quick way to vertically center an element. But if you’ve read this entire series of posts, you can guess we’re not going to use tables — tables shouldn’t be used for layout! Period.

The most reliable CSS method is to use absolute positioning. This requires knowing the dimensions of the element, so we’ll be using a combination of CSS and JavaScript.

Added to the SWFObject callback function:

//Fix the centering for the SWF
CaptivateSWF.style.marginTop = "-" +(CONFIG.HEIGHT / 2) +"px";
CaptivateSWF.style.marginLeft = "-" +(CONFIG.WIDTH / 2) +"px";

Added to the HTML page’s CSS:

/* JavaScript is used to set pixel values for margin-left and margin-top */
#Captivate { position: absolute; top: 50%; left: 50%; }

We also set the height of body to 100%. Height is inherited from a parent element, so setting 50% height on an element won’t work in some browsers until you specify the parent element’s height.

View the result of task #6

Cleanup task #7: Final massaging!

We’ve done just about everything we can. The last step is to see if we can clean up our code to make it more tidy (and readable), then run it through some syntax checkers to look for bugs. I suggest JSHint.com, a fork of JSLint that doesn’t aim to hurt your feelings.

One change I’ll make is refactoring my CONFIG object to make it easier to read. While I prefer the original syntax (it compresses better, too), many n00bs prefer the more verbose style because they find it less confusing.

var CONFIG = {},
    flashvars = {},
    params = {},
    attributes = {};

CONFIG.TITLE = "@MOVIETITLE";
CONFIG.FILEPATH = "@MOVIENAME";
CONFIG.BGCOLOR = "@SKINCOLOR";
CONFIG.FPVERSION = "@FlashPlayerVersion";
CONFIG.WIDTH = "@MOVIEWIDTH";
CONFIG.HEIGHT = "@MOVIEHEIGHT";
CONFIG.WMODE = "@WMODEVALUE";
CONFIG.RIGHTCLICKENABLED = '@IsRightClickFunctionalityRequired';
CONFIG.TARGET = "Captivate";
CONFIG.NOSCORM = "Sorry, but the course is not available at this time (SCORM API not found). Please try again. If you continue to encounter problems, please contact the course administrator.";

//For SWFObject
params.bgcolor = CONFIG.BGCOLOR;
params.menu = "false";
attributes.name = CONFIG.TARGET;

While I’m cleaning, I’ll reduce the number of vars I introduced into scorm_support.js when adding new functions. This is also where we can do nitpicky stuff like replacing tabs with spaces and ensuring we have semicolons in the right places. Be sure to remove any alerts or console.log calls you may have added for debugging.

I think I’ll make one other change — add SWFObject 2.2 to standard.js. Yes, this means standard.js will contain both SWFObject 1.5 and 2.2, which is a bit odd. However it seems like a safe choice, since some institutions might not like loading SWFObject from a 3rd party CDN such as Google.

I’m also going to compress RightClick in standard.js to reduce file size. Be sure to make a backup copy if you’re following along.

View the result of task #7

Cleanup task #8: Move the files into the Captivate publishing folder

It’s been a long road, but we’re finally ready to make the jump! Let’s replace the existing template files.

You can grab the new code here.

First, make a backup of your entire publishing folder and put it somewhere safe!

Next, rename your HTML file to Default.htm and drag it into Templates\Publish\SCORM\2004\ (Original file was 11.8KB, new file is 1.7KB)

Now copy your scorm_support.js file to Templates\Publish\SCORM\2004\SCORM_support\ replacing the original file. (Original file was 6.7KB, new file is 7.4KB)

While you’re in your SCORM_support folder, go ahead and delete scorm_support.htm (590B) and scorm_support.swf (149B) — they won’t be used anymore.

Update: If you choose to delete these two files, you must edit Manifest2004.xml to reflect the change. Just remove the two lines that mention scorm_support.htm and scorm_support.swf (found at about line 108 in Manifest2004.xml).

Finally, go to Templates\Publish\ and replace standard.js with our updated copy. (Original file was 10KB, new file is 19KB)

Sweet: Even after adding SWFObject 2.2 to standard.js, we were able to shave about 1KB from the total file size! (29.25KB to 28.1KB)

Now restart Captivate and give it a try!

The next installment of the series will provide a quick summary as well as some additional options and considerations. Go to Part 6.

Cleaning up Adobe Captivate’s SCORM Publishing Template, Part 4: SCORM

In part one of this series, we published a simple Captivate course and examined its file structure. In part two, we cleaned up the HTML file and externalized all JavaScript. In part three, we cleaned up the JavaScript. In this installment, we will examine and update the SCORM code.

Captivate and SCORM. Not the greatest buddy movie you’ve seen, and certainly not as awesome as peanut butter and chocolate.

Captivate’s SCORM code — both the JavaScript you’ve seen in the publishing templates and the ActionScript you can’t see inside the SWF — were written eons ago, when Internet Explorer 6 was the latest and greatest browser, and Firefox was still a twinkle in Mozilla’s eye.

Communication between a Flash SWF and JavaScript was an evolving issue; ExternalInterface hadn’t been created yet, so developers had to choose between the synchronous FS Command, which only worked in Internet Explorer for Windows (no Netscape or IE for Mac), or the asynchronous getURL hack, which worked across browsers but required clumsy timeouts and polling. It also caused a slew of clicking sounds every time it was used.

In 2005, Mike Chambers and his cohorts at Macromedia created the ExternalInterface API for ActionScript, which provided Flash developers direct synchronous access to JavaScript, and vice-versa. Since ExternalInterface works cross-browser and cross-platform, it was (and still is) a godsend for e-learning developers.

ExternalInterface shipped with Flash Player 8 in 2005.

RoboDemo — Captivate’s product name before it was rechristened in 2004 — supported SCORM 1.2. From what I’ve read, most of the SCORM integration was performed by Andrew Chemey. Since ExternalInterface hadn’t been released yet, Andrew implemented both the FSCommand and getURL approaches, enabling RoboDemo’s SCORM-based courses to work in all browsers. It was a fine bit of work for its day.

Taking a look at the Captivate product release timeline, the first edition of Captivate was released in 2004. This is when SCORM 2004 support was introduced to Captivate, as an add-on to the existing SCORM 1.2 support.

The SCORM support code has barely been touched since then. Here’s a simplified look at Captivate’s lifespan with regards to SCORM:

  • 2005: Adobe acquires Macromedia.
  • 2006: Adobe Captivate 2 released, with no changes to the SCORM support code.
  • 2007: Adobe Captivate 3 released, boasting “Improved learning management system (LMS) integration” but with no substantial changes to the SCORM publishing template.
  • 2008: radio silence.
  • 2009: Adobe Captivate 4 released, introducing the option to publish to ActionScript 3. ExternalInterface is introduced under-the-hood, but is not used universally. The SCORM code still uses the old FSCommand and getURL techniques, depending on browser (hence all the blog and forum posts about the g_intAPIType hack).
  • 2010: Adobe Captivate 5 released. Touted as being “built from scratch,” the SCORM publishing templates still contain original SCORM support code from Macromedia Captivate, and still uses LocalConnection/getURL to communicate in Mozilla-based browsers, most notably Mozilla Firefox.
  • 2011: Adobe Captivate 5.5 released, with one big change: ExternalInterface has become the exclusive communication method for SCORM. FSCommand and getURL are never used… but the templates aren’t updated to reflect this change!

Captivate 5.5 finally allows us to breathe a little sigh of relief; as of 2011 — a full six years after ExternalInterface was released — Adobe finally made ExternalInterface the sole technique for Captivate’s SCORM communication. This greatly simplifies the codebase and browser support.

But hang on — why does the SCORM 2004 publishing template still contain all that legacy code? What a drag, Adobe shipped outdated legacy code in a paid update. Again.

Snarkiness aside, it’s interesting to note that Adobe hasn’t really publicized the transition from the old communication techniques to ExternalInterface. I challenge you to find any official documentation on the topic! However, if you look very closely at the unedited publishing template, you’ll see one clear indication of the ExternalInterface update in Captivate 5.5:


var g_intAPIType = 0;
// Hook for Internet Explorer
if ((navigator.appName && navigator.appName.indexOf("Microsoft") != -1 && navigator.userAgent.indexOf("Windows") != -1 && navigator.userAgent.indexOf("Windows 3.1") == -1) || g_intAPIType == -1)
{
    g_intAPIType = 0;

    // ... other stuff ...

} else {
    g_intAPIType = 0;
}

Regardless of the outcome of the browser detection in the ‘if’ clause, g_intAPIType will be set to 0. This is a change; in prior versions of Captivate, the ‘else’ clause would set g_intAPIType to 1, forcing non-Internet Explorer browsers to use the getURL approach.

This code excerpt is also a great example of poor quality control on Adobe’s part; the variable g_intAPIType is declared and given a value of 0 just before the if() block. So why does the conditional code include a check for g_intAPIType == -1? Any why even include g_intAPIType in the if/else statement anyway, if you know you aren’t going to change the value?

Regardless, we’ve clearly established the template needs cleaning, so let’s roll up our sleeves and get to work!

Cleanup task #1: Remove non-External Interface code

Since we know that “setting g_intAPIType to 1 means you’re forcing Captivate to use getURL in all browsers”, and getURL is no longer an option in Captivate 5.5, we can remove any code that uses g_intAPIType with a value of anything other than 0.

We also know that Captivate will never use any of the FSCommand code, so we can remove that, too.

This leaves us with a strange little chunk of code… remember the VBScript I mentioned in a previous post?


var g_intAPIType = 0;
// Hook for Internet Explorer

if ((navigator.appName && navigator.appName.indexOf("Microsoft") != -1 && navigator.userAgent.indexOf("Windows") != -1 && navigator.userAgent.indexOf("Windows 3.1") == -1) || g_intAPIType == -1)
{
    g_intAPIType = 0;
    document.write('<script language=\"VBScript\"\>\n');
    document.write('On Error Resume Next\n');
    document.write('Sub Captivate_FSCommand(ByVal command, ByVal args)\n');
    document.write('Call Captivate_DoFSCommand(command, args)\n');
    document.write('End Sub\n');
    document.write('</ script\>\n');
    document.write('<script language=\"VBScript\"\>\n');
    document.write('On Error Resume Next\n');
    document.write('Sub Captivate_DoExternalInterface(ByVal command, ByVal parameter, ByVal value, ByVal variable)\n');
    document.write('Call Captivate_DoExternalInterface(command, parameter, value, variable)\n');
    document.write('End Sub\n');
    document.write('</ script\>\n');
} else {
    g_intAPIType = 0;
}

ExternalInterface doesn’t require VBScript.

Question: What’s it doing here?
Answer: Absolutely nothing!
[Gong!] Delete!

Believe it or not, we have just removed the last bit of browser sniffing from our JavaScript code. Our remaining code is browser-agnostic and no longer contains special handling for Internet Explorer. Yay!

The Captivate_DoFSCommand and Captivate_DoExternalInterface functions are still being used but it appears the Captivate_DoFSCommand function is not really functional, so we can delete it.

(I removed Captivate_DoFSCommand to see if it caused any problems; the course worked in both Internet Explorer and Chrome without issues, so appears safe to chuck it.)

If ExternalInterface is truly the exclusive communication technique, we can also remove the dataToFlash and dataFromFlash functions, since these were only used by the old getURL communication technique.

We can also remove the “NS_dynamic” layer element from the HTML file.

The remaining SCORM code is looking much, much leaner and meaner! We still have lots of optimizations we can make, though.

Cleanup task #2: Optimize Captivate_DoExternalInterface and cache the reference to the Captivate SWF

The Captivate_DoExternalInterface function still has a number of issues. The first is useless variable reassignment. In the following example, strFSCmd, strFSArg1, strFSArg2, and strFSArg3 are all useless reassignments.


function Captivate_DoExternalInterface(command, parameter, value, variable){

    var CaptivateObj = document.getElementById("Captivate"),
        strFSCmd = new String(command),
        strErr = "true",
        strFSArg1 = parameter,
        strFSArg2 = value,
        strFSArg3 = variable,
        courseStatus;

This reassignment has no benefit and makes the code less readable, so we’ll clear it out, using use command, parameter, value, and variable directly.

Also, every time Captivate_DoExternalInterface is invoked, it performs a lookup to find the Captivate SWF in the page’s DOM:


var CaptivateObj = document.getElementById("Captivate")

This is wasteful and a surefire way to worsen your course’s performance. It’s best to create a global reference to the Captivate SWF and re-use it, rather than looking up the SWF every time. We can do this quickly and easily with a slight modification to the callback function we created for our SWFObject embed script.


var CaptivateSWF;

function callbackFn(e){
    //e.ref is the <object> aka SWF file. No need for getElementById
    if(e.success && e.ref){
        CaptivateSWF = e.ref;
        CaptivateSWF.tabIndex = -1; //Set tabIndex to enable focus on non-form elements
        CaptivateSWF.focus();
    }
}

Last but not least, there are a couple of places where we can simplify the syntax, and as a best practice, we should be using a strict comparison operator === instead of the loose comparison operator ==.

View the result of task #2

Cleanup task #3: Get rid of the timer

There’s a timing issue with our template: the template’s JavaScript code is trying ensure the SCORM API is found before embedding the SWF, but it’s doing so with a timer, which is clumsy and can slow down load time. It’s better to let the getAPI function run its course first, then do a simple conditional check to see if the SCORM API has been found. If yes, embed the SWF. If no, show a message informing the learner to try again or contact the course administrator.

While we’re at it, we can clean up the SWF’s URL. In the original template, the variable strURLParams is used to add two querystring parameters to the SWF’s URL; these parameters indicate the version of SCORM being used, and the communication technique being used.


if(g_objAPI != null)
{
    strURLParams = "?SCORM_API=" + g_zAPIVersion + "&SCORM_TYPE=" + g_intAPIType;
}

var so = new SWFObject(strURLFile + strURLParams, "Captivate", "641", "512", "10", "#CCCCCC");

Since we know we’re using SCORM 2004 with ExternalInterface, we can hardcode the value of strURLParams to the SWF’s URL. This enables us to delete that last remaining references to strURLParams and g_zAPIVersion.


swfobject.embedSWF(strURLFile + "?SCORM_API=1.0&SCORM_TYPE=0" ...

View the result of task #3

Cleanup task #4: Clean up the ‘find’ code for the SCORM API

Even though this is a SCORM 2004 template, there’s still a bit of waffling in the code — the code includes sniffing for the SCORM 1.2 API. We should remove it.

Frankly, I’ve never been a fan of Captivate’s findAPI approach, so I’m going to replace it with the findAPI approach used in my pipwerks SCORM wrapper. It follows the approach of ADL and Rustici Software (scorm.com), is thoroughly tested, and IMO is much easier to troubleshoot.

View the result of task #4

Cleanup task #5: Improve the exit/finish handling

Proper use of an unload handler is very important for SCORM courses. It ensures the course exits properly and saves the learner’s data.

Captivate’s publishing template includes some unload handling, but we can improve it. For example, we can ensure cmi.exit is set to a reasonable default, and we can add an onbeforeunload handler, which is helpful in Internet Explorer. These steps will help ensure the course can be resumed if the learner leaves before completing it.


var unloadHandler = function (){
    if(!unloaded && isInitialized && !isTerminated){
        var exit_status = (courseStatus === "incomplete") ? "suspend" : "normal";
        SCORM_API.SetValue("cmi.exit", exit_status); //Set exit to whatever is needed
        SCORM_API.Commit(""); //Ensure that LMS saves all data
        isTerminated = (SCORM_API.Terminate("") === "true"); //close the SCORM API connection properly
        unloaded = true; //Ensure we don't invoke unloadHandler more than once.
    }
};

window.onbeforeunload = unloadHandler;
window.onunload = unloadHandler;

View the result of task #5

Cleanup task #6: Initialize SCORM connection earlier

There are a number of tweaks we can make to improve Captivate’s SCORM handling. For example, Captivate finds the SCORM API before embedding the SWF, but then sits on its thumbs; it doesn’t initialize the connection until well after the SWF loads.

Personally, I think it’s better to have JavaScript get SCORM’s motor running before the SWF has finished loading, as it will reduce course startup time. The problem is, if we initialize the SCORM connection ourselves, the Initialize() command sent by the SWF will cause an error — SCORM doesn’t allow initializing twice! The solution is to neuter the Initialize() handling in Captivate_DoExternalInterface.


...
if(command === "Initialize"){

    //We already initialized, just nod politely
    //and tell the SWF everything is okay!

} else if(command === "SetValue"){
...

Cleanup task #7: Prevent redundant SetValue calls

Captivate is horrible about sending the same calls to the server over and over again. For example, Captivate sets cmi.score.max and cmi.score.min on every slide! In well-designed courseware, these are typically values that get set once at the beginning of a course and are untouched thereafter. Let’s ensure Captivate only sends the value once; if it tries to send the same value a second time, let’s intervene and prevent it from being sent to the LMS.

We can also prevent Captivate from sending other values that haven’t changed since the last time they were sent. For example, if the completion_status is already “incomplete”, we can prevent the course from sending the “incomplete” value again (which Captivate does over and over and over). This helps shield the LMS from a deluge of useless calls, lightening its load and hopefully improving its performance.

I’ve added a cmiCache function that stores values sent to the LMS; if the Captivate SWF tries to send a value that has already been sent, cmiCache will prevent it from going to the LMS.


var value_store = [];

var cmiCache = function(property, value){

    //Ensure we have a valid property to work with
    if(typeof property === "undefined"){ return false; }

    //Replace all periods in CMI property names so we don't run into JS errors
    property = property.replace(/\./g,'_');

    //If cached value exists, return it
    if(typeof value_store[property] !== "undefined"){
        return value_store[property];
    }

    //Otherwise add to cache
    if(typeof value !== "undefined"){
        value_store[property] = value;
    }

    return false;

};

Which is used like this:


//Check to see if value is already cached
var cached_value = cmiCache(parameter, value);

//Only send value to LMS if it hasn't already been sent;
//If value is cached and matches what is about to be sent
//to the LMS, prevent value from being sent a second time.
if(!cached_value || cached_value !== value){
   //Not cached. Sending to LMS.
} else {
   //param and value has already been sent. 
   //Preventing redundant LMS communication.
}

View the result of task #7

I tested this code with a simple quiz-style course; the course contains 8 questions. I logged every call to Captivate_DoExternalInterface. SetValue was invoked by the SWF 261 times; the new cmiCache feature successfully prevented 70 redundant SetValue calls (a 26% reduction), reducing the total LMS load to 191 SetValue calls. Still a lot, but an improvement.

Update: The cache handling has been refactored to fix a bug and simplify its use. See the modifications here.

Cleanup task #8: Prevent redundant GetLastError calls

Looking at the log from task #7 is quite revealing. For example, Commit (save) was invoked 19 times — always after setting suspend_data — and GetLastError was invoked after each and every SetValue and GetValue call, for a total of 273 times. Ideally, GetLastError would only be invoked if the SetValue or GetValue attempt failed.

SetValue returns a boolean in string form ("true", "false") indicating the success of the call. We can prevent many of the GetLastError invocations by limiting them to situations where SetValue returns "false". We won’t bother monitoring GetValue calls, because they’re trickier to work with (don’t return booleans indicating success) and they aren’t used very often in Captivate. The log from task #7 shows 12 GetValue calls compared to 261 SetValue calls.

While we’re at it, let’s remove the redundant CaptivateSWF.SetScormVariable(variable, strErr); calls… we like our code nice and DRY.

View the result of task #8

After launching the course again and looking at the log, we see the following data:

  • SetValue = 261 invocations
  • GetValue = 12 invocations
  • Commit = 19 invocations
  • GetLastError = 273 invocations

Yes, you read that correctly — Captivate is trying to hit the LMS 565 times for an 8 question quiz!

The log also reveals the result of the prevention script:

  • 258 GetLastError preventions
  • 74 SetValue preventions

332 LMS hits were prevented. That reduces the course’s load on the LMS by over 50%! (Down from 565 to 233.)

If I had a nickel for every time I prevented Captivate from calling the LMS in this course, I’d have $16.60, enough to buy a nice lunch.

That’s about it for the SCORM edits. We can nitpick some more, but the basic functionality is set, and most of the advanced functionality is handled internally by the SWF.

In the next installment of this series, I’ll go over file organization and discuss how to use these edited files in your Captivate publishing templates folder. Go to Part 5.

Cleaning up Adobe Captivate’s SCORM Publishing Template, Part 3: JavaScript

In part one of this series, we published a simple Captivate course and examined its file structure. In part two, we cleaned up the HTML file and externalized all JavaScript. Today we will clean up the JavaScript.

Cleanup task #1: Tidy things up

Personally, I like to clean up code whenever I can; I feel it helps to be consistent with your code style. For example, do you place brackets { } on a new line, or in-line? Do you skip them once in a while? Are you consistent with your semicolons and line breaks?

I’m going to quickly run through this code to add brackets where needed, clean up usage of tabs, spaces, and other whitespace, and clean up any other little messes or inconsistencies I might find, without refactoring the code.

Here’s the ‘before’ code, if you’d like to follow along. Here’s the same code after it has been cleaned up.

Not perfect, but it’s a start.

Cleanup task #2: This code is VARy verbose

Here a var, there a var, everywhere a var var. There are way too many var statements in this code, some of which re-declare a variable that has already been declared! Minimizing vars is a great first step for refactoring. I will remove vars where possible, and also group and re-order where it makes sense.

While we’re at it, let’s get those function blocks out of the conditional statements.

View the result of task #2

Cleanup task #3: Replace SWFObject 1.5 with SWFObject 2.2

This template uses SWFObject 1.5, which while very durable, is also very outdated. SWFObject 2.2 provides additional features that we can put to use in our template, including a DOM-ready function and browser detection.

I’ll be linking to the copy of SWFObject stored in the Google Libraries API. Why? It loads quickly, and it might already be cached in the visitor’s browser, and it’s one less chuck of code for me to manage. No worries, though — if you don’t like the idea of using Google’s service, just paste the SWFObject 2.2 source code into standard.js, replacing the original SWFObject 1.5 code.

Next we need to replace the SWFObject 1.5 syntax in captivate.js with SWFObject 2.2 syntax. Since SWFObject 2.2’s embedSWF method includes domready-style event handling, we don’t need to wrap the SWFObject code in a window.onload event. We can also use SWFObject’s callback functionality to invoke the focus() method.

Aside: only form elements and links can receive focus; to enable other page elements to receive focus, you must set the element’s tabIndex property. The original Captivate code did not handle this task, so we will handle it here by setting tabIndex to -1, which enables us to use JavaScript’s focus method without disrupting the browser’s default tab index order. Read more about tab index here.

View the results of task #3

Cleanup task #4: What’s with the sniffing?

Line 23 of captivate.js sniffs for Internet Explorer by looking at navigator.appName. Line 207 does the same thing, with extra checks, including a check for Windows 3.1.

No, seriously:


navigator.userAgent.indexOf("Windows 3.1") == -1

(What decade is this?)

Since SWFObject 2.2 includes browser detection, we should replace all IE checks with SWFObject’s swfobject.ua.ie property. If you really stop to think, you should be asking yourself “but why are we checking for IE? Why should it receive special handling?” The goal is to use cross-browser code that works everywhere without hacks.

In two of the three IE checks, we see this:


var CaptivateObj = swfobject.ua.ie ? Captivate : document.Captivate;

Umm… yeah, more code from 1998. We can do better by simply using the W3C standard document.getElementById. This is 2012, all browsers support document.getElementById now.

View the result of task #4

Cleanup task #5: Keep your comments to yourself

There are a lot of bits of code that have been commented out. Since these are never used, let’s get rid of them.

Cleanup task #6: Tame the variable definitions and string manipulation

Variable definitions are strewn all over, with some being nested in if/else blocks. Let’s simplify where we can using ternary conditional statements or by refactoring to remove the variable, if possible.

There is also a lot of clever string manipulation going on around the document.location object, specifically with the variables strURLBase, strURLParams, strURLFull, intTemp, and strTemp. If you follow the code through the document, you’ll see a huge glaring problem when you get to line 259. All of that convoluted document.location parsing and string manipulation exists solely to define the value of strURLParams, yet when we get to line 259, we see:


if(g_objAPI != null){
   strURLParams = "?SCORM_API=" + g_zAPIVersion + "&SCORM_TYPE=" + g_intAPIType;
}

This line says “if the SCORM object is not null, give strURLParams the following value, overwriting any previous value.”

Since this is a SCORM 2004 course, if the SCORM object is null, the course is dead in the water. Therefore all of that hullabaloo around defining strURLParams is useless, except the part at line 259.

Also, the strURLParams variable is meant to hold value/key pairs found in the page’s URL; our template files never append querystring values to the HTML file, so there’s no point in looking for querystring parameters that will never be used. Let’s delete it… all of it!

View the result of task #6

Cleanup task #7: eval() is evil.

Any JavaScript developer worth his salt will tell you that eval() should only be used in very very very limited circumstances (such as parsing JSON). Most JavaScript developers will tell you it should be avoided completely. I’m one of them.

eval() is a security risk, and is often used as a shortcut by lazy coders. Captivate’s JavaScript (and ActionScript) is chock full of eval statements. Let’s refactor the code to avoid using eval(). It has the additional benefit of making the code more readable, too!

document.write is considered almost as bad as eval, but we’ll leave it in there for now — its sole purpose is handling VBScript in Internet Explorer, which is likely to be removed in a later post.

View the result of task #7

Cleanup task #8: SCORM 1.2 has no business here

This template was adopted from a SCORM 1.2 template, and contains lots of conditional checks to see if the course is using SCORM 1.2 or 2004. Since we know this is a SCORM 2004 template, we can remove all code related to SCORM 1.2. Captivate maintains separate templates for SCORM 1.2 and SCORM 2004 anyway, so it makes no sense to have code for both SCORM versions floating around in the page.

View the result of task #8

Our captivate.js file is now under 200 lines of code!

Cleanup task #9: Organize the SCORM code

As you recall, we created the captivate.js file as a place to store our external JavaScript. However, now that it has been pared down to a manageable and easier-to-read state, we can see that most of it is SCORM-related; since there’s already a scorm_support.js file, it’s only logical that we move our SCORM-related JavaScript from captivate.js to scorm_support.js.

View the results of task #9:
captivate.js
scorm_support.js

Cleanup task #10: Clean up scorm_support.js

Now that we’re getting into the scorm_support.js file, we should clean it up as well by applying all of the cleanup techniques and approaches we’ve used so far.

You can see a slightly cleaned up version here.

In the part four of the series, we’ll dig in to the JavaScript portion of the SCORM code, examining the FS Command and ExternalInterface code contained in the Captivate template. Continue to part 4.

Cleaning up Adobe Captivate’s SCORM Publishing Template, Part 2: HTML

In part one of this series, we published a simple Captivate course and examined its file structure. In this part, we’ll take an in-depth look at the HTML generated by Captivate (using the SCORM 2004 publishing template) and clean it up as much as we can.

Here’s the default HTML published by Captivate.

I’ll take the high road and avoid the ever-so-easy snarky comments about this code. Suffice to say it needs some serious cleanup; it’s obvious that multiple people with multiple coding styles have worked on this document, and no quality assurance team has run through it to ensure it’s clean and concise. For example, there is an entire block of code commented out at line 141 (commenting it out means it never gets used, and therefore is useless bloat).

There’s also an aborted attempt at using SWFObject from lines 214 to 242 — the object is declared, but never invoked. Never. Did you know this code has been shipping with Captivate for years? I’m amazed no one has bothered to clean it up (and yes, I have reported it to Adobe, but they chose not to act).

As irritated as I get looking at the code, this blog post is not meant to be a rant, so let’s be constructive and get to work cleaning this mess.

Cleanup task #1: Externalize the JavaScript

This document is incredibly hard to read due to all of the <script> elements and JavaScript code. Let’s start by removing the JavaScript in the document’s <head> by cutting it out and pasting it into an external JavaScript file.

View the results of task #1:
The new captivate.js file
The slightly cleaner sample.htm file

This single step makes the HTML file much easier to read.

Cleanup task #2: Fix the doctype

Stepping through the HTML, the very first lines of code (lines 3-4) contain a conflict: the doctype says this is an HTML 4 (transitional) document, but the head element contains an XHTML lang declaration.

We’re in an HTML5 world now, so let’s use the HTML5 doctype. It’s 100% compatible with all browsers (even Internet Explorer 6), and all the cool kids use it. We can retain the lang declaration, too, with a few modifications. While we’re at it, let’s update the charset meta tag to the accepted HTML5 syntax.

View the result of task #2

Cleanup task #3: End the crazy <script> abuse!

There are six <script> blocks in our HTML file, and they are all inconsistent. For example, some have a “type” attribute, some have a “language” attribute, some have both, and some have neither. This is a sure sign of multiple authors working on the document over a long period of time.

Going through the <script> block, we can clean them up as follows:

  • Line 8: Since we’re using the HTML5 doctype, we can simplify it to remove the “type” attribute.
  • Line 9: Leave as-is.
  • Line 10: Remove the “type” and “language” attributes.
  • Lines 17-25: This entire block is never invoked and is completely useless. Delete it.
  • Lines 37-73: The contents of this block need cleanup, but we’ll handle that later one. For now, just remove the “type” and “language” attributes.
  • Lines 74-77: There is no need for a separate <script> block here; merge the contents with the previous <script> block.

View the result of task #3

Cleanup task #4: Remove inline scripts and styles

The <body> element contains two inline attributes: a style attribute, and an onunload handler. It’s an accepted best practice to leave your markup as clean as possible by removing inline styles and scripts when possible, so let’s create a new <style> element to hold the CSS, and move the onunload handler to our captivate.js file (just paste window.onunload = Finish; at the bottom of captivate.js).

View the result of task #4

If you’re not sleeping yet, you’re probably wondering why creating a <style> block is better than leaving the style attribute in the <body> tag. For this project, I know I will be adding more CSS declarations to the <style> block, so we may as well set it up now.

Cleanup task #5: Cure <center>itis

There are two sets of <center> elements on the page that can be replaced by adding one line of CSS to the top of the page.

Delete lines 16, 47, 66 and 72. Add text-align: center; to the body selector in the <style> block.

View the result of task #5

Cleanup task #6: Edit the <noscript> block

For accessibility and usability purposes, it’s usually a good idea to include a <noscript> block; this enables you to present a message or fallback content to visitors who have JavaScript disabled in their browsers.

Captivate uses SWFObject — a JavaScript utility — to embed the Captivate SWF. To hedge their bets, Adobe also attempts to embed the SWF in the <noscript> block using a method that doesn’t require JavaScript. Normally this is a good idea. However, SCORM courses require JavaScript; if JavaScript is disabled, the course won’t be able to communicate with the LMS. Period. End of story.

For this Captivate template, it’s probably best to remove the SWF from the <noscript> block and leave a message for the learner informing them that they can’t take the course unless JavaScript is enabled. Chances are they can’t get to the popup window containing the course anyway!

View the result of task #6

Cleanup task #7: Get rid of the <table> markup

The JavaScript on lines 39-41 and 54-56 generate a <table> whose sole purpose is to make the SWF vertically centered on the page. For our purposes, this is unnecessary because most courses launch in a popup window that has been sized to fit the course.

Ironically, the <table> that is meant to make the embedded SWF look nice on the page actually causes a significant problem — the table has cellpadding and cellspacing set to 7, which means the SWF will never extend to the edge of the window. When you’re trying to make a perfectly-sized popup window for your course, this cellpadding and cellspacing will cause scrollbars to appear, driving you bonkers!

Also, it’s widely accepted that tables shouldn’t be used for layout purposes, anyway, so it’s best to get rid of the <table>.

View the result of task #7

Our HTML file is starting to look pretty sweet!

Cleanup task #8: Externalize more JavaScript where possible

We externalized JavaScript in steps 1 and 4, let’s try and get the rest of this JavaScript externalized. The only remaining inline JavaScript is contained in lines 22 through 51. Our first task is to determine whether it needs to be inline; will moving it break anything?

  • Lines 23 through 36 appear to be safe to move into the document’s <head>, which means it’s safe to move to our captivate.js file. Just cut and paste — place the script at the very bottom of captivate.js.
  • Lines 38 through 47 use SWFObject 1.5 to embed the SWF. We can move this code, but it will need to be wrapped in an onload event or else it will break the page. In a later step, we will upgrade SWFObject to 2.2, which helps us optimize the Captivate template even further.
  • Lines 49 and 50 can be moved, but will also need to be wrapped in an onload event.

While moving the SWFObject code, we can also clean it up a bit:

  • Line 39 is not necessary because quality = high is Flash Player’s default.
  • Line 41 is not necessary because SWFObject is already set to use “Captivate” (the second argument passed on line 38) as the ID for the SWF.
  • Line 42 is not necessary because wmode = window is Flash Player’s default.
  • Line 45 is not necessary because it does nothing, it’s a completely gibberish line of code. I suspect it was a placeholder put there by a developer years ago, and no one has bothered removing it. It has shipped with Captivate for years.
  • Line 46 is useless; the redirect URL is only invoked when two criteria are met: 1) the embed markup is present in the HTML, and 2) the visitor does not have the required version of Flash Player. This Captivate file is using SWFObject to write the embed code. SWFObject has its own check for Flash Player (argument #5 on line 38); if the minimum version specified is not found, SWFObject will not write the embed code into the HTML. This means requirement #1 listed above will never be met, which means the redirect URL will never be invoked.
  • Update: Upon re-reading this post, I noticed even more issues with the SWFObject code: line 40 (‘name’ is not a param, it’s an attribute) and line 43 (bgcolor param isn’t needed, the color should be specified as the 6th argument in the SWFObject declaration). I won’t update the examples because we’re replacing SWFObject 1.5 with 2.2 in the next part of this series, so the entire SWFObject code block will be replaced.

    The updated HTML:

    Nice and simple, huh? We can pare it down more later, but this is a great start.

    View the updated captivate.js file.

    We were able to reduce the sample.htm file from 278 lines of code to 23 lines. Our new captivate.js weighs in at 224 lines of code, but we’ll be taking a sledgehammer to the JavaScript code in part three of this series.

    Continue to part three.

Cleaning up Adobe Captivate’s SCORM Publishing Template, Part 1: Introduction

Adobe Captivate is an enormously popular tool for e-learning developers. My assumption is that most Captivate users chose Captivate as their development tool because it enables them to publish LMS-compatible courses without requiring any programming skills — no need to know JavaScript, ActionScript, SCORM, etc.

This might explain why no one is up in arms about the astoundingly bad HTML and JavaScript output by Captivate — very few people look under the hood.

In this multi-part series, I will walk through the files Captivate outputs when publishing to SCORM 2004, pointing out the bad parts (hey Adobe: this is constructive criticism, it’s for your own good) and suggesting alternatives when needed. At the end of the series, I will provide a fully-functional SCORM 2004 publishing template you can use with Captivate 5.5.

Getting Started

The first step is to create a very simple Captivate course and publish it using the SCORM 2004 template. This will produce a set of files that we can examine and modify without breaking any templates.

  1. Go to File > New Project > Blank Project
  2. Select a small screen size since we’re just messing around. I selected 640 x 480.
  3. Add something to the stage just so we have something to look at aside from a blank white screen. You can add a text caption, image, etc. — it doesn’t have to be fancy, it just gives us something to look at.
  4. Publish to SCORM 2004
    1. File > Publish Settings
    2. Quiz > Check “Enable reporting for this project”
    3. Under Learning Management System select SCORM.
    4. Click the “Manifest” button. The Manifest dialog will appear; select 2004 from the drop-down menu.
    5. Click OK, then click OK in the Publishing Settings dialog.

Now publish your course: File > Publish. The Publish dialog appears. Nothing to change here, unless you want to select a different location for your files. Click “Publish”.

Attack of the Files

Find the folder containing your published files and take a peek at what Captivate generated for you. It’s quite intimidating, especially with all of those SCORM 2004 XSD files. I suggest sorting the files by kind.

Here’s a quick breakdown of the files:

  • All the DTD and XSD files are a required part of SCORM’s packaging system. The common, extend, unique, and vocab folders all contain SCORM-related XSD files. None of these files or folders should be edited, renamed, moved or deleted. You must keep them, but otherwise it’s best to act as if they don’t exist.
  • The imsmanifest.xml file is required for SCORM 2004. Don’t move or rename it. Some portions of the file may be edited, but you’d better know what you’re doing!
  • The SWF file (in my case sample.swf) is the Captivate course.
  • The HTM file (in my case sample.htm) is the HTML file that contains the SWF.
  • standard.js is a JavaScript file that contains some 3rd-party JavaScript utilities.
  • The SCORM_support folder contains files that Captivate uses to communicate with the LMS when using really old browsers. The files aren’t part of the SCORM standard, they’re just helper files created by Adobe.

Hopefully the files don’t seem so intimidating now that you know what’s what.  Once you ignore the XSD and DTD files, there are actually very few files left to work with.

The next post in this series will cover the HTML file produced by Captivate. Continue to Part 2.

HTML5, Flash, Silverlight, and your courseware

What a busy week.

Flash is dead. Sort of, but not really.

In case you haven’t heard, Adobe formally announced the discontinuation of Flash Player for mobile devices (“Flash to Focus on PC Browsing and Mobile Apps; Adobe to More Aggressively Contribute to HTML5“). Adobe employees struggled to come to grips with what has undoubtedly been a tough week for them — aside from the product news, they were also informed of massive layoffs (around Adobe 750 employees). Regardless of your feelings about Flash, your heart must go out to the families affected by a sudden job loss.

Flash critics were quick to declare Flash dead. But in the immortal words of Monty Python’s Eric Idle, “I’m not quite dead yet.”

Yes, Adobe is scaling back on Flash to focus more energy on so-called HTML5 technologies (“so-called” because many of the technologies involved are not actually part of the HTML5 spec.) However, their public announcement was that mobile Flash is dead, and Flash on the desktop will continue to thrive.

Flex is being abandoned

Then the “Official Flex Team Blog” dropped a bombshell: Adobe Flex is going open-source:

Yes. We know Flex provides a unique set of benefits for enterprise application developers. We also know that the technology landscape for application development is rapidly changing and our customers want more direct control over the underlying technologies they use. Given this, we are planning to contribute the Flex SDK to an open source foundation in the same way we contributed PhoneGap to the Apache Foundation when we acquired Nitobi.

Okay. Flex is being open-sourced. To be honest, this isn’t really shocking news to me since Flex has mingled with Eclipse for a long time and has had its toes in open source for ages. The part that made my jaw drop was in the next section:

Does Adobe recommend we use Flex or HTML5 for our enterprise application development?
In the long-term, we believe HTML5 will be the best technology for enterprise application development. We also know that, currently, Flex has clear benefits for large-scale client projects typically associated with desktop application profiles.

Given our experiences innovating on Flex, we are extremely well positioned to positively contribute to the advancement of HTML5 development, starting with mobile applications. In fact, many of the engineers and product managers who worked on Flex SDK will be moving to work on our HTML efforts. We will continue making significant contributions to open web technologies like WebKit & jQuery, advance the development of PhoneGap and create new tools that solve the challenges developers face when building applications with HTML5.

In the long-term, we believe HTML5 will be the best technology for enterprise application development. For those of you unfamiliar with Flex, it’s Adobe’s ‘enterprise-level’ Flash development path. Designers use Flash Professional and the timeline, while programmers use Flex and its pure ActionScript/MXML environment. This line is basically saying “see ya, Flex, was nice knowing you. We’re putting our best guys — the ones who weren’t laid off — on the ‘HTML5’ train.”

By extension, if Adobe is wiping its hands of Flex, it means they’re seriously scaling back support for the entire Flash ecosystem.

Whoa. The anti-Flash crowd really does have reason to celebrate. But not so quick, my friends: Support for the HTML5 environment is nowhere near Flash’s level of ubiquity, it will take a couple of years to get there, and even then, I doubt it will have the full capabilities Flash offers today.

But does it matter? Let me come back to that in a minute.

Silverlight is dead. Sort of, but not really

For now, lets turn our attention to our friends in Redmond, WA. While Adobe created this week’s loudest thunder, Microsoft made a few waves itself. If you recall, about a year ago one of Microsoft’s presidents (yes, they have more than one) caused a stir when he said “HTML is the only true cross platform solution for everything, including (Apple’s) iOS platform”. Microsoft quickly issued a statement backtracking from the implication that Silverlight was on its way out, and stressed their commitment to Silverlight.

A year later, the circus is back in town. According to some industry sources, Microsoft is planning to stop development of future editions of Silverlight; version 5 may be the last hurrah, except for security updates. Stop me if this sounds familiar.

However, this time around, the rumor sounds much more feasible because of Internet Explorer 10.

Microsoft’s Internet Explorer, that grand ol’ browser, is going through a major metamorphosis. In general, Internet Explorer 10 will behave less like its ancestors and more like Firefox and Webkit (Safari/Chrome). For example, IE 10 will not support Microsoft’s long-standing conditional comments. This is a big deal for web developers, as conditional comments have become a major crutch when dealing with Internet Explorer. But the biggest news I’ve heard about IE 10 thus far is that it will not support plugins — Flash, Silverlight, Quicktime, etc. — when running in “Metro” mode. Microsoft’s Windows 8 team believes that removing plugins from IE will result in improvements across-the-board: security, reliability, privacy, battery life in mobile devices, etc.

For the web to move forward and for consumers to get the most out of touch-first browsing, the Metro style browser in Windows 8 is as HTML5-only as possible, and plug-in free. The experience that plug-ins provide today is not a good match with Metro style browsing and the modern HTML5 web.

Running Metro style IE plug-in free improves battery life as well as security, reliability, and privacy for consumers. Plug-ins were important early on in the web’s history. But the web has come a long way since then with HTML5. Providing compatibility with legacy plug-in technologies would detract from, rather than improve, the consumer experience of browsing in the Metro style UI.

Plugins will still be supported in the non-Metro environment, but it appears Microsoft’s way of the future is Metro, and Metro is HTML5-based, with no plugins allowed, just like Apple iOS. Microsoft is clearly serious about leaving plugins behind, including its own Silverlight Player.

The analysis

Flash and Silverlight are not dead, but are being minimized by their owners. If you read the articles closely, you’ll see a pattern: both Adobe and Microsoft hope to port some of the technology from their plugins to the open web, aka the “HTML5 ecosystem”.

As it currently stands, browser technology and HTML5 ubiquity will take a number of years to catch up to the baseline capabilities of Flash and Silverlight. Even then, I doubt browsers will have some of the advanced capabilities Flash offers today.

The thing is, I don’t think most Flash developers take full advantage of Flash’s capabilities; they seem to use the same basics they’ve been using for years. The cutting-edge stuff is nowhere near as common as the mundane: video players, slideshows, and simple games.

Today’s editions of Firefox, Chrome, Safari, and even Internet Explorer 9 are massively capable browsers. JavaScript, canvas, and CSS3 can be used to replicate many of Flash’s features. The real question becomes: what are you trying to do?

Video

The vast majority of Flash usage appears to be for serving streaming video. HTML5’s video support is not quite ready to replace Flash in this regard, but it’s getting pretty close. The codec wars are the biggest stumbling block, followed by support for DRM and perhaps a handful of advanced features. If you have a simple video that doesn’t need DRM and can be served via two codecs (H264 and OGG or WebM), you can proceed directly to Go, collect $200.

Need to add some interactivity to your movie? Canvas and JavaScript can do an awful lot. Projects like WebGL and Mozilla’s popcorn.js are upping the ante. The future looks pretty bright for native online video.

Gaming

Flash-based gaming is another strong user base. My kids have been using NeoPets and similar sites for years, so I understand just how far and deep Flash gaming goes in our community. But some of these games are deceptively simple with their graphics, and I wouldn’t be surprised if Adobe’s HTML5 tools soon enable Flash game developers to port their games to the HTML5 ecosystem.

Apple’s iOS and Facebook have created big-money opportunities for game developers willing to switch gears to HTML5. We’ve already seen JavaScript/HTML ports of Nintendo games, including the best video game ever made: Super Mario Brothers. They work. They’re fun. Yes, it will take a long time to get market saturation, but HTML5 already has its foot in the door and a lot of money behind it — gaming is big business!

E-Learning

If you’re reading this blog, chances are good that you’re an e-learning developer. You probably also know that most major e-learning rapid development software outputs Flash SWFs. I can’t think of any industry aside from online gaming that is so utterly dependent on Flash at the moment. This has worried me for years — I’ve long preached that e-learning developers should be less reliant on Flash.

When Apple’s iPad was released without Flash support, the outcry from the e-learning industry was fierce. I also feel it was misplaced — it clearly showed the industry’s reliance on a plugin, and rather than focus on removing the Flash requirement barrier, many people chose to plant their feet in the ground and buy non-Apple devices as a form of protest. Some vendors, to their credit, modified their products (Raptivity, Lectora, Rapid Intake, etc.) to take steps away from plugin requirements and towards modern HTML5 experiences. (I admit I haven’t tried the HTML5 editions of these products yet, so I can’t speak to their quality.)

Don’t get me wrong, I’m not anti-Flash — anyone who follows this blog knows that I work with ActionScript and am a member of the SWFObject project team — I just think browsers plugins should be used sparingly, with decent fallbacks in place for people who don’t have Flash, such as video transcripts for people who can’t see the video.

My personal development approach has been to develop the course interface and base pages in HTML/JavaScript, and only use Flash when necessary, such as when playing a video or providing a software simulation experience. Now that native video playback is possible in modern browsers, it’s easy to go back and retrofit courses to use HTML5 video. Same goes for audio if you like to have narration in your course. Some situations, such as software simulations, are much trickier, but this is where we rely on tool vendors to improve their tools. For example, Adobe is working on enabling Captivate to output to HTML5 (it currently only outputs a non-interactive video version of the SWF).

Quizzes, fun interactions, and elegant slideshows are all possible with JavaScript today, even in lowly Internet Explorer 6. I have no idea why a simple course system like Articulate Presenter doesn’t provide an HTML5 publishing option yet… interactions can be handled via JavaScript. Narration can be handled via HTML5’s audio element. Quizzes can be handled by JavaScript (though I admit the security is not as strong when you can’t obfuscate answers via a SWF). Even Captivate should be farther along than it is, but at least they’re making progress.

Hopefully this week’s news about Adobe and Microsoft shifting gears away from plugins will help the more hard-headed among us in the e-learning industry to take a more active role in moving away from Flash and towards a true native web experience.

SCORM “Planets” Example Updated

Update 10/13/2011: I added more comments to the ActionScript code to help explain what each line of code does. I also added a Flash CS4 version of the FLA to the ZIP so more people can access the example.

My “Planets” example (How to Add Basic SCORM Code to a Flash Movie) has proven to be one of the most popular items on pipwerks.com. Unfortunately, it was designed as a quick example and had a bunch of flaws and shortcomings. It’s also about 3 years old and starting to show its age. Since people frequently contact me with questions — many of which were due to the flaws in the example — I decided to update the project.

The new Planets example has a bunch of fixes:

  • Full compliance with SCORM XSD requirements (it includes all those pesky XSD files that really don’t do anything but are required anyway).
  • Upgraded the pipwerks JavaScript wrapper to the latest version
  • Upgraded the pipwerks ActionScript 3 wrapper to the latest version
  • Upgraded SWFObject from 1.5 to 2.2
  • Changed the doctype and markup to HTML5
  • Added an unload handler to the JavaScript to ensure course progress is saved if the learner exits early
  • Added support for tracking progress across attempts using cmi.suspend_data
  • Completely rebuilt the FLA file to remove all timeline-based animation and scripts. Now uses a single ActionScript file, loaded on a single frame. All animations (fade transitions) are handled via ActionScript. This makes the file smaller and hopefully less confusing.
  • The SCORM code is clearly separated from the rest of the movie’s ActionScript; it’s in the same file, but not intermingled with other functions.

I haven’t decided if I’ll create a detailed tutorial to explain the updates; I’ve added a ton of comments to the ActionScript file, and hope it’s clear enough for others to follow.

Download the updated Planets example
The ZIP includes two FLA files: one in CS4 format, and the other in CS5.5. The code, movieclips, and graphic elements inside the FLAs are exactly the same.