Product Requirement Document: Enhancements to the Author Experience for using and re-using LTIs

 

Goals:

  • Allow for global re-usablity of LTI tools throughout the course, across course runs, and across different courses, which involves creating options for course teams to save and reuse both 1) License and course-level settings and 2) Assignment-level configuration settings.

  • Create an author-friendly UI that makes it easy to configure LTI once and save and reuse settings. This involves removing all LTI-related fields out of Advanced Settings and creating WYSIWYG modals at the course level (new modals on the Pages & Resources pages) and at the unit level (improvements to the LTI component block).

Problem Statement:

Currently, the process for course teams/course authors to add LTI tools to their courses and reuse LTIs is cumbersome, intimidating and unnecessarily repetitive. Specific pain points include:

For course authors and course teams: 

  1. In order to use LTI tools in my course, I have to go into the Advanced Settings page and enable the LTI Block via a json field in the Advanced Module list. Why isn’t this enabled out the gate?

  1. In order to add LTI tools to my course, I have to create the LTI passport string and then enter it into a json field in the Advanced Settings page. This is an intimidating process and I wish it had a friendlier, easier, non-technical UI.

  1. When I want to use that LTI tool in a unit in my course, I have to enter the launch ID and launch URL in the LTI block, and that is the only way to get the tool into my course. It’d be easier if I could simply choose from a list of tools that already have a passport, license info and course-level configuration settings entered.

  1. When I want to reuse that LTI tool in my course again, in a different unit, I have to fill out all of the settings in the LTI block again, because they aren’t saved (launch id, launch url, and assignment specific settings like frame width, launch in or out of line, etc)

  2. When I want to reuse that LTI tool in a different course, I have to start the entire process from scratch, starting with creating a new passport, because the settings aren’t saved.

  3. When I create a new course run, I have to start the entire process from scratch, starting with creating a new passport, because the settings aren’t saved.

For learners: 

  1. I have to give permission for an LTI launch if it uses any PII, every time it appears in the course. This is repetitive, cumbersome and annoying.

 

Proposed Scope of Work

We want to enhance the course author experience to add and use LTI tools in a course. We want to reduce friction caused by the above pain points by:

General Improvement:

  •  Enabling the LTI block by default as part of the Core Product experience

In the Pages & Resources Page:

  • Moving all LTI json commands for enabling an LTI tool in a course (ie, adding the passport with the key and secret) out of the Advanced Settings page and into newly designed modals with appropriate UI via an LTI tile on the Pages & Resources Page 

  • Allowing course teams to save the course-level licensing settings (launch ID, launch url) for an LTI when that tool is added to a course for the first time. This way, authors will only have to enter it once.

    • See Technical Requirements section for more information about differences between 1.1 and 1.3.

In the Course Outline/Unit Pages: 

  • Pulling the LTI component block out of the “Advanced” component tile and creating a new LTI component block 

  • Via the new LTI component block, allowing course teams/authors to add an LTI tool to a course by selecting from a UI-friendly list of the tools that have already been added, rather than having to re-enter the id and url as the mechanism for choosing which LTI tool to add.

In the LTI Block:

  • Simplifying the process of configuring LTI tools within the course by simplifying the fields in the LTI block. This involves 1) removing the repetitive course-level configuration fields (launch ID, launch url, etc), which will be possible because those settings will be saved, and 2) creating a friendly UI for the configuration fields at the assignment level

  • Allowing course teams/authors the option to save assignment-level configuration settings for reuse within the same course, and allowing teams to choose from those saved settings when reusing the LTI tool

Re-use across courses:

  • Allowing course-level configurations (launch url, launch ID, etc) to carry over into new course runs. (This excludes the  need to carry over assignment-specific settings.)

  • Allowing course-level configurations (launch url, launch ID, etc) to be reused in other courses within the same instance or organization where multi-course licenses have already been obtained. 

For learners:

  • Learners should be able to give permission for a particular tool for a particular course once and then have those permissions saved by the LMS.

 

Features & Requirements

