Status: Handed off for UX/UI mocks and Technical Discovery UI Implementation underway
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
...
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.
...