LinkedIn toasts are the worst.
Toasts are bad UX
251–260 of 401 posts
Re: Toasts are bad UX
#252Earlier quoted context omitted.
> In this specific example you do have an Undo button: the checkbox itself. That's false. The checkbox itself is not a viable undo button under any circumstances in this specific example (i.e., you accidentally clicked but have no idea where, and let's assume you have no idea of that particular checkbox's state prior to the accident). Any adjacent checkbox would have extremely similar plausibility for a user wonderin…
> i.e., you accidentally clicked but have no idea where, and let's assume you have no idea of that particular checkbox's state prior to the accident That the same for every single checkbox in every single form on the Web. Even in the unlikely case in which you clicked on the lists button that opens the popin and then accidently clicked on a checkbox without seeing which one and without seeing the checkbox state chang…
> That the same for every single checkbox in every single form on the Web.
In my experience, the majority of forms on the web don't commit until you decide to submit, so if you have an accident before then, you can recover (well, buy a sense of certainty at the cost of redoing some work) by reloading the form. In contrast to that majority, here we're talking specifically about forms where each component auto-submits immediately. I think that if a component auto-submits, then anything related to that submission (success/failure status, undo, etc.) should be presented within that very component.
Re: Toasts are bad UX
#253There things worse than toasts: hidden slide panels. They are basically hidden toasts that are necessary for some actions and are completely unintuitive, unfindable and undiscoverable. My worst experience was with waze using the cellphone of someone else; I had to do something (don't remember what) and just stared at the screen (like a retard) trying to guess what I had to do; the person eventually got the phone, sli…
I remember installing Snapchat one and immediately realizing how awful it was. Different corners had different functions. It needs to be illegal
Re: Toasts are bad UX
#254I'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…
I don't entirely hate toasts, I don't think your example is good, either. A toast is best for asynchronous, high priority, fleeting information.
You don't want to stack them, or if you do you need some sort of inbox for them. You don't want to be spammed by them, you don't want them used as a stand-in for representing object state.
For a checkbox, I'd rather the info be communicated "inline" maybe by color/shape/shading. A toast could be used like an info popup, perhaps i.e. "why did my checkbox get reverted".
Or it could be for a high priority event, that just doesn't fit (well) in the current screen. But, again, care should be taken.
If you communicate with your user, don't spam them - provide them with prompts and visually appealing methods to obtain their data. Toasts can be a part of that but shouldn't be the first tool reached for (ideally). I think the reason they are so dangerous is because they are outside the main UI flow, its technically and visually "easy" to use them.
Re: Toasts are bad UX
#255Re: Toasts are bad UX
#256For 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)
Thanks! I pinned the second link to the top: https://news.ycombinator.com/item?id=41304011.
Would it be ok to assign you as the author of that comment? I don't want to take credit for your link.
Re: Toasts are bad UX
#257Let me share the dark side of Toasts. World of Warcraft has these, they're used for lots of things. Notably achievements and things like that. There's also add on that look for rare monsters and pop up when it detects one while you're flying about in the land, loot drop announcements However, we just went through a special event called "Remix" which basically offered degenerate gameplay. Absurdly powerful characters,…
In this case, this is a video game, it isn't meant to be productive, it is meant to be awesome, and an excessive number of toasts can be awesome, especially during an excessive event.
The problem here is not that there are too many toasts, it is that they are annoying. Having a stylish way of dismissing them all could turn that annoyance into something awesome.
Re: Toasts are bad UX
#258Earlier quoted context omitted.
> Note that Snackbars are preferred for brief messages while the app is in the foreground. https://developer.android.com/reference/android/widget/Toast
That's the Android widget, not material design which is used for YouTube's UI
I fear we're talking past each other. Material Design doesn't have a Toast.
Material Design Snackbars aren't toasts:
* Snackbars are local, toasts are global
* Toasts don't receive focus, snackbars can (via the optional action)
* Toasts auto-dismiss. This is optional for snackbars
* Snackbars can explicitly be dismissed early by a user
Re: Toasts are bad UX
#259Earlier quoted context omitted.
If it's supposed to be a "modal operation", then it's supposed to complete before any of this becomes relevant. When that can't happen (e.g. because of an Internet hiccup), IMO the user should be able to take manual action to "minimize" (reversibly hide) the widget, but it shouldn't disappear until the operation is complete.
> it shouldn't disappear until the operation is complete Says you, but why? There are many workflows where this would be an unnecessary slow point in the user's work. It's all about balance. If 99.9% of the time a non-instananeous operation will succeed, and the user has faith that it will succeed, leaving the modal up is a terrible UX. But quietly notifying them on success might not be.
>but why?
Because otherwise I wouldn't be able to get it back. But if I have some kind of temporary hiding feature, I can easily use that as soon as I notice that the operation hasn't immediately completed. (And again, the common case should be that it completes immediately.)
And if something isn't supposed to be instantaneous, I hold that the interface shouldn't be modal anyway.
Re: Toasts are bad UX
#260Earlier quoted context omitted.
The inevitable tradeoff here is having a somewhat standardized location for notifications versus allowing them to appear arbitrarily determined by the developer’s notion of where they are ostensibly drawing your attention. Maybe that’s worthwhile, but I think there are going to be a lot of cases where the ideal location is ambiguous, or where devs have an idea for where your attention will be that’s not always correc…
It's not standardized. And putting notifications on or right next to a control you're INTERACTING WITH is not "arbitrary" at all; you must be looking at it, because you're using it.
Doesn't it depend on your platform, and isn't experimentation the way things become standardized?
User notifications on MacOS are definitely standardized, but originally they were Growl notifications until Apple made it a first-party API and iterated on it.