Improve ergonomics for validation form

With an ergonomics approach, the "Save changes" button should be on the right.
I suggest you to read my answer about that. https://www.nngroup.com/articles/ok-cancel-or-cancel-ok/

Proposal

Dismissive actions on the left

The dismissive action returns the user to the previous state.

Example: Cancel

Affirmative actions on the right

Affirmative actions continue to progress towards the user goal that triggered the dialog or form.

Example: Submit, Ok, Delete

added ~19492 label

Thanks for sharing, @kwad! One question - your examples show 2 buttons: Ok and Cancel. I can see how we could want the recommended option, in this case Save, to be on the far right, and thus the resting spot for the eyes. But in this case, how would we handle the 3 buttons: Save, Delete, and Cancel. Should Cancel always be on the far left of the button group (so it is consistently the first button you come to), or should Cancel always be in the same space, the 2nd from the right button?

Thoughts on this @tauriedavis @cperessini? Any reasons you see to keep Save changes on the left?

This is something I've thought a lot about since starting at GitLab. I've always leaned towards the recommended option - with the primary button being on the right as this is the way you read. Adding another button does of course make the order a little more complicated but one option is just a matter of reversing the order completely so that cancel is always in the same position: Cancel Delete | Save

There is also the option where the destructive action is place on the left, and the edit options are grouped: Delete | Cancel Save

The comment box would become: Discard draft | Comment & close issue Comment

All that being said, the most important factor is consistency - like the many articles linked from that the stack overflow question point out. I think it is OK to leave the buttons as they are since they are consistent throughout the website. I can't remember if there was an original reason for the current order so it's great to have this discussion (again). :)

I agree, the most important thing is to be consistent. About the 3 buttons: Save, Delete, and Cancel we can also approach the issue with a different way:

Why is there a delete button in the same place where there is a save button? When the task is to edit a ticket, the buttons should only be save and cancel. Deleting a ticket is a separate task that should occur on the screen before this. Mixing delete and cancel button together can cause confusion and errors because the two buttons are very similar.

Think of it like this. If the user's task is to edit a ticket, which buttons are necessary for this task? Save completes it, but Cancel aborts it. Deleting a ticket is not part of editing. It's a completely different task. You shouldn't mix the two on the same screen.

@kwad I completely agree with the quote you posted above. This is how I have handled delete and cancel before as well.

It felt out of scope for this issue but maybe it is not after all.

What do you think @awhildy?

mentioned in issue gitlab-foss#26205 (closed)

mentioned in issue gitlab-foss#26679 (closed)

mentioned in issue gitlab-foss#27464 (moved)

Maybe we could get this scheduled or added to Backlog @awhildy ?

changed milestone to %Backlog in gitlab-foss

added ~897282 label

To be able to implement this, we should come up with a model that works for 3 buttons. While I want each flow to be simple and direct, with a single action/cancel option -- that is going to take time to work through, and will have to be on a case-by-case basis. I would say in an effort to keep this issue doable, we should scope it to the ordering of buttons, and open separate issues for any simplification needed.

On that front, let me see if I understand the proposal:

• Yes/Ok/Accept/Submit (Green buttons) should always be the farthest right.
• No/Cancel buttons should always be the farthest left.
• Any secondary button should be grouped on the inside of the side that it is most related to. This will most typically be the right side.

For the secondary buttons if it is related to submitting or going forward with the issue (such as 'Comment and close') it should be next to the submit button (in this case 'Comment'). If there are cases where we have 'Delete' and 'Cancel' (while we can create separate issues to simplify this), for now, we should put 'Delete' on the inside, next to 'Cancel'. Cancel should always be in the same location.

Does this make sense @tauriedavis? If so, I'll quickly document it, and see when we can schedule this for. This sort of change would ideally be scheduled for 9.0 as it is disruptive. I will have to look into what resources we still have available, though.

Lost comments

From @tauriedavis:

Yes, I think this is a good first step and we can work on the cases where we have Delete and Cancel in a separate issue. Thanks @awhildy !

Then I asked about keeping the button for the main action on the right side even if it was a destructive action.

And @tauriedavis commented:

I cant currently think of where Delete is the primary action. Where are you referencing @cperessini ?

So here's an example of that:

Is that a new modal for issue boards? Currently there is no delete modal since you can just add the board back super easily.

