Establish a pattern and improve consistency of controls for destructive actions

[afercia]

Description

Follow-up to #58083 as this is a broader issue across the editor user interfaces and not limited to the Font Library.

Historically, controls for destructive actions in WordPress core use the color red.

While for accessibility color alone isn't sufficient to convey meaning, red is a pretty established convention since ages and help at least visually. That is not to say that this pattern is consistent in Core. There's some work to do and that is tracked in this Trac ticket:

https://core.trac.wordpress.org/ticket/49714

After considering ticket #49603, we think that WordPress should take a look at the consistency of informing users when they are in a destructive context and when a control will have destructive consequences.

In the editor the styling of destructive controls is mixed, at best, and there's some large inconsistency.

The most promminent place of a destructive control in the editor is the 'Move to trash' button:

This button establishes a convention. I would expect all other destructive controls to use red.

Some of them do, for example the new 'Delete' button in the Fonts modal dialog.

Some don't, for example the 'Delete' button in the Fonts confirm dialog and others.

For a clearer UI and a better user experience, I'd think the editor should use a well established convention, establish design guideliens, and make them consistent e verywhere, including the Core classic admin.

A couple screenshots:

Worth reminding that all the three main button variants (primary, secondary, and tertiary) do have a is-destructive styling that uses red. Example:

Step-by-step reproduction instructions

N/A
Just observe hte vaarious controls for destructive actions in the editor have inconsistent styling.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[andrewhayward]

The 'Button' component has an isDestructive prop for just such occasions!

[afercia]

Looking back into this issue, it appears the inconsistency in the editor is larger now. I'd suggest to consider give ore priority on this issue as destructive actions should always use a consistent pattern. Cc @WordPress/gutenberg-design

To recap:

• Historically, controls for destructive actions in WordPress have always been red.
• The controls in the editor use largely inconsistent colors.
• Also, regarding menus, sometimes there is a separator before the destructive action and sometimes not.
• Lastly, the documentation for the data views actions appears to state something that isn't always true:

isDestructive: boolean, optional. Whether the action can delete data, in which case the UI would communicate it via red color.

A few screenshots from latest trunk, not pretending to be representative of all occurrences:

[jameskoster]

Totally agree we need to be consistent about this.

A simple rule of thumb we might consider is to reserve the destructive button variants for actions that are irreversible.

The 'Move to trash' button is a curious example. If we followed the logic above then it wouldn't be destructive because trashed posts can be restored. If we're going to use destructive variants for reversible actions then there's going to be a lot of red in the UI which will trivialise truly destructive actions.

If keeping 'Move to trash' as destructive is preferred, then we should apply consistently, and consider a treatment for truly destructive actions—perhaps they utilise a confirmDialog?

cc @auareyou who has been thinking about this.

[afercia]

The 'Move to trash' button is a curious example.

Yes I'd agree it is. However, for published posts, trashing means that a published post gets unpublished. It disappears from the front end. I guess that's the reason why, historically, 'move to trash' has always been red.

As an aside: there are other inconsistencies related to the concept of 'move to trash' and 'permanently delete'. Have you had a chance to read #62185 ? Trashing triggers a confirm dialog. Permanently deleting doesn't 😆

[richtabor]

A simple rule of thumb we might consider is to reserve the destructive button variants for actions that are irreversible.

I don't think the primary dialog buttons should be red, even with destructive actions.

Otherwise some dialogs have confirmations that are blue, others that are red — one inconsistency for another, more confusing inconsistency.

If keeping 'Move to trash' as destructive is preferred, then we should apply consistently, and consider a treatment for truly destructive actions—perhaps they utilise a confirmDialog?

"Delete" where an undo action restores it shouldn't be red. Only destructive actions, and yes those should likely come with dialogs to confirm (but not with red buttons).

[jameskoster]

However, for published posts, trashing means that a published post gets unpublished.

Yes that is a good nuance to acknowledge. Although undo-able, the result is immediate on the frontend. This separates 'Move to trash' from things like deleting a block.

Trashing triggers a confirm dialog. Permanently deleting doesn't 😆

This one is tracked in #66570.

"Delete" where an undo action restores it shouldn't be red

Agree, if there's a single-click undo then the action needn't be red.

Perhaps it would be helpful to define the different types of destructive actions and figure out appropriate patterns/designs from there?

