Modern user interfaces for all users If this initiative is successful, 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.
|
The Wikimedia Design System Team is developingCodex, a Vue.js-based library that will enable developers to more efficiently and effectively build consistent, accessible and interactive user interfaces (UI). 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.
This is background information for the "Modern user interfaces for all users"Technical Decision Making Process (TDMP), seeT317270.
The reasonCodex components are currently only available in modern browsers is that they're implemented as client-side-only JavaScript, meaning the code that renders them executes in the user's browser. That will only happen if the user's browser supports a modern enough version of JavaScript and if the user hasn't disabled JavaScript (or doesn't receive the JavaScript experience forsome other reason). And it won't start happening until the JavaScript code has been downloaded, which could take a while on a slow connection.
If we want users of older browsers to be able to view and interact with user interfaces built with Codex, we need to render (a version of) the user interface on the server, so that the UI is already part of the HTML that the user's browser receives. This also helps users of modern browsers see (an initial and non-interactive version of) the UI faster, because they don't have to wait for the JavaScript code to be downloaded and executed. There are inherent limitations to how feature-rich and interactive a UI can be without JavaScript (or before JavaScript arrives), but in many cases a basic experience can be provided.
Below are some approaches we have considered to the server rendering issue. These aren't meant to be universal approaches that we would use in every case: in practice, we'd likely use different approaches for different use cases.
The simplest solution to this problem is to decide that we don't want to solve it at all. A user interface could be implemented entirely client-side, in JavaScript that runs on the client, and nothing would need to be rendered on the server. Users of older browsers would see an error message saying they can't use the feature. Users of modern browsers would be able to use the feature, but would initially see a "Please wait" message or some other placeholder before the UI loads.
Some user interfaces may not need any interactivity, or can implement the limited interactivity they need in HTML and CSS. In this case, the UI can be rendered entirely on the server, no JavaScript is required, and the browser support and performance issues are moot. Most basic UIs in MediaWiki already work this way.
Codex does not currently support rendering components in PHP, and many components do require JavaScript-based interactivity. However, HTML+CSS-only implementations could be written for a subset of Codex components to support server-side-only interfaces.
In this approach, the UI is rendered on the server. This UI looks (mostly) like the full UI, but is not interactive. When (and if) JavaScript loads, it enhances the UI by adding interactivity, but doesn't change how the UI looks (or makes only minor changes).
This is how the web worked in the jQuery era, but modern web applications tend to be more complex, and modern web frameworks and libraries tend not to support this method. This method is most suitable for providing smaller amounts of interactivity in simpler UIs.
This is similar to the progressive enhancement approach in that the UI is initially rendered on the server. But instead of enhancing the existing UI, the JavaScript code destroys the server-rendered UI and replaces it with a client-side only UI that looks the same.
This approach essentially combines the server-only and client-only approaches, getting the best and worst of both. The UI is implemented twice, in different languages, and these implementations must be kept in sync for the transition from the server-rendered UI to the client-rendered UI to work correctly, otherwise visible jumps can occur or state information can fail to be preserved.
Vue.js is a JavaScript-based UI framework that's primarily designed for client-side use, but it also supports rendering UIs on the server, through a feature it callsserver-side rendering (SSR). Similarly to the "separate server and client implementation" approach, the client-side JavaScript takes over once it arrives and makes the UI interactive ("hydrates" it). But crucially, the server and client execute the same code, so no duplication is required.
Project phases come from WMF'sInclusive Product Development playbook.
| Phase | What? | How? | Target Start | Target Completion | Status |
|---|---|---|---|---|---|
| Strategize | Articulate “why” and “for whom?” Assess team's capabilities to deliver. Surface dependencies and risks. Establish community engagement strategy. | Technical Decision Forum:T317270 | September 2022 | March 2023 |  In progress |
| Discover | Better understand the needs and goals of target audience | Technical Decision Forum:T317270 | September 2022 | March 2023 | In progress |
TODO: Community engagement plan | |||||
| Define | Turn research, insights, etc. into an addressable and achievable scope of work with a concise problem statement. | Decide which server rendering methods to use in which casesT322163 | November 2022 | TBD | In progress |
| Prototype a Vue SSR implementation using V8jsT286966 | TBD | TBD | Upcoming | ||
| Develop | Design and development of solutions and experiments from the DEFINE phase, in preparation for the DELIVER phase. | TBD | TBD | TBD |  Blocked |
| Deliver | Deliver and test final code and/or interface. This could be either for delivering a smaller scaled test or final scaled experience to production. | TBD | TBD | TBD | Blocked |
| Own | Monitor and refine based on positive and negative impacts resulting from the product/code delivered. | TBD | TBD | TBD | Blocked |
We welcome and encourage your participation in this initiative. Here are some ways to engage: