> The technician left empty a field that would normally contain a target telephone number. The network management software interpreted the empty field as a 'wildcard,' ...
Exactly the same type of technical error happened nine years ago at Google!
> We maintain a list of [malicious] sites through both manual and automated methods. We periodically update that list and released one such update to the site this morning. Unfortunately (and here's the human error), the URL of '/' was mistakenly checked in as a value to the file and '/' expands to all URLs.
This is a painful reminder for those of us who routinely design form-based interfaces to ensure ambiguous fields are explicitly understood by the user before entry or called out during verification of the submission.
An "Are you sure?" prompt goes a long way and sometimes takes a really long time to get added, even when it's historically been a problem[0].
Particularly in these kinds of cases -- this is software that is used by very few people at very few companies and at those companies, it's used very rarely. That nobody at Level 3 knew leaving that field blank would cause that issue doesn't surprise me at all. We had management applications for some switch software that we had to run on Windows 98 using ThinkPad laptops[1].
[1] I was a Frontier, then Global Crossing and ultimately Level 3 employee for around 17 years. The story about the ThinkPad Laptops is detailed in another comment in this post.
We had some remote desktop software that asked "are you sure" about all kinds of things. If you hit logoff/restart/shutdown on a group with nothing selected it'd ask "Are you sure" yes/no and select everything in the group and perform said action. I pushed for ages to get that "default do everything" behaviour removed entirely.
If you think "are you sure" is a good solution, you may have problems much further back in the applications flow, any it may not be helping even if you do add it.
Excessive prompts are equally dangerous. “Click fatigue” is a real thing and you can quickly shift from a state of “let me know when something differs from the expectations” to “why are you making me agree to everything?”, which means more often than not the user just clicks blindly instead of reading the prompt for context of why this time the prompt is different.
I’m a proponent of appropriately prompting the user when their submissions, if processed, would result in ambiguous / destructive and not-easily-reversible outcomes.
Requiring confirmation for an action should be something a user very rarely, if ever, sees. That ensures when it does occur it 1) is serious and 2) surprises the user, gaining their full attention.
Another approach here would have been implementing sane defaults. Blank field as wildcard is not a sane default. Default to that which has the least impact.
While "Are you sure?" is often a great prompt, there are two things that can be done to improve it.
1) Just putting AYS? after every prompt is bad, people stop taking the time to think and just mash Y.
2) Discussing the consequences in the AYS? is better.
For instance if you @channel in slack you get an AYS that lists the number of people you are going to piss off with the notification. Great UX... and yet people at my office still seem to think things like girl scout cookies are worth @channel'ing #general with a few thousand people in it is a good idea.
I think a lot of those problems can be solved with a few techniques:
In the case of the famous rm -rf /, having a flag to ditch confirmation (which, IIRC, the reason the confirmation prompt was not there in the first place is because "f" means force, but hey). I think about "zypper" (openSUSE's package manager), which has the -y flag for installs/updates, one to auto-accept licenses and one to force resolving conflicts aggressively so that there are, literally, no prompts. To me, having a -y and an auto-accept licenses is unnecessary, but I suspect that may exist for legal reasons. Having the extra flag for aggressively accepting conflicts is a really good idea because in interactive mode you're often given 3 choices and often all three of those choices will break something. Conflicts/package resolution issues aren't common and when the creep up it's usually because you've got a unique configuration and need to do some other steps before you're going to get a successful installation.
As for the "Are you sure?" GUI prompts where flags won't cut it, providing a "[ ] Never ask again" is usually suitable. Though in the case of Slack, I'm with you. My answer to that would be after a person has used @channel more than a twice in a day to throw another prompt up that says "You're going to get a reputation for being an obnoxious dick. Knock it off." ...and that's why I'm not a UX designer.
> The technician left empty a field that would normally contain a target telephone number. The network management software interpreted the empty field as a 'wildcard,' ...
Exactly the same type of technical error happened nine years ago at Google!
> We maintain a list of [malicious] sites through both manual and automated methods. We periodically update that list and released one such update to the site this morning. Unfortunately (and here's the human error), the URL of '/' was mistakenly checked in as a value to the file and '/' expands to all URLs.
What it looked like: https://i.imgur.com/W5ICyVq.png, https://i.imgur.com/LrtLceN.png
Source: https://googleblog.blogspot.com.au/2009/01/this-site-may-har...