TEMPLATES
A template is the separation of content and design elements. A cookie cutter is an example of a template. The cutter is the design element and the cookie dough is the content. With regard to an e-Learning course, a template can mean many different things and you can apply it on many different levels.
Background and positioning templates
When moving from a static course, the first step, and probably the biggest up-front time-saver, is the “background and positioning” template. This means taking everything around your content and making sure there is a single copy of it. The simplest way to do this in an HTML course is to take a page, cut everything above the content, and paste it into a separate header file; then do the same with everything below the content for the footer. Now your content is in a file all to itself, and can reference the header and footer files. Changes made to the header and footer files affect the course globally. This is now a two-tier application; since you have separated the data (content) from the interface and logic.
Figure 14.3 - HTML course with top and bottom visibly partitioned
Data as data
This is all fine, but there is still a significant amount of hard-coded information, dictating how the data should be displayed, stored in the page. The simple solution is to use styles with your content. This way, you can change the styles if you need to change layout, size, or color in the course. Unfortunately, this still doesn’t give you full control, and it really only works well in HTML anyway.
The ideal solution is to completely abstract your data from all layout information. This is probably best and easiest to do in XML, but any data structure will work. The important thing is that you present the data as unbiased data. Metadata then provides context, which the engine interprets to decide where the text, images, and video go. Now if a particular client wants the picture at the top left of the page, video at the top right, and rubber duckies for bullet points you can say, “OK, but it’s going to take me at least 15 minutes to reformat all of our courses!”
You can find a simple example of this in PowerPoint. You can change the background as well as the look and feel of the content by applying a new design template to your presentation. PowerPoint doesn’t store, “Here is a block of “Green 16 point Arial” text which says “Hello World.” PowerPoint stores “text ‘Hello World’ with ‘heading 1 format’” and separately stores “style ‘heading 1’ is ‘Green 16 point Arial’.”
Interaction templates
Another useful place to use templates is in interactions. One of the features introduced in Authorware 3 was the concept of models. A model allowed you to pre-build a component and then place it wherever and whenever you liked. Of course this was basically copy-and-paste without the effort of finding and copying your example component, but it quickly brought to light the power of a template approach. You put in effort up-front to create a perfect working example of an interaction and then you didn’t have to build it every time you needed it. The emphasis on “perfect” is because although I could create an interaction from scratch in not much more time than it took to customize the pasted version, oddly enough, the interactions customized from the “model” rarely had errors or omissions. Interactions built from scratch were much more likely to come back to me for rework.
A few years later, Authorware added a much more powerful feature called Knowledge Objects. These allowed you to not only paste a model, but to control the contents of the model through a step-by-step wizard interface. Now standard interactions were error free all the time and course creators never even saw the code behind them. The drawback was that creating the knowledge object was much more complicated than creating and manually editing the model.
There is another drawback to both approaches. The logic, interface, and data are all stored in the interaction. When the requirement came in for all multiple-choice questions to respond to keyboard shortcuts, you had to program in that functionality manually for each interaction. To avoid such problems, we again turn to the two-tier approach. Abstract the generation of the interaction to a global function, and not only can you modify the way every interaction in the course works with a single change, but you don’t have to do more than cut and paste the interaction content to create it in the first place.
Communication templates (APIs)
Another obvious “template” in the e-Learning world would be the SCORM or AICC APIs. This is a communication template between course content and a LMS. Communication templates are what enable a three-tier approach.
I mentioned SCORM. It is hard not to at least bring it up these days when the subject is e-Learning. My advice, contrary to popular opinion, would be to ignore it. Instead, I recommend being flexible.
Now I’m coming at this from the perspective of a custom content and off-the-shelf e-Learning developer, so being flexible in terms of interoperability is very important for me. Why don’t I use SCORM? Because none of my clients do! Of all the government, educational, and business clients, from small business to huge multi-nationals, I’ve only run into two that could actually accept SCORM content, and they both wanted hosted content instead, so they didn’t have to deal with the process required to get a course into their centralized LMS.
In the multi-cultural world of today’s LMS market, one system requires post data to a hidden frame, the next uses a parameterized image load, and a third uses one of the AICC methods or some form of SCORM. In order to be flexible, you can’t build the communication into your pages; it has to be a global function. The particular data your pages communicate has to go through your own API into your engine, which then knows how to deal with the particular environment it is running in. In my Flash delivery engine, a configuration XML file is included with the engine files. Changing one setting in this file is all that is required to get a new course running in an existing client’s LMS or delivery environment. Yes, that comes in handy.
Now that’s not to say that the work done by the AICC and the ADL initiative in building their standards should go to waste just because your client doesn’t use their standards. There is nothing wrong with the data models and communication methods used. Using those same data models in your own engine will make adding SCORM and AICC support down the road that much easier.
“Cookie cutter” courseware
I am sure some of you didn’t care for my cookie cutter analogy. We are building engaging learning material, something that challenges people and makes them think. A cookie cutter is the last thing we want to compare our courseware to. In order to avoid the repetitious feeling of the cookie cutter course, you don’t need to make every screen different, you just have to be able to mix things up and stay open to new ideas. Solution: Use multiple background and layout templates. I generally use a layout or two for video, a few for pictures and animations, one for un-scored questions and interactions, and maybe one for scored questions if they are mixed into the course. Your particular requirements are likely different, but the best approach I’ve found is to start with the few obvious requirements, then look for opportunities to create new layout templates as you encounter different types of content or an excess of similar content that needs to be broken up visually.
The other important aspect, which I consider a must, is to allow static content. There are some things you just don’t template, like subject-specific games or extremely complicated interactions. One of the early courses I worked on had a “Click on the next joint to solder” interaction. There was no specific order, simply a rule that you didn’t solder two adjacent joints and risk excessive heat buildup. If the last two joints were side-by-side, you had to wait two seconds before soldering the second one. I’ve never come across a similar interaction. If I were using my template system and I didn’t allow static content, then that interaction, which to this day is one of my favorites, would have been written off and a multiple choice question would have taken its place. One of your options should always be to include a file instead of building a page. The extra hassle when converting your course or moving platforms is worth providing creative freedom for your instructional designers.
Another tier?
All this talk about software engineering and three-tier applications and I’ve only talked about splitting the content out. The next step, splitting the interface and business logic, is actually fairly easy at this point. Move the logic. Right now in our two-tier courseware, when you click on the forward arrow it knows where to go and takes you there. To make this a three-tier application, make the forward arrow ask the engine to move forward. Want to know if you need to disable the forward arrow because we are at the last page? Get the engine to tell the forward arrow when it should be enabled.
Separating this functionality out creates a number of opportunities for us as developers. For starters, we have no longer specifically tied the development of the engine to the interface. We can send the interface to the graphics department for updates without worrying about them breaking something, and we can continue to work on the engine while modifying the interface.
The astute among you may have noticed a conundrum with separating interface and logic in interactions. Generating an interaction on the page is half look-and-feel and half logic. So where does the code go? Well, you do have the option of trying to separate the logic half from the display half, but this may be more effort than it is worth. In Flash, I put the generation on the display side, since different displays will use different font sizes, and so on. In an HTML environment, I would put the generation on the engine side and use CSS to control the layout from the design side.
The trade-off is up-front complexity versus time saved down the road, and this isn’t the only place you’ll find this kind of issue. The solution is to make an educated guess as to which is more overall effort. If you aren’t sure, implement it the easy way and decide later if it would be better to put in the extra time. Another alternative is modularizing your components further. For instance, you can make the interaction generator a modular part of your interface. This way you would only update it when a particular interface was wildly different than another, and you could simply drop upgrades into existing courses, instead of upgrading every interface separately.
REUSABILITY
We know the benefits of templates in terms of development effort and down-the-road updates, but reusability is where the real, but sometimes less obvious, benefits are to be seen.
”Skinning”
Everyone loves the personal touch. Jill’s Big Digging Machines Ltd. wants a course on soil types and you already have one you wrote for Joe’s Flower Hut. Fantastic! This is how you make money! The problem is, Joe wanted a flowery look. Jill, on the other hand, probably doesn’t. The advantage of having your logic separate from your interface means they can both get what they want, and you have to make only one course, maintain one engine, and build them each their own interface, or “skin.” If you upgrade the engine later on, you can pass that upgrade on without having to worry about re-doing each interface.
The concept of skinning has wide reach. In many entertainment applications “skins,” applied on a user-by-user basis, can make the interface more appealing to the individual. There’s no reason one can’t do this in e-Learning, and although I haven’t implemented it myself yet, I’ve certainly heard it requested.
Interoperability
One of the mandates of the ADL initiative is interoperability. Vast repositories of content are being created from which one can simply “pluck” a learning object (LO) here and a LO there and create a finished course. Of course, in reality, it doesn’t really work that way. Each learning object has its own color scheme, keyboard shortcuts, levels of accessibility, optimal screen size, fonts, point sizes, and so on. Put a bunch of objects from different vendors together and it is definitely a learning “experience.”
Our three-tier content abstraction helps immensely in this area. If someone has your collection of learning objects and wants to use them in their course, they first edit your interface component to match their existing course. After that, the engine instantly formats any object they pull in the way they want. Think about it, that’s pretty cool!
FUTURE-PROOFING
Future-proofing and reusability are basically the same thing. It’s great when you can reuse stuff next week, but when you can use it 10 years from now, it’s even better.
Accessibility
This is a current issue for lots of us, but it could also be a future issue for a course where you did not think it would be required. My company had to turn down a contract years ago because our course on visual inspection of solder joints wasn’t fully accessible to the blind — you just never know. Even if your content is accessible now, standards evolve. With abstracted data you have full control over the accessible components of your course. A single change to bring all of your courses up to the latest standards is a powerful thing
The future is “m”
M-Learning is the next big thing, or at least that’s what I’ve heard. I’m not ready to buy that line quite yet, because I despise low-resolution displays and am rarely five meters from my computer anyway. Then again, I’m probably not the target market. The point is that m-Learning could be in your courseware's future. If you separate the engine and interface from your course content, then your entire library of courses could be available on a PDA near you with a lot less work than you might think.
Expert systems and intelligent tutors
What I consider to be the future of e-Learning, and this may just be the geek in me, is not the delivery platform, but the underlying method that provides the right information at the right time. Expert systems and intelligent tutoring systems do just that, but they are complicated pieces of technology and require a lot of invested time and information before they are able to function properly. What they need is data, and at some point one source of that data could be existing courseware. Having the data separated from the content makes it much easier for the system to extract it. Having contextual information with the data may make it easier for the system to understand it. This also brings to light the importance of metadata. Think about what you might want to know about the content if you were peering at it from a distance or trying to place it in a larger hierarchy of knowledge. This will immediately help people with content reuse in a repository environment, but may also eventually help computers to understand your content as well. This is once again an excellent place to look to the SCORM for inspiration.
RETURN ON INVESTMENT AND RAPID E-LEARNING
Thus far, I’ve said nothing about doing things fast; it has all been about consuming time before course development even begins in order to eventually save time after the course is finished. The biggest business driver is what generates the most money right now.
Return on investment
Everything I’ve described in this chapter should take your average programmer about one to one-and-a-half months after all of the feature creep, de-bugging, and so on, is finished. That’s probably a week of design, two weeks of programming, and one to three weeks of working out the bugs and adding features. That’s effort, not elapsed time. Figure out what that costs you.
Now figure that it takes almost zero programming time to create every standard course you develop from now on.
How long until you save money?
Now that’s a rather quick and exaggerated example, but the point is that you have to consider the aggregate cost savings and benefits. Not only are you spending less time creating a course, but your experienced developers are now free to concentrate their efforts on more elaborate interactions or more complicated and lucrative contracts. The process of putting the course together can now be delegated to junior developers or, if you can find good ones, trained monkeys.
If you want to skip the course creation altogether, you can work in a system that exports to a viable XML format and simply drop that in the directory and call it a course. This is what Doug Wallace and Anthony Levinson were talking about in Chapter 5.
Rapid e-Learning
Scripting a course, putting some media with it, and sending it off to the client: that is my definition of rapid e-Learning. No programming, no extensive QA, nothing else required. Everything that PowerPoint can offer you in terms of speed, and most of what custom development can offer you in terms of creative flexibility and interactivity — all of this directly in the hands of the instructional designer, who knows that when time is of the essence he is limited only by what he has done before.
Fast, cheap, and good — on the technology side, we can deliver!
Existing tools
I am not aware of a single integrated tool which does all I just described, but collectively at least 85% of it is implemented and available for purchase as a number of separate components. I have run into at least one e-Learning IDE (Integrated Development Environment), which exports XML as well as providing e-Learning-specific workflow tools, course previews, and issue tracking capabilities. Couple that with a delivery environment that runs off XML, of which I know of at least one available and inexpensive option, and you are off and running. The tradeoff of third-party tools is complexity versus required features and future customizability, but they generally get you up and running cheaper and cost less to maintain than a homegrown solution.
DRAWBACKS
Yes, there are drawbacks to this approach; however I wouldn’t be writing this chapter if I didn’t think the benefits outweighed them.
LMS compatibility
Your courses will work in everyone’s LMS, but they will not always work as well as you would like.
One of the original requirements of our off-the-shelf courses was for trainees to interact with the course when hidden content was available through the interaction. This means you must disable the forward arrow until they have completed the activity. This is not a standard function in every LMS, and in some implementations it isn’t possible to meet this requirement because the LMS provides the navigation and you don’t have the option to change that.
Another issue, this one with an LCMS, was that because the LCMS provided the navigation, you had to provide a separate entry point for each page of your content. Passing a different page variable to the same main file was not an option because the LCMS wanted you to browse for the HTML, Flash, or document file. To make matters worse, the LCMS stored every LO in a separate folder, no matter how you wanted your course structured. This meant you had to replicate the engine and content for every objective in the course. This worked, but now if you wanted to change the look of the course you still needed to copy the interface for every single LO. This was actually partially a limitation imposed because the SCORM didn’t allow for a shared file dependency between LOs, or at least didn’t require implementation of it.
As a general rule, your content will work best in your own delivery engine and will lose some functionality on other engines. Portability of client-side technologies like JavaScript and Flash will also generally be easier than server side technologies like .NET. For this reason I built my main delivery engine entirely in Flash, but you may have constraints that force you to take a non-plug-in route.
Complexity and true abstraction
I mentioned the difficulty of building your interaction generator since it has components of both logic and display. Unfortunately, the more you add to your engine, the more complex it gets, the more issues you run into, and the more compromises you have to make. That is life in the software development world, but for a pure multimedia shop, it may become more complex than your developers can easily deal with. Two viable options for solving this, if you don’t have the expertise in-house, are outsourcing development or using off-the-shelf tools. Adherence to object-oriented (OO) principles and a formalized event model are a must for complex intercommunications.
Cost
Money is an issue. Time is an issue. Implementing a template-based delivery engine will cost you both, whether you develop it in-house or use third-party tools. Slowly working towards this goal may be more attainable than building it all in one pass, and will allow you to put the time savings from the first steps toward taking the next ones.
CONCLUSION
An industrial designer once told me that the job of the engineer was to always document your job function so you will be easy to replace, and continually automate and simplify your job function until you are no longer necessary. The automation and simplification of standard page-based e-Learning almost completely removes the need for programming support during course development. This frees your programming resources for more useful tasks, such as porting your courses to a mobile platform, building more advanced tools, or creating workflow enhancements to support your processes in other areas.
I have only covered one part of the development process here. Ten years ago programming was probably only a third of our development cost, and that ratio has steadily decreased as the developers became more proficient and we built up a number of pre-programmed components. One could certainly argue that the week it takes to turn a storyboard into a course (without the fancy delivery engine) is insignificant compared to the three weeks or more it takes to research, consult, design, and review the storyboard or, depending on the course, the many weeks it may take to create the graphical elements. While the technical side is certainly the easy part of the average course, it is also the low hanging fruit. We can probably gain in other areas as well, and I hope that others who read this chapter will tackle these difficult subjects.
