GitLab UX Team, 24 Aug 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Paper Cuts Settings Review

Description

Sascha, from the UX Paper Cuts team, walks through recent work he and Annabel completed for Settings throughout GitLab.

A

So awesome, so we are meeting today to discuss uh or just to review what paper cuts has been working on for settings over the last two Milestones. So this Foundation starts to to jump into working more in depth and settings.

A

I thought it would be really helpful to have some insight from Sasha and team on what they've worked on and I think Sasha. You mentioned that yesterday that you encountered a lot of things that actually I think this was your idea. So you've encountered a lot of things that uh would be helpful for us. So.

B

C

Yes, yes, um let me share my screen quickly.

C

D

You see my browser.

C

Window perfect, all right, um so I don't want to bore you with. Like all the consistency changes we did, um but just focus on maybe the biggest changes we did in the in the last two milestones.

C

um So the first thing was the addition of uh sticky sections. So some of the settings Pages we we basically eliminated the accordion element and introduced sections uh with like sticky sections.

C

um So you know, like the the title of each section, would be sticky as long as the the section is is visible, and we also introduced like a sticky footer, so that the save changes button, for example, on some settings pages, is always visible, so the user doesn't have to scroll all the way down to do um or to save changes.

C

We couldn't introduce that to all settings pages, so we only introduced this setting or this style to settings Pages where we were able to remove the accordions, um because we have a lot of settings pages in on the project level and on the group level, which have like a ton of different forms and each form can have a safe changes button right. So we have some auto save settings and then we have some which requires a save button.

C

um So this it's itself might be one thing to look at how we can solve that that little mess in in settings as a whole, um but yeah. This was the first edition.

C

I think it's best shown here on the settings preferences page um and then the the other big part was that we, let me go here um so for all the pages which still use this accordion Style.

C

um We we changed like the um the description off of each section to use um jail, Tech secondary, um so just to be more.

C

um You know like consistent across the board because there was a mix of secondary color and not. This was a subtle change, but was changed through all the settings Pages we have uh in gitlab and then the bigger change was to introduce.

C

um Maybe it's best shown here in the repo settings um to unify, like the the the appearance of managing content within settings right to use like this new GL card Style um just to to unify the experience of how we show items uh in settings and also to this is a not a good example.

C

Maybe this is a better example yeah, um so to have like the the ad form so before we had like settings where we intermixed um actual settings like toggles input, Fields with like an ad form, um and there was no break between okay, what is actually which are settings and which is like the ad form itself.

C

So with the introduction of the this GL Court, um you know name to be defined in the future of this component um as we discussed yesterday. But then we have like a single approach, how we display um those additional content in settings and how it behaves with adding content and managing content um being deployed. Tokens has another one and deploy Keys has also one so.

A

C

Now pretty consistent across the board.

A

Yeah, it's actually jump in here. The the reason if I remember right that you did this was that under the the previous state, you would have to actually navigate through the form. First before you even saw what you had created for settings. So this kind of flips, the Paradigm, where you see what you've already set and then you get, then you can take an action to see the form and be able to do additional information. So this reduced the um the.

C

A

It took to see what your settings were and it made the action more meaningful, I think right.

C

Yes, um so that that was that that is 100 correct, so um first, like a good example was web hooks because it has a pretty long um ad form. So if you have like a smaller screen, um this is a pretty big one here, but if you have a smaller one, you would never see content at its first glance, you would always be welcomed by the ad form.

C

um So if, if you go to settings to manage content, you will never see that content right, because you would always be greeted by the form secondary also like. If you rely on keyboard, like for accessibility reasons, for example, you would have to go through the whole Forum before you actually access the content, which is there and with the introduction of that component, we actually see at the first glance the content, and um you know, users don't have to go through the whole content, like the whole ad form before they see the content itself.

C

