Improve user interface text on the account cancellation screen

In the second option, the unpublishing cannot easily be undone - especially if the user had some unpublished content beforehand. I think the sentence is clear enough that cancelling an account is generally an irreversible action, trying to explain that the first option is technically reversible is not worth adding an overcomplicated explanation.

#3043725: Provide a Entity Handler for user cancelation could have implications/relevancy here, as it aims to provide a process for any entity type to hook into the user cancelation and take appropriate actions based on what was chosen on this form.

Do we even need the "Select the method" text any more? The user can already see the radio buttons. If we want to force them to make a choice we could not provide a default option?

Thanks for the work on this @anmolgoyal74, looking good :)

Re @6longwave in #6:

Do we even need the "Select the method" text any more? The user can already see the radio buttons. If we want to force them to make a choice we could not provide a default option?

I agree with you, during the UX meeting I made the point that the whole line was redundant. We were running low on time so agreed to revisit this issue at next week's meeting and discuss further since we'd seen the proposed changes so far. You'd be welcome to join next week's meeting if you'd also like to input on the issue at the meeting :)

As mentioned in #5, we discussed this at the Usability meeting on 2021-02-26. I am removing the tag for a review.

Help text suggestions:
When canceling the account -> Select method to:
Change the cancel account to Confirm

Getting rid of cancellation.

We discussed this again at #3200771: Drupal Usability Meeting 2021-03-05.

We have the following recommendations based on the latest screenshot in #5.

• Change the text "When cancelling the account" to "Select the method to:" (include the colon), this then leads the user into the 4 options.
• Remove " to cancel account" from the "Require email confirmation to cancel the account", so it would simply read "Require email configuration".
• Completely remove the line of text "Select method to cancel the account above", which sits above the action buttons, as this is now redundant text.
• Change the label of the "Cancel account" button to simply "Confirm". Having two buttons with one saying "Cancel account" and the other saying "Cancel" could be confusing.

There was overall agreement during the meeting that these proposed changes would make the screen much cleaner and removes the ambiguity a round the word "cancel".

An idea was raised to have the label of the primary action button change dynamically depending on which of the four options was chosen. The idea being that if either the first or second option was chosen the label could read "Disable", whereas if either the third or fourth option was chosen the label could read "Delete". It was agreed that this should be explored in a follow-up issue.

Finally, we agreed to bring this issue back for one final look and sign-off once these changes had been implemented.

