GitLab Design Reviews, 24 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Dev Manage:Plan:Ecosystem UX Design Review — 2021 05 24

Description

— Icons for compliance pipelines (Manage:Compliance)
— Collabjects exploration (Plan:Project Management)

A

You only uh you miss the shots. You don't take right.

B

Yeah yeah, so it gets all right um cool. We can jump over to the next point. Then um I was working through some ideation of how we visualize the difference between a job in the pipeline. That's inherited um through a compliance means and one that's just like created natively in a project.

B

Initially we thought about using an icon, and then we were doing some other exploration through some different states, kind of drifting back to the icon, but I've received some mixed thoughts around what icon to use.

B

Initially, I was leaning towards like using the shield, but then jeremy's like we really should just reserve that for the nav item for security and compliance- okay- oh maybe like a lock and libor was kind of on that train. But then nadia was like. I don't think the lock really communicates it very well. So I was just curious if you all had some creative ideas in terms of a better icon to represent there or a different way.

B

A

I want to push back a little bit, the um so use the shield for the nav item.

B

A

Wouldn't using the shield be one way of like drawing a connection that hey this: is compliance related or is it that it means two things: security and compliance yeah good thing to do.

B

I felt like it did also like tie them together, but I maybe I could further um dig into jeremy's thought. I kind of just took his initial thought and um ran with it, but maybe it has some the.

A

Lock, icon usually means uh you know that you're gonna have to take an action like enter a password or that it's um not that it's security related but that it's secured and so.

B

I it is like enforced, like you can't like edit it if that makes sense, so it is technically like a locked job like you can't make a modification to it and.

A

From who's whose perspective is it immutable? Who cannot make that change.

B

Well, the people that can modify it would have to have access to where the compliance pipeline lives, which would be in a different project in a different group somewhere else. So if you were.

A

To um if you were to accompany that icon with a label, what would the labels say or if.

B

You have it something I was a little biased towards leaning into is when you set up a compliance framework, you're creating essentially a label or badge for that framework. So I was trying to think of how we could reuse that property um in settings or in other areas to help understand like where is this coming from?

B

It's not just like the icon. The problem we run into with this pill in particular, is like it is a fixed width item and it already has so much of its space, truncated.

A

Is it important to communicate this at that level.

B

Like the um framework piece or the job name,.

A

Their framework piece is it important to communicate it at the pipeline status, the aggregate pipeline status level.

B

I I think it's important to be able to distinguish like what came from your specific project so like if you're working in gitlab. You want to know that these were jobs defined in the gitlab project, whereas this one could have been defined in the sox project. That gitlab is inheriting it from so they are coming from different places and just trying to inform users like. Why did this appear? Because, if you're a gitlab developer, you might not know where that thing came from. So I think the most important thing is communicating.

B

This is a foreign object that you didn't, probably define, or the people on your team didn't define, but you are required to follow it.

A

Yeah I I would say that on the the pill, the name is the most important thing. We already lack a lot of real estate for it and then, on the detail, view there's more opportunity to be to be more detailed, like not just the sox label, but it's enforced pipeline complaints. So on the on the condensed state on the pipeline pill, we're almost creating like more mystery and in in more questions that users are going to have about what is this, and why can't?

A

I see the whole name of my pipeline, so I would, I would say, for now, like not even put it on the pipeline status on the pipeline pill and put it on the um that table view.

B

Right in a table or in the drawer like where it appears yeah, what do you think holly.

C

I was needed and I went to reach for my mouse and just promptly knocked it off my desk. It's just very enthusiastic about this response. I guess um I actually I agree with mike. I think that the pill is such a small location and as a user, I would- and this is me I guess, projecting, but I would expect for it would it to be more valuable to be able to see as much of that title as possible as opposed to the icon, the table. You have more space in the drawer view.

C

Also um I I was taking a note when you first started talking, so I'm sure I missed this, but is what is the value again of having an icon at all.

B

Yeah, so an easy way that I could show this is if, um if you're looking at our pipelines today in gitlab, um let me look at lab: do some thinking here open one up into the graph, so you'll see like a long list of different job names? um If a project is inheriting a compliance pipeline, it's going to inject different jobs into this graph.

B

um Those jobs have been defined in a totally different location, not in gitlab specifically, and so you would see this list and probably some new jobs that you're not familiar with. I don't know where this job came from. It's not in my gitlab.ci yaml file. Where did this thing come from right now? We don't do any visual distinction for the users, in this view, or even in the list of job names or if you were to dig into the job in that drawer, say: hey like this.

B

This is a unique job compared to the ones that you're used to seeing.