And the third reason was that, as I mentioned, like managing those parts uh in settings, we had a lot of different paradigms, how we actually display them and how to add, content and and how to remove content and stuff like that. So we try to uniform the approach um used across like settings UI with like this to be defined. Currently a GL cart, custom implementation. We have um so yeah that that that were basically like the the bigger changes we we did across the board in in settings. Ui.

A

Yeah just a question like the ability to add new before seeing what exists just in the keyboarding and focus order. I was curious like if there was exploration on like you get to the bottom of the list, and then you can add a new one to know that it's going to be appended to that or like was there an exploration on on some of that interaction.

C

um Not really, we, uh you know like we were pretty time limited, so we just scamped the product of, uh and also like, you know, like the design system, of what components do we have available today and which would be the best to use for our use case, and this was basically what we came up with.

C

um So there was no research involved in this decision making.

A

C

Yeah I think this sums up like the most important changes. There were a ton of small changes, but I don't think you like in the summary they filled up, maybe a milestone, but um I. Think like these are the bigger changes we did.

C

Oh I forgot one change, let me see where we actually can see it, um so we did another change where we we actually started to limit certain um field, lengths in like the width of input fields, for example, because um in a lot of different areas um in settings we basically just use like a hundred percent with for input fields or drop downs or whatever all the time, even if the the actual required input might only be one chart or two charts, so we actually tried to make use of uh what actually is defined in pajamas right um to have like the different sizes for for input Fields like the small, medium large axle sizes.

C

So I don't know if in mind where we actually did that, but it were like different parts of settings where we came across. We we tried to implement that Paradigm as well or to make use of that.

C

Maybe that helps as well.

A

Yeah yeah, so you've shown examples from both user settings and uh project like uh like what was your approach to unifying like across, like the different levels of settings or different types of settings, we have.

C

um Like I said we we didn't do any or we try to avoid any high level changes. So we did not touch like those overview page like those settings Pages.

C

um You know like to change like the accordions on those pages, because in itself these settings pages are very long and um you know they would need a more holistic approach, uh maybe to to tackle or like to to change um the the reason why we we actually introduced, like the the sticky headers here, for example.

C

um These are Pages which use the side-by-side layout. You know which had like the section title on the left and then the content on the right, and we tried to simplify those pages, because we were in alignment that um you know, especially with the introduction of the of the Cyber navigation, that doesn't make sense to use that layout.

C

um So we wanted to get rid of the two column layout in settings and we replaced those instances with um you know like the sticky sections instead, um so that was one of the more conceptual changes with it. But we didn't want to go further and you know like touch those you know, settings and and and group pages um as a whole, but it only made changes to the sections itself, not to the pages.

C

Does that answer your question at all? It does yeah yeah.

A

Oh absolutely yeah yeah a lot and I know that we've covered a lot of this too, but just for the posterity in the recording and having it having it down. I thought it would be helpful.

A

um You you did mention uh when we did when we ducked before that there were just some things that you and Annabelle ran into. That would be just good like helpful to know I'm curious what uh what some of those things might have been yeah.

C

So when we, when we did some research on um you know, we, we searched a bit through Reddit and social media channels and stuff like that, just to get an idea of feedback around settings, UI and also like searching um you know like in issues like older issues um and one of the things which came up quite often or like uh multiple times, was that it's very hard to search through settings, um because you know if you're in general, you only search through the general settings and not integration, web books or whatever.

C

But maybe you don't know that a setting um you know like is part of general or like another. You.

D

C

Like another section here, um so it would be beneficial to to have like a global search um example, if you're in a project that you can search through all the project settings.

C

um That was one of the things we saw, but you know that was like out of scope because it was a big big change and needs more. You know, like yeah I, think, like a whole holistic. Look at things um because currently how settings is built, it's not possible to introduce that right.

C

um So that was one of the things, um because there are some overlapping things like uh you know like in merch requests or general and and which you might not know where settings are located right. So it's hard to find those.

C

So that's, maybe something um you know to note down or have a look at. You know the the discoverability of settings.

