High-impact destructive delete pattern

[vesnadean]

When users need to perform a delete action that is highly destructive, we want them to stop and think twice about whether they want to proceed, instead of having them mindlessly clicking okay.

We currently have this pattern in Storybook, which achieves the above goals, but is case sensitive and most likely not i18n compliant.

The Cloud auth team came up with this pattern that uses a toggle component. The default state is "No" and users need to toggle it to "Yes".

The question is:

1. Is the typing pattern annoying and does it fail internationalisation and localisation standards?
2. Is the toggle action enough to make users stop and think before performing a destructive action?
3. Should we tweak the existing pattern / come up with a new one?

[staton-hyse11]

@joshhunt do you have any insights on how i18n might come into play here?

@vesnadean If we remove the capital "D" from "Delete", do you think this would solve some of the concerns with this pattern? That would be a simple adjustment with little dev/design cost.

[vesnadean]

@staton-hyse11 It would definitely solve a part of the problem.

[joshhunt]

The typing pattern is kind of intentionally supposed to be annoying. Purposefully introducing friction so the user slows down and hopefully acknowledges the severity of their action. We can localise the word, but I think I would recommend not to - it just simplifies things and makes it more resistant to bugs. It doesn't matter exactly what they type, as long as it's something (and we tell them what to type)

Public Dashboards has a similar "speed hump" pattern:

[joshhunt]

I think the Toggle component is wrong to use here - for boolean yes/no options we should use checkbox instead.

[staton-hyse11]

I agree with the checkbox suggestion and it would align with the shared dashboard implementation. To me, the question that needs to be answered is: How much friction is appropriate for various destructive patterns? This needs alignment across the product and defined to ensure consistency.

I am leaning towards maintaining this pattern as is today and we can work to define these tiers of friction to better suit needs across the product in the meantime.

[staton-hyse11]

I've begun to capture some of the existing patterns in a delete pattern doc

[gelicia]

Hello, as you may have heard, we are transitioning away from using discussions to discuss feature requests. Due to the age and number of responses to this discussion, we are deciding to close it. If this is something you would like to see in Grafana, feel free to open an issue so the discussion can continue. Thank you!