Collapse build tabs that dont fit

An example of what it should look like:

Could you propose a better navigation for builds tab?

Here's what it looks like right now:

Added ~19173 label

If we do truncate the build list, we should consider putting all failed builds first so they're easily accessible. Beyond that, they should be grouped by pipeline stage, and then alphabetical within stages.

This might be a good stopgap before addressing in #18141 (closed).

@jschatz1 Does this seem like something that could be picked up soon?

Milestone changed to %Backlog

@annabeldunstone can you grab this?

Milestone changed to %8.10

mentioned in issue #18920 (closed)

How about an accordion? Like this:

@winniehell Good idea. In the above example that would be a lot of vertical space.

that would be a lot of vertical space

@markpundsack Thats true, but if builds are sorted (successful, failed, running, pending) then it should be easy to get an overview of all builds. Is it really a problem to scroll down in that case?

This is actually similar to how https://travis-ci.org/ does it:

However, they open up a new page when a row is clicked.

Reassigned to @annabeldunstone

@winniehell I really like the accordion idea. We can put a fixed height on the log element so you can scroll within it, rather than scrolling all the way to the bottom of the page. @markpundsack the list would be pretty long in the above example, but each row could display more information if we do it this way. I think it makes more sense than just adding a More button. @hazelyang what do you think?

I agree. @hazelyang what do you think? I say go for it.

I think this issue started as a quick fix, but is turning into something larger. Unless there's a quick and easy fix, we should fix this in context of #18141 (closed).

I'm not sold on the accordion yet. We've got 39 jobs on gitlab-ce for branches and 71 for master, so that's a big list. If the original issue was complaining about having 10 lines above the build log, how does having up to 70 lines above make sense?

We've currently got a bunch of meta data available on the build page, including actions such as retrying and downloading artifacts. Where do those go? The list above looks like it's pushing some of the meta data into the accordion, but not all of it. Would we want to push all of it there? More importantly, what does a developer need to see when looking at this list?

We already have a vertical list of builds (e.g. https://gitlab.com/gitlab-org/gitlab-ce/pipelines/3689624) which has (most?) meta data and actions. Would we want to just turn that into an accordion and show the build logs inline, one at a time?

One problem is that failed builds at the bottom of the list could be hidden. In general I like the idea of putting failed jobs first, but somehow I think this is going to feel unsorted and harder to grok. But maybe not. Even if it does work, sometimes you're going to be looking at lower builds on the list, and so you're back to the problem exposed in the original issue.

Reassigned to @hazelyang

The more I think about it, the quick fix seems to be:

Sort the jobs by failed, pending, running, cancelled, succeeded (are there other states?)
Secondary sort by name, alphabetically
Fit however many you can in one line, then use "More" button
More button triggers a drop-down of the rest of the jobs (in the same order above)

Thus:

We'll never see the tabbed interface on multiple lines (which it isn't meant to handle)
Important jobs show up first
Jumping betweeen failed jobs is fast/easy
The use of the More button should be infrequent

What do you think @hazelyang?

@markpundsack seems like a good solution for the time being

@markpundsack I think it's good. I'll work on the mockups.

mentioned in issue #18141 (closed)

Default

Dropdown

For the dropdown, I was thinking more like a modal dropdown. This kind: . One of the objections to the current design is that it's using a tabbed interface for the jobs, but showing it multiline, which doesn't work for tabs.

Do you want a filter for the statuses (Failed, Pending, etc.) or just sort by that order? If we do use a filter, we should probably have an All option.

This did not happen in 8.10.

Milestone changed to %8.11

mentioned in issue #19982 (closed)

Added ~307491 label

Added ~19492 and removed frontend labels

Once the UX is done here @markpundsack you can add ~Frontend label. ~Frontend is only added when UX is done.

@jschatz1 Funny, I think ~Frontend was added at issue creation. At least I don't see a system message when it was added.

At this point, I think this issue is superseded by #18141 (closed), but in case we don't get to the full scope of that, this is still a good scope to ship. The mockups in that other issue are mostly correct for this, minus the pipeline stage stuff. Or heck, maybe even with the pipeline stage stuff. We don't have to wait until the pipeline graph ships to show builds in stages.

