The current version of pipwerks.com is mostly traditional HTML with WordPress being used for the Journal entries; the new version of the site will be almost exclusively Wordpress-powered.

Because of the move to WordPress, many of my static HTML files will be converted to WordPress 'pages'; this means you may see some odd posts in my RSS feed from time to time. Feel free to ignore them.

Why WordPress? A number of reasons, including:

• easy 'themability'
• enabling users to post comments on normal pages, not just blog entries (this will be especially useful for gathering feedback about my lab work with SCORM and Captivate)
• statistics tracking
• ease-of-updates for pages (browser-based editing means no more Dreamweaver and FTP)
• WordPress' extensibility via plugins and widgets
• Search engine friendliness
• Automated linking of content via tags and categories can help visitors find related content more easily

I'll still be using plain HTML for code examples and demonstrations, but that's about it.

I have a few tricks up my sleeve and hope to try them out soon. In the meantime, I'll just mention that my new theme (which hasn't been activated yet) is HTML 5-based and uses a bunch of CSS trickery. Geeky fun for all.

Why so quiet lately?

If you're a regular reader of this blog, you may have noticed that it has been very quiet lately. Rest assured there are a number of blog entries waiting in the wings — I've simply been too busy to write them. I promise I will get to them soon(ish).  In the meantime, I invite you to join me on twitter.

Possibly related journal entries:

• March 21, 2009 — Gotchas in Internet Explorer 8
• February 1, 2009 — Obfuscating email addresses, revisited
• February 28, 2008 — Accessibility development tools
• February 7, 2008 — Development standards for e-learning… a starting point
• February 4, 2008 — Rapid Intake: Where are the standards?
• June 13, 2007 — Email address obfuscation

This work by Philip Hutchison is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.

Changes to pipwerks.com

//Assuming your SWF is embedded using the ID "myID"
var myMovie = CaptivateController("myID");
myMovie.pause(); //Pauses the Captivate SWF
myMovie.mute(); //Mutes the Captivate SWF

For those of you familiar with the pipwerks.captivate.control utility, this CaptivateController is not a simple rehash of the original; it is a complete re-write that adds a number of extra features, including:

• Support for Captivate 2, Captivate 3, and Captivate 4 files
• Auto-detection for skins; you can write the exact same JavaScript whether your SWF uses a skin or not
• New query methods, including the ability to query a user-defined variable in a Captivate 4 file

The CaptivateController took a long time to develop because it deals with a number of inconsistencies between Captivate 2/3 SWFs and Captivate 4 SWFs, including the shift from using GetVariable to using Captivate 4's proprietary cpGetValue (via ExternalInterface). It also handles inconsistencies with Flash Player in different browsers. Safari and Internet Explorer both provided their own small challenges.

There are still some inconsistencies that cannot be solved using JavaScript; for instance, Captivate 4 SWFs published using ActionScript 3 provide a richer set of system variables than Captivate 4 files published using ActionScript 2. I expected to have the same access to all system variables regardless of ActionScript version, but alas it was not meant to be.

Someday I hope to post a chart of which variables work when, but until then you can check out the Automated Test Suite, which illustrates which variables are available for each flavor of Captivate SWF.

Download

The CaptivateController weighs in at about 8kb and has been successfully tested in the following systems:

• Mac OS X (10.5): Firefox 3.0.10, Safari 3.2, Opera 9.6
• Windows XP: Internet Explorer 6, Internet Explorer 8, Firefox 3.0.10
• Windows Vista: Internet Explorer 7

You can download the compressed version (8kb) here.

You can view the source version here (please do not hotlink).

Quickie documentation

I haven't had the time to do a full write-up of the CaptivateController API, but the following information should be enough to get you started.

Don't forget to check out the test suite. A list of Captivate Variables can be found on the Automated Test Suite and also in this blog post.

"Control" methods available in the API

• pause()
• resume()
• next()
• previous()
• rewindAndStop()
• rewindAndPlay()
• gotoSlideAndPlay(slidenumber)
• gotoSlideAndStop(slidenumber)
• gotoFrameAndPlay(framenumber)
• gotoFrameAndStop(framenumber)
• volume(volumelevel)
  • Takes number, 0-100
  • Returns current volume level, 0-100
  • Volume only works in CP4+
• mute()
• unmute()
• muteAndShowCaptions()
• unmuteAndHideCaptions()
• showCaptions()
• hideCaptions()
• showInfoBox()
• hidePlaybar()
  • Doesn't seem to work consistently via JavaScript
