Open klonos opened 3 years ago
I agree with @jlfranklin that "cancel" seems odd in this context (and in this specific form, having both a "Cancel account" and a "Cancel" link side by side does feel odd).
Having said that, I see @indigoxela's point re different ways to "cancel" an account, so there may be valid reason for it to remain as is. For instance, we provide the options to either "disable" or "delete" an account, and right after that we have a checkbox that needs to apply to both of these actions, which uses the word "cancel" in its text (to be applicable for both actions). If we don't use the word "cancel", then what do we change the text for this checkbox to? We'd need to dynamically change the text to say "Require e-mail confirmation to disable (the) account" or "Require e-mail confirmation to delete (the) account" 🤔
Anyway, my other thoughts with re to this form are:
Maybe not a big problem, but another situation needs to be considered: the word appears in the form to let the user "cancel" their own account. And also for admins to "cancel" other peoples accounts. And there's a permission "Select method for cancelling own account", so some roles may have the choice how to delete (or block/disable) their account and others have not.
Thanks for opening the issue @klonos! Let's see if we find a term which is able to replace "cancel" (and "block"). As an experiment, I've looked up "to cancel" in an English-German dictionary, picked convenient German translations and re-translated them to English: The result is a list of alternative terms. However, I'm not a native English speaker, so for me it's hard to say which terms from the following list, if any, could be considered suitable alternatives which cover both "disable" and "delete":
In the context of user accounts:
The rest of the terms you listed @olafgrabienski are not fitting as replacements for "block" or "delete" (at least not in the context of user accounts they aren't).
I can't think of any word that would apply to both the permanent and non-permanent actions. I suspect the Drupal devs couldn't years ago when they added this feature, and settled on "cancel".
I can see two possible ways forward here: relabeling the existing single menu item "Suspend / Delete" (or "Suspend / Terminate"), OR splitting it into two menu items, one for "Suspend" the other for "Delete" or "Terminate". The former is simpler. Same on the form itself, we can relabel the Cancel Account button as "Suspend / Delete" or split it into two buttons, and use #states
to show one of them. (Can #states
relabel a button?)
Splitting into two separate menu items would allow finer permission granularity. A customer support role could suspend an account pending review, a site manager is required to delete them. Or a user could be allowed to suspend themselves, but not delete themselves.
I'm leaning towards relabeling the existing menu items and form button, and leaving the more complex solution to contrib. Machine names for the buttons and menu items can stay the same.
On Delete vs Terminate, I have no strong opinion.
I would like to discuss this further in the next UX biweekly meeting.
Our Drupal brethren (their UX team) seem to have decided to rename "Account cancellation" to "Account closure" in the admin UI: https://www.drupal.org/project/drupal/issues/3229146
Problem/Motivation
During the work on #3199972: Update Help text on account cancellation screen and while reviewing that issue at #3228187: Drupal Usability Meeting 2021-08-20; It was highlighted that, relating to disabling/deleting/cancelling users, we use the terms "cancel"/"cancellation" to mean different things and in direct contradiction.
For example, on the Account Cancellation Form, in the title we use "cancel" to mean "cancelling the account" but further down the form we have a "Cancel" button which means "abort the current action". This is confusing on its own but potentially even more so for non-native English speakers.
Proposed resolution
During our discussion at #3228187: Drupal Usability Meeting 2021-08-20 we agreed to open this follow-up issue with the following.
The agreement was that we should remove our usage of "cancel"/"cancellation" relating to cancelling a user, and instead use the terms "close"/"closure".
We agreed that "closing an account" or "account closure" is a well understood term, for example banks use this term when a customer wants to "close their account".
Also, in Update Help text on account cancellation screen they seem to have decide to add the word "Permanently" to any dangerous/irreversible account cancellation options (I've included that in my PR for #5283).
I agree, "to close" and "closure" are reasonable (and better) terms. What do others think?
Also agree: "to close" and "closure" are clearer.
Does "close" or "closure" mean my user data is deleted from the system? Or kept for eternity?
I personally like when sites use the word "delete" because it is a better indicator of what is supposed to happen to my data.
When I "close" an account at a bank for example, the data they have on me is never deleted.
"Closing" the account (in Backdrop) is only the first step ...we aren't a bank, so we offer people the option to delete all data if they wish 😄 ...saying "delete" when in fact the next step gives you options to (optionally) retain things doesn't feel right (delete, but don't delete).
@klonos alright. Never had to delete an account on backdrop before so if there's a second step, then close is ok as long as the user understands "there's another step" to delete data. It's honestly been so long since I've "closed" a user facing Drupal account, I don't even remember how D7 handles it. Carry on.
... so we offer people the option to delete all data if they wish smile ...saying "delete" when in fact the next step gives you options
That's not completely correct, though, because that depends how Backdrop is set up. The second step may offer options, if the user (role) has sufficient permissions, there won't be any options, if they don't.
Following is relevant:
1) Account settings /admin/config/people/settings, "When cancelling user account" - which sets the default 2) Permissions /admin/config/people/permissions - whether a role has permission to choose, how that cancelling happens.
This is what the second step looks like if the user (role) has no option to switch:
This is what the second step looks like, if the user (role) has permission to "Select method for cancelling own account".
Personally, I still think that "cancel" for sure isn't 100% appropriate, but it's a compromise I can live with. As @jlfranklin already stated in a previous comment:
I can't think of any word that would apply to both the permanent and non-permanent actions.
Looking at these two screenshots... Wait, maybe we can not fix the wording everywhere, but we might be able to dynamically switch the button text in the second step depending on either the predefined site-wide action or the action selected with the radios above.
What do people think? Is it worth the effort?
@indigoxela I like it. Close account "if" radio = disable and Delete account "if" radio = delete. The UX would be more synonyms with what is actually chosen.
What do people think? Is it worth the effort?
Have you checked out my PR for #5283 @indigoxela? ...if you test things in the PR sandbox, you will see that I am switching between a "plain" primary and a "danger" button, depending on whether the action selected is reversible or not. Under the hood, these are 2 buttons, that are being hidden/shown via #states
. So we could have make them also have different labels ...so I guess what I'm saying is that there is little effort, since the PR is there - we just need to decide on the button labels here 😉
Seems we're trying to do two things here:
Regarding (1), we have an interesting suggestion with "close" and "closing". It got some positive feedback, and it would improve the situation even without (2).
I can't think of any word that would apply to both the permanent and non-permanent actions.
Does that remark also apply to the term "close"? In my understanding "closing" a user account can represent both actions in the same way as "cancel" does. At the same time, it avoids the downsides of the "cancel" term (ambivalent meaning, simultaneous presence of the "Cancel account" button and the "Cancel" link).
So, regarding (1), I'd still suggest to replace "cancel" and "canceling" with "close" and "closing".
I, too, find that "close" encompasses both disabling and deleting in meaning. So I agree with those who suggest using "close" and "closure".
Having the button and warning label change depending on whether disabling or deletion is chosen, as demo'd in @klonos's PR for https://github.com/backdrop/backdrop-issues/issues/5283, is also clear. Giving them different labels (as klonos suggests above) in addition to the formatting and warning message would also make it clear what's about to happen. So "Disable account" and "Delete account" as button labels makes sense and is consistent with the radio button choices.
Oh, and of course we'd change "Cancellation method" to "Closure method" as the label for the radios.
TBH, I'm fine with keeping the danger button, because no matter what the action is - for users cancelling their own account, the action can not be undone and will be their last step in that Backdrop install.
Trying to do too much (different things) in that form is probably more difficult, than it may seem at first sight, because to my understanding the same form has to cover different situations (admin / unprivileged user / disable / delete / with and without choice...). Adding even more complexity should be avoided.
Trying to switch the whole terminology everywhere (this issues actual topic) seems like a bad idea to me - but that's my personal opinion.
Trying to switch the whole terminology everywhere (this issues actual topic) seems like a bad idea to me
First, thanks for reminding the actual topic of this issue. I hadn't seen the separate issue about buttons and labels.
And I'm curious: Why do you think it's a bad idea to switch the "Cancel / Cancelling" terminology in the context of user accounts?
Why do you think it's a bad idea to switch the "Cancel / Cancelling" terminology in the context of user accounts?
"Cancel" is currently used everywhere. We could - with quite some effort - including updating lots of translations - replace it with another word. Which also wouldn't fully fit. So we'd put effort in changing something, that's not perfect (we agree on that!), to something else, that's not perfect, either. Worst case we even cause more confusion. So why bothering? Again: personal opinion.
The other issue (#5283) tries to do less, but with immediate benefit: displayed word consistent with selected action.
Thanks for your feedback! I still don't get why "Close" wouldn't fit better than "Cancel" in the user account context. Sure it's not perfect but "Cancel" has a specific problem. It is used to express two different things in Backdrop:
(1) Stop or interrupt an action (instead of hitting the "Save" button you use the "Cancel" link) vs. (2) Perform an action (Delete or Disable a user account).
PS: Maybe there's a misunderstanding. I don't suggest to change "Cancel" everywhere but only in regard to user accounts.
Maybe there's a misunderstanding
Yes, I agree on that. :wink:
This issue here suggests to switch the wording "cancel(ling) (user account)" everywhere throughout Backdrop, the other issue just tries to fix one form.
FTR, I don't expect us to file any PR here - just decide on what wording changes that should go into the PR for #5283 re the action being performed. The assumption is that the "Cancel" link in the form submit actions remains as is (for consistency with all the confirmation forms throughout the entire Backdrop admin UI). I've created this separate issue here because I could see how the discussion would drag on 😅
@jlfranklin brought this up in https://github.com/backdrop/backdrop-issues/issues/5118#issuecomment-864011695
@indigoxela provided the following argument:
Here's that confirmation screen with the various options: