Posted by Andy Whitaker
Posted 4 February 2014
Last week, we did a webinar that showcased the most advanced deployment of the Tin Can 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 Tin Can at some point in the future?
A. Ask your LMS provider, or future LMS provider, if they intend to support the Tin Can 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 Tin Can API will look like. Will they be able to receive statements from non-LMS originating activities? Will they be able to share Tin Can Statements with outside Learning Record Stores? Using an LMS that supports the Tin Can 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 Tin Can API enables this, but the other site(s) needs to support the Tin Can API in order to track the activities and deliver Tin Can 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 Tin Can 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 Tin Can 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 Tin Can API specification defines a Learning Record Store as a system that stores learning information (Tin Can Statements). Prior to the Tin Can API most LRSs were Learning Management Systems (LMSs); however the Tin Can API specification uses the term LRS to be clear that a full LMS is not necessary to implement the Tin Can API. The Tin Can API is dependent on an LRS to function.
Most Learning Record Stores will not only store Tin Can Statements, but will also be the system that makes meaning of the Tin Can 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 Tin Can 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 Tin Can instead of SCORM?
Q: Why is both SCORM Data and Tin Can 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 Tin Can, 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 Tin Can 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 Tin Can 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 Tin Can 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 Tin Can. Converting the SCORM data to Tin Can 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 Tin Can, or rely so heavily on SCORM’s runtime sequencing and navigation rules that converting them to Tin Can 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, Tin Can statements, from the LRS.
Q: What are some examples of the Tin Can 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 Tin Can API. If you’d like more information about this project, please email firstname.lastname@example.org.
Q: What technologies were used for native mobile apps? PhoneGap? Objective C?
Q: Is the Tin Can 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 Tin Can 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 Tin Can API. Rather, the Tin Can 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 Tin Can 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 Tin Can 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 Tin Can 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 Tin Can 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 Tin Can implementations with Sharepoint?
Q: Can Tin Can 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 Tin Can API. The outfitting of a Sharepoint instance can be done by the organization using Sharepoint.
For an application like SkillPort to support the Tin Can API, the owners of that application, in this case Skillsoft, will likely need to implement the Tin Can 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 Tin Can to tap into informal learning?
Q: Given that LifeWay is bringing in event data converted from SCORM in Liferay, plus Brightcove-sourced Tin Can 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 Tin Can. 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 Tin Can compliant courseware?
Q: How long does the framework conversion usually take from SCORM to Tin Can 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 at email@example.com 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.