GitLab CI/CD UX Team Design Reviews, 10 Dec 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CI/CD UX Team Design Review | 10 December 2019

Description

Design Review session of CI/CD UX Team.

Discussing usage of status icons for pipelines.

A

I'd be a bed of its own sorry.

B

A

Problem, what might be a benefit beneficial conversation is the process for introducing a new status icon because it it sounded like it. Maybe wasn't the most straightforward thing in the world: I myself wasn't aware of it. It sounded like Jeremy, wasn't aware of it as well. So I don't know if that's a worthwhile conversation to have. That might be something that better serve just the featuring myself having offline or we could have it here. If anybody else has anything more exciting, I think more than happy to deal I.

B

Think that's an interesting one for alignment. If anyone if anyone doesn't agree with that, you know like feel free to drop as well, but I think for myself. That's also interesting or aligning everyone on the same base. Also prettier a good discussion, so I feel like we could go on. Anyone else has anything to suggest for today.

C

I'll probably have some stuff for the next one, but not today.

B

Cool Mike: let's go with that. I know that we had to be in there chuckling. We have been tackling some of these questions already so curious. How did you proceed? What are the outcomes there? What are the questions sure.

A

So let me give you just a little bit of background on what we're talking about here. First.

A

So we're talking about pipelines and mostly the kind of status of them, so there's a few views that there's this mini stage or the kind of mini graph view that you get in the pipeline's view, but also somewhat similar to what mitri talked about last time when you're in the pipeline view here really talking about these status icons. So in this particular issue, we are talking about limiting pipeline job concurrency using semaphores right.

A

That's the kind of things just rolls off the tongue, but basically it's the idea that sometimes you want to have a process where you are only running one job at a time I you could. This could apply to the same job within the same pipeline, but I think it's easier to think about it as if you're running, multiple jobs or multiple pipelines that run the same kind of job. There are times when you would not want to run two of those at the same time.

A

So the idea here is to only let one of those run a great example be if you have a physical device like an iOS device, you can only want to run the tests on that at the same time, so thinking about an actual physical device. So this went through a number of iterations but ultimately landed on defining a resource in your CIE mo and then that resource in this first iteration will have concurrency of one meaning.

A

Only one of those can be run at the same time, so you can now define that group and you can set it to run. So only that's you know. If that resource is currently being used, then all the other jobs that are trying to use it would be marked as waiting. So there wasn't really much UX to it. It was just the introduction of this one icon.

A

Here, a new status went with the hourglass, it's a SVG that we already have no library just introducing it as a status and then adding a tool to appear that says. Waiting for the resource group is, which is the keyword that you use in the CI mo file, and then it tells you what resource group is currently using that.

A

So there's that that's the background on it I guess there are any opinions on I. Guess the introduction of a new status and end or the use of.

B

So what you've done like you? Will you basically took this our our clock? Our glass I can enhance yeah and they put it in the circle. The circle indicates the stages of something right, like yeah.

A

So we have a number of, let me pull up to get web SVG.

A

If you go to this and type in status, we have these status ones that are specifically I, think only used in this pipeline view I'm, not sure if they're used anywhere else, but it it generally is this circle with the icon in the center of it.

D

If you want I can give some additional context or out loud, so the ones with the circle are older. I can send the one without a border. At some point we chose to get there with engineering to let's make those scale a little bit better, we're going without the like the circle around it and create that art with CSS I dunno, there's also a different option there to add or to style the SVG elements inside the SVG to know to be dynamic in width and that kind of thing.

D

But it was a decision back then there's an issue to clean it out. So eventually there should be only one set of status: icons going I'm.

A

Glad you brought that up, because Nadia and I were actually talking about that. The other day. Does it make sense to carry around you know like especially in this case where we have the our add class icon and then having a separate one as a status when yeah, you could just add the circle with CSS, so we are moving in that direction. That sounds good, so.

B