In order to realize this MVP, we believe the following features will be required. 

Feature

Requirements

Feature 1: Modals for course teams/authors to add an LTI to their course and save the course-level settings/license information

 

 

 

 

 

Feature 2: An LTI-specific component block available in the components section of the unit pages

 

 

Feature 3: A “list of LTIs” modal that lets  course teams easily select from all the tools that have been added to the course.

.

Requirements for Feature 1: A new “LTI” tile on the Pages & Resources page. The tile will house a series of modals that will walk the author through UI-friendly fields to add a new LTI id, passport, and save the settings so they don’t have to be re-entered every time the LTI is used in the course. Authors can also enter the launch ID and launch URL once. See Design Concept 1.

 


Requirements for Feature 2: Pull the LTI component block out of the “Advanced” component tile and create a new LTI Component Block 

 

Requirements for Feature 3: A friendly UI that authors can access from within the course outline via the LTI Component Block to choose which LTI they want to add to a unit. See Design Concept 2.

 

 

Feature 4: Modals in the LTI Component Block for authors/course teams to configure a learning tool within a course unit for specific assignments. 

 

Feature 5: An option to save assignment-level settings that can be chosen on reuse of the LTI tool in the same course.

 

 

Feature 6: A modal for learners to enter permissions once.

Requirements for Feature 4: A UI for a list of configuration fields that focus on configuring the tool specifically for the assignment. 

 

Requirements for Feature 5: A setting that lets authors save custom settings so it doesn’t have to be rebuilt every time it’s used in the course or in new course runs.

 

Requirements for Feature 6: Many possible approaches: 1) we could have one modal appear at the start of a course that requests permission from learners for all LTI included in the course; 2) we could have one modal appear per ‘new LTI tool’ launch with the system thereafter remembering the given permissions; 3) we could have option 1 combined with option 2 for any LTI tool added by the course team after term start. 

Design Concepts

 

Design Concept 1

 

 

Design Concept 2

 

 

Technical Requirements:

  • The platform must remember course authors’ license and configuration settings so they are not prompted with every LTI add. This includes both 1) license settings at the course level, and 2) assignment-level configurations.

    • Currently, LTI 1.1 allows the key and secret to be added once and for that to be utilized across multiple LTI launches. For LTI 1.3, we need to send from the course team to the tool vendor: the Client ID + keyset and access token unique-URLs. 

    • If the vendor on their side authorizes the unique Keyset and Access Token, then the LTI would work for that unique install, but for any subsequent installs, the vendor would need to authorize/authenticate the respective unique installs. 

    • This is an extremely cumbersome and untenable (read:unscalable) process for use of LTI1.3, rendering it essentially inoperable on edX without a fix. Tool vendors who work with many different organizations strongly prefer using generic URLs, which would streamline the integration process for both edX and the vendor. Given how this is a lift for both sides, it is critical that this is resolved, or it can render LTI 1.3 unusable.

  • The platform must remember end user’s permission settings so they are not prompted with every LTI launch. These permissions should be user specific and remembered by the platform for (at minimum) the duration of the course. 

License Ownership Definitions:

  • Operator with a single organization – the platform can be registered once with a single client_id and the tool integrated multiple times.

    • User Experience: An admin integrates a tool at the platform level, and then course teams can enable and use this tool in multiple courses seamlessly. When only one org is represented at the platform level, the license applies to the entire instance.

  • Operator with single or multiple organizations, course teams under an org are responsible for managing their own catalog of LTI tool integrations.

    • User Experience: A course team configures, integrates, and manages their own LTI tools. They can integrate at the course level, with their own org’s license. They only need to integrate a tool once per course. Once a tool is integrated and license enabled for a course, a course team can add this tool anywhere within that course with ‘one click’.

 

Roles & Permissions Definitions

Course author: Can add LTI tools to a course that have already been configured by a superuser, global staff or org-level admin. Can configure and save new tools in Studio for use in the course. Configuring once will allow multiple uses throughout the course with settings saved by the platform. Only placement level information will need to be adjusted.