DEV Community: xAPI dev

AI in training and learning: the next experiment

xAPI dev — Tue, 25 Feb 2025 22:42:06 +0000

Cue the track, because 🎵 it's been a while 🎵

The 'ol blog may have gathered dust, but the mouse and keyboard did not. Life has been full of changes and challenges over the last couple of years, but one thing that has remained is my commitment to exploring the future of learning and training. What was once the future is....still, in very many ways "the future" as the vicious enemy of "reactive training" still very much persists. At this point, we may as well add it to the list of certainties in life alongside death and taxes, because as much sense as it makes to try and get ahead of your training or learning needs, it's far more common to not realize what you need until you end up realizing you needed it.

In my 10+ years now of trying to understand and support training initiatives, I have seen this problem with EVERY business I have worked with, regardless of the sector they are in. Sales are down? Time to train the sales team! Glassdoor says your company culture stinks? Let's do some ultra fun games in our training! Let's select images and colors that give less "corporate" and more "L-I-V-I-N". These decisions are often made with good intentions, but to move away from reactive training, you have to create a culture of continuous improvement. This is not the simplest task, and to be honest, most of the businesses I have worked with never had the team or resources required to pull it off on their own.

Enter AI. A tool that can truly empower small teams to do much bigger things, and an area that has tremendous crossover for those in learning and development right now. Every business, every team is trying to understand how to best use AI, and I feel like L&D/Training is the absolute epicenter of this convergence - because not only is AI going to be able to help you and your team, but you are also going to be vital to the adoption of any AI tools - so, as they say, "the more you know 🌠".

Over the coming weeks and months, I'm going to be sharing about the AI-integrated tools I am building, and many of them will be free to use for anyone interested. The focus is on empowering those smaller teams, or those teams with skill limitations to still create powerful and effective lessons, courses, programs - whatever it is you teach or train! Follow me to to follow this journey - it's going to be a fun one!

The Future of Learning: Embracing Adaptive Learning with xAPI and cmi5

xAPI dev — Sat, 17 Jun 2023 13:54:27 +0000

As the landscape of learning and development continues to evolve, the need for asynchronous learning and personalization is growing, and traditional eLearning methodologies are beginning to show their limitations. Let's look at why those limitations exist, and how to break through them to achieve next-level learning and development!

The Current State of eLearning

For years, SCORM (Shareable Content Object Reference Model) has been the industry standard for eLearning content. Its ability to track a learner's progress, completion status, and assessment scores made it an invaluable tool for training. But, while SCORM served its purpose well in standardized, synchronous learning environments, it falls short when it comes to providing a personalized, adaptive learning experience.

SCORM operates in a self-contained environment, which makes it incapable of cross-communication between various learning resources or systems. As a result, it can't adapt to a learner's activities outside of its own course shell. SCORM also lacks the ability to report on a user's specific actions, so even with learning paths, there was no ability to understand which users were ending up on which paths and use that data for anything actionable.

The Power of Adaptive Learning

Adaptive learning is a methodology that crafts personalized learning experiences tailored to each individual's learning style, pace, and performance. It's a learner-centric approach that aims to enhance engagement, improve retention, and make learning more efficient.

Imagine a training program that adjusts its content, level of difficulty, and learning pathway in real-time based on a learner's responses to assessments, engagement with course materials, and even their performance in the real world. That's adaptive learning in action!

Embracing Change with xAPI and cmi5

This is where Experience API (xAPI) and cmi5 come in. These advanced standards provide the technology backbone that makes adaptive learning possible on a large scale.

xAPI has the ability to track a wide range of learning experiences, not just those that happen within the confines of an LMS. It can document granular interactions a learner has with a course and can also track learning that happens outside of a traditional course, such as on-the-job performance, interactions with peers, or engagement with resources on the internet.

cmi5, on the other hand, merges the best features of SCORM and xAPI. It allows for interoperability like SCORM while also possessing the advanced tracking capabilities of xAPI. With it, we can have courses that are aware of a user's current training status, answers/results from other content, and other data that may influence the content needed to properly train them.

