GitLab CI/CD UX Team Design Reviews, 13 Apr 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Show runner group details in runner details page - MVC proposal

Description

Gina Doyle (Sr. Product Designer: Runner Fleet) summarizes the proposal for runner groups.

Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/388854

A

Hey team, Miguel and I had met earlier today and talked about this issue based on some feedback that I got from the team, which brought up some really great concerns about performance of the page and over complicating the runner's page. A bit I also met with hayana who's, my design manager to review like where we should go next for the MVC.

A

So um my my proposal for the MVC now is to really simplify things so that again we're not over complicating and then we can use instrumentation to learn a little bit more about what. If we need to make iterations in the future, how we should do that and then we can potentially bring in more data as I kind of was trying to support in the beginning, but now I'm I'm no longer supporting that okay.

A

So the proposal now is to remove the expandable rows so, but I'd still like to group um the data about the runners that are in a group, so we can summarize them. I know that right now we don't have summaries of the status is I believe or it's going to be really complicated. So we can talk about how we present the statuses in the beginning for the MVC, maybe like we said before. Maybe we just take whatever one has contacted gitlab most recently, I think that that again can cause confusion.

A

So, ideally, I'd like to see this as our MVC but again I understand that we we need to break this down and iteratively.

A

The other thing that I've changed is I've moved the um number of Runners that are in the group to a badge and then, when you hover over it, it says two runners in this group think that makes it a little bit more obvious and distinct.

A

um This makes it more distinct from the other ones and and then we're still summarizing the data here. Like, however, many upgrades are available of the whole group, that's in there and then we're only presenting last Runner created uh what whatever day I go.

A

So then the numbers up here I also wanted to bring up the total numbers. Those include the what we're calling Runner managers that are in those groups, so I have 11 Runners right now, even though I don't have 11 items in this table, I have 11. If we count up all the totals plus the individual Runners that are in here, I think that that makes the most sense, because those Runners are still alive and potentially running jobs. So I do still think that we should add them up into the totals.

A

Then, when you click on a runner group in The, Details page will add a new. This is the same thing, but we'll add a new value called Runners and I brought this icon in just so.

A

It brings a little bit of a connection of what we're showing in the table to here we'll add a pop over explaining what people are seeing I'm going to ask Fiona to look this over and I would hope that we can link out to documentation because I tried to simplify in the best way that I could about what's going on here, but I think people are probably going to be a little confused at first.

A

So if we have further documentation about why we did this and stuff that's what I would hope to to link out to. But then, if you show the details of the runners in that group, you'll get a breakdown of their statuses, will include the system, ID version, IP address, executor, architecture, platform and last contact.

A

The only row or yeah. The only column that I would want there to be sorting on is last contact because for our Edge case, which Pedro shared with us, there could be 76 runners in a group and it's most likely that a lot of those are stale. So if we're able to sort by last contact, it's probably our easiest way of showing which ones have contacted gitlab first, so that people have those as the most important ones.

A

We should limit the amount that we're going to show here and I would expect that there is pagination on this table.

A

So we can talk about that as well, but I think you all know better than I do about how many we should limit in this table performance wise before we switch to the next page and then the next thing here is the jobs page. So we'd add the system ID column into this, so that admins get an idea of which Runner manager is running each job and then the last thing here is when you delete a runner group, you should get a confirmation modal, that you're deleting more than just one Runner.

A

So, however, many Runners are in that group. We use this for both delete today, so I'd expect. We show the same message for this.

A

um Okay, so I think that's it. I did want to point out some other things that I added here like feature usage, metrics um I really would like to add instrumentation to the accordion in the runner Details page that expands and collapses the table of all of the runners I. Think if we're able to add tracking on that- and we see that there's a lot there's a high usage, we could consider reevaluating where those details go.

A

I think we should also add instrumentation to the delete button for each runner in the group. So again, that's within the accordion areas to open this back up this button. I think this will help us track. How often people are using that if it's not used and people are just relying on the automatic deletion that that we're going to add into here, then we could get rid of it. We don't have to support it and then the last thing here was I'd like to I.

A

Don't know if we already do this, but I'd like to monitor the number of visits to the detail pages and see if it increases after this feature is added.

A

That might also give us more insight into why or what people are trying to do with groups of Runners if they're coming in The, Details page more often, they're likely also expanding this um so I think that would help us figure out the path that users are taking and what their, what they're doing in the UI, when they're dealing with groups of runners um and then I'm hoping that we will still no longer see a bunch of Runners clogging up the UI, which was reported in the kubernetes issue and then also I still want admins to be able to get the information if there's a problem going on with the runner from the list view.

A

So that's why again. I was like pushing to summarize this, but if they need more information, we still give that to them by drilling down so I I feel pretty confident in this um proposal still and I think simplifying. It was the best path forward, so I think I answered everything yeah. Thank you again for all of the feedback and discussion around this and I think we are gonna land in a good place for the MVC.

A

um So just help me figure out how best to break this down, because I know that there's still a lot of changes and we can go from there thanks.