• showPlaybar()
  • Doesn't seem to work consistently via JavaScript
• lockTOC()
  • Enables/disables user interaction on TOC
  • Only works in CP4+
• unlockTOC()
  • Enables/disables user interaction on TOC
  • Only works in CP4+
• exit

Example:

//Assuming your SWF is embedded using the ID "myID"
var myMovie = CaptivateController("myID");
myMovie.pause(); //Pauses the Captivate SWF
myMovie.mute(); //Mutes the Captivate SWF

Commands can also be chained together, like so:

var myMovie = CaptivateController("myID");
myMovie.pause().mute(); //Pauses then mutes Captivate SWF

Query methods

The primary query technique is to use .query("captivate_variable_name"). For example,

var myMovie = CaptivateController("myID");
//Retrieves the author's name, if available
var author = myMovie.query("cpInfoAuthor");

You can also use this method to query user-defined variables:

var myMovie = CaptivateController("myID");
 
//Retrieves the variable My_custom_variable_name, if available
var myUserDefinedvariable = myMovie.query("My_custom_variable_name");

I have created some additional query methods below. Some are designed to help avoid worrying which version of Captivate is being used (ie they work with both CP3 and CP4), and others provide data directly from the Flash SWF (not using CP variables).

• captivateVersion()
  • Returns major number, currently either 2 or 4 (Captivate 3 SWFs self-identify as CP2 SWFs!)
• asVersion()
  • Returns either 2 or 3
• FPS()
  • Returns the frames per second of the SWF
• hasSkinSWF()
  • Returns a boolean indicating whether the SWF is using a skin
• hasTOC()
  • Returns a boolean indicating whether the movie has a Table of Contents
• hasPlaybar()
  • Returns a boolean indicating whether the SWF has a playbar
• width()
• height()
• volume()
  • Returns a number (0-100) indicating volume level. Note: volume only works in CP4+.
• Flash SWF (not Captivate) properties
  • percentLoaded()
  • getname()
  • geturl()

You can also grab a reference to the SWF itself by using .swf. This is the equivalent of document.getElementById():

var myMovie = CaptivateController("myID");
myMovie.swf === document.getElementById("myID");

Does it work for you?

I'm planning on refining this controller utility over time. If you encounter any problems or have any suggestions for improvements/new features, please let me know by leaving a comment below.

DISCLAIMER: This controller is provided as-is. Use this controller at your own risk. I cannot be held responsible for any problems you may encounter while using the controller. kthxbai.

Possibly related journal entries:

• May 16, 2009 — Captivate 4 variables gone wild
• January 20, 2009 — Adobe eLearning Suite and Captivate 4 released
• November 10, 2008 — Adobe E-Learning Products "Sneak Peeks"
• September 8, 2008 — Control a Captivate SWF using JavaScript: The basics
• September 7, 2008 — Send Captivate Quiz Data to JavaScript
• March 23, 2009 — LegacyCaptivateLoader example updated

This work by Philip Hutchison is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.

Introducing the CaptivateController

Here is a list of variables I dug up while combing through Captivate 4's source AS files. I tried to add descriptions where I could, and will continue to revise this list as I get more information. Kudos to Michael at www.captivate4.com for posting his helpful list, too.

Notes:

• I've tested each of these variables in JavaScript to ensure they exist and are accessible, and have weeded out variables that return errors.
• I've also included Captivate 3 variables at the bottom of this page.

Captivate 4 Variables

Functional variables (perform an action)

Informational variables (retrieve or set data)

Captivate 3 Variables

Functional variables (perform an action)

Informational variables (retrieve or set data)

Possibly related journal entries:

• June 7, 2009 — Introducing the CaptivateController
• March 23, 2009 — LegacyCaptivateLoader example updated
• April 8, 2008 — LegacyCaptivateLoader: dealing with pre-existing scripts in your Captivate SWF
• April 3, 2008 — New: LegacyCaptivateLoader class
• March 11, 2008 — Introducing the pipwerks e-learning development forum
• August 14, 2007 — Captivate 3, JavaScript and Actionscript

This work by Philip Hutchison is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.

Captivate 4 variables gone wild

But as I hear more from these seasoned SCORM pros, I've made (what I believe to be) an interesting observation: there is a sharp division between die-hard SCORM developers and casual users.  I suppose I've felt this way for a long time, but it's really coming into focus this week. Let me try to define the camps.

