/
Content Libraries Decision Log

Content Libraries Decision Log

Pending decisions

Decisions around support for Legacy Libraries in Ulmo

Supported:

  • Editing exiting legacy libraries

  • Viewing legacy libraries

  • Syncing legacy references

  • Creating new legacy references

Not supported:

  • Creating new legacy libraries (via the legacy UI)

  • Q: Do Ulmo v2 libraries support advanced python problems?

    • If so, then there are no remaining use cases for V1 libraries, so it is OK to completely drop ability to create new ones.

    • Otherwise, we should still support some way to create legacy libs, so either we will:

      • Document REST API endpoint for creating legacy libs, or

      • Add the UI for it in frontend-app-authoring

Decisions around text overrides and available syncs

Context: We’re allowing text overrides for Ulmo, but we also have the following temporary limitations for Ulmo:

  • The sync modal may not show a diff of component before/after state for reused content blocks.

  • We will not support partial syncs (ie syncing parts of a published update but keeping some other local overrides).

Pending decision:

Given the above, we think locally overridden library text blocks should not receive updates when a new version is published at the library. Without giving users the visibility and tools, we want to avoid the possibility of accepting a sync without understanding the implications, and blowing away local edits.

Cases to discuss:

  1. A library text block is added into a course created unit. An educator edits that component. When a new version of that block is published from a library we think the block should not appear on the library updates page, and should not have an available sync icon.

  2. A library text block is reused into a course as part of a library unit. An educator edits the text block. A new version of the unit is published where the only change is to the text block ie: no reorders, no other changes to any other content of that library sourced unit. In this case, we think the unit should also not appear on the library updates page, and should not have an available sync icon.

  3. As above, a library text block is reused as part of a Library Unit to a course, and an educator makes a local text override). A new version is published from the library where multiple edits are made including a change to the locally edited text block. What should happen in this situation?

Decision around what components to import from a course

  • We import anything that has an XBlock installed for it. If it’s not known to work properly in libraries, we fall back to displaying OLX.

  • By default, we filter the search to only show supported types, but users can opt to include unsupported ones as well. Certain fields like the title will still work.

Decisions around export+backup+restore:

Decision - We will allow cross instance sharing of export files

Decision - We are intentionally NOT calling this export/import. trying to make this clearly different from the persepctive of users

Pending decisions:

  • Q: Do we need to export both published and drafts? Do we need to preserve history on export? If we are preserving both draft and publish on export, then what is the behavior on import? OR can we just import/export draft and control publishing of that as part of the import process

Settings on imported blocks: What should be preserved in libraries, what should be shown in libraries, what should be copied into courses, and what additional prompts and validations are needed?

6-24 Decision:

  • All subsection/sections are preserved on import from a course to a library

  • Settings are viewable but not editable in libraries. UI question as to how.

  • When these subsections/sections are reused, need messaging for authors to guide any re-configuration needs in the local courses.

Product to-dos:

  • UI for view only settings in Libraries

  • UX/messaging for authors to re-configure reused content locally in courses

  • (Discussion between Eddie and Braden that I missed)

  • Braden: One option is: Preserve settings in library, but drop them in the course

  • Scott: Seems weird to import graded subsections into a course. Seems like they should come in without a grading policy, but maybe they have a message saying that they were graded and that the new author should set a new policy.

  • Which settings are where in the spectrum of very-not-library to useful-as-defaults-from-library?

    • Verawood Plan: Settings visibility + editability

    • - Visibility (Section, Subsection, Unit)

    • - Graded / Ungraded (Subsection)

    • - Messaging in course noting “Format” (ex: HW, LAB, etc) is not yet specified)

    • - Discussion Enabled / Disabled (Unit)

    • - *Consider Discussion App setting only?*

    • - Reuse Notes (New / Future)

    • - increment toward showing pedagogical intent

    • - Learning Objectives (Section, Subsection, Unit) → New / Replacement for Section Highlights)

  • https://docs.google.com/document/d/1ZxxetJgMXn-aa0ybFDEbm1tE623Nr6TXwk3XTBfgsTo/edit?tab=t.0

  • Braden: Two different ways libraries can be used… as a general content repository, and as a personal content repository. The former is more likely to not want settings from the library, whereas the latter use case does.

    • Scott: Agreed. Latter is similar to re-runs… one does want the settings to copy over.

  • Are there any that definitely should not be carried over and preserved?

  • Scott: Whatever we do, just be transparent. Make it obvious that additional config is necessary

  • Marco: 3 things

    • while in libs, what does the settings tabs show?

    • on ref/reuse, do we need an extra step for structural blocks?

    • missing validation in the authoring environment. e.g., making sure the grading policy matches the number of units

  • existing validation frameworks

    • one validation framework for just components (e.g. problem bank)

    • one at the course level – “checklists”

  • Dave:

Write permissions at the content level (instead of library level?)

Content Libraries Sync Notes | [date]

Approach for “forced V1 migration” in Verawood

Content Libraries Sync Notes | [date]

Proposed: Make the sidebar a plugin slot when we refactor those into new groupings as part of upcoming UX work.

Rationale: This is a natural extension point and likely one of the more stable elements of the UI.

Dave: Another Ulmo discussion: What plugin slots are we going to ship?

Braden: I think a lot of that depends on how stable we think the current UI patterns are. Will we be introducing list mode or bulk edits or major re-organization of the sidebars? If so, I'd be hesitant to build too many plugin slots for now, or would at least carefully mark them all as unstable.

So maybe this is a question for the -ux channel too

