SCORM LMS Headaches
Well, SCORM is basically the only way that vendor courses are communicating now-a-days. AICC seemed so simple and it always worked on our LMS. I know that those who are really into this “course communication method stuff” will have many reasons why SCORM is so much better. That’s fine and they are probably right. However once started loading the SCORM courses bad things started to happen. Mainly….the courses wouldn’t launch.
Brief Description of Issue: SCORM needs Java enabled in order to communicate with the LMS. Not all of our users had it enabled and IT wasn’t confident that we could just say, “Hey everyone, click the Java checkbox.” Nobody could say with certainty that it would cause other problems. (However nobody could even say what those problems could be.)
If you’re implementing SCORM content you may want to read below. Here’s what we ran into:
- What is the standard IT desktop image?
IT thought that they had a standard desktop image but we discovered that was not the case. We even had a tech re-image a box so that we could have it “fresh and untouched”. That would allow us to do some testing. Well, the settings did not match the “corporate image”. So…be aware that the computer settings/image may be a moving target.
- Some applications broke when Java was enabled.
Even though the corporate standard was to have Java Runtime enabled there were still applications that didn’t support it. By enabling Java we broke various applications. In the end our thought was, “If you decide to build a system outside of the corporate standards then tough luck.”
- Random web applications not working.
There was a particular application that used a URL that would recognize if a user was using Microsoft VM or Sun Java. It would then direct them to the proper URL to launch the application. What we saw is that when we enabled Java some of the users could still launch the app and others couldn’t. Yikes…did we break the redirect URL or maybe the redirect wasn’t working as designed? Nope. What we discovered is the the Help Desk and individual users were creating their own short cuts and bypassing the redirect URL.
- The settings all looked correct but the score wouldn’t pass.
Once we got Java enabled on the users’ computers we had them test 4 different courses. For some reason 3 would launch and record test scores just fine. However the 4th course would randomly work. In fact we could try it 10 time on the same computer and it would work 9 times and not on the 10th! So…was this a computer setting issue? IT did not like that we couldn’t recreate the issue. It just so happened that we were talking to the course vendor and mentioned the error. He had another company having the same random error and we already working on a fix. Good thing we spoke to the vendor or our IT group would have been looking into this forever.
So in the end:
- SCORM must have Java enabled to work. But you must consider other web applications when making this change.
- Also if you’re having problems, remember that it might be an error on the LMS, with IT settings, or possibly with the course files. Good luck and may the LMS gods smile on you everyday.
If you’d like to get more into the details, here’s a nice article. It’s a little dated but the SCORM basics are still the same.
Checkout our flash eLearning games.
Cutout people images. No backgrounds and lots of poses!
Just thought I’d chime in on the subject since we’re working with this all the time. SCORM, itself, is not really to blame here. Many LMSs, TestTrack included, do not require Java in any way. Try it out, if you upload your content there, you can have Java completely disabled.
If you try your content there, and succeed, I think you can point to your LMS in particular as the challenge. It’s dependence on Java is likely the problem, and there are many LMSs that do. While Java has its place, we have found that the compatibility problems it brings to the SCORM world outweigh the benefit of using Java applets.
I’m sure that it is our LMS that’s to blame. The latest service pack that we installed called for a newer version of java. (the LMS vendor failed to mention that)
Funny, stumbled across this as I was checking out your site Andrew. We have also worked with Tim Martin and Mike before from SCORM.COM to do our SCORM impementation and I think you both cover the issues pretty well. Many LMSs out there rely on Java, and unfortunately the ubiquity of Java isn’t all that high (like only 53% of all desktops have it), and many Learning Management Systems haven’t done a great job of Java detection, or version detection to let you know if there is going to be an issue.
Anyway, good post, and great comments.
[...] Java definitely has its place, but LMS environments is not one of them. Â See post and comments here for more info. [...]
Just to clarify, SCORM does _not_ require Java. However, some LMS systems and courseware developers choose to implement SCORM using client-side Java.
Java is very dependent on the version and vendor, which causes support headaches as only one version/vendor can be set in the client’s browser. If there are multiple courses and LMS vendors requiring different versions, as Andrew encountered, some will not function until the vendor provides an update supporting that flavor of Java.
Even when you manage to find a version that works for the LMS and/or courseware, the end client may not be able change their Java version, as it may be dictated by a company IT department or required by another installed product.
Inevitably, if the course or LMS requires client-side Java, it is not going to work everywhere and will greatly increase your end-client support calls, unless you have full control of all client installations. On installations where the LMS/course does function, any subsequent updates of the LMS/course, or Java version could break it all over again.
[...] Java definitely has its place, but LMS environments is not one of them. Â See post and comments here for more info. [...]