 looks like we're ready to get started. Is Tim here? Oh, there's Tim. Tim, you're up. Hello. Thank you very much. I was always in the wrong room. So let's get started. I'm super, super, super, super excited to show you what I'm showing you today. So let me start my screen sharing. Cool. Can everyone see my screen? So what I already discussed with a couple of people and we discussed already in the past is the, I think the most important step is that we have now the awesome stuff in GitLab UI. Give design.gitlab.com and we need to figure out how to get this integrated and get this actually now in full swing, get this fully used, make everyone aware of what is already available in GitLab UI, make everyone aware of what is already available, design.gitlab.com, exactly what is already also written by Tori and Dimitri in that part and get this really into our daily usage and basically ramp up the production of components. So I have played around a little bit last week and have built a QC, which is already like in radio mode on one hand in GitLab UI and then that's the second part of it is in design.gitlab.com. And that's what I actually want to show you today. I have the example. The first part will be mainly targeted at front-end engineers and the second part will be targeted at everyone. So please bear with me. I will try to explain it as nice as possible. So if you get lost on the way, please let me know immediately if I'm too fast or jumpy in my thoughts. But apart from that, let's get started. So what do we have? We have an example here, which is the skeleton loading. I took the most easiest component that we currently have in our code base on GitLab UI. So it has a props. It has basically one prop, which is around the lines. So how many lines should be shown? It has even a validation in there, which is also nice. So that's a minimum range of one to three, which you see here in the validator. And what was the actually problem that we have? I have seen it in all the years that I am working already. This documentation is nice as long as you started, but then documentation is not updated. It's not in prolonged etc. So I tried to find a way to automatically document our endeavors in GitLab UI. So everything that currently is needed on the example that I really need to show you is that I have introduced a documentation property attribute to the whole component. So this is there to actually describe on top of what is already there through reflection to describe, for example, in this case, the validation of having a range from one to three, so that this can automatically get documented. We have also some other examples. So for example, our button is exposing the documentation. So it is exposing as it is based on a bootstrap component. It describes, okay, the base component is B button so that basically our reflection system can go to view bootstrap and take all the documentation from there and also integrating our documentation so that you don't need to jump between our documentation, designgitlab.com and view bootstrap, get everything in one place. You can describe on top of it special props info, for example, on the variant property of the underlying button, you can describe, okay, this is based on an enumeration. Those are like the types like primary blah blah blah blah so that this gets automatically displayed in our documentation, what events we are exposing in that case, etc. So we have also, let me see, for example, another example is over here where we don't have anything which is also important with pagination. So a lot of it gets automatically described without adding any extra documentation. So that's one thing is to integrate into the actual component an extra attribute which is called documentation. There's already the documentation on the documentation props is in the merge request. So what you can extend it, it's events and what you can describe as events, slots, the specific properties, what types they have some special info, etc, etc, etc. The other part that we have per component is the actual written documentation. And that's the part that I wanted to reduce. So before I started with the whole thing, the skeleton loading was a documentation on what is the base of it, what are the properties or table, full description, etc, etc, etc. And the only thing that is left by now is just this one paragraph which describes under the, oops, which describes under the hood, how this animation is done. The same happens for the button. So the button on the button is a bad example. The pagination has also only left now the additional notes, also everything above can go away, and which is what I will show you later on. So reducing the actual needed written documentation to an absolute minimal second part. The third part is examples. We want to provide examples and that is currently something that I just started now as a PC. Let's see if we can perhaps even integrated the storybook in one or the other way. The way I have started it now and that is here is basically that you define examples, components and examples for skeleton loading. So this is by example, I found two, three other design systems that do it exactly in the same way. So we have a basic example, which is just a skeleton loading, which is just exporting the component done. Second example is a one liner. So it's exposing, okay, this is now an example with just one line display. So super pretty straightforward examples of that component that can be used. They are then exported through a tree that can be also grouped. So you can say, okay, these are my basic examples. These are my styling examples, et cetera, et cetera, et cetera. So far so good. That's everything that you need to do in GitLab UI. So that's the part that faulted engineers need to do to actually document the component, expose examples. And that's everything that you need to do to get it imported then in designgitlab.com. Now let's go and switch over to designgitlab.com. And now I need the attention again from, especially also all your Xers. And I think it's Tori around. I hope she's around. So I think that should make you quite happy. So what I have done is I changed our format, which is currently some view components. I changed it now to a format which is called frontMatter, which basically is a combination between YAMR definitions and properties and markdown description. So the definition of the skeleton loader defines the component or the element in the skeleton loader, the view component that we have in GitLab UI is the GA skeleton loading. And by example, the related components is the spinner. It was also part of the description so far. And the rest is now markdown and not a view component anymore. It has a lot of advantages because you can't forget closing tags, etc., which is something because I added ESLint and pretty on top of it. And that brought a ton of missing closing tags, etc. And with markdown we can get rid of that pretty, pretty easy. The other thing that I implemented, I will show you in a second the outcome of it is you have a special tag which is currently called sample. I will rename it to example. So you can directly markdown and write, okay, I want to show exactly at this point one specific example, which is the skeleton loader basic, which was defined by the front end engineers on the other side. So you can write whatever you want to describe the actual usage, actual design intendance, and document it with actual living and life examples of that by simply inserting those markdown comments. Yes, and that's it. And that's now what the outcome of this is, is that DesignGitLab.com now looks the skeleton loader page looks now like this that it has on top of the design part and the view component. The actual markdown is now transpired to a view component and in that view component you have also now the actual example that we have just inserted for markdown. This preview component will also have the source so that you can copy it and the HTML output so that should also help then developers to actually use it. The other part that is now coming all from the reflection side from KitLab BI is on the view component tab. So this is mainly for developers to have on top of that to actually how to use this and this is where you can see, okay, you see all examples that are currently defined for a skeleton loading. You can switch between those. You can play around with those. You have the actual menu description here and all the automatic descriptions. So this component by example is not yet fully designed so it gets alert message, okay, our design system on this component is not fully implemented yet. It will show all the properties. In this case, it's pretty easy because it has only one value which has like a limited range and you get automatically also the line how to import this into your code. So this is basically the target point for every developer to go there and actually take the code from there. And the next step, it would be also the idea to get knobs in here so that you can actually play around with those values and see how the component life changes on top of it. And you can also take a look at all the samples, their source code and the HTML directly in DesignKitLab.com. And how this will look on more complex samples. I can show you still in the storybook because I haven't integrated them in DesignKitLab.com. So by example, the button is a more complex component and this gets also reflected. So nothing of this is done manually. All the reflection of the properties from the view components have automatically taken from view bootstrap integrate everything to one table. Everything that is blue currently is coming from view bootstrap. You get the events, you get the import. You see, okay, this is based on the view bootstrap component, the button, you can go there and read even more on the view bootstrap side. And that's it. That's the basic starting point to get a BitLab UI integrated in DesignKitLab.com. Questions, comments, etc. Maybe I missed it in the beginning. How do we update the thing? So if on DesignKitLab.com do we always have to forward the GitLab UI version and then we're done with it? Yes, there will be the ideas to have also their manual task to actually upgrade the GitLab UI version or that we go to the latest as always with every release. So the only thing is actually to go there, say okay, the view bootstrap component that is underlying of this is blah, blah, blah, and then everything gets updated from there. Okay, cool. Does the documentation property that we're adding to the view components need to be a property of the view component? Can it be some extra exports or some external files so that it can be tree shaking away in production? Yes and no. I simply didn't make up my mind because I saw exactly the same thing in both ways. Some did it directly in the view component or in the rect component in reality and some people did it in an external file. Some people did it in the package.json. As we currently don't have actual folder structure for component, I was going for now for having it as a property. We can also inject another file that's completely up to it. The other thing that I was thinking of was that during the export that we also could simply cut it away. The property goes away through the build script that you don't export it and as view, by example, you have a runtime and a full export. Something like that would be also way but I couldn't make up my mind what I like more to have everything at the same place or to have in a separate file. So still up for discussion. I wanted to, first of all, thanks. This is amazing. This is like the best post-vacation gift I've ever gotten in my life. Timeline, I know that obviously we're working on rolling this out. When do you think we'll start being able to actually see this get into design.kit lab? The merge request on the GitLab UI side was already reviewed by Clement the first round last week. I did now some more changes to actually, during the connection between those two. On the other hand, I make everything backwards compatible. So still all the view components that were used for describing everything are still the fallback. So only if you start writing and adding a markdown these front meta files, only then the specific new controller is used to display everything. So in reality, if the GitLab UI thing is reviewed and merged, then designkitlab.com can also be reviewed. I hope this gets merged both of those this week. Okay, perfect. And then obviously I'll get with Clement to figure out how the UX department as a whole can help make sure that we're getting things done and speeding it up. So whatever we need to do, we'll do it. This is really important and really amazing to see. So thank you. You're very welcome. I think this will, this should be now the kickoff that we can also scale the whole GitLab UI. That now we have the whole workflow in place from visual screen testing over to creating the components to integrating the documentation. So if anyone knows, okay, now you can go to designkitlab.com and use those components from there and everyone can start producing components and then we should get very fast way more. Yeah, I think it's for both departments. It's super important that we have now than the full workflow in place. So Tim, first of all, thank you so much. This is amazing. I'm still pinching myself to know if this is a dream or not. This is so cool. And I have two questions. So one of them is related to pages that we currently use HTML on. Like for example, if you go to the foundation scholar page, for example, it has a lot of custom HTML and CSS there. Would it be possible to integrate both things? So markdown with the examples and maybe some areas that have specific classes or HTML? Yeah. So right now what I've integrated is simply a component that looks first if we have a markdown file and if not, it goes back to the HTML file. I targeted it mainly now the view component as an underlying view component that does now all the rendering of that stuff that was only targeted in the first place of components. But we can take it from there and can build whatever we want so that we then also convert the color page with specific HTML. So markdown it that is the markdown renderer I'm using also supports included HTML. So you can write markdown with HTML and markdown again. So that's also this is just really the starting point. We can also extend it. We can extend, for example, the attributes per page also to have like a thumbnail and stuff like that so that we get nicer overviews that we can create keywords on top of it. We can also the other idea that I have on my to do list is that we can show in the that the whole menu on the side on the left. I want to create at least the components section now from index file so that you don't need to add anything more anymore to the to the menu manually. And that we can also show if we already have new components available or not or can actually filter down the whole tree so that every engineer already knows. Okay, there is stuff that you can use and that you can work with to go ahead and use the stuff because I think that's for us. The most important thing that we have already now five, six components and everyone is aware of them and uses them all the time. And that we can take it from there. That's great. Thank you for explaining that makes a lot of sense. And my second question is related to the examples. You, you were showing that you define the examples of the components in the GitLab UI. Why did you I'm just curious to understand why do you define the examples there instead of being in the design system for example. One easy thing, first of all, it's easier for the developers to actually try them out stuff with the code. So if you write samples, they can be also used for the visual difference. So every example that we write in GitLab UI is already there. And if you work in one repository, it's most probably easier. Okay. And on top of that, we should be able to use all the visual difference on those. Okay, that makes sense. So the, so for example, when you were showing the storybook that has the knobs on the right sides that you can tweak all the properties. So that would be the place like the playground for when people are developing components, they would be inside of storybook, tweaking all the things making sure everything works. Is that it? Yeah. Yes. But I want to, that would be step number two would be to bring this also over in our table. So that this table here with the component property that instead of here just having a static value that you can actually play around with it. Correct. And that there's a component on top of it that actually changes so that you have inside the scientific.com also the knobs, but really nicely integrated in the page itself. But that would be definitely step two. So. Okay. And so when people then push a new version of GitLab UI, would we have to manually update here in the design.gitlab.com or are you predicting another better workflow to do that? Yeah, I think we should find a way that as soon as you that we have a really easy way as that was the same thing that Lucas mentioned before that we find a really easy way to have GitLab UI updated in design.gitlab.com in a very easy process so that you can either run just one command, and then it should work or that you can do it manually over CI step or that you can have it always upgraded if you change by example something in the markdown. But that's definitely something we need to figure out first. Thank you so much for showing. That's all I had for now. Really good. Thank you again. Any other questions? Then I will hand it over to Dimitri. Please take it from here. Yeah, sure, Tim. Yeah, thank you so much for this. And I think this has been the best answer towards the second point on the agenda, which is basically the gist of it is let's communicate design.gitlab.com more with frontend. And as it's been mostly a resource for for design, and it now will become an even better resource with more applicability for for frontend, I think it's going to be already a lot better in the future going forward. I had this. I had this idea because of a discussion like hey, is frontend actually using this or are they referring back to it. And I just wanted to make it like known that the design system is for everybody. As Tari is describing exactly in the in the subcomment there, if you've not viewed it in a while or effort, please, please, please take a look and help be an advocate for the design system throughout the throughout gitlab. I think it's interesting that the design system is only worth as much as the people that are using it. So the more people that are using it, the more valuable it will become and it's a it's a nice thing that not only not only design people but also frontend people are everyone in the company can refer back to this documentation and see if decisions are made appropriately. Right, or things are missing in this documentation. We're handling on basic instinct or intuition, which may be good, but should be documented in the end. Is there anything you want to add. Sorry. I just want to add that if this is the first time that you're seeing the design. It's probably a little more clear what it is after Tim went through that demo but if you're still like what is this is the first time I've seen it just reach out to me because I would love to talk to you about it and just kind of evangelize it more within gitlab from our two teams because it is super valuable for our teams. So if you're like oh this is so new and awesome I want to learn more than I'm available to talk about it. And I linked all the things that we have in there now. So like take some time to look through it just to see what's currently there. And then obviously the things that awesome things that Tim is adding is super exciting so it's really coming to life which is really awesome to see. And where the point to this. Yeah, which I think I know where this point is came coming from it's from a I think it's from discussion in every role of mine. And I would like to iterate on the communication point because what led to this point was the fact that the mockups and instructions provided did not match the design system. It was very confusing to do what was in the mockups and then on the review. The review wasn't like immediately approved because it wasn't according to the rest of the of the design systems or the rest of gitlab so it was a bit confusing to have two sources of truth and I think this is where the communication problem is coming from. So sometimes it's hard to understand should I follow the mockup that's been provided an issue and the instructions, or should I follow the design system. No, it's true you got a good, good point there Philippa and you're right on that like we are still in this state of like where not everything is documented and not everything is like there are multiple sources of truth. I think the only way forward is is it needs it needs our input and the point of where I thought was like hey there's some some misconception or some miscommunication perhaps is the fact that because in the communication point between us. It became apparent to me that the design documentation. Yeah I lost lost Dimitri as well but I do want to say that there's only one source of truth and that is the design system. And there's cases where we may not follow the design system right now but that there's only one single source of truth. And it's really right now and this kind of we're in between phase is a communication between the people working on the merger quest and the and the designers like it's just about communicating and figuring out what can get done in this merger quest what needs to be done in the second merger quest. I don't think it's going to be as easy as follow a mock up or follow the design system it really depends on so many other factors so just communicate with the designer and then you guys have to work together to figure it out until you know the design system is implemented further or if you have time to influence something for the design system that's awesome do that but I do want to state that like there's there's not multiple single sources of truth there's only one. It's just a matter of getting to that one over time and it's going to take time. Thanks. I think he's next. Yes, I'm here. Thanks story. So just a quick note about the discussion that we started in our UX weekly last week and just wanted to get more eyes on this especially from front end. We have the updated form guidelines and accordingly we have the updated design specs for forms. And we started a discussion where I suggested that we should update the forms and validation of forms whenever we can whenever we work on issues that we work on and if we encounter forms that we should update them. But then the pushback was that we don't always have the time or resource to do that. And then we started discussing okay maybe we need a more systematic approach to do this. And we took the discussion to an issue and I would just like to get your points of view and continue the discussion because we really need to update this because the moment. Very often when you form validation is just you want to submit the form and you get a alert on top of the screen and the screen scrolls to the top. And it's really painful to use that especially on settings pages where we even close the sections where the where the error actually happened and new form guidelines and form validation should be much more user friendly. And let's try to get that updated so I just like to get some comments and then I can take it forward and come up with a list of most of the pages that need to get updated and we can take it from there. And yeah, that's pretty much it for me. If anyone has a comment right now, you know, you're free to share it otherwise I would really appreciate it if you take this sometime to look at the issue. And I think, I think most of the forms that you're referring to Matthe are still the old. Hamel files right so I think in these cases we have a lot of validations that get rendered through the old Hamel files and not the new components and in these cases we are using the big red blocks on top in some scenarios. So this is a lot of stuff that uses the old like rails ujs like magic form validation to that it would be great to get rid of the move on. I think a lot. I think a lot of them are like coming straight from the active active directory validations right active record validations. Cool, I would suggest let's take it to the discussion to the issue because we're running out of time. And I have another meeting and I think other people have meetings as well. So yeah, have a nice day everyone. Thank you everyone. Bye. Thank you.