GitLab Create Code Review Group, 14 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Pedro - Explore design concepts to restructure merge requests

Description

Pedro Moreira da Silva, Product Designer on Create:Code Review, reviews a few ideas on how we could restructure merge requests.

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

A

Hello, my name is pedro de silva and today I'm going to share with you um some of the concepts that we came up for. One of the hypotheses of the merge request restructure. We had three hypotheses for I focused on the third one, which is called separating. The navigation of comments, findings and changes will reduce the time and effort for sasha to review them.

A

Sasha is our software developer persona if you're not familiar with them and before uh I go through each of these concepts and explain them? Let's take a look at this diagram, which explains as simply as possible what users usually interact with when looking at merge requests, particularly what they need to review each time they visit a merge request.

A

So, first of all, a merge request edits as it's written here in this sticky note merge requests you can think of it as um an object that groups multiple sources of information to provide a consolidated, co-review experience before changes are merged. So what are these multiple sources of information?

A

So a user reviews all of these items right and, of course they can post comments. So that's something that they not only contribute, but they also review.

A

They also look at changes which can have comments attached to the changes themselves or the comments could be made in emergency quests in general, and then the changes are fed into a pipeline.

A

The pipeline takes the changes as input and the pipeline contains jobs that run usually on top of the changes to analyze the changes- and you know, do all sorts of things and jobs usually output, one of the following, so either the output report, for example, code quality report or security report, accessibility, browser performance, metrics, etc.

A

They can also output artifacts, which you can say, are reports as well, but they're not integrated directly into the gitlab experience as first class reports.

A

So you can still have you know: custom code, quality reports coming in as artifacts, but anyway, reports are first class outputs of jobs. Artifacts is basically everything else that people can output with the jobs and reports contain findings. That's what you consider like each point or item inside a report would be a finding, and these findings can then also be attached to specific changes and and lines of code, just like comments right.

A

So this is also something that people need to navigate and understand the context where the findings are in and finally, this one which is not linked to anything else, is the merged checks. So, looking at the status of the merge request and understanding what needs to be addressed before the merge request is able to be merged and there are many kinds of merge tracks. You know the most basic one would be not having any conflicts between the source and target branch so that the merge is is able to be performed cleanly.

A

Another one that is made used most of the time is the pipeline must succeed. So if the pipeline fails, you won't be able to merge it, and this is also something that users need to take a look at and understand the health of the merch request.

A

So, with this information, and particularly taking into account comments, changes the reports and the findings.

A

Let's take a look at the different concepts for this hypothesis, which again is about separating the navigation of comments, findings and changes to hopefully reduce the time and effort for sasha to review them, and one note about these concepts is that across all of them, as it says here, we try to enlarge the active work area by automatically collapsing the navigation, the global navigation sidebar.

A

So that would be this sidebar here that it's usually on every page and screen of git lab. It would be automatically collapsed. um That said, it could be also expanded on very large screens, but we really want to enlarge the active work area by default and we think that this might be a good solution.

A

So the first concept and each one of them, I think, are quite straightforward, or at least I tried to make them straightforward, so I'll try to go through them very quickly.

A

This one is called accordion sidebar, as it's written here at the top, and basically the navigation is all consolidated into this sidebar, which you can expand and collapse each of these sections to show either more details or even sub navigation. So, in the case of the overview, we can have the metadata like assignees reviewers labels, milestones, etc, shown here and here on. The right.

A

You'd have the content that pertains to the overview at the top status and title of the merge request, and the global actions would all be available here when you change to another section like the changes tab.

A

uh Sorry, the changes section um it'll show the list of changed files, and you could also then filter uh changes depending on the commits and do a commit by commit review or look at a number of different commits together, and we would show the changed files here on the right and the same thing would happen for the reports, comments and findings which I will show you in other concepts.

A

But the main idea here is having just one sidebar that serves, as you know, navigation between the different sections, while also showing details uh or sub navigation for each of them.

A

The second concept is the icon sidebar, and it is similar to the accordion, but it doesn't have that behavior of expanding and collapsing sections. So here at the top, we have the three main sections of the content, navigation, overview, changes and reports. Right now we're looking at the overview overview section, and we have the ability to overlay certain information in in with sidebars.

A

So right now we're showing the information sidebar or details sidebar, where we have the assignees reviewers label and milestone and other metadata, and that is shown by default in the overview page, and we also have the overview content would be shown here, and you can you know toggle these overlays, showing information, comments, findings or even close the sidebar altogether in any of these locations. So another example here would be the changes tab. uh Sorry, the changes uh page when changing to it.

