E-learning today involves enough moving parts - instructional design, graphic design, sound design, and programming - that it can be very difficult to know everything necessary to ensure that your e-learning vendor delivers a quality product. At times, it can feel like building a new home. You end up going on faith that everything is going well until the roof starts leaking.
Making sure that the roof doesn't leak on your next e-learning project is a two-part process. First, you have to ensure that you deliver a quality course by choosing the right tool for your content, validating the effectiveness of the instructional design, and identifying any technical constraints. Then, you need to make sure that you can update it.
Choose the right tool or the content
There are a plethora of e-learning development tools. Although they all claim to be one-size-fits-all, not every tool will be equally suitable to your content. The good news is that you can often see for yourself which tool might best serve your purposes. The website for each tool usually has a demo that shows that tool's particular strengths.
Ideally your e-learning vendor should be familiar enough with each tool to be able to recommend one that is appropriate for the content and type of e-learning experience you are creating. Unfortunately, many e-learning vendors specialize in only one or two different tools that they will recommend without considering your content or instructional goals. You could end up paying too much for a high-end flash-based course when it's not necessary.
Validate that the instructional design is effective
Instructional design should facilitate learning. The following are some of the mistakes I've witnessed - or even committed - that hindered the learning experience:
- A lesson structure that doesn't reflect the job. In corporate training, we are teaching people how to do a specific aspect of their job. So why not organize content to reflect job tasks and situations rather than use a topical approach? Using the job as the basis for organization not only facilitates training transfer, but it also makes it easier for learners to reference specific information later.
- Overly long lessons. Once a lesson goes beyond about five screens of content, I believe we are treading in dangerous territory. An overly long lesson can be tedious to wade through, which increases the chance that learners' minds have begun to wander from the topic at hand. Plus, if learners will be squeezing training into their work, it makes it harder to find a stopping point that makes sense. Finally, finding specific information once the course is done can be harder than finding a needle in a haystack.
- Redundancy. This mistake usually involves the narration of on-screen text. Narration should be saved to explain diagrams. Better yet, narration can be used to present content in more interesting ways. For example, learners can click on photos of various people to hear how they are using the best practice being taught.
- A mismatch between the instructional design and the tool. Training demos are terrific examples of how to integrate content with the tool and good instructional design principles. You can and should use the demos to vet your instructional design approach.
This is also why you need to pick your tool and stick with it. We developed a storyboard for a client in the agreed-to Flash software. The client's supervisor then decided to switch to Articulate. We needed to retrofit the storyboard for Articulate before we could do any programming.
Identify any technical constraints before you begin
A few years ago, we developed a course for a client that was to be delivered via their corporate intranet. During the alpha review, the client decided that she also wanted the option of delivering the course via CD. This caused myriad problems with the security settings on her company's computer when the e-learning course attempted to run an executable file. The file worked fine when the course was run from the company's intranet, but it was impossible to run from a CD without a workaround.
There are things programmers can do up front to avoid this sort of problem if they know how you plan to deliver the course. If you wait till the eleventh hour to communicate your needs, though, you jeopardize both your schedule and your budget.
You also need to let the e-learning vendor know which version of Flash you are running and if the course has to be SCORM-compliant. Regardless of whether the course is SCORM-compliant, you should test the prototype to make sure it runs properly on your LMS. Finally, let the e-learning vendor know if you have accessibility requirements. This could include closed captioning or the ability of a text reader to read the text on the screen. If the on-screen text is in Flash, for example, text readers won't be able to read it because it is presented as a graphic.
Ensure software updates
Part two of leak-proofing the roof is making sure you can update your e-learning course by using standard programming tools, avoiding obfuscated tools, knowing when software components are used, and getting the source files.
Use standard programming tools. Some e-learning vendors develop proprietary software that speeds the programming process. The benefit for a client is a less expensive module. The drawback is that if the vendor goes bankrupt, you are left with a module you can't update.
Not only should vendors avoid using proprietary tools, but they should stick with standard tools familiar to many developers. If they use a less popular tool, you may have a hard time finding someone to make the revisions. In fact, if you can't find a developer, you may be faced with the cost of reprogramming the entire module with a standard tool just so you can update it.
Avoid obfuscated code. As defined by Wikipedia: "Obfuscated code is source or machine code that has been made difficult to understand."
One client contacted us to update a two-hour new employee orientation module. To bid the project, our programming team needed to take a look at the structure of the source code. What they found were deliberately confusing naming conventions and file structures.
Thankfully, we caught up with the original vendor before he closed his doors. In a conference call with the client on the line, the vendor admitted to creating this obfuscated code to ensure the client would be forced to hire them for any updates. Then, they coughed up the cheat sheet that unlocked the mystery of the source files. Had we contacted them a week later, the company would have vanished right along with the client's initial investment.
Request that the programmer use self-commenting code. For example, a variable name indicates what that variable does. This approach to programming will reduce the time it takes for a different programmer to figure out how the code works.
Finally, consider hiring a programmer who is not affiliated with the vendor to poke around the code when the vendor delivers the prototype. This is similar to asking your mechanic to inspect a used car you are thinking about buying. If the investment is small, it's probably not necessary. But, if the investment is large, this very small additional cost can save you potential headaches in the future.
Know when software components are used. The inclusion of software components as part of the source code is another issue that we have encountered. These components are built to take care of different types of functionality such as menu or scrollbar behavior.
In and of themselves, software components are not bad. They allow e-learning vendors to reuse code for standard types of functionality such as menus. The use of components also allows these vendors to assign lesser skilled (and less costly) programmers to assemble e-learning programs. If the vendors pass on these savings to their clients, you benefit, too.
Beware if you decide after the module has been delivered you want to change functionality. In this case, you must go back to the original vendor. We ran into trouble when at a client's request we tried to change the way the menu worked in a module that had built-in components. We could make changes to text, images, and audio, but the module's functionality was set in stone.
Get the source files
Source files are the actual programming files. They are coded using a program such as Flash or Java and then compiled to produce the final module. You receive the compiled files to install on your LMS. The problem with only having access to the compiled files is that you can't change the underlying code.
Getting the source files isn't a problem assuming you have a good relationship with the original vendor and they are still around. Unfortunately, twice in the last two years, clients asked us to update modules because the original vendor had closed its doors. As a result, our clients were faced with the costly prospect of paying for the same work again even though only minor revisions were required.
This is why it is important to make sure you ask for and get all source files associated with an e-learning project as a final deliverable. Then, store them on your server where they won't be deleted and can be easily located. Without them, updating the module may prove more costly than you expect.
Knowledge is power
Now you know how to get the most value from and protect your e-learning investment. You might want to keep these tips handy for your next e-learning project to prompt you through the discussion with the prospective vendor. Wishing you success!