...
Similar to the Libraries MVP, this phase of work includes user stories that bridge workflows in both Libraries and in courses, more specifically the Course Outline page.
Functional requirements: Library Side
Units function as independent, bounded entities in Libraries
Libraries support units (defined as a pre-determined sequence of components) as independent, bounded entities. In other words, the sequence of components – the unit – is treated as a singular object.
Units are considered a “content type” in the filter
Units exhibit many of the same behavior patterns in Libraries as do Components:
Creating and Editing Units
Units can be created from scratch in the +New workflow. When a new Unit is created, components can be added, rearranged or removed to the Unit.
Units can be edited, meaning components can be added, rearranged or removed
There are 3 pathways for adding components to a unit from within the unit editor
New components can be created
Existing components can be added
Components copied in the clipboard
When components within a unit are being edited, they must visually display in some way their connection to the unit (breadcrumbs?)
Expected behavior of Components in relation to Units
We assume valuable reusable potential for all components in a Library, whether they exist as standalone entities or as part of units. Thus, all components in a Library can/could exist as both a standalone component and / or as part of a unit or many units.
When a component is created within the context of a unit, it does not automatically populate in the Library as a standalone component, but authors are prompted at the time of creation or edit whether they want the component to be added to the Component Tab.
If a Component is added to the Component tab, it remains synced to the unit(s) where it is referenced
Components can be copied from a unit and pasted into the Library as a standalone component, or into a collection.
If a Component is pasted elsewhere in the Library, it remains synced to the unit(s) where it is referenced
When a Component is reused as an existing component in a Unit, it maintains its reference to the original component.
When authors edit a component that is referenced in a unit, they are prompted to choose whether they are editing within that usage or as a new block.
If they choose as a new block, the reference is broken.
If they choose to edit within that usage, all changes are synced across all references and standalone instances of that component within the library.
...
Units can be published. Once published, units are available for reuse.
The same publishing rules apply to units as components; units are available for reuse in courses once they are published (see: https://github.com/openedx/frontend-app-authoring/issues/1353 )Publishing can happen at the Unit level. When a unit is published, all components within it are published. If a component in a unit also exists independently of a unit, it will also be published.
Quick publish concept for reused components: If a component is published, it will auto-publish in any unit where it is referenced, unless there has been an override of that component in a unit, in which case authors will be prompted manually to accept the changes.
When a Unit has been published, it is available for reuse in a library. If some individual components in a unit are published but not all components, the unit is not available for reuse yet.
Units can be tagged
Units can be copied
Units can be pasted
Units can be added to, and removed from, collections
Collections can contain a mix of both components and units
...
Requirements TBD
Managed content item - any level of content (section, subsection, unit, component) that exists in a library.
Externally managed content item - any level of content that exists in a library that is ‘connected’ to an external CMS.
Unmanaged content item - any course content not from a library
Functional requirements: Course Side
Units can be reused in Courses
Units can be reused via the Course Outline page in a course
Library search can be accessed from within the course so authors can find which units they want
Library units can be synced/updated from the Course Outline page
Units can be updated in a library and synced at the course level
Users receive notifications about content updates made in a library
Users can review and accept/deny content updates [need to tie the definitions/requirements for managed and unmanaged to the sync workflows]
Accept the updates and override any local edits that may have been made to the unit
Accept the updates while keeping any local edits that may have been made to the unit
Deny the updates
A refresh of the library will update the course, but will not affect unmanaged content (unless its parent is removed).
Units can be edited locally
Happy path and edge cases TBD
Course authors can add content, in the course, to library-managed content items. For example, a course author can add an LTI component to a unit that is contained in a subsection that is managed by a library.
Locally, components within a unit can be rearranged into different orders (parity with current experience with units in courses.)
UX/UI Needs
Library-side
Libraries must support a creation workflow for creating new units, subsections and sections
Libraries must support an editing workflow/editor environment for units, subsections and sections
In-context sidebars must be expanded such that each unit, subsection and section has a sidebar.
Needs discovery: Are previews necessary? Even possible?
Library Home must contain one tab each for units, subsections and sections, where users see a filtered view by content type
All of the searching, sorts and filters that apply to components must be extended to units, subsections and sections.
...