Design System Team/OKRs/FY23-24/WE3.1
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. |
The Design System team continues to focus principally on WMF and WMDE developers & designers. The strategy remains one of voluntary adoption. We are not forcing teams to start using Vue & Codex; we want them to see the benefits and choose to use it over legacy technologies. Wherever possible, we are also trying to have contributions to the library come from collaborating teams. The model we are striving for is one of federated governance and self-service usage.
Long term, we expect to decrease the fragmentation of front-end frameworks and technologies by eventually having everything built using Codex. This doesn’t necessarily mean everything is built in Vue.js. It could mean that a certain user script uses our design tokens, or that a basic interface uses our CSS styles. The key is that designers and developers are using the well designed, tested, accessible, and consistently maintained components, guidelines, and best practices. This will lead to eventual consistency of visual design across the projects and a better experience for all Wikimedia users.
Our near term goal is to see all net-new front-end web features built using Codex, including migrating existing experiences away from legacy technologies (Backbone.js, OOUI, mediawiki.ui, Wikit) when it makes sense to do so. We know that achieving 100% on this metric is unlikely in this fiscal year; there are a number of teams or product areas where Codex adoption is not yet possible even if the feature team wants to use it. However, this is the case for only a smaller portion of the overall places where Codex can be used and have an effective impact.
We plan to measure our success this year in two ways, contributing directly to the Product & Technology OKR WE3.1:
- 75% of WMF and WMDE teams building user interfaces have used Codex in a project at least once.
- When surveyed, 100% of designers and developers who have used Codex do not wish to go back to using legacy tools and ways of working.
We believe we can increase Codex adoption in the following ways:
- Expanding the library of tokens, components, and patterns.
- Extending Codex’s capabilities as a design system (e.g. support for responsiveness, theming, …)
- Creating better documentation, examples, and integrating existing resources (like the design style guide) into Codex.
- Migrating existing code bases to leverage key standardization tools (e.g. tokens).
- Advocating for design systems and our system in public forums like department meetings, blog posts, and at Wikimedia events.
- Providing workshops, design review, code review, office hours, and other channels to help others learn about Codex, associated tools, and guidelines/best practices.
- Eliminating the technical barriers to adoption by certain teams or in certain Wikimedia product areas (e.g. performance concerns by the Web team, reliance on OOUI for Visual Editor by the Editing team, …).