Looking Ahead

The combination of adaptive learning with technology standards like xAPI and cmi5 heralds a new era for learning and development. These technologies are breaking down the barriers of traditional eLearning and paving the way for a future where learning is more personalized, more engaging, and ultimately, more effective.

As learning professionals, we have an exciting opportunity to harness these technologies to create next-level learning experiences. It's time we move beyond the limitations of the past and embrace the future of learning.

Stay tuned to this blog as we explore more about how xAPI, cmi5, and adaptive learning are reshaping the landscape of learning and development. Together, let's navigate this exciting journey into the future of learning!

Adventures in xAPI Implementation: Visualizing your Statements

xAPI dev — Sun, 28 Jun 2020 22:45:45 +0000

This is the fourth post in my "Adventures in xAPI Implementation" series. If you're just joining us, feel free to take a look at the previous three posts to get caught up!

At this point in the adventure, I am now collecting statements in our LearningLocker LRS, but as I mentioned in a previous post, it isn't the friendliest place to review your results - take a look at what I mean - apologies for the censoring - my test account uses a coworker's name:

Now, this is actually already easier to read than reading the raw statements, but as you add learners, and everyone is making selections at different (or the same) times, this could get challenging very quick.

If you're just looking for basic visualizations like the total numbers of one answer, LearningLocker has several options, and your LRS may have visualization options as well - but I needed to do some comparisons that required a couple levels of extrapolation for a recent project, so I turned to PowerBI. I love PowerBI's flexibility to pull in data from multiple sources, create relationships between that data and create extremely deep queries that are also easily repeatable for different data sets.

So without further ado, let's take a look at what it takes to bring your xAPI data into PowerBI!

I've created a quick 5-question quiz based on Parks and Rec character Tom Haverford:

Each answer will send its own xAPI statement, and a final determination of whether the learner "is tom" or not will also be sent. What I'm going to analyze afterwards is, what are the most common answers for people who ended up being Tom, and what are the most common answers for people who did not end up being Tom.

Simple and completely not scientific - but should be an effective example.

So I run a handful of test users through the quiz, make sure the data is in our LearningLocker, and now I can open up a new report in PowerBI.

When you start a new report, you will be asked to get data from somewhere. LearningLocker has an option to download your data in .csv format, so I'm going to use the .csv option. LearningLocker stores all the data in its JSON format, so the initial import is going to look a little challenging to understand at first.

No worries though, I'm going to click "Transform Data" and get that fixed real quick.

Once the Transform Data window loads up, the first thing I'm going to do is check out the columns. You can see from my screenshot below that there's one issue we need to fix right off the bat.

If you noticed that my actual column headers are on the first row, rather than in the proper location - you're doing great. Easy fix - PowerBI's main ribbon has a button on the Home tab specifically for this. It's labeled: "Use First Row as Headers".

Once it's clicked, my headers are in the right place, and I'm ready to do a little more cleanup. In this situation, I don't need the _id column, so I'm going to right click it and remove it.

You may be basing a query on the combination of actor, verb, and object, but for this example I'll just be using actor and object - but I need to get them out of their JSON object to work with them. Again, thankfully, PowerBI makes this extremely simple. I'm going to select all columns, switch the ribbon to the Transform tab, and find the Parse button. Select JSON from the dropdown, and........

I'll admit - this looks a bit scary at first. Where there at least appeared to be data before, now all I can see is the word "Record" repeated over and over again - with no sign of my actual data anywhere in sight.

All I need to do is click the split arrow button in each column header. This activates PowerBI's "Expand" feature - a way to pull each of the object keys into their own column. You actually get a nice selection menu, to determine which of the keys you actually want to bring in.

For my work, I'm going to use the "name" key from the "actor" column - but depending on how you have your statements organized, you may choose to use a different identifier.

