5 ms·

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 peo

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

Sylos 8y ago
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.
- oldcynic 8y ago
  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.
  - wtetzner 8y ago
    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.
  - Sylos 8y ago
    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.
    - oldcynic 8y ago
      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
ProxCoques 8y ago
https://www.nngroup.com/articles/ten-usability-heuristics/ https://www.nngroup.com/articles/ten-usability-heuristics/ https://asktog.com/atc/principles-of-interaction-design/ https://asktog.com/atc/principles-of-interaction-design/
- oldcynic 8y ago
  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.
  - ProxCoques 8y ago
    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.

Sylos 8y ago

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.

oldcynic 8y ago
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.
- wtetzner 8y ago
  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.
- Sylos 8y ago
  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.
  - oldcynic 8y ago
    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

ProxCoques 8y ago

https://www.nngroup.com/articles/ten-usability-heuristics/ https://www.nngroup.com/articles/ten-usability-heuristics/ https://asktog.com/atc/principles-of-interaction-design/ https://asktog.com/atc/principles-of-interaction-design/

oldcynic 8y ago
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.
- ProxCoques 8y ago
  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.