This post is part of a series on the concept of a Learning Management Operating System.
In my last few posts, I argued that accommodating niche learning applications is an important part of the next wave of LMS design, pointed to Google Maps as an example of a niche application that’s designed to be easily integratable, and pointed to Apple Dashboard as an example of a framework for integrating niche applications. Now I’d like dispense with the analogy and talk about the correct foundation for an LMOS integration framework: the portal.If you want to experience a modern portal is from a user’s perspective, just go to My Yahoo!. You’ll see a bunch of boxes on the page–one with your stock quotes, one with your weather, one to look up phone numbers, and so on. In other words, each box is a window into an application, much like a Dashboard widget. You can rearrange the boxes on the screen, add new ones, take old ones down, and sometimes even configure preferences for particular boxes.
Now, when you’re building a platform for which you want developers to create applications (like either Dashboard or a portal), you want integration to be as easy as possible (lowering the barrier for entry) and you also want, whenever possible, to use industry standards, so that you’re not asking developers to learn skills that won’t be useful for any other purpose. In the case of portal applications, there are two relatively new standards that aim to accomplish these goals. To begin with, there’s the Java community’s JSR-168, or “portlet” standard. JSR-168 is a standard for integrating applications into those little boxes, or portlets, on your portal pages. Because a wide range of portal products–including FOSS projects like Liferay and Apache’s Jetspeed as well as closed source products such as IBM’s Websphere and Oracle’s 9i Portal–support JSR-168, developers can build portlets for one and know that they will be able to run on a wide range of portal platforms. JSR-168 is also intended to make it easy for developers to create portlets using the tools and styles with which they are most comfortable, starting with the trivially easy. If all you need to do is put a page in an iFrame, you can do that with JSR-168 very easily. Likewise, it’s trivial to display one or more RSS feeds. If you need to do something more elaborate, you can write portlets using Java servlets, JSPs, or XML/XSL. You can even build portlets using PHP or Perl if you so desire. There are also small but growing collections of FOSS and closed source JSR-168 portlets that you add to your portal, like the ones here, here, here, here, here, and here.
If you can’t find an existing JSR-168 portlet that does the job for you and none of the JSR-168 development options suits your fancy, then you can draw on a second portal standard, called WSRP. WSRP is a standard for building a portlet using XML. It can be written in pretty much any programming language, and the portlet application doesn’t have to be hosted on the same server as the portal itself. So, for example, you could run a .NET portlet in a Java portal using WSRP. Many of the Java portals that support JSR-168 also support WSRP.
So, to my mind, the heart of an LMOS should be a JSR-168- and WSRP-compliant portal, because it can accommodate the long tail of learning applications through ease of integration.
Now, a couple of caveats. First, just because one can technically integrate portlets written in many different languages into a common portal doesn’t mean that you should. There are practical limitations in terms of performance and support. I’ll address some of these considerations in a post some time down the line. For now, the main thing is to remember that great flexibility is not the same as infinite flexibility. Second, having a My Yahoo! equivalent with a bunch of learning applications does not, by itself, make for a decent LMOS. You’re going to need to integrate some of the applications with each other, you’re going to need some more system-wide behaviors in place, and you’re going to need to enforce at least some common interface conventions. That said, I believe that these challenges–particularly the level of inter-application integration required–are often over-estimated. I will argue over the next few posts that it is possible to create a seamless learning environment in which there are only a few, fairly loose points of integration. This will be essential if we are going to break up the monolithic LMS.
In a portal like My Yahoo the portlet is not the application, it is a little feed that leads you into the application. Click a stock quote and you leave My Yahoo and got to Yahoo Finance. Yahoo Mail has a portlet but it’s just a window that tells you how many unread message you have, if you want to send a message, you click a link in the portlet leave My Yahoo and move to Yahoo mail.
So wouldn’t it make sense to develop applications so that they operate independently of the portal, but can send a small preview of their contents over to a portal? Sakai tries to be the portal, and assumes that EVERYTHING happens in that portal, you never leave.
This seems like a mistake, perhaps the best way to integrate UPortal is not to build into Sakai, but export views of Sakai to UPortal via JSR-168. Sakai doesn’t need to be a consumer of JSR-168 (I believe that’s the current plan) rather it can just export little windows into it’s functionality to a larger university portal, that might also include portlets from the school teams, dining services, whatever. That way Sakai tools (quiz and gradebook, say) can share a class website together, and be happily talking to each other, while also each sending a preview to the school portal.
Of course you’re right about the My Yahoo! portlets; I meant to use them only as a course-grained example of the portal user experience for people who are not familiar with modern portals. But you make an important distinction.
One of the advantages of having the applications live completely within the portal rather than having people click out to them is that it enforces some consistency in UI. By drawing on standard portal controls, the applications will automatically behave similarly for things like minimizing and maximizing windows, location of the contextual help button, etc.
So, regarding Sakai, I agree that Sakai made a mistake by trying to be a portal, but not for the same reasons that you do. I have no problem with everything being in the portal. My problem is that, if Sakai is going to take the portal-is-the-platform approach, then they should use the already existing and excellent uPortal rather than re-inventing the wheel. Making Sakai into its own JSR-168 consumer doesn’t solve the fundamental design problems of Sakai being (a) too unecessarily heavyweight as a framework, and (b) too narrowly conceived in terms of its permissions, groups, and roles. I would much rather see Sakai broken up into uPortal applications and let uPortal handle the main display, the session management, and the grouping.
Michael, not like you need more work, but I came back to this article recently and to my chagrin found that the majority of URLs you had collected around currently available JSR-168 portlets came back 404. Normally I would just move along and write this off to the aging of the web, except I think this issue, the availability of JSR-168 portlets, is not a trivial one, and in trying to assess the traction of JSR-168-based approaches it would be helpful to know what educational developers can draw on. Any ideas where to find large collections of these? Cheers, Scott
Thanks for calling my attention to this, Scott. The proliferation of FOSS JSR-168 portlets has been somewhat slower than one might hope, for several reasons. First, A number of the portal systems out there had legacy non-standard portlet specifications with many tools already developed to them, so the move over to the standards has been slow. It is comeing, however. For example, uPortal 3.0, due to be released imminently, has native support for JSR-168 and only rudimentary support for its legacy non-standard channels specification. The second problem is that the JSR-168 standard doesn’t offer as robust options as some of the non-standard solutions. This is also being worked on, with the second-generation JSR-286 and WSRP 2.0 standards both near finalization.
At any rate, in terms of finding JSR-168 portlets today, you can check out the JA-SIG Clearinghouse (registration required), the Jahia portlets repository, the Java.net portlets repository (currently a bit thin on entries), and the JBoss Portlet Swap. There are also some relatively large FOSS and proprietary applications that are compliant, such as the excellent Alfresco content management system (FOSS) and the QuestionMark Perception test engine (proprietary).
I should add that it’s fairly trivial to put an RSS feed or mashup (as an HTML fragment) into a portlet, so most of the Web 2.0 stuff that people have been playing with should move over into a portletized environment roughly as easily as putting it into a plain old web page and play side-by-side with the more sophisticated (and heavy) fully portletized apps.