I’ve often said that most e-learning design and production processes, as currently practiced, stunt creativity. There are too many people involved, roles don’t overlap enough, there’s a lot of dissociation from clients and learners…it’s all rather 20th Century and industrial.

It seems to me that if there was a tool that allowed a multi-skilled learning designer (ID) to conceive, prototype and largely deliver a final product, this might move us towards a more fluid, creative situation – and potentially a lower cost one.

That’s where rapid authoring tools come in. Using Articulate, or most other rapid tools, I can do the whole lot, from start to finish. The trouble is, these tools are – or have been until recently – too restrictive to generate anything more than the most basic interactive learning experiences. So although I can experiment, try things out with learners and clients and evolve my design as I’m building my final application, I can do so only within the tightest of constraints. 

I got a bit excited when I read what Clive Shepherd said about Adobe Captivate a few months ago. His implication, which I’m picking up from lots of sources now, is that Captivate has moved on from its previous positioning as the rapid systems trainer’s efficiency tool of choice. Apparently I can do some pretty ambitious things in Captivate now, and not just in the area of systems sims.

So a few days ago, when I had a few hours spare, I tried it out. I set out to replicate some of my favourite MCQ structures (“favourite MCQ structures” isn’t a phrase you see often…) in Captivate to see how far I could stretch it in a very short time, without getting drawn into coding, Actionscripting or similar. I wanted to see if I could use workarounds (following Tom Kulman’s lead) to produce more interesting MCQ-type interactions than Captivate has built in.

I also set myself the constraints of having to originate or source all the assets (backgrounds, photos, videos, music, voiceover etc.) in the time I had available, (between just before lunch and picking up my son from the the childminder at 4.30pm) just to see if I could, even loosely call the process “rapid”. You can see the results via the links below. It’s worth pointing out that none of this is optimized (pre-loaders, compression etc.). 

• Video-based MCQ - watch 3 videos then choose which one answers the question.
• Simple scenario - two versions of a basic scenario including alternative feedbacks, consequences etc.; the second one also has rollover resources to help the learner make decisions.
• "Are you sure" MCQ - answer a question; before reading feedback, you're prompted to have a re-think; then you get feedback/consequences

Captivate clearly isn’t my dream tool yet. But I’m happy now that I could produce, in a few hours, with help from a graphic artist, what I’ve often been told could take days, and involve developers, project mangers and so on. 

Getting back to the main point, I’m convinced that using a tool like this, I can offer better value to clients and learners, because I’ll not get tied up in over-complex development processes and lose sight of why I’m doing what I’m doing. I’ll offer more creative solutions because I’m in control of the whole thing, while not being overly constrained, as I am when I use more basic rapid tools. 

A tool like this is – potentially – the basis for very different development processes; processes that can professionalise our industry and offer far better value to clients. NOT because they’re cheaper and quicker, but because they produce better results.

Although these samples are very rough, they taught me some important things:

• All interactions are trackable and scorable, so they could be assembled into a scored scenario, or sequence of scored events. I don’t need to use Captivate’s built in quiz mechanisms, which look a bit crude. So I can build courses, scenarios, games even that have scored and un-scored sequences interchangeably. When I’ve asked this of developers, they’ve tended to suck in their teeth and reach for their code books…
• I can add pretty decent accessibility features very quickly.
• I don’t have to use Actionscript at all, just a few slightly clumsy workarounds. This is important because various sources (including Kineo) have pointed out that Captivate’s Actionscript implementation isn't perfect.
• Now I’ve done these, I could professionalise them in a couple of hours and customize or re-skin them in minutes. That’s rapid enough for me.

This approach – pushing a rapid tool to do things it’s not entirely comfortable with – clearly has its limitations. There are all sorts of things I can’t do: video-driven multi-select MCQs, ratings, decent-looking drag and drops, and so on…But if Adobe could fill in the gaps a bit, improve on the SCORM functionality, and support the product better, I’m sure they’d find a ready market. 

And we could all stop driving poor old e-learners nuts by offering them such dull rubbish. 

PS – having re-read this posting, parts of it read like an advert for Captivate. I promise you it isn’t. I don’t care what tool I use, as long as it does what I need it to do.