Buttons that do drastically different things should look drastically different. Seven respects that design maxim on the node edit screen by making the Save more visually prominent than the Delete. The User Save/Cancel account buttons, on the other hand, look very similar and are placed right next to each other.
Further, consider the situation where a user accounts get funky for some reason (automated import, someone messing in the database, some wonky user validation logic etc.) and the account can't be saved because it fails validation like having the same e-mail as another user on the site. If the site admin tries to get rid of this problematic account by clicking the "Cancel account" button they will get the form validation message. On the other hand, if they just go to the url user/UID/cancel they can actually delete the account.
So, for visual separation of drastically different actions and to get around a weird validation-on-data-about-to-be-deleted usability issue I propose that we change that button to a link.
This will require changes to about 13 tests, so, before I do that.... 7.x or 8.x?
Comment | File | Size | Author |
---|---|---|---|
#9 | interdiff-1649286-5-9.txt | 1.96 KB | pixelmord |
#9 | usability_bug_cancel-1649286-9.patch | 807 bytes | pixelmord |
#6 | cancel_account_link.png | 160.27 KB | pixelmord |
#6 | usability_bug_cancel-1649286-5.patch | 2.37 KB | pixelmord |
Comments
Comment #1
mr.baileysSince you refer to Seven's styling of the "Delete" button: #544398: Delete buttons look disabled in Seven theme even though they're not
I'm no usability expert, but I never warmed to the whole button-as-link thing. IMO, buttons do stuff, links take you places. With regards to the validation, it seems that converting the button to a link does not address the real issue of validation being run when it doesn't make sense, but rather is a work-around.
So it looks like there are two separate issues here:
Comment #2
Bojhan CreditAttribution: Bojhan commentedAgreed, that visually its not distinctive enough. However, since we are in UI freeze and this is not critical - I would say this is a Drupal 8 item. Also because we need to find an pattern in this.
Comment #3
vegantriathleteA related, but I believe separate, issue is also the confusing UI on the confirmation screen. Making this a link instead of a button would make the confusion even greater. See Usability bug: Cancel account confirmation screen is confusing.
Comment #5
pixelmord CreditAttribution: pixelmord at Wunder commentedI think that is a fair assessment to say the style of those links/buttons should be consistent. So I will look into patching that
Comment #6
pixelmord CreditAttribution: pixelmord at Wunder commentedI created a patch that converts that "cancel account" button into a link with .button--danger class.
I added a relationship to another issue that is about implementing the #type = danger concept for themes, see link
The patch gives the desired result if Seven is used/allowed as admin-theme, Bartik unfortunately has no styling for button--danger, so that will at the moment make the link look like a "standard" button again, but also that is another issue that needs to be solved in Bartik. If I can fin and already existing issue for that I will add that as a relationship. However as I said outside of the scope of this patch.
Comment #7
pixelmord CreditAttribution: pixelmord at Wunder commentedAdded the relationship to the other issue with confusing button labels, because we might have to rename both links to solve the related issue
Comment #9
pixelmord CreditAttribution: pixelmord at Wunder commentedOk I was thinking in the wrong direction. All the tests fail because I actually converted the form button to a link and all the tests use a helper function that expects a button with a certain text to be clicked on.
The much easier solution is to just add the appropriate classes, because Seven will then display the button styled as a "dangerous" link.
Next patch attached
Comment #10
pixelmord CreditAttribution: pixelmord at Wunder commentedI just found out that this is fixed in 8.2.x, so I guess this can be closed on this basis.
I could not find the exact issue that fixed that, but I am pretty sure that the solution there was a much better one, because it uses the concept of "button_type" and the classes are set depending on that value.
Comment #11
Gábor HojtsyThanks, removing from UX sprint now.