Sam: I think it’s fairly likely that a few of those changes may come up in the next 2-3 releases, depending on user feedback

  • List mode is in consideration for post-Ulmo

  • We have some initial designs for bulk edits, but are not currently prioritizing them soon (will evaluate based on user feedback)

  • We’re planning to restructure and rename the info sidebars already, under a more clear grouping: Preview / Organize / Usage / Settings (this may fall under Ulmo, or post-Ulmo)

Dave: I think making the sidebar tabs an extension point would make sense then. If we're shuffling them around anyway, it might be a good time to make sure we can add new ones.

Braden: Yeah that sounds good

Long term: Course editing options for Learning Core-based courses?

Are we going to support the exact Course editing experience when moving a course to Learning Core, or will those courses only be editable in a new to-be-built UX? We definitely need to continue supporting some course-centric authoring view, but exactly what this is may be a post-Ulmo exploration/decision. (slack thread)

Dave:

(longer-term conversation) Maintenance burden of maintaining Course editing in Studio

Kyle, Braden, and I are putting together a conference talk on what it would mean to port courses to Learning Core. Based on previous conversations, our sketch is going to assume that we're keeping two editing experiences for courses--one through the existing course editing UX in Studio, another via a new "make your course in a Library" interface that has yet to be fleshed out.

I just wanted to flag that having parallel experiences is going to incur a high cost. We'll need to:

  • Re-implement the Studio backend for course editing to support Learning Core as a backend.

  • Maintain both implementations in parallel for a transitional period, e.g. with new features and bug fixes.

  • Deal with mismatches in capabilities if we want to enable new capabilities (which I really think we do). For instance, you won't necessarily need to sync anything if you're adding content from the same library, we'll be able to do much richer queries on publish/draft change history, etc.

From an implementation point of view, I would really like to see us create Learning Core backed courses in an entire new interface that is libraries-friendly (whether that's within a library explicitly or not). So basically, something similar to what we're planning to do with v1 libraries: a course is either in the old world or has been imported into the new one.

(It can still show up in the top level list of courses, but when you click, it goes to a new interface if it's backed by Learning Core and made to work seamlessly within libraries.)

Jenna:

this is def a longer term convo. I don't see a world where we don't have the option to continue creating top-down courses, as it exists today. Whether that continues to exist in studio or elsewhere is another question

Dave:

Do you know at the moment if that mean we need to preserve the old course editing experience as-is, as a parallel path? Or might it be acceptable to have a solution where clicking on a course in the Studio list of courses takes you to a "course editing" UI that is in a library (even if the library aspect of it is minimized somehow)? (e.g. there are different "views" of the library).

(If the answer is, "we don't know yet", that's totally fine.)

(I just want to make sure that we're conveying that uncertainty accurately.)

Jenna:

I think as long as the course editing UI maintains parity with what exists today (barring improvements we continue making), and the UX is no confusing, that could be open to exploration

maybe the prototype to explore this is building some sort of CBE pathway sequence creator in libraries/on LC

Log

Jun 3, 2025

  • Decision: Learning highlights we will treat as a setting that doesn’t get carried over into the library because it is course-specific.

    • However, we are exploring a learning objective/learning outcome field with library content. Still pending some input from the CBE product discovery this month. The longer term intent is to depr the learning highlights feature and replace it with a better designed and more comprehensive learning objective. Open questions about relationships to tags, etc.

Jun 6, 2025

  • V1 library migration - Ulmo will be manual/voluntary migration only; need to make a decision for Verawood on approach to auto migration

  • Need to support library import/export for Ulmo in order to maintain parity with V1 and support migrations

 

May 30, 2025

  • Will we need to support granular permissions within a library, e.g. different groups of people having write access to different parts of the library?

    • Most likely yes, will write up more about this soon.

  • Dates are preserved on course import into library.

    • Do we need to inherit down?

  • Kyle: Why the difference between the things you can edit vs. you can’t in libraries based on whether it’s imported or created in the library?

    • Marco: Preserving everything on import is the most important thing. Have a place to show these settings is secondary. Figuring out what we allow people to be able to set in libraries is tertiary.

    • Decision: Preserve all container fields to start, everything is read-only to start, editable later.

  • Decision: When importing from a course into a library, we do not have to link it, i.e. the newly created subsection in the library does not become an upstream of the course subsection.

  • Decision: Libraries will not support split test xblock

May 28, 2025:

Subsections/Section settings requirements [LINK to updated PRD - coming soon]

We need to apply an “MVP + phased roll out” approach to tackling subsection and section settings requirements. This is driven by the hypothesis (to be tested in May/June) that there are two categories of subsection/section reuse, each with nuanced setting/configuration needs:

1) Reusing subsections/sections already in existence from courses, and

2) creating new subsections/sections from scratch in a library for reuse later.

We will develop an Ulmo MVP for settings around the former, and address the latter in Verawood.

Ulmo settings requirements:

  • When a course is imported into a Library, the course-level settings on subsections and sections will carry over in the Library. They will be read-able but not edit-able in the Library. If that subsection/section is reused in another course, the settings can be overwritten locally in the new course. All settings need to be preserved on the backend.

  • When a subsection/section is created in a Library, the settings will not be settable. When those subsections/sections are reused, the settings can be overridden locally.

    • The following settings will not be viewable at all in libraries because they don’t make sense (but still :

      • Change due date

  • In future releases, we will expand settings in libraries so that they can be edited in Libraries.

References: https://docs.google.com/document/d/1ZxxetJgMXn-aa0ybFDEbm1tE623Nr6TXwk3XTBfgsTo/edit?tab=t.0

copy-pasted from the concept decision log doc, Dave to clean up later:

May 23, 2025

  • Discussion: Generalized idea of “publishing dependencies” as a broader way to describe the kind of publishing relationship between containers and their children (to better support courses later).

    • Decision: Yes, this language is fine, but it’s probably not going to be exposed to the user except through documentation.