If you’ve been an instructor or a student in a class in higher education in the last 10 years, you probably used a learning-management system or LMS. There are plenty to choose from, including Blackboard, Canvas, Sakai, Moodle and D2L. Many of these systems started as small, nimble startups but have grown into large “learning-technology” organizations as they have matured.
One of the biggest challenges with LMSs is that they are designed to support everything. From content organization to discussions, assessments, lecture capture and synchronous learning. This results in an overbuilt system with too many features that you may never use. It’s an 80/20 problem: You need 20 percent of the features, such as a standard webspace to point your students to a roster and gradebook, but 80 percent of your LMS just gets in the way.
Is an online synchronous chat room needed for a face-to-face class? Most instructors just leave that chat room in the menu, unsure of its purpose. The result is that this bloated software locks learning into restricted choices between suboptimal versions of features. There are many options for interactivity not included in your LMS you could choose, but the defaults are still there getting in the way. The problem with the LMS is the “M,” management. Learning software should facilitate learning, not manage it. Learning management reduces teachers to middle-managers between students and the registrar.
Micromanagement Migraine
Most institutions will change from one LMS to another specifically to improve upon their learning tools. At most institutions, a switch to a new LMS provokes two reactions: 1) it’s better than the old one, and 2) it’s more complicated and not intuitive. These reactions are both correct. Sure, software built from the ground up will incorporate new features that the old LMS scrambles to shoehorn in with software patches, but both are overbuilt and lock in choices about how learning should happen.
Michael Feldstein explains why our institutions keep repeating the same choices as a procurement problem in the recent piece, "What’s Really to Blame for the Failures of Our Learning-Management Systems." We have been through a couple of LMS migrations at different institutions and see what Feldstein describes: the committee evaluation and procurement process drive the discussions and decisions of which bloated LMS to buy next. That’s why the emphasis on a learning-management system needs to go.
All LMSs, both new and old, are overbuilt and lock learning into a complex suite of features that administrators and teachers spend too much time trying to figure out, customize and disable. In "What's Next for the LMS?" Brown, Dehoney and Millichap offer a framework of five primary functions of an LMS and call for a "Lego approach” where components can be fit together and pulled apart to customize the LMS. They are on the right path, but what we really need is not another LMS, but something very different. We need to focus on three features: agility, simplicity and interoperability and ultimately form a new learning operating system.
Trim the Fat
In a recent post, The LMS of the Future is Yours, Mike identifies three features and principles of openness (on the software side) that your next LMS should have. With further discussion, we both propose that your LearningOS just needs two features: a roster and analytics. That’s it.
The roster is the connection to the student information system (SIS). It manages roles and permissions of everything in the online environment. This is a function that every course uses, even if it isn’t currently using the LMS for anything else.
Analytics happen in two domains. First, what has happened, as in time that students spend on tasks, clicks and downloads. Second, what does it mean for a student’s learning, as both formative and summative assessment. This has traditionally been the role of the gradebook, however most lock assessment into letters, points, percentages and maybe a few comments. Analytics will require an API (application program interface) to connect the data from the LearningOS to dashboards and transcripts, much like what is being proposed by Caliper. The Caliper Framework suggests a standard method to capture, display and transport learning analytics.
All of the other tools in the LearningOS are plugins. The good news is there is already a mature standard for this, Learning Tools Interoperability (LTI). This means that all the learning tools out there designed to support LTI already work with your LearningOS. Projects like EduAppCenter already provide over 200 tools that can be implemented using LTI.
How is this different than adding plugins to your existing LMS? LearningOS promotes depth rather than breadth by starting with the basics and allowing for teachers and students to plug in the rest.
Are there concerns? Absolutely. Are providers really offering LTI-compliant environments? Are extensions really LTI-compliant or just “mostly compliant”? Is data safeguarded? How will support work in a multi-tool environment? These are among the challenges that institutions will face with the LearningOS.
Some might wonder if LMS providers would support external plugins when they’ve been creating competing toolsets. By allowing for specialization, providers can accommodate for best-of-breed tools built by people with expertise in these specific capabilities, instead of growing a feature set until the platform becomes bloated and static. This move also puts the choices back in the hands of the pedagogs. Don’t want features from one tool? Find another that is compatible and works better for your learning environment. This would ultimately drive greater adoption at an institution, where instructors have greater flexibility of tool choices within an interoperable framework.
LearningOS isn’t just your current LMS stripped down, it’s a new approach that favors well curated plug-ins over vanilla features suites. LearningOS will handle the learning in your classes and probably more, depending what teachers, students and institutions choose.