Once I've pulled out the name, I'm ready to dig into the "object" column. This time, there's a little more digging to do, as sometimes the field you want is nested a little deeper. For this report, the data I wanted was three levels deep. Sometimes, the easiest thing to do is expand one column set as much as it will expand before moving on to the next one, unless you already know where to look. Once you've found what you need, you can remove everything else.

After those final few column removals, I'm ready to save the query, and head back into the report builder by clicking "Close and Apply" on the Home tab.

Now you have your data over in the far right pane "Fields" and your Visualization options to the left of that in their own pane. At this point, you should have everything you need to start building an actual visualization.

Each of the visualizations will have slightly different setups, but at this point, a little tinkering with the placement of your fields should get you the visual of your choice. I'm far from being a PowerBI pro, and this is a very insignificant amount of data to work with, but here's a quick look at my end result before I give you a quick once-over of how I got there:

So, again - these results do not represent an actual breakdown of what 100 people taking this assessment would actually answer - but the visualization lives and works exactly the same way. The top graph is showing the breakdown of selections for those who were deemed "Tom" and the bottom graph shows the same thing for the "Not Toms".

To get there, I took my initial data set, and in the "Transform Data" window - which you can get back to by clicking on the three dot menu next to your table name in the "Fields" pane - I duplicated my data set three times, to make a total of four data sets. After that, I filtered the first one down to include only rows that matched the "Tom" value. This gives me a list of people that are Toms. Somewhat confusing in this context, but I'm sure you follow. Next I went to the second dataset and filtered it down to give me a list of people who are "Not Toms". In the third data set, I filtered down to only the rows that contained the names of those who were Toms, and filtered out the Tom objects. In the fourth data set....you probably already know, but I did the same exact thing for my set of Not Toms.

Now I have a count of Toms, a count of Not Toms, and a count of all answers that were provided by both sets.

If it sounds confusing or intimidating....well, it kind of can be at times - but there are a lot of great resources for learning how to visualize your data - my main goal here was to show how the data comes in from the LRS from a .csv and ends up in a nice visualization. I hope I was able to do that - but if you've made it this far and have any questions, please feel free to reach out to me any time - either here, or @_jonny5 on twitter.

Adventures in xAPI Implementation: What to do with these statements!

xAPI dev — Fri, 26 Jun 2020 12:34:15 +0000

This is the third post in my "Adventures in xAPI Implementation" series. If you're just joining us, feel free to take a look at the previous two posts to get caught up!

Let's Continue!

If you've been following this journey, then you know I'm now sending custom xAPI statements from my Storyline course, and in my case, those statements end up in our SCORM Cloud LRS. Not only that, but I'm doing it without having to modify any of Storyline's output files - no additional wrapper or anything. This makes it so much easier to start sending more custom statements, but what's the point?

The "point", as points tend to be, will be different for everyone. That's part of the reason I want to share some of the things I will be doing with statements, and maybe that can help some of you out there in your efforts to provide more in-depth learning analysis or to improve the quality of your courses! I'll dive deeper into how exactly you can accomplish these in subsequent posts, but for now, here's a couple of ideas on what to do with the xAPI statements in your LRS.

1. Visualize that data!

Now, if you're only using SCORM Cloud, this one will take a little more work, as they do not seem to provide a way to pull a .csv of your data any more, but many other LRSs will give you this option. In my case, I've set up a LearningLocker instance on AWS that all our SCORM Cloud statements forward to. LearningLocker does allow me to pull a .csv, and once I have that, I can pull the data into PowerBI to create interesting visualizations. To be fair, you can design some basic visualizations inside of LearningLocker itself, but it's a bit limited, so for any kind of advanced visualizations it's a lot easier to work inside PowerBI or some other visualization tool.

For me, this is huge, as I think data can tell a wonderful story when presented correctly - but if you show a stakeholder your LRS log, it's most likely going to cause more confusion than anything else.

2. Use it in your courses!

This part is wild. It's what originally attracted me to xAPI, but I faced numerous obstacles in order to make it work.

You can actually query the statements in your LRS and set a variable inside your Storyline course based on whether there is a match or not.

