Do all APIs need to have goofy names?

When SCORM first came around, it was a little unusual…but it’s an acronym (Shareable Content Object Reference Model) so even if a little odd, at least it’s rooted in some reasonable and descriptive basis. And indeed, ‘ORMs’ have been around for a while, though more often as ‘object-relational maps’, and perhaps most known through the GORM API. Was it a coincidence that the SCORM wordplay worked out to be similar? Does it matter? Maybe what matters is just ensuring the API has a memorable name to hasten The Buzz and, hopefully, adaptation.

The latest entry into the world of silly API names is, formerly-known-as the TinCan API, ‘The Experience API’…which sounds like something from Jersey Shore 2.4, Geeks at the Beach.

Oh, ok, we get it. The Experience API name attempts to actually describe the intent more precisely. Why complain? At least it diverges from the tired, contrived acronym approach! Instead of the rigid (well, mostly rigid with some unclear definition) requirements of SCORM, the Experience API allows ‘subject, verb, object’ reporting from most any device to most any (‘LRS’) location. It does indeed seem to really open up the possibilities of tracking learner activity…or perhaps in a more concerning perspective, really opens up the possibility of tracking everything a user does online where this Experience API is integrated.

The ADL refers to the Experience API as ‘the next generation of SCORM’, but other sites – such as the TinCan/Experience site itself – seem to discard the association. This leads to some confusion; IS the Experience API the next iteration of SCORM? If so, will it retain current SCORM functionality? Or is it a completely different, standalone API with no integrated SCORM methods or structures? If that’s the case, then calling it the ‘next generation of SCORM’ is a dangerously misleading characterization. For example, if the Experience API is to be considered an extension of SCORM, but is such a completely different specification in itself – how does that affect vendors and developers who claim SCORM-compliance?

At any rate, goofy names aside, the Experience API is starting to be integrated into a variety of products, and our own Inquisiq LMS certainly has this API integration on the roadmap as well. It is interesting that the ‘Experience API’ website actually just redirects to the established TinCan website…and the few beta tools we’ve seen with this new Experience API integration still refers to it as ‘TinCan’ tracking. Surely everyone will get on the same page eventually…
…though sure would have been a bit easier to dismiss marketing concerns, especially for an open API, and just call this SCORM 3.0.

BUT it does look to be a solid advancement for eLearning overall. It’ll be nice to be able to move out of the more restrictive SCORM spec to one as flexible as the TinCa…Experience API. One significant hurdle, however, is how to structure effective and friendly reporting tools around a ‘learning record store’ that’s going to hold a wide variety of subjects, verbs, and objects. More on that later…