e-learning – pipwerks

February 23, 2014

AppleScript for generating SCORM manifest nodes

SCORM requires all of the course assets to be listed as a <file> item in the <resource> node. This is not evenly enforced — some LMSs don’t care of you do it or not — but is still a good practice.

If you’re anything like me, you find it to be a major pain and try to avoid it.

Today I decided to whip up an AppleScript that automates the generation of the <file> nodes to make my life a little easier. If you’re on a Mac, you may find it useful, too. I’ve posted it on GitHub as gist:

https://gist.github.com/pipwerks/9179518

Note that it doesn’t include the name of the root folder. Let’s say you have a root folder named content. If needed, you can simply specify the root using the “xml:base” attribute of the resource node, like so:


<resource identifier="reosurceID" adlcp:scormType="sco" href="index.html" type="webcontent" xml:base="content/">
   <file href="index.html" />
   <file href="Lesson01/index.html" />
</resource>

Clean out the root of your SCORM 2004 package

Anyone who works with SCORM 2004 has seen something like this:

With just a little effort, you can make it look like this, and still be perfectly valid:

SCORM manifests are required to specify a slew of schema files via the schemaLocation attribute. Here’s what you’d typically see:


<manifest identifier="pipwerks-schema-example" version="1.0"
          xmlns="http://www.imsglobal.org/xsd/imscp_v1p1" 
          xmlns:adlcp="http://www.adlnet.org/xsd/adlcp_v1p3" 
          xmlns:adlseq="http://www.adlnet.org/xsd/adlseq_v1p3" 
          xmlns:adlnav="http://www.adlnet.org/xsd/adlnav_v1p3" 
          xmlns:imsss="http://www.imsglobal.org/xsd/imsss" 
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
          xsi:schemaLocation="http://www.imsglobal.org/xsd/imscp_v1p1 imscp_v1p1.xsd 
                              http://www.adlnet.org/xsd/adlcp_v1p3 adlcp_v1p3.xsd 
                              http://www.adlnet.org/xsd/adlseq_v1p3 adlseq_v1p3.xsd 
                              http://www.adlnet.org/xsd/adlnav_v1p3 adlnav_v1p3.xsd 
                              http://www.imsglobal.org/xsd/imsss imsss_v1p0.xsd">

Notice the structure of the data in the schemaLocation attribute: external URL followed by a space then the local (relative) URL. For example:


http://www.imsglobal.org/xsd/imscp_v1p1 imscp_v1p1.xsd

In this example, imscp_v1p1.xsd is at the root of the package, in the same folder as the imsmanifext.xml file. The trick is to create a subfolder in the root of the package, then update schemaLocation to point to the subfolder. I created a subfolder named SCORM-schemas, which you can see in the following code exerpt:


<manifest identifier="pipwerks-schema-example" version="1.0"
          xmlns="http://www.imsglobal.org/xsd/imscp_v1p1" 
          xmlns:adlcp="http://www.adlnet.org/xsd/adlcp_v1p3" 
          xmlns:adlseq="http://www.adlnet.org/xsd/adlseq_v1p3" 
          xmlns:adlnav="http://www.adlnet.org/xsd/adlnav_v1p3" 
          xmlns:imsss="http://www.imsglobal.org/xsd/imsss" 
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
          xsi:schemaLocation="http://www.imsglobal.org/xsd/imscp_v1p1 SCORM-schemas/imscp_v1p1.xsd 
                              http://www.adlnet.org/xsd/adlcp_v1p3 SCORM-schemas/adlcp_v1p3.xsd 
                              http://www.adlnet.org/xsd/adlseq_v1p3 SCORM-schemas/adlseq_v1p3.xsd 
                              http://www.adlnet.org/xsd/adlnav_v1p3 SCORM-schemas/adlnav_v1p3.xsd 
                              http://www.imsglobal.org/xsd/imsss SCORM-schemas/imsss_v1p0.xsd">

Test, test, test! I’ve tested this in SCORM Cloud as well as a couple of real-world LMSs and haven’t encountered any issues. Your mileage may vary depending on your LMS’s SCORM implementation, but this is perfectly valid XML and shouldn’t break in any LMSs — unless the LMS is poorly coded, but that’s a rarity, right? (LOL)

March 13, 2013

Flash support is increasingly a minefield

Back in 2011, I mentioned that Microsoft was about to halt development of the Silverlight plugin, that Flash mobile was being discontinued, and that Adobe recommended HTML5 for enterprise RIA development instead of Flex, which was being open-sourced. My post was a little long-winded, but the short version was: whoa, the times-are-a-changin’, it’s getting dangerous to rely on browser plugins.

Over the last year, the situation has evolved in an interesting way — browser support for plugins (especially Flash Player) has been considerably restricted by browser vendors due to repeated security vulnerabilities in Flash Player and Java.

Automatically disabling Flash Player

