Status:
Overview
This document lays out the Product Goals and the steps toward incremental delivery of value towards the broader Open edX Learning Tool strategy. The aim of the MVP is to deliver value as quickly as possible by limiting scope. This will allow us to learn quickly and shape future direction based on how stakeholders use the new tools.
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.
Long-term goals (beyond MVP) of the Open edX LMS Consumer Strategy
For all Open edX users, the process of finding compatible learning tools, whether third party applications or native xblocks, should spark inspiration, while offering straightforward means of integration or configuration. The goal should be to offer customizable learning experiences and to improve pedagogical outcomes.
Strategic Goals
The benefit of this work for edX and Open edX as a platform, is that this will bring the platform a step closer to providing the best of both customization and ease of use for those who want the freedom, privacy, and security of an open source LMS. The hope is that these first of several LTI usability enhancements to the LMS will enable and support the platform’s goal to maximize customization possibilities and to support subject-specific teaching and learning needs.
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.
As an instructor, I want to enable this tool for some courses and not others. I want to be able to save custom settings so I don’t have to rebuild it for every use case.As an instructional designer, I want to search for a type of tool or even see recommendations for various tools when I’m planning a course. I want to clearly see which ones are already enabled, which ones can be added easily if I get a license, and which ones would require more specific one time configuration.
As a student I agreed to the permission needed to use Tool A, why is it asking me for permission again every time it launches?
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
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’.
Placement Options:
Options related to placement of LTI tools for organizations and instructors. When deciding on the best placement we also need to ensure consistent interactions across the platform. At this time, the new Studio UI is a WIP. At this time, however, we could draw inspiration to the new Files and Uploads UI.
See Further Details on Subpage
Placement Case Studies: See UX/UI Subpage for Details
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
(Not MVP) A Global Marketplace of Learning Tools that are compatible with the Open edX platform
Phased Deliverables
MVP Stage 1: Instance or Org-level LTI Configuration, and Course-level LTI Configuration (2023)
Configuration: Instance/Platform, Org, Course
Instructors or course leads adding a tool at the course 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 it is available for use in any course in that org/instance
At the course level, authors toggle on/toggle off tools that have be added and pre-configured by admins
Within a course, authors configure tools within the course outline
Students not needing to give permission every time a tool launches - remembering student privacy permissions for an entire course.
Platform/org level LTI License Management
Please see License Ownership above for User Stories + License Use Cases
e-Commerce for LTI tool providers:
Allow orgs to sign up & pay for for LTI vendor license within the platform itself with consenting vendors. This would make usage even easier, but the key and secret would need to be applied on the backend.
Additional infrastructure needed: A way to track usage in the way that the vendor needs it to be tracked (examples: exam count vs student count), and for the license holder to be billed - all within the platform.
Stage 2: LTI Directory to improve discovery for course-level tools, (2024)
Tool recommendations as part of the LTI /Learning tools Directory - by category or function. Enable a 1 click add for pre-configured tools, only needing a key and secret to activate at the org level. Adding this to the org level experience.
Stage 3: Student-level Applications space, (2024 or 2025)
Students able to add accessibility supportive LTIs that could work across their courses - and support their learner experience. Tools that allow for individual student licenses only.
As a student who needs accessibility accommodations in note taking, I’d like to add a tool that allows editing of transcriptions, and to participate via voice or text with my peers in live sessions. I can sign up for a license, and then install it once, making it available for me in all my courses. I can have the learning experience I need to thrive.
Curated list of tools that support a learner’s accessibility needs: auditory support, neurodivergent /cognitive support, visual support, etc.
Conceptual Visualizations
See Further details on UX/UI Subpage
MVP Specs
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. | 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. |
Technical Open Questions
We anticipate the following to some of the key questions that we will need answered during technical discovery.
What is the technical lift for the features listed above for Stage 1? How much of Stage 1 can be captured within the MVP in 2023?
For Stage 2: What would be the technical lift for having separate customizations with different tools default configured in each vs having all approved tools configured broadly, but enabled at the customization level? Technical lift per tool vs number of tools.
What things can be done on the back-end now, BEFORE having UI done?
Re-usable configuration → at course level, at org level, or at instance level (power to override/customize configuration settings high to low)
Configuration and license settings saved at the org level
Product/UX Open Questions:
Widespread need for import/export of settings? (talk to MIT and Harvard/Colin)
What does author experience look like vis-a-vis dynamic admin decision-making on what to enable/disable?
Need for UI for tools that place tools in other parts of the course besides the unit level?
Placement options: overlay, side panel, embedded, pop-up, in-line
case study examples of 3 different apps with different placements needs - capture the different options that will need to be included in the spec
capture with case studies (screen captures? would take some time, but that’s ok) what these different LTI integrations and interactions with the content would look like
Ed, Annoto, and Yellowdig as example use cases?
when instructor enables at course level - it can be placed anywhere within the unit, or moves dynamically with the content, etc - however it needs to be placed
there’s a requirement to place tool anywhere in the unit an instructor wants, not just as an xblock in a unit
does it need to be placed at the section level? or at the course level? in other places besides the unit
Instructor vs learner view of LTI tool placement tool placement presets - does this have an impact on tech?
capture in admin dashboard as a workflow - uniform decision across all courses across an org
Questions:
Can you import or export configurations from one instance to another? Is this a need?
probably could use data from users - check in with Harvard or MIT
not MVP, but find out if users will eventually need it
Override at the org level if something is configured at the instance or platform level?
This does need to be possible
Add as user story and as requirement in admin dashboard space
What is in MVP vs future iterations?
hit the main needs only
Licensing use
Account for gaps in current PRs