What is the Tin Can API?
The Tin Can API (sometimes knows as the Experience API) is a brand new learning technology specification that opens up an entire world of experiences (online and offline). This API captures the activities that happen as part of learning experiences. A wide range of systems can now securely communicate with a simple vocabulary that captures this stream of activities.
Previous specifications were difficult and had limitations (see Tin Can vs SCORM), but the Tin Can API is simple and flexible. It lifts many of the older restrictions. Mobile learning, simulations, virtual worlds, serious games, real-world activities, experiential learning, social learning, offline learning, and collaborative learning are just some of the things that can now be recognized and communicated well with the Tin Can API.
It’s important to know that we don’t own the Tin Can API. ADL is the steward of the specification. We just know this space so well that ADL asked us to help develop it. The Tin Can API is community-driven, and free to implement.
How does the Tin Can API work?
- People learn from interactions with other people, content, and beyond. These actions can happen anywhere and signal an event where learning could occur. All of these can be recorded with the Tin Can API.
- When an activity needs to be recorded, the application sends secure statements in the form of “Noun, verb, object” or “I did this” to a Learning Record Store (LRS.)
- Learning Record Stores record all of the statements made. An LRS can share these statements with other LRSs. An LRS can exist on its own, or inside an LMS.
The freedoms of the Tin Can API
- Statement freedom: the structure of “statements” using nouns, verbs and objects lets you us record almost any activity. Think: “I did this.”
- History freedom: the Tin Can API allows LRSs to talk to each other. LRSs can share data and transcripts with one another, and your experiences can follow you from one LRS (or organization) to another. Learners can even have their own “personal data lockers” with their personal learning information inside them.
- Device freedom: any enabled device can send Tin Can API statements (mobile phones, simulations, games, a CPR dummy, the list goes on). A constant network connection isn’t necessary — occasional connectivity is fine.
- Workflow freedom: tracking learning events doesn’t have to start or end in an LMS, it can start wherever the learner is and on whatever device they choose to use. Your content isn’t tied to an LMS.
I want to dive deeper
If you want to realize the full implications of the Tin Can API, check out “The Layers of the Tin Can Onion” by Mike Rustici.
The Tin Can API and Rustici Software
ADL, the keepers of SCORM, issued a BAA asking for ideas for the next generation of SCORM. We applied, and they asked us to research what the next-generation e-learning specification could/should look like. We then began 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 this process Project Tin Can because it was meant to be a two-way conversation between us and the e-learning industry. It’s only fitting that the solution be named the Tin Can API – an elegant solution for letting learning systems communicate with one another. Check out a much more detailed explanation of Project Tin Can.
We not only realized the standard, we wrote it. Now that it’s in the community’s hands and actively developed by many developers and businesses, we are more engaged than ever. See the evolution of the Tin Can spec here.
We are helping people solve hard problems and working with the community to make the standard the best that it can be. Our minds are being blown daily, and we like it. We welcome the opportunity to make this better with you. If you have a question about Tin Can, we can help.