mLearnCon 2013 is happening right now, and we thought this would be a good time to write about some related topics:
Mobile learning. M-learning. Native apps. Tablets. Smart phones. Offline e-learning. HTML 5.
These are all terms that we’ve been hearing a lot about in the e-learning community, but where do we really stand with all of these different things, especially when talking about trackable and standards-conformant learning?
When looking through the eLearning Atlas, I wondered if the versions of SCORM that companies claim to support are closely matched to what we see being used in reality, via SCORM Cloud. Let’s check it out:
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.
A car salesman’s credibility is quickly lost when he guesses what size engine is under the hood or what the gas mileage could be. Claiming a car has “good” gas mileage is not the same thing as knowing it’s 40 mpg. A 6-cylinder engine can come in a variety of flavors… in-line or V, turbocharged or naturally-aspirated, these details create some machines that are much faster than others. With cars, more is not always better, sweating the details creates vehicles that keep “car guys” debating for hours. People who care nothing for cars will make generalizations that make me cringe, but nobody wants a guessing salesman to help choose the perfect vehicle.
A year ago, we talked about 5 things every piece of SCORM content should do. Today, I wanted to mention 4 things every SCORM test should do… Keep in mind, SCORM tests are a subset of SCORM content, so they should be doing those same 5 things I mentioned a year ago. Take that as a given. This is just a further set of details.
1. Record your interactions with full detail
SCORM provides a way for content to record the learner’s answers (and the questions) to the LMS. Put simply, do it. We see content all the time that elects not to report these interactions, and it’s a waste. Even if the LMS doesn’t report well on this information today, it could do so ultimately. And from a learning/remediation perspective, it’s crucial that the administrators of the LMS be able to see how their learners are progressing. Just do it. Nike would be proud.
Now for the details. Recording interactions can be done well or done poorly. If you want to do it really well, and your LMS supports it, opt to use SCORM 2004, rather than SCORM 1.2. SCORM 2004 allows content to be far more expressive in reporting interactions.
Next, understand the data model elements. I’ll spare you all the details here, but here are some highlights. For the purpose of examples, pretend like we’re working with this question:
What is my name?
A. Tim Martin
B. Reggie Benes
C. Dan Stook
D. Keith Bolliger
- Record the result (correct/incorrect) in cmi.interactions.n.result
- Record the learner response and correct response using a human readable identifier (or collection of them). Better to record “Tim_Martin” than “A” if the learner answered the question correctly. This gives the LMS an opportunity to share that data with the administrator in a useful fashion. And in SCORM 2004, “Tim_Martin” is now a valid response pattern. (In SCORM 1.2, “A” was the best you could do.)
- Use cmi.interactions.n.description. Frankly, this is one of the best additions in SCORM 2004, allowing you to record that the question was, in fact, “What is my name?” From a reporting perspective, this a vast improvement.
- If you’re going to go this far, you might as well complete the data model and record the following:
2. Understand the difference between state and journaling
First things first… interactions are recorded in an array. Take note of cmi.interactions.N.whatever. That array is sequential, and each time a SCO wants to record something to it, it has to ask for the next available space (via cmi.interactions._count). Separate from the N I’ve just mentioned, though, is the identifier of the interaction… cmi.interactions.n.ID.
If a piece of content wants to record a 10 question test and have a slot for each of the 10 questions, it can do that, even if they allow the user to update their answers. It would do so by cycling through the existing interactions and examining their cmi.interactions.n.ID to see if it matches the one that needs to be updated. This technique of updating a given interactions values by cycling through the array and resetting those values is called “state” or “stateful”. The recorded interaction indicates the current state of those values. It also eliminates any prior values that may have been recorded. State is a valid approach to recording interactions.
On the other hand, the array allows for you to simply add another value to the interactions array rather than seeking out the old array location and overwriting it. In this case, the content would simply request the cmi.interactions._count value and record the new interaction data in that slot of the array. In using this journaling technique, all of the historical values for that interaction are maintained. If the content wishes to retrieve those values, say on relaunch of the content, though, it has to be more intelligent about discerning which of the answers was most recently given.
Note, both journaling and state are valid option. It’s crucial, though, that the content manage it’s concept of cmi.interactions.n.ID well though. A piece of content that uses a new ID each time it reports and interaction is not properly journaling, because the association between multiple answers of the same question is lost.
3. Set completion status and success status
In SCORM 1.2, completion status and success status were rolled up into a single entity, cmi.core.lesson_status. It had six potential values, including completed, incomplete, passed, failed. In this world, it was impossible for the content to tell the LMS if a failed status meant that the user should be allowed to take the content again or not. Was it failed because they hadn’t finished? Who knew?
SCORM 2004, though, separates the concepts of passing and completing using two distinct data model elements:
- cmi.complete_status (completed, incomplete, or unknown)
- cmi.success_status (passed, failed, unknown)
This allows the content to be more expressive about whether a failure was final. Each content vendor is welcome to their own interpretation here, but making use of both completion_status and success_status is important in SCORM 2004.
4. Post a score
Lastly, be sure to post a score. It’s such a simple thing to do, and it’s hugely useful to the LMS. Take note, in SCORM 2004, the posting of a score should look like this for a 10 question test on which you got 8 right.
- Set cmi.score.raw to 8
- Set cmi.score.min to 0
- Set cmi.score.max to 10
- Set cmi.score.scaled to 0.8
Older Posts »