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