There are many organizations that have multiple LMSs, and many of them have the same problem—they wish they had just one LMS, with all of their data in one place.
We created the eLearning Atlas to be an ideal tool to easily find the proper solutions. Jena and I have tried to speak to every company in the Atlas, and we continue to seek those that we’ve missed. This process provides a valuable pool of data. Rather than hoard this information, I thought it would be nice to share.
Let’s take a graphical look at some of the interesting conclusions I’ve drawn. The following graphs only include traditional products that can implement standards (Authoring Tools, LMSs, LCMSs and Content Libraries). Here we can see the haves and the have-nots:
eLearning Atlas Products That Support At Least One Standard:
A look at the Haves:
So, what does this all mean? For the majority of the industry, SCORM works, but there are lots of eLearning products out there that don’t play nicely with one another. The creation and delivery of content is a hard problem to solve, without a common standard or model… it’s really hard to solve. When developers try to fit a unique course into a unique learning system… things get complicated. When eLearning gets complicated, things get expensive.
The eLearning Atlas proves that there are thousands of possible companies who can create, manage and deliver eLearning, some doing it without any claimed support for standardization. For some companies, the expense of stepping outside their branded box of solutions, locks a customer in for life. We think SCORM frees people to choose the best fit. The eLearning Atlas can help users easily filter out the noise of companies who are not interested in playing nicely with one another, and make connections with products that want to work together.
To look at it another way, we’ve currently found 219 Authoring Tools, some being used by 360 Custom Content Creators to make training that will be delivered using 655 LMS/LCMSs… that’s 51,640,200 possible combinations. Trying to fit all those pieces together, each time, is a daunting task and the exact pain ADL created SCORM to solve. SCORM (and other standards) help eLearning providers play nicely with one another; the eLearning Atlas can help users find the products and services that will play nicely with the systems they already use.
When content sends data to an LMS via AICC, it uses a Microsoft INI data format. For instance, the data might look something like this:
A bunch of data to be saved for later
The “bunch of data” stored in the core lesson field is free text data that can hold any amount of data. Since it is free text, various content modules will store all kinds of data in there. We’ve found that some LMS’s however have a problem handling square bracket characters “[" & "]” in AICC’s core lesson field. It make sense, that these characters could cause a problem since they are significant in parsing the INI format. We were able to code the SCORM Engine to handle them without problem (unless somebody sought to spoof the start of the next section), however it’s easy to see why some LMS’s would choose to parse AICC requests another way.
In AICC 3.5 and earlier, the specification is silent on the use of square brackets, which, in my mind, implicitly allows them. However, AICC 4.0 does now explicitly disallow their use. We recommend that content vendors avoid the use of square brackets whenever possible, regardless of which AICC version is being used.