Child pages
  • Vision for Next Generation LMS
Skip to end of metadata
Go to start of metadata

A Strategic Vision for SakaiNG
** DRAFT **

Editorial Note (2/19/2014):  The following are notes developed by Joshua Baron and reflect his initial and early thinking around a vision for the next generation Sakai.  The intent at this stage is to simply surface this early thinking as means to stimulate a broader dialog.  Also, many of the terms used below come from the Sakai Learning Design Lens work which were developed in 2010-11 by the Sakai Teaching and Learning Group.  We have linked key terms used here to the Learning Design Lens definitions as a reference for those not familiar with that work.

Overview

Sakai recently celebrated it's 10 year anniversary.  Over the past decade it has not only achieved tremendous success as a project and product, it has had a strategically significant impacted on the entire global Learning Management System market place.   From open standards such as LTI to just the concept of openness in education, Sakai has been a driver for a great deal of innovation and change in the industry.  At the same time, it is important to recognize that Sakai was launched before Facebook, YouTube and the iPad which have been important mile markers on the wildly steep and curvy "information superhighway" that we've been speeding down now since the beginning of the Internet that point to the constant need for technology projects to be re-inventing themselves in order to remain relevant in this super dynamic market.

The following outlines early thinking around one possible direction for Sakai to take as we continue down the road we began 10 years ago and work to remain relevant over the coming decade. Central to this vision is the concept of disaggergating or "unbundling" the Learning Management System which has been discussed by many over the past few years but which has yet to be realized in any fundamental way within the LMS industry.  As an open-source project does not need to be concerned with profit-margins and shareholder expectations, we are uniquely positioned to play a leadership role, as we have over the past decade, in realizing such a vision and the innovation that it could bring to the market. 

Again, this is early thinking from one person and meant to stimulate broad discussion and debate.  Please share your comments below or add your ideas to the page itself.

Why unbundled the LMS?

  • Provides users with the ability to "install" their own learning apps to create a personalized learning environment
  • Facilitates the ability to swap out "learning devices" as means to replace major categories of capabilities easily and efficiently
  • Increased choice and ability to customize more significantly

Core Values

  • Truly Open - We believe in truly open systems that go beyond marketing hype and provide open source code, open communities, open APIs, open standards, etc. which support tools that are both "consumers" as well as "providers"
  • Delightful User Experiences - We believe that powerful learning capabilities developed on robust code are useless unless the user experience is one that delights to the point of users wanting to use the system more and more over time
  • Cloud-Ready Scalability - We believe that the Next Gen LMS will need to be highly scalable within cloud environments that can facilitate use by large number of users and sharing "above the institutional layer".

Core Learning Services

Core Learning Services that are (or will be in the future) fundamental to teaching and learning, these might include:

  • Learning and Teaching Management, which would encompass:
    • Roles and Permissions (Individuals and Groups)
    • Event Messaging/Enterprise Service Bus
    • Data Capture and Secure Sharing
  • User Autonomy and Networking, which would encompass:
    • Profiles
    • Personalization
    • Academic Networking
  • User Interface, which might include:
    • User Experience Framework – Technical and UI specifications which are “enforced” by the Core Learning Services to ensure consistent UX.
  • Openness, which would encompass:
    • Open Standards and APIs
    • Interoperability
    • Open Licensing – ability to support use of Creative Commons licenses
    • Open Educational Resources – ability to integrate with OER projects, content, etc.

Core Learning Devices

Teaching and Learning tools or groups of tools which can be connected through the Core Learning Services, these might include:

  • Content Creation and Use, which would encompass:
    • Finding Content
    • Authoring Content
    • Managing Content
    • Publishing Content
    • Administering Content
    • Reusing Content
  • Learning Activities, which would encompass:
    • Application of Learning Theory
    • Sequencing and Workflow
    • Scaffolding and Guidance
    • Reflection and Metacognition
    • Portfolio Process
    • Learning Interactives
  • Learning Interactions,which would encompass:
    • Communication
    • Collaboration
    • Community
  • Assessment and Evaluation, which would encompass:
    • Grading, Rating and Feedback
    • Tracking
    • Documenting Learning
    • Reporting

Learning App Market Place

These would be user-focused learning apps which could be "installed" by individual users as means to allow them to create highly personalized learning environments customized to meet their own unique needs.  These Apps, which could be developed without extensive technical skills, could be made available through the Apereo/Sakai web site which could help create a revenue stream for sustainability.

Learning Cloud

