I have been working with Joseph Berkovitz, the CEO of NoteFlight (www.noteflight.com) getting his software to support the IMS Basic LTI Producer specification. NoteFlight is a tool designed to teach music. Instructors can make assignments, perhaps giving them a partial composition and then students can compose and play music, handing in the assignment when done and then the teacher can again go back in and grade the student submissions.
For the impatient or those uninterested in the glorious philosophical and technical detail about how this was done, here is an awesome demo of NoteFlight in action running inside of Moodle using the BasicLTI4Moodle consumer for Moodle 1.9:
YouTube (lower quality): http://www.youtube.com/watch?v=kpPZ4osXJO0
Thanks to Joseph for sharing his demonstration with us.
This is the perfect example of a whole class of tools that are rather narrow when the entire teaching market is considered – but absolutely essential for teaching certain kinds of courses. Because of the narrow nature of the overall market for a tool such as NoteFlight, and the likely lack of financial clout for the teachers of those classes, it is not likely that a school will pay a large amount of money to integrate something like NoteFlight into their LMS system – so teachers and students would simply have to make new accounts on the NoteFlight site and keep track of separate passwords.
Of course, this is the kind of tool that we see IMS Basic LTI making possible. By reducing the cost of integrating into LMS systems to virtually zero and making it possible to place a tool in pretty much any LMS system with one integration, it allows tools like Noteflight to be made available to those courses that badly need the tool and keeps the costs of building NoteFlight low to allow NoteFlight to invest more in the tool itself rather than chasing after lots of LMS integrations just to get some business.
If you look at the demo, you will see an exciting implementation pattern in the NoteFlight support for IMS Basic LTI. It uses what we call “resource_link level configuration” where all instructor configuration is done on the NoteFlight servers (i.e. inside the frame). The use case is that the Instructor simply placed a generic “NoteFlight” tool as a Moodle Activity and then enters the tool and sets up the assignment. Under the covers, NoteFlight is detecting a new “placement” and keeps this new placement separate from all other placements. So the instructor can place many instances of NoteFlight in their course map and configure each separately.
What you don’t see is that if the instructor placed the activity and then did not configure it, and the student launched it, NoteFlight would say something to the effect of “not yet configured”. But since it is so natural for the instructor to place and then enter the tool, the configuration step just happens in the normal course of setup and the student simply never sees the tool in an unconfigured state.
It takes a while before folks used to writing deep integrations like a BlackBoard Building Block, Moodle Module, and Sakai Tool get the simple elegance of this approach. Most tool developers want to fight with the LMS until their particular and weird configuration needs are properly done in the LMS user interface. The problem is that then the end-user experience is under control of the LMS and they may change it or break it in some future release. Also, it really simplifies writing tool documentation. All of the configuration screens are the same for a tool like NoteFlight – regardless of which LMS it is running in, making documentation simpler. Tool writers kind of have been taught not to feel empowered when facing the daunting task of LMS integration. IMS Basic LTI gives tool writers far greater control over the user experience – which in my opinion is as it should be.
All in all, I want to thank Joseph for his excellent work and helping explore the capabilities in the IMS Basic LTI Specification (www.imsglobal.org).