D

A

um I have a few more questions, but Dan or Chris wanted to give you time two to ask anything that might be on your mind.

D

um That's that's the major thanks for um walking through them um through the changes. I noticed in advanced, looked quite different um as well on this one.

D

um Could you maybe talk through some of the changes that happen there because they look like they use the things that look like the cards where you add stuff, but there's no add-in stuff in there.

C

Yeah um so you mean Integrations, for example,.

D

Oh no in general, advanced.

D

Sorry, oh yeah, there's a big red thing that used to be at the bottom as well.

C

um Yeah I think Austin is not here right. He would maybe be interested in that. um So there's a long story around that advanced section in settings and how we um you know, could improve or remove like the the alert style like the custom, other style, which wasn't an alert and stuff like that.

C

um So that was one of the last things we we tried to to see. If um you know we could use the cards here um just because we use that that component quite often in settings, so it was on hand to to make use of it here as well.

C

um Now that it has to be like that, but I know that the advanced section popped up quite often um that it needs some change. So that was like just our approach to to try to clean up some things, um because there were a lot of different elements used in this section, and now we just use like a single one for everything um not saying that this is the best approach, but it was just you know, on hands to to to make a change here as well to clean up things.

A

I notice on Advanced here, like some of the card headings, have the description in them and and some have the what seems to be a description in the body like because was that intentional.

C

um That was just kept as as it was so um you know before we had. um You know like some elements which had like a description and some did not have one, so we just kept it, as is um so. That was basically like a one-to-one translation from what we had before um twos and carts.

C

um So no I mean this. This could be changed easily, but uh we didn't want to to go any further down the rabbit holding in the advanced section and just you know doing the.

A

A

C

B

Maybe we can quickly.

C

Well, we were now in projects- and this is the groups section that let me know where we have it. Advanced.

B

Project settings here.

C

So, just to show you maybe like how it looked before.

C

So this was what we had before right, so we had like this custom element here, um then some other so delete this project hat like this other custom styling, which which looks a bit like an alert, but it isn't and stuff like that. So we just try to clean this a bit up and because we use the like this new implementation of card quite often in settings it. It just made sense to clean these sections up with with that component as well.

D

What was the hardest thing about working in settings.

D

C

It's the hardest thing is that, once you start changing things, um you know you will discover more and more and more so.

C

um You know like when we first scheduled, like our the first Milestone or like the Milestone we wanted to to work on settings UI.

C

um We just started at one in I think in Project settings and then we discovered so many things we could change or align um stuff which uh were incorrect um stuff. We could migrate.

C

um You know like uh components which don't use um or like loose components: um bootstrap styles that were just like I think just it's just like overall, a bit a mess because, like you know, like I, think like all like almost all groups Touch settings at some point- um it's just like wild west in settings currently um and then, when we started like cleaning up things, we just saw that we need to add another Milestone, because um after the first Milestone we did clean up some things, but we couldn't reach an end.

C

So the state after the first Milestone was basically an even bigger mess than when we stored it, because we introduced new things and we tried to clean up. But we couldn't, you know like do everything in one milestone, so that's why we added another one to at least um you know clean the stuff up.

C

We we already started working on, so we could have at least like you know, like finish off some of the work, um and then we actually discussed if we want to add a third Milestone to it and um yeah, and then basically, we didn't knew that foundations would have a more holistic view on settings itself, so it wasn't worth like adding another Milestone to it, and here we are now right, 64., so.

C

Because the problem I see is that you know like, for example, like um Fields.

C

um There are like a lot of fields which which do not use like uh components from gitlab UI, for example, um or there are a lot of custom, implementations and settings and stuff like that, so yeah I think one thing would be to to migrate and clean up things, and then we also have like this different approaches.

C

um You know like settings Pages like this, which have like the the or Court like the accordion feature, um and then we have other settings Pages which have like the side by side view which we eliminated by now and um yeah. There were some other custom implementations as well um in in different areas, so.

