Computer Based Training Packages (CBTs)

When your CBT project turns into a nightmare you find yourself asking questions like "What does my client REALLY want?", "Why do they want all this flashy stuff?" and "What is a good CBT anyway?"

First, a CBT can serve two purposes. It can be a showcase for marketing your business or it can be just a computer based training package. For a CBT to work as a training, it does not need the "flashy stuff" at all. It is enough to have a logical flow of content material, examples, review questions etc. But for marketing purposes, you have to be COOL and not just useful.

Creating cool and useless stuff takes at least as much time and energy as creating boring and useful stuff. Targeting only for the "cool stuff" generally makes the "useful stuff" harder to achieve and vice versa. Add in the business realities and you end up making some trade-off between these requirements.

In the world of CBTs, useful stuff is pretty much canonized in the SCORM specifications. You have reusable packages with a standard API, system-wide navigation controls and otherwise similar user iterfaces. So, given the popularity of SCORM compliant LMSs in large enterprises, you would expect to see a lot of small SCOs combined in a nice content structure specified in the SCORM manifest. Navigation in this structure would be handled by the LMS so the user interfaces would be pretty much the same overall [1]. Only downside would be that different SCOs would look different based on their original context. I mean, hey, you can't just add someone elses HTML and expect it to look right with your CSS.

Perhaps the aviation and army people didn't see this as a major issue. They could always pass some new regulations to standardize their CSS classes anyway. Unfortunately, this is not the case in the enterprise. Basically, every eLearning package that I have seen looks the same. A monolithic presentation with its own navigation and structure elements, usually delivered in a single pop-up window. Content is sometimes Flash, sometimes DHTML. SCORM is required only to pass the scores to the LMS. But the outlook of each "one-window-slideshow" is consistent, clean and usually designed by a graphical desig professional. This is what businesses want.

I don't know how to fix this situation. But I do know, that if you get a SCORM project, don't expect it to be very technical in the SCORM/JavaScript side. Your client probably wants only to pass a handful of scoring data to the LMS. Bulk of the work is going to be spent like in any other media project. You need a SCORM-capable platform, one programmer who handles the platform and one graphical designer who handles the visuals.


[1] The people behind the SCORM standard actually made it really hard to implement navigation inside a single SCO without braking the whole thing