It cost a lot of money to build CBT ten years ago, when I started in what was to become the e-Learning industry. $50,000 an hour was the standard metric, and from there you would modify the cost based on factors such as the amount of video, quality of video, flexibility of navigation, tracking requirements, and number and complexity of interactions.
Today, the standard cost is under $25,000, and that includes in-depth instructional design, complex interactions, non-linear navigation, and lots of high-quality media. Ten years from now it will probably be closer to $10,000 for the same course, with better quality media and more complex interactions, navigation, and tracking.
So, what has changed in ten years?
Hardware has changed. I’m sure we could chalk technology advancements up for a large chunk of the cost savings. At the front end, thanks to better quality equipment at lower prices, everything a cash-strapped multimedia shop or department needs is easily within their reach.
During production, tasks that used to take days now take hours. I remember three people spending half a day, running a full lab of computers non-stop to process the audio files for an hour-long course. Today, that same task takes a high school co-op student an hour on a single PC. One can now do, over lunch, 3D animations that used to render overnight, and compiling that 30-second video clip is something you do while you get a cup of coffee.
Of course the time savings don’t stop there. Because the client has access to better hardware, we don’t have to worry as much about using higher bit depths or complex compression algorithms. We can also design for 800x600 or 1024x768 resolutions, and know our audience won’t need the latest technology (or a magnifying glass) to use our courseware.
Software has changed too. Better hardware has contributed to putting more powerful development tools into our hands. Ten years ago we could send text, pictures, and audio over a phone line. Now you say you want a 3D multi-user environment delivered in a browser? Hey, no problem. The hardware limitations no longer hold the software back.
Another major driver of progress has been a convergence of custom tools and modern programming languages and methodologies. It used to be that custom scripting languages were designed around a limited feature set the designers thought was important. While that is still somewhat true, they base the majority of products today on standardized scripting languages such as ECMAScript (JavaScript), which allow greater flexibility and portability, due to their more generic nature, as well as an easier transition for traditional programmers.
We — the producers — have changed. Yes, we too have evolved along with the software and hardware. As an industry we are more interested in defining standards, re-using content, and generally being efficient in our work. We’ve also taken the advancements in our tools and leveraged them to create more with less. Some of this leverage has come from applying principles of software engineering and design to our courses and the engines that drive them.
SOFTWARE ENGINEERING AND E-LEARNING
“Software Engineering and e-Learning” could have been the title of this chapter, but it lacked the buzzword appeal. It could also have deflected the attention of anyone who isn’t a software engineer. Rest assured software engineers are not the target audience.
Now that I’ve allayed your fears, let’s talk about software engineering. Take almost any application out there and you can divide it into three components. There is the interface, which is the toolbars you see above the application and the window that contains it. There is the data, which is the content itself, text, graphics, hyperlinks, and so on. And there is the logic: the component responsible for intelligently sharing data between the two.
If you were to open a software engineering textbook, you might find a diagram that looks like Figure 14.1
Figure 14.1 Three-tier architechture
Now, let’s talk about your static HTML e-Learning course. Are all of those three-tier components identifiable? Sure they are. We still have navigation buttons, content, and communication between the two. The problem is that all of the layers are in the same place.
Figure 14.2 -Three tiers in one
The basic course
Assuming the most basic HTML course, we have:
- Statically linked pages. (Each individual page holds information pointing to next and previous pages.)
- Replicated interface. (A copy of the code for the global navigation and graphical layout is included on every page.
- Static layout. (One must place every element on the page manually including text, graphics, interactions, and navigation elements.)
- Duplication of content. (The content in the story-board does not tie, in an automated way, to the contents of the course.)
This course is not easy to create. We must copy every page from the storyboard. The programmer must make layout decisions, screen by screen. We must update the navigation links on every page and thoroughly test each one when the course is finished. We must create interactions from scratch or copy them from existing code and then customize them.
This course is not easy for the subject matter expert or instructional designer to update. Both the storyboard and the course require updates. Alternatively, we may throw the storyboard out once we have created the course, and it is then more difficult for reviewers to provide feedback on the course contents.
This course is not easy to update for the programmer. Adding or moving a page means updating the links on the next and previous pages as well. Changing global controls or adding new features requires, at best, a complicated search-and-replace operation, and at worst it requires manually editing each page.
This content is not reusable. If someone were building a different course and wanted to re-use a module, they would have to replace all of the hard-coded navigation and modify the layout in every page to match the look and feel of the new course. If the layout in the new course is different, and the content needs to be re-arranged, then you basically must create each page from scratch.
Beyond the basics
There is a lot one needs to do to turn this course into a full three-tier application, probably more than the average developer has time to even think about. Luckily, we can build up the final application over a number of courses by working in stages. This approach costs more in terms of overall work, since you don’t have the easy development environment up front, and you will probably also want to go back to early courses and update them once your engine is complete. On the positive side, time-to-market is better; since you don’t have to wait to build the engine you can keep the whole team busy, and you can spread the engine development cost over multiple courses.
