The Case for Learning Platform Grade Book

A little while back, I wrote a post reflecting on how close we are to getting a next-generation, modular learning platform and how the next steps in the IMS standards-making process can influence whether and when we might actually see this elusive beast in the wild. Today, I’d like to zero in on what I believe is the next logical step, given the current state of the ecosystem: namely, making LMS grade books fully interoperable with courseware and other ed tech tools.

No, it isn’t sexy. No, it won’t revolutionize education. But I believe that it will benefit vendors and educators alike in a way that will shift relationships among ed tech tools, reduce wasted effort reinventing the wheel, and open up new design possibilities.

The Basic Idea

While the integration approach I’m going to explain here isn’t different from what I described in the aforementioned post, I’m going to go into more detail here to make sure that the description is clear.

Just about every school in the US and Canada, and many across the world, has an LMS, and every LMS has a grade book. While the degree to which faculty utilize it varies greatly, it is typically one of the most utilized tools, at least for the basic purposes of communicating grades to students and the registrar. In fact, many schools require faculty to enter grades in the LMS grade book.

Grade books are hard to build and even harder to build well, in large part because they have to handle every imaginable combination of grading schemes—points, letters, percentages, combinations thereof, curves, dropping grades, extra credit, and so on. Building a grade book that isn’t completely horrible is really hard and takes a lot of effort and practice to get right. Building a grade book that faculty and students love is probably impossible.

And yet, many ed tech tool developers find themselves building grade books. Once faculty are assigning and grading more than one or a couple of assignments or activities in the tool, they will need a grade book to track and manage the grades. And they will want it to be able to do all the things that they are used to being able to do with their LMS grade books. To make matters worse, some faculty will want to do as much in the tool and as little in the LMS as possible, while others will want the reverse. Meanwhile, students generally like to be able to go to one place to see their grades. As a result, most ed tech tool developers feel compelled to build their own grade books and to build integration with the LMS grade book. Neither of these two projects generally gets the level of effort it needs to work well enough to make the faculty happy, while the lack of a single, standard place to go for grades is virtually guaranteed to make students unhappy.

There is a better way. If LMS developers and ed tech tool developers both focused on making the integration the best it can possibly be, then educators and students would always use the same grade book—their LMS grade book—regardless of which ed tech tool they happen to use. All grades would flow from the tools to the LMS grade book. If a tool needs to have a grade book in it, the LMS grade book would appear inside the tool in a similar way to how many external tools appear inside the LMS today. Faculty and students would have only one grade book to learn, one grade book to manage, one grade book to check.

Why This Integration Must Be Standards-Based

This kind of integration will likely never happen without both interoperability standards and one or several open source implementations of them, for a number of reasons. First of all, different tool vendors have different use cases. Grading works differently in different contexts. If LMS developers were left to discover these use cases and build to them on their own, it would take forever, and some use cases would likely be left out. This is a classic case where getting many LMS and tool developers together in specification development working group has value.

The standards development process is hard, complicated, and painful for the same reason that any multilateral political negotiations are. In order to make them work, you need to make sure that everybody gets at least something that they want badly enough to make the effort and compromise worthwhile. But in cases like this one, you need everyone on board. If the integration approach works for one class of tools but not another, then you haven’t really solved the problem. And the most efficient way to make sure you are getting all the use cases through a standards-making process.

Second, even if LMS developers come up with all the use cases on their own, that would leave the ed tech tool developers in the situation of having to develop a separate integration for every LMS that their customers use. Many ed tech tool development teams are small. While developing separate integrations for each LMS is probably less work than building a complete grade book, it’s still a lot of work. If this is to catch on, then the implementation cost must be manageably small for tool developers.

Third, many tool developers are always going to have to deal with the use case where the faculty don’t want to use their LMS at all (or don’t have one to use) for one reason or other. There must be a fall-back for them in case the customers’ LMS (or lack thereof) lets them down. That’s why the integration must not only be standards-based but have at least one open source implementation. Tool developers need to have a fall-back grade book that they can provide to customers without having to build their own. (If they have to build their own grade book anyway, then their motivation to just integrate with somebody else’s grade book diminishes dramatically.) Ed tech tool vendors need to know that, if the customer doesn’t have an appropriate grade book, then the vendors can run their own instance of Moodle, Sakai, open source Canvas, OLAT, ILIAS, or whatever and use the grade book provided by that platform.

How This Would Work Technically

As I wrote in my previous post, there are two parts to making this workable. First, LMS developers would need to make their grade books LTI “tool providers,” which simply means that the basic educator and student grade book views would have to be available to ed tech tool developers as LTI “windows” that can be put into the applications. Second, because the current version of the specification does not support robust communication of grades from the tool to the grade book, the next version of the LTI grading specification, called Outcomes2, would need to be finalized—with input from all the various tool developers to make sure it covers the appropriate use cases—and implemented in the LMS grade books.

The IMS process requires at least two different implementations on each side of the integration. So two LMS developers and two tool developers would need to step up and agree to implement as a way of both testing to make sure the standard is adequate and to build momentum for others to implement.

This basic approach still leaves lots of room for innovation and differentiation by individual developers. For example, LMS developers could choose (or not) to make their Speed Grader-like grading tools more usable in these other ed tech tools. Meanwhile, the tool makers could choose to provide robust tool-specific analytics on their side (or not).

What Everybody Gains

This approach provides value to multiple stakeholder groups.

LMS developers get to make a part of their platform that they invest in heavily become ubiquitous and essential. There would be one grade book, which would be the LMS grade book, always and everywhere. This approach would likely also increase demand for cloud hosting. If the LMS going down means that every grade book in every ed tech tool goes down, then there would be increased pressure on schools to provide rock-solid uptime.

(By the way, this brings up another reason why the standards-based approach is critical. If ed tech tool developers are going to be dependent on the LMS provider for a critical function, then they absolutely need the customer to understand whose fault it is if the grade book stops working. That only can happen if the pattern is consistent everywhere. “The grade book? Oh, that’s always, always, always from the LMS.”)

Tool developers get to take all those development resources they’ve been spending on reinventing the wheel and apply them toward building a better product instead. They get to stop taking the blame for the limitations of functionality that, while it may be essential, is not well liked. They get to benefit from the experience (and the scars and scabs) the LMS companies have from their years and years of building grade books that have to work for everyone. And they get all of this without being locked in to one LMS. If all LMS developers are competing to provide a smooth, standards-based implementation across a wide range of tools, then the LMS developers’ interests are aligned with those of the tool developers.

Faculty get to limit the number of electronic grade books they have to learn and manage to a maximum of one, which doesn’t change very often. They don’t have to learn a new grade book if they choose to adopt a new homework or courseware product. And they can use the one they have wherever they want to. If they prefer to manage grading in the LMS, they can do that. If they prefer to switch over to a grading tab while they’re looking at the students’ work within an ed tech tool, they can do that. They can do both of those things without having to choose one over the other. Less time learning and managing multiple grade books means more time available for more high-value teaching activities.

Students get the same basic benefit that faculty do, but potentially multiplied by the number of courses they take. They would know exactly where to go and how to find out their grades in every single course, regardless of the ed tech tool that their instructors have adopted.

Humanity as a whole gets many fewer horribly developed grade books that are destined to be hated, ostracized, and eventually abandoned. Think of it as a courseware spaying and neutering program.

Finally, this approach would establish the idea that bits of the LMS can become essential infrastructure in various learning tools. We would move in the direction learning platforms that provide critical utility functions and ed tech tools that ride on top of those utility functions to create more specialized and differentiated educational capabilities. It would set a precedent.