You talked, we listened.
There’s a ton of relevant information on this page, but if you want the latest and the greatest, visit TinCanAPI.com.
SCORM is over 10 years old. ADL, the keepers of SCORM, tasked us with researching what the next-generation e-learning specification could/should look like. We’ve been gathering information about what the next evolution in the e-learning specification world should be in five main buckets:
- The Tin Can User Voice Forum
- Our interviews with key players in the industry
- Our daily contact with Rustici Software customers
- The LETSI SCORM 2.0 white papers
- A list of existing ADL requests
We called it the Project Tin Can because it was meant to be a two-way conversation. It’s only fitting that the solution be named the Tin Can API.
The Tin Can API solves a lot of problems that older specifications suffered from, but it also adds new capabilities, new business cases, and new ways of handling content. The Tin Can API fuses a decade of collective e-learning experiences with a decade of technological advances.
At the core of Tin Can API is a simple sentence structure:
“Jack completed safety training.” “Christie experienced the Berlin Wall in Second Life.” These statements can be simple or complex. The actors, verbs, and objects can vary widely, and can be described with varying levels of detail. Actors/learners can also be described in various different ways.
An actor doesn’t have to be a learner β it can be an instructor that’s asserting a statement, or even a software agent. It’s up to the end user to decide the level of complexity that is needed.
These statements will be the outcomes of experiencing a piece of e-learning content, taking a test, completing a simulation, or even an essay being graded by an instructor. Content will no longer just be limited to SCOs, and in this respect content becomes part of a larger superset that we call “activities.” Content creators will be more like “activity providers.”
The way that content communicates with LMSs changes, as well. The LMS doesn’t need to know that the content or the learner exist until the learning experience (or other verb) is completed.
This is a big separation from all traditional e-learning specs. An activitiy (content) lives on its own, outside of the LMS. It is launched outside of the LMS. In fact, an LMS becomes something more like a Learning Record Store (LRS.)
LMSs will still play the critical roles that they do today, but content won’t need to be delivered β only the statement. No more back-and-forth from the content to the LMS, just send a statement to the LRS when the activity is completed.
We’ll get decently deep into what the Tin Can API is and how it works in these pages. If you’d like to see the slides of Mike Rustici’s 2011 LEEF presentation about where we are with the Tin Can API and where it’s headed, you can see that here.
What Tin Can API is and will become relies on you. Any new e-learning specification just won’t work without input from everybody that it affects. The development of the Tin Can API is a collaborative process, and we’re excited to see what you have to say about the new capabilities and the weaknesses that we’ve identified. Click through to our capabilities section, and make sure to leave comments on the capabilities that mean something to you.
|
Next ->
|
|
Tin Can API Capabilities
|