A visit to any of the public forums of leading authoring tool vendors will reveal on-going problems in using courses developed in their tools to track successfully in LMS systems. They will recommend to load the problem course to Scorm Cloud to validate the course is communicating properly. This helps in assessing if a course is communicating, but often the suggestion is made that if it works in Scorm Cloud then it must be a problem in the LMS.
This is a false analysis and must be challenged. The only thing you learn in loading the course to Scorm Cloud is it works or doesn't work in Scorm Cloud.
Scorm Cloud is a test bed and a controlled environment. It does not replicate the load of your environment or state of internet connectivity at the time the user was having the problem, does not replicate what is happening on the workstation at the time the user was having the problem, and may not replicate the way the user is interacting with the course that lead to the support need in the first place.
This use of Scorm Cloud stems from other LMS vendors that do a terrible job in supporting courseware. Frustrated course vendors turn to Scorm Cloud as a neutral arbiter. It's a viscous cycle with you in the middle of trying to sort out if a tracking problem is in the course or in the LMS. Well we're not like other LMS vendors particularly in how we approach troubleshooting courseware tracking. This rather common problem is addressed quickly and efficiently with some uncommon technology in Ability and better education.
Let's start with the basics. It is an imperative you look at problem solving course tracking problems through the lens: it is the the responsibility of the course to send tracking data. It is the responsibility of the LMS to process the data the course sends (or requests).
So how do you know the course is sending tracking? You get from Scorm Cloud the course is (or is not) sending tracking data in a controlled environment. For sure that is helpful, but we go way beyond SCORM Cloud and log all communication for all users for all courses, something most LMS systems do not do. We recommend you use Scorm Cloud to validate the course is communicating, but need to stress the logging in Ability is authoritative and incontestable and our logging should be your first stop in troubleshooting course tracking problems.
Because all course communication to Ability is logged, if the course never sends a Complete or Pass status, or does not bookmark, the log will tell you what is happening. For example, a 100 page course will typically have log entries for each page you visited in the courses and tracking data for work done on that page. If the course is behaving you see in the log when the course posted a Complete or Pass status and/or Score. So along comes a user who never is marked as complete. The user might even show a screen capture they finished the course, but on inspecting the log you see the course never posted a Complete or Pass status. Ability cannot make the course send the status but can and does record everything the course sends.
Armed with the data the course is (or is not sending) you or your course vendor now can assess the behavior in the course as to when it should send a complete or pass status and what use case is occurring as to why the course is not sending the status. We remind you the course must send a complete or pass status.
The beauty of our logging is it will show the complete history of each and every post by the course for all launches for the user. You can and should share the log with the course vendor and they should be held accountable to explaining what the data means and why a course is or is not posting data. Likewise, you are always welcome to ask MaxIT to inspect the logs. It takes just a few support tickets to understand what we look for. There are considerable support articles in this knowledge-base that cover how to use and read the logs as well.
Here is one recent support example to share. A large multi-national client was experiencing an intermittent problem for some users (not all) in bookmaking for a required 2-hour course. The rather nasty effect was a user would return to the course to resume where they left off only to be bounced to the beginning of the course. Some users were just about finished and to be sent back to the beginning caused a lot of grief sent to the training department. In a sister division running a different LMS, we were told the course was running fine in their LMS which could just as well been SCORM Cloud. Needless to say there was major user frustration particularly for those users towards the end of the course with senior leadership taking a critical eye towards the support problem and disruption it was causing. The clear inference of the client was that this was a problem in Ability since it worked in this other LMS and the intermittent nature of the problem.
We looked at the log and it was clear the course was posting bookmark data when the user exited the course in 100% of all cases (good!). It was also clear than on a resume operation, the same bookmark data was sent back to the course in 100% of all cases (good!). Last, for some users, the very next post of tracking data by the course showed the course as resetting the user bookmark to the beginning of the course. In other words, the log showed the bookmark data being sent back to the course on a resume, and the very next post of tracking by the course showed the course as setting the user to the beginning for those users experiencing the effect. Clearly this was some odd behavior in the course. So we insisted they engage the course developer who armed with the data showing the effect subsequently identified and corrected the problem. It turns out the problem existed in the other LMS too, but our system is used much more extensively in their enterprise.
Bottom line is course authoring engines change. Browsers change. How a course is packaged for loading has numerous settings. How the course developer uses the tool might have errors that break behavior under certain use cases. The local environment can have incompatibilities. Rules for Intranet or Extranet caching can impact the behavior of the course. And yes, sometimes we need to make corrections to Ability. The list of what can break in eLearning is massive and always changing.
There is a place for Scorm Cloud for sure, but it is inadequate for the range of problems to solve in courseware tracking support. In contrast, the use of our logging is a best-practice and should be embraced by clients who have to support problems in course tracking.
So let's circle back to the underlying reality in problem solving course tracking problems. It is the responsibility of the course to send the tracking data. Our logging will capture the entire life cycle of all course to LMS communication. In other words, our uncommon, advanced technology can tell you the entire communication history across all user launches and that will guide you to where to problem solve.
Best Practices to Consider
We can offer 4 best practices you should ask of all users to minimize the need for course tracking support. Think of these best practices as e-learning hygiene. A useful comparison is a person who does not have good dental hygiene. Over time their teeth deteriorate and their breath stinks. Likewise, we don't want taking e-learning and supporting e-learning to become a more painful experience than it needs to be. Best practices will keep both user and support rep from having to endure that stinky experience with an ounce of prevention.
(1) Before starting any e-learning close all applications including all browsers and open a new browser window. The only application running should be the browser and the only site should be AbilityLMS. We often see clients with 30 or more browser tabs open and the workstation is way over stressed. If you are trying to learn it is best practice to ensure your environment is optimized for learning.
(2) Do your training in one session. If you get distracted with a phone call or some other activity and you are away from the workstation for more than 30 minutes, follow rule 1. We see all the time in our logs where users we're in a learning course for 48 or more hours.
(3) Do not spend more than 60 minutes in a course at 1 time. Give your brain a rest.
(4) Do not rush through the course. Many courses will track that all pages are visited and a user quick on the click can easily break the internal tracking of what the course is sending to the LMS. Remember, the LMS is only the RECEIVER and the course, eg the SENDER, must send good data.
While not a best practice, it is suggested you reboot your computer from time to time just to reset your environment to a clean state.
If you will follow these best practices, not only do you drastically shrink the range of causes for courses not to communicate to AbilityLMS, you will get better results in terms of the learning/training that takes place because you eliminate distractions. Sure there is probably some happy medium in these best practices, but the moment you start having problems with a user/course, you should ask for this behavior because you eliminate many (not all) environment issues that might cause the course to misbehave and can more easily zero in on other problems.