[BD-14] Sync 2020-10-02
Demo of latest features
MFE
Library license configuration
User access configuration
Video-type libraries
Problem-type libraries
Filtering and pagination in the library list
Studio and LMS
Adding library content to a course
What happens when you update a library?
Notes
License + access configuration
Library listing page:
No API currently to paginate (V1 union V2) libraries.
So, you cannot list “All” libraries currently - only one type at a time
This is a result of V1 and V2 libraries being stored differently.
One possible listing would be “V2 only”, though.
Kyle: Could V1 libraries be added to the ES index? Would that solve it?
(is this worth doing, though? we’ll want to DEPR V1 libs as soon as we can)
Dave: It’s actually better to keep them separate. +1 Nimisha
Nimisha: Could be confusing if V2-only is all of a sudden the default listing, as some folks expect to see their V1 libraries there. Keep this in mind during rollout.
Nimisha: Using a multi-select or some other experience might be better than drop-down.
Dave: Need to make sure this page works with huge # of libraries (for example, some MIT admins are given access to thousand(s) of libraries).
@Former user (Deleted) will test this
Dave: We need to be able to support being able to manage 1000 libraries, but that doesn’t mean we need to be able to display 1000+ libs at once. A “you need to filter it down” experience could be fine.
Adolfo: The backend should be in a good place to handle this.
Library block editor:
HTML is one of those blocks that doesn’t work in the MFE
Video editor doesn’t work either.
But the blocks render fine through the library sourced block in the LMS.
Drag and Drop block does work.
Kyle: Is there a clear distinction between blocks that do and don’t work in the MFE author_view iframe?
It’s blocks that make assumptions about the page they are being rendered in. This is especially true of the
author/studio_viewof blocks built into edx-platform.
(We’ll talk about this after the demo)
Library sourced content
New tentative UI – feedback expected, mockup would help
Key difference:
V2 libraries require an explicit publishing step, whereas V1 libraries are automatically updated
Library block updating / falling out-of-date with library.
@Former user (Deleted) will explore this.
Dave: Hammering down what the edit/publish/update flow should look like is really important.
With V2 (blockstore) libraries, we can have more sanely versioned libraries (v1,v2,…)
Should we surface versioning to users?
@Kyle McCormick add to the agenda for meeting next week and create a discovery ticket to track these discussions.
@Dave Ormsbee can write up an doc/page/something to set the stage for this conversation.
Marco: as a high-level comment, lots of stuff to iterate on UX-wise in M3, but overall, nothing jumping out as too concerning.
Marco: Both library detail view and component editing pages have “Publish” button. Would be good to make it clear to the user what exactly those publish.
Adolfo: That’s a result of Ramshackle inheritance. Currently working on new library editor that is more Studio-esque. Publishing button will only be in one place.
Nimisha: Static asset UI?
Adolfo: Is temporary. Current view is “operator” view, will be smoothed out.
Block editor modernization
Braden’s latest comment: https://github.com/edx/edx-platform/pull/25125#issuecomment-702421440
“It's not just these two blocks unfortuntely; there are a number of (first and third party) XBlocks that make assumptions about the surrounding frontend runtime environment of the
studio_view. The "API" for how XBlocks render and usestudio_viewhas always been very fuzzy, and I'm pretty sure I've seen XBlocks rely on functionality like tabs in the studio edit dialog that depend on Studio's existing JS+CSS.”
Do we forsee a situation where many blocks' editors will simply not work in the MFE without modernization?
If so, do we need to rethink the Library Authoring MFE component editor?
(Adolfo replies prior to the meeting:) We can conduct a survey of which ones work, and which don’t. Just keep in mind that feature-parity-wise, legacy libraries to this day do not support advanced block types (while v2 will work with most), so the list of blocks to test is not as long as one would think.
Takeaway:
@Former user (Deleted) will survey the # of “bad blocks” that we want to support (where “bad block” => block with a studio_view that is too coupled to legacy studio, and thus would either need modernization or shimming).
Will help us decide between 2 options:
Rewrite studio_view of each bad block. Sub-options:
nano-frontend-views for each bad block in edx-platform
nano-frontend-views for each bad block in studio-frontend
extract bad blocks from edx-platform – probably out of scope of this project.
Support all bad blocks at once with a shim. Sub-options:
Write compatibility wrapper into frontend-app-library-authoring, mimicking the JS/CSS dependencies of Studio.
In edx-platform, write a “chromeless-xblock studio-view”, mimicking the chromeless-xblock student view that frontend-app-learning relies upon.
UX feedback timeline
Marco will be making lo-fi collateral for this project.
Marco: Will be working on this and reviewing it next week.
Core views should exist by early next week, may not be reviewed yet
Updating existing lo-fi figma file: https://www.figma.com/file/M8KdImlxlTdAuDIBP7igxT/Content-Library-Editing-Low-Fi?node-id=0%3A1
Hi-fi stuff coming in within next 2-3 weeks.
@Marco Morales (Deactivated) - Can you speak to when the team will be able to see mocks?
How does that timeline affect the project?
500s on Stage
Milestone 3 planning
M3 was originally the beginning of Taxonomies, Tagging.
We identified last time that we should instead focus on bringing M2 results to parity with V1 libraries. Does that still sound good?
Can we identify a high-level objective for this milestone?
Import/export is part of this milestone
This is blocked by publishing/updating/versioning questions