[Spec Memo] Convert Legacy edX Studio UI to MFE
Studio Overhaul Approach Memo (TBD Brad Brown)
The Most Important Thing
In Q3, the 2U>Teaching & Learning squad (T&L) will collaborate with a RaccoonGang dev team to recreate 13 of the remaining 19 edX Studio pages inside of the existing course-authoring MFE. T&L believes this investment is the appropriate first “small batch delivery” of the Studio Overhaul initiative (which is focused on these 13 pages and is already in the “UX research” phase).
This project will involve three teams: RaccoonGang-DevTeam, T&L, 2U>UX.
RaccoonGang-DevTeam will have a full development team which will build the bulk of the pages.
T&L will have one developer (Kristin Aoki) dedicated to this project in two capacities. First, as the RaccoonGang PR reviewer. Second, as an individual contributor building a subset of the pages.
UX will produce hi-fi mockups for complex pages, and provide UI review for all simple pages.
Join the #proj-studio-mfe Slack channel to follow along with the progress!
Design Highlights
This project aims to deliver feature parity in the new react-based pages, making adjustments only when a clear opportunity for optimization or deprecation appears. There are a few design choices that have already been made:
All 13 pages will be added inside of the course-authoring MFE, which already contains four Studio pages. This was chosen because T&L does not currently believe there is a need for a more granular Studio MFE architecture, and course-authoring is ready-to-go.
End-user page performance should remain the same. Our assumption is that this will be obtainable without needing to modify any existing backend APIs. More detail about performance expectations can be found in the Measurements section.
UX will accept small UI/UX changes between legacy to MFE if it means using an existing Paragon component instead of building something custom to match legacy.
An example of this currently being discussed is the vertical progress stepper on the Import+Export pages. It would be ideal to leverage the Paragon Stepper component, but there currently does not exist a vertical version. This project may make tweaks to the experience to be able to leverage this component, or extend the component if UX feels it is warranted.
Dropped Items
This project will not include the following six Studio pages because they are not in scope for the Studio Overhaul initiative and T&L Product is trying to keep both the budget and timeline of this effort to a minimum.
Course Group Configurations Page
Course Checklists Page
Course Certificates Page
Course Textbooks Page
Accessibility Policy Page
Studio Error Page
High Level Design
The goal of this project is parity with the legacy Studio UI experience. To achieve that, we will leverage as much as possible from already existing pages and Paragon. Below is where each page section will live (caveat: there may potentially be some components built inside of frontend-lib-content-components if deemed necessary)
There will be course waffleflags created which will control the availability of each individual MFE page. While T&L does not plan to launch pages individually or roll out to individual courses or organizations, these flags will enable a detailed beta test and allow us to have a higher range of control post-rollout if needed. These course waffleflags will be OFF by default for all non edx.org instances of Open edX.
This project must also strive to provide support for the “existing user bookmarks and documentation references” use case in our final solution (Discovery).
Where necessary, there will be APIs built to support legacy actions that are not API-driven. RaccoonGang will investigate in detail as soon as the project kicks off. However, we assume that three pages will be required to build new APIs: Course content outline page, Course units page, Schedule & Details page. These pages will most likely require new endpoints to get initial data to display on the page during first load.
Risks
T&L believes that a fragmented Studio UI will be accepted by our users for a decent length of time. Studio already has four pages that live in the MFE (Text+Video+Problem Editors, Course Pages & Resources page), extending this to more will hopefully receive the same general level of acceptance. If beta tester feedback shows this to be untrue, additional effort will be needed which would make the project ~25% more expensive and possibly extend into Q4.
High Level Work Plan
T&L has pre-classified the pages into either a Simple or Complex bucket based on the complexity of the UI elements on each page.
Simple pages should not require mocks, so build out will begin immediately. UX will provide T&L and RaccoonGang-DevTeam the Course Advanced Settings and Schedule & Details page mockups (Figma link) as a guide. A post-build demo of each page will be held, then UX will review the UI and provide feedback as needed. T&L has seen speed-to-market gains with this approach for Studio Editors already.
Simple pages include:
(T&L) Course Custom Pages Page
(RG) Course advanced settings page
(RG) Course Schedule & Details page
(RG) Course grading page
(RG) Course updates page
(RG) Course Import page
(RG) Course Export page
(RG) Course Team page
For Complex pages, UX will build high-fidelity 1:1 mocks to ensure all teams have a clear picture of the desired endstate. RaccoonGang will move the buildout of these pages to the end of the schedule to allow for more UX time to generate these mocks.
Complex pages include:
(T&L) Course Video Uploads Page
(T&L) Course Files & Uploads Page
The page will see an overhaul inside of this project scope
Likely deprecate studio-frontend (Discovery)
(RG) Studio Home Page
(RG) Course content outline page
(RG) Course unit pages (react-based xblock rendering is out of scope)
Note: There is one exception to the approach described above. The Spanish Consortium has decided to work with EduNext to overhaul the Studio Home Page in H2 2023, so this project will deliver the new Studio Home Page to EduNext as early as possible.
Proposed Schedule
Rollout Strategy
The rollout of all new Studio pages will be atomic in nature (aka flipping the waffleflags for all users), which is T&L standard rollout procedure. The rollout date will be clearly communicated with content authors through our standard set of communication channels.
Prior to rollout, T&L will use page-specific waffleflags to run an extended beta test period where pages are added incrementally to the beta test group and collect fast feedback throughout the project timeline (see orange bars in Proposed Schedule). T&L has a set of beta testers that were used for the Problem Editor release which will be re-used for this project. T&L Product Manager Brad Brown will communicate to the group once each new page is deployed.
Measurements
Pertinent Studio Page metrics, e.g. “How many users visited Studio pages today? Where are they located? How long was their session?”
Note: The course-authoring MFE does not currently have traffic data feed into 2U>Google Analytics. This must be corrected in order to observe long range before-and-after comparisons of Studio traffic. |
The most pertinent performance metric is likely User-centric page load times from 2U>New Relic. Our goal will be to maintain a consistent experience to the current legacy Studio baseline:
Risk Measurements
Qualitative user feedback obtained via beta testing, interviews, and surveys. If our power users are unhappy with the experience, T&L may delay or partially roll out these changes.
Community Considerations
This work will be done in openedx repos, and the MFE itself is already a part of the Open edX release. T&L expects these pages will begin to be adopted by community members starting with the Quince release. T&L will need to update both developer and user documentation as part of this project.
This project will also see the openedx\frontend-app-course-authoring repo become officially maintained by T&L.
Unanswered questions
[Operationalization concern] T&L currently struggles with MFE version management. How can we improve life related to this struggle within this project?
Is there anything this project can do to help with ensuring consistent styling/theme representation across all different environment levels? (e.g. openedx vs edx themes, devstack vs prod)
Alternatives, discarded version
The Studio Overhaul initiative could be achieved with two alternative approaches:
The initiative could include the MFE-ing of all pages at the time of overhaul. T&L believes this approach would dramatically increase the timeline and overall project complexity.
The initiative could be delivered in the legacy Studio UI. T&L believes this approach would balloon the implementation phase as legacy development has massively long feedback loops. This approach would also not progress the overall platform toward its architectural vision.