A

The sidebars uh would auto close to show the commit picker and the file tree. But you can still look at the changes and show the list of comments if you want, so that would be this overlay, which, instead of navigating the merge requests by files, you would then be more concerned with navigating by comments and resolving comments across the merge request.

A

A possibility here is on very large screens to move the complementary sidebar, so the one that has the details, comments and findings, move it to the right side so that we can still show, for example, in the changes view, we could show the list of changed files and the comments at the same time. So this arrangement would allow us for more flexibility depending on screen sizes, so that smaller screen sizes don't suffer from a bunch of different fixed elements and double sidebars on the left and right sides.

A

um The third concept concept c is just tabs, uh and this is, I think, it's very similar to what we have today and what um annabelle and phil were experimenting in the beautification of our ui, of having the metadata sidebar the details sidebar only showing on the overview tab, and this would follow that.

A

We would only have two tabs- the timeline which would be similar to what we know the overview tab today and the changes tab.

A

The pipelines would fall into the reports and merge ci checks area, and if you want to look at all of the pipelines for a specific merge request, you would go to the pipelines list and the commits tab would be integrated into the changes tab as we've seen so. um The commits you'll be able to pick from here, and this would change the list of files below.

A

So it would also act almost act like a filter um that would affect this whole view, and here in the timeline, we would add a bunch of different filters and searching capabilities so that you can narrow down the activity view and uh also, I guess you know, jump through the different comments and etc it. It doesn't have an area dedicated to comments or findings, uh because we're only using tabs and we don't have any sidebars other than the metadata on the timeline and the file tree or commit picker in the changes. Tab.

A

The concept d, tabs and sidebar tries to join. uh You know some of the concepts that I uh showed just now, and here we have three possible concepts for tabs and sidebar, and each one tries to enlarge the active content area as much as possible.

A

So this is very similar to what we have today with tabs at the top the file tree, and then you can potentially have the details sidebar with metadata comments and findings, and but we know that this severely limits the content area in small screens, because you have you can have in especially in the changes tab two sidebars at the same time.

A

So another way we could do this is actually changing the file tree to a drop-down that would allow you to jump to files by showing and opening this drop down instead of having all the files listed all the time. So this would be another idea, and yet another one is yeah. Taking this idea of a drop down instead of a list of files is even moving this sidebar.

A

That is always visible here with the icons moving that to the top to even reduce the to even more the um the fixed elements and take advantage of the height that we're already dedicating to the tabs and putting icons here on the right to open the sidebar.

A

So that was tabs and sidebar. Then concept e is a very different and I think, a big departure from what we have today, which wouldn't have different views at all different sections. It would be just a single scrollable view for everything, and so we would have here in the main view. First, the merge and ci checks.

A

Then the description then we can have the commit speaker and then the changed files and the way you navigate this single view uh without losing yourself is using the sidebar, so the sidebar would function as a table of contents to navigate to files, comments and findings. So, as you can see here, the sidebar would show the information with the metadata details, uh the files, so that would be the file tree the activity here now it's the comments. uh Sidebar is active, we'll also be able to show findings or even close.

A

The sidebar altogether, if you just want to look at the contents.

A

And finally, the last concept concept f is the master details sidebar, and this is similar to the first concept we saw of uh using a accordion, which you know you expand and collapse sections to show the details. So that would be similar to this one, uh but the interaction would be a bit different.

A

uh So right now this is showing the overview and with the metadata instead of being shown here, the metadata would actually be parts and listed at the top of the overview.

A

We would then have the merge, ci checks in the description, and then you can drill down into each of these sections, which would show a different view of the sidebar and by default, when you're in the overview or even in the changes, we always show the list of changes by default, so you can easily jump directly to the list of changed files without having to first click on changes and then selecting the file.

A

You can see the files that are changed immediately here and click to navigate to them, and so, if I click, for example, on comments here, it would show something like this, where I'm still seeing the contents of the overview. But now I have the comments sidebar with the list of comments, and I can click to go back to the last view um and the same thing would happen to the reports or co or findings, so that would show a different.

A

You know like a drill down view of the sidebar, and that's it. Thank you so much for watching this video. uh I hope that we have enough content here to discuss and make a way forward on this hypothesis, which I believe to be the most important hypothesis for us to tackle from the merge request. Restructure, see you next time.