Status: UI Implementation underway

Overview

This document lays out the product specs for the first incremental delivery of value towards the broader Content Tagging Strategy for the Open edX Platform. The aim of this 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.

Key Use Cases

To focus scope of the MVP, we are focusing on the following use cases (selected from larger list) that emphasize reusability of content, including the ability to search for content based on tags:

• As an Instructor, I want to see all the content I've got for a particular competency, or subject, or skill, or learning outcome.

• I want to search and filter for content catered to individual learner needs or knowledge gaps. 

• I want to attach topic tags to questions I create in Content Libraries so it's easy for me to find questions and reuse them in different assessments.

• I want to create components that I can reuse in different courses, and tag those components with the right subject, like ‘soil health’, so I can see quickly what the subject matter of the component is when I reuse it.

• As a learning designer, I want to tag units for competencies and learning objectives so that I can check for alignment between unit learning objectives and the overall course objectives.

• I want to pull in external taxonomies such as the Open Skills Management Network so I don't have to create my own taxonomies from scratch and can align my content with third-party, vetted taxonomies.

Deliverables

• Taxonomy Management System (Instance & Organization levels)

• Tagging tool (Course & Library levels)

• Content search capabilities (Course & Library levels)

Users

• Instance-Level Super User: Refers to anyone with the ability to create and manage taxonomies for an entire instance. This is particularly relevant in multi-tenant (i.e., multi-org) instances the platform. This user typically has admin controls through Django Admin. We are proposing that as part of this project, this user type can manage instance taxonomies within Studio to take advantage of what we build without having to go into Django Admin.

• Org-Level Super User: Refers to anyone with the ability to create and manage taxonomies for an organization. We anticipate that this role will be assigned in the same way that one is granted the ability to create courses and libraries today.

• Content Author: Refers to anyone with the Staff or Admin role on a Course Team within a Course and/or Library. These users will be able to manage tags using the tagging tool.

• Learner: Refers to anyone engaging in learning on the LMS. Tags will not be visible to learners as part of this MVP.

In Scope / Out of Scope

Based on the above use cases, we are breaking down on high-level scope as follows:

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: Tagging MVP Workflows

Taxonomy Field Types

We use the following definition of field types throughout the document. The MVP should include all these types except for free-form.

Tag behavior

1. When a Content Author reuses components from a Library to a course, all associated tags will display in the course outline. Tags will not display in the LMS or in any learner-facing view. 

2. When a Content Author exports a course to a Library, all associated tags will display with the content in the Library.

3. The tags and taxonomies that a Content Author sees are determined by the taxonomies chosen and configured for their Instance or their organization. So if Instance A uses the Lightcast Skills taxonomy and Instance B uses the Open Skills Management Taxonomy, each will only see the tags in the taxonomy configured for them.

4. Tags will not be associated with specific course runs or versions. When a tag is applied, it will remain with the component/unit for subsequent course runs. Tags added will not be applied to previous versions of the content.

5. The platform will identify a core set of fields and taxonomies that are established and standardized, such as “language”, “content format” and “organization”. The platform will control these taxonomies to mitigate messy data and so that these fields can be used for faceted searching in libraries. 

   1. These core fields may be auto-generated from core data models in content blocks.

   2. The fields and taxonomies will be unchangeable by the user. 

   3. Many of these would not be visible but some might be integrated into facet search (e.g., content format, language). Most would not be editable.

6. When taxonomies update, super users have the option to edit existing taxonomies or create new taxonomies. There will be no version control to associate multiple versions of a taxonomy.

Technical Open Questions

We anticipate the following to some of the key questions that we will need answered during technical discovery. 

• Where should the taxonomy live? Should it integrate with the current Discovery tagging tool or be built as a standalone service.

  • Current discovery: Architectural discovery - should tagging be built as a separate service? · Issue #43 · openedx/modular-learning   

• What is the best way to address the needs of a multi-tenant/org instance in which we need the ability for specific users to be able to create centralized taxonomies that are available to all organizations in the instance, while other users are only permitted to create taxonomies that live at a specific org?

  • Current thinking: We would like for the same taxonomy system to be used but separate super user permissions between instance-level and org-level.

• How might we handle the situations in which users need to add and/or delete rows from an existing taxonomy? Should we build the capability to manually add these into the UI or force users to do an export→edit→import workflow? If we choose the former, shouldn't we also allow users to simply leverage that same functionality to create simple taxonomies directly in the UI?

  • Current thinking: We think eventually full manual taxonomy creation and adding/deleting fields should be available but not sure if this is technically too much scope for MVP. If it is, are we okay with the MVP process involving more cumbersome export→edit→import workflow?

Successful Rollout: UI Considerations

