[Archived] LTI MVP
- Anna Aldric (Deactivated)
MVP Stage 1: Instance or Org-level LTI Configuration, and Course-level LTI Configuration (2023)
Configuration: Instance/Platform, Org, Course
Instructors or course leads enabling a pre-configured tool at the org level, making it available for all courses in that org when it is enabled
At the org/instance level, admins add/configure a tool at the org or instance level, and that configuration is available for use in any course in that org/instance. If a license is also added at the org level, then an instructor or course lead only needs to enable before use.
At the course level, authors toggle on/toggle off or adjust some configuration settings (iframe sizing) for tools that have be added and pre-configured by admins.
Within a course, authors can also configure tools within the course outline. This is what is currently possible, and we do not want to remove this capability. Any changes will only apply to the course for which the author has permissions.
Students not needing to give permission every time a tool launches - remembering student privacy permissions for an entire course.
License Ownership:
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 multiple organizations, provides a catalog of pre-registered LTI tool integrations to multiple customers – in this scenario, the business relationship is established at the platform level and there is only one platform registration per tool (client_id). Ignoring deployment_id, this is the same as use case #1.
User Experience: An admin integrates a licensed tool at the platform or instance level, and then provides use of this tool to multiple organizations, all using the same license, and all with the ability to apply this license and integration in multiple courses.
Enable or disable at the org level
Override at the org level
Operator with multiple organizations, each organization is responsible for managing its own catalog of LTI tool integrations – each org has a business relationship with the tool provider. There are multiple platform registrations (client_ids) for a given tool provider.
User Experience: An admin configures and integrates a tool at the platform or instance level, but each organization utilizes their own unique license (a là Canvas, adding 3rd party tool extensions with 1 click + key and secret) and each org has their own independent business relationship with the tool provider. For the MVP, the org is responsible for acquiring their own license outside the platform. At the platform level, there may be multiple organizations utilizing the same tool provider, each with their own unique license.
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’.
Features & Requirements
In order to realize this MVP, we believe the following features will be required. Refer to the following flow chart for more details:
Feature | Requirements |
Feature 1: Add LTIs at the instance or org level once, and have it available to enable in every course in that org or instance. | An Administrative Dashboard experience in Studio, where admins can:
|
Feature 2a: Have a function that would enable course teams to select from a drop down list of LTIs enabled at the org level. Feature 2b: Have the platform remember users' permission settings so they are not prompted with every launch. This would allow for a more seamless user experience. | From the Studio Dashboard/Studio Settings, users [course teams, faculty, etc.] will be able to:
|
Feature 3: Within a course, have an easy way for authors/course teams to configure a learning tool at the course level. | A space in the Course Outline (probably a component tile) where LTIs that have been toggled on for the course can be configured within a course. 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 the clone of a course. |
Feature 4: At the platform level, have a set of LTIs that are ‘pre-configured’, and only need a key and secret to enable at the org level. This way an institution only needs to acquire a license in order to set up an LTI from the ‘pre-configured’ list. Like the Canvas apps list. |
|
Short-term goals (MVP) of the Open edX LMS Consumer Strategy
For administrators, the process of configuring third-party apps for use across their instance or their organization should be straightforward and non-technical if possible.
The technical set up should only be required once per instance/platform, after which org level enablement should be non technical. This is the step at which a license (key and secret) can be entered, and access enabled
For authors and course teams, the process of choosing which pre-configured apps to use in a course should be straightforward, non-technical, and so should the process of configuring chosen and pre-configured apps within a course.
For learners, the process of engaging with an LTI tool should be straightforward and only require permissions for authentication once. User permissions around LTI should be stored and tagged to the user account, and ideally should follow the user from course to course to enable a unified experience. Furthermore, user settings should be saved for as long as a user’s account exists or until the user requests a change.
Archive:
Key Use Cases
To focus scope of the MVP, we are focusing on the following use cases that emphasize an enhanced learning experience for students, through facilitating use of LTI by faculty, learners, organizations:
At the organization and/or instance level:
As an Instance or Organization administrator, I want to be able to configure apps at the organization level, so they can be used in every course.
As someone in university tech leadership, now that I’ve acquired a license for Tool A, I don’t want to be pulled in every time this tool needs to be configured/added to a new course. I want to configure this once, and let all the instructors in their various courses add, access and use the full capabilities of this tool. I also want all verified learners to have access to this tool.
At the course level:
As an Instructor, I want to easily add LTIs to the course that have already been configured/licensed by my admin, by selecting from a list or dropdown menu. I know my university has a license with Tool A - I just want to just select that tool and add it to my modules.
Roles & Permissions Definitions (for MVP)
Superuser/Global Staff: Can add and configure LTI tools at the Instance or Org level, and for multi-tenant sites
Org-level Admin: Can add and configure LTI tools at the org level
Course author: Can add LTI tools to a course that have already been configured by a superuser, global staff or org-level admin
MVP: Key Features to Develop
(MVP) An Administrative Dashboard experience for admins to configure tools at the org and/or instance level
(MVP) A Studio Settings experience for authors or course teams to toggle on/off pre-configured apps in a course
(MVP) A workflow baked into the Course Outline experience for authors or course teams to configure apps at the xblock level