Content that explains how to configure Adobe Captivate e-learning courses to work with Learning Management Systems.
If you’re an Adobe Captivate e-learning developer, it is now most likely that you will be delivering your e-learning courses via some kind of Learning Management System (LMS for short). If so, you may encounter an issue where course participants complain about the content “freezing up” or pausing repeatedly during playback.
This issue is usually caused by LMS server latency. In mild cases it can just be annoying. In serious cases it can completely cripple the effective delivery of your e-learning project.
As mentioned in the above-mentioned post explaining LMS server latency, the greater the number of separate files there are in your course, the more requests will be sent to your LMS server to download them. An HTML5 course published from Adobe Captivate is actually made up of hundreds (potentially thousands) of smallish files, all of which need to be requested from the server. But since HTML5 is now more or less the only viable Adobe Captivate publishing option for web delivery you should at least reduce the number of file requests by minimizing the number of images, and other small objects in the course content. For example, rather than having a large number of separate images on a slide to create a complex background, how about just assembling these images in a graphics editor as a single graphic file and use that as a slide background instead?
Minimize data requests by modifying Quiz Settings
If you’re suffering with serious LMS server latency issues, the number of files in your ourse is not likely to be the biggest culprit. You should probably be looking at reducing the number of data requests. Server latency issues often turn out to be related to the number of times your Captivate content is pinging the LMS server to tell it about the course participant’s interaction with the content.
So what can you do about that? Fortunately quite a bit!
For the purpose of this discussion we’re assuming you’re using a SCORM-compliant LMS because this gives you the largest number of options for reducing server load. (Choosing any of the non-SCORM reporting solutions in Captivate cuts out most of the options we discuss below.)
All of the options that allow you to reduce LMS server load are found on the Quiz > Reporting dialog. We’ll start at the top of the dialog and work our way down, discussing each option you can use.
Use the SendTrackingDataAtEnd Template
When you choose SCORM as your LMS standard, Captivate assigns a default template full of code designed to communicate with the LMS. However, the default template uses Captivate’s normal ‘verbose’ communication method, which deluges the LMS with tons of information.
However, you can opt to use a different Template by selecting one from the dropdown list. The best one for reducing LMS load is called SendTrackingDataAtEnd.
How is this template better? Well, instead of sending tracking data to the LMS all the time while the participant is interacting with your course, this template stores the information and only sends it to the LMS when the user exits the course module. That means one request to the server instead of dozens.
This single change is likely to have the biggest positive impact on server latency issues. If you want to test whether or not changes to your content will fix your server latency issue, perform this one change and test the output on your server. If this has little noticeable impact, I doubt whether any of the other changes below will make a difference either. Your server is probably toast.
(By the way, if you have experienced SCORM programmers on your staff, you also have the option of creating a custom template and adding this to the relevant sub folder in the Templates folder of the Captivate install directory under Program Files. But don’t attempt this unless you or your programmer really know what you’re doing.)
Report quiz results only, not slide views
Let’s be honest. How often do you really need to track what percentage of the slides were viewed by the course participant? In most courses the key result that everyone is interested in is whether or not the participant passed or failed the quiz.
So, unless you have a compelling requirement to track slide views, I recommend you turn off this option by deselecting the relevant Slide Views boxes on the Quiz Preferences screen as shown in the example screenshot below.
Since the number of content slides in a module usually far outnumber the quiz slides, not tracking slide visits will further reduce the data sent to the LMS server.
Don’t report Interaction Data
Further down on the Quiz Reporting dialog you will find the section that determines Data to Report to the LMS. This option is selected by default. Deselect it, as shown below, to further reduce load on the server.
This dialog is reached via buttons near the bottom of the Quiz > Reporting dialog. Just look for the Advanced button (as shown in the screenshot above) and when clicked it opens a dialog like the one of those shown below.
This dialog is seen when you select SCORM 2004.This dialog is seen when you select SCORM 1.2
As noted below each screenshot, there are slightly different options depending on whether you select SCORM 1.2 or SCORM 2004. However, regardless of that difference, the two important options here for reducing server load are:
Send Data On Every Slide – Ensure this option is deselectedto prevent Captivate from pinging the LMS every time the user advances from one slide to another.
Never Send Resume Data – This option is deselected by default. So, you need to selectit to preventCaptivate from sending data to the LMS about which slide the participant is currently on. (Resume Data allows the LMS to ‘bookmark’ the specific slide the course participant was viewing at the time they exited the module as well as grab any data about their quiz question answers and score. When the user later resumes their session this data is fed back to the module so that everything looks the same as when they left off. So, selecting this option to “never send resume data” effectively disables LMS bookmarking. Bookmarking the user’s progress in a course module is usually regarded as a good thing. So, you would only choose to disable it if bookmarking was deemed far less important than reducing your server latency.)
Which countermeasures should you use?
Well that depends entirely on how bad your server latency issue happens to be. Only you and your IT department are really able to answer that question. If you’re not currently suffering with noticeable server latency issues (as indicated by course participants complaining about the content freezing up for no apparent reason), you probably won’t need to enact any of the countermeasures outlined above.
Another factor to weigh up is that all configuration options in Captivate have advantages and disadvantages. Each thing you turn on or off will have an impact somewhere else in your content. For example, if your e-learning modules are quite long and most users do not complete them in a single session, having Resume Data bookmarking might be deemed more essential than the small amount of extra server load it imposes.
So, you need to weigh the pros and cons before making a final decision. And the only way to evaluate the pros and cons is by making changes and then testing to verify the resulting differences in server load.
Last resort: Upgrade your server technology!
At the end of the day, if your server technology is outdated or inadequate, none of the measures suggested above may ever be enough to fix “the issue”. You could end up just chasing your tail spending hours, days or weeks modifying your courses when the best solution might simply be to lobby your management for budget to buy the level of hardware infrastructure your organization really needs to cope with the amount of learning you need to deliver over the next 5-10 years.
If you’re an Adobe Captivate e-learning developer, and you’re not already using a Learning Management System (or LMS for short), then the chances are very good you WILL need to work with one in the near future. When you do, you’ll find the issue of LMS server latency is something you need to understand and solve when developing your content.
Why do you need to understand this somewhat technical issue? How bad can it be?
Broadly-speaking, the term ‘latency’ refers to the time a host server (e.g your LMS) takes to respond to a request for a file or object. I’m keeping this explanation as simple as possible and more focused on how latency relates to e-learning content.)
In a web-based e-learning course, your learner is using a browser to access and interact with your e-learning content. While they do this, ‘under the hood’ the browser and your LMS are sending data back and forth to each other across the internet, telling each other things and asking for things in return. When your course asks for a file or for information, this is known as a ‘request’.
Server latency is usually measured in milliseconds, thousandths of a second. And, as the page linked above tells you, a latency of 20-30 milliseconds is considered minimum, with latency between 75-140 milliseconds quite normal.
There are two main types of requests involved. File requests and interaction data. Let’s talk about them one at a time.
Latency due to the number of file requests
In the case of a typical Flash-based e-learning course that is NOT being served from an LMS, the objects requested from a web server might consist of an HTM file, one or more SWFs, a JS file, and possibly some video files (if you’re using video at all). Just a handful of objects is really all that’s required to serve up Captivate content.
Additionally, one of the big advantages of the Flash SWF file format is that it’s actually a compressed ‘wrapper’ file that works in a similar way to a zip archive. It can contain almost any number of files in a convenient, highly-compressed format. And since all the other files are encapsulated within the SWF wrapper, it only requires a single request to the server to download to your browser, regardless of how many files are bundled up inside it.
If you turn on SCORM 1.2 reporting in Captivate, and publish for upload to your LMS, the innocent-looking zip archive you end up with contains at least 15 files. Conversely, if you change to SCORM 2004 reporting and publish, you end up with a total of 47 files for the same course module. Now, these extra files are of course required for SCORM communication with your LMS.
In real terms even this number of files is still quite a small number and would not normally cause issues with excessive latency. Since all of these files need to be downloaded before your course can begin communicating with the LMS server, the only time they might be responsible for a delay in playback is right at the beginning of playback for your course module, not from then on.
How publishing for HTML5 can further add to server latency issues
As mentioned above, an elearning module published to SWF/Flash format might have 50 or so files. But, if you’re publishing as HTML5-based e-learning targeted at mobile devices, then you can add a lot more files to this list. In fact, a module containing just a single blank Captivate slide published for HTML5 SCORM 2004 will result in about 200 files. And that’s BEFORE you start adding any content!
Unlike the SWF format, HTML5 isn’t using any encapsulation or compression. So, all of the files that went into your course will exist as separate objects. This includes all images, audio clips, videos, style sheets, JavaScripts and other files containing code required to make your course work.
Even a reasonably simple course module will contain hundreds of objects. A large complex module could contain thousands, every one of which will need to be separately requested from the server. Every request will result in at least some latency.
So it should be no surprise that one of the frequent complaints now being heard on the Captivate Forum about HTML5 output is that it takes too long to load, and the playback is very “jerky”, stopping and starting often while another piece of content loads.
Latency issues due to the volume of interaction data
And now we come to the other big wrinkle in this issue: Interaction data. In fact, this can often be the biggest issue of all.
A lot of communication that happens between your course content and your LMS relates to data about what your learner is doing at that moment in time; how they are interacting with your course content.
In this area, Captivate has a reputation for being very ‘verbose’. That is, it’s default settings are to tell the LMS about everything that the learner is doing, potentially deluging the poor server with information about every slide entered, every object that gets clicked, every question answered, etc, etc.
This wouldn’t be so bad if the server had the option of selectively ignoring some of these requests. But in fact the server is expected to reply with a short acknowledgement that the interaction data was received…after each and every request.
And here’s the real kicker…After sending a request to the server, Captivate will sit patiently waiting for the server to reply before moving on. If your server is already busy, that’s when latency really bites.
The fact that Captivate pauses while waiting for the reply from the server doesn’t cause a noticeable issue UNTIL your server starts to reach the limit of the number of requests it can handle. But if your server has become overloaded with requests, then the latency delay while Captivate stops to wait for the server’s reply can gradually build up slide by slide until your course participants are potentially waiting several minutes for Captivate to respond.
And that’s when LMS server latency bites your e-learning course bigtime. Because as soon as the course participants are being forced to wait for any longer than a minute or so, they will conclude the course as “stopped responding” and therefore must have crashed. They’ll probably close down the browser, and hopefully try again. But it’s also likely they will log a support call, or complain about the amount of time they’ve wasted without getting a result.
What happens to the LMS Server?
A single 10 minute Captivate module can potentially communicate scores of requests to the LMS server while the user is interacting with it. If you have scores of users accessing courses on the same LMS server, the number of requests increases exponentially.
At some point all LMS servers will reach their request limit, and at that point everything slows down, latency increases, and if the volume of requests does not diminish, the server may eventually crash.
A case history
Some years ago I was working on a number of e-learning courses for a multi-national company. At that time the company did not have their own LMS so they had outsourced delivery of the course content to a nationally recognised LMS provider who supposedly had huge capacity.
We loaded up some first draft course modules for load testing and had them accessed by a few dozen employees. One module had 25 quiz questions. When any more than a dozen or more employees accessed that module, they started experiencing significant latency that gradually increased to several minutes between slides.
I was able to dial in and personally watch the Task Manager CPU readout of the LMS server during one of these sessions and saw it gradually climb to 100% CPU usage until the server eventually crashed under the load.
There was no way we were going to be able to roll out those courses until we reconfigured Captivate to reduce the LMS server load. Fortunately, we WERE successfully able to do this, and if you want to know how, read the other post I mentioned above that explains the counter-measures for LMS server latency.
