 Hi everyone, welcome to our next session. Let me welcome here our speaker, Metz, the principal developer advocate at DevRiot. And we're looking forward to your presentation. The floor is yours. Thank you, thank you very much. So let me share just this screen and it would be good to go. Okay, awesome. Perfect. So hi everyone. I'm really, really happy to be here. And I'm really happy that there's so many people with us today. So we're going to talk about the design systems and how to work with design systems from a developer perspective. Because, you know, we talked about UX for years, but unfortunately, we don't have that much resources regarding design system and user experience from the developer perspective. We've got a lot of resources dedicated to designers and the design side of design systems and building consistent interfaces and good interfaces for our end users. But we don't talk that much about the developer side. And the fact is, developers are users to just, we have other needs because we are using tools that our end users are probably not using, except if you are doing some kind of that footing with your own product. But in a sense, we are still the same thing anyone. We are still users, but we need the dedicated tool for our very own work. So we've got plenty of designer resources, not that much they have oriented, dedicated to design system and what it is and how to work with them. The idea of this guide is to try to give you some advice and some tips to start the design system from the developer side from scratch. So as a reminder, at first came the atomic design principle and the atomic design pattern. So in a design system, you will have different aspects of your complete interface and your complete system. So the first thing is your design tokens. They are holding the different variables and the different common sense of your brand and what it is and describe your identity as brand, as a product. Then you've got a design kit, which is finally how you are exploiting these design tokens and that helps you to finally build the basic elements, basic blocks of your interface and your application. Then upon that, you are building a component libraries containing the different kind of elements and the different kind of components that you do need to use to build your final interfaces. And you also need dynamic documentation because you know, even if you've got a really good product and a really good design system and components libraries and tokens and so on, without a good documentation to come along with it, you have nothing because nobody know how to use your library and how to use your tokens and your components. So you do need a really good documentation associated to the rest of your interface. Both of them, the world stack of those four elements finally forms what is a design system from a developer. So design system is just here to help people to deliver better products in a better way. So if I go back to the atomic design principles and atomic design pattern, when it was defined by Brad Frost, something like 15 years ago, something like that, I guess, we have this definition. We first have some kind of organic approach to what is a design process and a development process and how to make them consistent in the overall experience. So we start with atoms. There are the minimal viable elements in your interface or in your design system and in your application. Upon those atoms, you are building molecules and those molecules are finally some kind of aggregating different atoms to form advanced elements. Then you could build organisms and organisms are some kind of compositions of your molecules. So you are compositing your different parts of your interfaces by building different kind of components. Then using those organisms and your those molecules, you can build templates and iterate those templates to build final pages that you are pouring and giving to your end users. Pages could be views, could be whatever you want and whatever you want to ask it. Depending you are building a static website or a web application or whatever. So, from our perspective at DIV Riot because we are building a product oriented to design system, we prefer to see this in this way. We've got design tokens at the center. There are the single source of truth that are finally helping designers and developers to get in sync together and those design tokens are finally nurturing the design kit by itself and also the components library and also the documentation site. And having this in this shape help every kind of people in this front-end area that are designers and developers and product manager and QA testing and so on to all work in sync to find the same kind of elements. So, we want to build components and we want to build components that are first reusable so they could be agnostic and you could use them in any part of your application and reuse them in different kind of variants depending on the context you are using them. We want them to be testable so it will be easier to finally focus on kind of issues securing in a specific element and fix these issues in those specific elements rather than trying to fix the entire application. We need them to be customizable so we will be able to finally have some kind of variants of theming or something like that to improve the final user experience with the overall interface and we want them to be collaborative so any kind of people could contribute on the code side and the documentation and the design and so on. So, what do we have at the design system foundations? First, the design tokens. First step, your design tokens are finally some kind of atoms in the atomic design system pattern and in it we should consider them as some kind of variables. So, we will externalize as much content as we can in our design system and our design tokens and we will composite them. So, we will have some kind of real like color, spacing or typography. We would group them by specific concerns like color phones or spacing sizes and so on and we could then name them, add some values and maybe add some kind of attributes to help to contribute them and to update them. From a developer perspective, it's something like a tree and finally, if I represent them in the JSON format I would have some kind of definition like tokens containing colors. Those colors have some palettes of colors or some fonts and we have some kind of variables in them. So, the base font of the gray hundred color in the palette and so on with associated values and kind of meta-daters like theme-able or comments or whatever you want. This kind of definition is pretty interesting because this is exactly what the design token community group is pushing in the W3C as a standard to have a common standard to exchange information in a form of a design token between design tools and developer tools. We are using a different way of using a solution named Style Dictionary which is built by the Amazon team and we made a simple playground in the sense of a Style Dictionary play interface where you could easily define some kind of token in this kind of JSON format and automatically export them, build them in a final GS file or JSON file or CSS custom properties file or whatever you want. So, I would carry it and play with it but this solution is really interesting because it directly exploits the format that is nearly the same one as the design token specification. So, it's a good try at first. Second step, build your base components. So, with your base components, we are finally creating molecules and those molecules are finally some kind of component-driven development. So, you will build all the small elements that you will need, the buttons, the input, the headers, the body content, the menu and so on, the navigation. So, you have to stick to the basics because we don't want to build an advanced component like, I don't know, a carousel or something like this. We prefer to have really small elements that we will be easier to aggregate after that. So, in this very simple example, I just create a simple button using the React area framework and using it, I just build some kind of button adding some advanced composition using the React area primitives to pour some kind of area content in the button by itself. And I just expose it and after that I could reuse it in the other side. So, I could import my button and get access to my button and finally have kind of variants like the small one, the medium one and so on. Then, I could exploit the token in the size of the custom element itself. So, I will exploit my tokens by just importing them in any form that I want. In this one, I use the CSS module in the form SAS file but I could also rely on any kind of styling library, style data mounts or something like this by importing the token in any formats because the D tokens are finally burned in a specific JSON format but are exported in any kind of format that I want and I could explode them finally in the final component. Third step, documentation. You do have to do it and do it probably the right way to help people to understand how to use your component. I really love this approach which is the diatexis framework and the diatexis framework is saying that you are splitting your documentation in four parts. The first one is the tutorials. They're just simple steps that you could reproduce over and over and over and always having the same result at the end. This is the best way to get started with a new project or a new component, a new element, something like that. On the other side, you've got the how to guides and the how tos are finally an approach where you are solving specific issues. What will I do if I want to use my button in this specific context or with these specific frameworks and in these specific kinds of views and so on. They need a prerequisite context that when you have it you would just have to follow the guide and finally have the expected results. On the other side, you've got the explanations what are some kind of FAQs, the historic explanation of the component by itself. Why do we develop these components this way? Why do we embed those kind of primitives, those kind of react area primitives or something like this? Just to give some context to the developers so they are able to understand where the system is working but this is not mandatory to finally use the components. This is just to have a more deep overview of what your component is doing and how you could use it in different contexts. And finally you've got access to the reference and API documentation full of a view like a man pages of your final component and you could reproduce that for any kind of components in your design system. By doing so when you split your documentation in those four paths, finally you've got access to the practical aspect of your component in the tutorial and your two guides and more to the theoretical overview in the explanation of the reference but when you are just studying for the first approach what is this component and how it is working you just have to focus on the left path for the tutorials and the explanation just to understand what it is. And on the other side when you are really deeply working with the component and trying to find how it works and how you have to use it in your specific use case then you've got access to the right path with the O2Guides and the full overview documentation of your component. So this is the best way the best mental model to finally shape your documentation because each time you are adding some kind of content or looking for a new content in your documentation you just have to think first at first what I am exactly looking for. Is it some historical approach, a specific guide getting started of another view documentation and that's where you are looking for your final documentation for your component. But because we are working on dynamic content we do have to build a documentation that is adding exactly what we want because what we are shipping at your end users at the end is not some kind of documentation it's not some kind of design at all it's code. So code is finally a single source of truth of your design system and of your overall application because this is what you are shipping to our end users at the end. So your documentation may take care of Zeus code as a single source of truth so rather than just reproduce some kind of content and some kind of code in your documentation and having to keep it in sync with your code so each time you edit the code you have to edit the documentation to reflect your changes in it. You probably have to just import the code into the documentation and have a live documentation in it and this is exactly what the MDX format and or the Mardin in JavaScript or the JavaScript in Mardin format stands for. They are finally just a way to embed your components directly into your documentation. In the left elements this is where I'm putting the chart components and I put the chart directly into my Mardin content which is the best format for my documentation or in the right side this is Mardin JavaScript and I'm just importing some kind of element and I just suffix my code block with a specific content. Here is a previous story so I know that this code which is my final component of my card will be finally rendered as a form of the story directly into my documentation. So by doing so you are able to code your documentation which you could directly embed some kind of playground, some kind of props tables that are dynamically extracted from your code and put right in place in your documentation. On your right side you are looking to backlight which is the design system editor we are building at the riots and in this documentation tab you are seeing a documentation which is a live documentation with a live playground or the live props table and you don't have to write them directly into the documentation they are just extracted from the component you are documenting. For a part test them and test them out so you need to test your component you could use any kind of regular framework that you want to use but you do have to test and to unit test your components which means testing the rendering, testing the results, testing the user's interaction to make sure that anything is covered and you won't forget anything in any case of use of your final components. Tell them extensively take the default values, properties different slots and what they are supposed to receive and use any kind of framework that you want you are not constrained on any kind of frameworks but do it and do test your architecture. So to make a future proof architecture in a sense of a design system you have to focus and different themes and variants for your final application. So to do so you have different kind of example but the best way to is to defining some kind of default and extends those defaults. In this example this is a way of extending defaults tokens in CSS custom properties way but you could do that in any kind of format. So in this one I just defined different elements by just defining some kind of different variants the light one, the grape one and so on. Then I will define what is the default version and default is finally just a remaping of my light elements into the default values of my final tokens in my application and I could define some kind of variants by just targeting some custom attributes or custom elements and I could redefine and override my default tokens with my specific content for a specific theme or specific variants or something like this. So finally this is just a way to define a common collection then define the default and then override the default and this is the best way to handle some kind of variation and some kind of teaming of your final application because at the end your components will just use the regular tokens that you want brand, text first, text second surface first, surface second and so on. And this is your responsibility as a theme owner to finally override them depending on the context and the variants that you are specifically targeting. You could also rely on different variant queries like targeting the OSDark model, thoughts like that. This is exactly the same way to do so. So it both allow to have variants but let the hand on the final user to specifically choose which kind of variants he or she prefer to use in the final application. So they are just able to switch them by switching a theme switch or by defining their user preferences in their browser or their application also. It finally allows you to have a live version of that. If I go back in Backlight and see this kind of example in application I have this theme switch in my documentation because my documentation is coded by the rest of my tokens extracted from my application then my documentation is inheriting this different kind of variants and values coming directly from my design token of my application. So I could also preview live in my documentation what is occurring on my different components for zoo specific variants and so on. Then advanced composition you are able now to build some kind of organisms and templates. So we will be able to build advanced component based on the default primitives and default ones like building a big dialogue using different kind of elements like a title or a content or a button that you are directly re-importing and so on. So now we could build big organisms and those big organisms are also using some kind of composition for the theme and for the aspect using the tokens which means that you will be able to finally just build some kind of advanced definition like button models and so on that are finally a composition of your different theme and variations in that. Then you will be able to release it and this is a final step of your design token. So distributing it as a library format and having some kind of exploiting the package building a monorepo architecture and push them everywhere in the registry where it will be able to be reused directly from your final application. So you are just distributing your design system as a library and you will be able to reuse it anywhere in any kind of format. Then you will be able to reiterate it and having your final component ready. So designers have high level tools and us as developers need the same kind of high level tools to build the design system that we want. The idea behind that is that you will be able to shift left to your design system so shift left the complexity meaning that you will solve also the different issues that will occur in the components themselves rather than in the application itself. That would be easier for maintaining it for the future and make it more robust in time. So keep in mind that developers are finally just users just like you. I thank you all. I'm Mads. I'm a principal developer at the riots. We are building different tools oriented around design systems and components like backlight use so in the this token in different demos. I thank you very much for being there with me and I hope you know see a bit more how to architecture design systems from a developer perspective. Thank you.