E-Learning 1.0
Managing the E in E-Learning
By Eli Munzer
The most sophisticated and instructionally sound e-learning course can fail if its design isn't technically sound or if the LMS launching it can't predict and resolve technical stumbling blocks. Learners expecting a trouble-free learning environment can get discouraged when faced with technical difficulties--and may not come back. Here are descriptions of the most common problems and how to solve them.
The two most common technical issues that discourage e-learners are low bandwidth and incorrect configurations. We'll tackle each of those issues separately.
Bandwidth: the apartment water pipe
Network bandwidth is the amount of data that can travel between points A and B in a specified time period. In the case of e-learning that's supported by an LMS, bandwidth is the amount of data that can travel between the learner's PC and the LMS at a given point in time. Bandwidth can be measured in KBps, which stands for kilobytes per second (one thousand bytes per second).
The bandwidth in a network is always changing--it depends on the total available bandwidth and the number of users at the time. Think of bandwidth as a water pipe in an apartment complex. The pipe, under ideal conditions, can deliver x number of gallons per second. Everyone in the apartment building shares the same water pipe, though, so if everyone turns on the water at the same time, the water flow rate drops to x number of gallons per second divided by the number of users.
All online courses have a minimum bandwidth requirement, which can be calculated based on the data transfer rate and the size of each page in the course. I use two seconds as a fair wait time. So, if you know that your transfer rate is 50 KBps, for example, you can have a combined data size requirement of 100 KB for the page, adding together the data size of all the course elements--images, audio, text, and applications (like Flash) that will launch in that particular page of your course.
A course packed with full motion video and audio will require much more bandwidth than a course made up of mostly text and still images. And, the more you add to your course, the longer it will take to load, resulting in the course being deemed "broken" by its audience.
Imagine assigning all employees in a building an online course and having them start using it at about the same time. The bandwidth is shared among all employees in that building, and as soon as the transfer rate drops below the tolerable level for the course, the helpdesk phone lines start to light up. The helpdesk is then overwhelmed, and wait times increase. The result? A very unhappy group of e-learners.
Once learners are discouraged by a course, they may never come back. Remember, your end users generally don't know what the source of the problem is. To them, the course is at fault.
The many sides of configuration
Bandwidth is the primary frustration e-learners face, but incorrect browser and PC settings are the second most common cause of e-learner defection. Most online courses are quite sophisticated. Their system requirements are generally well beyond the requirements of the average Webpage. Many use Java, JavaScript, and browser plug-ins; and most require a certain screen resolution and color depth. We'll look at those one by one.
Java and JavaScript. Many courses use Java and JavaScript, programming languages that require an application to translate the code on the learner's workstation so that the instructions can be followed by the PC. Trying to read that information without the translator is similar to trying to open a Webpage when you don't have a Web browser. When you open the page in a text editor, all you'll see is the code in the page, not the page itself. It takes a Web browser to translate the instructions into what you see on the screen.
The application that Java requires on the workstation is Java Virtual Machine (JVM). The good news is that JVM is usually included in the Web browser installation. The bad news is that the JVM version may be outdated and cause all sorts of mysterious errors that are difficult to track.
JavaScript is included in the browser installation also and, like Java, has different versions and types. Microsoft and Netscape both have their own versions of JavaScript. Furthermore, a course using Microsoft's JavaScript version 1.2 will misbehave when launched from a browser that supports only version 1.1. The errors generated by mismatched versions are elusive and difficult to troubleshoot.
Neither Java nor JavaScript will generate error messages in English to explain to users what's going wrong. As a result, learners will call the helpdesk with vague descriptions of the problems they're experiencing. For example, "Nothing happens when I click on the Next button." Tracking down the root cause can be difficult, and the problem often goes unresolved for some time.
Plug-ins. The most common of these add-ons to the Web browser are Macromedia's Flash Player and Microsoft's Media Player. When a course contains audio, video, or rich simulations that the Web browser isn't programmed to handle, plug-ins step in to deliver the media. If a course is programmed properly, it will usually recognize when the necessary plug-in is missing and ask the user to visit the vendor's Website to download and install the proper software. But this type of programming, in my experience, is the exception rather than the rule.
Including the code to find and install a plug-in is not the ideal solution either. Even if learners follow instructions and go to the vendor site to install the required plug-in, they're still forced to leave the course and may have to restart their computer to install the plug-in. They may improperly exit the course, losing course bookmarks and causing tracking problems. Worse yet, they may not come back to finish the course.
Screen resolution. The number of pixels (dots) that make up the viewing space on a computer monitor is what we call resolution. Common screen resolutions include 640x480, 800x600, and 1024x768. The first number represents the count of horizontal pixels and the second the vertical. If a learner's monitor is set at 640x480, and the course is designed to work in 800x600, then the learner will get to see only part of the screen. In order to view the rest, he or she will have to scroll horizontally and vertically. That's not a pleasant way to go through an online course, and chances are your e-learner won't come back--ever.
Color depth. The number of colors the monitor is set up to display may be the least of your worries. With an incorrect setting, the course will still run as designed and track time and scores--it will just look bad. Common color depths are 16, 32, 128, up to millions of colors. If the course contains high quality images but the learner's PC is set to a low color depth, then the PC's video system will attempt to compensate by filling in its own translation of what the colors are. That generally results in very low quality, and sometimes distorted, images. In the learner's mind, the course is to blame.
Solving the problems
Available bandwidth isn't something we have any direct control over, or can even pretend to have an immediate solution for. It's just a lot of network traffic at a particular time. Slowdowns in data communication can result in errors ranging from incorrect course sequencing to lost course results. Even losing all bandwidth is not uncommon. All we can do is set learners' expectations and explain what might happen. If learners understand up front that they might experience some course errors because of data congestion, they might come back later or choose to put up with a slow course.
I like to keep track of available bandwidth while the course is running and notify learners of potential problems with an explanation as they begin. Most courses launched from an LMS are tracked in the background by either a browser frame or an open window. I like to include some programming in that window that checks for bandwidth availability every minute and sets the learner's expectations during the course if things are about to go wrong--offering an explanation of why. If you do that, remember to give the learner the option to turn off the warning message. There's nothing more annoying than a slow data connection except for a warning message that pops up every minute.
To solve configuration problems, browser and PC setting detection can help. This simple step can be done programmatically or purchased as an off-the-shelf Web server add-on product. Many examples exist on the Internet; all you have to do is perform a search on "browser detection." If you already license an LMS, run these concerns by your vendor. An LMS should have the ability to launch and track the courses flawlessly, regardless of the method of programming used to develop them.
Since the programming logic for checking the learner's system is the same for all courses, it makes sense to place your browser and PC detection software on your LMS and make it a part of the LMS functionality. I recommend checking the learner's workstation with two distinct parts of the LMS. First, check the learner's browser and system settings to ensure compatibility with your LMS. That should take place at log-in. For example, check the browser type and version to ensure it meets requirements. If a learner is using Netscape 4.7, and the course is designed to run on Internet Explorer 6.0, the program should inform the learner at log-in that he or she may experience difficulties and recommend that the preferred browser be used.
Second, check the learner's browser settings and bandwidth availability at the attempted launch of a course. If any potential pitfalls are detected, then the user should be notified of what might go wrong, why it might go wrong, and what steps to take to resolve it. For example, if the LMS detects that learners don't have the Authorware plug-in installed, and it's needed for the course, it should stop them from launching the course, explain to them what's going on, show them how to install the plug-in, and provide them with a link to it.
In order to check the browser settings for compatibility with the course about to be launched, you'll need to know what the course's requirements are, and those requirements need to be stored in your LMS. Courseware suppliers can provide technical requirement specifications for you to store. At course launch, the LMS will compare the course technical requirements to the learner's system capabilities and provide necessary information if the learner's PC doesn't meet those requirements.
The last thing you want to do is ask learners to contact the IT helpdesk (unless you happen to have a very responsive one). You want an immediate and painless solution so that the learner can continue using your system. Remember, first-time users are most likely to encounter any browser shortfalls at log-in. Those learners may not yet know about all of the wonderful things awaiting them once they successfully log in, and may never come back.
Including a proactive troubleshooting program in your e-learning strategy is one of the best methods you can use to minimize your risk of failure. It's not a holy grail or a silver bullet, but it will reduce your support costs and help you gain product acceptance in your enterprise.
Published: November 2002