• Doesn't immediately affect the frontend, easily reversible. E.g. delete a block
• Immediately destructive on the frontend, reversible. E.g. Move to trash
• Immediately destructive on the frontend, irreversible. E.g. delete a template, reset a template, delete a taxonomy term, delete a media item
• Doesn't immediately affect the frontend, irreversible. E.g. delete a synced pattern, permanently delete a post, admin actions like deleting a custom data view

[afercia]

"Delete" where an undo action restores it shouldn't be red.

It's not always black or white. It depends.
Historically, for posts, comments, media, users, etc. both 'Trash' and 'Delete permanently' have been red. There is a reason for that. For posts, as mentioned earlier, trashing a post is a case where content disappears from the front end so that it's a special case.

To me, rather than basing this on whether an object is technically deleted, it is best to consider the potential of losing data. When any action potentially removes content or deletes data, it should be red.

Still, as an user, I may be confused. Why some 'delete' buttons are red and some aren't? What is the difference? How much cognitive load this difference would add? Wouldn't be better to drastically simplify and make all these red?

"Delete" where an undo action restores it shouldn't be red.

When a 'Delete' action isn't a real deletion because it can be undone, then I'd argue it shouldn't be called 'Delete' in the first place. However, it's still not all black and white.

For example: deleting a block. I would argue that, technically, deleting a block becomes irreversible only when the post content is saved and after leaving the edit page. While editing, it can be undone. However, the potential that the block is permanently lost is very high.

Overall, I'd think that attempting to distinguish all the different cases and nuances wouldn't help provide the best user experience. I'd consider to simplify as much as possible and just make all red.

[jameskoster]

In #66570 some updates to the pages data views are being explored, so it would be good to find some consensus on trashing / permanently deleting so that we can refine as a part of that work.

As @afercia pointed out, trashing currently invokes a confirm dialog. In the Editor the button is destructive, in data views it is not. Permanently deleting does not invoke a confirm dialog, and the actions are not destructive. What is the preference here?

My feeling is that both should invoke a confirm dialog (trashing because it immediately affects the frontend as pointed out earlier in this issue). The inclusion of a confirm dialog makes it less important to mark the action as destructive, imo. The confirm dialog is adequate. Though in the case of permanent deletion I would still consider making the primary button in the confirm dialog destructive as a final warning, given the action cannot be undone.

---

From this use case we could theoretically extract the following heuristic:

Action type	isDestructive?	Confirm Dialog?
Doesn't immediately affect the frontend, easily reversible. E.g. delete a block	No	No
Immediately destructive, reversible. E.g. Move to trash	No	Yes
Immediately destructive, irreversible. E.g. delete a template, reset a template, delete a taxonomy term, delete a media item	No	Yes, with destructive primary button

One benefit with this approach is that we don't need complicate the Menu component by adding a destructive variant. Another is that we reduce the reliance on destructive variants, which rely on color to communicate their nature. As we know, color alone is not always an adequate indication, accounting for a11y and cultures that associate differently with color.

What do y'all think?

[t-hamano]

For Dropdown, either the DropdownMenu component or the Menu component (formerly DropdownMenuV2) is used. And it's important to note that Menu component items don't support destructive colors yet:

• DropdownMenuItemV2: Add "destructive" state #61079

Menu component example	DropdownMenu component example

If we want to make the button in the Menu component red to indicate that it's a destructive action, we need to add a new API for color at the component level.

cc @WordPress/gutenberg-components

[afercia]

we reduce the reliance on destructive variants, which rely on color to communicate their nature. As we know, color alone is not always an adequate indication, accounting for a11y and cultures that associate differently with color.

That's certainly true when the destructive action is communicated via color alone. However, in most of the cases there is visible text. With clear, meaningful visible text, the destructive action is clearly communicated. In this case, the red color is an additional indication.
Instead, color alone wouldn't be eufficient when there is no text e.g. an icon button.

That said, I'd like to stress the fact that in WordPress there are conventions established since ages. Many actions including the one that aren't 'permanently deletion' e.g. 'Move to trash' have always been red in WordPress. I'm not sure the trend I see in Gutenberg design that tends to ignore everything that comes from che classic WordPress admin is ideal to provide a choesive experience for users. There are establishe dconventions in WordPress that, to me, should be preserved.

[jameskoster]

@afercia I suppose my point is that a confirm dialog is a more flexible/accessible 'additional indication' than red colorisation. Especially because there are a few instances of destructive icon buttons. It also avoids adding complexity to the components, as Aki points out.

