52

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?

iBug
  • 1,091
  • 2
  • 9
  • 11
  • 183
    I prefer that method. You can throw all the red buttons you want at me, if I'm tired I might just click on it. I may have picked the wrong thing to delete. Forcing me to enter the name definitely makes me think twice. – MetalMikester Nov 18 '19 at 12:23
  • 71
    "In my opinion, an extra modal with a bright red button that does't respond to keyboard actions (like the Enter key) would suffice." Think about accessibility, someone relying on the keyboard won't be able to perform those actions. – jazZRo Nov 18 '19 at 14:20
  • @jazZRo That could be easily improved, for example when the button is reachable with Tab and then the default Enter behavior applies (click the selected item). – iBug Nov 18 '19 at 14:21
  • 11
    @iBug so... in other words, it responds to keyboard actions in the same way everything else does? Tab navigates, enter ""clicks"" – Delioth Nov 18 '19 at 19:29
  • 73
    "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." Yes, exactly... – Lightness Races in Orbit Nov 18 '19 at 19:40
  • 13
    @MetalMikester makes an important point: if you meant to delete a different repo, you won't be able to get past this modal, because you'll type the wrong name. – Nonny Moose Nov 19 '19 at 01:21
  • 4
    I would prefer if you had to type in the name of the account/repo -- I once deleted several repos at a former employer, thinking I was deleting my forks of those repos (the team used a fork-heavy workflow). – Eric Wilson Nov 19 '19 at 19:12
  • 5
    'I want to delete MyOldProject'. "Delete Project?" 'Yeah sure.' "OK Deleted." 'OK Good.' (Navigates to MyNewProject but it isnt there). 'Wait, which project did I just delete???' – user1445967 Nov 19 '19 at 20:36
  • 2
    A red button is still a common UI element that you can instinctively press without paying attention. Making the user type something forces them to read the instructions (in order to figure out what to type). – dbkk Nov 20 '19 at 02:44
  • Red buttons are so overused that we click on them even when we know we should double check what we're doing. – Tvde1 Nov 20 '19 at 13:49

7 Answers7

171

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:

xenia
  • 109
  • 3
Big_Chair
  • 6,815
  • 3
  • 30
  • 50
  • 6
    "usually only used for very critical deletion operations". True. I've seen this on very few sites. The Azure portal is one, when you're about to delete something big like a database, site our other resource. Not something one would usually do all that often anyway, but the consequences of deleting the wrong item can be disastrous. – MetalMikester Nov 18 '19 at 12:24
  • 1
    Intent can be hard to determine from clicks alone which can matter if you are trying to minimize deletions or support requests where the user asks, "Where did my data go? Why can't I get it back?" This model may not impact the former, but it can probably reduce the latter. – Nathan Rabe Nov 18 '19 at 18:36
  • 10
    If you have the molly-guard package installed on linux it also makes you type type hostname in when trying to reboot, shutdown, etc the machine while connected with SSH – GammaGames Nov 18 '19 at 22:15
  • 2
    WoW has this since at least 10 years - you have to type in "Delete" into a text box to delete epic items. it works remarkably well in ensuring you look twice at what you are doing and that what you are deleting is what you actually want to delete. – Polygnome Nov 18 '19 at 22:40
  • 5
    @Polygnome funny, I was about to use WoW as a counter-example. Because you have to delete so many items as part of everyday behaviour within the game, it becomes completely automatic (yet still a painful manual step) and loses any of its molly-guard properties it was intended for. – Coxy Nov 19 '19 at 00:16
  • 41
    Typing the name of the item is much better than "delete". The accident you are trying to avoid is deleting the wrong item. The user knows they want to delete but they might have clicked on the wrong item. – Qwertie Nov 19 '19 at 06:25
  • 19
    In Japan, train companies (most notably, but also other industries) have taken this to the extreme. The employees are required to point at what they are planning to do something with, vocally announce what they are going to do, and then do it, even if nobody else is around. It has reduced errors by 85% https://www.atlasobscura.com/articles/pointing-and-calling-japan-trains – Suppen Nov 19 '19 at 08:35
  • @Coxy Yeah, using the name of the item would be more effective, that is what GitHub does, after all. It is still more effective then having an additional "Are you sure?" button. My main point is that this scheme is used in the wild and has been for quite some time. – Polygnome Nov 19 '19 at 10:33
  • @GammaGames Good to know, I would have needed that more than once. – Alexander Nov 19 '19 at 13:00
  • 3
    "It's not necessarily about "good UI design"" - it's arguable. Deliberately introducing friction seems like a reasonable compromise between "ease of use" and "prevent Bad Stuff™ from a user action". – VLAZ Nov 19 '19 at 15:25
  • @Qwertie: What if the name is very complex or contains special characters which – for some reason – you are unable to type with your current keyboard layout? – Michael Nov 20 '19 at 11:52
  • 1
    We have a software where it requries you to write down the number of devices you are going to delete. There user still users who copied carelessly stuff like 55427 and deleted half of the devices of their company from the database... Still better than not having this, otherwise I bet, knowing the users, something like this would happen once a week instead of once every couple of years... – Giacomo Alzetta Nov 20 '19 at 12:57
  • @Michael First of all, that would be a terrible naming strategy for stuff where this is useful. Secondly, as noted in the question, you can just copy/paste it. No need to actually type it. – Suppen Nov 20 '19 at 13:49
  • Of course, a better solution yet would be to allow the user to reverse the action. Most of our UIs have gone that way, and it's so natural you don't even think about it (until there's that one thing that Ctrl+Z doesn't work on, oops). But showing a confirmation dialog like this is a cheap way of solving most of the accidental deletions. – Luaan Nov 21 '19 at 08:44
  • 1
    @Luaan, would mostly agree that reversing action if good, but it requires that one notices the error on time, and on the other hand, e.g. for security reasons you might want that the deleted item is permanently and irreversible gone. – Tero Lahtinen Nov 21 '19 at 15:41