Do you meet you what you just now said, basically that all of the icons with a.

B

D

I'll, let I'll link the issue. The issue has been scheduled before see. If it ends up being deliverable, there's been pushed no mouse them at the milestone, but it is an issue where we, you know it's basically technical depth. Then we need to solve that and get rid of you know one of the icon.

D

Icons in the status like either like we're either gonna keep the one with the border or we're gonna keep the one with the border list and I would push for the borders right now, as that allows us to make the icons that are without a border there and they can be used in in multiple places. If maybe there's some cleanup work to be done. Basically, the.

B

Fitment that I gave earlier to Mike that I feel like the ones that have border inside are especially if they have a smaller size. You, it's really tough, to see what's inside, like especially with this hourglass, if you will put it into this border circle, for example, like here I know that this is not the size, the original size, it's a bit smaller, but it's really hard to see. What's in the circle like.

A

This is a good example here, once it gets down to that size of Israel, challenging yeah. So.

B

And who is making the decision? Are we using? Are we going for ones with borders or without so.

D

There is an issue that is belongs to continuous integration and I created that original original issue, but I believe Jeremy Jeremy alder shown interest in that issue as well. So when we finally get to scheduling it or making it deliverable, we can, you know, make the decision right there, but I think borderless should be, or it's most likely gonna be dissolution. Going forward.

C

So it's borderless, but when it joined the pipeline we are going to draw this year code with with CSS right. Yes,.

D

C

I had a pusher about the color, wouldn't the color being I'm afraid like when I see that color I just assume that it's kinda like a warning and then like sometimes with our own pipelines, like the ones that we use internally in in in he'd love after a while I ignore them, because I know like it's something that has nothing to do with my my I merge.

C

It's just like something about the pipeline, so I just see you when I see, yellow I automatically assumed that it's yeah it has an issue. But it's not my issue and I'm gonna ignore it because she passed you know so.

C

D

What you're talking.

C

D

Is allowed to fail, and then you know the pipeline did continue or they pass, even though the failure of single job was right.

E

D

Would say it depends right, like are you the target audience to fix an error? Maybe not in that case, like you, shouldn't like to matter to you right, but for.

E

Example, I hear.

D

The kid DRI of the development of that energy quest that you know that error might very much be of interest to you.

A

Yeah, like I guess, can I can I do a mini user test on you. So if this is a status of waiting, meaning that it cannot proceed until something else happens, is there a color that would speak to you better.

C

That's a good question. Let me think about it.

C

Well, I was gonna, go weed block, but just for a reason. It's because we already when we have a merge conflict, I'll show you.

C

When we have a merge conflict, we're ready show like are where you need to resolve conflicts. That's what we do wait.

C

I'll say I.

D

B

So while you are doing that, like do, we use yellow color. If that means that region action needed or is it, the warning color were.

A

Let's go to the videotape.

A

Slow loading pajamas today.

A

Yeah so I mean that was my debate as well. I could see it being just this. The gray, you know nope no color to it as well. I, don't think green or red would be appropriate. It's not a success, and it's definitely not an error. I see great being a possibility as well yeah.

D

Inside our colored documentation on design MacGibbon become the waving action has been depicted as belonging to the orange color as far as I remember. So, if you decide to be otherwise, we might need to. You know, review that documentation again, because then we would not be aligned with those guidelines on you.

A

Yeah I, don't I, don't recall what the word was all, but I did consider it. When I did this months ago, it did seem like orange, was the appropriate color and.

D

Perhaps perhaps it's interesting to know that when runners were introduced, you know see, I was introduced and especially if you are on a self-hosted instance, having no runners available is a much more likely thing to happen and therefore you know having your pipelines be in a pending stage. You know, waiting for a runner, for example, is something you want to be. You know that is a warning.

C

I'm, sorry, that was me sorry I'm. So sorry, noise.

B

Everyone is awake right now for sure.

F

B

