2024-05-14 LTI/Learning Tool WG Meeting

Recording + Transcript

No recording for this meeting. We kept the WG check-in to 10 minutes, and primary action/take away is for everyone to please view the recordings from April 16 and April 30, and provide asynchronous feedback on Santiago’s presentation of the LTI UX/UI work by EduNext.

LTI WG Meeting Notes: Feedback requested (please view recordings from past 2 WG meetings)

• We kindly ask participants and anyone interested to watch the following two videos showcasing the prototype aimed at enhancing the administration and reuse of LTI tools. Please share your comments, questions, and feedback in the comments bellow to be addressed in our upcoming meeting.

  • 2024-4-30 presentation: https://drive.google.com/file/d/1DY4-EbMwAVqv3JWgB91lfiVN-5mGXREm/view

  • 2024-4-16 presentation: https://drive.google.com/file/d/15YSrZzLy1soCN5A-ymggogBL4lRYugR1/view

  • You can explore the following clickable prototype: LTI Prototype

Attendees:

• @Anna Aldric (Deactivated)

• @Lisa Ishimaru

• @Zach Hancock (Deactivated)

• @Santiago Suarez

• @Lisa Ishimaru

• @Mohamed Rafeeh Ibrahim

• @Xavier Antoviaque (otterpilot)

Action Items (carry over)

• Feedback requested

• I'll try to use terminology from the lti 1.3 spec (https://www.imsglobal.org/spec/lti/v1p3):

  1. lti implementation, in edunext presentation
     refers to the placement of an lti tool in the course
     in my comments: resource link, resource_id

  2. lti setup, in edunext presentation
     credentials for an lti tool, which currently is set in "Advanced Settings"/"Passport" in Studio and then used as "LTI ID" when editing an LTI component (lti 1.2)
     e.g. for lti 1.2 consumer key, secret key, lti launch url
     in my comments: lti registration, which is the contract between platform and tool that establish trust between both parties

  3. tool settings, in edunext presentation
     configuration for a particular implementation/resource_id
     e.g. if the tool should be displayed inline or open a new window
     in my comments: component config - this is an edx thing, not in lti spec

  The administrator dashboard displays all the resource_ids in an organization. Each item is displayed in a "card". That can potentially be hundreds of cards. These items can be filtered by:

  • creator

  • lti version

  • lti reused

  • plus a text search (that i believe in by the "tool name" given when you create an lti resource_id
    The items are also grouped by registration, so all resource_ids that share the same registration are listed under this card.

  For items that are grouped by shared registration, how the title in the card is chosen? I realized that this "tool name" is what is displayed to learners so, potentially, there might be multiple cards with the same "tool name" that are tied to different courses (this would happen with HarvardX reruns) and it is confusing.

  For HarvardX case, we would have hundreds of implementations given the number of courses
  and reruns. Even with the grouping by registration, a tool that shares the same registration platform-wise for example, will show a very long list of resource_ids that can be only discrimated by the "tool name". Since "tool name" is displayed to learners, it might not be possible to be used for the purpose of discriminating the tool nor particulars of an implementation. Note that there might be particular configurations in each implementation stored on the tool side.

  The "LTI implementation list", displaying all resource_ids associated with the same registration helps, and in my view the main benefit for this list is to provide quick access the lti component by course authors for review or edit.

  The problem, as i understand, is not solvable by a UI. The restriction is dictated by the underlying model for registration at component level that does not implementn the hierarchy needed to associate registrations at institution or course level.

  Per lti 1.3 spec (see https://www.imsglobal.org/spec/lti/v1p3/#lti-domain-model), the platform provides a client_id for the lti_tool at registration, and this client_id can then be associated to a context (course) and resource_id. The way it is now, the model conflates client_id and resource_id, forcing a new registration to be created for each resource_id and making the process of configuring lti in a course laborious, and management of registrations very confusing.

  Again, registration in lti 1.3 is not simply a key-pair, it involves a back-and-forth between platform and tool to exchange the credentials and guarantee security. For lti 1.3, the UI prototype does not display the (client_id, deployment_id) generated by edx which is part of the back-and-forth between tool and platform during registration. There was also mention to the "LTI 1.3 only URL" or dynamic registration (https://www.imsglobal.org/spec/lti-dr/v1p0), which currently is not supported by edx.

  Considering the difficulties that edunext had to redesign the UI for lti registration and configuration, it seems to me the sensible path would be to review the underlying model for lti registration and see if it is possble to have the registration be separated from other lti configurations. As much as i understand that lti is difficult to setup, it deals with learners information and requires security, and security is hard to simplify without compromising security.