Beautifying our UI (15.11 - 16.1)

• Designer: @annabeldunstone
• Engineer: @iamphill
• Milestone(s): %15.11 - %16.1

Every milestone, we will ask Product Designers and Engineers to volunteer to partner in making self-directed usability improvements. It is an opportunity to fix the things that have been bugging you or that you've heard from users without worrying about prioritization.

• Self-Directed: There are no restrictions on where in the product the pair can make improvements. The goal is to empower the pair to focus on usability improvements that they personally want to see fixed in a product that they use themselves almost every day.
• No restrictions on product area: The pair is not required to work within product areas owned by their own stage groups.
• No restrictions on pairings: The Product Designer and Engineer pair do not need to be from the same stage group. This is a voluntary initiative.
• Work in MRs, not issues: Both the Product Designer and the Engineer should work directly in MRs to make changes. For the Product Designer, these MRs will likely be focused on less complex usability issues that the pair identifies, such as documentation, minor UI polish, or UI text changes.
• Length of rotation: The length of the pairing will be 1-3 milestones, depending on what the pairing believes is appropriate for them. This means that multiple groups could be working on Beautifying our UI in parallel.
• Prioritization: The Product Designer and Engineer will inform their stage group team of their involvement in the initiative, so that they can make time for it during milestone planning.

Learn more

What this issue is for

• Link each MR to this issue
• Braindump potential UI fixes

Testing

Please make sure package-and-qa job passes in every MR as we expect some E2E tests will be broken by the changes. QA review would also be beneficial.

assigned to @annabeldunstone

marked this issue as related to #364574 (closed)

added to epic &7781

added Beautifying our UI UI polish UX featureenhancement frontend typefeature labels

changed milestone to %15.11

Command palette Looks like this is being worked on by another group

User profile page

Activity filters on MRs (and possibly other issuables)

We could also explore moving the participants out of the sidebar, since theoretically they would be listed in the From: filter.

Although that probably doesn't cover all the cases that define participants (for example, giving a to an MR etc)

Example:

@iamphill Would it be possible to add a filter just on merge requests? So we could default to showing specific things but give users the option to see all activity? (replacing the history/comments only dropdown)

All MR activity types (I think)	Proposed defaults
approved
unapproved
cherry-pick
commit
edit description
merge (is this automatic merge when pipeline finishes?)
merged
opened
closed
time tracking
assignee
reviewer
title
task
label
cross reference
branch
milestone
comment
outdated (is this when someone comment on an outdated diff?)
lock
unlock
due date
start date

@annabeldunstone Yeah we can do that So the idea would be would to for example filter out approved system notes?

@iamphill Yes! And I don't know why I keep talking about default; it would be a way easier transition to just keep the default to All and let users select what they want to see

So by default it might look something like this (or however the current select dropdown looks):

And then if you filter out some things, it could look like this:

Questions/notes:

• What are your thoughts on putting this behind a feature flag? Or is that a huge additional effort?
• The Apply filter button was just for the prototype testing; we could do whatever we currently do for applying selections
• I don't know if these actions should be ordered by importance (in our opinion), alphabetically, or something else

I like it! I don't know if I would use it (mainly because I don't use a filter anyways )

What are your thoughts on putting this behind a feature flag? Or is that a huge additional effort?

Feature flag doesn't add much more effort

The Apply filter button was just for the prototype testing; we could do whatever we currently do for applying selections

I prefer the button

@annabeldunstone Hey there When you add this, please also update the docs at:

• https://docs.gitlab.com/ee/user/discussions/#show-only-comments (we'll need to change it to be named something else, for example "Filter discussion activity")
• If this will affect also work items, then also:
  • https://docs.gitlab.com/ee/user/tasks.html#view-task-system-notes
  • https://docs.gitlab.com/ee/user/okrs.html#view-okr-system-notes

@msedlakjakubowski Will do! It should only affect MRs (and will be behind a feature flag)

Also- that screenshot

Also- that screenshot

I saw this a couple days ago and thought this image needs to go, but then forgot about it

Edit: I'll create an MR to review this.
Edit 2: Fix style issues and outdated info for Discussions (!115065 - merged)

I don't know if I would use it (mainly because I don't use a filter anyways )