We believe there is some risk in low adoption of this new feature upon initial rollout due to the lift involved in aligning on taxonomies and tagging content. We believe that organizations will need time to get used to thinking about this and that future feature enhancements (such as tagging APIs or AI-driven tagging) may lower the barrier. Therefore, we want to be conscious about how we might drive adoption and educate users during the MVP stage. 

We are proposing the following to help drive adoption:

• New User Product Tour: MVP should include a new user product tour that will be used to walk authors through the features of the new tagging system and present ideas on how they may use it. This tour may include a video of the features and be set to prominently display to them when first accessing the Taxonomy Management System. We should consider whether the tour will only be available to super users who can create taxonomies or whether to include a non-super user facing tour available within the Taxonomy Management System and/or Course Outline/Library that raises awareness of features and encourages them to talk to super users to get a taxonomy created. Risk here is that the Tagging Tool cannot be used until a taxonomy exists.

• Taxonomy Management System Getting Started Guide: Within the Taxonomy Management System, we need to provide super users with the template to create taxonomies as well as links (and possibly templates) to suggested taxonomies they may want to leverage. These can be hosted on docs.openedx.org.

Product & UX/UI FAQ

The following represent our Product view of key questions. However, we look to the UX/UI and technical teams to validate these as needed.

Q: How many levels of hierarchy will we support in initial taxonomies?

A: 3.

Q: Can a taxonomy author upload multiple free-form field taxonomies at the same time using an import file?

A: Yes

Q: What kind of user experience for viewing taxonomies are we expecting for the following hypothetical – an org taxonomy that has one very large predefined taxonomy (e.g., Lightcast skills) with thousands of rows of fields:tags, one medium-sized super user-defined closed taxonomy with hundreds of fields:tags at three levels of hierarchy and then dozens of free-form admin- defined fields?

A: ???

Q: Is it possible to re-upload/replace an existing taxonomy? If so, how?

A: ???

Q: Will we pre-load some taxonomies that they can use into the system?

A: In looking at this as a possibility for MVP, we decided that it would be too difficult to try to identify the right taxonomies, pre-load them onto the platform, and commit to keeping them up to date. This would also mean that certain taxonomies would always be loaded into the platform in a completely different way. Extending the Taxonomy Management System to an instance-level superuser and providing recommendations on possible taxonomies to import would help seed this instead.

Q: How will tags update when someone tries to edit a tag on a component in a course outline that is also in a library and possibly used in other courses?

A: ??? 

Q: Decision on tag relationships between components in a unit to that unit and vice versa

A: The logic for this should align with how this is handled for all other updates made to these shared components 

Future Direction

The following features are not part of the MVP but may be added during future development of this product. They are offered here only for consideration as MVP platform decisions are made that may impact future opportunities. 

Tagging Tool Development:

• Open-ended free-form tags (and a strategy for data management)

• Adding tags to subsections and sections directly in the course outline

• Creating units, subsections and sections independently in Libraries and add tags as part of that authoring workflow

• Taxonomies will support localization

• Programmatic ways to bulk add tags (e.g., authoring APIs or AI-driven solutions)

Tagging Management System Development:

• Map hierarchical or horizontal relationships

• Personal taxonomies

• Enhanced controls such as locking down taxonomies

Content Management Experience Development:

• Use tags to organize content into playlists, folders 

• Additional search filters

Tag Performance

• Tools to assess content and/or learner performance based on tags

• Tools to facilitate content recommendations 

UI Examples

Source: OER Commons, http://www.oercommons.org

The following are examples used as reference for possible UI approaches.

Content Author user stories - Creating tags

Authors can see tags displayed in content blocks in Libraries and in each level of the course hierarchy in Studio.

OER Commons has built a tag display UI where tags/metadata are presented beneath the content block itself. See example here: https://www.oercommons.org/courses/musical-tension-and-release

Open

Open

Authors can add free-form tags on super user-defined fields.

UI where author is presented with the field and can enter a single free-form tag.

OER Commons has an author interface for “free form tags on super user-defined fields” here. The instance administrator would have already defined that “subject”, “education level” etc are fields that should be attached to the content. However, there’s no prescribed taxonomy attached, so authors can type anything they want in those fields. Maybe there’s predictive suggestions when they start typing. 

Predictive suggestions:

Authors can choose from a tag from an super user-defined closed taxonomy.

UI where author is presented with the field and a drop-down (or other UI selection element) to select the value.

This is OER Commons interface for “super user-defined field with closed taxonomy”. So in this case, the admin has predefined “education level” as the field, and associated a taxonomy with 8 tags in it (“preschool”, “lower primary” etc). The author must choose one of those 8 fields. We can imagine taxonomies with hundreds of tags in them. In this case, maybe the drop down is alphabetical, or maybe there’s also predictive suggestions, but the suggestions are limited to terms in the taxonomy.