GitLab UX Team, 14 Jun 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Merge request widget framework: Feedback request

Description

This walkthrough of the current merge request (MR) widget framework provides a quick overview of the current state of the framework in order to kick off feedback.

The merge request widget framework synchronizes a wide variety of merge request (MR) widgets that serve many purposes. By systematizing attributes like layout, hierarchy, and content regions, the widgets will be more consistent, scannable, and utilitarian. Widgets will better adapt to page layout (responsive), and future widgets will have patterns to follow. The framework provides constraints where possible, but ultimately a widget's unique purpose should define the extent of how it's applied.

- Epic: https://gitlab.com/groups/gitlab-org/-/epics/5710
- Visual design issue: https://gitlab.com/gitlab-org/gitlab/-/issues/328245
- Design file (Figma): https://www.figma.com/file/iztE4TfG4le33QfROEhWaM/UX-OKR-F22Q2-MR-Widget-Audit-and-Exploration?node-id=0%3A1

A

Hello, my name is jeremy elder, I'm a staff product designer for the ux and front-end foundations team at gitlab, and this video is just a quick walk-through of the redesigned. Merge request. Widgets epic specifically focused on the visual design piece, which I'm working on there's a framework that I will review. That is in process, and I will highlight some of the areas that we are requesting feedback on. So, let's jump in first off here you can see the redesign merge, request, widgets epic.

A

I won't spend time going through this I'll, provide links in the video notes that you can jump to any of these items and specifically, what I'm tackling is the visual design aspect of it, and the purpose of this is to create unity and a synchronicity between all of the merge request, widgets I'll jump in and explain more of that in a bit.

A

But the scope of this involves the structure, iconography actions, visual design, content, lots of bullet points here that you can also explore async I'll try to keep this as brief as possible, so I'm going to jump over to figma once again this this file will be linked, and this is where you'll be able to add most of your comments and feedback, a quick structure, overview of the file, the cover with the explanation link to the epic the status is in progress.

A

This was uh born out of an audit of all the applicable, mr widgets, that we're covering and also have reference for, not included widgets. Once again, I'm going to skip at a high level through through this file, so that we don't have to make this longer than needs to be.

A

But you can, if you jump into this file, you'll see screenshots from different, I believe, there's nine different, uh merge, requests, widgets and different states, etc. Of those that have been used in consideration for design updates. As part of the audit, there was a learnings, a summary that ian had put together and you can review the notes and the synthesized action items as well.

A

There's a design exploration area where I explored the items that were mentioned in the uh the visual, uh the visual issue that covered off on these items- and this is just purely my exploration around spacing- and structure and hierarchy, indentation, a few different options, iconography status, etc.

A

So at any point you need any background or want to go through the file and check any of these sections out. Please do all right, jumping forward components. As I was building out the framework.

A

I started to also build in components so that any updates would propagate don't have to go through and make changes to multiple instances so try to make it easy on myself and anyone else also just a precursor to future work where having this as a resource and figma. Anybody should be able to take these files, these components and quickly, spin up what uh a new or existing mr widget would look like in a very variety of states, statuses, content actions, etc.

A

I'm going to skip over this framework for just a second.

A

This is another reference file. In fact, I will just rename this reference as we speak here. There's some work ongoing for the merger quest widget, which is not part of this audit. However, it's great for reference, material and directionally contains some of the similar aspects that are being explored here and, lastly, there's a review exploration file. This is empty at the moment or page.

A

I should say this is empty at the moment and as part of the ask for providing your feedback, I've just created a space here, a page that if you need to explore anything on your own, take what exists and say how might we or I have this scenario, then you have a place to do that within the document for context, uh so we'll jump into the merge request, widget framework, you start here, feedback request.

A

What I would like feedback on is specifically anything in here. So that's not very specific, but you get the idea items that you like don't like or have questions about. uh Please just drop a pin on there, it's as easy.

A

As hitting the comment field or the c on the keyboard, and just hitting that dropping a comment, what I would ask that, if you have suggestions or questions, concerns, please link to examples and and fully explain, reasoning or a background if necessary, like I mentioned earlier, if you'd like to explore on your own, create a frame under that review exploration page, that would be a great place to do that.