@hazelyang Is the UX work done here?

(Minor thing I noticed is that the "Post tests (4/69)" probably shouldn't have the "4/" part, as mentioned for the pipeline graph itself.)

@markpundsack I added the screens in mobile. Currently UX work is done.

Mockups for mobile.

@hazelyang I assume we have a standard pattern if the stages don't fit on one line? Fade and scroll?

ah, my bad. Thanks for reminder. I changed it.

Oh funny, I wasn't thinking about that line. I was thinking of the stage names above, Prepare, Test, Post test. If there was a 4th stage, I assume it would fade and scroll, but the > button would get in the way of the << button.

Minor thing, but we stopped pluralizing the stage names in this release, so we'll drop the 's' on those stage names.

I misunderstood. I did the change.

Ah, that looks kinda bad with that whole line just for the menu icon, right?

@markpundsack That's true. To keep it consistency with the pattern we user, it looks not good.

I tried another solution. My only concern is that the <<button and >> button will not in the same place while opening and closing. What do you think?

Well that looks better. I'm not sure about the new problem.

@hazelyang Talking with @annabeldunstone today, I realized that we're mixing UI patterns by having the More drop-down for desktop, but then using horizontal scroll for mobile. And I guess horizontal scroll hasn't been working that well. I wonder if we could use the drop-down pattern for mobile as well? And use it for the stage name too?

Then one big problem left is how much vertical space both of those take up. What if we collapse the job list all the way to a single entry for the job, with the current job name appearing there, and the job name itself being a button to show a drop-down to navigate to another one. Do the same for stages, and they'll be small enough to fit on the same line. Also, we already we drop the Pipelines, Builds, Environments sub-menu when looking at an individual pipeline or build, so that saves a little more vertical space.

[hamburger] [project] [icon]
[project menu]
[stage dropdown] [job dropdown] [<<]
[build details]

@markpundsack I did the changes based on your suggestions.

Do you think you could show the current stage and job rather than the words “Stage” and “Job”?

@markpundsack Yes, absolutely. Thanks for the reminder.

Great!

Does that work for you, @annabeldunstone ?

I don't think this is the best idea. In order to find another failed test from that list you'd have to first select the stage and then find the test. If you were unsure of which test actually failed, you might end up having to click through every single stage in order to find one test you're looking for. I think the right solution for now would just to be show about 7-8 tests at the top, followed by a single dropdown for the rest. Ranked from failed > pending > running > canceled > skipped > success. It's not the most elegant solution and it may need a much bigger redesign down the road, but it's a good place to start. What do you think @markpundsack @hazelyang

mentioned in merge request !5595 (merged)

@annabeldunstone Generally speaking, you should never have failed tests occur in different stages. If stage1 has a failed test, stage2 doesn't run. There is an exception if you declare a job in stage2 to run when: always, and I guess that job could then fail. But that's not the common case. So, assuming you're looking at one failed build, then finding the next one is as simple as clicking on the job name, and picking the next one on the list. It's still sorted by failed > ... > success. Perhaps we need to include the status in the drop-down too so that part is obvious, and you know when to stop looking through the jobs. But I'm not as worried about needing to jump around stages.

I guess you could be worried about not even being on the right stage to start with, so you have to search through all the stages to find the first failed build. I would hope that you'd be coming to this page via the Pipelines page, where the pipeline graph would show you which stage failed. Or you got an email with the failed jobs mentioned, so you're going directly to one of the failed jobs.

@annabeldunstone Does that assuage your fears?

@markpundsack I didn't realize that was the case. If it sounds like it'll be good to go in terms of usability, I'm all for it.

Added frontend and removed ~19492 labels

Reassigned to @annabeldunstone

For the stage and job dropdown, can we add a header to the lists? The header will only show up when you click on a list, but in case people are confused by which is a stage and which is a job, showing that header on dropdown might help. /cc @hazelyang @annabeldunstone

Had a long discussion with @annabeldunstone and it looks like this issue is more complicated than we thought. The main problem is that the desktop and mobile mockups are basically completely different elements, so making a responsive page that handles both means creating both, hiding one, and then cutting over to the other one at a specific breakpoint. That's not great responsive design.

Option 1:

Go mobile-first, and take the dual-dropdown approach of the last mobile mockup, and do the same thing for desktop.

One problem with this approach is that often jobs are named after the stage they're in. e.g. build job in build stage. So we talked about adding labels for the dropdown. This takes up a bit more room, but seems to be worthwhile.

But the big problem is that we miss the opportunity to have a better experience on desktop. I personally like this view for mobile, but dislike it for desktop. So:

Option 2:

Focus on desktop; go back to @hazelyang's latest mockup for desktop, and figure out a different way to be responsive down to mobile. My proposal is:

The job list shows as many jobs as it can, and then puts the rest inside a drop-down. This is already responsive down to small screens, with the degenerate case being a single drop-down with all the jobs in it.
Apply that overflow dropdown technique to the stage names as well. We'd probably have to do this anyway for consistency in case you have 20 stages on desktop. But by doing this, we also get it to be responsive down to mobile sizes.

When you're looking at one failed build, it's easier to navigate to other failed builds. Perhaps more importantly, you have a better overview of how bad the pipeline is. As in, you can see at a glance whether everything is all green, one build has failed, a few have failed, or many have failed. By having that awareness, you'll instantly know whether you even want to look at other builds or not. For example, I get an alert that the pipeline failed, so I click on a link that takes me to a build. I look through the log to understand what went wrong. Then looking at the navigation, I see that 2 other builds failed, so I'm encouraged to click through them as well. That information would be lost if it were buried inside a drop-down.

I think it also just looks much better. And it's responsive so easier to code and reason about. It feels like a smaller change from the current display, so less jarring for users. This is particularly important because we're considering changing this whole thing again (in another issue not yet created), so doing smaller incremental changes feels better.

But, this options isn't great. I don't expect it to look nearly as nice on mobile as option 1.

I'd love to get people's thoughts on option 1 vs 2, or if there's an option 3 out there.

At any rate, because of this, this issue is at risk of not shipping in 8.11. Priority is on getting the Pipeline graph in from #18141 (closed).

/cc @ayufan

mentioned in issue #20863 (moved)

Updated description with latest mockups.

@tauriedavis Would love your thoughts on the last comments and option 1 vs 2.

My only concern is that the <> button will not in the same place while opening and closing. What do you think?

The build sidebar is related to the actual build selected and should be next to it. If the navigation is above the build header, the build sidebar should be next to the build header (and under the drill down options, not above). This will give more horizontal space for tabs on smaller screens and keep the arrow in the same place on expand/collapse.

Would love your thoughts on the last comments and option 1 vs 2.

I worry about the two drop downs because drilling down here is sequential (you pick stage first, and then select job). It should be obvious that these options are ordered and not just separate filters by looking at the UI. I also feel having four rows of tabs on a single page is overwhelming the UI. This might mean an accordion for the stage options and tabs/more dropdown for the jobs associated with each stage. Just one idea to explore. @hazelyang Can you look at ways for drilling down this information that makes it obvious that it is sequential and make a wireframe/comp of what you think is the best? It should also respond well from desktop to mobile, ideally not having completely different elements at different break points, like Mark is mentioning.

cc @markpundsack

An inspiration from @tauriedavis 's suggestion.

I am wondering if we move the stage dropdown and job list to the sidebar, we'll see:

Don't need to hide the jobs in a dropdown, so people will have a better overview of the pipeline.
Better responsive design. We can have the same functionality both on mobile and desktop.
Feel light on the header.

Build-desktop

Build-mobile

YES! I love this @hazelyang! I've been wanting to utilize that huge empty space on the right for so long. What do you think @ayufan @markpundsack?

That is very very good Nice one @hazelyang!

Nice @hazelyang! :) This is much more obvious.

cc @dimitrieh

@annabeldunstone @hazelyang Yes. This looks awesome!

Status changed to closed by merge request !5595 (merged)

mentioned in commit c236ee4d

Mentioned in issue #22204 (closed)

Mentioned in commit nick.thomas/gitlab-ee@c236ee4d

mentioned in issue gitlab#5799

mentioned in merge request !14785

Collapse build tabs that dont fit

Proposal

Links

Designs

Child items ...