Designing Openly for Everyone: Meet Codex!  ## Metadata - Author: [[YouTube]] - Full Title: Designing Openly for Everyone: Meet Codex! - Category: #articles - Summary: Bárbara Martínez, Senior Designer at Wikimedia Foundation, talks about Codex, the Design System used at Wikipedia and all Wikimedia products. Through several examples, during her Keynote at Penpot Fest, Bárbara shares how designing openly might take more effort, but ultimately leads to stronger and more sustainable and inclusive design systems. *Penpot Fest 2025 | Better, together: Refining the designer-developer workflow.* -- Penpot is the free open-source design tool for Design & Code collaboration. https://design.penpot.app​​ Penpot is ideal for product design: UI designs, prototypes, wireframes, mockups, webs, apps, and much more. Penpot allows a true collaboration and no handoff drama between designers and developers thanks to features like CSS Grid Layout, Flex Layout and Code Inspect. Designers get a professional, intuitive, powerful design tool with ground-breaking responsive layouts, design systems at scale. While developers get a design tool that expresses as code and provides ready-to-use code to develop faster. Penpot is the only one that can be web-based or self-hosted. The app works with open standards (SVG and CSS) avoiding vendor lock-in. Also, it enables teams the flexibility and control in their designs, thanks to the API and webhooks available. Penpot Community: https://community.penpot.app App: https://design.penpot.app​​ Help: https://help.penpot.app​ Contribute: https://github.com/penpot Penpot Fest: https://penpotfest.org Follow us: *Mastodon: https://fosstodon.org/@penpot/​ *Bluesky: https://bsky.app/profile/penpot.app *X: https://x.com/penpotapp *LinkedIn: https://www.linkedin.com/company/penpotdesign *Instagram: https://www.instagram.com/penpot.app/ *Github: https://github.com/penpot Penpot: Design as code. - URL: https://www.youtube.com/watch?v=oNuj40dElaI Yeah, thank you. So welcome to Designing Openly for Everyone: Meet Codex. Yeah, as Medet said, I'm Bárbara Martínez. I'm Senior UX Designer at the Wikimedia Foundation. And during the last few years, I have been collaborating in the creation of Codex, the design system of Wikimedia, not the one from OpenAI that is the same name. And yeah, some of you know what is Codex or have been playing with Codex in some way, in some moment. Maybe not, or maybe yes. Because if you have ever clicked, edit, read, or do anything in Wikipedia, you probably have been playing with Codex because Codex is the design system that we use for Wikipedia and any Wikimedia project in some way. And yeah, when I first joined the Wikimedia Foundation, what amazed me most was not the scale of the project that is over a billion of users. What most amazed me was how open everything was. Because anyone could see our work, contribute, and improve it. And when I started working in Codex, I realized that Codex is not only the design system, it's a living conversation with people from everywhere and in all the world. Designing for Wikimedia means designing for everyone. And this is not always easy, it's complex, but it's really meaningful. We build with the community, not just for it. This is super important in our projects. This means that we collaborate with a thousand volunteers that contribute to Wikipedia or any other Wikimedia project. And designing not just with my team, but with people from all over the world is really exciting and motivating. And what is Codex? Codex is more than a UI library, it's a collection of guidelines, standards, and reusable elements that help our teams and also people outside the Foundation to create new features. Wikimedia serves over a billion of users, this means that we work for users for different languages, different devices, different abilities, different contexts, and different cultures. And Codex helps us respond to this complexity, but by a system that supports consistency, accessibility, and scalability. Codex came from after more than 20 years of Wikimedia projects, and over all these years, teams and volunteers were creating different features, different tools, and different things in many different ways. So Codex was born to unify all these previous things, but always without losing the origins, because it's important that we communicate always the essence of Wikimedia and Wikipedia. And what makes Codex truly unique is that it's built through open collaborations. Contributors from Wikimedia Foundations, Wikimedia Deutzland, and also the global volunteer community help make Codex every day. As part of this open collaboration, Codex is a federated design system, this means that no single team owns it. Instead, different designers, developers, and also people from outside the foundation are collaborating, creating new components, new icons, or new tokens. And while this openness is sometimes complex, this makes the Codex design system also strong, with more inclusion and more trustable. Since we work for open collaboration, we manage all the design and development tasks in Fabricator. Fabricator is our beloved tool that is open for everyone and is where we manage all our tasks for design and development. Anyone can jump in our Fabricator's task and ask questions, comment, provide feedback, suggest change, anything. This is truly unique, and many components and tokens have been created directly with volunteer contribution and with contribution from people outside the foundation. And also, we prioritise always tasks in Fabricator based on real needs, what the teams are working on, what the volunteers request, all this. Always we introduce something in Codex is because it's going to be used in real life. And as part of this open collaboration, I'm giving some examples. The Type Heads search is one of the components in Codex, Type Heads search that is basically the search input that we use in Wikipedia on many other Wikimedia sites. With Wikimedia, we detected that this search input was not working properly for small devices, so we decided to open a task in Fabricator. And with the feedback of many different users joining the task that was so long, we decided to redesign some things like including a clear button to remove the type of text when you are searching or removing the search icon on mobile to make this better for small screens. But not only this, we improved the keyboard navigation and we also include some accessibility improvements, especially for those users using this Type Heads search on mobile. Another small but big change was the external link icon. The external link icon is this icon that we use everywhere for links, the links that are also only external. The previous version that was this one, the first one, was not well-optimized because it was not well-visible in this small size because we used this in 12 pixels. So some users requested that this needed to be updated and we created a task. We collaborated with them, we provided a lot of feedback, we collected a lot of feedback from them in the task, and based on this real feedback, we redesigned this icon to this other version. They are similar but not the same. And the second one is working much better, of course, in this small size. So these are small changes that make a big difference or that have a lot of impact. And Science Open collaboration means listening and evolving based on the community feedback. During the last Wikimedia Hackathon, we received some requests from volunteers to have in Fabricator some space where we could have good first tasks for volunteers, regardless of their expertise, because not all of them have the same expertise and some of them wanted to work in some tasks that were more easy for them. So we created the staff in Fabricator with good first tasks for Codex so everyone can join this Fabricator board and find tasks that fit in their expertise. So, we can improve the collaboration. And also, as part of the last Wikimedia Hackathon, we also created this Codex, this Telegram channel for Codex that everyone can join. You can join now using the QR or you can ask me later. Please join. And here you can ask questions. You can open any conversation related with the Codex design system. And another thing that makes the Codex design system unique is the accessibility, of course. Accessibility is not just a checklist in Codex. It's the baseline of our mission. Accessibility is about making sure that everyone can navigate, interact, and contribute without barriers. And we design for people that is using screen readers, yes, but accessibility is not just for these few people, it's for everyone. Because anyone, regardless of the screen readers or keyboard navigation or anything, they can benefit from accessibility improvements. One example is someone holding a baby with one hand and using the mobile with the other one. Maybe the other one is reading or editing an article in Wikipedia. In this case, this person is using just one hand, so this person will need the interface and all the components and all to be really easy to navigate, to be able to navigate with just one hand. Or maybe you have a broken arm or something. Sometimes you don't have permanent disabilities, but time disabilities. Another example, the typical one, when you are reading an article or editing or doing other tasks. In a train, while the sun is writing in the screen and writing directly on your mobile, in this case, this user will need that the interface is in contrast to be able to read in a proper way. And these are some of the examples that people that don't have permanent disabilities, but anyway, they benefit from the accessibility improvements that we work every day. Because accessibility is not something that you can check once. It's an ongoing effort. It's something that you need to include at the beginning of the project always and evolve while the project is growing. So we are constantly learning from people, providing feedback in our fabricator task or user providing feedback, and always improving the accessibility. Because also the accessibility requirements are always changing, so it's something that we regularly need to evolve and review. And as part of these accessibility improvements, one example is the dark mode. The dark mode was a feature that was highly requested by many users. It reflects our focus on accessibility and our focus on visual comfort readability and reduce eye strain, especially in low -light environments. As part of the dark mode feature, we needed to review all our color palette and also make things like desaturate some colors, especially the progressive or the blue ones that we use for buttons or links. This is how we create the palette. We needed to take all the colors that we have and then create new ones that we're going to use in the dark mode. We use some accessibility tools, but we also needed to use manually some colors. And as part of the dark mode work, you can read Wikipedia in both light mode and dark mode. But in Codex, we have all the tokens and all the components ready to use for both light and dark mode. So, if you want to create any project, you only need to use the component and then this component and all the tokens will work automatically. Another example of the accessibility improvements is the diff styles. The diff styles are the ones that we use to indicate when the content was added or removed from an article. This is really important because it's the way we have to explain users the history of an article. The previous version was using just colors and these colors were not working super well and also the problem that we have with the diff styles, and this is the way we decided to redesign this, is because we were using diff styles differently across different projects and across different platforms. So there were some inconsistencies across projects and platforms. So, we decided to create a fabricator task, as always, and work with the community feed and work in different iterations and we ended up with this new version that not only includes different color updates, but also we reinforce the concept of adding and removing with other visual clues such as the icons, also the borders and redesigning some things in the interface. Because this is an accessibility principle, not always rely on colors to indicate the different states or status or the different elements, but also rely on more visual clues to indicate these differentiations because the colors will be perceived by some users, but some other users will rely on icons or will rely on the borders or even in the text. So we have different ways to improve the accessibility, not always with colors because all of us know about the color contrast, but accessibility is much more. Another important thing in Codex is the internationalization. The internationalization Codex is built for more than 300 languages, that is a lot, and this is not only about translation. The internationalization in Codex includes full support for right-to-left language, the reading direction for Arabic and Hebrew, also icon flipping for all our icon system, takes expansion for the different components in Codex and flexible components to be able to include all these differences in the different languages. One example of the internationalization applied in Codex is the icons. We need to, apart from the 300 languages, we need to cover many different cultures and the icons, some icons are examples that, not in all cultures, an icon means the same. For example, the bold and italic. We needed to include these icons not only once, but in the difference, in all these different variations, because bold is understood as bold in English, but in Spain we say negrita, so in Spain we need an N, and the same with these different languages, and also with italic, in English we say italic, while in Spain we say cursiva. So we need to always make sure that anything, any component or any icon that we include in Codex is not only included, we need to make sure that this is going to work for the different 300 languages and the different hundreds of cultures that we work for. So yeah, in Codex we added up the icons, and we include locally saved versions for icons and components. And also we design components with this differences in mind. Thanks to open collaboration, we can collect feedback from many different people from many different countries around the world, so with this feedback we can improve how we work for internationalisation, because of course not all of us know how to read for Arabic, so this feedback provided by real users is really meaningful, because they are real users that are using this. So yeah, we create all our components, all our components are ready to be used in left to right, reading direction, and also for right to left. And since directionality is really important in Codex, we have dedicated guidelines in the Codex site explaining the difference and explaining how to mirror any component icon or also interface. And also the variation across language, this is also part of the internationalisation, since we work for many different languages, not all the languages have the same text length, and this is really important. We sometimes design for English or for Spanish, but we need to make sure that, we need to always work for the edge case or for all the case, not for the case that is going to work visually well in design. For example, and we also need to test the components not only once, we need to test the components. When creating one single component, we need to test this component in many different languages and many different use cases to make sure that this one single component is going to work well in these different use cases. An example of this is a menu. Imagine that we design the menu. The menu will probably work well for English or for Spanish because these words are not so long or so short. But what if this menu is going to be used in Chinese or in Japanese? In this case, the text of the word is going to be too short. So we need to make sure to test this to decide the proper width of the menu. So this is why we regularly need to test our components many, many, many, many times to make sure that it's going to work for all these hundreds of use cases that we need to cover. And this is why simplicity and reusability is the base of Codex. We design Codex as simple as possible because if we create more complexity and more components and more icons and more things, we are going to test these in all these hundreds of use cases. So this is why we try to create our Codex system and also our interface as simple as possible, but trying to cover all these use cases. And yeah, we are almost at the end. So just to say that you can be part of Codex because Codex is open for everyone. This is a QR where you can find the Fabricator task that you can start contributing to or join the design discussions in any task. So you can use the QR to join the Fabricator board or ask me later. You could subscribe and comment to any Fabricator task, propose new components, icons, and tokens if you think that they are going to be useful. You can share feedback, improve documentation. You can also improve the codec documentation in the Codex site. Join the design discussions and also submit patch for code or review code. You can be part of Codex joining our Fabricator board. And yeah, to close, I will say that designing openly, of course, might take more effort. It's more complex, but it leads to systems that are real, more strong, more sustainable, and of course, more inclusive because you open the conversation to people that is going to use this system in the reality, not internally in the company. So yeah, let's keep building and let's keep doing it together. Thank you so much. And I will be in the QA session in case you have questions for later. Thank you., Designing Openly for Everyone: Meet Codex!, YouTube, 01k8te7n3akfpghqvx6rhw3p11.