B

Does that help paint the picture.

C

It it does and it sounds like the work when you say it happens somewhere else you mean an entirely different tool. I gathered just because you said outside of gitlab or no.

B

So I was referring to gitlab the project hypothetically.

C

B

We have like a socks organization or socks like audit team at gitlab. They might have their own project in the gitlab.com environment and in there they could define their own yaml file and say we want the gitlab project itself to inherit a few jobs. We think these are best practices they should have enforced, so they would then appear in this area, even though it was not defined in this gitlab project. It was somewhere else and it was.

C

Brought in and the value of seeing the icon in this particular view would be so that they know that they just get that insight.

B

C

B

Why I was exploring the opposite, like I'm not still on being an icon or using the badge, or maybe even using like a different weight or style of border to try and differentiate it, but just knowing these are different types of jobs. I mean yes they're both running in the same area, but they came from different locations.

A

I haven't I sorry I was reading a slack message did when you were on that previous screen. Did you um and it has the group by tabs? um Did you mention grouping by compliance framework.

B

um Hadn't gotten there yet I think that's an interesting idea to have uh both the stage and job dependencies, but then maybe another one for compliance. Hadn't thought about that.

A

Yeah, I think the nice thing about that is when you don't need the icon, and it elevates the fact that there's a compliance framework in play.

B

It's true they will. It will still show up in these places, though, but you don't seem to find that concerning at all.

A

um It'll still show up in these places like.

B

It'll still show up in the stage and job dependencies.

A

um Yeah, I think you know you could have group by and then show the columns in the group by would be compliance framework.

A

Right, if you look at stage stage, has um stages.

B

Yeah but the compliance jobs they live in those stages, so it'd be kind of weird to isolate them.

A

Okay, yeah it was, it was sort of uh more of a here's, an idea does it have any value to them? I.

B

Think it would so where I think it would be useful is, if you're trying to understand the compliance pipeline itself in isolation, so in isolation from how gitlab the project sets up its pipeline.

B

I want to see the pipeline graph of the compliance pipeline itself, so I could see those two things being useful, but this point when it's running they've been merged together, they're running together in the different stages.

A

So the reason I the reason I say that the group by option is it seems like it would satisfy whatever use case you had in mind for the icon.

A

The group by compliance framework would have the same, would satisfy the same use case, but it would be like easier than skimming the page for an icon that you have to know what it means ahead of time. Right.

C

A

There, a value.

C

I'm sorry good. The the group by is essentially just a filter, though right, and is there value in seeing the items that would have an icon alongside the items that wouldn't for any reason.

B

Is there any value to have a.

C

B

C

To kind of see everything together as opposed to the group by which is going to filter things out,.

B

um Yeah I mean today it's going to show everything group by would filter it out, hypothetically speaking, if we did it just by the compliance framework, but it would still show the same it'd be like stage by compliance frame. Compliance pipeline.

B

Maybe just like a toggle to like turn, show or hide the compliance jobs could also do that. Instead, like the way we do that with um labels and uh boards.

A

I like that, and then um you could still have the detail like on the the table view you could have detail about the compliance framework, but at least that grip by would create entry points into drilling down into the uh job or pipeline uh or whatever it's called that's uh under the compliance framework.

B

Yeah I mean it's confusing right because, like a pipeline is a collection of jobs.

A

B

When you define the pipeline, inherently you're, defining the jobs that run at various stages um but yeah, obviously we have a little bit more space to use the table asset to our advantage to provide more details like we can here, where you can see organization that came from with specific tags that which you don't get that same affordance when you're. Just looking at the the pill view of all the different job names that pretty much just tell you status, but yeah. Okay, I think that's a good direction.

B

I think I have a couple ideas to explore.

A

Four agrees, or is that loki.

C

That's not me, oh.

B

Really, no, that was sally.

A

Sully is sully the one who uh flew the plane into the hudson river.

B

Nope, it's the beach, that's near my house. Oh okay,.

C

That's a different sully.

A

I hope that was helpful. Austin.

B

Yeah, it was because I think what you did was you helped me reconsider that, even though sometimes it seems easy to use nikon, maybe there's still another third avenue to explore, which I think is the whole point of it.

A

It's easy for us, it's difficult for the user. It's an exchange of energy right.

B

We're just looking for um low low effort means to at least better communicate the status like. Where did this thing come from without creating tons of new components or complex interactions? We're just looking for how can we simply just start creating some visual distinction.

C

C

um I think that is next for me, then, unless there's anything else that we want to touch on for this topic awesome. Thank you for sharing austin I've been dealing with some icon deep dive. I guess over uh issue types and there's so much opportunity surrounding an icon all right. Let me share.

