Use Advanced Components (XBlocks) in Libraries

[jmakowski1123]

"As a Library Author, I expect to have the exact same experience when creating and editing advanced components in Libraries as I do in Courses."

Libraries utilize the same advanced components as courses.

In particular, the following need to work:

• Drag and Drop V2 (note: it has its own button in the "Add" section, but is otherwise similar to other advanced components)
• LTI Consumer
• Open Response (ORA2)
• poll
• other 3rd party XBlocks

The Advanced component can be accessed from the following places in the UI:

• When I click the "new button" and the "add content sidebar" opens and I click on "Advanced", then the Advanced component list pops up and I can choose an advanced component type to create.

  • TBD: Which advanced components do we show? This is blocked on design work happening in courses to simplify the configuration of advanced components.

• In the component card, when I click on the 3-dot menu and then when I click on "edit" in the 3 dot menu, then the editor for that component pops up, and I can make edits or adjustments to that component.

  • Example editor: the ORA2 modal editor:
  • Note that some work has already been done by Raccoon Gang on embedding these legacy modals into the course authoring MFE.

• In the header of the component sidebar, when I click on the "edit" button, then the editor for that component pops up, and I can make edits or adjustments to that component

[jmakowski1123]

@bradenmacdonald Thinking through the configuration implications of this story - do we actually need a separate story for authors to configure which advanced problem types they want to use, in the same way they need to configure them for courses? I don't love the idea of making authors go through a json-string workflow for adding advanced modules to a library... This new project is kicking off now which will create a visual configuration experience for authors to choose which advanced blocks they want in a course, and will launch with a pre-determined set of auto-on advanced problem blocks as well.

I'm working through whether it makes sense to hold off on implementing this story in libraries until that first milestone is implemented in courses, and we can do design and implementation for libraries at the same time. I'd classify advanced problem types in libraries as a nice to have but maybe not necessary for an MVP launch. I suppose it partially depends on how complicated it would be to implement the configuration workflow, and whether it makes sense to do that given the other visual configuration project coming down the pipeline...

[bradenmacdonald]

@jmakowski1123 Assuming you mean "advanced components":

and not "Advanced Problem Types" (which are not configurable):

Then yeah, I totally agree on holding off until we've got the UI figured out for courses. That will also help on the editor side, because it's going to be harder to support the editors of all the third party (advanced) XBlocks, which are completely different than the built-in problem/text/video/ora2 editors.

[jmakowski1123]

Yes, I do mean the Advanced block. Agreed then, I'll move this to no status until post-MVP.

[jmakowski1123]

@bradenmacdonald Would you classify ORA under here as well, or should ORA have it's own story? Likewise, will ORA be as complicated to implement for the MVP as the Advanced block?

[bradenmacdonald]

@jmakowski1123 I asked on Slack to make sure, but as far as I can tell, the ORA settings/configuration interface is a legacy modal and would be most similar to other XBlocks under the "Advanced component" category. So it would be in this story too. We should definitely call it out as a specific case that needs to be supported.

[bradenmacdonald]

@jmakowski1123 I think ORA is actually the most complicated Advanced block to implement; so if we can get ORA working then I'm pretty confident any others will work too.