💬 Feedback: Merge request sidebar design updates
🐙 Note: this is enabled only on gitlab-org/gitlab and gitlab-com/www-gitlab-com
Background
This started as a simple MR to keep the sidebar only on the overview tab of MRs. The sidebar in its current state takes up valuable space across all the tabs, affecting the Changes tab in particular. We commonly hear feedback that the page is "cluttered" and that there are too many fixed elements. Additionally, there is low usage of sidebar clicks across the other tabs (roughly 15% on Changes and from what I remember, <5% across Pipelines and Commits).
As the most-clicked areas on the Changes tab were Assignee and Reviewer, we hypothesized that users were "finishing" their reviews on the Changes tab by submitting their comments and reassigning the MR. In order to help facilitate that flow we designed 🎨 Design: Add comment and approval as part of c... (#350394 - closed). Users can reassign or update any other metadata via quick action in this new "finishing comment." We know it's not perfect, as quick actions are not discoverable or known by a large amount of users, but it gives us a new component to iterate on.
Unfortunately simply removing the sidebar from the other tabs resulted in the entire page shifting to the side when you navigated from Overview (which had the sidebar) to any of the other tabs.
...which led us to the current version
List of changes:
- The sidebar only appears on
Overview -
Source branchhas been removed- It's in the header, which is also available across all tabs so the copy branch (
b) shortcut still works
- It's in the header, which is also available across all tabs so the copy branch (
- Sidebar is no longer
fixed- We realize this introduces empty white space as you scroll, which might not be ideal
- We have an open MR to experiment with making the sidebar sticky
- Feel free to check out this MR locally. Do you prefer the
stickybehavior? Why or why not? - There are extra considerations to think of here, like two independently scrolling sections
- Feel free to check out this MR locally. Do you prefer the
-
Lock statushas moved into ellipsis dropdown in header- This is an action rather than MR related metadata
-
Notificationshave moved into ellipsis dropdown in header- This is also an action as opposed to MR metadata
What do we still dislike/not get a chance to fix?
- To dos. It doesn't seem to belong with the rest of the sidebar content
- In general, the concept of a sidebar
😅 We'd love to find a way to get rid of the sidebar entirely and surface the information in a different way - The merge request sidebar is very different from other issuable sidebars (issues, epics, alerts, etc)
Links
- Merge request: Move sidebar on merge requests (!85584 - merged)
- The comments help illustrate the general evolution of how we came to this design
- Epic: ✨ Beautifying our UI (15.0) ✨ (#356703 - closed)
-
Figma file -- current implementation (beware- it's mostly a braindump of ideas
😄 ) - Figma file -- experiment with adding sidebar items to the top header
| Before | After |
|---|---|
![]() |
![]() |
![]() |
![]() |
Questions to help guide feedback (answering these would be immensely helpful but feel free to include any other feedback 🙂
- What do you notice first about the new UI?
- How do you feel about the sidebar scrolling behavior?
- How do you feel about the lack of sidebar on the commits and changes tabs?
- What do you notice about lock status?
- What do you notice about notifications? Can you locate them easily?
- What, if anything, would you change about the new design?
⚡ ️ Action items and summarized points
- Get Make sidebar in MRs sticky (!88165 - merged) updated and merged
- From my last count, 10 out of 16 people who have participated in this issue have mentioned this in some way. The main reasons I think we need to move forward with it are:
- Contextual awareness when you arrive at an MR from a comment link. Currently users need to scroll up to see the sidebar content
- Quick actions regarding MR metadata become more difficult to use as the sidebar isn't readily available anywhere but the top of the page
- No other design work needed here yet; I think it's worth adding only this functionality and seeing the feedback
- From my last count, 10 out of 16 people who have participated in this issue have mentioned this in some way. The main reasons I think we need to move forward with it are:
- Figure out a better location for
to dobutton. Should it be in the header? Does a change like this depend on aligning with other issuable layouts? - Users who exclusively use todos don't care about the new
notificationslocation. Users who exclusively use email notifications don't like the new location