52

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.

Bryce Howitson
  • 1,375
  • 7
  • 14
  • 46
    "Randomizing placement of process continuation buttons." That's a recipe for disaster when coupled with muscle memory! – Emile Bergeron Nov 18 '19 at 22:08
  • 1
    I'm not condoning the solution, just saying that I've seen this type of thing done. Also that doesn't mean swapping known positions, but moving to the right or left of a confirm modal for example. – Bryce Howitson Nov 18 '19 at 22:55
  • @EmileBergeron I was testing some software that was newly translated so I wasn't able to read the exact text and I clicked the wrong button which opened a dialog which in english would have had the buttons "Do action" (in grey) "Go back" (in blue). Not being able to read the text I chose to click the non primary button expecting it to be the button to cancel the action. – Qwertie Nov 19 '19 at 06:29
  • 2
    The initial paragraph alone already earned this answer an upvote. – O. R. Mapper Nov 19 '19 at 08:58
  • 7
    @EmileBergeron Free-to-pay games utilize that one all the time, tricking the player into clicking a "buy now $99.99" button instead of the "next level" button. And because it required user interaction, the app is allowed to automatically charge their Google Play account. .. – Draco18s no longer trusts SE Nov 19 '19 at 19:43
  • 7
    I respectfully disagree with the first sentence. Good UI is about giving the user what they want. The sticking point (which you've elaborated on quite nicely in the rest of your answer) is that "what the user wants" and "what the user actually asked the computer to do" are very often not the same thing. – jmbpiano Nov 20 '19 at 00:08
  • a big Korean bank is randomizing the key positions every time it asks for the PIN – phuclv Nov 21 '19 at 04:43
  • @phuclv But that's not to prevent them from accidentally entering the wrong PIN, is it? :D – Luaan Nov 21 '19 at 08:46
16

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.

frodo2975
  • 261
  • 1
  • 3
  • 2
    Glad to see your #2 on this list, people seem to be missing that. It's critical. It doesn't ensure you're deleting the right repo, but it moves the bar further if you have to actually type the name. "Okay, let's get rid of this old repo. Oh! I have to confirm deletion, okay: thing-I-no-longer-want. Huh! It won't let me delete -- OH MY GOD, I just almost deleted my 20 man-year repo!" – T.J. Crowder Nov 20 '19 at 14:46
9

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.

user117529
  • 191
  • 2
9

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).

taswyn
  • 3,087
  • 1
  • 15
  • 10
  • 1
    Avoiding "unrecoverable" actions is a really good point! I wish more interfaces would take that into account. I suppose its a function of the UI designer, product owner and dev architect/coder not communicating or not having a clear definition of success for the user in most cases. – Bryce Howitson Nov 19 '19 at 21:04
  • 3
    While it's a great idea, unfortunately, it's not always practical. And as soon as you make it recoverable, there WILL be someone who says they want to permanently remove the recoverable data. – barbecue Nov 19 '19 at 22:40
  • @barbecue I absolutely agree that it's not always either practical or even necessarily possible, but part of the point is taking a step back and examining what makes sense, and what the related costs are both in terms of UX concerns and also data loss/support time (particularly if support turns into retrieval from backup). And, yes, sometimes people do want to permanently remove data: but maybe that's something which should occur via other means, then. Or add it in your recovery area (recycle bin/etc): you now have to completely change contexts to perform the permanent action – taswyn Nov 19 '19 at 23:08
  • Requiring movement of mouse is not a barrier at all. Modern machines have touchpads right below the keyboard and touchscreens that are easy to accidentally touch anywhere. – R.. GitHub STOP HELPING ICE Nov 20 '19 at 00:48
  • @R it's definitely a barrier to accessibility, and as an aside, "modern machines" aren't just laptops. – moopet Nov 21 '19 at 12:04
5

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.

WoJ
  • 359
  • 1
  • 8
3

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.

dougajmcdonald
  • 2,094
  • 12
  • 15