Let’s imagine that you speak a magical, universal language that anyone, anywhere can understand. The dialect is a simple, straight-forward method of communicating to just about anyone, but limits your ability to communicate complex ideas. In other words, you can say “food,” “water,” and “cold.” What if you would like to say something a little more tangible like “hungry,” “thirsty,” and “blanket?” Your ubiquitous language has taken you pretty far, but not quite to the point of being able to speak completely to your needs.
In the eLearning world, we are all at least somewhat familiar with the SCORM standard for tracking and verifying a learner’s progress. In our analogy here, SCORM is essentially that universal, rudimentary language that allows us to record various learner data (Course Launch, Course Progress, Course Score, etc.). However, the simple touch-points established in the SCORM standard fall substantially short in creating a rounded view of what actually is happening within each learner’s experience.
Recognizing the gap in what actions are being performed by a learner in any given session and what is actually being reported, as well as understanding the widening array of available learning opportunities, has led the SCORM developers to expand upon the existing language and provide a solution with a much larger ‘vocabulary:’ The Tin Can API.
Referred to also as “The Experience API” or “xAPI,” this new standard greatly expands upon the original ideas of SCORM, but includes a wealth of additional information to more thoroughly describe the learning process. Of course, simple tasks similar to what SCORM can record may be monitored in the same, straightforward way that SCORM does things (e.g. ‘Jack completed course X with a score of 50%’), but Experience API has the capabilities of dramatically rounding out Jack’s experience. Not only can Experience API track basic information as mentioned in our SCORM example, it can also describe how Jack took the course.
In order to describe various learning events, the Experience API is built a little differently than our good friend SCORM. An additional repository has been put in place to meet the API’s need to know the “who’s, what’s and where’s” of available learning opportunities. The Experience API’s developers refer to this repository as an LRS, or Learning Records Store. The LRS is full of verbs, objects, and ‘actors.’ An actor is just a another name for a noun. Having the LRS in line with an LMS or another tool for reporting allows us to reference these verbs, objects, and actors freely, and use them either simply or in a complex manner.
The Experience API allows us to build structured phrases to describe a learner’s actions by stringing these 3 types of information together. This in itself is a huge upgrade from SCORM’s elementary way of tracking.
Here’s something worth noting: It doesn’t necessarily have to be your LMS that is passing information to the Learning Records Store (LRS) for tracking purposes. The information can come from virtually anywhere, or any activity that has the ability to declare certain activities to the LRS. The beauty here is that while information can be passed from another venue, it can still be viewable and held accountable inside the LMS. Or not – it’s up to you.
Let’s say that it is necessary for a learner to view a certain document in order to achieve compliancy. The necessary document can be placed on a simple webpage, or linked to from another. When a learner either opens, reads, downloads, or a prints particular document (remember, we are creating our own vocabulary within the LRS, so whichever action is applicable), this information can be sent back to the LRS and marked as achieved by a call-back to the LMS or other tracking device/software.
Another, less tangible way for the API to be used would be similar to that of our buddy SCORM. Now, this one we can get our minds around. We are used to this scenario: Create a “SCORM-ish” compliant course, which passes information back to our LRS for tracking purposes. Replace “SCORM” with “Experience API” and it just works as expected. One caveat, though, is that the course does not necessarily need to reside within our LMS and although it requires a connection to send information to the LRS, it’s much simpler to develop for intermittent connections. As long as the course, activity, or experience can speak to the LRS at some point, the system can be designed to save the data and log usage when possible. With some minor customization, intermittent connectivity can be dealt with quite easily. Learning activities can be performed ‘offline,’ and send data once an appropriate connection is made to the LRS. Therefore, the system can be designed to save the data and log usage when a connection to the LRS is established.
Since our learning activities are able to be performed potentially without a constant connection to the LRS, and also take place outside of the LMS, it’s possible to take our learning to an entirely new level – tracking data in ways that can be interactive (such as a mobile app, a standalone web application, a proprietary simulation software, etc.). We’ll talk about this in a future offering, but just think of this: What if you are training a person like Jack who must meet certain requirements to be specialized in a certain field, or certified on a specific piece of equipment. It’s possible to embed our ‘language’ in a simulator and have each and every choice that the learner makes passed back to the LRS and tracked.
Not only does this level of adaptability have an enormous impact on what learners can have stored in their records in a positive way, it also presents a problem. It’s necessary to understand that folks use words differently. Some prefer a certain synonym over another; some simply use the incorrect word to describe an action. Removing ambiguity, while still taking advantage of the flexible nature of the Experience API, is a bit of a tightrope walk. A certain balance must be achieved in order to keep all of the ducks in a row. We want our records to be homogenized, regardless of the ambiguous nature of a statement: Whether a learner has finished, completed, concluded, accomplished, or passed a learning opportunity, the records should look the same.
With an appropriate understanding of the tool, the Experience API can be highly effective and very powerful. The technology is leaps and bounds beyond SCORM in many ways. One key benefit is that, unlike SCORM, connectivity issues can be overcome and therefore not necessary during the actions of the learner.
The Experience API removes the static nature of SCORM records, allowing the system to adapt and grow to new devices, new technologies, and new ways of learning.
