On Authoring Tools…

There’s been some fantastic writing of late in the realm of digital learning, education and training. I don’t know if I know about it more because the tools for sharing via RSS are more ubiquitous or there are just more people writing about it — but the point is that ten years ago, this was a professional field that didn’t even exist as its own discipline (but for the Authorware folks) and now we have hundreds of bloggers building up the calluses in their fingertips as they blog away about this domain, and that’s wonderful for everyone involved.

There are a couple of peers blogging who are fairly regular readers (and when the [FFL discussion list](http://groups.google.com/group/flashforlearning) is active, they also chime in), so I make it a point to follow what they do. One of those guys is Philip Hutchinson who I think writes very well in all things meta concerning E-Learning. Philip’s most recent post to [Pipwerks](http://pipwerks.com/) is [his take on choosing authoring tools for E-Learning](http://pipwerks.com/journal/2008/01/20/how-i-build-my-elearning-courses/), and I can’t find a single thing I disagree with in his post.

> Most eLearning tools do not promote the creation of effective courses, do not promote web standards, and do not promote accessibility; they merely make cookie-cutter course development easier for technically inexperienced course developers.

I agree. Most of the authoring tools I’ve seen port right to Flash. I love Flash. It’s done me and my family well for many years now. But it’s not the most open of formats. It’s also not the most flexible of formats. It’s just about impossible to do anything with the published Flash content that any of the popular E-Learning tools on the market. And if you ever want to talk about [reusability](http://flashforlearning.com/2008/01/16/redefining-reusability/), there’s just about no easy-bake oven method available to make published Flash content look like something other than what it was published as unless you know a lot about the underlying code in the compiled file. Sure, the textual content of tools like Articulate is all extracted into XML, and theoretically you could use that XML as a basis to reformat content in a different medium, but again that work is highly prohibitive — as are any of the alternatives that actually work with web standards (at least the ones that might be released in the market today).

Philip writes more…

> …not being tied to a particular tool or proprietary format means that practically anyone with general web development experience will be able to make edits to your course or even create new courses using your system. Millions of people around the world work with HTML, and hundreds of thousands work with JavaScript. I’m willing to bet that the number of people familiar with proprietary eLearning development tools is much smaller, probably numbering in the thousands. It’s a niche.

Okay, here’s where we part ways a little bit, I guess. Philip is absolutely correct that the shear number of “web developers” of which “E-Leanring developers” might be a subset in that they mingle in some of the same technologies is about, maybe, a 10,000:1 ratio. I’m not disputing that working with web standards wouldn’t significantly improve the likelihood of making revisions and edits faster and cheaper, let alone the opportunities for re-use.

I’d argue, though, that one of the reasons why authoring tools like Articulate, Captivate, Raptivity, Lectora, FlashForm, Adobe Presenter (we can go on) are so popular is specifically because, as Philip also writes…

> …They’re geared towards users with little or no development expertise. Yes, they’re geared towards the PowerPoint crowd.

Couple that fact that learning, education and training budgets are smaller than just about every other department, at least in corporate America — and that’s if budgets for training even exist, and the likelihood of attracting and maintaining (or even contracting) qualified talent to work with tools from scratch make it prohibitive to work with what I call low-level authoring tools like Flash (as a tool) or Dreamweaver (as a tool) or even Textpad to produce standards-compliant HTML, CSS and JavaScript.

The trick is that these people will use a great authoring tool if it’s easy to use, and the use of any authoring tool is likely to be a trap in and of itself, because the designers and the engineers of a tool have their own assumptions about the nuances like class and id names in CSS — it’s still going to be difficult to translate this into reuse. And if you’re not talking about reusability, now that you’re going with CSS and JavaScript, you now have to contend with possibly making sure it presents and functions correctly across browsers, which was one of the biggest strengths for Flash-based platforms from jump.

And we’re still talking about single authors using tools, which works great if you’re a one-person army building E-Learning. But I know on my team, we’re already running into some pretty glaring issues of source portability with tools like Articulate, where we want to collaborate and have multiple people authoring — but have issues of losing our audio or embedded media paths, versioning, etc. If we want to discuss collaborative authoring, none of your big, popular authoring tools really cut the mustard (though I’m curious what Adobe and maybe Articulate has cooking in this regard).

So What’s the Answer?

Well, there is no one right answer at the moment for weening off the PowerPoint-to-Flash model, but I’ve heard about some interesting things from [Eduworks](http://eduworks.com/). Robby Robson has been heavily involved with standards organizations from before I got into E-Learning and has brought up some interesting ideas in conversations over the last year that make me think they’re thinking about solutions for standards-based content development in the E-Learning realm.

There’s also a nifty open-source project called [eXe](http://exelearning.org/) that amazingly runs on both Mac, Linux and Windows, and purports to publish content as standards-compliant HTML, CSS and JavaScript. I don’t know if I’d say it’s ready for primetime, but it’s promising that there’s an open source tool that runs on all platforms and may get to being as user-friendly as any other given authoring tool.

My point is that Philip is absolutely correct that if we keep using the same authoring tools, we’re going to eventually be limited by design implications inherent in the technical constraints of the tools that we choose to use. The more flexible a tool is, the greater skill is needed to wield it.

But no matter what, to get to making it easier to edit or adapt learning content, we need to get out of published Flash to do that — and, oh by the way, we need to make the experience collaborative to take advantage of efficiencies that can be gained by having multiple contributors to projects and integrating QA into the workflow.

As Philip suggests, moving towards web standards should make all this much easier to do, but it will be the authoring tool, and not the technologies themselves, that will get corporate learning, education and training to jump to it.

10 replies on “On Authoring Tools…”