LMOS Integration and Specialization

This post is part of a series on the concept of a Learning Management Operating System.

In my last few posts, I argued that a next-generation learning management platform should have the following characteristics:

• It should provide a framework that makes it as easy as possible for programmers with different skill levels in different programming languages to build and integrate learning tools that will serve specialized teaching and learning needs.
• Whenever possible, the technology standards implemented by the framework should be general rather than education-specific in order to encourage the re-use of relevant groupware applications that weren’t originally designed for e-learning purposes.
• Part of what the framework should provide is a set of user interface primitives, thus reducing the usability challenge of mixing together applications that were designed by different groups of people. But those primitives should be inheritable by applications with as little specific programmer effort as possible, i.e., they should mostly come along automatically when the developer chooses to use the framework.
• Another part of what the framework should provide is strong and flexible groups, roles, and permissions structures to be used by the various learning applications.
• The roles, groups, and permissions framework should also provide the capability of a user-centric view in which users can get roll-up views of data in applications that they use across several different groups (e.g., the combined calendar dates in several courses plus club and campus events).

I have claimed that all of these goals can be met by using a modern, JSR-168-compliant portal as an architectural basis.

But two questions naturally arise. First, don’t we need any inter-application integration? Second, to the degree that we do need that integration, does it need to be done using specialized, e-learning-specific APIs? Depending on how the goals defined, I think the answer to both questions is “less so than you might expect.”To begin with, some applications don’t need any more in the way of integration than we already get from the portal. For example, suppose you want to present an RSS feed of relevant content to the students in my class. The system only needs to know that there is a window, called “Professor Jones’ Psych 101 RSS Feeds”, that needs to appear on the Psych 101 class page. It doesn’t need to care about what is in the window, and the application in the window doesn’t need any data from the larger system, either. If you want to get a little fancier, you could have a notepad application that is aware of the permissions structure. When you take notes in the respective notepad windows on each of your various class pages, those notes are all rolled up (and appropriately sortable by class) in your MyLMOS tab. So for these sorts of stand-alone applications, no further integration interfaces are necessary. That’s good, because the fewer integration interfaces that are required, the easier it will be for people to write new e-learning applications, and the more likely it is that you’ll get a proliferation of different useful applications.

But sometimes you do need more integration to build a useful e-learning application. How much more depends on your goals. Let’s assume, for the moment, that our goal is simply to replicate baseline capabilities common to current LMS’s on the market, but to do so with a framework that allows maximum flexibility for the addition of new and better learning tools and that also maximally re-uses other quality source code that is relevant to solving e-learning problems but is being written outside of the e-learning community. (I will raise the bar for the goal in subsequent posts.) For this goal, I can only think of two essential integration points, one of which is generic and the other of which is e-learning-specific.

The first pillar of integration is the calendar. Since the vast majority of of instructor-facilitated e-learning courses have a temporal arc with temporal bounds, one of the crucial types of information you need to communicate about with your students is dates–opening dates, closing dates, due dates, and so on. In addition, if you have functionality like timed tests or selective release–both of which are necessary to meet our goal of replicating baseline LMS capabilities–then you need your applications to be calendar-aware, and you need a user interface that allows faculty to manage this functionality. It’s best to build one central calendar function once and allow each relevant application to integrate with it rather than having each application implement its own, separate calendar functionality. Fortunately, there already exist technology standards for calendar integration. So a designer of an LMOS application that needs this functionality should only need to know that the system (or distro) will have some calendar application that utilizes, say the iCal/vCal standard.

The other important integration point that’s required for baseline LMS functionality (although it has only rarely been implemented well in any existing system that I’ve seen) is grading/evaluation functionality. Basically, any student contribution to a course should be able to take a grade and/or an instructor’s comment as metadata. This includes things like assignments and tests, but it also should include, say, discussion posts. And in order for this functionality to be practically useful, we need it to be easy for the instructor to add a grade/comment and easy for a student to access the grade/comment. So ideally, any LMOS application that enables student submissions should be able to associate grade and comment metadata with each submission, and a gradebook application should be able to aggregate, categorize, and release this information. For example, a faculty member might see a student’s discussion post, click on the “grade this submission” link next to the post, and assign a grade or comment on it. At that moment, the instructor should also be given an opportunity to verify that the evaluation information is being filed under the appropriate assignment column in the gradebook or, if it’s a new assignment, create the appropriate assignment column. At any time in the future, the instructor should be able to go into the gradebook and release the grades and comments to the students. This, obviously, is e-learning-specific, so we’d need a specific application programming interface (API) to be defined for it.

I can’t think of any other integration points that would be essential for hitting the goal defined above (though I encourage you to comment on this post if you think of something I’ve missed). I think that a system meeting these goals could be assembled out of standard, existing, Open Source parts in a relatively short amount of time and with a relatively modest amount of programming effort. I believe it would be roughly competitive with the current releases of, say, Blackboard, WebCT Campus Edition, or Sakai. But personally, I don’t find that benchmark to be especially compelling, even if we also achieved the other goal of maximum flexibility. I’d like to raise the bar a bit higher and look at adding some more interesting teaching and learning subsystems into the mix. Specifically, we need a well-conceived learning content management system and a learning process management system. I’ll be talking about both of these components over the next several posts in this series.