I have been working on tools interoperability for learning management systems in one form or another since 2003. One of the first deliverables for the Sakai Project in 2004 was a document called the “Tool Portability Profile” (TPP) – this mythical document was going to explain how one would write a tool to plug into a learning management system. When we proposed this notion, the idea was to make it so that some developer would get a copy of the TPP and they would be off and running writing their tool to extend Sakai with no further training required.
Part-way through 2004, through some interaction between the Sakai Project Board, Blackboard, and the Mellon Foundation, we formed a working group in IMS called “Tools Interoperability 1.0”. In the early meetings, I proposed a very Java-centered specification that was an approximation of the (still nonexistent) Sakai TPP. No one seemed to like it and most discussions went in circles until Chris Vento came in and suggested that we switch to web services modeled on WebCT PowerLinks. I quickly saw the benefit of his approach and immediately switched my support to Chris’ approach.
IMS Tools Interoperability 1.0 was completed and we did an awesome demo at the 2005 Alt-I-Lab meeting in Sheffield England. We had working code from Sakai, WebCT, Blackboard and Moodle.
IMS TI 1.0 ended up not being used in the market because of a combination of solving too simple of a use case – but using technology that was too hard to use. In a sense, developing the implementations for the Sheffield demo made it pretty clear that it just was pretty hard to get IMS TI 1.0 in production.
But the notion of coming up with a single standardized way to plug tools into learning management systems was something that was still highly valuable and something we felt that we needed to build a standard around. So we founded IMS Learning Tools Interoperability (note the new “L” character in LTI).
IMS Learning Tools Interoperability was lead by Bruno Van Haetsdaele of Wimba. Wimba had taken an approach for their Blackboard integration to create a very thin building block that effectively “remoted” the common building block operations and used simple REST-based web services to forward the building block operations to their Wimba servers where they had much better control and flexibility. IMS LTI was initially set up to replicate this “remote building block using REST web services” as designed by Wimba . In addition we were going to look at Facebook’s API and iGoogle to insure that our interfaces would be easy enough to use to have people who would actually “like” using them. My personal goal was that it work in PHP – and not just Java and .NET.
Wimba took the lead in LTI and started building both software and the specification in the working group. Mark Ritter was hired to really push this forward. At one meeting, I saw a demo of working code that Wimba had written and I became interested enough to start building a Sakai implementation of the draft specification. By February 2008, things were really starting to get nailed down – I had taken several trips to Wimba HQ in New York City to do intense development sessions.
In March 2008, I proposed a Google Summer of Code project to get us
additional resources to crank up the project and get us over the hump.
About the same time, Blackboard showed the group their upcoming Proxy tool specification and offered it to the working group as a starting point for LTI. It was quite different than the approach we had taken in the Wimba version – but it was far more mature in terms of its scope. We did not have to switch to the BB9 Proxy approach – but after some thought it was really clear that we would gain more than we would lose by switching to the BB9 proxy approach. So we switched and went back to the drawing board in many ways.
Pearson had also been telling the rest of IMS about their TPI integration approach which was a REST-based launch and IMS-Enterprise inspired roster provisioning. While we were getting close to completing the Wimba led design for LTI, TPI seemed like it was too complex to bring into LTI. As we switched to the BB9 proxy approach, it was a great opportunity to align the IMS LTI with Pearson’s TPI.
During this transition, I had been awarded two students for the Google Summer of Code in 2008. But all of a sudden I no longer had a mature specification. So I quickly whipped up a non-formal specification which I called SimpleLTI which was a mashup of the ideas in the Wimba variant of LTI and the new Blackboard BB9 proxy specification. I effectively had to write a specification in a week so I could had it to my new students Katie Edwards and Jordi Piguiem-Poch who would be writing Sakai and Moodle implementations respectively.
I spent the summer of 2008 working with my SimpleLTI spec and my students. The rest of the LTI working group led by Bruno van Haetsdaele of Wimba, Lance Newmann of Blackboard, and Greg McFall of Pearson started going through the BB9 proxy approach, the Wimba approach, and TPI approach and unifying the approaches. For example, Bruno brought us the OAuth specification as a way to securely sign messages – which was great because my SimpleLTI spec (based on the Wimba version of LTI) had a flaw because I was not an expert on message signing approaches. Using OAuth let Google, Twitter and Facebook get message signing right and we could just use it.
By the end of Summer 2008, SimpleLTI was a pretty good spec – it was simple, clear and fun to use and write to. We have solid Java, PHP, and C# implementations. I had added production-ready code to Sakai for the tool consumer, Katie had build a series of nifty features turning Sakai into a SimpleLTI Tool Producer and Jordi had build a Moodle Tool Consumer.
We also decided to do a bunch of cool demos using Simple LTI for 2008 Educause with ANGEL Learning, Pearson, McGraw-Hill, and Microsoft. The demos were awesome – they demonstrated the potential power of the connection between IMS LTI and the IMS Common Cartridge specification. It showed a very simple and elegant way to have cartridges which referenced high-quality (i.e. not free) content in a cartridge – without having to include the content in the cartridge.
For me, I always knew that SimpleLTI was only a *temporary* specification and that at some point I needed to “kill” SimpleLTI and switch my efforts to the “Real LTI” under development by Bruno, Greg, and Lance in the working group. After the Educause demos, i pretty much decided that SimpleLTI was done and that all of my future work needed to work toward the ultimate real specification.
So I dove into the real LTI specification and I saw that it was a *lot* more complex than either the Wimba Design or the SimpleLTI design. It had a lot of great technology inside of it but it was way too big to be “fun” to implement. So my first reaction was to go through an exercise to “subset” the LTI specification and pulling out the particular elements of LTI that mapped to the scope of the SimpleLTI specification – and I called this notion “Basic LTI”.
As part of this exercise, I was finding places where SimpleLTI had a different approach than LTI. Since I had been deep in SimpleLTI, I always assumed that SimpleLTI was right and LTI was wrong. Lance Newmann and Greg McFall patiently talked me through each of the conflicts and educated me about the right way to model data and model interactions.
One by one, we walked through the differences and the Basic LTI subset of LTI (we now called this “Full LTI” in the working group), we ended up with a very nice specification that had a nice architecture and a spec that was easy to implement.
After I had taken all of the input and developed what I figured was the final version of Basic LTI, we then we back-pushed all the concepts into LTI so that Basic LTI would be a perfect subset of LTI when LTI was finally released. Since I am impatient, I always am ready to ship when something is “good enough” – but with Lance and Greg – “good enough” was simply not good enough. It had to be elegant. And they made Basic LTI elegant.
Now that Basic LTI is in internal draft in the IMS Global Learning Consortium and members are quickly building compliant and interoperable implementations and opening up a new market for interoperable tools hosted outside of LMS systems, I just want to publicly thank my friends and mentors that have helped me and taught me so much on this journey:
- Bruno van HaetsDaele (Wimba)
- Greg McFall (Pearson)
- Lance Neumann (Blackboard)
As first the industry, and then the end-user teachers and learners benefit from the several years of dedicated engineering that went into IMS Learning Tools Interoperability – I just want to make sure to recognize and thank the people who never gave up on the idea – meeting weekly for nearly two years – to give this great gift to us all.