This post is part of a series on the concept of a Learning Management Operating System.
I have argued in this series that the heart of an LMOS should be a portal. The main reason I have given so far is that a modern portal is well suited to handle the long tail of specialized learning applications. But portals have many other virtues as well. For a good overview of the benefits it offers to a higher education environment, check out this report [PDF] put out by The Observatory on Borderless Higher Education. In the specific case of an LMOS, the second virtue that I want to highlight is flexible groups functionality.When defining “groups”, most LMS designs are dominated by the metaphor of groups of people on a physical campus. In particular, they usually focus on groups of students within a class and on extra-curricular clubs. This is all well and good, but it misses a critical dis-analogy between the social concept of groups and its implementation in software. In a computer program, the concept of a “group” determines access privileges, which often doesn’t map neatly to those social groups. As a result, if I want to, for example, make a document (and just one document) available for an ad hoc collection of people to review (e.g., a few colleagues who are reviewing an article before publication), or share it across classes or sections of a class, there is often no easy way to do it. As these cases arise, programmers can create work-arounds and patches, but these become increasingly awkward and time consuming to implement. I suspect that this limitation is one of the reasons why Blackboard has developed their Content System as separate application from the main LMS with a separate (and far more flexible) permissions structure.
Another area in which the rigidity of LMS group designs can become problematic is administrative permissions. Suppose, for example, that you have a multi-campus system and want to delegate the ability to create courses (but not other site-wide administrative privileges) to campus coordinators. In many LMS’s, these permissions are hard coded and require programming to change. As these systems have evolved and been patched and improved, specific customer demands have often driven the addition of certain flexibility in assigning admin privileges for specific areas. But the areas of flexibility are usually limited and often unpredictable because they were ad hoc.
In contrast, because portals are intended to be useful for a wide range of applications, the permissions and groups structures are usually very powerful and very general. In most cases, any application (or “portlet”) that properly uses the portal’s permission structures should be flexible enough to re-scope for arbitrarily defined groups without requiring programming. For example, in the case of our campus administrators, making the change should be as simple as the portal administrator using the administrative interface to create a group called “campus administrators”, assigning that group certain administrative permissions in the course creation applications (which may be additionally scoped to the group that defines their campus), and assigning the appropriate people to the “campus administrators” group.
Another advantage of using a portal’s native permissions and grouping system is that it encourages student- and faculty-centric design rather than course-centric design. In traditional LMS’s, each course is its own island. I may, for example, be in five courses with five different calendars. Over time, LMS designers have realized what a pain this can be and have, on created roll-up views for some functions. Many, for example, now give the students unified calendar views for their course so they can see all their assignments due dates, exam dates, and so on in one view. Again, though, this is ad hoc. They may, for example, provide a roll-up of calendar events but not of new posts on all the discussion boards to which a student has access.
A portal, on the other hand, provides a generalized mechanism for application designers to add roll-up capabilities to their portlets fairly easily. Behind the scenes, there is only one calendar application (for example); each event added to the calendar has permissions that are scoped to a group. So, for example, the calendar portlet that shows up in the “History 101” space will look to see which calendar events have been assigned to the “History 101” permissions group and display only those events. On the other hand, the calendar that shows up on a student’s “MyLMOS” tab will show all events for all the permission groups to which that student belongs.