A

I know we're we're at time, but I'm curious. Since you you mentioned that multiple groups, you know pretty much, every every group has settings related to it. What was your approval process when you made changes specific to a group.

C

um Yeah we like in the beginning the the first change that we did was was just clean up, um so there were not a lot of approvals needed um when we dig further into uh like you know like changing, like the the situation of of having like those ad forms and and content lists within settings.

C

um It was not all the time clear who is responsible for for those settings. So some of the things uh or you know we- we have like a lot of groups which don't have like any um assigned designers at the moment as well. So these we uh for those things we just went away ahead and for others we we actually pinged designers to to be aware of changes um or that we made changes, um especially like in in merch requests and and other areas where we knew that people are also working on.

C

um You know like over, like overhauling some settings so, but we can do better I think um you know that was one of our read in in our Retros in in the retrospective um I.

C

Think um you know we it's it's always a bit of trade-off, because we we don't want to Ping too many people on our changes, um because uh you know I think it can get quite busy when, when we work uh in a special in a on a theme um but I know, uh on the other hand, we also want to raise awareness right that we do changes in in other people's ballpark.

C

um So yeah we're we're still trying to find ways how we, how we can improve that as a whole, not related to settings but as general for paper cut work um so yeah. Maybe that answers your question.

A

Yeah, it does yeah um I guess if you have a second I have just uh maybe one well one one more question, and maybe two if we have time, but uh are you good with that sure all right, I I was curious? uh Did you involve Tech writing at all, or did you make any copy changes or or content changes.

C

Yeah we did um so we did some minor changes. um Whenever there were, like um um you know, changes involved. We we picked Tech writing as well.

C

We didn't do too much to be honest, um I think we removed some more or less publications of health tax uh throughout like settings UI, um you know, because sometimes you have like a help text right in the description or like in the summary, and then you you would have like another help text right below that when you expand the section and it would be more or less the same, um so we pinged Tech writing on some of those changes or if we wanted to merge multiple texts into a single one.

C

um So yes, Tech. Writing was also involved in, in some cases,.

A

A

uh Cool, maybe we can there's something we can add. Async I I think it's probably a deeper question, but I'd love to know more about like what other than the card component. What components were helpful or not helpful, or you know things you ran into, but um I know we're doing some work on the cards separately. That we've discussed so I'd be interested to know more about that. But um maybe we can take that one async. uh Does anybody else? Have any questions before we close out.

D

A

You again scheduled.

D

For a long guy.

A

So don't panic too much, oh good, good good! All right Zoom is showing like count up, but no countdown I guess I can I should try to change that. There we go time remaining. Okay, thank you. Yeah I would love to know more about. In that case, thanks Dan I would love to more to know more about like in addition to like card what other components were uh critical in the effort.

C

As I mentioned like there are a lot of, like you know like things which are not tied to components in settings UI, um so those are things we try to eliminate um or like stuff. We we tried to to migrate towards, like um gitlab, UI components which were not used yet, um but I think there. There are like some there's a wizard somewhere in settings as well. uh Don't remember where it was, but.

C

Yeah and just like overall, like the the Paradigm of like the the difference, setting sections behave differently um like I mentioned before, like some of them have like a save button, some of them are like automatically saved um and, and these implementations of those forums are all a bit different.

C

um So yeah, like I, think the devil is like in those details.

C

um So in terms of components, we used I think like the most used component update was like using this GL card or updating whatever has been used to to um that instance of GL card um or like updating like different input, Fields or like form Fields towards, like um you know, like the the gitlab UI counterparts, um I, wouldn't call that a component but yeah as I mentioned, like the the other thing we introduced was the sticky header, sticky, footer paradigm, um which is currently solely living in the product.

C

