Why would one use "enter the name of the project to confirm"?

Question

If you're a long-time GitHub user, you probably have seen something like this:

This happens every time you do a potentially destructive thing to a repository, like switching its public / private status or archiving / deleting it.

The prompt shows up in a modal after clicking the action button, so this is an extra measure to prevent accidental actions.

But as far as I am concerned, this is either ineffective in "setting another barrier" or too cumbersome as "an extra confirmation". One can simply copy the repository name from the URL or right above the input box (the bold text above), but this is still more complex than just clicking an extra button.

In my opinion, an extra modal with a bright red button that does't respond to keyboard actions (like the Enter key) would suffice. One would have to move their mouse onto the bright red button to click it for an extra layer of caution. This is less cumbersome and the disability to simply hit the Enter key is both simple and effective.

Can anyone explain how this "enter project name" is a good UI design?

Answer 1

It's not necessarily about "good UI design", but much more about taking all measures to prevent accidental deletion and ensure that the user is fully aware of what they are deleting.

This blog entry here captures it quite well:

Instead of giving users a confirmation button that they could mistakenly press, give them a text field and ask them to type the word “delete” to confirm. When the user types “delete” in the text field, there is no doubt that they want to delete. There is no accidental pressing of the delete button. There is no regret when the user deletes, because the confirmation text field makes them certain about what they’re going to do before they do it.
_{How to Make Sure Users Don’t Accidentally Delete - UX Movement}

Sure, pressing a button is easier, but that always leaves the chance that you misread the name and delete the wrong item.
When you have to type out the name (or even copy paste it), you can be 99% sure that a user won't do that mistakenly. They would realize it at the latest when highlighting the name for copy-paste.

Besides that, this is usually only used for very critical deletion operations. These happen very rarely, so the argument about making it easier or less annoying doesn't really hold there.

---

Here are some related questions:

• Double confirmation for DELETE action?
• Drawing users' attention to unrecoverable actions?

Answer 2

Just to be clear "good" UI design doesn't mean giving the user what they want. It often means helping the user to be a better version of themselves.

In addition to what's already been mentioned, this pattern (and several like it) allow the UI to reduce speed. In general muscle memory -> speed -> mistakes -> sad path.

Imagine that you're doing work in healthcare. If users build up too much of a "flow" in common tasks they could potentially make a simple mistake that kills someone. While counter intuitive, its often good to pull the user out of their flow by requiring an interaction (more than a simple confirm dialog that always appears in the same place and can be added to muscle memory).

Typing text is just one example of this. I've also seen:

1. adding a time out to buttons before they become available.
2. Randomizing placement of process continuation buttons.
3. Adding a lock (eg run process as administrator with password)

All of these patterns are intended to annoy the user enough that they stop to mentally assess the process before going forward.

Answer 3

This is to ensure that:

1. You understand the danger of what you're doing.
2. Most importantly, that you're actually deleting the right repo.

If a user has a lot of repos with long names, it can be easy to get them mixed up. Typing the name is a good way to make sure you don't nuke the wrong one, which would be really really bad.

Answer 4

I remap an unused keyboard key (via AutoHotKey) for intermittent use as a left-mouse-click to decrease strain from overuse of my mousing wrist, and sometimes (rarely) hit that key in the wrong spot when multitasking. I've also occasionally bumped the mouse itself and unintentionally clicked a button on a dialog.

While "don't make me think" is a very good rule, it makes sense to help the user focus on exactly what executing a infrequent, destructive command will actually do. I'd even consider having the user type a full sentence of the form, "Please delete the iBug/example-repository repository, including its wiki, issues, and comments" verbatim to clarify the user's intention to themselves in that situation, as the user will only do that once on that repository.

Anyone actually writing code has to type full, clear, correctly spelled lines of text very frequently, so one more such line to confirm the most destructive action you can perform on a project is not unreasonable.

Answer 5

In my opinion, an extra modal with a bright red button that does't respond to keyboard actions (like the Enter key) would suffice. One would have to move their mouse onto the bright red button to click it for an extra layer of caution. This is less cumbersome and the disability to simply hit the Enter key is both simple and effective.

