Hacker News Reader

Comment by ProxCoques | Hacker News Reader

When it comes to OK/Cancel for a non-recoverable event (like delete), it's ALWAYS been the case that the dialogue should NOT appear in the first place.

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.

View on HN

Maybe for power users. Time based UI actions are not accessible, though. Novice users, elderly, those with lowered motor functions, etc will struggle with time-based interactions.

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

That's not what the HCI research and general literature on this says.

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

I've never come across that recommendation before. I can't immediately think of a case where I'd want that or it would be anything but annoying.

> 99.9% of people know what they're doing

You have very different users than those of anything I've ever written then. :)

I think, Google recommends this for Android application development. Not that I would consider Google a shining beacon of great UIs.

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.

Interesting. I dropped Android a year or so back but can't remember bumping into an app doing it like that. Definitely encountered a few "are you sure?" style dialogues though.

The only one that comes to mind is the GMail app. When you swipe to archive an email, it gives you an undo button. I have to say I don't particularly like that UI though. If I accidentally swipe, then I only have a few seconds to undo it. I'd prefer a screen that showed me actions I've performed in the past, and let me undo them. That way I wouldn't have to worry about the undo popup disappearing too quickly.

The UI element typically used for this is the "Snackbar", so if you search for "Android Snackbar", you should find some examples.

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.

Thanks again.

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

https://www.nngroup.com/articles/ten-usability-heuristics/

https://asktog.com/atc/principles-of-interaction-design/

That's something entirely different, and very well known. I can't find any reference to providing a delay before you truly perform an action, but allowing undo for that time.

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.

On the web, it is extremely difficult to have an undo stack, so I'm talking about "undo" as implemented by appearing to do the action (eg delete), but delaying its actual action while giving the user the ability to undo it. If they take no action (or navigate away, etc.) the action is done.

In both of those links I posted, it clearly states well-designed systems have undo.

I think this depends on the actual semantics of the delete. If the operation is truly non-recoverable, and you simply lie about doing it and do it after a delay, there is a chance you will be caught in that lie when your process is cancelled or failed for whatever reason.

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.

That may be your opinion. But 30 years of HCI research and recommendations on the subject say otherwise:

https://en.wikipedia.org/wiki/Mode_(computer_interface)#Asse...

https://www.nngroup.com/articles/ten-usability-heuristics/

https://asktog.com/atc/principles-of-interaction-design/

That gives me an idea for my .bashrc:

  rm () {
    (sleep 30 && \rm "$@") & 
  }

(Untested, and I'm unlikely to use this.)

I’ve seen it generally recommended to use a different command rather than aliasing `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...

lol. good luck running a bash script that does a bunch of 'rm's.

His aliases wouldn't be in scope there.

Thanks a lot! Here is a better explanation https://unix.stackexchange.com/questions/362546/what-is-the-... . This seems like a decent gap in my knowledge.

Is it still going to be out of scope if he e.g. runs the shell script from the shell?

Not if the alias is in .bashrc / .zshrc and they execute the shell script in the normal way. If they source the script, sure. But no one runs scripts that way, for this exact reason.

Reply on news.ycombinator.com