This post is part of a series on the concept of a Learning Management Operating System.
Ben Brophy raised an important point in his comment on my last post in this series regarding the different ways in which portals can be used with an application. As he points out, My Yahoo! just provides windows to external applications , while some other portals actually pull the entire applications into the portal itself. To be clear, I favor the latter approach over the former for LMOS designs. In other words, an LMOS should not just have a portal; it should essentially be a portal. There are a variety of technical, cultural, and usability reasons for this, some of which I won’t get into in this post, but the main one is related to the history of LMS design and why I think they generally have sucked so badly for so long. Basically, the historic design process for LMS’s has generally tended to look something like this:
- Look out at contemporary designs for generic groupware.
- Apply a brick-and-mortar conception of a class to the groupware designs and scale them down accordingly (while mixing UI metaphors and adding lots of eye candy).
- Re-implement the stunted version of generic groupware–badly.
- Dream up a few teaching-centric tools (like a gradebook or test engine) and throw them into the mix.
What you end up with is the worst of all possible worlds. You don’t get the best thinking in groupware design, you don’t escape and limitations in groupware design either, and you don’t escape the fundamentally limiting metaphor of the physical class. Not good.
Now, there are two FOSS LMS projects that have at least partly escaped this problem in very different ways, with interesting results. Moodle was basically designed from the ground up by teachers with a particular instructional philosophy in mind. It looks quite different from traditional groupware, in part because it is designed around very specific conceptions of instructional workflow (in contrast to the purely functional organization that generic groupware tends to take). The second interesting project is dotLRN, which is built as a layer on top of a fine, pre-existing developer’s toolkit for building community systems, i.e., groupware. As a result, dotLRN really functions as best-in-class generic groupware, and is sometimes used as such. It also has good instructional applications, of course, (some of the newer of which are really quite innovative), but at its heart, dotLRN’s feng shui is that of a very well designed groupware suite.
Ideally, you want to benefit from both approaches. You want to re-use the best thinking and the best code in generic groupware design while adding specialized layers that pull the user experience together in ways that are optimized for teaching and learning. The best framework for accomplishing this today is probably a portal. My own personal, highly unscientific survey has shown me that most new groupware applications are being developed as portlets. And since any standards-compliant portlet should work in any standards-compliant portal, that means there’s more code out there to be re-used. You should be able to take a discussion board that was part of the Liferay portal and stick it in uPortal (or JBoss Portal, or Oracle Portal, or whatever) instead. That’s good news. At the same time, because the portal controls the display layer of your application stack, you should be able to use it to create learning-centric organizational structures. (I know this last statement is a bit vague; I’ll be fleshing it out later in this series of posts.)
At any rate, while it would be possible to accomplish the above and not have to cram the entirety of each application into the portal, I think we want to avoid building e-learning-specialized components of the system except where there is a compelling reason to do so. The more functionality you can re-use from a generic portal framework, the less tempted you will be to re-implement it–badly–as a separate LMS component.