+++ b/core/modules/user/src/Form/UserCancelForm.php
@@ -58,7 +58,7 @@ public function getDescription() {
     if ($this->selectCancel) {
-      $description = $this->t('Select the method to cancel the account above.');
+      $description = NULL;
     }

$description should be a string rather than NULL. This entire if statement could be reworked a bit to make it simpler, but not sure it is worth it.

@anmolgoyal74

Thank you for the updated screenshot and patch.

The question of what the user sees when cancelling their own account did come up at the last UX meeting, would you mind also posting a screenshot of that interface as it currently is in Core, and then a second screenshot of what it looks like once the patch is applied?

Thank you.

Attaching the screenshots for: "what the user sees when canceling their own account"

Before Patch

After Patch

Marked #2978063: Give information to user whether account is disabled or deleted when cancelled as postponed on this issue, seems like a good issue to look at once this is addressed.

I am transferring credit from the duplicate issue #1649286: Reword user cancellation form buttons.

We looked at this issue at #3201985: Drupal Usability Meeting 2021-03-12.

The group were happy with the latest text changes for the administrative interface.

Regarding potential impact and any text changes on the user facing interface (as seen in comment #18), we were happy with changes that the patch would make, but we did agree that a follow-up issue should be created to look more specifically at the text on the user facing screen. This would be in addition to the follow-up issue that was suggested in #11.

Overall though, the UX group are now happy to sign-off on the proposed changes this issue will make.

Tagging needs issue summary update, as it probably needs a slight update.

Edit (next day): I remembered this morning that during the meeting it was also noted by Benji that the spelling of the word "cancellation" (in the "require confirmation email" description) needs to be changed to the American English spelling "cancelation".

Updated Tests and made changes to the cancellation form as per #33.

The Drupal Cspell word checker is not considering "cancelation" as a part of valid word , so I have added it to the spell library.

Fixing fail tests and created patch, Please have a look.

+ '#description' => $this->t('When enabled, the user must confirm the account cancelation via email.'),

The word "Cancelation" and "Cancellation" both correct but we should use "cancellation" in this case:

+ '#description' => $this->t('When enabled, the user must confirm the account cancellation via email.'),

It's because there is this word in other comments. E.g.:

// Repeat with permission to select account cancellation method.

So we need to be consistent, to use the same standard in the file

So another possibility is to change the comments to use "cancelation" as well

From:
// Repeat with permission to select account cancellation method.

To:
// Repeat with permission to select account cancelation method.

Changed "Cancelation" to "cancellation" as mentioned in #40. Please review.

Removed 'Cancelation' from the dictionary.txt and Fixed fail test.

See note in comment #33 from UX group review, the spelling should be "cancelation".

Edit (next day): I remembered this morning that during the meeting it was also noted by Benji that the spelling of the word "cancellation" (in the "require confirmation email" description) needs to be changed to the American English spelling "cancelation".

So in all cases it should be "cancelation" not "cancellation".

There's a whole article on Grammarly about this which suggests "cancellation" is correct for US and UK English: https://www.grammarly.com/blog/canceled-vs-cancelled/

Noting the existing signoff from UX group on this, I want to note that the most recent screenshots (#18, #39) show a button labelled "Cancel" which has the action of "don't cancel the account". This might be confusing to some folks?

Needs a re-roll.

Re #47: Thinking about that for a bit, I kind of, sort of agree, that maybe this could be another point of confusion. But then the pattern of "Confirm" and "Cancel" is a very common pattern that's recognised across systems and interfaces, however we are using the word "cancel" with different meaning in the same UI, which is a big UX problem.

Okay, I'm going to bring this issue back up at a usability meeting and get a recommendation, so self-assigning for now.

Queuing for review at #3228187: Drupal Usability Meeting 2021-08-20 or a future meeting, thanks.

As per comment #49, we discussed this at #3228187: Drupal Usability Meeting 2021-08-20.

We discussed the potential for confusion around the use of the word "cancel" to mean two different things. The word "cancel" is used for the "Cancel" button to mean "abort this action" (the opposite of "confirm"), and is also used to refer to the action of cancelling the user. We agreed that this is a problem and a potential source of confusion.

We did not want to recommend changing the text of the "Cancel" button, as the "Cancel" button is a generally well used and well understood pattern. We did propose the idea of changing the use of "cancel"/"cancellation" (in the context of cancelling the account) to use the terms "Close" and "Closure". In other words, that would mean instead of saying "cancel account" we would say "close account"; We noted that this is a well understood pattern, the specific example being of a credit card or bank where users understand the process of "closing" their account.

We decided to recommend changing this as part of a follow-up issue. This is because we identified a number of other areas where the this change would need to be made, and in addition changing the path of the form, which would be seen as a backwards compatibility break and so would need to be done in a major release (aka in 10.0.x).

I'm leaving this as Needs Work because we found that there is a companion "Account cancellation" form for bulk cancellations, and that form will also need to be updated to match the changes to the UserCancelForm. Essentially that means copying the changes made in Drupal\user\Form\UserCancelForm to Drupal\user\Form\UserMultipleCancelConfirm.

We also noted that a reroll for 9.3.x is still needed as the latest patch fails to apply due to changes in the tests.

Thanks.

Filed #3229136: Rationalise our use of "block" and "disable" relating to users which we discovered as a problem while reviewing this issue.

Also filed #3229146: Rename "Account cancellation" to "Account closure" in UI as per comment #50.

In a previous review in comment #11, we recommended filling a follow-up for dynamically changing the primary action button text depending on if one of the disable or delete options are chosen, however we now feel the "Confirm" option is sufficient and this would probably just be more work for very little benefit, so removing the follow-up tag now.

Working on it.

I moved the issue to MR approach and added the changes to UserMultipleCancelConfirm.php as well.

Hi, changes look good.

Steps performed:
(1) Got changed code.
(2) Code review.
(3) Basic sanity test.
(4) No errors in log.
(5) Run Unit Testing: BulkFormAccessTest.php

I think this is a great cleanup, however I'm not sure about the 'Select the method to:' label to the field.

I don't think this conveys what the field set is doing to a non-sighted user. And I'm not sure it is the right text for a sighted user either.

Not professing to be a UI expert, so will yield to the team - but I think the `to:` on the end is what's giving me pause.

Thanks @larowlan that's a really interesting point, and I can see where you're coming from.

I'd be interested to get some input on that from an accessibility maintainer as I have a feeling your right and that might be something we overlooked. As someone with a visual impairment myself, I can definitely see where this might cause problems for users of screen readers and those using keyboard navigation.

Thanks,
-Aaron

I raised this in the accessibility channel on Slack, however haven't gotten any feedback yet, I will also bring this back up at a usability call, so have queued it for next weeks meeting #3232405: Drupal Usability Meeting 2021-09-17, thanks.

We looked at this issue during #3232405: Drupal Usability Meeting 2021-09-17, specifically regarding comments 57, 58 and 59.

After some discussion around the wording of "Select the method to:", after brainstorming some options we settled on the wording "Select the cancellation method" (without the colon).

This felt the most concise while still conveying what the choice is that the user is required to make.

Updated MR for this. A few notes!

I was unsure about the trailing colon, and in Aaron's comment above it is removed. I have removed it. I could not find any mention of whether trailing colons are appropriate for option list labels in https://www.drupal.org/docs/develop/user-interface-standards/interface-text ... EDIT: You said "without the colon" right there, I missed that first time!

While looking for that guidance I noticed that https://www.drupal.org/docs/develop/user-interface-standards/radio-buttons includes the text

Avoid (...) beginning with "Select to…" or "Choose to…" because these are usually redundant.

(I didn't participate in that meeting, so the MR accepts the text as proposed and I'm flagging that guidance for visibility.)

MR also changes two inline docs strings, tidy up but happy to remove if those aren't appropriate here.

Re #61: That is a good point, thanks for raising the Ui standards. The spirit of the discussion during the meeting was essentially: what are the fewest possible words we can use to convey what the options represent. If our UI standards advise against "Select...", and since we follow the practice of less is more, I'd say going with simply "Cancellation method" is probably fine.

NW for the removal of the if statement and I think all unresolved threads can now be resolved. Also if we could get an updated screen shot in the issue summary that would be helpful given the change to the field label.

Thanks,
-Aaron

It's great to see that what we discussed in the UX Community meeting the other week is being incorporated. Everything appears to be on track and I wanted to thank the folks working on this for adjusting to our suggestions.

Updated IS with the new interface and attached a screenshot of the UserMultipleCancelForm.

Moving issue to RTBC.

Thanks for the screenshots and update Paulo, although I'm getting this back to NW because there are some unresolved threads in the MR.

I also noticed from your screenshots that the change in the label text to "Cancellation method" only seems to have happened for UserMultipleCancelForm, UserCancelForm still seems to be using a previous iteration of the label.

Once the outstanding thread are resolved, I think this can to go back to RTBC, thanks.

Resolved all threads and attached screenshots.

Alright, this is looking good, happy to RTBC this!

One minor nit on the MR for readability (my campaign against else continues!)

Tagging as a string change as there's three changes here.

That means this can only change in 9.3.x (i.e. can't be backported).

Also are we sure this is a bug? It feels like a task to me.

Left a comment on the MR to confirm that we're sure about the latest string change (I think its good, but just looking for a +1 yes we know its a translation break)

Agree this is not a big, reclassifying.

I removed the 'else' but not what was inside it, because if the #confirm_description is not set, the getDescription() method should return $this->cancelMethods['#options'][$default_method]; as it was before. Does it make sense?

About the string change mentioned in #74, i agree with the points that @xurizaemon wrote in #75 and makes sense to have them changed.

+1 to removing the else statement, I will happily join @larowlan on his campaign against the else!.

Agree I think changing the text is a worthwhile change here.

Taking the opportunity to retitle this.

Take 2.

I think we need to work on the new test a little more. There is no such thing as permanent delete vs another delete in Drupal.

Thanks Alex, I have commented on the MR.

Attaching screenshots and updating IS.

Latest change has gone green, think we're all good here again!

Saving credits

Thanks all for being accommodating of the numerous rounds of changes here

Merged to 9.3.x

Yay 🎉

Thanks @larowlan!

For anyone looking to help move along some related issues, it would be great to get some of these moving along:

• #2978063: Give information to user whether account is disabled or deleted when cancelled: unblocked now by this issue;
• #3229136: Rationalise our use of "block" and "disable" relating to users: Follow-up from a UX review of this issue, would be great to start pushing this one now, seems like a natural next step;
• #3229146: Rename "Account cancellation" to "Account closure" in UI: Another one that came from UX review, already has some work done on it, doesn't need much more to get it over the line, also a good next step;
• #2980952: Wrong message on cancelling account with e-mail confirmation request: Looks like a fairly straightforward UI text imporement issue, I don't imagine much would be needed to also get that done.

Adding release highlights tag in case there's space for this, if not feel free to remove.