For anyone as confused as I was, this article is not about toasted bread [1], but about a type of UI widget [2]. [1] https://en.wikipedia.org/wiki/Toast_(food) [2] https://en.wikipedia.org/w/index.php?title=Toast_(computing)
Should have been called "pop-tarts."
Toasts are bad UX
131–140 of 401 posts
Re: Toasts are bad UX
#132The redesign of the "Save" operation is better than the original, where the checkbox list is positioned in context, and there is an indicator for the async operation.
But I think it would be better if it kept the toast. When the operation completes successfully, presumably the async indicator just disappears. That has no impact and a toast fixes that.
Also, presumably the operation can fail. I suppose you'd replace the async indicator with a red X or something, and maybe revert the checkbox. But it would be useful if there could be a textual description of what went wrong, and a toast is a nice and consistent way to present that.
Re: Toasts are bad UX
#133> The "Undo" button in the toast is unnecessary because the user can just click the checkbox again I disagree with this part, at least in general. Having an Undo is very good if you have accidentally clicked somewhere and don't know precisely where, and you don't know the application well enough to easily undo based on the message alone.
Re: Toasts are bad UX
#134For me the worse aspect is that they disappear (too quickly), and that they sometimes unnecessarily draw attention to themselves for success messages where you would trivially assume the action to succeed. The combination of the two is particularly vexing: Your attention gets unnecessarily diverted, but you don’t know if it wasn’t actually important because it disappeared too fast. Conversely, there’s also a variatio…
Re: Toasts are bad UX
#135Earlier quoted context omitted.
Have you worked with an old person? Redundancy in UX confuses them. The closer you can get to the whole UI being a single sentence and two buttons the better.
Have you? Things disappearing with insufficient explicit feedback for what actually happened to the things is one of the most common issues I've encountered with older computer users. I think it's the most common issue. Toasts add persistency and visibility for users who barely or don't understand the UIs they're interacting with, which makes it easier to understand what happened. If Outlook gave feedback to every us…
That would make me utterly crazy. I couldn't use an application that did this.
Re: Toasts are bad UX
#136Teams has, hands-down in my opinion, _the_ worst usage of toasts that I've seen. It's bad enough I get the OS toast from Teams, that may or may not disappear on its own after a time (on both Windows and Linux). However, there's also an in-app toast that blocks part of UI that is used the most: replying to messages. Literally, typing a reply, then boom, toast appears, blocks most of the buttons used to interact with your reply. (formatting, emoji/gifs, attachments and even the reply button!)
Re: Toasts are bad UX
#137It's a lazy cop-out to avoid having to figure out how to integrate important elements into the design of your page.
I find Google/Material Design's floating action buttons very frustrating.
Re: Toasts are bad UX
#138Earlier quoted context omitted.
Have you worked with an old person? Redundancy in UX confuses them. The closer you can get to the whole UI being a single sentence and two buttons the better.
Have you? Things disappearing with insufficient explicit feedback for what actually happened to the things is one of the most common issues I've encountered with older computer users. I think it's the most common issue. Toasts add persistency and visibility for users who barely or don't understand the UIs they're interacting with, which makes it easier to understand what happened. If Outlook gave feedback to every us…
Re: Toasts are bad UX
#139Re: Toasts are bad UX
#140Earlier quoted context omitted.
Fair enough, but when they are not communicating the same thing, there are no grounds for objecting to them on the basis of redundancy. The problem with notification only of failure is that one is left uncertain about success, though I would agree that striking a balance between distraction and uncertainty is difficult.
It also would mean you would move the item eagerly, then put it back on error. Or alternatively make it a "ghost" item in the list then remove on success. But overall the eager-move + toast + undo is just a much faster feeling implementation and the overall UX is so much cleaner.
For the checkboxes, I'd say GitHub nailed it: for settings that are applied instantly (e. g. https://github.com/settings/appearance), they show a spinner and then a single checkmark right across the section title. (It used to be next to the input element – both ways are fine, I think)