Status:
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
...
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
...
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
...
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.
...
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
...
Key Features to Develop
(MVP) An Administrative Dashboard experience for admins to configure tools at the org and/or instance level(MVPPhase 1) A workflow baked into the Course Outline experience for authors or course teams to configure apps at the xblock level
(Phase 2) 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 Phase 3) An Administrative Dashboard experience for admins to configure tools at the org and/or instance level
(Not MVPin Scope) A Global Marketplace of Learning Tools that are compatible with the Open edX platform
Phased Deliverables
...
Phase 1: LTI Workflow Enhancement
Phase 2: A Studio Settings Experience
Phase 3: 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.
...
Phase 4: 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.
...
Phase 5: 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.
...
See Further details on UX/UI Subpage
...
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.
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 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:
What is in MVP vs future iterations?
hit the main needs only
Licensing use
Account for gaps in current PRs
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
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
Future Vision
Learning Tool Center/ LTI Global Marketplace
...