Tin Can API has emerged as a new opportunity. This new learning technology specification cumulates offline and online experiences to provide new perspectives for analyses and improvement. The API captures the activities that are part of a learning experience. The Tin Can API aims to overcome the limitations of previous specifications and puts forward a simple and flexible approach by enabling diverse learning applications to be recognized and be able to communicate with the Tin Can API. One of the aims of the Tin Can API was to be able to record all these actions that represent learning experiences. When such an activity needs to be recorded, the application sends statements in the form of “Noun, verb, object” or “I did this” to a Learning Record Store (LRS).
One significant issue in serious gaming has been tracking and reporting that usually were limited to the proprietary systems in which they were developed. The Tin Can API addresses this issue. Serious games can be tracked in any LRS that support the Tin Can API. This approach broadens competition and opens up more possibilities to content creators, learning institutions, and learners.
The Tin Can API supports tracking and reporting through different means:
– Distributed content: games can be implemented on local servers and send statements to external LRSs.
– Multiple learners and team-based learning: Data can be reported to all the participants in the learning experience.
– Browser independence: Tin Can API conformant activities are not limited to a browser session, therefore larger quantities of data can be sent to the LRS.
– Customizable instructor interaction: the instructor can intervene to change a scenario in a game through the use of user-defined variables.
– User-defined variables: the player can adjust his/ her learning experience and use real-world data from just about any source to create dynamic games.
Older e-learning specifications have issues that are inherent with the way that games and simulations are tracked. Games and simulations are often meant to be played and tracked over long amounts of time, and with many attempts at the same activity. The Tin Can API comes through in this area where older e-learning specs fall short.
All Tin Can needs is an occasional internet connection. Tin Can statements are stored on the mobile device as activities are experienced. When there is a network connection, the collected statements are sent to an LRS (or several LRSs). And because there’s no need for a browser, activity creators can now use native apps for trackable learning. Some people are already doing it, and yes, it’s really that awesome.
With the Tin Can API, activity creators can design native apps that download lots of activities to an app when there is a connection, store them on the device, record Tin Can statements as learning activities are performed, and later deliver the results to an LRS when there is a network connection. And because learning is happening in a native app, activity creators have complete control over the user experience.
Older e-learning standards have limitations on recording in-games experiences. Many games are not played inside a web browser or inside the LMS, don’t always have a network connection available or are played on mobile devices.
Just like any other learning data, tracking it is useful to spot trends and make judgments about what activities are actually working to help people learn things. And if this data could be tracked in a way that it could live side by side with other learning data (test results, for example) then the big picture of teaching and learning is easy to see.
The Tin Can API makes games more useful by making it possible to record all of the generated learning data, and that data lives side by side with all of the other data that’s being generated by students and teachers.
For more on how to get started, access Tin Can API Solutions