• Die-hard SCORM developers (aka scormmies). The scormmie is a person who understands what SCO roll-up means, and can hand-code an entire manifest.  A scormmie thinks the word metadata is sexy. This person believes a course should be designed to use SCORM from the start, complete with sequencing and interaction tracking; if the course isn't running in an LMS, it won't function without being loaded into some kind of SCORM player or test suite. Scormmies get angry if their LMS hasn't implemented the entire SCORM spec.
• Casual users (aka shruggies). The shruggie is a person who doesn't care about multi-SCO courses. Shruggies don't want to be bothered by the technical details, and use rapid e-learning development tools to build courses, freeing them from needing to know any of the technical mumbo-jumbo. Metawhat? "SCORM… yeah, that's one of the publishing options in [insert product name here], right?  So it will work with my LMS?"

The e-learning market has changed significantly

Over the last week I've mostly heard from scormmies who make comments such as 'well, if a developer knows what they're doing, they'd never make their course that vulnerable to begin with!' and 'a developer should never design a course to only require a completion and score… that's asking for trouble.'

The problem with this line of reasoning is that the e-learning landscape has changed dramatically since SCORM was first conceived; the scormmie used to be the majority.  Now, with the proliferation of e-learning development tools and LMSs, the scormmie is a minority. Most "e-learning developers" are not programmers by trade, and are not familiar with the very complicated and intimidating SCORM spec. They use tools that do the heavy lifting for them.

If you survey most e-learning development tools (which is a booming market), the courses they publish are almost exclusively single-SCO courses that only use the simplest core SCORM functionality: completion status, lesson location (bookmarking), score, and suspend_data.  These products are designed to create courses that work without SCORM, which means they only add the minimal SCORM code needed to get the course running on an LMS; all other logic is generally handled internally.  They certainly don't use sequencing and navigation or cmi.interactions.

LMS vendors generally advise customers to buy these off-the-shelf tools to build their courses.  E-learning conferences are packed with tool vendors and advertisements selling the virtues of a 'no technical expertise required' tool.  At work I sometimes get calls from vendors trying to sell me the latest and greatest tool.

The majority of courses are no longer developed by scormmies

All of this leads to one point: I think some of the SCORM guys have lost touch with the current market and don't realize just how much of a problem a simple SCORM cheat like mine could be.  Sure, it probably wouldn't work on courses developed by seasoned scormmies because multi-SCO courses that utilize interactions are much too complicated for my itty-bitty script to tackle… but courses developed by mainstream development tools are easy targets. Ducks in a barrel. So long as the API is JavaScript and unprotected, a script like mine can bypass the SCO completely and set the course to complete before the learner even gets past the table of contents.  The only way to figure out if someone cheated is to run a completion report and look for unusual patterns, which is highly unlikely in most corporate environments. As a friend noted the other day, there are many more script kiddies who can write cheats like mine now than there were when SCORM was first proposed.

Who gets the blame for the vulnerability?

Can the tool makers be blamed? Maybe, but hey, their #1 priority is satisfying the needs of the community, and the community wants quick, easy, and 'can run on a CD-Rom'. Could the vendors have implemented more sophisticated SCORM mechanisms? Yes. However, everyone chooses the path of least resistance (and least development dollars), and we all know SCORM development is not a walk in the park. I've been using SCORM for five years and still avoid most of the complicated stuff because it's … well … complicated.

The community at large (aka the shruggies) has bought into the notion that SCORM is the standard for e-learning.  This is what the scormmies wanted, and it made the most sense for everyone involved, even the tool vendors.  But how many people knew about the security vulnerabilities in the JavaScript-based API? A lot: the SCORM authors, the ADL, LMS vendors, tool vendors, and a number of prominent SCORM developers. Did any of these people warn the end clients of the risks? Maybe, but I personally have never been warned of any SCORM security issues in my five odd years of SCORM work. I've never been told "don't use SCORM for that because it isn't secure."

Why didn't anyone act?

I wasn't privy to the early conversations, but I've been told that SCORM developers have said "don't use SCORM for high-stakes assessments" from the very beginning, circa 2000.  If this is the case, why has nothing been done to improve SCORM's security?  It's only been about nine years. Did convenience beat out security in the race to implement the standard?

I get the impression that the scormmies (and remember, my term scormmie just means a person that works with SCORM, not necessarily an official representative) felt no one would bother trying to hack the system, and that a well-built course would be so difficult to cheat that it would be easier to simply take the course.  With today's simplistic single-SCO courseware tools, I don't think this is a valid argument anymore.