@iamphill Interesting! Why would you not use it? Do you find all the activity entries useful? What filter do you not use- the comments/history only one?

Curious: Would these filters also apply to Notes on the Changes tab, though?

I think the filter by author of comment could be very useful to tune out the noise of multiple reviewers at once and being able to focus on the feedback of ONE reviewer at a time would be awesome.

Curious: Would these filters also apply to Notes on the Changes tab, though?

@andr3 Good question! It looks like that's how our current history/comment filter works, so I guess we'd keep it that way. Do you see any problems with that?

I think the filter by author of comment could be very useful to tune out the noise of multiple reviewers at once and being able to focus on the feedback of ONE reviewer at a time would be awesome.

Agreed! That was also part of the MR restructure prototype:

Do you see any problems with that?

@annabeldunstone not really, but I'd recommend that somehow we keep an indicator visible that "content is being filtered" while seeing the Changes tab (which I don't think happens today).

Interesting! Why would you not use it? Do you find all the activity entries useful? What filter do you not use- the comments/history only one?

I guess I just haven't really looked into how useful for me it would be Maybe the From filter is a bit more useful, especially with reviews

@iamphill Following up from our discussion today, I had a few more thoughts:

Filters UI

I don't think I took into account the existing Sort option in the two-filter designs.

We could make both filters secondary and add the sort button on the actions filter like this:

Default filters	Filtered options

Users dropdown

• This should only include users who have commented
• Maybe we could add the Users dropdown to the Changes tab, right next to the version switcher:

To help avoid adding so many options in the filter, maybe we should group some of the actions:

All MR activity types (I think)	How they're grouped/displayed in filter
approved	Approval
unapproved	Approval
commit	Commits & branches
branch	Commits & branches
cherry-pick	Commits & branches?
merge (is this automatic merge when pipeline finishes?)	Merge request status
merged	Merge request status
opened	Merge request status
closed	Merge request status
assignee	Assignees & reviewers
reviewer	Assignees & reviewers
title	Edits
edit description	Edits
task	Edits
label	Labels
cross reference	Mentions
milestone	Tracking
comment	Comments
outdated (is this when someone comment on an outdated diff?)	Comments
lock	Lock status
unlock	Lock status
due date	Tracking
start date	Tracking
time tracking	Tracking

What do you think @iamphill @phikai

@annabeldunstone I agree that consolidating some of these things down makes a lot of sense so there aren't so many filters. I think we could probably group these even tighter as the consolidated list still feels a bit long.

Maybe an approach would be what actions are probably infrequent (dates, time tracking, lock status, others?) and group those up somehow. I can try to spend some time thinking about fewer groupings if you think that would help, but I agree with your overall premise that fewer is better here.

FYI, this is about consolidating filters in different places, but cross-linking &9937 (and @fguibert) just in case it's helpful.

Thanks for the ping and sharing the epic here. There is a lot going on in this issue so I will turn notifications off, however, please keep me in the loop during filter changes implementation.

I'm looking at consolidation at a different level, but it could still overlap.

Visually group batch comments/reviews

I've always wondered if we should change the styling of the review comments to match normal comments, but just add a badge to indicate it is a review comment

Wondering if a badge would be useful or if it would add to the general chaos (that's too strong a word but I can't think of another one) of the activity.

We could look into it though. Or a user filter that you can only filter by users who have actually left a review

Or group all review comments into a collapsible section

Improve styling of approval rule widget

Instead of having the View eligible approvers with the toggle:

Should it match the rest of the merge request widget toggles:

The avatars in the eligible approvers seems kind of pointless I would think anyways because it isn't even all the approvers, just some suggested ones

Should it match the rest of the merge request widget toggles

@iamphill That makes sense to me. How are the first 5 approvers selected? Is it completely random?

@annabeldunstone It is a list of any user that can approve, but I don't think its ordered in any specific way

Putting together a branch for this now

added 1 deleted label

added automation:ux-missing-labels label

@iamphill May also be a good time to finish up Saved replies unless it gets merged before then

assigned to @iamphill

changed the description

added typeignore label and removed typefeature label

removed featureenhancement label

removed 1 deleted label

removed automation:ux-missing-labels label

