The OpenDocument XML.org web site is not longer accepting new posts. Information on this page is preserved for legacy purposes only. For current information on ODF, please see the OASIS OpenDocument Technical Committee.
Earlier, I covered some interesting new characteristics of Sakai 3, but want here to add another. Existing LMSes are hamstrung by a number of assumptions and limitations. To sum them up, today’s LMS tends to be both course-centric and tool-centric. If, for example, students that share two or three related courses want to setup a group, they can’t do it; the LMS assumes students are part of courses (or in some cases, non-course sites). Similarly, the LMS experience is constrained by a focus on discrete tools. If you want students to reflect on some ideas, and then host a discussion on them, you need them to go to two separate places: some webpage-like thing that describes the ideas, and then a separate forum where the discussion may happen. If the student wants to refer back-and-forth between the two areas, they need to do awkward things like open two windows or tabs, or do the browser back-and-forward button thing. This is a totally artificial limitation that has real consequences.
Thankfully, Sakai 3 does away with these limitations. Groups, for example, may exist independently of course and sites, and so will allow more flexible sorts of online sociability and collaboration among students, researchers, and so forth. On the tools front, Sakai 3 breaks down the walls that have previously divided them. If you want to host a discussion on some content, you can simply create your page, add the content, and then at the bottom of the page add a “discussion” widget. Upon doing so, a discussion thread will be available at the bottom of the page for students to view and contribute to.
The current UI has widgets for a variety of common features: polls (complete with a nice instant-view graph of the results), comments, quizzes, etc. But it also has some clever new ones, such as a Google Maps widget that allows you to embed a live Google Map (though as I geographer, I have to say that I’d really like to see more here, like the ability to ask for a country, and have it understand what I mean; this might be more a limitation of Google Maps though).
Here’s an example of what this looks like with the polling widget. First, we decide to add a poll to our page. We go to the “insert more” drop-down on the right side of our editor …
Once we select “poll” we get a dialog to set it up.
Note that this dialog pops up in place; no need to go to some separate page to manage this. Once we have it all ready and click “insert widget”, and save the page, we then see this, which is also what students will see …
When a student comes across this, again, they don’t have to go to some separate place to take the poll; they simply click their choice in place. Even more cool, once they’re done, the live widget presents the results of the survey in a graph view.
In turn, this graph will continuously update as other students take the poll!
A couple of months ago, Lance Speelmon at Indiana University presented a demo of this at a Sakai conference in Japan. You can see that starting at about the 23 minute mark or so of this video:
So let’s pause for a second and ponder the implications of this: I will be able to create a page for some topic in a class. I can add some text to present the issues for the topic and link to some background readings. I can then embed any other widget I want right there in the page! Bigger picture, this widget architecture is designed to be easy to work with for developers. So if I have some idea for a great new widget, any on-campus developer with basic web development skills could hypothetically help me create that widget.
When I started pondering what I want in a next-generation LMS, this is exactly the sort of thing I was imagining!
So in trying to come to a conclusion on Moodle vs. Sakai, it’s easy to get wrapped up in the minutia of feature comparisons and such. It seems to me, however, it’s important to keep in view the larger, longer-term, picture. In this case, that in part involves the strategic directions for these two projects, which will give us a sense of where they might be in five years. To wit, below is my understanding of Moodle 2 and Sakai 3. Am in a bit of a hurry with end of semester chaos, so please correct me if I have anything wrong here, or if I’m missing important details.
As I read it, Moodle 2 is a significant change to the platform, but a largely incremental one. The primary change appear to be the addition of a repository API, which provides a flexible way to add access to different kinds of resource repositories. For example, there is a plug-in that uses this API to make it easy for users to browse and insert images from Flickr from within the standard Moodle editing tools. In addition, there is work on new features, many of which are outlined in the following video:
In other news, there appears to be independent work on making Moodle friendly for mobile devices. Here’s a video of one such example:
From what I can tell, Moodle 2.0 will be ready for deployment sometime later in 2011.
Sakai 3, on the other hand, is a more radical change: effectively a complete rewrite of the platform. This rewrite involves building the Sakai-related functionality on top of other, more generic, open source code. The new core code, and hence what the Sakai community is responsible for maintaining, is dramatically less than the old; at present a reduction of close to 90% of the code base! In addition, one of the core developers on the new Sakai core has also become a developer on the Apache Sling project on which the Sakai 3 core is based. This reflects some smart strategic decisions, and should provide a focused, easy-to-develop and maintain foundation.
Following are a few examples we can glean of what this might look like from the design wireframes (visual mockups, not necessarily running code at this point) and the running demo code.
Example: Everything is Content
Michael Feldstein does a good job explaining what this all means. But perhaps some pictures will make the implications more immediately apparent. Consider search. Because existing LMSs are both organized based on courses and tools, its quite awkward to search for content (forum posts, blog posts, assignment or page content, etc.) globally. On the other hand, consider this proposed search UI for Sakai 3: So one does not go into, say, a forum and search the forum. Rather, one has a search interface that is the same whether you search the entire university’s content, or an individual course. That integrated search interface looks beautiful, and will be instantly familiar to anyone used to using contemporary web interfaces.
A few more screenshots follow below, these all from the actual current Sakai 3 demo server.
Example: Widgets for Integrating Different Content
The new interface is based on widgets, which allows you to quickly add different blocks of features, and move them around as well. Because of the new core foundation, these widgets are also designed to be really easy to develop, so that it’s much easier to add new functionality. In this view, for example, you see a “widget” I’ve added to access my Google Docs documents from within Sakai.
One design priority for Sakai 3 is to make editing content much easier. Here we see the clean new editing interface.
In addition, all content is versioned, so that you can easily step back through changes, and see who made what changes. Since all content is treated uniformally in Sakai 3, there are no artificial limitations in how this versioning support can be applied. Here’s what it looks like the UI currently:
What I get out of all of this is that Sakai 3 will be more scalable (faster), more flexible, more elegant and easier-to-use: a brand new LMS designed for the needs of the 21st century. The devil will still be in the details of exactly how they implement specific features (gradebook, assignments, etc.) on top of this new core, but I am also really encouraged by what I am seeing of the design process. It demonstrates an attention to detail that is necessary to do this right.
The current roadmap is that it should be ready for large-scale deployment sometime in mid-to-late 2011 [I corrected the year from 2012, per comment below]. Also, there’s some work going on (at Indiana?) in allowing mixed 2-3 deployment; using v2 tools within a v3 context for example.