um You know because it's coped to to the to the two settings, um like a lot of the other components which are used in settings right. This collapse, expands component is also like uh one I have only seen in settings UI, um so yeah I think I think it's it's very beneficial of Foundations having a look and what we could try to improve and streamline and which components can be used throughout. Like the the whole settings. Ui.

A

It's a really interesting uh topic, just about form, submission and the way forms are working and like auto, save versus manual. Save that's gonna, be uh something Chris that we'll have to think about with back end as well that we hasn't been on my radar, but that's really good to think through.

C

Yeah, like the the way it's it's built um or why some settings have like you know, like the all. The safe settings are usually migrated ones which use View um and then the other ones with the save buttons are still like handled. If um you know like JavaScript with like um jQuery or whatever has been used, um and each section sometimes have like a different back-end call, so I was told you know we have like a like a a form per section, because there are like different back-end calls um so yeah.

C

This is maybe something to to keep in mind, and then we have some settings for like only if you do changes the save button would show up. We have other instances where it's it's shown all the time. Then we have instances where the the button is disabled. Until you do a change and then you know it gets active um yeah. So there are a ton of implementations for those forms um within settings.

C

B

Yeah, it seems like we may need to do some kind, but it feels like our first step needs to be some kind of audit, where we can at least review, unfortunately review every single setting to see okay using the UI kit or not, and then some of these other attributes of okay. What is the sort of saving pattern? What are some of the other attributes that might be useful for us.

D

B

Because yeah I think um I think scope is going to be a big question. You know: are we really committing ourselves with the team to sort of refactoring every single settings? I said a lot of them like, of course we're not doing that commit to that. um So then, what's the yeah what's the way forward, there.

A

A good question because we also don't want to like paint ourselves into any kind of corner with like oh, this is our. This is how forms should behave, and then we run into some back end process that it's like. We can't change that, and so yeah that'll be it'll, be interesting.

C

Okay, um maybe one one more things like um um in our component: Library, we for form fields. We have like the prefix and suffix right for for like at least for input fields, so um this could also be beneficial if that would be used in settings UI for um at least you know like to, because we have a lot of instances where we we actually look for a certain input. Let's say we, you have to input like something in bytes or megabytes or I.

C

Don't know like what what uh units is being um expected and currently we we either put that in Brackets behind, like the the field label, or it's written in the description in the form description so could be an opportunity to to use like the the suffix, for example. For that, so you know not only if I don't know like.

C

If, if you can only input like two digits, we can shrink the for the form fields to you know like a reasonable width and then maybe you could also use like the suffix for that I think I I actually created like a year ago, or even longer than that like uh an issue for that.

C

um But maybe you know this is just a brain dump now, because we didn't have the time to do that: I'm even not sure if it's already, if the suffix is already available in gitlab UI or not for for input fields,.

B

A

Believe that it is but I don't I, don't think it's widely used.

C

Let me see if I can find the issue.

A

Actually, if I I'm looking at it in uh gitlab UI- and it does not come anywhere close to design specs so I'm, assuming that anything similar in the product is not using a component.

D

My suspicion is that most of our system work on it will be um in patterns and how decisions are made for settings um like from our Sasha was saying it sounds like things are in a a place where things are consistent within themselves, but not consistent when you take three setting screens and stick them next to each other. There might be three completely different things, but on. If you just look at one page at a time within itself, it's all there and I suspect. Some of that is from.

D

Not not having a one place to look for if I'm trying to get this type of thing, how should it be, and it's just matching within its pages, so yeah I suspects, that'll, be a large large part of our system output.

A

So well, we are at time so I will put this on unfiltered and and we'll have a record of it uh and if we need to schedule a follow-up with more questions. So if we have time to think through this I think that would be. That would be good too, but thank you for to you and Annabelle for all the everything you've done so far and for filling Us in like very helpful.

C

Yeah I hope I hope we, you know we did some improvements and not like vice versa, but um at least I think some of the cleanup was was necessary.

C

um Yeah looking forward to to the foundation work on on settings as well.