Forgot who I was talking with you to this sound meat? You are saying something right again,.

D

Let me see so: I was talking about the orange color being applied to the pending state. Inside of you know a pipeline, and that is because, if you're on a self-hosted instance, and especially in the beginning of CI, you know having a runner available for your pipeline is not a natural thing or my Creed not be natural thing, so you want to be notified of that and it's like a warning state. Hey your your pipeline is doing nothing until its provision. We get lab runners. That's why the pending state is orange.

D

Color, like it's a warning right.

B

Aha, but so it's actually orange is the color of warning, not the color of waiting, because in that case, in that particular example, waiting is a warning kind of like it's not normal, but in general I would never associate orange with waiting. If that doesn't require any action from me.

D

It's interesting, it's interesting to look at it like that.

B

Yeah yeah, so yeah yeah I, like I, agree with that bronze question, like you know, I'm, not sure about the orange. If that's, if that doesn't really, you know like request any action.

C

I, just are you sure, on those loans like because I cannot send images on the top of this yeah, but that when there's a merge conflict that warning icon is black I'm, not saying that there should be the quorum? Do you say that that's what we do well.

B

Actually, in that case, I would expect it to be orange or red, because that's a warning, that's kind of like a sure thing right.

G

So maybe this is where it's wrong. My.

C

G

A

C

You to take an action right like.

A

It's not asking you checking out, and it's it's just indicating that you're I'm gonna use the word. Progress is impeded at this point, meaning this. This will not go forward because you would expect it to go forward right if, without this situation occurring normally the pipeline would have gotten to the point. It should normally proceed at this point, but this.

E

A

Proceeding because of a specific situation which there's no action that needs to be taking, everything is happening according to plan, but the progress in my opinion is impeded at this point.

D

We might need some like a hierarchy view of colors like if this is you know, if it's more informational than a warning, then perhaps the blue color should be applied in some of the of the orange one. Yeah.

B

Yeah I would agree to that at least I feel like that's. The generic standard accepted like the blue is the waiting in progress forever. Green is completed. Good Brad is warning aborted, whatever it's like just general psychology of the colors.

A

Some people recommend a little bit, though I do feel like the user like when they need to become aware of. This is they're, probably in a situation where there may be initially confused, why this isn't proceeding right, so something that does draw your attention to it. I think it's not the worst thing in the world.

E

Yeah proof that.

A

Could be blue though I mean blue does not really stand out, though, in this context, so.

B

I guess we have to judge on the situation right if we want to attract users attention to that, meaning that hey you need maybe to have a look into this or double check or whatever. Then we might use colors like orange red. If this is just indicating the progress here, you should kind of like just wait and not that you know there is nothing you can do you just kind of like need to wait. Then the blue is fine, I! Think well,.

C

What the other interesting thing is that, if this is gonna be shown in a pipeline, there's a combination of the icon that you are seen and then the next one. So couldn't we do something in the next one I don't know if that makes sense. What I'm saying but, like you know like because, like the next one cannot run because it's waiting on something else that one kind of how like and other status as well right, yes,.

A

You're saying the one that actually is doing the blocking or half the current one is an indication right.

E

A

We have a follow-up issue to address that as well to have it both ways right, the one that is waiting and one that is causing the wait as well. Yeah.

H

And that came out of the dag research they weren't the they're using the pipelines and then, in this case the dag to troubleshoot. They they don't care. What's running fine, that's great I! Don't need to focus on that. I want to focus on the things that are not running fine, not on time failing and then I want to know more information about those things. So it's great that we've gotta issue open to indicate dependent failures, because that was something that came up as well, because it speaks to this whole troubleshooting tasks.

B

Nice information, Laurie.

A

So I think we have this in our meeting, but one thing I did want to get through in this as well. This is great discussion. We're having it, but I was also hoping Demetri on the spot and explained the process of these sets icons because it seemed to me like there was confusion around it. Reading the the comments that have been bouncing in this issue, is there a specific process and is there something unique about these status icons that is different than the normal icon flow or am I just reading.

