Integration with a Learning Management System

A solution for integrating with a third party while avoiding the pitfalls of embedding our UX inside their product

Client/Project: Eli Review
Timeline: August 2015
Objectives: Add single sign on and course creation automated via an LTI integration with Desire2Learn
Team:
  • Shekhar Patil, Developer, Venturit
  • Mike McLeod, Project Manager, Eli Review
My Role: User research, information architecture, interface design, requirements, front-end dev, QA
Categories: , , , , , ,

Overview

This is a case where I had to walk a minefield of personal relationships and design dilemmas as I tried to find a solution to a problem that would work for our stakeholders while not compromising the user experience of our product.  This is how I found I found a happy medium between the people who pay the bills, the people who use our product, and maintaining the integrity of our design.

Background: the UX of Integration

Eli Review was conceived from our work as faculty and researchers at Michigan State University. MSU has been one of our biggest customer since the days of our first prototype through to today. They were also the first to ask us to seriously consider integrating Eli with their learning management system (LMS), Desire2Learn (D2L).

Eventual co-branding for the project integration

While we were eager to support the university, one of the biggest concerns about integrating was the integrity of our product. Having used D2L and a variety of learning management systems as instructors ourselves, we knew that LMSs do not like to let users outside of their propriety sandboxes, which they typically control by containing external content in an iFrame within their own UI. There are a number of affordances lost when working in an iFrame (screen real estate, navigation, scrolling, etc) and we knew that we were not willing to surrender those to work within the confines of an LMS.

The challenge, then, was finding a way to accommodate the university’s use cases without sacrificing control over our own user experience. We were able to accomplish this, eventually, by integrating indirectly.

User Stories and Project Scope

While MSU had a long list of user stories they hoped integrating would accommodate, the eventual list of stories was narrowed down to:

  • As a user at any level, I want to sign into Eli using my existing MSU credentials (single sign on) and not have to create a new account just for Eli
  • As an instructor, I want to set up my Eli course with as few clicks as possible
  • As an instructor, I want my students to be able to join my course without a code
  • As a university administrator, I want instructors to be able to utilize the seats we bought for Eli Review without having to give each instructor an access code
Screenshot of the project requirements document, which lays out all of the information needed to convert D2L data into variables for Eli's database.

With the list of user stories narrowed down it was much easier to determine the scope of the development needs and to prepare a complete set of project requirements (pdf download). One of the challenges in writing these requirements was working with MSU IT staff to figure out how their configuration of D2L differed from standard LTI data and how that data would map onto Eli’s database as users connected from their system to ours.

The workflow diagram describing how subscription workflow changed to accommodate our new model that would better accommodate D2L.

A significant issue regarding system design that D2L integration forced us to confront was our model for assigning seats from institutions who purchase them in bulk for their students. Prior to this initiative, seats were allocated to students one by one and the system tracked to whom and for how long those seats were issued. This created an administrative nightmare where, if seats ran out, instructors and students were both locked out of participating in their courses.

Integrating with D2L gave us the opportunity to revise that method. I designed a new model for allocating subscriptions that would allow us to fully account with the institution without interrupting student or instructor work. This way the burden was on us and the institution, rather than on instructors and students who have relatively little power over the choices of their institution, letting their experiences teaching and learning go uninterrupted.

What Changed

While most users did not experience significant change in their experiences, there were dramatic changes in store for instructors and students at Michigan State University who say a dramatic drop-off in the work needed to support faculty and students using Eli.

  • Database updates: new fields for keeping track of LTI data to support single sign on
  • Subscription allotment for institutions: new workflow to prevent students from being locked out when institutions exceed their number of purchased seats
  • Steering MSU instructors to D2L: minor UI updates to the “Create a Course” form to encourage MSU instructors to use D2L to create their courses
  • D2L mini-app: a limited web app that operates in D2L’s iFrame while functioning as an API into Eli Review, allowing users to create accounts, instructors to create courses, and making single sign-on easy.

The mini-app was a significant compromise both by MSU and by us. Keep reading for details.

Before and After

The institutional purchase manager for MSU with the D2L option available.

For administrators at MSU, who used to have to give each Eli instructor the access code to use MSU’s purchased seats, integrating with D2L relieved them of that responsibility. They could still hand out access codes to instructors with particular needs, but for the most part, instructors now set up through D2L and no longer required an access code.