C

And let me know if I need to zoom or anything like that with uh this wide monitor here. um Austin have I showed this before this uh collab jacked piece. I can't remember if I've talked about it in this meeting or not previously, and I just want to give a little background, if not.

B

Not specifically in this meeting, but I've watched several unfiltered videos.

C

Okay, nice: oh someone.

A

Oh you're, the one person that's watching this.

C

Oh thanks for your support, austin.

B

I love them. I don't know why. I don't know if I feel the same way, but I love like just being able to watch some youtube while like drinking coffee in the morning, it's perfect or like, if I'm in a car ride, listening to something.

C

B

C

Been listening to audiobooks.

B

Sometimes it's a good time to listen to like the amas and stuff things I don't have to watch but are sometimes interesting to listen to.

C

Well, I'll just kind of quickly go over um at a high level what we've been working on so we are exploring for about six or so weeks. Here, we've we being myself and alexis kristen and gabe um some possibilities for creating a new kind of issue type and we're calling it a collab checked: it's not it's not going to stick. I don't think I'm going to push for it to not stick as much as I've enjoyed using the term during this discovery phase. I.

A

Changed my twitter handle to clapjacks by the way.

C

I love that, so what essentially we're looking to do is create a thing that potentially, in the long term, issues epics bugs enhancements features. All of these different kinds of issuables could be this thing at its core and then you could apply, maybe a type to it, and that type could eventually have its own custom interface to a degree and that if it's a bug it might have options that are different from being a feature.

C

So we're exploring a lot of things um which I think could be part of the problem, but we're also exploring ways to address that in itself.

C

For this particular uh epic and I included the epic in the agenda, but let me just show a quick prototype, so one of the things that we are looking to understand is how we can access this item from anywhere in the product. So I created just a simple prototype, showing if you were to access it from a to do. You might have a side panel view like this, and I haven't updated this recently.

C

We've actually had some discussions surrounding it and some changes that can be made to it, but you might be able to open a sort of a minified view of it here with the title and the description, maybe truncating the description initially. Just so that you don't have to see that whole thing we found in research that people have a tendency to skip over the description. They read the title.

C

They read the comments, but not necessarily the whole description until they have to- and I think that's the feedback I've heard is that people often feel that our titles and our descriptions are not as informative and useful as they want them to be. So I think, there's also a separate opportunity there for us to explore ways to encourage people to write more thoughtful titles and descriptions that are a little bit more clear, but also I took a in terms of maybe reducing some of the friction with the collaboration aspect, so hiding the secondary comments.

C

The threaded comments under maybe a reply section and then, when you click it, it would expand to reveal some of that also moved. Some of the key functions up here to what I'm calling an action bar, which would include the like and dislike, maybe the ability to update your emoji and labels. This is not a proposed final design for labels, but just kind of pulling in some of the existing functionality to show maybe how that could work um same with assignees.

C

My thought here is that you would only show maybe up to three or maybe even just one and a number beside it, to show that there's more than one with similar functionality, but just again striving to kind of condense, this information to what's most useful.

C

I currently have this menu showing just everything in the sidebar and the top action menu, but I'm not sold on putting all of those things there. I think each of those things needs to be thoughtfully analyzed to determine what needs to be where and how we might want to address those.

C

This closing would simply close it this uh item. Here, though, you could click and go to kind of the full detail view, and so one of the things that we're exploring in this detail view is how we can simplify the experience of reading the title and the description alongside the comments and not have to do so much up and down jumping around, particularly when we've got those really long issues, issues that have a long history and a lot of conversation.

C

It really complicates things. um One of the things that I am exploring for. This is maybe making this kind of soft gray divider here draggable kind of like in storybooks, so you can drag it left and right and view more or less of one section if you want to.

C

um I also had the sort of action bar over here, although I'll show some examples in a minute where we had met last week and mike made a great point that, in terms of proximity, this is way off to the side and a lot of us use large monitors. So it's going to get pushed way off and there may be some disconnect for the user to understand that that is related to the issue and not perhaps to maybe something else in the product.

C

So let me go back and show some of that exploration and I'm moving kind of quickly because I know we're low on time, but the specific feedback that I'm looking for is and you're welcome to put this async as well. What I'm doing right here, perhaps in terms of our three, how might we's or our how might we use for this discovery, are right here uh we want to make it more efficient.

C

How might we make it more efficient to understand, what's changed and what's new since the last time we interacted with the cool object and I'll show some ways, I've done some exploring surrounding that.

C

