Pressure to add account-level LTI 1.3 apps for a small number of courses

[kylejtuck]

I struggled with how to title this. Originally, I thought about saying “LTI 1.3 is fundamentally broken”, but that isn’t really accurate.

I started creating LTI apps a couple of years ago. I started with LTI 1.1 because it is very simple to get an LTI 1.1 app up and running. I then started learning how to create an LTI 1.3 app using the celtic project library. I have learned quite a bit about LTI over the last couple of years, but I do need to stress that I am far from what would be considered a professional developer or an expert in LTI.

The root of the problem is how an LTI app is deployed. LTI 1.3 fully supports course-level deployments, but several app publishers (who tend to be traditional publishers) specifically design their platform to be installed at the account/root level. They argue that their app can be “hidden by default”, but this is only partially true. What they mean is that the app can be hidden by default from the course navigation menu, but it is absolutely not hidden from instructors/IDs within the course settings.

There are a couple of challenges presented by the scenario in which the app is not hidden from instructors.

First, it works against the goal of trying to keep the LMS clean and uncluttered. Instructors and IDs have to navigate an increasingly large list of nav items to find the things that they actually want in their course. It is particularly frustrating having an app listed here when it is only used in a small handful of courses (less than 10 courses out of thousands).

Second, instructors can see all of those options but likely do not know what they are. Any inquiries about these "mystery navigation items" will be directed to IDs or LMS admins who really don't want to be answering those questions.

Publishers will argue that they need the Deployment ID, per 1EdTech. However, they can capture the Deployment ID when the tool is launched, along with the Platform ID and Client ID. The latter two should be sufficient for the publisher to identify the “customer” as much as a root account Deployment ID (except for Inherited keys).

There are advantages to using course-level deployments for tool publishers as well. Each course can still be associated with a single “customer” via the Platform ID and Client ID but will now pass a unique Deployment ID to the tool. In a modified version of the Celtic Project’s Rating example, I was able to implement course-level customizations within the tool while still inheriting "customer level" settings.

Please share your thoughts. Perhaps I am misunderstanding something, but I still believe that there is a serious issue with how publishers are pressuring us into root/account-level deployments of LTI 1.3 apps.

[Debra-Sheridan]

We don't allow anyone to add LTIs other than admins, so a course level LTI is a bigger burdIen on our small LMS Admin team. I agree the listing can get cluttered depending on how a tool is deployed, publishers being the biggest issue. We partner with our campus bookstore and are working to have all of our publishers go through their tool. Then when faculty integrate, the use the bookstore tool which connects them to the publisher and their materials. We are hoping this will cut down on a lot of the tool lists from publishers.

[kylejtuck]

@Debra-Sheridan We do have apps that we install (and want to continue to install) at the root/account level, such as ones that are used by all (or a significant percentage of) courses. However, there are some apps that are used in fewer than 10 courses.

Each school/district is going to be different. My issue is that some publishers are not giving the choice when LTI specifically allows for that choice.

[Debra-Sheridan]

I don't like not having a choice. I have one set of 10 items that have to be added individually rather than one for all 10 and it makes a mess. I would definitely prefer a better way to do this, but no luck so far.

[AlexisNast]

You're definitely. not the only ones experiencing this! We've heard it from many institutions. As a result, we are working towards a solution on how deployments are handled within Canvas to make it easier to set a tool up at the root level and only have it available for use in specific subaccounts or courses. We will be starting an Early Adopter Program for this feature in the next two months and based on feedback from that will determine our release timeline.