I've also heard from scormmies that we're still fine, because everyone knows SCORM shouldn't be used for high-stakes training. I think a significant number of corporate, military and government trainers would disagree with that assessment, because the LMS salesperson never mentioned it.  Neither did the e-learning development tool vendor. Oh, and that instructional designer we hired out of college?  She's heard of SCORM but has no clue how it works. Isn't it safe since you have to log into the LMS with a password?  There's a padlock icon and an https protocol… that means it's secure, right?

Nope.

Simple-SCO courses are used for all kinds of sensitive training nowadays. Compliance training alone is huge these days and can be found in examples from almost every simple-SCO tool vendor. As a colleague recently remarked, "it's all low stakes until someone's attorney gets involved".

No hard feelings!

I would like to point out that I am not targeting anyone in particular, have no animosity towards anyone, and have the utmost respect for the scormmies and what they do (I'm half-scormmie myself). I'm an optimist with a very critical eye, and this post is intended as constructive criticism… criticism intended to cause positive change.

It simply became apparent to me that at some point the scormmie community dropped the ball and got complacent; it seems as though the whole community assumed no one would bother to hack a course. Well, I did. And I used public documentation to do it. It took two hours while I was flying on an airplane, and I'm not the sharpest tack in the box. I'm sorry if my cheat script caused a stir (and if this blog post makes some people uncomfortable) but we need to talk about this issue.  Now.

What's the solution?

OK, we've covered enough of the criticisms and the importance of working towards a solution… I'm ready to let it rest. Let's finish on a positive note: SCORM uses existing technology and standards, and if multinational banks can protect billions of dollars from cyber-criminals using standard web technology, we should be able to secure our courseware, too. I personally think we should be able to figure something out in the next couple of months and that it ideally shouldn't require much work to implement — no need to wait until SCORM 2.0 comes out!

Here are some suggestions I've heard:

• using a secure web service to handle important duties such as processing completions and scores
• rolling up SCOs in a way that forces the LMS to analyze multiple SCOs before setting pass/fail (a second 'dummy' SCO could be used if the course is a single-SCO course)
• using form posts to submit the completions (the form post would contain a unique encrypted key that must match a key on the LMS)

Personally, I'm especially interested in ideas that don't require modifications to LMS implementations and might only involve a strategic re-organizing of a SCO's manifest or SCORM code. Perhaps using a SCO roll-up can become a security best practice, even if the course only uses one SCO? That type of simple solution would be ideal since it wouldn't require modifications to an LMS or SCORM spec — it would only require a broad marketing effort to get the word out to all SCORM developers and toolmakers.

I would love to hear other ideas, as I feel we can probably come up with any number of workable solutions.    Please add to the discussion! Remember, these need to be solutions that can be implemented easily and by the single-SCO type of courseware tools flooding the e-learning market.

By the way, while we're at it, can we improve accessibility in our e-learning, too? 

Possibly related journal entries:

• December 13, 2008 — SCORM 2.0: high-level solutions or low-level tools?
• June 22, 2008 — What do you want *your* SCORM to do?
• March 11, 2008 — Introducing the pipwerks e-learning development forum
• February 14, 2008 — SCORM JavaScript wrapper updated to 1.1.4
• January 28, 2008 — SCORM API Wrapper updated to 1.1.2
• January 24, 2008 — SCORM API Wrapper updated to 1.1.1

This work by Philip Hutchison is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.

SCORM security (two kinds of SCORM people)

• Mac OS X:
  • Firefox 3.0.7
  • Opera 9.6.3
  • Safari 3.2.1
• Windows XP:
  • Internet Explorer 6
  • Firefox 3.0.6
• Windows Vista Business:
  • Internet Explorer 7
  • Firefox 3.0.2
  • Opera 9.5.2
  • Safari 3.2.1
• Windows 7 Experimental
  • Internet Explorer 8 (Beta)

Note: the LegacyCaptivateLoader will probably fail if you embed the SWF using SWFObject 2's static publishing option, as the nested <object> elements will cause problems for the JavaScript.

Possibly related journal entries:

• April 8, 2008 — LegacyCaptivateLoader: dealing with pre-existing scripts in your Captivate SWF
• April 3, 2008 — New: LegacyCaptivateLoader class
• May 16, 2009 — Captivate 4 variables gone wild
• March 11, 2008 — Introducing the pipwerks e-learning development forum
• January 14, 2008 — Loading Captivate files into an AS3 Flash SWF
• August 14, 2007 — Captivate 3, JavaScript and Actionscript

This work by Philip Hutchison is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.

LegacyCaptivateLoader example updated