I

Too much into it, no I, you're kind.

D

Of right so I was explaining this to to Jeremy as well. I would consider the current status icons, s-some kind of like a legacy, UI element, so the so. When you create a status status icon, you are not only you know, creating a status icon. You also need to take care of five icons. So there's there's that, in order to create those five icons, I really need to dive deep into. You know old, work-in-progress, sketch documents as to see how I originally created those.

D

It was a less less review back then, and because the process to get to the final result is a little bit a little bit strange, and it was like this. This situation, where we do say 64 by 64 template where we scale down to 32 by 32, which is creating a favicon which is also dynamically generated the whole. The whole thing is a little bit.

D

You know it's, it's it's a little bit undocumented and untouched for a long time, because it was be prioritized. A lot of things came up which are more interim porting.

D

Apart from that, I think the additional compacts I can give. Is that the, for example, if you have the check mark I, can write with the green one, the green circle around there, the I can, with a circle around it kind of like a connection with CI status.

D

That's also why you see them in the longer badges, for example, on the pipe on lists. If you moved it, if you move that, you know who is screencasting currently go to CIC the pipeline page, and you see here, you even see the like in one of those running badges, you see a circle depiction on the left side.

D

Yes exactly so it kind of like it, it states towards the user like hey. This is a like: a pipeline status, icon the circle kind of unifies, the different statuses, but they all you know matter to some extent and direct to a pipeline. That's why the pipe like that that I can, whichever one is, maybe if it includes the circle around it, can be shown throughout the UI by itself, and you immediately know hey. This is about a pipeline um and let me see the last thing around that could be.

D

For anything to be hard here, I wanted to say one more thing, but there the escapes escapes my my brain as we speak about it. Didn't answer your question, though: I.

I

A

Okay, so we do show the I was curious about the favicon, but it is I see it now and now it makes sense to me. I was when I saw the ones that you had generated, that they were in the lower right hand corner. It seemed odd that an icon was offset, but it's overlaid with the other one. So exactly.

D

The size accounts are dynamically generated and, what's by the way, a community contribution, which I think is pretty pretty great, but then you need to take care of that right, like you need to like. Have that context see like? Is it gonna work in a favicon, yes or no, and also perhaps the last thing, and then I won. Remember again is that when introducing a new status icon, we are, you know, expanding the Ray of statuses that we can show towards the user.

D

I've always tried to be careful with introducing new statuses, because before we know it, we have so many status. Is that it's no longer like immediately clear to any user, especially beginning uses what is happening right and they have to learn additional statuses before they can immediately grasp. What's going on from just seeing the icon, so I've been I've been careful with that, but perhaps it's time to introduce a new one. Otherwise I've been thinking of you know, for example, using the pending state, but with additional information upon a hover.

D

So, for example, hey resources are missing or we're waiting on, more runners have been provisioned or something like that.

A

So do you feel like this rises to the level in your opinion of a new status, or should we turn towards the pending one? In your opinion, that's.

D

A good question, I would say like: is there enough value in it to immediately know without to interact with the status, to see that you know that this status is different from you know a pending status, because if you look at, for example, pending versus waiting, it's the same thing like pending means waiting right.

D

But if there's value like significant value in showing to the user that you know waiting, these resources is different from waiting for a runner to be provisioned, and you should always know that immediately then I would say yes, another status is is a good idea. If not I would I would disagree with it and I'd say like let's see if we can do the same thing, but with the pending status.

D

A

We ever have a pending I, always I've, always seen pending I've searched for this before I've never found a pending I always see here. I, never see it in a job. Is that even a possibility to have pending in a job? It should.

D

And I'm sure why it's not shown there.

D