A

And, lastly, if you need to invite others to this file, please ensure they only have view access unless they're already a paid seat under our figma account. That way, we can manage our licenses appropriately.

A

Some of this all right so the framework- let me just zoom out really quick here. What you'll see in this document- and this page in particular, uh is a frame that covers the framework and then there's some exploration or examples at different break points. There are five different scenarios.

A

I've laid out here: I've taken existing merge, request, widgets populated the content, based on what was captured in the screenshots from the audit put it in here, formatted it, and that way you you should be able to have a quick example of what your merging quest widget should look like, or could look like under this framework and that's a great opportunity for you to kind of kick the tires on that test, that out and see what works and what doesn't work for you. What scenarios are missing, etc, all right framework.

A

Here we go all right. The framework I'm just going to read this really quick. The merge request, switcher framework, it synchronizes a wide variety of of mr widgets, that's their many purposes, and so by systematizing attributes like layout hierarchy, content regions. The goal is that the widgets will be more consistent, scannable and utilitarian.

A

Widgets should be better able to adapt to page layout, responsive and then future widgets will have something to uh patterns to follow and to build on, and this framework provides constraints for possible and ultimately, a widget's, unique purpose should be. You know, should define the extent of how it's applied. The goal here is to systematize and make everything as universal as possible.

A

However, I understand that there's going to be and and are widgets that have specific functionality, use cases that that may fight fall outside this, and so this should be ultimately used for a framework, but keep in mind that if something doesn't align, there is liberty to within reason to to go outside of these bounds for a specific component when, when necessary, so the layout section here, you can take some time to read through this, but high level. Widget is more of a grid.

A

uh Think of the a paradigm event inbox where you have a list of emails and you have the status of red and unread and starred you have the subject. You have actions that you can take on these. This is a very similar paradigm in the mergerquest widget area, where there's items where there's three levels to this and there's a hierarchy and there's a status and a subject and actions you can take so in this grid layout left column.

A

Here there are three levels: there's the parent level of the widget, which is always visible level, two and level 3 which are nested underneath and we'll get into more of that in a bit also in figma. These sections are linked. If you just want to jump to them in the document for quick reference, and then there are three content regions so uh column wise. We have the status the subject and actions level three doesn't have any related actions. Anything that's within a level three happens within the actual subject.

A

Content and you'll be able to see that through the examples, so you can go through that cover that off grid grid has our base 8 scale from pajamas to align all of the elements within. So you can see a little legend here of how that works.

A

If you have any questions, you can go to pajamas and in fact, I'll I'll make sure to update this with the link to pajamas to the spacing scale where you can view that and see how that's applicable, taking a look here at responsive, where the smaller viewports use a little bit of a reduced padding to hopefully get more more text in there there's a little bit of a balance, and you can feel free to weigh in on this, where reducing the content on a smaller device means that touch targets can be closer together.

A

So think through that, as you evaluate it and and see what might be comfortable or if you have suggestions, I would love to hear that, let's see, there's some information about the responsive, overflow is tbd uh and if you have an insider work on a widget that has overflow, I would love comments and feedback here right now, there's a like a max height for the secondary or level two area and within that, if it overflows it scrolls so we'll be building this out as we go and learn more there's a section for hierarchy now so start with the container.

A

This is the item, the object that wraps one or more widgets. So it's a simple frame, etc. It's got the border contains them level, one, the primary level level two secondary there's a few options here, based on the attributes that can be turned on and off in figma, so referencing the the component. You can see here. Okay, it's a level two, a full border means it's the first item, any n, plus one as mentioned in here, has an inset border.

A

I'll show that, in the examples how that works- and so these are built out just to have different options and and make it extremely easy to build with these and use them level. Three very similar- you just have the options that are there, so that covers the levels as part of the hierarchy. Next is the content regions there's three content regions, there's the status, the subject and the actions broken down that way, just to have a concise area that we can reference and talk about it.

A

So if we say you know this happens in the subject, we know where that content goes. If we're talking about the status level, it's easy actions, etc. The status itself there's three levels at level. One is primary and it has this highlight and this extra visual weight so that it provides more of a visual anchor and a visual cue. As someone is scanning through a merge request page, these are designed to be able to stand out more and and highlight that actual parent level status.

