A Flexible, Interoperable Digital Learning Platform: Are We There Yet?

In 2005, some colleagues and I had been tasked with identifying a single LMS that could serve the needs of all 64 campuses of the State University of New York—from Adirondack Community College to SUNY Stony Brook to the two medical schools. We came to the conclusion that no single LMS at the time could meet such diverse needs. We proposed instead that SUNY should build a modular system from which each campus, and indeed each educator, could create their own fit-for-purpose digital learning environment. We called this idea the Learning Management Operating System, or LMOS.

We were neither the first nor the last group of people to propose such an idea. We had been preceded by e-Learning Framework, which had been put forth by the UK’s Joint Information Services Committee (Jisc) a year or two earlier. In 2012, Phil wrote about the idea of  Learning Platform here on e-Literate. In 2015, the EDUCAUSE Learning Initiative (ELI) started promoting the idea of a Next-Generation Digital Learning Environment (NGDLE).

There are some conceptual and implementation differences among these different formulations, but they share two things in common. First, they all posited that contemporary learning environments were insufficiently flexible to meet a diverse range of teaching and learning needs. Second, none of them have been implemented. An upcoming issue of EDUCAUSE Review will focus on NGDLE, in part to try to build momentum for it. I have contributed an article.

Nearly a decade and a half after the idea of some kind of modular learning environment surfaced, why hasn’t it happened yet? How close are we? What are the barriers? Having recently returned from IMS Global’s annual Learning Impact meeting, I am convinced that we are closer than ever. But how quickly the remaining barriers fall and how well the end result works will depend heavily on what happens next in the standards-making process.

From Portals to Platforms

The basic rationale for a more flexible digital learning environment is not hard to understand. As I wrote in 2004 about the dominant LMS of that time,

The analogy I often make…is to a classroom where all the seats are bolted to the floor. How the room is arranged matters. If students are going to be having a class discussion, maybe you put the chairs in a circle. If they will be doing groupwork, maybe you put them in groups. If they are doing lab work, you put them around lab tables. A good room set-up can’t make a class succeed by itself, but a bad room set-up can make it fail. If there’s a loud fan drowning out conversation or if the room is so hot that it’s hard to concentrate, you will lose students.

Two things have changed since then. First, we now have many more discipline- and pedagogy-specific digital tools that can be incorporated into the learning environments. To continue the analogy, we have gas jets for chemistry experiments that we can mount on our lab tables. Our notion of the “learning environment” now extends well beyond chairs, tables, and heating or cooling units. Learning analytics, the latest ed tech fashion, can be viewed as just another set of capabilities that expand our notion of our digital “learning environment,” by which we mean an environment that is conducive to learning.

The second thing that has changed—and this is the more radical of the two—is our shared notion of digital environments in general. In 2004, the prevailing vision for a configurable digital environment was one of rearranging boxes and menus on a screen. We had web portals like AltaVista, and Yahoo!, and AOL. Enterprise portals from companies like SUN, IBM, BEA, and Oracle followed this model as well. The basic idea was to bring more functionality to the user with as few clicks as possible. One of the dominant rationales at the time was fear of the user getting “lost.”

Today, many of us have dozens of different applications that we carry around with us all the time in our mobile phones. We are not disturbed or disoriented by the fact that Yelp looks and works completely differently from Google Maps, which looks and works  differently from Pokémon GO. We do not worry about getting lost in our software. Software design and user sensibilities have co-evolved to a point where we don’t have to worry as much about squeezing everything the user needs onto one page (never mind onto one screen, because some users didn’t know to scroll down).

This does not mean that interoperability doesn’t matter anymore. To the contrary, it has moved from the surface structure of the portal, where applications could sit side-by-side in adjacent boxes but largely couldn’t interact with each other, to the deep structure of the platform where, for example, our calendar app can pass an address to our GPS app or we can log into many random apps with our Twitter or Facebook or Google credentials.

Wikipedia defines a computing platform as

the environment in which a piece of software is executed. It may be the hardware or the operating system (OS), even a web browser or other application, as long as the code is executed in it. [Emphasis added.]

The term computing platform can refer to different abstraction levels, including a certain hardware architecture, an operating system (OS), and runtime libraries.[1] In total it can be said to be the stage on which computer programs can run.

We have moved from a world of portals to a world of platforms.

From Learning Management Systems to Learning Platforms

When my SUNY colleagues and I talked about a learning management “operating system,” we were thinking in terms similar to Wikipedia’s description of a computing platform. I am going to use Phil’s “learning platform” terminology going forward because it is more evergreen. A learning platform should be a software environment on which educational programs can run analogously to iOS and Android being software environments on which mobile programs can run.

Despite multiple advances on multiple fronts, today’s LMSs have not yet made this leap. I know there are LMS developers who would disagree with me on this point.  I therefore offer you a litmus test. When you customize the digital learning environment provided by your LMS, do you end up spending a large percentage of your time rearranging boxes and menus on a screen?

