People don't read the message in the popup. But when presented with a Delete button users start to think about what they are doing.
Also: 'Delete - Cancel' sets 'Cancel' in a much better context. You are going to cancel a delete action not an 'Ok' action.
Instead, the UI should be seen to do the operation, but then delay its execution while showing an "undo" for a few seconds.
The reason for this is that 99.9% of people know what they're doing. So don't bother them for the sake of the 0.1% who make a mistake.
But more importantly - for each dialogue (of whatever kind) you have in an application, the chances of the user reading it declines by the square of the number of dialogues they encounter in a given session to the point where they will never be read, ever.
In your example, you could use a dialog during the first delete with a toggle option in the delete confirmation dialogue of "don't show this next time."
https://en.wikipedia.org/wiki/Mode_(computer_interface)#Asse...
The issue is that novice, elderly, power or otherwise, if you have dialogues popping up all the time asking you if you're sure, and 99% of the time you ARE sure, then pretty soon you will habituate to just hitting OK whatever until the one time you DON'T mean OK, at which point you have an undo.
This isn't controversial, or just my opinion, it's observed, researched HCI stuff (mainly in the context of aircraft cockpit design but also on desktop software and the web).
> 99.9% of people know what they're doing
You have very different users than those of anything I've ever written then. :)
Relevant to delete / undo they talk of the preference for an undo (eg ^Z at any time) to "Are you sure?". No mention of delaying action or availability of undo. Then preference for consistency of action - within app and generally, not deviating from common expectations (eg that a trash can allows restore), and recommendations for visual feedback when latency and delay is involved. None of which fits the original temporary delay/undo.
In both of those links I posted, it clearly states well-designed systems have undo.
Well, and it is also much easier to quickly locate and hit an Undo-button on a small touch screen than it is with a mouse on a giant screen.
But yeah, I definitely also see a lot more confirm-dialogs still.
Seems to be a classic case of such a UI pattern being great and hyper modern and marketable in 99% of cases. But if in 1% of cases, the user accidentally deletes a file that they didn't want to delete, then you lose that user in that exact moment.
That is, if you are not a preinstalled app. If instead you are Google, then users are generally not aware of alternatives and cannot switch away from your app, if this happens to them. They just live with your UI eating their files.
Not to mention that it was quite clearly their fault for not finding the Undo-button quick enough. Which is also generally an opinion that users manage to hold, who have not yet progressed to looking at alternatives of programs and comparing different UIs for their merits.
Perfect example of a UX pattern that's simply asking for trouble, or being clever rather than helpful. :)
You can undo if you notice quickly enough, if your dog, child, doorbell or 1,001 other things didn't distract you at the wrong moment and if you didn't get an incoming call in the temporary undo window. No, we won't tell you how long you can undo for, even though times can vary. Don't be old (or even middle-aged needing reading glasses), or slow.
Seems very much against long known recommendations from Nielsen et al for consistency of expectation etc.
A quick skim through search seems to indicate it came with Material Design. I suspect had it generally caught on it my switch to iOS would have come even sooner. :D
That is a worse user experience by far - you should never tell someone something has been done unless you are sure it has been done permanently.
https://en.wikipedia.org/wiki/Mode_(computer_interface)#Asse...
rm () {
(sleep 30 && \rm "$@") &
}
Pretty sure there are a plethora of options for each OS but here’s a couple:
For OSX, homebrew has a handy “trash” command line tool [1].
For Ubuntu, trash-cli seems popular [2].
1. `brew install trash`
2. http://manpages.ubuntu.com/manpages/precise/man1/trash-put.1...
Is it still going to be out of scope if he e.g. runs the shell script from the shell?
I've always looked at interface choices like this: As a non-Chinese reader, if I see a dialog in Chinese and the "Yes/Confirm" and No/Back" buttons are the same size, shape, and color, I will have no clue which does what. However, if the "Yes" option is a darker shade, or has bolder text, or the button shape makes it scream "click me!", I'll feel relatively confident that this is the button I need to press to proceed with whatever I'm trying to do.
Another thing to note in the Factorio mockups is the use of a guideline that I originally picked up from the macOS HIG[1]: use descriptive verbs rather than a generic confirmation.
"Apply settings" vs "OK"
"Load game" vs "OK"
"Delete file" vs "OK"
"Send email" vs "OK"
"Print" vs "OK"
and so on.
[1]: https://developer.apple.com/design/human-interface-guideline...