Last week, we did a webinar that showcased the most advanced deployment of the Experience API that we’ve seen to date. We always get a lot of questions during webinars, but we never have time to answer all of them during the webinar—so we answer them with a blog post.
If you missed the webinar, you can watch it and download the slides here.
And now, here are the questions we received, and our answers to them.
Q: What would be your advice to an organization currently revisiting their use of an LMS? What should they consider to ensure whatever ecosystem they reimagine is future proofed to include xAPI at some point in the future?
A. Ask your LMS provider, or future LMS provider, if they intend to support the Experience API and when they plan to roll this support out to their customers. It is also wise to ask them what their support for the Experience API will look like. Will they be able to receive statements from non-LMS originating activities? Will they be able to share xAPI Statements with outside Learning Record Stores? Using an LMS that supports the Experience API will be an important part of your organization’s ability to easily study the learning activities across the enterprise.
Q: Is the LMS a separate component from the portal? If so, was the portal custom built or was the base of the portal built using a product like Drupal or WordPress?
Q: The Portal was created by LifeWay, correct?
Q: What is Liferay?
Q: What was the portal used by LifeWay? Was it Liferay? Not sure what I heard
Q: What LMS did LifeWay use? Home-grown or bought? or is Ministry grid the LMS?
Q: So they do this is in the absence of a LMS?
Q: When you say “they built their own LMS” do you mean from the ground up or did they purchase out of the can LMS and then customize?
Q: “They built their own LMS,” was there a specific platform that they used to build their LMS? Open Source?
A. LifeWay uses a portal called Liferay as the way their users access the system and content. This is the system they customized to serve as their LMS.
Q: Can a participant explore learning outside of the LMS, and record learning from other sites?
A. The Experience API enables this, but the other site(s) needs to support the Experience API in order to track the activities and deliver xAPI statements to an LRS. The participant may also record activities in the LRS via a simple tool like a browser bookmarklet.
Q: Is there a social element to the app Ministry Grid where people can discuss their learning?
A. Not at this time. LifeWay may expand their offering to add social features in the future, however.
Q: Is content only available via the Brightcove Player or can it be brought in through other methods?
A. The System LifeWay has built uses content from multiple sources. Their video content is being handled primarily through the Brightcove player. However, traditional SCORM content can still be brought into the system, similar to any LMS.
Q: OK, so xAPI is *not* a core repository where one would store the “master” representation of a course. One still needs a separate system for that. Is that correct?
Q: So is xAPI a canonical repository for a course, or does it store “someone did something” activity records? Does it *replace* a traditional LMS, or work *with* it?
A. The Experience API specification defines a Learning Record Store as a system that stores learning information (xAPI Statements). Prior to the Experience API most LRSs were Learning Management Systems (LMSs); however the Experience API specification uses the term LRS to be clear that a full LMS is not necessary to implement the Experience API. The Experience API is dependent on an LRS to function.
Most Learning Record Stores will not only store xAPI Statements, but will also be the system that makes meaning of the xAPI Statements.
A Learning Record Store can stand alone or be integrated with an LMS.
Q: Are there any good LRS database schemas available in the community? Still trying to wrap my head around what an LRS DB would look like.
Q: Is there any set standard for LRS database structure?
A. We’ve gotten this question a couple of times. The short answer is that the xAPI specification doesn’t go into that level of detail, leaving it as an exercise for implementers. While the schema Rustici Software uses internally is proprietary, there are a number of open source LRS implementations that allow you to see what different people in the community have implemented, such as the ADL Open Source LRS.
Q: So this functionality is built into the HTML5 video player?
Q: Why did you choose xAPI instead of SCORM?
Q: Why is both SCORM Data and xAPI Statements being captured? Will that be addressed?
Q: Why were course results reported in SCORM then converted? Legacy content? Sorry, I was late to the call.
Q: Is there a reason that the “Take a Course” was not wrapped in xAPI, instead of going to Scorm first, then to the LRS?
Q: Is it fair to say that SCORM will still be needed to track the progress of a user on a specific course (bookmarks, attempts, etc) and xAPI will track the actual key achievement (exam scores, visited a key section of the course etc) within that course?
Q: So they were able to get more item analysis/tracking within the videos using xAPI over SCORM calls?
Q: Can you elaborate on the SCORM to TinCan conversion?
Q: Any information on how SCORM course creation is being approached now in light of xAPI availability?
The biggest worry in this situation is the added complexity of having to deal with two different types of data/reporting systems; one for SCORM and one for xAPI. Converting the SCORM data to xAPI is largely a response to this. Going forward we expect our customers to bring large libraries of legacy SCORM content to the table. These courses run a high likelihood of being so complex that they become time prohibitive to convert to xAPI, or rely so heavily on SCORM’s runtime sequencing and navigation rules that converting them to xAPI is not feasible. To accommodate those courses we take the registration details and convert the user’s details into a series of statements roughly equivalent to the statements we’ve outlined here. These statements will represent a course’s score, completion, status, total time, and all of the related interactions. The reporting system can then be created to operate on a single type of data, xAPI statements, from the LRS.
Q: What are some examples of the xAPI statements that Ministry Grid is capturing?
A. We’ve documented a little bit of that here.
Q: Do you have any example implementations in the higher education sector?
A. We are helping Vanderbilt Medical Center and their LMS provide support via the Experience API. If you’d like more information about this project, please email us here.
Q: What technologies were used for native mobile apps? PhoneGap? Objective C?
Q: Is the xAPI Offline Player SDK mobile only or is it usable for offline PC development?
Q: Does this mobile implementation work on both Android and Apple iOs?
A: The mobile apps are built using two native SDKs created by Rustici Software and open sourced here for the xAPI support. These libraries are written in Java and Obejctive-C targeting the iOS and Android mobile platforms in particular. However, the SDKs are open source and can be easily adapted to run on PCs and Macs.
Q: So Rustici SCORM Engine works on mobile devices?
Q: What technology is used for the mobile app, custom built or product?
A: The Rustici Software SCORM Engine can play SCORM courses on mobile devices through the browser or through an application using a webview or the SCORM Engine’s Mobile SDK. More details on the Offline SCORM Player extensions for the SCORM Engine are available here. Note that our mobile SDKs do not resolve the challenge of playing Flash courses in mobile browsers that don’t support flash.
Q: How are badges integrated into xAPI?
A. Badges as a concept aren’t directly part of the Experience API. Rather, the Experience API provides a way for you to capture and catalog a number of events, interactions, and observations about what a user did. This means that the Experience API provides an excellent foundation for building a system that powers a badging system. The accomplishment, or set of accomplishments, that results in a badge being awarded can be expressed as a set of xAPI Statements.
Q: What makes this implementation the biggest? Is it the complexity of the messaging, or the the volume of messages, diversity of systems?
A. As we watch people deploy new xAPI based systems into live production environments, we haven’t seen anyone match the size of the diversity of systems you see here. Further, using the Experience API as a way to regulate how the various activity providers report data across these different systems is where they have chosen to add the complexity in their system. Their system will require a particular format, including extensions, from all of their activity providers and will reject statements that don’t match the format prescribed.
Q: Has anyone done any xAPI implementations with Sharepoint?
Q: Can xAPI be integrated with Skillsoft’s LMS “SkillPort”?
A. Sharepoint is an application that falls into a class of applications that can and should be outfitted with the Experience API. The outfitting of a Sharepoint instance can be done by the organization using Sharepoint.
For an application like SkillPort to support the Experience API, the owners of that application, in this case Skillsoft, will likely need to implement the Experience API before their customers will be able to take advantage of it in the content of the application.
Q: Do you have any implementations which use xAPI to tap into informal learning?
A. There are several Watershed First projects that will tap into the tracking of informal learning. To keep tabs on these projects, checkout www.watershedlrs.com.
Q: Given that LifeWay is bringing in event data converted from SCORM in Liferay, plus Brightcove-sourced xAPI statements, how did LifeWay keep a unified view of its users across the different source systems? Was there a single login across Brightcove, LifeWay portal, etc., or how are they able to build a holistic profile of “what user 123 did across mobile, web, video, etc.”?
A. The Rustici Software SCORM Engine is involved in handling the “actor” value for all launched content as well as the data converted from SCORM to xAPI. The SCORM Engine will use the same method to create the actor value for both of those situations. In both situations, the actor will be based on some user ID provided by the Liferay portal to the SCORM Engine application. This allows them to map back the data from the actor values to users in their system.
Q: What will be the cost if you are providing as a service to convert existing SCORM compliant courseware to xAPI compliant courseware?
A. Our SCORM Driver product may be the right solution for you. Please contact us here for more information.
Q: How long does the framework conversion usually take from SCORM to xAPI for a 1-hr course?
A: There is no way to give an easy estimate based on the running time of the course. This will largely depend on the complexity of the course. For more information about this contact us here and we would love to help you.
Q: Does TinCanJS support offline statement caching?
A. The short answer is no. The longer, and much more exciting, answer is that someone in the community has created a companion library to add offline capabilities to TinCanJS: https://github.com/mikedawson/tincan_queue/.
We always put a lot of thought into the software we opensource and the software we choose to keep proprietary. It’s always exciting when we see the community validate our decision to open source a piece of software by taking that code to expand and improve.