Status: Handed off for UX/UI mocks and Technical Discovery UI Implementation underway
Table of Contents | ||||||
---|---|---|---|---|---|---|
|
Overview
...
...
MVP Specs
Users
Features & Requirements
Taxonomy Field Types
Tag behavior
Technical Open Questions
Product FAQ
Future Direction
UI Examples
Content Author user stories - Creating tags
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.
...
Based on the above use cases, we are breaking down on high-level scope as follows:
In Scope | Out of Scope |
Taxonomy association at the Instance and organization level. | Personal or course-level taxonomy association. |
Taxonomy authoring through a CSV/JSON import process. [Stretch] Manual taxonomy creation directly in the platform. | |
Taxonomies will be made available to all courses and libraries within an organization. | Ability to free-form tag without an super user-defined field. |
Ability to create both super user-defined fields for free-form tags and closed (super user-defined fields and values) taxonomies. | Ability to make it required for authors to add specific tags. |
Ability to add/remove tags at unit (outline + libraries) and component (library only for now) levels. | Tagging at other levels. |
Tags will |
be visible to |
authors in Studio. | Tags will not be visible to |
learners. |
Tagging at |
unit and component level. | Search across courses and/or libraries. |
Free text search and tag-level search at both library and course outline levels. | Analytics on learner engagement with tagged content. |
We will create a product tour for new users. | Ability to programmatically add tags on components/units. |
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
Feature | Requirements |
Studio Home Access to Taxonomy Management System | All users with Studio Home access have the ability to view taxonomies at the org level in the same way they can see Courses and Libraries today. |
Taxonomy Management System | Designated instance-level super users have the ability to do the following across the instance:
Designated org-level super users have the ability to do the following across the org:
All super user-created taxonomies can be set up as specific fields that content authors can free-form tags on or as closed taxonomies with defined field-value pairs. The taxonomy authoring experience should include access to a downloadable template (example) and instructions for how to set up/import a taxonomy. Super users can create hierarchical relationships (child and grandchild) between tags. Non-super users have the ability to view existing taxonomies. |
Course Settings | Content Authors can turn taxonomies (instance and org-levels) on/off at the course level. |
Course Outline Unit-Level Tagging Tool Course Outline Component-Level Tagging Tool Libraries Component-Level Tagging Tool | Content Authors can view/add/delete tags as part of their authoring workflow in three separate experiences. The component-level tagging experience should be aligned across Course Outline and Libraries, while the Unit Level one only exists for the Course Outline today but future expansion to the Library authoring experience should be considered. This includes:
Permissions for adding or editing tags follow the same logic and permissions structure as editing content. |
Course Search | Authors can search for content within their Course Outline using both freeform keyword search (i..e, not tag-related) and tag-specific search. Include a facet for content type. |
Library Search | Authors can search for content within their Library using freeform keyword search (i..e, not tag-related). Authors can search for content within their Library using tag-specific search. Include a facet for content type. This experience should mirror that in the Course Outline. |
Course Library Reference Component Search | Authors can search by tag for content within their Library using tag-specific search from within the Library Reference Content xBlock. |
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.
Field Type | Option | Field (example names) | Tag (value) | Content Author Experience |
|
|
|
|
|
System-defined | Core tags controlled at the platform level (and auto-generated from the codebase) in order to keep consistency across search and discovery and for general messiness control. Super users would not be able to change these. | Language, format/content type, organization | Specific set against each of these. | Many of these would not be visible but some might be integrated into facet search (e.g., content type). Most would not be editable (ex. Perhaps language?) |
super user-defined fields | Super users can set up specific fields that authors can free-form enter tags on. These would typically be used for instances in which there could be many possible tags but super user wants them organized separately from free-form tags | Outcomes, Learning Objectives | Anything Content Author wants to enter | Content Author is presented with the field and can enter a single free-form value. |
super user-defined closed taxonomies | Super users can set up specific fields that require closed taxonomies (including selecting from existing, uploading, manually creating). Includes ability to create child and grandchild hierarchies | Lightcast skills, state standards | Biology, Microbiology | Content Author is presented with the field and a drop-down (or other UI selection element) to select the value. |
Tag behavior
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.
When a Content Author exports a course to a Library, all associated tags will display with the content in the Library.
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.
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.
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.
These core fields may be auto-generated from core data models in content blocks.
The fields and taxonomies will be unchangeable by the user.
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.
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.
...
Where should the taxonomy live? Should it integrate with the current Discovery tagging tool or be built as a standalone service.
Current discovery: https://github.com/openedx/modular-learning/issues/43
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.
...
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?
...
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
...