What is it?

The Design Systems Team is developing Codex, a Vue.js-based library that will enable developers to more efficiently and effectively build consistent, accessible and interactive user interfaces. However, Codex components are currently only available when modern JavaScript is available and once JavaScript has loaded, which would exclude users of older browsers. We would like to find a way to make user interfaces built with Codex work for these users as well.

End-User Impact

( ) All Wikimedia users will benefit from modern user interfaces using the new design system, even if they use an older browser, use a mobile device, have a slow connection, or have JavaScript disabled.
( ) Without a server-renderable solution, the skin has to recreate the JS only components, leading to duplication of effort and inconsistencies. Building experiences that are accessible to the most number of people support the organizational goals of knowledge equity and inclusivity.
(-) Negative impact

Engineering Impact

( ) Positive impact
(-) Negative impact

Design Impact

( ) Positive impact
(-) Negative impact

Other Impact

What does it block?

[add teams, products, projects, features, etc that will remain blocked if we take no action]

• If we take no action:
  • User interfaces developed with the new design system load slowly on slow connections or slow devices, and don't load at all in older browsers or when the user has JavaScript disabled
  • Developers building user interfaces that need to support these users could decide not to use Codex, which would result in a less consistent design and worse accessibility
  • Alternatively, developers could decide to build a user interface twice, once in Codex for users of modern browsers, and once without Codex for other users. Developers would have to write and maintain twice as much code, and users could experience inconsistencies and bugs.

What does done look like?

For this discovery phase, "done" means we have made enough decisions to either move forward with a defined first phase of delivery, or adjust/abandon the initiative. Likely artifacts include:

• Prototypes T286966
• Architectural decision records (ADRs)
• Outputs from Technical Decision Forum T317270
• Documented risks & open questions
• Delivery epic(s)

Phases of Work and Owners / Timeline

• Owner: @Catrope
• Phases/timeline: https://www.mediawiki.org/wiki/Design_Systems_Team/Projects/Modern_user_interfaces_for_all_users#Timeline

Cross-Team Dependencies

• Design Systems Team - leading the project
• SRE service ops - If the solution involves a Node.js service for Vue SSR, SRE service ops will have to manage the deployment and operation of this service.
• Core Platform / MW value stream - The solution will likely involve adding at least some infrastructure to MW core, which this team maintains.
• Security team - If the solution involves a Node.js service that executes JavaScript code it is given, and/or that processes private data, the Security team will have to evaluate and approve how that is handled.
• Performance team?

Existing Artifacts

• Project page: https://www.mediawiki.org/wiki/Design_Systems_Team/Projects/Modern_user_interfaces_for_all_users

Open Questions

• It's not clear what will make a solution "good enough" when evaluated; modern JS support is mentioned, and FOUC is referenced (but not by name) in passing, but are there other inputs like server load, page weight, etc.? Is the idea that these will be established in the working group, or is there some specific target for which the team are aiming?
• When we run into this specific server-side rendering problem with Vue.js, isn't it better to look for another solution that solved this problem already?
• To what extent performance overhead (in terms of bandwidth usage or latency) as a result of UI being part of the HTML which the user browser receives is significant or negligible?