@tauriedavis It's currently live on GitLab.com, I don't know when it was implemented

Oh weird, I was just deleting boards locally the other day but didn't remember that modal (probably just forgot). Maybe it is better to have an undo state here rather than a modal?

To answer your specific question though, I think it is most important to clearly label the buttons (which they are) and create consistency through a guideline. From our guideline above, primary actions are on the right and cancel/return actions are on the left. I think a better phrased guideline is what Google says:

The dismissive action of a dialog is always on the left. Dismissive actions return to the user to the previous state.The affirmative actions are on the right. Affirmative actions continue progress toward the user goal that triggered the dialog.

This would mean that Delete is on the right and Cancel is on the left. Apple has a similar guideline.

Microsoft does the opposite though. Here is a good article https://uxplanet.org/primary-secondary-action-buttons-c16df9b36150#.2eqohhlzn

Thoughts @cperessini ?

Side note: I just see this system modal for deleting boards:

I like Google's wording. Cancel is a constant element in most of our dialogs, independently of if the main action is positive or negative.

---

The dialog I posted was for deleting a whole board and yours is for deleting a list in a board But seeing that they're different, we should make them consistent. Or if we want to remove the dialog for deleting a list I would definitely include an undo button.

mentioned in merge request gitlab-foss!8972 (merged)

mentioned in issue gitlab-foss#28078 (moved)

mentioned in issue gitlab-foss#28717 (closed)

There's not a single answer to this, as it depends on the context and layout used.

For small contexts such as dialogs/modals which only have text, I agree with placing the actions on the bottom right with the affirmative/forward action coming last. This is what @kwad suggested, referring to this article. The users' scanning flow zig-zags from left-right top-down, so it works well.

However, I don't agree that this placement and order works for forms. In this case, users' scanning flow follows the placement of the form inputs (usually top-down). Aligning the actions with the form inputs (usually on the bottom left) with the affirmative/forward action coming first performs better.

Take the “New issue” form as an example:

Left (aligned with inputs)	Right

It's interesting that in the test you linked, they only tested placement when the buttons were of equal weight which doesn't give good insight into the design solution we came to here: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8972

I think it is more important to be consistent here throughout the app. It doesn't make sense to have the primary action right aligned on dialogs but left aligned for forms. This is hard for muscle memory.

added ~974571 and removed ~19492 labels

mentioned in issue gitlab-foss#28849 (moved)

@tauriedavis I agree with being consistent. However, as we can see in these examples, confirmation dialogs are different as they represent a “warning step” that we place between the user's intention and the final decision before a destructive action. For that reason, having the buttons in a “not so easy to click” position (right aligned) might be the best choice for confirmation dialogs.

So, for all situations, except confirmation dialogs, the buttons would be left-aligned, ordered from Affirmative > Dismissive. Example: Save changes, Test settings, Cancel

For confirmation dialogs, the buttons would be right-aligned, ordered from Dismissive > Affirmative. Example: Cancel, Block user, Delete user

What do you think?

@pedroms The two articles you referred are interesting and useful. However, I think it's important not to confuse different particular contexts.

For example, the problem with the second article you referred is that it's about one specific case: a sign up form, which is short with all inputs aligned on the left in one column (the right side is empty). If we take a different case, for example the second picture in the first article you referred, the button is now better on the right.

In the context of a sign-up form, we want to ensure that the user won't abandon the form. Generally the user will use this form one time only, so the consistency can be less important in this specific context.

However, in our case it's not a problem having the buttons placement on the right because the form is not short, has many columns and it uses all the space (the right is not empty). As @tauriedavis mentioned, the brain is used to expect the buttons consistently on the same side everywhere in an application. And for the reasons that I already mentioned, I think it's still better having the placement on the right everywhere.

@tauriedavis what's your opinion regarding https://gitlab.com/gitlab-org/gitlab-ce/issues/26248#note_26082532 ?

I think it is better to have consistent placement everywhere. I think mixing up the order and placement for confirmation dialogs may lead to people mis-clicking from muscle memory.

changed milestone to %Next 2-3 months in gitlab-foss

marked this issue as related to gitlab-design#30

mentioned in issue gitlab-foss#36069

added Discussion in GitLab FOSS label

marked gitlab-foss#38581 (closed) as a duplicate of this issue

mentioned in issue gitlab-foss#38581 (closed)

moved from gitlab-foss#26248 (moved)