121–130 of 401 posts
I never found toasts to be bad UX
effective use of toasts is to confirm to that a big change that they initiated was successful. for smaller changes, like checking or unchecking a checkbox, toasts are redundant
Earlier quoted context omitted.
I think the suggested improvement clarifies what he means: if you're worried that the UI element the user is interacting with doesn't fully convey what's happening, then improve that element rather than adding a second element that divides the user's attention and challenges them to read quickly and make the connection themselves. Communicate the failure of their interaction in the context of the element they interac…
I get what they were saying and agree that in-context feedback should be added wherever possible. I just disagree that leaving off the toast is (in the cases cited) valuable. Taking the archive example: yes, the disappearing message successfully indicates that something happened. But it doesn't tell you if the message was deleted or archived, and misclicks are common. The toast unambiguously communicates what happene…
But adding a toast isn't free. It's a distraction, and arguably a pretty intense one for ND folks -- especially when it becomes a standardized message center with multiple items queued up.
In many cases the most useful toasts would also be better if they weren't toasts. For me, the most useful toast I interact with also demonstrates why toasts are bad UX: creating a new ticket in Jira. Since that can't happen instantly, it needs a delayed message to let you know when the ticket is created and you actually have a URL to open. A toast is useful in this case, but it's also far from optimal, because for some reason it's going to disappear in a few seconds, and it also won't tell me how many seconds I have left to read it.
Why would distraction be the primary mechanism? We figured out decades ago how to put a button in the header that opens a messages feed which the user can read and dismiss at will. While it's possible to implement such a feed badly so that it's annoying, it's difficult to implement toasts in a way that aren't annoying. Maybe even impossible.
Earlier 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…
This is what message feeds are for. Toasts are just a worse implementation of message/notification feeds.
I'm not convinced. Most of the argument seems to be that redundant UX is bad UX: > But by archiving the email, the email disappears from the list, which already implies the action was successful. > In this example, the button already includes a confirmation so the toast is entirely unnecessary. I vehemently disagree with the idea that just because you're already communicating something one way it's bad UX to include…
The unfortunate thing is they aren’t communicating the same thing. Taking the YouTube example, the checkboxes are 100% optimistic while the toast notification indicates that the request to the backend that was fired off asynchronously was successful. With the archive message example, it is the same thing. The message is removed from the list optimistically and the toast message is representing that the message was ac…
A toast makes sense only in 1 case: when it's a notification that is unrelated with the current action of the user. Similar to OS types of notification that the defunct Growl (memories) invented. Any feedback from a user action should be done within the context of the user action. If the action is async, it should be clear and the feedback should instantaneously indicate that the action is queued for processing. In t…
I'd add one more scenario: when the UI element that would give feedback, normally, has been removed, yet you still want to show feedback. If I removed a task from a board, I can't show - on the task - how to undo that action. There's a keyboard shortcut to undo it, but how would the user know, visually? I'm not going to replace the task with a note because notes don't belong in task lists - only tasks do. I'm not goi…
I think the actual issue is that Google makes bad UX often, and not toasts in general. Toasts themselves can be done well, but like every UI and UX element, they need to have some thought. I know Google have some good UI (sometimes UX on Android) every now and then but they are so fractured as a company, with so much product and feature churn, that their UX is all over the place. Every single Google app reinvents how…
Yeah, its wild because they were the ones who introduced the pattern to the general audience. And it was so successful that others started integrating it in non-material contexts. Toast and toast + action are here to stay, and for good reason, but I think google has individuals willy-nilly making design decisions and not quite being fully aware of how these elements should be used.
How about just getting rid of all food related jargon; salad bars, burgers, toasts, heroes etc.? As a backend developer this stuff is mind-boggling, just call it "notification widget", or a "confirmation widget" etc. Try explaining what toast is to an Indian subcontractor who has never eaten toasted bread in their life and then apply that to the UX usecase. Removing these terms will also improve accessibility and und…
How would you call a hamburger menu? "menu widget with three-or-sometimes-a-different-number-of little horizontal lines"?
As a backend developer you also have some jargon but you’re too used to it to notice it.
Their latest “addition” was rewinding a video after a long pause. You watch a video, pause it at t=1:24:57 and go to sleep. Next day you start the video again and it goes for a while from t to t+n (depends on the buffered data), until it jumps back to t-20s.
Someone thought it’s a good idea to -20s after a long pause, and it might be good, if they assigned a proper developer to the task. Instead someone pushed an obviously idiotic change, without anyone checking. It’s not even an issue, it’s clearly “job done” by someone who couldn’t give a lesser fuck due to ieee754 limitations.
You cannot avoid that behavior. If you go forward/back or manually jump elsewhere, it still resets you to t-20s shortly after. You might think you just reload the page, but reliably saving the current position is not in their competence either.
That and a dozen other stupid bugs they fiddle with constantly but can never fix. Literally on a site with a sidebar and a grid of equally-sized elements. Their thumbnail card alone takes 7.5 pages (17KB) of html.
For 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…
Agreed; a better solution would be to assume success and show these messages only if an error occured.