e-Literate

Present is Prologue

Tag: portals

  • The Portal is the Platform, Part III

    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. (more…)

  • The Portal is the Platform, Part II

    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. (more…)

  • The Portal is the Platform, Part I

    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. (more…)

  • Is Sakai a Platform or a Product?

    Ben Brophy, a UI designer at MIT, muses about whether Sakai is a platform or a product. His initial answer is that it should be both. But he worries about the implications of having it as platform:

    The conference ended with a Q&A session with the Sakai board members. I asked how decisions about what’s included as the ‘core tools’ will be made. The response I got from one board member was “I’d like to see Sakai include six discussion boards. The user can try them all and decide which they like best.” No other board member disagreed.

    That’s been bugging me ever since. Even assuming that each school’s IT department will pick a default set of tools (a possibility mentioned by the board member), does it make sense to have Sakai include every tool built? Can there be no standards for inclusion? If I’m developing a new attendance-taking tool that I want to be able to post grades, what do I do if there are 6 gradebooks?

    This isa problem, for sure. But it’s not one that I’d be looking to the Sakai community to solve for me. (more…)