Here's how some of the participants described the effort and its results:
Interested in the LMS market? Sign up to receive more information about our LMS Market Analysis service, including a free sample newsletter!
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.