A

That's based on the status of of sub items when present a level two to three general status. These apply to most mr widgets level, two to three severity, so anything like security that has uh that uses a critical high medium scale. That's where these statuses can be present next up is the subject within the subject.

A

There are description, title the content and meta information, so you can see here. I've just included examples of different formatting, so there can be inline links, highlighted text, meta information, that's a little smaller and lighter a badge if there's a like a system generated status like there's a new item, etc or or if it's dismissed. Something like that can be part of that here. You can be begin to see the indent and, and the purpose for that that I mentioned above in in level two where this is a nested item.

A

It's another level two item, but this nesting helps tie it back to that parent. When everything has a border, that's edge to edge you, you tend to lose that hierarchy a bit and that relationship because then you're, just basing it solely on a background color. This helps to inset it and help with that hierarchy and then, lastly, for a content region is the actions and within that uh I can update the the little points here. It looks like they got off a little bit, uh but there are. There are there's an info button.

A

A download, drop-down text link text link has actually been removed, so I will replace that uh tertiary button and expand and collapse the from a component standpoint built out the actions to account for everything that was visible in the audit. So if there was information, if there's downloads, if there were actions, expand collapse, all those are counted for in here.

A

So, as you build out widgets and go through these, these are designed to be plug and play turn them off turn them on etc as needed, and then, lastly, accessibility, the accessibility section is, is tbd once we button up the framework a little more and the reason for that is because, uh with that, I'm going to outline the roles like the actual aria roles, keyboarding content for screen readers, what I call the content behind the content that will all be documented and outlined in here as well, so that during implementation, it's development has a a baseline from an accessibility standpoint.

A

Is how how to implement these, how these should be communicated and announced to users of screen readers and and keyboard users.

A

All right the examples I will zoom out really quick here.

A

But the examples like I mentioned there are a few different layouts and those just account for different points, different break points in gitlab, so we have a anything under 576. We have a 576, a 767, etc, and also I've accounted for the navigation in here. So if you were to go in here, double click on this nav right, you can see. Expanded is off. If I turn this on, you can see that this widget content responds to that at that break point.

A

The reason I wanted to include this is because you might design at a mobile layout, but then at a larger break point you actually have less space when the sidebar takes up that content space, and that's the case here where, as you can see, this now becomes something that's more akin to mobile. So it's just a way to stress test this and understand that, because we don't have container queries and we're relying on break points right now, we want to make sure that all of those scenarios can be accounted for with the navigation.

A

The fixed layout is well. I I apologize. I will jump back really quick here and I know I'm going through this fast, so you can watch it at half speed if needed, but security and down you'll see are listed. I have an example of each widget that was covered off in the audit.

A

There's an example of it in here and it's in the expanded state just to give a feel for how that content might look and, at the very end, just to combine you know, combination of how they might appear collapsed together, not all of those just a subset of them at the smaller break, point, etc.

A

Jump up to the next break point same thing, just giving you an idea of how these work, how they function, how they reflow, where you can begin to see how some of the rules in the framework play out as far as truncation and then, if we go further once again, the other layout that now we have a different breakpoint and so the the additional padding is introduced, the truncation changes uh and then up all the way to our fluid layout. So you can actually see you know how. How will these work?

A

If you have a very large screen and actions might become far far enough out in the peripheral, so that should cover just about anything and everything in here. uh Like I mentioned I'll link to the files, the primary ask is that pm's designers, anybody that has a stake in these merge requests, widgets jump in and begin to comment and identify areas that work that don't work, things that you like that, don't that you don't like things you have questions about by all means.

A

You know attach screenshots of edge cases that might not be covered under this review exploration. That way, we can come back and and reassess that the goal would be to have a weak timeline to capture feedback from there to go through that feedback uh update, make any update to the framework and and componentry in here as necessary.

A

Do solution, validation, button up the framework and then release it for development. If you have any questions once again, please feel free to leave them in epic and the issue. Thank you for letting me speed through this and best of luck. Thanks for your time,.