In May 2012, Apple’s Safari browser began automatically disabling outdated versions of Flash Player: “Out-of-date versions of Adobe Flash Player do not include the latest security updates and will be disabled to help keep your Mac secure.” If a webpage contains a SWF but the installed edition of Flash Player is deemed out of date, Safari will display a “blocked plugin” message and inform the user they need to download the latest edition of Flash Player at adobe.com. This change came with Adobe’s blessing.

In January 2013, Mozilla introduced a global “click to play” mechanism that disables ALL plugins in Firefox by default, except the latest edition of Flash Player: “Our plan is to enable Click to Play for all versions of all plugins except the current version of Flash.”

To Adobe’s credit, Flash Player updates are being released at a fast clip to address known security vulnerabilities. Unfortunately, this has a nasty side effect: you’re very likely to have an outdated edition of Flash Player when you try to view Flash content on a website. (By my unofficial count, there have been at least 13 updates over the past calendar year, averaging about once a month.)

At a recent job, I managed a small network of Macs in classrooms. The Macs were set up to use Adobe’s ‘automatic updates’ feature for Flash Player, but they never seemed to update fast enough — we received numerous complaints from classroom users who couldn’t view Flash content because Safari blocked it.

Internet Explorer’s on-again, off-again relationship with Flash Player

I previously mentioned that Microsoft’s Windows 8 ‘Metro’ mode disabled all plugins, including Flash Player; Microsoft said Internet Explorer in Windows 8 Metro mode “provides an add-on–free experience, so browser plugins don’t load and dependent content isn’t displayed“.

In May 2012 Microsoft changed their minds and enabled Flash in Metro mode. BUT… Microsoft will ship Flash Player as a component of IE 10 (much like Google Chrome does), and will restrict which sites are allowed to run Flash! “While any site can play Flash content in IE10 on the Windows desktop, only sites that are on the Compatibility View (CV) list can play Flash content within Metro style IE.”

In other words, if you don’t have Microsoft’s blessing, your Flash site will not work when viewed in Metro mode.

Update: @chris_sage pointed me to a post by Microsoft written just three days ago where they apparently changed their minds again — almost a year after saying they’d require a whitelist, they now say they support Flash Player by default in Metro mode without requiring sites to be whitelisted.

What it boils down to…

If you develop Flash-based content, it will be more and more of a challenge to provide a smooth, problem-free user experience. For e-learning developers, one of the original lures of Flash was the ubiquity of Flash Player; Flash made it easy to provide the same e-learning experience across browsers and platforms. Due to fragmentation in Flash support, this no longer appears possible.

Adobe says: No Flash Player for mobile devices.
Microsoft says: ~~No Flash Player on Surface tablets (or other Windows 8/RT tablets) unless the user switches to desktop mode OR gets on our whitelist for Metro mode.~~ We love us some Flash! But we’ll manage the security updates ourselves, thank-you.
Mozilla says: Only the latest edition of Flash Player for Firefox.
Apple says: No Flash Player on Apple iOS devices, and only the latest edition of Flash Player for desktop Safari.
Opera says: Flash Player on desktop editions of Opera? No problem. Flash Player in Opera Mobile? Don’t get mad at us, Adobe stopped providing Flash Player for mobile devices!
Google says: We control Flash Player for Chrome (desktop) ourselves. No worries. Flash Player in Chrome on mobile devices? Don’t get mad at us, Adobe stopped providing Flash Player for mobile devices!

The browser vendors are enforcing their will. You don’t have to be a Flash-hater to see that building Flash-dependent sites is a minefield.

For those of you in e-learning who depend almost completely on Flash-based courseware, it’s a good idea to start looking for alternatives.

March 28, 2012

Important Adobe Captivate SCORM template update

Over the last few weeks, I received a few reports that scores were not being saved in the LMS when using my template. Turned out to be a simple oversight on my part, which I have just fixed. Please download the latest version of scorm_support.js (v1.20120328) from GitHub.

Cause and effect

If you’re curious what happened, here’s a quick rundown:

When a SCORM course launches for the first time, the value of cmi.completion_status is "ab-initio". This means the course is a fresh launch with no prior completion attempts, and therefore no historical data in the LMS.

When Captivate launches, it requests a slew of information from the LMS via SCORM_API.GetValue. This includes the usual suspects, such as completion status, suspend data, location, score.raw, score.max, score.min, and score.scaled. However, if the course has never been launched before, suspend_data, location, and the score elements will all be empty (null). If the LMS follows the SCORM spec, it will throw the “element not initialized” error.

In my earlier work on the template, I decided to prevent these “element not initialized” errors by adding some logic to the template, preventing suspend_data, location, and the score elements from being checked when the course status is ab-initio. This was achieved via a regular expression:


if(entryStatus === "ab-initio" && /location|suspend_data|score/g.test(parameter)){
   //prevent action
}