Integration with a Learning Management System

Another significant change affecting only MSU users was on the Create a Course interface. Because MSU wanted to steer its instructors to D2L, I developed a method for checking both an instructor’s email address for an MSU domain (msu.edu) but also the course they last created in Eli to see if it was for MSU. If either case was true, instructors would see an MSU-specific message directing them to D2L but also giving them the opportunity to use the form as they always had, should they want to do that.

The D2L Mini-App

After a number of experiments in how best to allow Eli to operate within the confines of D2L’s iframe, I determined that there was simply no way to protect affordances of Eli’s user experience while having its UI confined by D2L. We had to find another way to satisfy the project user stories without embedded our app in D2L.

A second and far more serious issue was dealing with the surprisingly high number of idiosyncratic use cases and potential failure points of authentication using D2L. Because MSU had been a client for so long, it was quite likely that many instructors and students would already have separate Eli Review accounts and many would be used to the workflow of going to the Eli Review app first, which meant we’d need a unique set of tools for resolving user accounts and courses with MSU’s database. We would also need a unique set of error detection and correction methods for all of the distinct information issues posed by working with D2L.

The logic flow for the mini-app inside D2L, focused primarily on issues of authentication via D2L and all stages ending in onboarding for the full Eli Review app.

I worked closely with MSU’s IT staff to document as many failure points as possible in the D2L authentication process. This was surprisingly complicated, but ultimately gave us a very clear picture of everything that might go wrong for instructors and students when setting up courses or signing in to Eli. This allowed us to create a customized workflow for MSU users to anticipate and prevent as many errors as possible.

The outcome of this design process was an app distinct to Michigan State University that would operate only within D2L. The mini app would offload the process for creating accounts and setting up courses to take advantage of D2L’s institutional data and, at the end of those processes, would present users with a single sign on link to take them directly to the Eli Review app outside of D2L’s iframe.

The first step in the D2L mini-app for new users: indicating whether or not you already have an Eli Review account.

Instructors and students first indicate whether they already have an Eli Review account; if no, the mini app uses D2L’s data to create a new account for them. Otherwise, they can enter their existing Eli credentials and connect their MSU and Eli Review accounts.

Instructors can either set up a new Eli course via D2L or they can connect to an existing Eli Review course.

For instructors, the mini app will connect to Eli’s course list and find any courses they are actively teaching. If those courses were created for the D2L course the instructor is working with, the instructor can select that course from this list and connect it to the D2L version.

The final step in the process of setting up Eli Review in D2L: leaving D2L and experiencing Eli in its own browser tab.

Then, once account and course setup is complete, the Eli Review experience inside of D2L is complete and users see a launching point for opening the full Eli Review app in a separate tab or window. Both instructors and students will see this interface from that point forward.

Welcoming instructors and students to Eli Review after busting them out of D2L's iframe.

The first time users go from D2L to Eli Review they are shown a message letting them know that the single sign on was successful but that they’ll now be working from inside Eli Review, rather than inside D2L. They can close the modal window and get to work.

This video has a complete demonstration of how to set up courses and accounts for Eli Review using MSU’s D2L platform and how to access Eli using single sign on:

Outcomes / Takeaways

With three years since the completion of this project, we have some confidence that we approached it in the best way possible from a UX perspective:

  • Resolving duplicate accounts became less necessary as instructors and students became used to the D2L portal – few returning users or instructors are going to the app first
  • Maintaining the app with a separate sign in portal has proven to be a valuable alternative for when D2L fails to authenticate for reasons we can’t identify (which happens more often than we’d like)
  • Preserving the UX for the app was the right choice – instructors who have changed institutions are able to bring their Eli-specific knowledge with them that remains useful despite no longer using the D2L mini-app

From a business perspective, working with university information systems proved to be a complicated and expensive process that doesn’t look any easier to replicate despite having had this experience at MSU:

  • LTI promises consistent use of data across apps, but understanding individual institutional settings is a serious challenge; things are named differently, and there are different levels of permissions for what instructors can add to courses
  • LMS integration is expensive – something like Shibboleth might provide a similar experience at a lower price (only about single-sign on, less inconsistency between institutions)