Reconsider two-click action dropdowns

Description

I know of two places where we have dropdowns that trigger an action but require two clicks to do so:

• create a branch from issue:

• report abuse on issue / merge request page (EE only):

After clicking on the desired action, the user needs another click to execute the action.

I don't like this behavior for the following reasons:

• When a user clicks the action, they make a decision. Forcing them to make another click is like rejecting their decision.
• Both actions (creating branch / reporting abuse) are not destructive. So extra thought put into the user decision doesn't provide benefit.
• The check mark indicating what action is select is used for persistent states at other places (notifications / sort order) which remains upon page reload. This is not the case for these buttons.

Proposal

Either

• remove check marks and execute action on first click
• use more actions (...) button like we do for comments:

/cc @sarrahvesselov

mentioned in issue #36536

@winh thanks for creating the issue, I agree that this can definitely feel like an “odd” and “slow” interaction model.

My suggestion, based on your thoughts:

• Don't repeat the main action in the dropdown
• Execute action on click, don't switch the main button
• For actions that need additional clarification, like the “Create merge request” button, we can show that help text in a tooltip when hovering the button. For actions in the dropdown, we can place the help text below the action label, like we do today.

About the ellipsis icon (…), I think it's more common to have a caret/triangle to signal secondary actions which are related to the main action, in a segmented dropdown button, like the examples you posted. I would expect to see the ellipsis as a standalone option to group secondary actions which are not related to any of the main actions.

@sarrahvesselov thoughts on this paradigm? @tauriedavis I think we were discussing the chevrons/carets for dropdowns and selects in another issue, maybe you have thoughts on this as well?

Thanks for making the issue @winh!

• Don't repeat the main action in the dropdown

• Execute action on click, don't switch the main button

• For actions that need additional clarification, like the “Create merge request” button, we can show that help text in a tooltip when hovering the button. For actions in the dropdown, we can place the help text below the action label, like we do today.

I don't feel very strongly about this one way or the other. I think that what you have outlined makes sense @pedroms.

The one thing I will say is that @winh stated in the description that the actions are not destructive so no added friction is necessary. Since this dropdown paradigm is used in many places, that is not always going to be a true statement.

@pedroms your suggestion sounds good to me!

the actions are not destructive so no added friction is necessary

Since this dropdown paradigm is used in many places, that is not always going to be a true statement.

@sarrahvesselov currently we have confirmation dialogs / dialogoids in place for immediate destructive actions. will that change in the foreseeable future?

I created this issue a few months ago to standardize the way this button performs: https://gitlab.com/gitlab-org/gitlab-ce/issues/30525

I think that the majority of our split dropdown buttons have no ill consequences if the action was performed immediately. I do worry about the Merge immediately button, though. This could cause problems if clicked accidentally. Is there a confirmation for this action?

There might be others like this as well. We should catalog where we are currently using this button, and ensure that performing the action immediately won't cause any bad consequences.

There might be others like this as well. We should catalog where we are currently using this button, and ensure that performing the action immediately won't cause any bad consequences.

I agree with @tauriedavis here.

currently we have confirmation dialogs / dialogoids in place for immediate destructive actions. will that change in the foreseeable future?

No, but we should ensure that these are actually in place for destructive actions as @tauriedavis suggested.

I do worry about the Merge immediately button, though.

Is there a confirmation for this action?

If not, it wouldn't be too difficult to add one, I guess. However, I think we should decide on one way to introduce friction: either two-click buttons or confirmation dialogs.

We should catalog where we are currently using this button

I have made a list of all dropdowns: https://gitlab.com/gitlab-org/gitlab-ce/issues/28921#note_36011920

From making that list, I only remember the two places above. But I can't guarantee I forgot one of course.

If not, it wouldn't be too difficult to add one, I guess. However, I think we should decide on one way to introduce friction: either two-click buttons or confirmation dialogs.

Agree, currently it is with the two-click buttons.

From making that list, I only remember the two places above. But I can't guarantee I forgot one of course.

There are more than just those two in the issue description. For example there is this one as well:

Before we decide to switch, we should feel confident in the list. Maybe someone can go through the list you made in the other issue and find all the split dropdown buttons. If we decide to change the UX of these buttons, confirmation dialogs should be added to the actions that have potentially bad consequences at the same time.

Maybe someone can go through the list you made in the other issue and find all the split dropdown buttons.

I need to go over the list at least once after cleaning up the CSS for 10.0 anyway, so I can do it. I'm assigning this issue to me so I don't forget.

assigned to @winh

mentioned in issue #31342 (moved)

None of the other droplab buttons I can find on the site are split and all of them execute the action as soon as you click a menu item. That is more consistent with other interfaces I have used. The current comment button makes it hard to discover discussions which promotes comments over discussions. It would be more consistent for the button to say "Post" and have "Comment" and "Discuss" items that execute immediately. The "Comment & close ..." button should be part of that menu, because it takes up a ton of real estate.

https://medium.com/designed-thought/drop-down-button-vs-split-button-f8e539fc0b78

https://gitlab.com/gitlab-org/gitlab-ce/issues/31342#note_39034277

I found the split comment button confusing, because sometimes there is a button adjacent to it. The split button may initially appear as if it is just a dropdown menu, which makes the adjacent button feel like the apply button for the menu.

I would prefer getting rid of the split buttons, using a neutral label for droplab buttons, and requiring the user to pick an action that executes immediately (unless warned by a secondary prompt). Providing a default action makes it harder to discover the other actions.

mentioned in issue #37289 (closed)