 All right, welcome everyone to the tutorial session during the hackathon for the Pajama design system. I'll just, there are a number of people we have from the UX team, and I'll turn things over to you, Sam, and you can introduce yourself and the rest of the folks and we can get started. I think you have a slides to share as well, so. I do, thank you, Ray. One second, let me just share my screen. Where are we? Oh, spoilers. Right, okay, so today we're here to talk about our component migration efforts. This is kind of a joint effort between the UX and the engineering teams. So this is quite a big effort. It's a big effort with lots of small amounts of work. So, we're doing this so that we can get the community involved and get as many people involved in this as possible, because it's a big task and we take all the help we can get. So everyone can contribute, right? So I'm Sam Beckham. I'm a foreign engineering manager here at GitLab. You can reach me at samdbeckham on GitLab, on Twitter, basically anywhere. GitLab and Twitter are probably the more useful ones, though. And I'm joined today by Jeremy Elder. I'll let him introduce himself. Yeah, thanks for joining and putting this together. So Jeremy Elder, senior product designer at GitLab, I'm on the front end and UX foundations team, helping with working through some of our design system with pajamas and GitLab UI. And so happy to be here, happy to have this migration effort and we'll walk through what that is and jump right in. We're hoping to have enough time for questions in the demo. So I'll let you take it from here, Sam. And it looks like Jarek's on too, right? So glad you're able to join us. If you wanna quickly say hi, you're more than welcome to. Yeah, hey, Ray, how's it going? My name is Jarek Ostrowski and I'm on the UX front end foundations team as a product designer and been helping out with the migration effort and yeah, looking forward to seeing what you put together. So very quickly just a little bit about what we're doing. As I said earlier, this is kind of a joint effort with UX and engineering. So we wanna increase adoption of our design systems. So that's pajamas, that's design.gitlab.com. So this is the sort of UX side of things. This is where we do component usage guidelines, component code guidelines, things like that. And we're helping to do this by increasing adoption of our component library, which is GitLab UI. And what that is, that's a series of components that are built using the design system. So the theory is if we increase adoption of GitLab UI, we increase adoption of our design system and the two things kind of go hand in hand there. And as a lovely side effect from this, we get to remove Bootstrap from GitLab. So Bootstrap is great at doing exactly what the name suggests and that is Bootstrapping something. We're now at a stage where we have our own component library and design system. So Bootstraps become less and less useful for us. So we're trying to move away from that and all of the other bits and pieces that we have and bring them in to use our component library and our design system and things. So that's, and I don't show what this effort's about. So why are we doing this? Again, there's a design, there's an engineering side. I'll let Jeremy talk about the design side of things and then I'll go over the engineering. Yeah, thanks, Sam. So from a design standpoint, we've got some really key points here. First, it's just single source of truth. So right now having a similar to Bootstrap and in GitLab and also as he'll talk in a minute, it's also part of GitLab UI. There's kind of two sources of truth and so we're always having competing differences between production and the design system. So this will provide and promote a single source of truth from a design standpoint and overarching design philosophy that'll allow us to just have one kind of methodology and approach makes it easier for the design team and UX to kind of tackle problems in a distinct way. The component library, keeping that robust and having that, you know, back to the first point, single source of truth, keeping it clean and as Sam will speak to kind of a dryer code base also dryer from design too. So we're not repeating ourselves and tripping over things. Accessibility is a big part of this. So as we introduce new components, we're evaluating them for accessibility. That includes, you know, color or contrast, interaction states, you know, ARIA, some of the content behind the content and from a design standpoint, we're allowed work. We're able to kind of capture all of that and do a single thought and help promote that. And lastly, just to avoid visual regression. So with that single source of truth, we can really allow ourselves to be streamlined and have just clear design communication and assets to point back to. Yeah, the engineer inside of it, as Jeremy pointed to that, it's very similar. We want to avoid code reuse and sorry, we want to increase code reuse and have a dryer code base. So we can have one component that we develop and then use that all over the place so that when that component changes, it changes all over the place when we need to update things. We can update it once. When we need to fix a bug or something, we can fix it in one place. And it helps us build things a lot quicker as well. We can just throw in, you know, like the get lab button, the get lab model, whatever it is we need. And it helps us move a lot quicker with building features as well. One kind of nice side effect of this is we have less third party dependencies. So where we previously used in bootstraps, obviously one of them, there's things like DropLab and all sorts of ones where they're like JavaScript framework, not frameworks, sorry. Plugins that help us do things. We can start moving away from them and using our own get lab UI ones so that we don't have all of this weird mismatch thing which, you know, get lab is a relatively large code base. Now we're starting to get a few things like this. So we're trying to move away from them and move towards get lab UI. As a result of removing these, we get some smaller bundle sizes. And as a result of that, we ship less code to the user. So we get some performance gains as well. And this is something that every engineer enjoys doing. And if we can do it at the same time as, you know, these UX improvements as well and the design sort of, what's the word I'm looking for? Like coherence, I guess, then it's great, we're all happy. So there is one kind of caveat to the removing bootstrap side of things. Like this is kind of the underlying thing for engineering, is removing bootstrap. If we move to get lab UI, we can remove the bootstrap dependency from get lab itself and removing that should allow us to start removing jQuery as well. So we're getting rid of two fairly large dependencies at once from get lab itself and the bundles and things that we ship to our users. The one small caveat, as you can kind of see in this diagram is get lab UI has a dependency on bootstrap itself. So we're not completely getting rid of bootstrap. It's still kind of there in the dependency tree and things. But we're avoiding having bootstrap included in two places and we do get some performance benefits and things from that. So this is kind of the ultimate goal when everything's moved over, we can totally remove that dependency and start seeing some of these benefits. So this is some of the things from get lab UI that we're trying to move from bootstrap. So these are things that exist in bootstrap that we're trying to take and move over to get lab UI. We have alerts, pagination, popovers, tooltips, buttons, drop downs, tabs and models. And we have different epics and things set up to track each of these. And this is what we're asking for help with really. So taking what we've got currently and just moving everything over to the get lab UI version. We have created about 1,000 issues so far. So like I said, we need help with these. There's a lot of issues. These are spread across two epics. There's the Hamel migration epic. So this is migrating all of the things from our Rails side of the code base and the Hamel templates and everything. Things that use bootstrap classes and bootstrap JavaScript and things and moving them to the equivalent get lab UI. Classes and then there's the view one which is exactly the same but with view. And it's a little different in that we can just use the view components because get lab UI is a view component library. Each of these epics have inside them their own sub epics that track each component. And then each of them sub epics have inside all of the issues and each individual issue is one particular file or one particular instance of where this is. So it might be change the alert on the branch page or something like that. And if you dig into these, you'll see what that is. So in get lab UI, this is an example of an alert that we have there. And you can see we can look at the source, the HTML. If we look at the source, this is the view version of it. So this is how you would change it out to be the get lab UI component in a view app. You can see this particular example is pretty simple. It's just wrapping it inside that GL alert. Then for the Hamel, it's a little more complicated. You can click on HTML to kind of see the HTML that builds up this component. There's some helpers and things in places but this is generally how we're having to do it on the Hamel side for now. Sometimes it might make more sense to migrate whatever is in Hamel to a view app so that we have the ability to just use get lab UI generally. But this is kind of our fallback that lets us remove bootstrap essentially. So for where we're at now, I'm gonna hand over to Jeremy to talk over these lovely shots. Yeah, thanks. So I'll go through these relatively quick but just kind of anecdotal charts here for the migration broken down into kind of different components. As you can see here, for view buttons and pagination, we've had a decent burn down. We're roughly closed 56% of all the issues. You can see that we still definitely need a lot of help with bootstrap buttons and loading buttons. Could use some help as well. So let's jump over to the next slide. All right, so the second KR is to migrate the dropdowns, modals, tabs. You can see this is one where we're pretty much at 0%. So there's a lot of room here, a lot of issues to be picked up to help kind of migrate these as well. And then the last one for our KR is the popovers and tooltips. So you can see we're roughly over at 1%. So part of the hackathon in this effort is to really help us bring down those 1,000 issues that Sam alluded to. So we've had a really good effort around buttons so far, but the other components could really benefit from some quick wins in jumping in. So next slide. So how to contribute, everyone can contribute and there's two ways to really jump in and start. The first is to review the two parent epics. So one for the view migration and then the other for Hamel. And under the view migration, there are links to each KR and those contain links to the subepics that have all of the issues that you can choose from. And you'll be able to tell which ones have been closed and assigned if you need any help following. You know, finding those will have resources at the end as far as how to contact us. The other is Hamel and you can view the links to subepics that are actually in that link there. So I encourage you to take a look at those. And most of the issues contain small chunks of work that are really great for first-time contributors. So if you want to jump in and contribute to GitLab, this is a really great way to do it. Great way to meet folks on the team as well as work through some really diverse areas of the product. So with that, I turn it over to you, Sam. Thank you, Jeremy. So this one's a bit of a question for Ray. Do we have 10 minutes to go through a quick demo to show how quick these things are to pick up? No, I think it would be great. I mean, we've got like 15 minutes left on the call, but even if we were to go over, I think this is completely worth it and make good reference. Okay, so hopefully this will take us down to 999 issues, right? We all know the song about bottles on the wall. So I'm gonna go back to the Hamel migration epic and just open that and go from there. Let me just move this zoom thing out of the way so I can actually change tabs. Here we are. So yeah, you can see in here, we've split it up. This is the main epic that tracks everything. I've split it up into different components, so alerts, pagination, buttons, et cetera, et cetera. There's some FAQs and things down there, but then if we go into alerts, this is a specific that has 58 issues and each one of these is a file where we wanna actually move something. If here's one I assigned to myself earlier. So in each of these, there's basically the same description because we're basically doing the same thing for every single one, right? So the title tells you where to look. So this is the file we need to replace the instance in. There's some instructions to say, here's what we want you to do. There's a class name, mapping guide. So this maps all of the bootstrap classes to the GitLab UI classes and then there's a little caveat here for dismissible alerts which we'll get to in a minute. So the instructions, take a screenshot before, replace each instance of the alert classes. Make sure it, I need to change the wording on this actually. So this says make sure it looks the same as it did. If it looks the same as it did, we've not done the right thing. It needs to look the same as it should in GitLab UI and in the design system. Take after screenshots to show that it's looking like it should and then open an MR with your changes being sure to include both the screenshots. So it's pretty straightforward. So this particular one is in app views project branches new. So if I go, this is my local environment, if I go into a project and repository branches new branch, it's on this page. It's not showing up right now so we probably have to trigger something. So if I open that file, let me just copy this and window, here we are, here's the page. Yeah, here's the alert. So if error, so we need to trigger error to see this alert. So if I go back here and say branch with spaces, then we should, yeah, there we go. So this is the alert that we're trying to change. So take a quick screenshot of that just so we can see. I'm gonna, I don't know if I got my own face in that screenshot or not, we'll see what Zoom does. Okay, so yeah, this is what we wanna change and we wanna change it to the GitLab UI alert here. So it wants to be not a warning, but a danger one. So this is what we're trying to change it to. So I've done that. I wanna replace each instance of the classes using the map. So what classes do we have? We have alert and alert danger. They map to GL alert and GL alert danger. So nice and easy to change. GL alert and GL alert danger. Now this should get us most of the way. If I just refresh that, yeah, there we go. So we're most of the way, but as you can see, this is not ideal just yet. This is not right and we're missing an icon here. So we need to do a little more. If I jump back into the issue, there is a thing about dismissible alerts. So this is slightly different to what we have now. I can just copy this though and put it in here. So this white space because it's Hamel and white space Mars. So this should, in theory, I should fix our cross. There we go, we've got the right cross in there now. We are still, yeah, we're still missing this. So this is where I would dig in to get that UI and just go into HTML here and look at what we're missing. So we don't actually have this icon part here. So I know this is written as actual SVG stuff, but we have a helper for that in our Rails app and we're using it for the close icon here. So I can just copy that and put that up there. And then we have these two extra classes here. So GL alert icon and alert icon no title. I'm gonna go ahead and add them in here to the CSS class thing. We should, it'll be the wrong icon because I've not changed the icon, but that should show up on the right side with the right color. It does, fantastic. What icon do we want? It's not the information icon, that's for this one. It's this icon here, which I believe. I think it's the error icon. I've got to get the SVGs. Here is get the SVGs. Is it this one? Yes, it's this one. I think it's error, is that the right one? Yeah, it's error. So all we need to do is where we've asked for the close icon here, that's for the error icon. And that should, that looks right to me. What do you think Jeremy? Does this pass UX review? I believe it does, the only question I would have was margin top on that below the breadcrumbs and I'd have to look into that to know if that was part of the component or the breadcrumb. And then I think you're still in the master branch, but that's... I am still on the master branch, that's right. Yeah, so I will take a screenshot of that. So I don't know the answer to the margin question. So we'll put it in the MR and we can take it from there. I would agree. So if I get rid of that, let me just grab the issue ID from there and do... I mean, you don't need to watch me create a merge request, I guess, but this is the point. Like in 10 minutes, we've done... And this is one of the harder ones because this is one of the hammer ones, right? We've not got the benefits of all the loveliness that Vue just gives us out of the box. If this was a Vue one, we'd literally just be changing the name of the component, right? Oh, we're in dark mode. But yeah, so we would just include them two screenshots inside the screenshots here. And they should be on desktop. So there's our before and after screenshot. I don't know which one's which. I've got no wrong way around. I'm not gonna fully submit this because I'll need to go through and fill out all this information and stuff. And no one wants to watch me type all that. But yeah, at this point, I would then submit it and assign it to the relevant people for review and make sure that I've gone through all of these conformity and things that we have for GitLab General and go from there. And then that'll automatically close that issue as well when it all goes through. So you can see one of the harder ones with it being the hammer one, it's took what 10 minutes and we've got one done. There's a lot of these, but they're all pretty small. So if you're looking for something to pick up that's relatively quick and you wanna get a contribution at GitLab, these are a great way to do it. Check out both of the epics that we have here. And yeah. There's some contributing tips here. I don't know if you wanna go over these, Jeremy. I think you wrote these out. Yeah, sounds good. So the first thing is just read the migration tips and troubleshooting help in the epics. A lot of those have steps and errors that many of us have encountered when we're going through whether that's updating spec tests or other pipeline issues that are related to these changes. There's a lot of troubleshooting help in there as well as just examples of if you're migrating one type of button to another, what elements to change, what are available properties. Second thing is to follow discussions and solutions in the issues and merge requesters. There's a lot of help that's already kind of laid out. A lot of grounds already been covered in some of these. And so it's just a good reference point. And then lastly, just picking the right people we're totally willing and available to help. So you can reach out to someone on the front end and UX Foundations team. I can update that slide to have the address. But if you go to basically do the GitLab team page at about.gitlab.com slash team, you should be able to search for the department for front end and UX Foundations and reach out to any of us jerks on there, myself, Tori, who was not able to join in. And then also you can find Sam and reach out to him as well from the Hamilton side of things. So yeah, I mean, that's about all we have today. As Jeremy said, if you have any questions, if you need help going through things, then reach out to his team or myself or a lot of people at GitLab can probably help you out as well. I don't want to say reach out to anyone because I don't want to speak for everyone, but we're a pretty helpful bunch. So yeah, happy counter-reviewing. Awesome. I mean, this is perfect. Thanks and I appreciate the demo. I mean, there are a couple of like community members I was thinking of that are pretty interested in a lot of front-end side of things. I mean, one person's in Asia Pacific regions, like in the wee hours and the other person's in Eastern Africa. So I'll, once the video is posted on our YouTube channel, I'll make sure that I send a link over to them. So hopefully, I mean, one of those persons in Asia, he's been contributing during hackathon. So I'll try to make sure that this is something that he takes a look at. And hopefully, we'll see more MRs. Yeah, thanks very, I appreciate that. And this is something that, you know, even if you're not particularly a front-end engineer, a lot of these things can be picked up, especially the view ones. There's quite detailed instructions in all of these issues as to how to do things. Some of the view ones are a little more detailed because Tori's been doing them and she's much more detail-oriented than I am, I think. But yeah, no, yeah. All the help we can get, we will absolutely take it. Awesome, all good. Thanks all for your time and we'll see you around. Yeah, thanks. We'll see you around. Thanks.