Many e-Learning developers have a standard approach to designing and developing content, which includes a number of base assumptions about the environment within which they’ll be working, what tools are available, and how best to use those tools. However, when a client project presents technical obstacles that make that standard approach unworkable, what other options are available? How do you develop compelling e-Learning when the deployment environment doesn’t support you technically?
I’ve recently completed a couple of projects where those questions came up, and this article reflects the results of that experience. For each of the projects I’ll outline the key requirements presented by the client, the challenges created by those requirements, and the solutions that were ultimately implemented. At the end, I’ll summarize the technical tips that can be used in other situations. Note that these two projects were designed specifically for Internet Explorer 6.0 (Windows). Many of the solutions will work with any modern browser (e.g. Opera, Firefox, Safari, Netscape 6+) but some are specific to Internet Explorer.
Project 1 — Limited technical capabilities and Internet connectivity
This project represented the combination of two common technical constraints:
- Users with dialup, intermittent, or poor Internet connectivity.
- Users with locked down desktops, where application installation and launch is tightly regulated.
Key requirements
While it’s common to see one or the other of these constraints, having to get around both simultaneously presented an uncommon challenge. Without reliable connectivity, you have to deploy the course through other means (usually CD). However, if you can’t run plug-ins or install applications from that CD, then Flash, Shockwave, and other runtime environments may not work either. The key client requirements for this project included:
- A need for the course to be highly interactive with significant use of imagery, animation and voiceover, on participant machines that had a secure desktop without Flash support, and without the ability to install new applications or run most common e-Learning executables.
- A need for tracking and reporting capabilities, including reporting back to the head office, even though the various locations only had dialup Internet connections.
Challenges
Without Flash (or the ability to install any new applications onto the machines) the course would need to be done completely in HTML and JavaScript. Delivering a suitable level of interactivity using only HTML and JavaScript presented the first challenge.
Without full time Internet connections, the best option for distribution appeared to be CD. Tracking participant progress on each local (locked down) machine and reporting back to the head office, with only dialup connectivity available presented the second challenge.
Of course, any proposed solution had to fit budget and timing constraints as well.
Solution
We developed an interactive course using HTML and JavaScript, then deployed it on CD. Cookies on the local machines handled bookmarking and tracking, and the course sent completion data to the head office via email. Here’s how we did it:
Interactivity
While Flash may be the most widely used technology for developing interactive e-Learning, HTML and JavaScript offer a reasonably well stocked toolbox for creating engaging learning experiences as well. Internet Explorer (IE), in particular, offers some very useful features, including:
- Visual filters — The wide range of filters for HTML objects includes transparency, shadows, blurs, and gradients. These greatly enhance the visual impact of content. Style sheets and script can control all of these filters, allowing easy animation and editing. You can see examples of these filters at http://msdn.microsoft.com/workshop/samples/author/dhtml/DXTidemo/DXTidemo.htm (Editor's Note: As of November 1, 2009, this article appears to have been removed from the Web.)
- Transitions — Many people have experimented with IE transitions that occur when pages load or unload. You can apply similar transitions to nearly every HTML object as well. As with filters, style sheets and script can control transitions. You can easily trigger transitions by mouseovers or clicks, and you can synchronize them with other actions. The link above also includes examples of the various transitions available.
- CSS and HTML — IE includes a number of “proposed extensions” to both HTML and CSS, so there are numerous tags and style sheet properties that aren’t available elsewhere. Some of these, such as the bgsound tag, can be very helpful when developing e-Learning. Microsoft’s HTML and DHTML Reference at http://msdn.microsoft.com/library/?url=/workshop/author/dhtml/reference/dhtml_reference_entry.asp?frame=true provides a complete list of IE tags.
With the help of those technologies, we could develop a course comprised of text, images, animation, and interactivity. We could easily create interactions such as drag-and-drops and clickable hotspots, and animated actions such as moving objects, fades, and reveals could add to the visual impact. (See Sidebar 1.)
Without Flash support, “movies” required the use of animated GIFs triggered by Javascript. On the page shown in Figure 1 in this sidebar, clicking each numbered step in the top right triggers an animated GIF to display in the middle of the page and start playing.
Here is the necessary JavaScript:
<script language=”JavaScript”>
function fadeIn(objName){
var obj = document.getElementById(objName);
obj.style.filter = “progid:DXImageTransform.Microsoft.Fade()”;
if (obj.style.visibility == “hidden”){
obj.filters.item(“DXImageTransform.Microsoft.Fade”).apply();
obj.style.visibility = “visible”;
obj.filters.item(“DXImageTransform.Microsoft.Fade”).play();
}
}
</script>
Voiceover integration also benefited from IE-specific functionality. We created individual voiceover files for each page as MP3 files. We used IE’s bgsound tag on each page as the container for the sound file. The default file for the page played automatically when the page loaded, but additional files could be triggered simply by changing the source of the bgsound object. For example:
<bgsound id=”sound” src=”t2p1.mp3”> <!— this file plays automatically —> <script language=”JavaScript”> function setSound(snd){ var s = document.getElementById(‘sound’); s.src = snd; } <script> <!— Clicking the link causes a new sound to start playing -—> <a href=”javascript:void(0);” onClick=”setSound(‘t2p1_1.mp3’)”>More info</a>
Turn off audio completely by setting the src to an empty string (e.g. src=””) or by setting volume=-10000. Create a volume controller the same way so the user can adjust the overall level.
While the bgsound object doesn’t offer any means of determining whether the sound has finished playing, you can create a JavaScript timer and set it to match the duration of the sound. For example, if the sound is 12 seconds long, a timer such as this will work:
var t = setTimeout(‘setAudioDone()’,12000);
Note that timers use milliseconds so you need to multiply the duration by 1000 to get the appropriate timer length. When the timer runs out, it triggers the function which may enable navigation buttons, show additional content, or perform any other function that needs to happen when the audio is finished.
Tracking
Tracking was tricky, but a cookie-based solution ended up working nicely. (See Figure 2.) IE (and most other browsers) allows up to 20 cookies per domain and the CD is considered a domain. So, up to 20 different participants could have bookmark and other login data stored locally at any given time. This was more than adequate since there were typically only four or five people actively going through the course. Each cookie can contain up to 4kb of data, which is plenty of space to store the login details, bookmark, and completion status, along with details of the pretest and final tests. Each cookie was a long string of data. (See Sidebar 2) The JavaScript in the course parsed this string each time the user logged in. We stored all data collected during the user’s session in variables in the course frame, and then wrote it to the cookie at the end of the session when the user exited the course. When the user completed the course, we needed a separate mechanism to submit the results to the head office. We used email for this. On the final page when users clicked the “Submit results” button, the course created an email message that included all the pertinent information in the body. See the code to generate the email in Sidebar 2. Since this was a preaddressed message, all the user had to do was click “Send.” When the user sent the message, one of two things happened:
- If the machine configuration initiated a dialup connection on demand, then the email application triggered the connection and sent the email.
- If the machine configuration did not initiate on-demand dialup, the message remained in the Outbox until the next connection. Since managers at each location used these machines to dial in to the head office regularly anyway, queued messages would be delivered at least daily.
This is an example of the cookies that track users. JavaScript parses this long string of data each time the user logs in.
fa=4,1118081284953;la=4,1118081543281;td=4,1118081406531;ms=4,100;mc=4;sr=4<
,1,67;st=4,1,100;qt=4,1,1,2;qt=4,1,2,1;tc=4,1;ts=4,1;sr=4,2,100;st=4,2,0;tc<
=4,2;ts=4,2;sr=4,3,100;st=4,3,0;tc=4,3;ts=4,3;bk=/default/csr/main/topics.h<
tm;bd=1118081552062;
This JavaScript code generates an email message containing a report of the learner’s< results on course completion:
<script language=”JavaScript”>
var mail = “mailto:datasubmit@cranialexpansion.com?subject=Results”;
mail += “&body=” + getEmailResults();
var f = document.getElementById(‘mailSubmission’);
f.action = mail;
</script>
<form id=”mailSubmission” action=”” method=””>
<input type=”submit” value=”Submit Results”>
</form>
This string of data formats the email report in a way that discourages tampering by the< learner:
data:fa=4,1118081284953;la=4,1118081543281;td=4,1118081406531;ms=100;mc=4;s
r=4,1,67;st=4,1,100;qt=4,1,1,2;qt=4,1,2,1;tc=4,1;ts=4,1;sr=4,2,100;st=4,2,0
;tc=4,2;ts=4,2;sr=4,3,100;st=4,3,0;tc=4,3;ts=4,3;bk=/default/csr/main/topics.
htm;bd=1118081552062;
Figure 2 Tracking system workflow: The tracking system stored much of the user data in an HTML frame (middle row). At key points, a cookie on the user’s machine saved the data and submitted it to the server via email after final test completion.
Either option delivered the results to the the head office within acceptable timelines.
Of course, an unsent email message is an editable document, so users could have edited their own results before sending the message. We considered this a minimal risk given the specific audience, but we further minimized the risk by formatting the message body in a user-unfriendly manner. A string such as the one shown at the end of Sidebar 2 achieved this end.
This format intimidated users enough to discourage direct manipulation, but it was easy enough for the head office staff to decipher — “look for the section that says ms=xxxx, that’s the final score.” The head office staff could then complete their part of the process and record the individual’s results.
The final tracking requirement was the ability to have store managers view results for their own locations. Here, a combination of printed certificate and online report did the trick. Any users who had completed the course could print out a certificate showing date of completion, final score, and other relevant data. For users currently in progress, we needed a report to show how many people were currently working through it, and what their status was. Since the cookies stored all of this data, we created a function that read all the cookies for the CD and collected the relevant bits of data. With that information, we could generate a simple report showing status and results for up to 20 current users. To access this report, store managers had a special login ID which redirected them to a report page showing this information.
Technical tips useful on other projects
- All modern browsers provide the ability to dynamically create content, move things around onscreen, hide/show objects, and much more. With script (including timers), all of these can be controlled by user actions and synchronized with other events.
- If the audience consists exclusively of Windows IE users, a number of additional objects, filters, and transitions greatly increases the palette of available tools and potential for “Wow” factor.
- Cookies provide a simple, powerful means of storing data on user machines — data can be stored for up to 20 different users at a time.
- Email can provide a handy mechanism for submitting results in situations where the user does not have dedicated Internet access. As long as the user has dialup connectivity of some sort, results can still be submitted to a central location on a regular basis.
Project 2 — More technical capabilities and connectivity, limited budget
The second project was actually an offshoot of the first one. In this project, we repurposed the previous course for an audience in a different region. This new audience had a very different infrastructure which led to a new set of requirements. The biggest change was the availability of fulltime Internet connections and the option to have a serverbased solution.
Key Requirements
The requirements for this project included:
- A need for highly interactive content similar to the previous project — significant use of imagery and animation, and full voiceover.
- Support for a larger number of participant locations (~300).
- Use of the available Internet connections, which were fulltime connections but very slow (Point of Sale equipment had priority and took most of the available bandwidth).
- Use of Flash where appropriate, since the client machines in this region supported plugins, although the budget and timelines did not allow for a wholesale repurposing of the course into Flash.
- Use of audio file formats other than MP3, since IT had recently implemented a “no-MP3” policy on the network.
Challenges
Given the number of locations, the availability of fulltime connections and requirements for more complex administration and reporting, we deemed a CD-based solution impractical and so we chose a server-based solution. However, the amount of content being delivered over those connections — with multiple images and voiceover on every page — presented challenges. (See Figure 3.)
Figure 3 Stills + Audio to save bandwidth. Clicking the image on the right starts the Flash movie, consisting of stills that change every few seconds with an audio track underneath. The image is actually the first frame of the movie.
Building on the foundation of the previous project, for timing and budget issues, much of the existing structure would have to be reused. In the previous project, file sizes weren’t an issue since everything ran from the CD. In this project, large images and movies would present significant delays when downloading. The “no MP3” policy meant we had to consider other formats for voiceover, and file size would be an issue here as well.
Getting all that content and media delivered over slow connections, while retaining the HTML/JavaScript foundation, was the primary challenge of this project.
Solution
The resulting course overcame these challenges in two ways. We minimized the required bandwidth through careful file manipulation and restructuring, and download activities were synchronized to maintain consistency and avoid large download bursts wherever possible. Here’s how we did it:
Minimizing bandwidth
When evaluating the required changes for this project, we discovered that there were many images in the course that were greater than 100k in size. While this wasn’t a problem for the CD version of the course, it would be a big problem for the server version. To shrink the file sizes, images with less than 256 colors were converted to GIFs, animated GIFs were converted to Flash, some images had their dimensions reduced, and some images were recompressed using a higher compression ratio.
The CD version of the course also contained a number of MPEG movies, too large to be practical to deliver over the available Internet connections. Rather than relying on file format conversions to shrink them, we created new Flash versions by grabbing still shots at regular intervals throughout the movie and matching that up with the existing soundtrack. The result was a series of movielike files where regularly changing still images supplemented audio. It wasn’t quite as powerful as the full-motion movies, but it conveyed the information well enough, with significantly less bandwidth requirement.
We also used code optimization to reduce bandwidth requirements for the Web. Webbased courses reuse many images in multiple places — navigation buttons that show up on every page, background images, etc. Each of those images may be reduced in file size, but if they’re being downloaded on every individual page, it can still slow the overall performance considerably. To minimize this duplicate downloading, we chopped the pages up such that page-specific code (e.g. the text content of the individual page) was in the page itself, and template or framework code (e.g. nav buttons, stylesheets, etc.) was in a separate, linked file. The actual course pages ended up being quite small, since there were a few dozen lines of HTML representing the page content, and five or six links to external files that provided all the things that were consistent from one page to the next.
In theory, this shouldn’t have been necessary. Most browsers will check if an object exists in the local cache before attempting to download it from the server. If the object does exist in the cache, and hasn’t been updated on the server, then it should use the cached version and avoid the download. However, during testing we discovered that even when the object existed in the local cache, the process of checking that the server didn’t have a newer version introduced delays to the download process.
Furthermore, users can configure the browser to always get the file from the server, regardless of cache status, so you can’t always rely on the cache to simplify your downloads. That uncertainty, combined with the extra hit to check the cache against the server, made it necessary to use other mechanisms to minimize the download requirements. Chopping up the files such that reused code was contained in a single external file, rather than duplicated on every content page, did the trick. Sidebar 3 shows an example of a page where the reusable code has been moved into external files. As a result, the entire template layout for that page requires only 12 lines of HTML (code in blue).
<html> <head> <script language=”JavaScript” src=”../scripts/dwFunctions.js”></script> <script language=”JavaScript” src=”../scripts/runtime.js”></script> <script language=”JavaScript” src=”../scripts/animation_runtime.js”> </script> <link rel=”stylesheet” href=”../stylesheets/styles7.css” type=”text/css”> </head> <body onclick=”top.handleOnClick();” onload=”top.superPageOnload();”> <div id=”bgArea” style=”position:absolute; width:803px; height:607px; z-index:1; left:0px; top: 0px”> <div id=”pageTitle” style=”position:absolute; z-index:7” class=”pageTitle2”> <script language=”JavaScript”>document.write(unescape(pageTitle)); </script> </div> <div id=”pageHeader” style=”position:absolute; z-index:8” class=”pageHeader”> <script language=”JavaScript”>document.write(pageHeaderString); </script> </div> <div id=”logo” style=”position:absolute; z-index: 3” class=”logo”> </div> <div id=”headerImage” style=”position:absolute; width:110px; height:69px; z-index:4; left: 11px; top: 12px” class=”headerImageStyle”> <img src=”../images/template7/default_header.gif” width=”110” height=”69”> </div> </div> <script language=”JavaScript” src=”../scripts/nav4.js”></script> <!— *************************************** CONTENT SPECIFIC TO THIS PAGE GOES HERE *************************************** —> </body> </html>
The other bandwidth-related activity to address was the file format for audio files. With IT mandating we could not use MP3s (the format used on the CD version), another format was required. With the bandwidth limitations, that format had to have compression equal to or greater than MP3, and the standard Windows audio engine had to support it. The solution was to use WMA — Windows Media Audio — files. WMAs use a compression scheme which is actually more efficient than MP3, allowing for a much smaller file size, without significant reduction in audio quality. For example, an MP3 file that was 151kb, ended up as 45.3kb when converted to WMA — that’s 30% of the original file size!
Timing activities
After minimizing the required bandwidth for individual files as much as possible, we addressed the overall download experience. As is often the case, this course had different requirements in different sections. Some modules were denser than others, with more images and longer audio files. We couldn’t have the course run smoothly for one module and then grind to a halt in another, so we needed some way to spread the downloads more consistently throughout the course. The answer was to take advantage of the lighter sections and preload content for other areas in the background. The first section where this made sense was the introductory Flash movie at the beginning of the course. Once downloaded, the movie ran for about two minutes and the browser sat idle until the movie finished. Rather than leaving it idle, we put the browser to work by configuring an off-screen frame to preload the main background and navigation images for use later in the course. Since the content pages had already been optimized to download these images once and reuse them on every page, the off-screen download completed that task without the user even noticing. When they finished the movie and moved on to the main part of the course, the default images were already there waiting.
Other places in the course where this happened included the main topics page (since it didn’t have any audio of its own) and the topic reviews (which were mostly just text and voiceover).
Keeping all of these activities synchronized involved some careful planning and coordinating. To ensure that slow downloads didn’t throw off the synchronization, timers were used to check completion status and make sure that automatic activities didn’t start prematurely. Some download activities were timed to start in the background once the basic page content had loaded.
Technical tips useful on other projects
- Images that have 256 colors or less (including most images that don’t have blurs or gradients) are likely to have a smaller file size in gif format than jpeg, and better quality.
- Flash movies comprised of still images with audio narration can offer a learning experience comparable to full motion video, with greatly reduced bandwidth requirements. better audio quality than MP3, and are much smaller.
- Segmenting HTML files and linking to external, reusable code can reduce both the file size and the bandwidth requirements for Web pages.
- When there is a lot of content to download, scheduling those downloads to take place off-screen or in the background evens out the download process and produces a more consistent experience for users.
Conclusion
Necessity truly is the mother of invention. Faced with some unique technical challenges, these two projects provided opportunities to discover and implement solutions that I might never have considered otherwise. We now routinely use many of the technical tips listed above on other projects, providing a better overall user experience even in situations where bandwidth isn’t an issue. Effective e-Learning really can be implemented when the technical environment is working against you; you just have to think creatively.
