Status:
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
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:
WIP
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.
Modal Overlay
A modal presents a required action to a user, which blocks the use of the rest application until the action is completed, or the modal is exited.
Anatomy of an optimal modal:
The Nielsen Norman Group define modals / non-modals as the following:
Modal overlay: Content on page is disabled until the user interacts with the modal.
Non-modal overlay: User can still interact with the background content.
The current Files and Uploads UI incorporates modals as follows:
Non-modal Overlay
...
A non-modal overlay can show advanced controls, explanations, or help. They’re often used when a task is not critical, and don’t block the use of the rest of the application. They can be disruptive, especially when obscuring important information.
...
Google Mail uses a non-modal overlay to compose new email messages. You can continue using the entire application with it open, or minimize it without losing your draft.
There are many different examples of non-modal overlays. For the purpose of this document we have selected two options that might serve as inspiration for LTI Placement:
Files and Uploads:
It seems the new Files and Uploads will include non-modal overlays.
...
Slide-out Modal
...
A slide-out modal is a panel that slides in over the application, partially covering the underlying content. It’s best used when a user needs to see additional content or functionality without leaving their current view.
...
...
Inline Accordion
Inline accordions display content within the given page. When a user selects a link or button, a panel opens below it displaying the content in question.
New Tab
...
When the user performs an action, a new page opens in a new tab.
According to the Nielsen Norman Group:
...
Dropdown
Similar to how Figma installs plugins: https://help.figma.com/hc/en-us/articles/360042532714-Use-plugins-in-files#:~:text=Figma%20design%3A%20Click%20Resources%20in,select%20the%20plugin%20under%20Recents.. This might be a nice way to keep the interface free from clutter. The user could always choose “more” and it could open a sidebar.
Popup
Not to be confused with the modal! A popup appears on top of the current content, and is usually triggered by an interactive element. Popups are generally smaller in size and house less content than modals. Users can often still interact with the underlying content without the popup being closed.
Status:
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
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
Case Studies: WIP
Annoto
Function: social annotation tool for video (and pages)
overlay:
layers on top of all video
allows faculty to input quizzes along the way that is graded, grade passback
comments and chat discussions on the video (with text, audio or video responses possible)
all interactions in a transparent layer on top of the video
annotation of page or documents also take place on a transparent layer above content
learning analytics tab
a tab where instructors can interact with learner analytics from all interactions of user with overlay
...
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
End-to-end workflow
...
An Administrative Dashboard experience for admins to configure tools at the org or instance level
...
A Studio Settings experience for authors or course teams to toggle on/off pre-configured apps in a course
...
A workflow baked into the Course Outline experience for authors or course teams to configure apps at the xblock level
...
cognitive support, visual support, etc.
Conceptual Visualizations
See Further details on UX/UI Subpage
MVP Specs
Features & Requirements
...