How might we take the outcomes of threaded discussions and efficiently capture them, and then how might we reduce the amount of context switching between the discussions and the title and description, as well as between call objects so for updates? One of the items that I explored was maybe using our alert panel here, potentially even having the ability to kind of toggle up and down kind of, like you can, with the arrows in merge requests um and in that.

A

Case, can I ask a question: um why not reuse the component from merge requests, um but maybe it wouldn't have like you know, show resolved, but it would be the basically the same component, because this the um alert I don't know, even even though it's an informational alert, I still look at it and go. Oh. I have to do something.

C

A

Wrong and the the threaded unresolved discussion component in mrs has more of a I'm in control kind of appearance right. It's it's like controls, rather than alerts.

C

A

So and then, um and then another um thought about all of the things that you can do in an issue like um add an assignee or you know the icons that you had below the navigation icons, you could apply the principle of progressive disclosure where, on the um on the preview version of the of the issue where the right panel flies out, you don't have those icons, you don't have the ability to add assignees or anything like that. You have to go to the actual issue.

A

To do that, the reason I say that is that we have to imagine that someone who just wants a preview of the issue is trying to either find the issue or just kind of get a survey of everything, and if they wanted to do specific actions, they would go to that specific issue.

C

That's my theory as well. I think that gabe really wants to never have to leave the current context and go to a full issue view. So there's a little bit of a, I think, opportunity there based on some, maybe feedback that we can get from prototype testing to validate which one is going to be more useful. But my thought is that when people select it, they want just some basic details, not necessarily to do a lot of configuration with it. um You make a great point about the banner here.

C

This was honestly, I think, just sort of a result of the evolution of the piece. I started with just a banner here and no view changes functionality and then, at the last minute I was like oh, but it might be nice to be able to so I just threw it in so I do think that there would be value in reusing an existing pattern there.

C

Another approach that I explored for this, though, was instead of having the banner at the top having sort of a little activity tab here that when you select that, maybe it um let me see.

A

I think there's a difference between never have to and showing everything all at once. So you have the kebab menu. You could have those actions under the kebab menu right.

C

Just keep that in mind, you know yeah yeah. I think I think that's great feedback as well.

B

C

B

Don't use the activity feature that much unless I'm trying to trace down like when did the label appear or disappear and who did it, but I think uh if you're taking some of the cues from issues, um you could just put a point in time on that timeline. At the last time, the user was there so right.

C

A

The goal, if I understand, is to um so right now the activity is interleaved with the conversation and it creates a lot of noise, so removing the activity from the conversation but still making it available. So you can. You can answer that question of when the label is added, but you can also peruse the discussion with more ease.

C

To help the user understand what might have changed since they were there last, which of course raised the question of how are we tracking that is it when they refresh the page like what is last visit to the system, um but that would be, I think,.

A

We have to worry about. I don't think we have to make it that, um like whenever we try to be that smart, it ends up, probably frustrating people, because then we're we have this added layer of hey. This is what changed since last time. We just assumed that people leave an issue and they come back to an issue.

A

If it changed it changed. If it didn't, it didn't yeah.

C

It could be yeah.

A

C

um No, I appreciate the feedback we are a minute over. So if y'all want to comment, maybe in the agenda, that would be awesome. But what I'm looking for is again how I might be doing things right in terms of my approaches where there might be room for improvement or deeper discovery.

C

I feel like I'm just kind of going for the obvious interaction opportunities, and some of that is because I think, there's still a little bit of fuzziness of what we're trying to accomplish on a larger scale, but I want to move forward and make progress so that we've got opportunity to discuss possibilities.

C

um But if there is maybe an area that I may be missing, something that can help us to go a little deeper or to a place. That's going to offer a little bit more value. I'd love any feedback on that as well.

B

Sure and just wait, one more clarifying question. Okay object as it stands today is not an issue. It's an issue. It's a different issue, type.

C

It's it's kind of um what I think is issues could evolve into, but it would just be a thing that could be could be. A bug could be. An issue could be a feature, maybe even eventually an mr could be an epic. It could be any of those things, maybe eventually.

B

But it's not something I pick when I'm creating an issue. It's not like a different issue, type that I'm selecting it's not.

C

It would be the base for that like it would be the base for that, and then you could add, like switch between the types that are possible for that, but it would be kind of like the baseline object, that you could build for those concepts.

B

Got it got it got it cool, good, cool.

C

Thank you all for your questions.

C

I appreciate it thank.

A

You for sharing.

C

A

C

This feedback from the sigma either one in the figma or in the agenda either way is great. Thank you all. So much.

B

Have a great day.

C