[afercia]

@jameskoster thanks, Yes I understand the point. A confirm dialog should be used only for real destructive actions. It's not all black or white though. There are cases that are in the middle. For example, 'Move to trash' isn't the right place for a confirm dialog but it still removes content from the front end and for that reason it has always been red in WordPress. I think these conventions should not be changed.

Regarding adding complexity to the components, I'm not sure I agree with the trend of attempting to keep components as 'pure' as possible. To me, that's more a 'philosophical' approach that may appear good in theory but in practice we need something different. To me, when a component doesn't do what the user interface needs, that means the component hasn't been designed keeping in mind the real needs of the interface in the first place.

Not to mention that in many, many places in the editor, the base components are used inconsistently or use style overrides exactly because the design wants something that the base components can't do. I would argue that this scenario is way worse than adding more flexibility to the base components.

[jameskoster]

To me, when a component doesn't do what the user interface needs, that means the component hasn't been designed keeping in mind the real needs of the interface in the first place.

I agree, but the point is that the UX should generally be informed by a system. In other words the use of destructive patterns should documented and applied consistently (as outlined in the OP 😄), and the components should support accordingly.

So let's try to align the shades of gray to some black and white principles. That's what I was trying to get at with the example in this comment, because (hopefully) we can extrapolate from there.

It sounds like you're advocating for move-to-trash to use destructive styling with no confirmation dialog, and that permanent deletion should also use destructive styling and a confirmation dialog. Is that right? It could work, but I wouldn't put deleting a block on the same 'level' as move to trash, so am not convinced that action (and others like it) should use destructive styling.

[mirka]

As much as I love the simplicity of making all destructive actions red, as a user, I instinctively become extra careful when interacting with UI near a red item. So having a lot of red would have the downside of making many sections of the UI more stressful to interact with, not just noisy.

In that sense, I would prefer that only permanently destructive actions be red. (And if an action leads to a confirmation dialog, the button that triggered the confirmation is not permanently destructive.)

[jarekmorawski]

Great discussion! You've looked at the problem from all angles, so I'll only add my thoughts here inspired by watching people interact with WordPress and WooCommerce.

I'd suggest removing the red color from such buttons and only using it when the user attempts to permanently delete an item. What we consider a destructive action isn't always that. Most are reversible, either by recovering a deleted item from the trash or clicking an undo button.

Here's a practical example.

• User navigates to Pages
• User opens the dropdown menu
• User chooses Move to trash (regular button)
• User sees a toast notification with an Undo button and dismisses it
• User navigates to the Trash page
• User finds the recently deleted item and clicks Delete permanently (regular button)
• User sees a confirmation modal
• User clicks Delete (red button)

This behavior covers most use cases with a deliberate use of the red color. Regular buttons do not raise an alarm when users browse the UI or take an action that isn't immediately destructive, while the persistent toast notification helps rectify possible mistakes.

The red buttons are limited to the final confirmation interactions and pop when the user is about to make a permanent change. Most people don't thoroughly read the text on the screen so having a scary big button may alarm them in case they take the action by accident.

[matt-west]

Thanks for starting this discussion @afercia. I agree that it would be useful to have some guidelines to ensure that the treatment on destructive actions is consistent.

IMO anytime an action is permanently destructive and/or results in a material change to the front end of the site (i.e. trashing a page), we should show a confirmation prompt.

However, I don’t think confirmation prompts are needed when deleting blocks within the editor as there’s already an expectation that any changes will be reflected on the front end of the site.

I don’t have a strong opinion on the use of red to indicate destructive actions. I agree with @mirka that over using the red could increase anxiety for users though. It also diminishes the value of differentiating using the red color if it’s used so widely.

[jameskoster]

I still think there's value in some visual distinction where actions are destructive and irreversible. It doesn't necessarily have to be colorisation of buttons / menu items though. Another option could be to use icons. Here's an example from Tailwind:

That said, I also think it would be okay to start without this, and agree with the general sentiment that the presence of a confirm dialog, and the nature of the message, is enough warning in most cases.

It seems we're honing in on something:

• No red styling is applied to any action.
• Destructive actions that are easily undone and not immediately applied on the frontend do not invoke a confirmdialog.
• Any destructive action that immediately affects the frontend invokes a confirmdialog, whether it is reversible or not.