Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

MVP: Key Features to Develop

  1. (MVP) An Administrative Dashboard experience for admins to configure tools at the org and/or instance level

  2. (MVP) A Studio Settings experience for authors or course teams to toggle on/off pre-configured apps in a course

  3. (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 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.

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:

  • Configure an app, for use in courses, within an instance or org

  • Manage configuration settings so it doesn’t need to be reconfigured multiple times

  • Manage all chosen apps made available to users in an org or instance, depending on administrative permissions

  • Manage licenses at the org level

  • A setting that enables tools to be turned off or on for specific courses in an org or instance.

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:

  • Select from a list of pre-approved tools licensed at the org level (as maintained by the org admin)

  • Enable the appropriate tools within a course needed for learner success

    • Option 1: Adjust configuration settings for an approved tool for improved utility

    • Option 2: Request a tool that has not previously been configured at the org or instance level. This request should be forwarded to and handled by the instance level or org level admin. The workflow for this request transfer is not within scope for this project, but should be determined by instance or org admins.  

 

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

  1. 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.

    1. 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

  2. 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.

  3. 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.

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

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’.

  • No labels