MVP
...
(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
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:
...
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:
...
Course author: Can add LTI tools to a course that have already been configured by a superuser, global staff or org-level admin
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.
...
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