When Rapid eLearning Isn’t Enough

I’m an avid photographer, so the digital photography revolution has made practicing my hobby easier than ever. Cameras and editing software are so affordable that anybody can jump in and start shooting. With that in mind, I’d like to introduce you to someone: Debbie Digital – the somewhat derogatory title given to the newcomers to the photography business. The stereotypical Debbie Digital buys a camera and jumps right into the photography industry to start taking pictures. Photography professionals know that the art is more than snapping a picture with a fancy camera. There are many complexities involved – for example, which shoulder should the subject turn toward the camera? Did you know that one is considered more feminine than the other? The argument against Debbie Digital is that she hasn’t taken the time to master these complexities.

But regardless of your position, the most important part of photography is the final picture. If it’s a good picture, does it really matter who took it?

The same is true for eLearning. Rapid authoring tools have made it easy for anybody to put together eLearning courses. I’ve used many rapid authoring tools and have created courses from scratch with custom code in various programming languages. Like photography, how the course is created becomes irrelevant when it results in a great eLearning, but just populating rapid authoring software with the course content is not great eLearning. Rapidly developing eLearning without taking into account things like business strategy, goals, user audience, and instructional design is akin to shooting a picture without factoring in all the subtleties of lighting, pose, etc (but I’ll save that speech for another time). Rapid authoring tools can be an appropriate solution, but they are not a one-size-fits-all solution and they ultimately have technical limitations that can negatively impact the learning in the following ways:

1. A “Template” Feel: Rapid authoring allows you to quickly create courses, but this can be at the expense of variation of interactivity and art, as increasing the variety slows down the process and defeats the purpose of “rapid” development in the first place. Courses can often look and feel very templated, which results in lower learner engagement. Engaging writing helps, but that’s only a third of the eLearning engagement puzzle.
2. Learner Locking: A very simple concept – the learner shouldn’t be able to move forward without completing the activity on the screen – yet very frustrating and time-consuming to implement in most rapid authoring software. Yes, this feature is usually bundled with quizzes, but what if I want to incorporate a custom exercise? In most rapid authoring software, I have to painstakingly add this feature in each page. When I’m custom-developing a course, I can simply use a previously created system that takes care of this functionality for me.
3. Limitation of Interactivity: Rapid authoring software contains predefined exercise templates, allowing the author to populate the templates with content. Custom exercises take more time, so the content tends to get forced into one of the predefined templates, as opposed to being married with an exercise that best supplements the learning. The interactivity should always be designed with learning in mind. Not force-fit into an existing template on account of time and programming ability of the author.
4. General Limitation of the Software: One of the best things about custom development is when someone starts a question with “Can you…” I can almost always answer “Yes!” With rapid authoring software, you’re limited to the functionalities of the software you’re using. Instead of having free rein, you can only do what that software allows you to do. The software limitations eventually changes some of the “Yes”s to “No”s
5. Lack of Total Control: When I do custom eLearning development, I have total control over what happens. I can have a user answer a multiple-choice quiz on the first screen that changes how the learner experiences a simulation on the last screen of the course. In rapid development, it’s much more difficult to have the exercises affect one another in this fashion – particularly if you’re incorporating many different elements (i.e. a captivate file, quiz, and simulation), whereas, anything I build, I can control.

So with these limitations, am I saying that we shouldn’t use rapid authoring software? Am I saying that all rapid authoring software users are the equivalent of an eLearning Debbie Digital? No. There are times when rapid authoring can be effective, but as eLearning developers, we need to acknowledge what rapid authoring is and what it isn’t – and it’s not the one-size-fits-all solution that so many seem to suggest it is.

Good photographers with good cameras can take good pictures, but only the best photographers with the best cameras can take the best pictures.