Think about that for a minute - say you want to know if someone has already taken another one of your courses, and if so, you want to eliminate some of the overlapping content in the course they are currently in. Maybe you want to provide more or less content depending on an already established competency level. Maybe you want to provide a reward when they complete a certain number of your courses.

These are all possible if you are sending the right statements, and then building your complimentary courses with that in mind.

Conclusion

So there's a little preview of what's coming up. Can't wait to hear what others are doing or wanting to do with their xAPI statements. In my next posts, I will get into how you can create these advanced visualizations and how to actually modify a learner's current course based on how they have interacted with your other courses.

Adventures in xAPI Implementation: The Sending Statements Saga

xAPI dev — Tue, 23 Jun 2020 17:36:36 +0000

So I fell in love with xAPI quickly - and why wouldn't I? The company I work for provides training for other companies, and with SCORM courses, we had little to show clients other than a completion or basic quiz score. There was very little to help us create an idea of what the impact was, and very little to help us determine what was or wasn't successful.

Considering we have to be ready to serve our content to any LMS, it's not like xAPI solved all of these problems on its own, but knowing we wanted to start creating content around it, we at least knew where to start looking in order to make this happen.

That brought us to SCORM Cloud - a service known to many in eLearning as the go-to place for testing your eLearning's functionality - I don't know how many forum posts I've read that have boiled down to - "If it doesn't work in SCORM Cloud, it's your fault, if it does work in SCORM Cloud, it's the LMS' fault." Even if that's all SCORM Cloud could do, it is an extremely valuable resource, but they actually have some other incredible features that really came to save us - namely, Dispatch.

Dispatch lets you take the course that you have hosted in SCORM Cloud and generate a tiny tiny package file that can be loaded into a different LMS. It handles functions like registration and version controls, but one of the more amazing things it does is take your xAPI course, and make it compatible with any LMS that supports SCORM 1.2 - which is basically every LMS.

So now we cleared that hurdle and began to focus on the statement strategy. Because of the way data goes into the LMS, it's important to know what you can and can't query, and how those results come back, especially if you want to eventually get into visualizing your results (which I will get to in the next post).

xAPI statements are comprised of three components:

actor
verb
object

By default, Storyline will send some basic tracking statements for you when you publish your course as Tincan/xAPI, and those end up looking like:

"Jamie Davis experienced (slide name)"

While it's great that they support xAPI out of the box, these statements will only be useful in very specific settings, like branched courses, where you may want to see which slides are being viewed most/least often - they're still providing very little context to the learning. Considering the scope of what you can define with an actor, verb, and object, it would be nice to track more.

When I first started looking for information on how to send custom statements (because Storyline does not yet have a built-in way to expand on these), I began following tutorials that mentioned tweaking the course's code and including other files in order to achieve this. It was cumbersome, and initially limited the amount of custom statements I was willing to put in, because I had to take so many steps to test any statements I added.

Then one day, I noticed statements were coming into the LMS without my having made any modifications to the Storyline output! After some careful investigation, I realized that Storyline was now including TinCan functions that I had previously needed to add in myself, including the sendStatement function and the LMS setup - so no modifications were needed at all, I literally just had to write the javascript to send the statements!

So what does that look like? Kind of like this:

Let's walk through it real quick - because you may have already noticed....there's no mention of an actor.

That's because the same TinCan support inside of Storyline's xAPI output that allows us to send statements to the launching LMS also allows us to automatically associate the active learner as the actor. So unless we want to override that value with a static value of some sort, we can leave the actor off our custom statements.

What we are sending are the other two parts - the verb, and the object. So now if you look back at our code, you can assume that the LMS is going to log this as:

(Active Learner) answered Spectacular

But again - there's more there - what's with the URLs!? If we just want the record to indicate that the learner answered spectacular, why do we have URLs from two different domains, and please tell me I don't have to build a webpage for each value I want to store because honestly I don't have the time for that.

It's ok - take a deep breath.

