1 of 13

Making course management easier with the new Canvas Course Manager

Melinda Kraft

Samuel Sciolla

Pushyami Gundala

Making course management easier with the new Canvas Course Manager

Canvas Course Manager (CCM) is a Web application that extends the feature set of Canvas (the university's learning management system) and simplifies some of its convoluted workflows. Integrated into Canvas courses for easy access, CCM helps faculty and course administrators prepare an online learning environment for students and format grade data. By providing this useful support tool, the ITS Teaching & Learning team aims to make Canvas work better for staff members and facilitate their digital fluency.

CCM features include cross-listing (or merging) various Canvas sections, making it easy for instructors to teach students enrolled in two or more different programs in a single course. Bulk section creation and user enrollment features simplify the setup for non-registered courses like labs or discussions. Staff can also simply enroll users from outside of the institution, such as other university instructors, to enrich students' experience with a cross-institutional perspective. Additionally, CCM provides grade formatting features to streamline the uploading of final Canvas grades to MPathways and incorporate grades from third-party course tools.

Our presentation will demonstrate some of these features, highlighting their instructional and administrative benefits. We will also review our development journey (replacing a legacy Java application with a modern Node.js stack), touch on our use of security and domain-specific standards (including Learning Tool Interoperability and the Canvas OAuth process), showcase our close collaboration with the ITS Digital UX and Accessibility teams to build an accessible and usable product, and celebrate a multi-year cross-organizational eff

2 of 13

What is CCM and why we built it?

Permissions

LMS Transition

Instructors and Admins

3 of 13

CCM Features

This is a screenshot of the section merge utility in the old CCM. When new courses are provisioned in Canvas, each section, including discussion and lab sections comes in as its own Canvas course with its own enrollments, but instructors may want to have all those sections together under one course to make course management easier.

With this tool instructors could merge sections as long as they were the instructor of record, that is to say they could only move their own courses. This presented its own problem because instructors don’t always get added to their lab sections, and sometimes instructors want to collaborate in a single Canvas course. For these use cases, we also at the “service center version” of CCM. It was a standalone site with more permissions for service center staff. As a standalone site, however, it meant that we had to maintain two separate sets of code, the LTI in Canvas and this version.

4 of 13

Problems

Elevated Token Usage

Old LTI version

Two Tools

ol

Older Stack

5 of 13

Project Goals

Open Source

New Technology Stack

Better UX and Fully Accessible

Stakeholder involvement

Feature parity

6 of 13

Demo

7 of 13

Design goals

Use Canvas

permissions

Canvas OAuth

Scoped tokens

Modern, performant, reliable

NodeJS

Type-

Script

Snappy, accessible UI

React

Material UI

One tool version

LTI 1.3

Role-

based features

Sam (1:30?)

So next, I'd like to talk some about our design goals and how some of the technologies and strategies we chose helped meet those goals. We'll be getting a bit technical, but I'll try to emphasize the user impact of each choice or feature I discuss.

As mentioned previously, the first version of CCM had multiple versions to accommodate Canvas users and users from the ITS Service Center. This made maintenance challenging, so we decided to condense this into one LTI tool, with Canvas admins getting access to all features. Some features also, like Merge Sections, have different functionality depending on your Canvas role (admin, or teacher, for example).

We also wanted to rely whenever possible on Canvas permissions, as this allowed us to simplify our code base. By using Canvas OAuth, when we make requests to Canvas to perform actions, we're doing it on behalf of the user, so we won't be able to do anything they couldn't do. We also scoped the Canvas credentials created for each user, so those tokens can only be used to take the actions needed by the application.

A major goal of the project was to modernize the technology stack, and after some deliberation, we decided on NodeJS. We were drawn to its performance gains and its growing presence in Web development. Furthermore, we chose to write the source code in TypeScript, which provides language features to ensure we write code that is dependable, consistent, and aware of edge cases. And to meet users' expectations in 2022 a dynamic and accessible user interface, we chose a familiar toolkit of React and Material UI.

8 of 13

Architecture

MySQL DB

React, Material-UI Webpack

NestJS

CCM Architecture

LTI 1.3,

OpenShift Container Platform on AWS

Web server (Express/NestJS)

MySQL database

on AWS host

OpenShift Container Platform (ITS)

Client (React) in browser

REST API

Auth layer (cookie)

Canvas

OAuth

LTI

Cirrus Identity

Token

High-level explanation of LTI 1.3 elements like JWT and handshake with public and private mechanism

Canvas oAuth 2 autheriation

Sam

So let's see all that comes together by going through a high-level overview of the application's architecture. First, we have the Web server, which is built using the popular library Express and then an additional structural layer is provided by the NestJS framework. For production, that Web server runs in the cloud using the OpenShift Container Platform, where we create multiple instances of the server as needed (represented by these dotted lines).

To store user and session data, we use a MySQL database that's part of an AWS service.

The other external services we rely are of course Canvas, which we communicate with via the LTI integration and OAuth, and Cirrus Identity, which is a service users outside of UM can use to set up a login method to Canvas. Finally, the React application in the user's browser communicates with the backend Web server using our REST API, which is guarded by a cookie authentication layer.

9 of 13

Performance

Utilize JavaScript features (async) and a queue library to quickly make hundreds of API calls without hitting rate limits
Maximize resources by running multiple server threads per container (using pm2), and handle additional load using autoscaling

1 server

4 threads

<=2 pods

With async event loop

10 of 13

UX & Accessibility: Some lessons learned

Consistency is key (UX).
Tasks need clear confirmation and success messages when they are completed (UX).
Controls must be usable via keyboard (e.g. Tab/Enter), with visible focus (A11y).

Descriptive aria-label attributes, use of aria-live attributes to announce changes, and table captions improve the screen reader experience (A11y).
Nesting elements is preferred over overriding original element semantics with role attributes (A11y).

11 of 13

Outcomes and Benefits

Collaboration between 3 ITS Teams (DUX/TL/DISC)

Fully Secure, Usable and Accessible product

Smooth adoption

Successful delivery of New Technology stack

12 of 13

Project Team

Pushyami Gundala, ITS Teaching & Learning
Janel Ilar, ITS DUX
Matthew Jones, ITS Teaching & Learning
Melinda Kraft, ITS Teaching & Learning
Zhen Qian, ITS Teaching & Learning
Chris Rowland, ITS DISC
Samuel Sciolla, ITS Teaching & Learning
Gonzalo Silverio, ITS DUX
Lance E. Sloan, ITS Teaching & Learning
Brandon Werner, ITS DUX

13 of 13

Questions