I rest my case.

A learning platform would offer educational app developers an environment on which their programs can run. It would provide not just windows and tabs but software services.

In fairness, LMSs have offered 3rd-party developers some software services—APIs—almost from the very beginning. But these services have been mainly designed to enable those developers to better integrate their tools into the boxes and menus on the LMS screen. They made it easier for developers to send a grade to the LMS grade book or add an assignment to the LMS assignment tool, but they didn’t (and largely still don’t) help developers actually build their learning tools. LMSs generally provide an environment in which learning programs can run from a user’s perspective, rather than an environment on which they can run from a software runtime perspective. A learning platform should provide services that are utilized by the developers for core functionality in the learning apps themselves.

Given this refinement of the definition, another way we can tell that we don’t have learning platforms yet is that Feldstein’s Law still holds:

Feldstein’s Law: Any educational app that is actively developed for long enough and has a large enough user base will become indistinguishable from a badly designed LMS.

If you build a great little educational app and it gets some traction in the market, sooner or later, somebody is going to say, “This is great, but it would be even better with an announcements tool.” And somebody else will say, “I’d really love to be able to have a place for class discussions.” And another user will chime and say, “Discussions would be great, but I’d like to grade student participation. Oh, and I also need an assignments list. Which would ideally show up in some sort of a calendar.”

On and on it goes. The app development team recognizes at some point that they are building features that are redundant to those of an LMS. But context is everything, and the users want these capabilities put in the right spot in the app, in the right way. So the developers keep building. And building. And building. Many of these features are not the ones that the developers think make their app great. But they have to be done. So they are. Often quickly and badly. And even if they are done well, the cumulative result is generally bad because the app was never designed to be an LMS and, after a while, all those unanticipated bolt-ons make an unholy mess of the user experience. Which the developers never have time to fix because they are always busy adding the next bolt-on.

Here is a warning to any educational app developers who are reading this post: You will know you have gone too far down the road paved with good intentions when you start building a grade book.

Nobody should ever want to build a grade book. The choice to build a grade book should be viewed somewhat like the choice to have one’s leg amputated.

“Would you like to have your leg amputated?”

“Uh…is it gangrenous?”

“No.”

“Is there another reason why I will die if I don’t have my leg amputated?”

“No.”

“Then I choose not to have my leg amputated. (But thanks for asking.)”

Once you start building a grade book, you will quickly find that you can consume your entire development team’s velocity just keeping up with grade book feature requests. “Can I drop the lowest score?” “Can I grade on a curve?” “Can I use points?” “Can I mix points, letters, and percentages?” “Can I change the scheme that you use to convert letter grades to percentages?”

Your development team can keep working on these feature requests, full-time, and not reach the end of the request list before the heat death of the universe.

Heat. Death. Of. The. Universe.

And nobody will ever thank you for building that grade book. Nobody will ever say, “I love your product because it has such an amazing grade book.” Not ever. Paradoxically, the single feature set that catapulted Canvas into prominence, far more than any other, was Speed Grader, because it enabled educators to spend less time in the grade book.

The problem is that, for many educational app developers, the leg is gangrenous. They need a grade book and they don’t have one. They know their users already have a grade book in their LMS. But it’s not accessible to developers in a way that enables them to avoid having to build their own. They can send a grade to the LMS grade book via the current LTI standard’s outcomes service. But that really isn’t enough. Today’s LMSs are not learning platforms.1

What would it look like if they were? How would that change learning app development?

Grade Book as a Service

Back around 2008, some stakeholders in the Sakai community decided that the next generation of Sakai should be redesigned from the ground up. It was to be called Sakai 3. But the development team anticipated that there would be certain complex apps that would take them an uncomfortably long time to rebuild to the point of feature parity with the old system. The grade book was one of those apps. So the Sakai development team did something interesting. They made Sakai an LTI tool provider. Rather than just being able to take other people’s boxes and put them into the Sakai screen, they would enable Sakai 2’s boxes to be put into Sakai 3’s screen.

The grade book is a particularly good candidate for this kind of treatment, not only because no responsible human being should ever willingly inflict yet another electronic grade book on the world, but also because grade books tend to be discrete apps in terms of the user interface. They are complicated enough that they need all the real estate on the screen. Launching the grade book is a little like launching Yelp on your phone. You don’t care if it looks nothing like the app you just had open a moment ago, because when you’re in Yelp, you want to do Yelpy things. In many cases, one could stick an LMS grade book into another learning app and have it feel fine to the users, particularly if those users were also already users of the LMS in question. In a world of learning platforms, users would always have their own LMS’s grade book at their fingertips regardless of what learning app they are using, LMS vendors would provide an essential and ubiquitous service, and learning app developers would never have to amputate their legs.

