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.

Similar Posts


  1. Hi Philip, I agree with your statements entirely. It will be a welcome advancement is what you speak of comes to pass but the last few updates have been lackluster at best. There’s so much turmoil in the whole flash-related biosphere right now, with rumors, speculation, and some downright falsehoods floating around who really knows what going to happen in the next year or two. I like the platform and continue to use it and learn as much as I can, but better interactions support and more flexibility in custom scripting would be very much welcomed. I don’t know how far down the road project TinCan will become a factor for vendors, but being JSON-based, and very streamlined, I hope it’s much sooner than later…the more I learn about the API the better I like it…guess we’ll have to wait and see. Thanks for all you contribute to the e-learning development community, you ROCK!!

Comments are closed.