Reading in auto mode and skipping is easy, writing not so much
I have seen instances where the wrong pod or whatever was deleted, because someone nuked "foo-api" instead of "foo-ui" or something, but it's significantly harder to footgun yourself this way.
This process is not an exploratory process for them at that point, it's simply the actions necessary to get it done. Check the box, sign the form, stand on one leg, "yea yea, yada yada yada. GO!!!".
The fact that they are WRONG in their knowledge is long past. This is not in question in their mind. The decision is done, now it's all action. And we all have long become immune to all of the click throughs and other arcane dances necessary to "get things done".
It's no different from being in an intersection and seeing another driver LOOK RIGHT AT YOU and drive into you anyway. You're not "supposed to be there", and they have that driving maneuver locked into their brain, they're just following through.
I was just confused with the name of the groups, and typing it didn't help.
I like that Azure makes you type in the resource name before deleting it, I know I am not going to accidentally click the button.
I'd say performing an action wrong item when having lots of tabs/windows open is probably pretty common.
Certain things should be a little harder. They should require deliberate action from the user to ensure as much as possible that they are engaged with the task at hand.
Typically you'll have requests like "I just want to do X with 'one click'" and "I want to be able to delete X with 'one click'".
I hate "one click". I hate counting clicks. Counting clicks is the fucking stupidest way to measure ease of interaction. I can make everything one click away, but it will be a fucking mess of an interface because there is not enough real estate for all that mess. A children's book requires far fewer clicks to type than the works of Shakespeare, but no one will say that a children's book is "better".
And I know that comparison is a little strained, but user experience isn't just clicks either. In some ways, it is a story about your application.
Ease of discovery is far more important. Relying on things people already know. I've slowly moved away from categories for most things and have gone to just alphabetize things. I don't have to worry if something is a TV show or movie, if it's horror, comedy, or action, or if it's a TV movie taking place between two seasons of a sci-fi western drama.
I wish more product teams really understood this truth.
Then you just get emails from the kind of people who get stuck at "Press OK to continue"
This is what GitHub does. But incidents like this still happen: https://httpie.io/blog/stardust
> Due to an unfortunate sequence of events, I accidentally made the project’s repository private for a moment. And GitHub cascade-deleted our community that took 10 years to build.
> There’s a confirmation box. It’s designed to stop users in a situation like mine from doing something stupid. It tells you that “You will permanently lose all stars and watchers of this repository.”
If it happens to experienced developers, imagine the laymen. Humans are just fallible, I guess.
https://httpie.io/_next/image?url=%2FBlog%2Fstardust%2Fconfi...
The developer was on automatic because he had just been working with another repo and the two repo names were similar, so the type to confirm didn't prevent the mistake. The blog post suggests other changes GitHub could make.
I think there's a literal psychological disease in American culture, where if you fuck up, then someone else was to blame for not preventing you from doing it. I think we just need less of that (not more of that) to force people to understand that they need to be considering the effects of their actions before they do them.
The author of the httpie blog post does not apply blame. In fact, he goes out of his way to explain his error, then suggests changes that would have prevented his mistake, to hopefully save others from the same mistake.
So we can blame humans as you seem to want to do, or we can accept human behavior and design our systems to be more forgiving.
cdelsolar at the top of this thread wrote that "I get emails, every single day" and that "It literally drives me crazy."
So what should cdelsolar do? Blame all the humans accidentally deleting their accounts, or find a way to design around it?
I know which approach I would take.
Let me suggest this book btw:
https://www.amazon.com/Field-Guide-Understanding-Human-Error...
Yeah they do and pilot error is very common:
> During 2004 in the United States, pilot error was listed as the primary cause of 78.6% of fatal general aviation accidents, and as the primary cause of 75.5% of general aviation accidents overall.[27] For scheduled air transport, pilot error typically accounts for just over half of worldwide accidents with a known cause
They can try to address that through training, certification, recertification and updates to manuals and checklists, but at some point some level of human failure is going to be inevitable. And with UI/UX like this there isn't much ability to do that, since people don't get certified on using GitHub.
Meanwhile, it is going to be very difficult to break people who are stuck on "autopilot" and just aren't reading anything out of it vi any kinds of dialogs or messages. Gonna delete 8,000,000 stars on this project? Good. Oh wait. Whoops. I'd like to see if the change to the UX to show that information has made any actual measurable impact on the accidental deletion incidents that GH sees.
There isn't any good substitute for just learning early that if you are going to delete something you need to stop, think, read and wait a second before hitting that button. Trying to fashion a world where people can navigate it successfully on completely thoughtless autopilot all the time isn't possible.
Also, that blog post is irritating because "Lesson #1" should have been for the author to STOP AND THINK when deleting or presented with a scary modal dialog box that actions were going to be permanent. My reading of that blog post is that the author didn't actually accept any blame, didn't see any need to change any of their behavior and shifted it all onto GH. It is equivalent to a non-apology-apology.
Modern accident investigators avoid the words "pilot error", as the scope of their work is to determine the cause of an accident, rather than to apportion blame.
And from the NTSB:
The NTSB does not assign fault or blame for an accident or incident; rather, NTSB investigations are factfinding proceedings with no adverse parties and are not conducted for the purpose of determining the rights, liabilities, or blame of any person or entity."
https://www.ntsb.gov/investigations/process/Pages/investigat...
> should have been for the author to STOP AND THINK when deleting
I've been doing system administration and programming since the early 90s. One of the first things I learned from a grey beard at the time was after typing a destructive command, take my hands away from the keyboard and read back what I just typed before pressing enter. It was a great lesson and has saved me from a lot of mistakes.
Guess what? I still occasionally make mistakes. Because I'm human.
So another thing I learned was to make any shells on production systems be visually distinct. All my production machines have a red shell prompt. That's saved me from even more mistakes than reading back commands. And it protects more than just me, but anyone else who logs into those machines. (Yes, ideally, no one is ever logging into a production machine.)
The problem with "STOP AND THINK" is that it requires every person to learn that lesson individually. Meanwhile, if you accept that human behavior is what it is and design around it, you can save many people from mistakes in the first place.
There's a saying: do you want to be right or do you want to win? Personally, I want to win (i.e. be effective). Winning means accepting humans are fallible and doing my best to design systems for them instead of holding them at fault in cases where a better design would have prevented the mistake.
https://en.wikipedia.org/wiki/1999_Martha's_Vineyard_plane_c...
> The probable cause of the crash was "the pilot's failure to maintain control of the airplane during a descent over water at night, which was a result of spatial disorientation".
At some point there's not much else to do. Pilot exceeded their training and flew into the water. You could try to prevent that with more and more autopilots and warnings, but at some point pilots have to be able to fly the thing on manual and need to have the actual training for the conditions. I doubt the modern NTSB would be able to say anything better.
The prompts that you have setup also won't stop you from doing a `sudo shutdown -r now` in production quickly one day on autopilot (and typing sudo doesn't help much at all because it is now so common and you probably do that on preprod as well). STOP AND THINK is still going to be the best tool in your toolbox.
And in addition to having been a system administration since the early 90s (and worked at Amazon for 5 years) I'm also a cave diver. There's a variety of different methods in cave/technical diving to avoid breathing the wrong gas at the wrong depth. The best one is probably just to simply label all your bottles with your MOD, always analyze your gas and have a gas analysis sticker on the tank that matches the MOD sticker, then to always go through gas switching procedure with your buddy and validate MOD and analysis sticker every time you do a gas switch (even if you think you're not carrying any gas that is outside of the range where you're diving that day). Alternatives like different colored regulators or carrying gas on different sides run into trouble with exceptional procedures when regulators fail or tanks wind up getting dropped and picked up and put on the wrong side. You can then wind up following "correct" gas switching procedure at the gas switch time and still die. The best solution anyone has come up with has just been to always verify gas contents before sticking it into your mouth -- stop and think every single time. Adding anything else is generally creating more of an overcomplication that causes more additional secondary problems than it solves.
> a better design would have prevented the mistake.
You still need to show that a "better" design actually does stop the mistakes. Does having the stars and forks listed in the message really do that much or do people who are autopilot not reading still just hit submit? Has anyone really measured that?
I do not share your unbridled optimism that the perfect UI/UX design is out there which solves all problems and has no unintended consequences, and one of the unintended consequences I think is social which is that we learn to expect that if we screwed up that someone else should have stopped us.
And I learned that early growing up on systems where deletion was largely permanent and people didn't have backups (although I did get paid some money in high school to manually undelete files on an Apple floppy disk that someone else had nuked by accident), so I learned to think through permanent actions early. And I didn't learn to blame someone else for my own failure. I leveraged that at Amazon and ran all kinds of nasty commands in prod on a daily basis and never destroyed the company (all of that was done in the service of standardizing the configuration management of the systems and in the long run reducing the amount that prod needed to be touched, but early Amazon had a chicken-and-egg problem with a massive production deployment and no good standardization).
To slightly validate this thought for you: https://en.wikipedia.org/wiki/Narcissistic_personality_disor....
I've personally known people who strongly exhibit these symptoms. There is no accountability (and no "good faith" arguments) for such people and I notice a seemingly similar pattern of thought in the linked blog post. Some excerpts which seem to intentionally shift blame:
> It’s a peculiarity of GitHub, to put it mildly, that making a repo private permanently deletes all watchers and stars.
> GitHub’s conceptual model treats users and organizations as very similar entities when it comes to profiles and repos.
> The problem is that the box looks exactly the same for repos with no commits and stars and for repos with a decade-long history and 55k stargazers and watchers.
I could go on. Anyway, just trying to offer another voice in agreement. Also, that particular call-out of "psychological disease" is especially notable to me for personal reasons. (Not that I'm intending to diagnose this specific blogger; just that the tone of the blog post indeed seems to be blame-shifting, which is a characteristic behavior of those with NPD.)
There's a general undercurrent of narcissism across our whole society, even if people aren't formally diagnosable.
Sometimes the brain just farts.
https://news.ycombinator.com/item?id=31033758
Expecting humans to change will lead to frustration. Humans won't change. You have to construct your process around the way humans actually behave, not the way you wish they would or think they should. Apply lessons from accident investigations.
The more websites start doing this, the more users will be trained to typing whatever you ask them to type. A dangerous trend is in formation!
I very much favor type-to-delete for important irreversible actions--and when it's delete one of a list the type-to-delete is the name of the object you are getting rid of. I never implement one-click for options which are rarely used and are potentially bad. This isn't a dark pattern, this is simply sensible UI design. (My entire career has been spent programming for industry--I have absolutely zero reason to implement any sort of dark pattern as my users aren't my customers.)
One approach I take is to make the user type something before taking the destructive action. Make them type IRREVERSIBLY DELETE MY ACCOUNT!, in all caps, with punctuation.
Another option is to have a 30 second timer where users have to sit on that screen and wait until you enable the delete button.
I’m sure many here would call these “dark patterns”, but these tricks have saved me so many painful support tickets over the years it’s not even funny.