• (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:

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

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