Mashing Up the LMS the Google Way

I have mentioned before Cambridge’s My Sakai project which, writ large, can be seen as an attempt to make Sakai more compatible with Web 2.0 by supporting development of widgets, gadgets, Facebook applications, and so on. Well, they’ve made some substantial progress of late, inspired in part by the Apache Shindig implementation of Google’s OpenSocial API. They’ve created a development paradigm that mostly eschews Java in favor of the HTML, Javascript, and RESTful web services that most Web 2.0 developers will find very familiar. The work, still very much in the experimental stage, recently culminated in a four-day workshop in which 4 Sakai schools (Cambridge, Michigan, Georgia Tech, and U of Toronto) created a new and more user-friendly interface for file sharing within Sakai.

Here’s how some of the participants described the effort and its results:

So, one aim of the Cambridge Get-Together was to see whether it would be practical in future to develop some Sakai tools using primarily JSON, Javascript and HTML. Another aim was to tie this in to the work that Ian Boston has been doing on implementing JCR-170 for Sakai. The hope was that by the end of the week we would have developed a proof of concept, and have a clearer idea of whether this development methodology might be used in the future for Sakai. A consideration in investigating this approach was a desire to expand the community of contributors and make Sakai development accessible to a wider skillbase. In particular, we hope to enable people with Javascript and HTML skills to develop tools with the support of Java developers developing services. During the Get-Together, we had 1 person working on the Java code, 1 UI designer, a quarrelsome stakeholder, 1 HTML / CSS designer, and 4 Javascript / JSON developers.

With only a few days it would have been difficult to produce a tool that not only worked but that was also a genuine improvement in terms of UI and functionality! We were very pleased by the results as a proof of concept, and thanks to Erin’s work it also looked very good, but this work could not and should not be seen as a replacement for the Resources tool, the Resources Viewer or the Image Gallery.

By the end of 3 days of development, we had a proof of concept “file manager”, with the following functionality

• upload multiple files simultaneously into a JCR-170 content repository
• display two different views of the contents of a Sakai site
• create ‘Collections’ (or categories for grouping content)
• assign files to collections

Keep in mind that (a) this is a much more ambitious development project then developing your typical gadget and (b) the group was not only developing the solution itself but also refining/debugging the toolset upon which the solution was built at the same time. Ian Boston, one of the principal developers of the toolkit, told me in an email that a typical application would take about 8 [hours] from paper to production for someone who knows their way about. Simpler applications are much quicker, e.g., the Quick Announcments [application] took 50 minutes to create and deploy into production.” That’s consistent with what I know about typical widget development for other environments. If this makes it into production Sakai, then it could really unleash the long tail of teaching applications. We’d be at the point where hobbyists could build a single-purpose widget in an hour or two or an application of typical Facebook-level complexity in a weekend.
There’s also potential here for much more rapid improvement in Sakai’s usability. The Cambridge Get-Together basically took existing content management services and, in four days, built a rich new interface for it that handles fairly complex user interactions. All of the various accounts from various participants mention that the approach really let them focus a lot more on user experience. It wouldn’t eliminate Java development for more complex apps, but it would encourage Sakai Java developers to move further in the direction of creating web services that developers without Java knowledge can (re-)use.
But I’m most excited about the potential for this to go beyond Sakai. Take a look at these data services from the Widget Development Manual wiki page:

Url	Description
/sdata/mcp	List of courses and projects of the currently logged in user.
/sdata/me	Information about the currently logged in user.
/sdata/mff?search=query	Search for files that contain the query.
/sdata/mgs?search=query&siteId=siteid/all.	Search for everything that contains the query within the current site or with in all your sites.
/sdata/motd	Returns the Message of the Day.
/sdata/mra	A list of what recently happened within my worksites.
/sdata/site?siteid=siteid	Get info about a specific site.

These services are collectively being called the “SData” API, no doubt in homage to Google’s GData. But you could just as easily call this LMSData, because it looks very generic to me. Any LMS could implement it, leading us to the possibility of an educational gadget standard. It could, perhaps, be a superset of OpenSocial; Ian is thinking about adding OpenSocial APIs (especially the FOAF stuff) to his implementation. Such a standard (maybe we could call it “TeachIn”) could also be supported in a reference implementation under a commercial-friendly open source license, like Apache Shindig. This would have a number of positive effects:

• Teachers and students who know a little web programming could create simple applications that could be used in any compliant LMS.
• Developers of non-LMS apps (whether it be Facebook or Peoplesoft) could begin to pull data from the learning environment in to other places where it would be useful to people.
• We’d have a set of APIs that could really support the creation of a first-generation PLE–not as a replacement for the LMS, but as a very rich extension of it.
• All LMS developers would be pushed in the direction of creating frameworks of re-usable services.

All in all, this is very promising work.