 It's top of the hour. Welcome everyone to the UX Functional Update. We'll just go ahead and get started. First, we have a lot of new people coming in to GitLab. So here's the list of the UX team. Tori, oops, I'm sorry about that. Tori, Sarah, Chris, Dmitri, Pedro, Hazel and of course myself. If you're ever in an issue and you have questions for UX or you think UX should be involved, feel free to add any one of us in those issues and we'll take a look for you. First, we're gonna go over the improvements being made in 10. First up, uniquely GitLab icons. The UX team is continually working to better define GitLab's unique personality. When you look at any screen, you should know immediately that this is GitLab. Iconography is a powerful visual cue to the user and is a great way for us to reflect our particular sense of style. Hazel has worked her magic and designed a whole new set of GitLab icons. These icons are being displayed using SVG Sprites and eventually we'll completely replace Font Awesome. We're starting with system icons and general icons and then moving on within probably the next two releases we should have replaced all of Font Awesome icons completely. Next up, we had a lot of feedback from users that the expanded sidebar on smaller screens was confusing. It overlapped the content and it felt like a bug because you weren't actually able to interact with that content. To fix this problem, we added a shadow, the same that we use for modals. Yeah, same that we use for modals to the sidebar when the contextual sidebar is expanded on smaller screens. If user clicks the page content, the sidebar will collapse. If you expand the screen to a size where the expanded sidebar fits, the shadow will disappear. We also had a lot of requests to change or the option to change navigation color palette. It was one of the bigger requests that we had from users both in the feedback issue on the blog and hacker news, pretty much across the board. Previous versions of GitLab that allowed users to customize the navigation sidebar with a color theme. It was a popular feature and many people actually used it to differentiate between their different GitLab instances. So the change to our new navigation, we had an opportunity to bring it back. Our default palette is still an indigo one based on the GitLab identity, but we now allow users to choose from a variety of themes under profile settings. The plan is to add more as we go along, but this is kind of our starter kit for the navigation color palette. So we also wanted to enable CI CD for all projects. That way everyone can enjoy the benefits of common best practices such as CI tests, code quality, review apps, so on and so forth. To accomplish this, we have implemented an implied GitLab CI YAML file where all projects which have CI CD enabled will use the implied configuration, even if they don't have one themselves. The implied configuration cannot be controlled or changed by anyone and it's rendered at instance level. If someone wants to customize it, the exact same file will be available also as a template. Can be applied to the project and then modified. The first iteration will not enable this configuration by default, but will make it easy to discover with a banner when convenient and enable it using a project setting. So we also improved share locking features for subgroups. When a parent group has a lock on sharing the project with other groups, this restriction now also applies to the subgroups. So you're able to apply a lock to a subgroup even if the parent does not have a lock. The subgroup is able to have a lock applied to it. Oh, I think I've worked that twice. I already said that. However, the subgroup will not be allowed to release a lock applied at the parent group level. So you're not in danger of undoing something at the parent level at the subgroup level. We updated the copy as well for more clarity and moved the option to the next two, the visibility permissions to make it more apparent and easily discoverable. We also made some improvements to issue boards. In issue boards, a list represents a label and all the issues in that list contain that label. The title of the list is the label itself, but in our previous design, the title was not styled to look like a label. Additionally, the label itself never appeared in the list. So it could be confusing to users whether or not that list correlated to a label or it just contained a mix of issues. It was very confusing. And the new design, the list title is displayed using the label style we use in the search box. The list title indicates it's a label, but it's not expected to be clickable. We've also added the label of the list back to the issue cards. For example, in this UX label list, UX label is visible as other labels in the card. This reinforces our purposeful label list design and the fact that Backwog and Dunn are two special lists that are not backed by labels. And group level issue boards. Group level issue boards are being implemented to help facilitate a stronger team-centered, product-centered approach to collaboration. In the group navigation, we have a new tab under issues called boards. It's analogous to the project level and a group board is the same in design as a project board. You can create, edit, delete multiple boards, edit the name of the board and associate a native group milestone with the board. There's a search bar in the board that can filter by author, assignee, native group milestone, not any project milestone, group label, not any project label and wait. Only issues in immediate child projects of the group are available in the group board. Only group labels of this group are available in this board. Project labels are not displayed in the cards and they are not displayed in the sidebar either. And this is a really, really nice, nice one. I'm very happy about this. Make projects and features visibility settings less confusing. So the view project settings was really confusing and not UX friendly at all. So Tori worked some magic and made some unbelievable improvements here. We're using a toggle now to indicate the enabled and disabled make it a lot more clear when you change the settings what is actually happening. The features were arranged into a logical order and we made project visibility visually distinct from the other features. We moved allow users to request access to the top under project visibility and only show it if it's public or internal. We changed the placeholder text for disabled features to enable features to choose access level. And we keep the green background that fades when changing project visibility. Moved access levels next to the feature toggle so you don't have to scan across the page to see the level related to each feature. And the container registry in LFS is now placed under repository and always visible like the other features related to repository. Also updated copy for private, internal and public help text to make it more clear exactly what that means. All right. So these are some other issues that we're currently work in progress or they have the UX ready label. It's kind of an overview. There's a total of 120 open issues in CE and EE where UX work is complete but don't already have a release milestone assigned to them. So one is multiple assignees for merge requests something that I would really love to have. Can I just let that in there? Now that we have multiple assignees for issues we wanna carry that through to merge requests as well. So here we propose to change the cannot merge icon from that heavy red to a lighter orange. It's also proposed that we should order the current assignees starting with those people that can merge in order to improve scannability. So this is sitting there. UX ready just needs to be assigned. We're also continuing to employ, I almost said employ to improve our empty states. So here we have an empty state for the geo feature in the admin panel, which right now is just a red banner that goes across the page. So the empty state obviously shows a much nicer visual explanation of what that feature is and how to get the feature. Exactly Pedro. So nice eye candy, right? And we also have these two as well for both projects and snippets. So there are three empty states that are UX ready. We just need to schedule those to get those into GitLab. Auto-generated issues made from unresolved merge request discussions. So when you create auto-generated issues from unresolved merge request discussions, that's a mouthful. We include the text follow-up from title. The user has the option to change the text but if they don't, we end up with a list that can be really hard to scan. Everything looks the same. So it makes it difficult to sort through different issues. We propose here that adding the first part of the first line of the discussion to that issue title in order to help differentiate between different issues created. The characters of both portions would be limited to around 50 characters so that they don't get too long. I think I featured this one last time. I'm gonna feature it again. It's still UX ready. So recently or a couple of releases ago, we removed the resize option for resizing comment boxes because of a performance issue and because we already auto-resize that form. However, when you edit a comment, the form does not auto-resize and there's no way to auto-resize the box yourself. It can be really frustrating. In this example that I give, there's a lot more content but this is as much as I can see and I have to scroll down in order to edit what I wanna edit. So we propose auto-resizing the edit form to allow the user to see the full message when editing with a max height of 500, which is the same as the current. There's another tiny change that I think could be really, really good is the inconsistent to-do counter when to-do counter is zero. And I believe Clement found this one. The to-do counter is inconsistent when displaying a zero count. Sometimes the counter badge shows a zero and other times it does not display at all. We propose that the counter badge should never ever appear when the count is zero. It draws attention to it for no reason and the addition of the counter badge once there is something will reinforced its importance rather than having it there all the time or inconsistently when there's a zero. Any questions? Comments? Yeah, I know Bob. I don't know, you'll have to ask Clement because he found it. He added a zero somehow. All right, if there's no questions, going once, going twice. Shout outs, real quick. We just wanna put some, so shout outs out there. Special thanks to everyone that always helps the UX team. But here's just some people that have helped over the past release. And I do wanna give a special shout out to Luke who's been working really hard on the marketing side with a homepage redesign and putting together pattern library for the marketing side. And he's reached out to us quite a bit and asked for our input and collaboration and we just appreciate that so much. It's been a delight working with him. So thank you, Luke, we really appreciate it. And if that's it, I'll let everyone go. I'll see you on the team call. Bye everybody.