Sometimes MR Descriptions can be big and you have to scroll down to see exactly what the source and target branches are for this MR. It would be easier (and more GitHub-like) if the source and target branch was at the top of the MR above the description.
Intended users
Developers
Reviewers
Approvers
Proposal
Move the "Request to Merge to " box to the top of the merge request form:
Their use case is in the issue description... a long MR description makes for a long of scrolling to get to stuff like the "source and target branch". They feel this is more important info that should be at the top of the MR.
As @pedroms is currently ooo, I can give some first opinion:
Simply moving this widget to the top of the page creates duplicate information on the page. This was already the case, just not as obvious as they were in different spots.
We can simply remove the top line From source branch to target branch, but even then I'm still concerned about how much vertical space the current design of the Source branch and Target branch combined with the two checkboxes takes. I will try to find a layout that pulls both the Source branch and the Target branch dropdown into one line and still follows the Pajamas guidelines, that could save as more space "above the fold".
I've updated the position of the source/target branch selectors (and the associated merge params) on the MR listed above (!17559 (merged)). As noted, however, I think this will require some UX work to actually overhaul this area of the new MR screen to reduce redundancy.
If we're okay shipping this with the redundant UI, then I'm good to go, but if we need to update the UI to eliminate that redundancy, then I'm blocked for the moment.
@thomasrandolph thanks for explaining the current state and your concerns
@mvanremmerden thanks for jumping in (also when I was OOO). The example you shared is in line with what me and @jramsay were thinking!
However, since users have already gone through the “Compare branches” page, where they pick the source and target branches, it would be great if we could reduce the vertical space and have a more compact version of those stacked selects. Perhaps making them inline can solve it:
I do agree that having them in a vertical alignment is looking way better.
However, since users have already gone through the “Compare branches” page, where they pick the source and target branches.
I think there are quite a few exceptions, maybe even more than we know yet. For example, when I start a merge request from the Web IDE, I won't go through the Compare branches screen. The same if I edit a single file.
Something else that now catches my eye: If we are working in a forked project, it's at least less obvious, or maybe even completely impossible now to say whether the target of that merge request is the fork or the original project.
I think there are quite a few exceptions, maybe even more than we know yet. For example, when I start a merge request from the Web IDE, I won't go through the Compare branches screen. The same if I edit a single file.
That's true, but at the same time, in those cases, the user has just committed to the source branch and is creating a request to merge those changes (into the repo's default branch) — so the flow is providing context. Additionally, I think having those “big” selects at the top, makes the from > to even more clear and visible.
Something else that now catches my eye: If we are working in a forked project, it's at least less obvious, or maybe even completely impossible now to say whether the target of that merge request is the fork or the original project.
You mean because the target branch just says master (or whatever the default branch name is)?
in those cases, the user has just committed to the source branch and is creating a request to merge those changes (into the repo's default branch) — so the flow is providing context.
I'm not sure it's always that obvious to the user. Let's take the case where I'm in the Web IDE, working on a forked project in a branch other than the default one. I commit my changes and create a merge request. This is the information we have at the top bar of the current New merge request page:
This is the information in the section that we have in the bottom of the page in the dropdown:
If the change we make in this issue is only to remove the top bar and move the dropdowns in their current implementation upwards, we are completely removing the information what the target project is. This can lead to confusing situations for users where they can't see whether they are merging to the master of the fork or the original project.
GitHub deals with this by having extra dropdowns for source and target project right next to the branch selection.
I'm not sure, but while we're talking about it, I also wanted to ask whether it's possible to remove the dropdown for the source branch entirely.
It's disabled: true in the code (and has been for a long time), so the fact that it's a dropdown is a bit arbitrary: the user can never change the source branch, so we might as well just make it text. This holds true for the target branch, too, but only for new MRs.
I'll look into where I can get the project path into this partial. I suspect it won't be too challenging. Would this be considered something we can create a new issue for?
whether it's possible to remove the dropdown for the source branch entirely.
@thomasrandolph thanks for the suggestion! In the future we want to have the ability to change branches in the New form: https://gitlab.com/gitlab-org/gitlab/issues/15893 Also, looking at the comments in that issue, it seems like there are users that don't notice the branch selection when it's written as text only. So, having the dropdowns there (even if disabled) makes this more visible. However, I agree that the disabled state is error-inducing and not helpful. Perhaps a compromise is having the branch names more highlighted, with some color, using our code element?
Would this be considered something we can create a new issue for?
I'm hesitant to create a separate issue for the project path because it's essential information that we currently provide. If we don't get it in for the next release, we are removing that info and not providing an alternative.