In order to make this work, we need two pieces. First, we need the learning platform developers to turn their grade books into LTI tool providers. Interestingly, in one of the sessions at IMS Learning Impact, Instructure’s Melissa Loble said the company has ambitions to turn Canvas into an LTI tool provider. So this is not a crazy scenario to imagine. At least one LMS provider has done this and another has declared that they intend do it. The other thing that’s necessary is a robust service the learning app developers can use to send multiple grades of multiple types to the grade book. LTI’s current outcomes service is not up to the task. But the next version, which is still in draft, should be able to handle this use case. With these two capabilities, learning app developers could send any grades from their app via a standard to whatever LMS grade book their customers are already using. They could also surface the LMS grade book itself inside their learning app so that users would have fewer clicks to get to that information.

Discussion as a Service

Not all learning environment capabilities are as “chunky” as a grade book and therefore as easy to integrate this way. A good example is discussion. Learning app developers don’t often start out wanting discussion boards; they usually want individual discussion threads, which is another way of saying that they want students and educators to be able to have individual, focused discussions about some exercise or piece of content in the context of that exercise of piece of content. Building a discussion thread capability is easy enough. The problem, again, is scope creep. Pretty soon, people want to go to one place where they can see a unified view of all discussions. Or they want to see the discussions that have new posts. Or the ones that have no replies yet. Maybe they want to grade discussions. Or they want branching. Or the ability to embed mathematical formulas. And so on and so on.

The scope creep potential for discussion is different from the potential in a grade book, though, because it is limited by context. Developers of a history app will probably not be asked to implement MathML display capabilities, for example. More often than not, the app developers will need some subset of possible functionality to meet the need of their core users and then will have a larger subset that represents the long tail of user demand. (In contrast, any collection of 10 educators will come up with at least 20 grading schemes when left to their own devices, regardless of discipline or context.)

There are a number of different ways that a learning platform could help solve the discussion problem, but one way would be to provide a set of discussion APIs. The educational app developer would build just enough user interface to solve the problem that the app needs solved and use the learning platform for all the back-end work, calling only the functionality they need through standards-based APIs. Want a simple discussion thread? Easy. Want to add some sort of a roll-up view? Can do.

The current version of IMS Caliper has a full information model for discussion. It could theoretically be used in this way.

But nobody I know of has plans to do anything like this right now, and nobody I know of is checking to make sure that Caliper is designed to provide high-reliability services that learning app developers would need before they could trust such essential services to their LMS integration partners. And that gets us to the heart of the problem that has retarded progress on toward learning platforms for close to a decade and a half now.

Politics

The last barrier to any standards-based interoperability solution is almost always the politics of implementation. The whole point of having interoperability standards is that there are multiple parties that need to share data and/or functionality. But those parties are almost never equally motivated. For example, right now LMS vendors want to everybody to implement version 2 of LTI, in part because it makes installing and configuring tools easier. If you’re an LMS vendor these days, you have customers who are installing and configuring lots of LTI tools, so this is probably a priority for you. On the other hand, if you’re an educational app vendor, you only have to worry about having customers install and configure your tool. The multiple tool problem is not your problem. So you don’t implement. Which means that LTI 2, and any other benefits it might bring, stalls. The LMS vendors can implement LTI 2, but if there are no parties implementing on the other side, then you have a world in which every home has electrical outlets but no appliances to plug into them.

When this happens, responsible stewards of any interoperability standard will take a step back and try to identify a less ambitious subset of features that all sides might agree to implement. This is exactly what is happening now with both LTI and Caliper. In the case of LTI, the standards committee has split off a few capabilities from LTI 2 and made them compatible as add-ons with LTI 1.x. Meanwhile in the Caliper working group, since the use cases that seem to interest most folks are mainly variations of sticking user data into a Learning Records Store for machine-readable analytics, there is a debate about whether parts of the specification that might useful for other use cases are just getting in everybody’s way for the things they want to do today. These are exactly the sorts of discussions that stewards of interoperability standards should lead in order to get everyone on board with implementing a standard. After all, half a loaf is better than none, right? Except that this pruning process is likely to move us further away from the goal of true learning platforms.

In order for this to change, the LMS vendors would have to lean into the idea of becoming environments that learning apps run on rather than merely the environment that they run in. Learning app developers would be much more excited about implementing LTI 2 if they knew the LMS would offer them multiple services that they could use to avoid the thankless task of rebuilding the features that LMSs already do a good job of providing. They would gladly invest time in implementing a standard that would enable them to focus on the differentiators that make their apps great rather than running on the hamster wheel of keeping up with LMS feature table stakes.

Will this happen? I don’t know. The biggest barriers to creating a learning platform were not technical 12 years ago and they certainly aren’t technical today. I believe incentives in the industry have changed enough that we could have a win-win scenario for all implementing parties. But pushing through the last barrier will require at least two of the major LMS vendors to agree on a common vision of the future and make a major commitment to address some of these use cases via the standards.