Group label additions in the activity feed (similar to description change) Merge request history lists label changes by th... (#377776)

Update styling of specific MR activity events. For example, the Merge event icon could have a green background, Approved could be light green etc

For example, the Merge event icon could have a green background

I know it is only an example but I would think we should match the color here with the status badge, so for merged it would be blue

Good point

Colors we could add:

Status	Background color	Icon color
Merged MR	$blue-100	$blue-700
Closed MR	$red-100	$red-700
Approved MR	$green-100	$green-700
Closed issue	$blue-100	$blue-700

I'm not sure about the green for approved It does match the checkmark in the sidebar, and the Approved text in the MR list view, so maybe it'll work here too

Going to be a put branch together for this

We'll want to update the system-notes docs page with this information when it exists.

@aqualls What sort of new information? Just screenshots?

@annabeldunstone Argh. I misremembered. The flavor of Markdown in GitLab-the-product supports the display of hex color chips … but the version we use in the docs site does not.

Screenshot it is, then, with some accompanying text.

@aqualls I'm lost Do you mean these docs? Why do we need to add a screenshot?

@annabeldunstone If we're using color to reinforce meaning in system notes, I want to call those meanings out in the system-notes docs. I was hoping I could use the hex numbers of each of the colors you mentioned in the table above to display colors without needing a screencap, but the flavor of Markdown we use in the docs doesn't support color chips. A screencap showing a few system notes of different colors, plus accompanying text, would be good on this page.

marked this issue as related to #356703 (closed)

Make file browser icon in MR diff page more accessible when reviewing code below the fold

added automation:ml groupintegrations [DEPRECATED] labels

added devopsmanage sectiondev labels

added groupcode review label and removed groupintegrations [DEPRECATED] label

added devopscreate label and removed devopsmanage label

removed devopscreate label

added devopscreate label

removed automation:ml label

added 1 deleted label

added automation:ux-missing-labels label

An idea, maybe improve the existing charts used in our dashboards (CI/CD Analytics, Insights, MR analytics, etc..).

The UI could be improved: colors, shades etc Functionally some improvement could be done in aggregating some data, adding some filters, etc. Not an expert here but lot of chart framework could fit: chart.js, Fusioncharts etc..

Another idea could be to improve grid view of certain pages. Like Environnement page. You need to open each environment to get some information. Having a data grid could help the global UX of the page.

mentioned in issue create-stage#13106 (closed)

added automation:bot-no-updates label

removed automation:ux-missing-labels label

Roll out MR sidebar updates globally

All SUS-impacting issues need to have a proper severity label set. Please add a severity label, remove the automation:ux-missing-labels label, and then reply to this comment briefly explaining your reasoning for providing this severity.

If you are not the DRI for this area and would like help determining the best severity, please @ the appropriate person for assistance.

added automation:ux-missing-labels label

Move Create merge request button in issues- #378018

Maybe not for this effort, but I wonder if at some point we should refactor that dropdown into a modal. The dropdown just doesn't look nice or work well in my opinion

I wonder if at some point we should refactor that dropdown into a modal.

Yes! Replace instances of DropLab with GlDropdown Vu... (#241801 - closed)

I like the idea of also moving it into the Related merge requests widget:

But that would require the widget to always exist. And the button would behave very differently than the other similar buttons (unless we also allowed users to manually link an MR, similar to linking issues).

This seems like a huge feature change though

Conventional comments in MR diffs - #354055[conventional_comments.png]

With saved replies rolling out - how would this work? Maybe for saved replies we could create a button inside of preferences that automatically creates these saved replies?

I'm not sure

The thinking behind it was making specific types of comments non-blocking (so if you add praise to a line of code, it wouldn't need to be resolved). I don't think that's been tested though so probably not worth doing

I think Saved replies is taking care of the entire UI portion though

mentioned in issue create-stage#13108 (closed)

added 1 deleted label and removed 1 deleted label

removed automation:ux-missing-labels label

mentioned in merge request !109418 (merged)

mentioned in issue #390376 (closed)

Highlight comments when navigating via the thread control

Update styling of code comments + Start another thread

marked this issue as related to #394879 (closed)

mentioned in issue create-stage#13131 (closed)