MFE Theme-ability Completion

[e0d]

Work to support MFE theming and unify theming in Open edX. (openedx/wg-coordination#42)

See:

https://discuss.openedx.org/t/open-edx-branding-and-theming-improvements/4747
https://gitlab.com/opencraft/dev/branding-and-theming/-/merge_requests/1

[Source: OEROADMAP-13]

Opportunity Objective
As the Open edX platform’s UI has evolved over the years using various different UI frameworks, it has accumulated a lot of inconsistency and technical debt. In particular, thorough theming of Open edX can be difficult (override “v1” and “v2” stylesheets, individual django templates, email templates, and now MFE appearances).

With the shift to react-based “MicroFrontEnds” (MFEs) for the user interface (and consistently using Bootstrap/Paragon), we have an opportunity to make branding/theming significantly easier, more consistent, and more capable.

Market Evidence
Open edX hosting providers like OpenCraft are very aware of the need for better theming tools, given consistent client requests for it, and their experience in developing themes for clients with the existing (inadequate) tools. Some Open edX operators have chosen to heavily customize their UI and then find that they are “locked in” to an old (and insecure/unsupported) version of edX, because upgrading their customized UI is difficult.

Proposal Specifics

• The entire learner-facing UI will be converted to React-based MicroFrontEnds.
• Every MFE will support “branding” and “configuration” as defined at Theming Microfrontends
• Where useful and feasible, MFEs will also support “customization” and “frontend plugins” as defined in that same document.

Open edX devstacks will come with two themes, “dark” and “edX”; the dark theme will be the default for Open edX in order to clearly show where theming is working correctly or not (seeing light colors on devstack or dark colors on edx.org prod means it’s not working).

Operators who wish to heavily customize the UI will be encouraged to create their own MFEs, and will be able to count on REST API stability during upgrades.

Allow operators to change the theme quickly

A standard, automated workflow allows rebuilding any MFE with an updated theme configuration and deploying it [to S3+CloudFront] in under one minute.

To allow a trial and error workflow for live editing of themes by users (see WYSIWYG Theming editors below), the changes should be viewable (or at least previewable) within a few seconds - quickly enough to allow to have a proper iterative editing workflow of themes from the web/WYSIWYG interface (edit -> see result -> edit -> etc.). It doesn't need to be instantaneous, but the compilation/application shouldn't take longer than it would be comfortable to a developer editing CSS.

Move the providers’ theming WYSIWYG editors upstream

Reuse existing code from hosting providers if useful - e.g. OpenCraft's Instance Manager Ocim (and/or other providers who want to participate? Eg Appsembler's Tahoe, eduNext's Management Console, etc.)

Theming WYSIWYG from these projects moves to become an official Open edX service/MFE, where people contribute to theming functionality and WYSIWYG editing together. Instead of isolated duplicate efforts, theming improvement and maintenance efforts (which can be huge!) can be mutualized into a shared community effort.

The theming editor allows configuration from "within edX", i.e. closer to the way Wordpress allows theming settings from its admin interface. It allows simple theming operations (changing the “branding” and “configuration”), without requiring DevOps intervention/knowledge, or local proprietary modifications to deployment systems

Success Measures
If this proposal is successful, the entire learner-facing UI will be converted to MFEs, the delineation between Open edX branding and edX branding will be very clear, and operators will be able to easily brand and customize their instances of Open edX.

[jmakowski1123]

Closing in favor of tracking #144