Update: The Output of Project Tin Can is Experience API.
It Needs To Be Simple
A major aspect that most of you are looking for in a next-generation specification is simplicity. Traditional e-learning standards are complex, so it takes significant time and cost to become conformant.
You’ve also asked for more power.
Unfortunately, simplicity and power generally don’t go hand-in-hand in a software environment, but we think we’ve found a solution.
The Tin Can API at its simplest is much easier than SCORM:
- You no longer have to deal with Javascript.
- The complexity of activities and LRS communication is greatly reduced (fewer API calls.)
- There are no more required manifest files or complex file structures.
- There are no complex requirements for the content (activity) to meet. It only needs to be able to send the statement “I did this.”
- Since the activity runs on its own (outside of the LRS,) there are no user interface requirements to be met by the activity or the LRS — the activity exists on its own and reports statements to the LRS.
“I did this” is simple, and it can stay that simple if that suits your needs. Statements can get as complex as you’d like them to be, and that’s one way where the answer to a “more powerful” e-learning specification comes into play. (There are many other ways that the Tin Can API is more powerful than traditional specs. Keep reading the “capabilities” section to learn more.)
An example of a more complex statement would be:
[Somebody] says that [I] [did] [this] in the context of
[ _____ ] with result [ _____ ] on [date].
Join in in the conversation below. Add your voice and see what others say about this solution to a simpler but more powerful e-learning specification.
| Next -> |
| Removal of the need for an Internet browser |