Unfortunately, I overlooked one important detail: when the Captivate course loads, it queries the LMS to see which SCORM fields are supported. This is done by requesting the “._children” CMI elements. For example, cmi.score._children will return the string “scaled,min,max,raw” indicating that cmi.score.scaled, cmi.score.min, cmi.score.max, and cmi.score.raw are supported by the LMS.

See any problems yet?

My regular expression was too broad, and prevented cmi.score._children from being queried, making Captivate believe that cmi.score was not supported. Since Captivate thought cmi.score was not supported, it did the right thing and stopped sending cmi.score data to the LMS.

The solution was to make the regular expression a bit more explicit:


if(entryStatus === "ab-initio" && /location|suspend_data|score\.(raw|min|max|scaled)/g.test(parameter)){
   //prevent action
}

Instead of blocking any GetValue calls requesting “score” data when the course is ab-initio, we now only block GetValue calls that request specific CMI elements: score.raw, score.min, score.max, and score.scaled. Problem solved.

February 28, 2012

Introducing SWFRightClick

Adobe Captivate currently ships with a 3rd-party JavaScript utility named RightClick.js, which enables the Captivate SWF to detect when a user right-clicks the SWF. While upgrading the Captivate publishing templates, I realized RightClick.js wasn’t built to work with SWFObject 2.x and suffered from a few shortcomings. I modified the Captivate template’s SWFObject code to get around the issue, but marked it down as something to revisit when I have the time.

Now, I’m happy to report I’ve created a replacement for the RightClick.js utility, creatively named SWFRightClick. It uses the same approach to handling right-clicks, but does it with a completely new codebase and a few extra goodies. SWFRightClick is compatible with every edition of SWFObject, and is free to use (MIT license).

Check it out on GitHub. I plan to fold it in to my Captivate publishing templates very soon.

February 15, 2012

New SCORM 1.2 Template for Adobe Captivate

By popular demand, the SCORM 1.2 edition of my revised SCORM publishing templates for Adobe Captivate 5.x is now available on GitHub.

Instructions can be found here.

While testing the SCORM 1.2 revisions, I noticed Captivate sometimes sends invalid data to the LMS, specifically for cmi.interactions.n.correct_responses.n.pattern, cmi.interactions.n.student_response, and cmi.interactions.n.weighting. I may fix these errors in a future update, but they’re relatively harmless, so I’ll leave them be for now.

February 2, 2012

Further Tweaks to the Adobe Captivate SCORM Publishing Template

Now that my version of the Adobe Captivate publishing template for SCORM 2004 is on GitHub, it has become a living document, bound to get updates (major and minor) from time to time. For those of you unfamiliar with GitHub, it’s a nifty site for storing code; it provides issues list for tracking bugs, it enables people to leave comments or make code suggestions, and it even lets you copy an entire open-source project with a single click!

Since the code for my templates will remain on GitHub, I highly suggest checking in from time to time to see if the code has been updated. I won’t be posting a blog entry on pipwerks.com for every little edit I make to the code.

Speaking of edits, I made two or three tonight, spurred by an insightful comment from Jimmi Thøgersen. He noticed a bug or two, and explained some of Saba’s bugginess — thanks Jimmi! If you know of any oddities or bugs, please let me know by posting an issue on GitHub.

January 25, 2012

Cleaning up Adobe Captivate’s SCORM Publishing Template, Part 7: Giving the Revisions a Home

I decided to post my revised Adobe Captivate publishing template to GitHub, where it can be easily copied, forked, and updated. Currently, the only files are for the Captivate 5.0 and 5.5 templates for SCORM 2004. I hope to add SCORM 1.2 soon, as well as replacing the default ‘standard.htm’ template, which doesn’t use any LMS-related code.

Update: The SCORM 1.2 template is now available.

If you take a look at Default.htm on GitHub, you’ll notice I’ve made a few changes since I wrote my series about editing the templates. I moved a few bits of markup/code around, added some configuration options (such as the ability to turn off centering, turn on logging, and require SCORM when loading), and added a ton of comments to explain some of the new options. Hopefully it’s all self-explanatory.

I also made a small edit to manifest2004.xml, and a few edits to scorm_support.js.

To use these template files, do the following:

Make a backup of your entire publishing folder and put it somewhere safe!
Go to Captivate’s Templates\Publish\SCORM\2004\ folder and replace Default.htm with the new file.
Go to Templates\Publish\SCORM\2004\SCORM_support\ and replace scorm_support.js with the new file.
While you’re in your SCORM_support folder, delete scorm_support.htm and scorm_support.swf, they won’t be used anymore.
Go to Templates\Publish\ and replace manifest2004.xml with the new file.
While you’re still in the Templates\Publish\ folder, replace standard.js with the new file.
Restart Captivate and give it a try!

Find a bug? Think of a good edit for the template? Post a comment here, or better yet, file an issue on GitHub!

January 22, 2012

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.

January 20, 2012

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:

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.