So this it has to do with the hierarchy in which statuses are shown, for example. So if we look at the mini pipeline graph in the middle screen, each of those icons represents a stage right. It does not represent a single job, and so it needs to displace like status. That kind of like is the conclusion over all the single jobs within the single stage.

D

There's a hierarchy coded into our system that says alright. If, if there is it fails that a failed job inside like 20 other jobs that have passed, then we show the stage has failed, because that failed job is much more important than all those jobs that have passed like. That is good news. We know that we don't care about that. Those those are good right, but that single one that has been failed is super like this.

D

It's far more important and we do the same with overall pipeline status, the ones that you see on the left side. So apparently those pipelines indicate that is pending, because one is one of those jobs should be pending. I don't know if that is the case, but if that is not I would say, there's some kind of error going on.

A

So I am I hesitate to say: I would defer to you in this, but I feel like you. Have your you've been.

I

A lot closer to this I would also say that fresh eyes upon this, no problem space is a good thing. Yeah.

A

I mean my initial thought was pending felt different than waiting, because pending I had interpreted that as mostly because I've only seen it in that status, where I rarely see it pending in a job where it felt like it was. You know something that was upcoming. It was almost almost almost scheduled, ripe and I know we have scheduled as well, but it felt like you know. It was something that was upcoming. Not it currently should be running, but it is waiting.

A

So to me is that is where the difference was, but I definitely see the argument that pending and waiting are not that far apart, and it is increasingly talking to float on the user to have to carry those around so I could easily talked into going back depending, and it would save a lot of icon work of that thing in there.

E

B

That's a very good point, though yeah it's like yeah would almost write down what the spending stages mean and then what we intend with waiting in the in which cases and then just almost compare that maybe discussing that with uh with the PM's or maybe even with technical writers. I, don't know, I'd.

A

Be curious to hear Ian and Juan's take on the now hearing that conversation.

C

Well, I mean I, think the less we have in terms like he'd not be super complex already. You know. So if we can reduce complexity like at that level, I think it's better than introducing more complexity, but I don't know that's my way of seeing it I. Don't.

D

Really got my tent.

C

What he said actually.

J

Had a similar opinion like I would always opt for whatever the simpler solution is so I. Don't know it's hard for me to really tell because I don't know the space well enough. If this new status is warranting, the pole icon in that entire treatment or if it is easier just to maintain it simplicity with what's already there so I would I'm gonna totally plug Laurie here and say, like we should do user research to see if you know if it's important enough to our users to be able to differentiate the difference.

J

If it's a question that we can't answer, I always put it off on the way. It's my go-to yeah dance. That's.

H

Why I'm here um I can tell you, though, that anything that we can do for the user to make it easier for them to understand what is going on without having to click into or drill into a job or an artifact or pipeline. That is what we should be doing.

H

If we can't, then we'll have to force them to hover click or whatever, to go into the field thing to find out what exactly feels where it feels all that jazz but they're, coming here to troubleshoot they're coming here to check the time to see how long that pipeline went.

H

So anything that we can do to surface that information at a higher level, so they don't have to cook in, would be perfect again. I guess I can't then make it easy for them to click in and get right to what they were. Looking to, yeah.

A

And I and I think here, like it's definitely simpler from a.

A

Engineering design, all that good stuff standpoint is, we just has one single item, but it would always require than a hover state to understand. Wait is this pending or is this waiting, so they are two distinct things. I think really would rise and fall on like do they care right? Does a user really care if it's pending or waiting I think would be the test that I'd like to ask and.

H

How are we defining the two? What is a pending thing? What is waiting thing.

D

So I can I can perhaps another scenario and ask you what what you were doing so, in fact, if a job fails so not depending on wedding, but if it actually fails. We turn to me expose within the tooltips, for example, if it's a script there, if it's an error, because in the runner, if it's some kind of like I, know, there's like five types of errors that can happen, I believe we're adding a sixth.

D

