Change Details

= What? **In one sentence, what is the problem or opportunity?** 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. **What does the future look like if this is achieved? ** 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. **What happens if we do nothing?** - 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. = Why? **Identify the value(s) this problem/opportunity provides. Add links to relevant OKRs. ** //Rank values in order of importance and be explicit about who this benefits and where the value is.// **User Value/Organization Value AND Objective it supports and How** # Knowledge Equity - Ensuring users who don't have the ability to run JavaScript get an equitable experience # [[https://www.mediawiki.org/wiki/Wikimedia_Engineering_Architecture_Principles#Principles|Architectural principle]] EQUITY/DEVICE - Making key functionality available on older devices/browsers - Improving the loading experience for users on slower connections # Design Systems Team Objective 2: All front-end contributors can rapidly build consistent UIs - Helps with key result C (90% of teams can leverage the Design System to build new features) by removing a barrier to Codex adoption **Why are you bringing this decision to the Technical Forum?** //What about the scope of this problem led you and your team to seek input across departments/organizations?// - Every team that develops front-end features is affected by this issue, and for many of them it's a barrier to using Codex - Overarching guidance for when and how to use server rendering affects all front-end product teams, and also requires input from e.g. the Performance team - The implementation of one potential approach (Vue SSR) would likely involve deploying a Node.js service, which would affect how MediaWiki is deployed at WMF and how third-party users install MediaWiki = Background This is a problem statement, so it only talks about the problem, not about possible solutions. However, the problem statement is somewhat abstract, so to understand it better some people may find it helpful to read [[https://www.mediawiki.org/wiki/Design_Systems_Team/Server_rendering_background_info|this page with background information]], which talks about what the solutions to this problem could look like at a high level.

= What? **In one sentence, what is the problem or opportunity?** 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. **What does the future look like if this is achieved? ** 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. **What happens if we do nothing?** - 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. = Why? **Identify the value(s) this problem/opportunity provides. Add links to relevant OKRs. ** //Rank values in order of importance and be explicit about who this benefits and where the value is.// **User Value/Organization Value AND Objective it supports and How** # Knowledge Equity - Ensuring users who don't have the ability to run JavaScript get an equitable experience # [[https://www.mediawiki.org/wiki/Wikimedia_Engineering_Architecture_Principles#Principles|Architectural principle]] EQUITY/DEVICE - Making key functionality available on older devices/browsers - Improving the loading experience for users on slower connections # Design Systems Team Objective 2: All front-end contributors can rapidly build consistent UIs - Helps with key result C (90% of teams can leverage the Design System to build new features) by removing a barrier to Codex adoption **Why are you bringing this decision to the Technical Forum?** //What about the scope of this problem led you and your team to seek input across departments/organizations?// - Every team that develops front-end features is affected by this issue, and for many of them it's a barrier to using Codex - Overarching guidance for when and how to use server rendering affects all front-end product teams, and also requires input from e.g. the Performance team - The implementation of one potential approach (Vue SSR) would likely involve deploying a Node.js service, which would affect how MediaWiki is deployed at WMF and how third-party users install MediaWiki = Background This is a problem statement, so it only talks about the problem, not about possible solutions. However, the problem statement is somewhat abstract, so to understand it better some people may find it helpful to read [[https://www.mediawiki.org/wiki/Design_Systems_Team/Server_rendering_background_info|this page with background information]], which talks about what the solutions to this problem could look like at a high level. For more background on why users may receive the non-JavaScript version of the site, see https://www.mediawiki.org/wiki/No-JavaScript_notes

= What? **In one sentence, what is the problem or opportunity?** 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. **What does the future look like if this is achieved? ** 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. **What happens if we do nothing?** - 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. = Why? **Identify the value(s) this problem/opportunity provides. Add links to relevant OKRs. ** //Rank values in order of importance and be explicit about who this benefits and where the value is.// **User Value/Organization Value AND Objective it supports and How** # Knowledge Equity - Ensuring users who don't have the ability to run JavaScript get an equitable experience # [[https://www.mediawiki.org/wiki/Wikimedia_Engineering_Architecture_Principles#Principles|Architectural principle]] EQUITY/DEVICE - Making key functionality available on older devices/browsers - Improving the loading experience for users on slower connections # Design Systems Team Objective 2: All front-end contributors can rapidly build consistent UIs - Helps with key result C (90% of teams can leverage the Design System to build new features) by removing a barrier to Codex adoption **Why are you bringing this decision to the Technical Forum?** //What about the scope of this problem led you and your team to seek input across departments/organizations?// - Every team that develops front-end features is affected by this issue, and for many of them it's a barrier to using Codex - Overarching guidance for when and how to use server rendering affects all front-end product teams, and also requires input from e.g. the Performance team - The implementation of one potential approach (Vue SSR) would likely involve deploying a Node.js service, which would affect how MediaWiki is deployed at WMF and how third-party users install MediaWiki = Background This is a problem statement, so it only talks about the problem, not about possible solutions. However, the problem statement is somewhat abstract, so to understand it better some people may find it helpful to read [[https://www.mediawiki.org/wiki/Design_Systems_Team/Server_rendering_background_info|this page with background information]], which talks about what the solutions to this problem could look like at a high level. For more background on why users may receive the non-JavaScript version of the site, see https://www.mediawiki.org/wiki/No-JavaScript_notes