Course: Libraries Page: Libraries Tab: list all library-sourced content in the course

[bradenmacdonald]

Designs are being revised but the initial version is here in Figma: https://www.figma.com/design/Y3gSyrpG6uncUUfjK7eQuo/Content-Libraries-v2.1-%5BOpen-edX%5D?node-id=1549-46333&t=hhz5Rljy8gvcwIUY-4

[navinkarkera]

@jmakowski1123 @lizc577 @sdaitzman @marcotuts The designs are missing following details and also have some open tasks:

• Empty states for libraries tabs
• On library block delete behaviour
• Overflow menu options for library cards
• Ordering?
• Help panel text.
• Review updates alert location? Do we need to display this alert in libraries page and course outline page both or only in course outline page.

cc: @bradenmacdonald

[sdaitzman]

Hi @navinkarkera, the designs referenced on this ticket are quite out of date. We'll add this as a priority and try to provide some updated designs soon.

• On library block delete behaviour

I'm not sure I follow, is this a question about what happens when you delete content in a course that was added from a library? Or about what happens when you delete content in a library that was added to a course?

• Ordering?

I think the libraries can be sorted alphabetically, and their contents can be sorted either by most recently modified locally or by their first course appearance. We can include this in updated designs for this ticket.

• Help panel text.

Can also include this in updated designs for this ticket.

• Review updates alert location? Do we need to display this alert in libraries page and course outline page both or only in course outline page.

I think the alert can appear just on the course outline page. The Review Content Updates tag in the libraries page will have an update count badge, so the user will have a clear indication already there (and will most likely be on the page intending to sync changes).

CC @edschema

[navinkarkera]

@sdaitzman Thank you!

Or about what happens when you delete content in a library that was added to a course?

Yes, what should be allowed actions when a library block that is used in a course is deleted?

contents can be sorted either by most recently modified locally or by their first course appearance.

I think contents can be ordered based on the library block modified date. Ordering based on its location in course would be slow as mentioned by Braden here so would it be ok to sort by name or modified date first and them implement it in a separate task?

[sdaitzman]

@navinkarkera thanks for clarifying, these are good questions.

Yes, what should be allowed actions when a library block that is used in a course is deleted?

There are a few options:

1. Remove the block from the libraries content listing for the course (essentially looks as if the content is "reverted" to being local content). Potentially also remove library link icon from the object in course authoring.
2. Show a "broken link" icon in course authoring, show that icon next to deleted library objects in the libraries content listing

I would lean toward the first option to avoid increasing scope, and treat the second as a future improvement for when it's possible to restore deleted content. When adding library units to courses is implemented, if local unit instances are read-only to start, we can incrementally add a "broken link" icon in course authoring to make it clear why read-only local unit instances can't be modified (or we could actually break the link and make them editable). @jmakowski1123 does that approach make sense to you?

I think contents can be ordered based on the library block modified date. Ordering based on its location in course would be slow as mentioned by Braden here so would it be ok to sort by name or modified date first and them implement it in a separate task?

If needed, I feel okay about sorting by modified date first, with name as another option, and ordering by location in course as a later enhancement.

[navinkarkera]

@sdaitzman

2. Show a "broken link" icon in course authoring, show that icon next to deleted library objects in the libraries content listing
   I would lean toward the first option to avoid increasing scope, and treat the second as a future improvement for when it's possible to restore deleted content.

We already show a broken link icon in course authoring. Also, deleted library blocks can be restored via authoring frontend within first few seconds of deletion via undo option. I think displaying a broken icon would be easier to implement now.

[navinkarkera]

Posting screencast of my current implementation for reference.

vokoscreenNG-2025-02-14_21-20-42.webm

[sdaitzman]

Thanks @navinkarkera! Just confirming the logic for ignore changes: if you ignore changes, can you still accept future updates to the same component?

[sdaitzman]

We already show a broken link icon in course authoring. Also, deleted library blocks can be restored via authoring frontend within first few seconds of deletion via undo option. I think displaying a broken icon would be easier to implement now.

If adding the broken link icon is feasible, I think it makes sense to do that now.

[sdaitzman]

One more question: what is the behavior of that "review updates" button? I think we should display the library sync message banner on this page if we want to flag that there are updates.

[navinkarkera]

Thanks @navinkarkera! Just confirming the logic for ignore changes: if you ignore changes, can you still accept future updates to the same component?

Yes, we are reusing the review modal from course authoring page.

One more question: what is the behavior of that "review updates" button?

It takes user to Review Content Updates tab where user can review and update them.

I think we should display the library sync message banner on this page if we want to flag that there are updates.

Yes, that is the current behaviour. So just to confirm, we should also add this alert to course outline page.

[navinkarkera]

Posting screencast of current implementation state.

vokoscreenNG-2025-02-21_17-01-12.webm

@sdaitzman Please let me know when the designs are ready, I can make the required changes.

[sdaitzman]

Hi @navinkarkera thank you, this is great progress and looks really good. For Teak, I think we can simplify some of this to lay the groundwork for some more full-featured library object management in Ulmo or later. An updated design is attached below, and you can find it in Figma as well. We're still making some minor updates to the review tab, but here are the steps I think we should take for Teak:

• Drop individual components from libraries tab
  • The main purpose of the libraries tab for Teak should be to make it easy to access all the libraries used in a course; this screen primarily facilitates opening libraries and courses side-by-side. Grouping objects by linked library was important to facilitate library management for a library paradigm where each library would require manual linking. This now happens implicitly.
• Each library should just link directly and should be opened in a new tab

I want to make sure to resolve some potential issues when the same library component gets used in multiple places in a course and has different local edits.

• I think that the before tab preview should show previous local version, not previous Library version. Is that the current behavior?
  • If not, and if it would be difficult to show the local library version, I think the compare dialog should show a message at the top that the "Before" object is the library version.
• We should show 1 review object per library object on review tab (regardless of multiple instances). Eventually, it would make sense to allow users to review the "before" states grouped by unique local edit if that turns out to be a common use case, but we expect it will not.
• If a library object is used in multiple places in the course, including as the child of another unit, for Teak I think we can just show a message that the component is used in 3 places.
  • If it's difficult to detect this case, I think we should always show message in compare dialog if needed.

CC @jmakowski1123 for confirmation on this product direction, and @edschema (who is now working on updated designs for #1566)

[jmakowski1123]

Based on the team sync today, we decided to stay with the current implementation of the preview tabs showing local library versions. We also decided to stay wtih the current implementation, that each reuse of a library object will display as its own sync.