So for these kind of errors, should we show a different icon to immediately notify the user that it's a script error versus a runner error or you know, do we like that, would introduce yeah five six different failed icons? Basically, or do we have enough with the single failed icon and the user can't find out upon further inspection.

H

That's interesting I so far and talking to people in the very little stuff I've done around pipeline like pipeline page and veins. No one's told me that they want more icons. um They just want it to be easier to find out what they need to do to fix it.

H

So one of the things if we're not sure about this is that we could mock up a page or two to to show like one page with old icons and then a page like with with other iterations of these ideas, and then maybe our current page and then have somebody go through a task to say like what's going on in this page. What? How would you try to solve this problem and get them to compare and contrast the idea of different icons, because my gut tells me the more icons we throw at them?

H

The higher the cognitive load will be for them to try to figure out. What's going on so I, don't know, but I don't know. That's my hypothesis.

D

Perhaps reach tooltips like make sense as well now.

J

D

Through solutions here, but.

D

H

I think you're onto something with that Dimitri, because what they told me in the dog research is that they they're only they come to the pipeline. These people, who I talk to typically, is to make it better.

H

You know it's making sure that it didn't fail and to fix the things for the next iteration and if we can make it easier for them to understand, what's going on like it with a rich tool tip or something like that, I think that that might be more effective and throwing seven more icons at them that they have to memorize what they mean.

A

Well, I'll make a slight counter-argument to this as well. If, if we hope that at the highest level that more icons increases cognitive load, then we should go to one icon or ie, no icon right so taking the limit of it that way, but everything is just an indication of a stage and the tooltip explains what's happening there right. So obviously that doesn't make sense right, I think failed and success. Definitely weren't different icons, so I think I think there's definitely a spectrum here right.

A

The answer isn't one and it isn't infinity it's it's some number in the middle and I think it's always just gonna have to be evaluated like we said on a case-by-case basis.

A

There's going to be you know things that butt up against each other pending and waiting is a great example, and when does those those gaps get big enough to warrant another icon, I think is: is the approach we're going to have to take yeah? That's true! That's.

H

A

Having said all that, though, it does I am trimming towards simplicity and MVC that maybe we just go with the pending icon, because it doesn't require the introduction of anyway, a new icon, and then we slate this for testing and only introduce the new icon. Little can prove that we actually need the new icon seems like the gitlab approach.

A

So let me make sure that that will fly with engineering and I will go that way as an MVC, and then we can revisit this.

A

It might make for an interesting study to do both the pending and also like you're, saying the errors or whatever other ones that maybe we've considered over the years and do a holistic kind of study on you.

H

A

Are we at the right number or should we increase or decrease or.

H

Is it even a number, is it's more about? Are we giving the people the information they need to do their job.

K

A

I love the this why? This is why I think these are fantastic meetings, because you would think like I use an icon, and it's all dip right. Nothing to talk about here here.

E

A

Minutes later, like.

B

Yeah I think it's a nice thing for us for everyone on this meeting to think about in the future. So thanks for bringing that up, Mike and Mike.

H

Would you mind writing yourself a note or whatever at some point, maybe in January opening that research request to to think deeper into this.

A

Yes, but I also think this is very close to Dimitri's workflow, so I, don't.

I

A

If you, if you don't, speak Mike, that's what Mike well.

H

That was Laurie was doing to because I'm not gonna. Remember somebody else to do this for me. But yes, please! Anybody, please take the initiative right upon research issue tag me in it. So I have it on my radar and I'd love to dive into this. This is fascinating I. Do we can do a cross stage group conversation too, with icon around icons as well. Yeah.

D

I'll take up the section point and get it off cool thanks.

B

Sweetie, alright, if there is anything else that anyone wants to bring up.

F

Seems like not oh yeah: what's that not yet not sweet prayer, alright.

B

Awesome well thanks for jumping in at the last point. Mike was a nice point for discussion. Thanks everybody for nice arguments and yeah chat soon. I guess.

K

B

J