A set of services and infrastructure that would sit “above the institution” and facilitate sharing, collaboration and research such as:

  • Instructional Content Repository
  • Pedagogical Best Practices
  • Research Learning Record Store
  • Academic Networking

 

  • No labels

12 Comments

  1. Here is the pice about the unbundled phone called phonebloks (yep it is spelled correctly) I spoke of in the meeting...-  https://phonebloks.com/en/goals

    1. Thanks, Dina.  it's a very interesting design model that is worthy of emulation. 

  2. The need for unbundling the LMS and allowing for "best of breed" external applications to integrate with it is clear.  But, as was brought up in the T&L discussion yesterday, unbundling of the LMS also has the potential to disrupt the workflow and relationship between learning tools.  While external applications may be "best of breed" in whatever they do, there is no guaranty they will do anything more than the minimum to connect to the LMS, let alone work with other external tools that are also connected to the LMS.  In fact, the incentive on the part of external tools is clearly to do everything they can to keep the user in their own areas as much as they can.  So, the question is what is the right balance between these opposing tendencies.  Most of it will depend on the functionalities built into the LTI standard.  But it seems to me that some of the enforcement of "good citizenship" among the external tools may be one of the purposes of the "Core Learning Devices" of the LMS.

  3. Thanks very much for posting these thoughts Josh, it's great to see a vision coming from outside of the purely technical arena. About 18 months ago I shared my own thoughts about what we needed to do for the future, met with an interesting debate in the comments: http://steveswinsburg.wordpress.com/2012/09/24/planning-for-sakai-2-10-and-beyond/

    From a technical and conceptual point of view, I don't think that much of this would be too difficult to implement. If we take a step back and look at Sakai as a basic shell that aggregates together a bunch of useful tools, each providing their own capability and APIs that others can leverage, we aren't far off the mark.

    We have previously discussed a way to structure Sakai as a pluggable system where you can choose the fucntions that you want, rather than having an all encompassing system with a bunch of functionality don't want or use. In this manner we would be able to swap out the functions for a better or different one. Don't like the wiki? Swap it out for different one and the system handles it for you.

    A few years ago we did a lot of the ground work for making this happen by decoupling the dependencies between the individual capabilities (tools). We aren't fully there yet and I see that as a good step towards achieving a fully decoupled LMS.

    Whilst I am a fervent supporter of LTI and the possibilities it affords, like Yitna I too am concerned about the consistency you get when you mix together tools from a number of different systems. Navigation, skinning and data storage issues all become much more apparent when the disparate services are aggregated together. I don't know what the solution is here, but I think that discussion is a crucial one to have.

    I look forward to discussions around the rest of the capabilities you outline as I think they are absolutely critical for a learning platform. Thanks for sharing!

  4. The future envisioned here is already a reality: students and faculty are using a variety of tools outside of Sakai, often with no integration.

    Let's assume that, at the present time at least, most campuses find it simplest to continue supporting a single LMS which can be extended through LTI and other integrations. One of the main reasons some schools chose OSS Sakai rather than a closed solution is that we can do local customizations; but many of us are now trying to scale back these customizations (it makes version upgrades very complicated), in part by offering non-Sakai tools as alternatives rather than trying to make the Sakai tools meet everyone's need. So if the future lies less in local customization of core Sakai tools and more in integration with external tools, then why Sakai? All of the LMS options can serve this same function. If Sakai's core functionality offers no unique, competitive value, it will fall by the wayside as a clunky relic.

    A few years down the road, will we still need a single central LMS as the core "glue" or portal for a variety of tools, or should we unbundle the LMS even more radically? We need to think about unbundling not only various tool functionality from the monolithic core, but also the user management functions. At Yale we are beginning an initiative that builds upon work that Duke and others have done in creating a "learning stack." One of the goals is to get Sakai out of the central brokerage function for managing/sharing administrative data related to course participants (rosters, user ID info, groups within a course roster). Faculty who want simply file sharing (via a campus-supported deployment of Box) and an email list should not need to go to a Sakai site stripped of all its core tools just to manage rosters and access control for those external tools.

    One final comment: in addition to LTI, the future will likely be shaped by developments such as the emerging "Tin Can" or "Experience" API for aggregation of activity data for analytics. The Sakai community is just beginning to explore this.

    1. A few years down the road, will we still need a single central LMS as the core "glue" or portal for a variety of tools, or should we unbundle the LMS even more radically? We need to think about unbundling not only various tool functionality from the monolithic core, but also the user management functions. At Yale we are beginning an initiative that builds upon work that Duke and others have done in creating a "learning stack." One of the goals is to get Sakai out of the central brokerage function for managing/sharing administrative data related to course participants (rosters, user ID info, groups within a course roster). Faculty who want simply file sharing (via a campus-supported deployment of Box) and an email list should not need to go to a Sakai site stripped of all its core tools just to manage rosters and access control for those external tools.

      This sounds like a service which could be provided at an institution's Identity and Access Management level.

      1. That's exactly how we're approaching it, Laura.  We've got an ambitious new IAM initiative underway on campus, and plan to leverage the native capabilities of Sailpoint Identity IQ (the platform at the heart of our IAM service) to achieve the group management, tool provisioning and integration functions needed to stand up this "stacked" approach toward learning tools. 

  5. Yes, we have to push the envelope to see how far this question of unbundling can/needs to go.  I wonder, though, about the first sentence in David's comment: "...students and faculty are using a variety of tools outside of Sakai, often with no integration."  If unbundling were to be taken to extreme, how would the question of integration be addressed?  Is integration (whatever we mean by it) the main purpose of any remaining core functionality?

    1. I agree that that is a, or even the, critical question, Yitna: how much integration is necessary, and what do we mean by integration?

      We will continue to need integration with centrally managed administrative data from our SIS and other campus administrative systems, that goes without saying: in fact, I think we will need to expand our ability to share this official registration data with a growing number of platforms and tools (opening up all kind of security issues that will need to be dealt with: just because we can share student enrollment data via LTI with cloud-based services, should we, and do we have assurance that those services are FERPA compliant?). 

      But beyond integration with user and group administrative systems, how much integration across tools is required? One of the assumptions of the Tin Can API approach is that the gradebook function is likely the first to be extracted from a central LMS and in need of integration with a variety of tools. If the gradebook function is no longer central to the LMS, then how do we define "core functionality" at the tool level?  Very few of our faculty use the Sakai gradebook to begin with....

       

  6. David, if on the one hand SIS and administrative data is to continue being centrally managed, how can the gradebook, – arguably the critical connection between teaching and learning activities and the administrative data (final grades for transcripts, etc.) – not also have to have a centrally managed component?  That's been an ongoing discussion for us at UVa with regard to LTI's grade submission capability.

    1. Our Registrar at Yale does not want faculty to submit official grades via Sakai, and we on the Sakai support side don't esp. want that responsibility either.  So currently we don't have any integration between the LMS gradebook and the official grades managed in SIS.  We're exploring the possibility for manual exporting the Sakai gradebook in a way that it could be uploaded to our official grades system.   The biggest obstacle for us is that within a single class, students can have multiple grading rubrics (pass-fail, letter grades, and even within letter grades some schools allow pluses and minuses while other schools do not) and only the official registrar's system is smart enough to know each student's appropriate grading options.  Sakai's gradebook does not and probably could not.

      More generally, I suppose my question about gradebook is whether Sakai is the proper or best tool for managing student grading when we're talking about integration of a constellation of tools and learning activities outside of Sakai proper. One variant of the Tin Can model extracts the collection of grades from the LMS and manages it through an external "Learning Record Store" (LRS), which could then vend the aggregated activity data back to the LMS but could also vend it elsewhere.  http://tincanapi.com/learning-record-store/  This is not to suggest that the LRS would not be centrally managed, but that it might be completely separate from the LMS itself.  So I'm asking what are the most critical aspects of an LMS that should serve as primary criteria for defining the central "hub" if we continue to feel that the solar system of learning tools needs a central "sun" around which and through which the others rotate.  
       

      1. It is very interesting to see the various ways institutions are handling grades and grade book management.  UVa has invested heavily into modifying the Sakai Gradebook to accommodate (among other things) both the possibility of multiple grading systems within a single course as well as the transfer of grades from the LMS to the SIS (although the later requires an additional step by the instructor on the SIS for security). However the grade is transferred, it seems to me there has to be some centrally controlled/sanctioned application to do it. And if that's the case, then does it make sense to say it's not part of the unbundled LMS?  (By the way, we hope to contribute our modifications in due time.)

        There was also some discussion in the T&L that a "meta-tool" for integrating the various external applications may also be something the LMS might provide. For example, an annotation tool for commenting over and making connections between, say, a discussion app here and a video archive there...  While this is certainly something an external application might be able to do for a particular cluster of tools, I wonder how robust it can be and positioned for the job compared to the LMS.  Anyway, "meta-tools" might be a class of tools to consider.