Let's start with the verb. The id contains a URL on the adlnet.gov domain, and if you were to visit it in your browser, you would get a 404 error. So again, what's the point?

The point is, by xAPI specifications, the id field must be a URL. For the verb, it does not need to be a unique URL, so in order to make things easy on ourselves, it is best practice to consult http://xapi.vocab.pub/verbs/index.html - the go-to resource for ensuring consistent use of verbs. The great thing is, they also give you the URL for each verb, and a description of how that verb is used within the specification.

Consistent verb use? How the verb is used? Isn't a verb just a verb?

Yes and no.

You can imagine that using verbs provides a lot of added context, but it can also get somewhat confusing - some verbs may mean slightly different things in different uses - for instance, one person might think that "evaluated" is a perfectly good verb for describing someone looking at an object and giving it a financial value. Someone else might think "assessed" is a suitable verb. Grammatically, neither is glaringly wrong, but in the terms of xAPI, both should have used the verb "appraised".

You don't actually have to include anything else after the id, if you don't mind your log showing a long URL as the verb, but if you like a clean, easy to read log, throw on the "display" field to assign how that verb displays in your LMS.

Object time.

Just like the verb, xAPI requires your object id to be a url, but unlike the verb, this URL needs to be unique. For that reason, it is recommended to replace the "aURLofYOURchoice" portion with a URL you own or have access to, and to create a system for ensuring unique URLs for each activity. You don't need to put a page at that path - you don't need to do anything with it - it just needs to be a URL and it needs to be unique.

One way I keep up with this is to categorize them by course, then activity, then the specific object itself. This makes it pretty easy to keep things unique, but it also never hurts to keep a log somewhere, just to keep track.

Just as we did with the verb, we're going to give the LMS something a little cleaner to log than a long URL, but as you can see from the code, we aren't using "display" - instead we use "definition" and "name".

We've now added everything needed, as well as a couple of extra pieces to help us out once we move on to interpreting our data, so execute the javascript from a trigger inside your Storyline course, publish the course as Tin Can API, load it up in an xAPI compatible LMS (again, this works great in SCORM Cloud and also Talent LMS, confirmed) and you should be all set up!

Adventures in xAPI Implementation: Introduction

xAPI dev — Sat, 20 Jun 2020 03:16:48 +0000

If you're new to Instructional Design, or new to xAPI, well...you're a lot like me.

A few months ago, I was working as a Project Manager. I had been working primarily as a Project Manager the better part of 7 years. Before that I was a restaurant manager. Instructional Design was nowhere near my radar.

I've always loved solving problems. I enjoy understanding how and why things work the way they do, so as a child in the 90's who had access to a computer, once I discovered the internet I wanted to know how it, too, worked. Coding was a natural fit for me, and before I knew it I was building websites, tweaking blog and (what would eventually become known as) social media profiles, and even setting up some online businesses. I loved it, and eventually picked up some work where I was able to learn about SQL and PHP...but with the pressure to go to college, get a job, etc meant that my love for coding kind of fell to the wayside. Fortunately, I've had reasons to dip back in here and there, so some of my skills have stayed relatively up to date, but there are other areas where I am completely blind.

Learning specifications are definitely one of those areas.

A few months ago, I had never heard the term SCORM or xAPI...I don't even know if I had heard of Articulate, and if I had, I didn't know what it was or how to use it.

Today, I am turning over my first eLearning course - a course designed in Storyline that utilizes xAPI for more in depth tracking of learner data, which then ends up in an LRS that I have also set up.

Some of the things I've included in this course are:

a personality assessment that will log 40 traits per person
course content that personalizes to the results of said assessment
an interactive scenario
a printable plan formed from the learner's answers to specific questions
light/night modes

It's been an adventure, and I'm excited to have a place to share the experience I had, and the lessons that come from it as it goes out to learners. My next post will dig more into the actual implementation of xAPI in a Storyline course, how to send custom xAPI statements using Storyline triggers, and a preview of what that data looks like as it comes back to us.