Final presentation to #xAPIBootCamp July 15, 2015 where the team shares how we used xAPI and Internet of Things (and the Internet of Internets) to support new hire orientation.
3. www.wallsave.com
BOUNTY:
Internet Of Things
“IoT is a concept that describes a
future where devices, systems and
services around the world are
interconnected across a common
network (typically the Internet) and
are able to interact in ways that
fundamentally enhance the way we
live our lives.”
- US Ignite Global Cities Challenge (2014)
https://us-ignite.org/globalcityteams/faq/
7. www.wallsave.com
a
About that
Internet Of Things…
“Connectivity and devices are just
enablers. The real value for users is
created by making sense of the data
that those devices generate. Sensors
generate data, data produces
knowledge, knowledge drives
action.”
- Schuermans & Vakulenko (2014)
IoT: Breaking Free From Internet and Things -
How Communities and Data will Shape the
Future of IoT in Ways We Can’t Imagine
11. Tour a place
Explore benefit package
Meet actual people
Attend webinar
Attend a class
Rate your experience
Complete online course
Observe something
Receive coaching
Watch a video
Follow a blog
Read a book
Elearning: Welcome
Elearning: Log into LMS
Elearning: Plant tour
Class: Your benefits & you
Class: Email and You
Elearning: Who’s who
Elearning: Our customers
Class: Finance 101
Recorded webinar
Webinar
Multiple choice test
Participate in an activity
Job shadow
Class: Using the intranet
Company BCompany A
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23. WHAT WE LEARNED
Flexibility of
display rocks
• Existing web tools make
assembly & xAPI easy
• A plan + structure = easy peasy
for instructional designers
• Flexibility of changing how
things are displayed vs. the
underlying verbs, activities, etc.
• Activity statements
• ADL statement viewer
• Shortcuts (rapid authoring tools,
templates) are convenient… but
limited and inflexible
24. WHAT WE LEARNED
User creation &
authentication
• Everyone in the pool!
• Simple approach: name, email,
password
• Save progress
• Query xAPI by email address
25. WHAT WE LEARNED
Reading data
from the LRS
• Use callbacks: checklist items are
only marked complete visually
when the LRS says so
• Allows us to act upon the
recording of individual xAPI
statements as they occur
26. WHAT WE LEARNED
Sourcing our
verbs
• Smart: Grammar counts
• Hard: There is no one source of
all verbs
• Then: Make up your own
27. WHAT WE LEARNED
What is
complete?
• Completion!?!?!
• We built a “Complete All” button
• cmi5 “Complete” sent once all
items are checked off
• What if new items are added?
• Checklist determines completion
vs. LRS/LMS determining
completion
Editor's Notes
Huge props to the whole team who added creativity to the mix, challenged each other’s thinking, pitched in to build, provided tools, offered creative storytelling, facilitated our weekly meetings and served as the grammar police … some of whom are here today and some are listening in remotely.
We chose the Internet of Things bounty. In part because the idea of a “bounty” seemed like a whole heap of fun. And in part because it would allow us to play in an entirely new space for most of us on the team who live in an elearning-in-an-LMS world.
We had a number of questions when we got into this, and it really depended on our perspective from where we were coming from. Our team was a mashup of instructional designers, developers and LRS/LMS guys.
Most people see the Internet of things in terms of personal products: and we focus on the UI or the affordances that make our lives simpler. You can buy these things today. There’s the Nest, the FitBit and the FitBit Surge watch, a Withings blood pressure cuff, all sorts of things that you can hop on the internet with your phone and have delivered to your home tomorrow, have it set up by time your family comes home so you can dazzle them.
If you’re a company or a government you can buy the enterprise version of these things that monitor security, manufacturing lines, inventory, logistics and supply chain, truck and personnel locations.
It’s not so easy to break into these Things to tinker with them – that’s the price you pay for ease of use for consumers – so we picked up a bunch of the kinds of things that are inside these products.
Gimbal Beacon - bluetooth low energy (BLE), temperature
WhizTags NFC tags – near field communication tags that can be “programmed” with a phone app
PunchThrough Light-blue Bean - also BLE, more sensors than beacon, temperature and accelerometer, can be programmed with arduino code
TI sensor tag - also BLE, has 10 sensors
TI cc3200 simplelink wi-fi board - has temperature and accelerometer, can be programmed, external modules can be plugged in
We also picked up a WeMo switch.
Our challenge was to wire these things up with xAPI … and make them useful in an experience-tracking-of-learning context.
But let’s get back to the bounty thing ... It’s not about the things – as cool as they are -- but rather what we can do with them. And that’s where xAPI and bringing these into the learning context was the key part of our challenge.
So our goal with the project was to use xAPI to track as many different Things as possible and figure out learning utility for them.
Along the way, we found a lot of items we initially thought of as Things, but that we actually classified as “Internet of Internets”. IfThisThenThat is a perfect example of a simple way of connecting two different things on the internet to each other. Some of these you can connect to things, but others are nothing more than trigger statements from one piece of the internet to another. We decided they weren’t really Things … but they’re a lot of fun, easy to use and a nice example of the intertwining of it all. So we did them, too.
Of course, the IoT is a perfect use case for xAPI – these Things don’t fit neatly into a box.
We needed a conceptually portable metaphor for our project and settled on a new hire checklist. Rob Houck and Megan Torrance use this slide in their intro to xAPI presentations – it lays out a traditional LMS kind of onboarding path (Company A) vs. an experiential path that could be leveraged by xAPI (Company B).
Company A’s approach works when you’ve got a large number of people you care about tracking.
It doesn’t work so well if you want them to do too much in their first 2 weeks on the job – they’re just sitting and “being trained” … they’re not doing. If you can just pour knowledge into heads, this works.
And you can track completion rates, scores, participation, time spent in training – you know these raw stats at any point in time. That’s the beauty of your LMS.
Company A’s approach assumes that everything you need to learn can be done inside the LMS, or at least in a classroom where the instructor records your participation in the LMS.
Company B’s approach is a much more action-focused, experienced based way to learn. This is way more interesting, and way more effective. It works when you’re small – you don’t have a lot of people, you don’t care about tracking really carefully … because typically you can’t track this much stuff, this much variety, at scale … not without a lot of brute force programming. And that doesn’t give you much flexibility. Of course, in an xAPI enabled world, everything changes.
So why the Gnomes?
Gnomes are memorable,
Gnomes are hard-working,
Gnomes are all about the experience
Gnomes are portable. They’re a lot easier than hauling around a factory or a piece of equipment.
The world of gnomes also gave us some context that we might not otherwise get if we tried to incorporate all of these Internet of Things items into a real-world checklist.
Gnomes aren’t exactly the type to sit in front of a computer clicking through screens. They like to travel, whether they do it by purchasing flights online, through their more traditional garden milieu, or in our case, by motorcycle. So, gnomes are the kind of characters that need xAPI because their learning happens all over the place. It only made sense to choose a gnome. [Note, Alison doesn’t really have any idea why we went with gnomes.]
In more practical terms, we needed a context that would help us understand how all the functionality of xAPI and the Internet of Things might actually play out. We developed a scenario for an onboarding checklist that has relatively authentic uses for all the cool stuff IoT and xAPI can do. Finbert the Gnome is a new hire at Fresh Fish, a fish processing and packaging plant located in, where else? “GNome,” Alaska.
So we did some brainstorming on the ins and the outs of the checklist.
Items noted in green are Internet of Things (IoT)
Items noted in red are Internet of Internets (IoI)
We brainstormed a mix of things coming in and things going out – there are actions on our checklist that are actively completed by the learner, and there are things that happen elsewhere or behind the scenes … and they automatically mark the learner complete for that “happening”, presumably as a result of some action by the learner.
We ran through several UI iterations … we’re not going to spend a lot of time on here because that has more to do with the mobile interface than the xAPI or the IoT. But it was an overall good exercise for our team. Most of us serve clients, but rarely get to “be” the client so this was good fun.
So here’s the list! I know it’s too tiny to read here. We’re going to dive into the highlights in a bit.
Note: if you use this QR code, you will get the web-based version of the app. Web-apps don’t hook into the phone tools like NFC, BLE, and whatnot so the Internet of Things hooks won’t work. The plain old xAPI things will, as will the Internet of Internets hooks.
And, if you click the Complete All … a light will go on in Michigan through our WeMo.
The first few items on the list are all completed within the checklist. When the learner pushes the button on the checklist, an xAPI activity statement is sent. The checklist then scans the LRS to see if the activity statement is there – basically checking to see if it was received.
This one gets a little fancier with both a rating and a comment box.
When you do something in the checklist, it sends a statement to the LRS. The item is red in that state. Then the checklist queries the LRS to confirm that the statement was received. When the Checklist sees the statement in the LRS, the item is greyed out and struck through for the learner.
This is the mechanism by which the learner can see REALLY whether they’ve completed something … and it’s how we track those things that the learner doesn’t actively do, but that “count” as checked off items.
We used the ADL xAPI Statement Viewer. https://github.com/adlnet/xapi-statement-viewer
Once the list gets deeper in, we get more Things! Or at least connecters of things.
We start with simple Things like NFC tags and beacons.
Then the Bean which was a little more interesting … and we didn’t get as much time to explore this as we’d like
We completely under-used the TI SimpleLink … but we did get it set up.
The TI SensorTags allow us to track a lot of interesting things. (none of which are loaded here in this screenshot)
And then we wrapped it all up with some shameless self-promotion via Twitter.
And a big party when the entire thing is complete: we switch on a light with a WeMo.
(Megan has always wanted her elearning to make coffee for her.)
We learned a few things along the way that are worth sharing.
Actually we learned a lot about a lot of things, but we’ll focus on the xAPI things.
The modern web offers many ways of transferring data back and forth and acting on that data, and xAPI can plug into them easily.
Having a plan for laying out how the statements should be made and structured is a great help in both the instructional design as well as the development, and in our case was referred to often. It also becomes a template for the next time you need it, and can be refined a little each time.One of the delights (for Megan at least) was the flexibility in choosing whatever it is that we wanted to use for the Display, while using nice, standard-conformant verbs and activities underneath.
Our statements could be pretty flexible, and the ADL statement viewer allowed us flexibility in what we displayed.
“Shortcuts” (like templates, rapid authoring tools, etc.) are convenient but limited and inflexible – there’s more work at the moment to make things happen with xAPI, but there’s a lot more control of the final result.
We did somethings here that we wouldn’t do with a corporate installation. We let everyone in.
With a simple login (username, email, password), we can save user’s progress and also take advantage of user account info to create and query xAPI statements easily, and keep the list and the LRS in sync
Using asynchronous JavaScript callbacks when sending the statements to the LRS, we can ensure that the checklist items are only marked complete visually when the LRS says so. This also enables us to synchronize app data, send tweets, use IFTTT, or any other JavaScript function to act upon the recording of individual xAPI statements as they occur (or soon thereafter).
We were determined to do this “right” and use predefined verbs for everything – or as much as we could. What we found is that the spec itself is pretty short on verbs once you get past the traditional things we think about in the “learning” space.
And, when in doubt, we had to make up one of our own: “threw”
Interestingly, the xAPI verbs are all neatly in the past tense. Other verbs are in the present tense.
A screenshot out of Parse showing the various sources of verbs we used… including ones we made up.
I know, I know! In an Experience learning environment, can’t we just get past the concept of “Completion” already!? It still serves a useful purpose, though. From Finbert’s perspective, never ever completing new hire onboarding – or a moving target for what’s expected of you in the organization – is a sure recipe for hopelessness.
For demonstration purposes, we built in a “Complete All” button on the main navigation screen – so that we could simulate getting all of it done and then what happens next. … but for practical purposes, we chose to use the cmi5 standard for our Completion activity statement.
Our checklist looks to see if “all above items” are checked off and, if so, it sends the Completion activity statement.
What we didn’t tackle is what happens when a new item is added to the checklist, what happens to your Completion?
Now this is driving completion from the learning experience’s perspective, not the perspective of the LMS/LRS, which is another way to do it. Just like with SCORM – or perhaps more hairy than with SCORM – you’ll have each learning experience and each vendor accounting for completion in some form or another.