We have been doing some work towards adding TinCan support. TinCan doesn't really define a process for launching content, in the way that LTI, AICC, or SCORM all defined a launching process. TinCan is primarily about communicating and storing information with a Learning Record Store (LRS). In this respect, TinCan is similar to SCORM in that it would usually save/retrieve activity progress from the LRS, very similar to how SCORM commits/gets information from the LMS. The benefit of TinCan is it is better able to scale out and track a much wider variety of information with a standard API, thus making it easier to collect and store information outside of the LMS in a standardized LRS. In summary, TinCan is more of a communication API, than it is a content package standard. Thus, when we talk about "TinCan content" we are really just talking about a learning activity that has been implemented to send statements to an LRS, which is somewhat agnostic of what type of content package it happens to be.
Because TinCan spec defines a much narrower set of features than previous standards, focused mainly on communication with the LRS, it leaves alot of room for how design the interaction between TinCan content, LRS, and LMS.
I would like to try and collect as much information about what everyone's ambitions are for TinCan. I'd like to hear from people who have an interest in TinCan, what the driving force is for their interest.
1) Do you already have access to content that's only available in a TinCan format?
2) Are you building TinCan content that will generate statements that you are interested in mining from your LRS? If so, what are you trying to accomplish and what kind of statements are you interested in?
3) Do you have tooling that you will rely on for building TinCan content? Will you be implementing the logic to generate statements from the content? What is your level of comfort or your staff's comfort level with implementing TinCan content. (Often referred to as xAPI content)
4) TinCan content can be built such that the learner can transition to a proprietary native application, such as on a phone, yet still send/track progress with the LRS. This allows more flexibility than other standards. Is this a driving factor for moving to TinCan? I know this is certainly an appealing feature, but interested in hearing if this is your primary reason for wanting to support TinCan.
5) Any other information about your goals would be great to hear.
-
David Sensenig
At this point, our primary need for TinCan is to allow our users to download Articulate Storyline content to the iPad so they can access it without being connected to the Internet. Mobile performance of Storyline content is frequently poor through HTML5, but works much better when using the Articulate Mobile Player (AMP) native app. The problem is, in order for users to access content behind a log in it must be published for TinCan.
-
Sara Charles
We have added Tin Can and LRS integration in Sprint 75! Please go to http://www.learnercommunity.com/communities/insight/discussions/1953/sprint-75 to view the discussion on this sprint.