(emphasis added)

Are you sure that they'd have to "move their mouse"? Every time? Even if they're on a device with a different resolution, where maybe things don't line up as anticipated? Or if they're zoomed in? What about touch input? What about people who aren't using a mouse (due to difference in ability/etc)? Now you have to make sure it responds to keyboard in a way that doesn't break accessibility, but doesn't allow an accidental deletion.

While there are arguments against indiscriminately following best practices simply due to them being best practices (versus developing an understanding of why they are in place) or at least "what everyone else is doing", particularly when they aren't always actually so great, I'd like to point out that usually they have become a best practice because there are unforeseen issues which will arise, and trying to go against them simply because you don't see the point of them is usually a bad idea. When looking at something that is a widespread/widely adopted best practice, start from the assumption of it being meaningful and significant and likely having strong underlying reasons that have developed over more time (and likely among more people than just one, and certainly having been reviewed by more than just one person) than you alone have probably devoted to the same set of problems (and with only your own perspective guiding you). Not to mention the global consistency issues.

@BigChair's answer alongside @Bryce Howitson's answer both dig into why this is a best practice for unrecoverable actions in general. In UI design, it's important to create friction for critical actions that will be unrecoverable, and these both cover the topic quite well for this context.

Where possible, though, I would advise taking a different path in any case where it would be feasible to implement:

Avoid letting actions be unrecoverable in the first place

With that said, the best way to move forward is to not have user actions result in unrecoverable software states in the first place. Remember, what a UI exposes to the person using software does not have to match what the software does to its state internally, in a 1:1 of related semantics. It's ok for how something is represented to the person using it to not match the technical implementation of what happens when they activate a related action.

Don't delete things in your software representation of them based on user input alone. Mark them deleted in your storage representation of them and provide a means to retrieve them (a recycle bin/etc). Don't allow the creation of situations where a person using your product can back themselves into a corner they can't get themselves back out of. Not only is it better UX to avoid the necessity of these types of confirmations wherever it is possible to do so, it also reduces support requirements and related levels of friction in related support issues (which are also UX aspects). When someone is "deleting" something, make abundantly clear that they will also be able to revert the action they have taken both while engaging in the action and afterwards (so that if they have accidentally "deleted" something without reading screens up to and including taking the action, they can now see where to go to undo it).

Answer 6

I already made what I call accidental mistakes:

• my hand shifted the second I pressed the button (wanted "Cancel", got "OK"). Alternatively: an ad popped up and shifted the page.
• the instruction was so confusing that I pressed the wrong button (of course not the less destructive one)
• I was "oh no no no" and in panic pressed the wrong button
• I may or may not be Juan Pablo Davila

This is why I really, really prefer to have in such cases a process which makes me act differently from what muscle memory suggests.

Answer 7

What Github are trying to do here is avoid user error, but specifically "slips" as Don Norman refers to them in The design of everyday things.

Slips occur when users intend to perform one action, but end up doing another (often similar) action. For example, typing an “i” instead of an “o” counts as a slip; accidentally putting liquid hand soap on one’s toothbrush instead of toothpaste is also a slip. Slips are typically made when users are on autopilot, and when they do not fully devote their attention resources to the task at hand.

I emphasise the last part of the quote as its especially relevant.

The following article from nngroup talks about how to prevent slips

slip-type mistakes often are made by expert users who are very familiar with the process at hand; unlike new users who are still learning how to use the system

https://www.nngroup.com/articles/slips/

Considering the types of people who would use Github, you would consider them very high on something like the GDS Digital Inclusion Scale which would imply they are expert users more likely to make slips.

Then put the two together and empathise with an expert Github user who's put hundreds of hours into a project, but is tired, forgot which project they were in and and slips to press delete when they didn't mean to. How do they feel?

Many Github users have a high number of repositories and on the delete page there isn't much to tell them apart if you're not paying attention, perhaps you meant to delete the "million pound project - draft" repo, but you were in "million pound project".

This is what they are doing and I would consider it effective UI design for that. Putting helpful constraints in the way of operations which are unrecoverable is good practice.