Earlier quoted context omitted.
As a developer who started with jQuery and then Backbone.js it seems like frontend dev has become very rich but at the same time has developed some weird esoteric rituals and practices which don't seem to go with conventional software engineering.
I'm curious as to how you're defining 'conventional software engineering' here; can you give some examples of things that are not conventional software engineering in the front end?
Toasts are bad UX
261–270 of 401 posts
Re: Toasts are bad UX
#262Let 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,…
> They dominate roughly 30% of the screen real estate (when presented in volume), smack in the center.
Pretty sure this is customizable. My loot toasts are relatively discrete, I can put them wherever.
> Similarly, if you log into a zone, particularly a quiet zone, it's not uncommon for the screen to explode with alerts telling you of all the rare monsters that are simply sitting there because the zone is very quiet for players.
This sounds to me like you're using the addon SilverDragon which is deliberately obnoxious about alerting you to rare monsters, but with it you can control every aspect of the alert, when/where they occur, or disable them entirely.
Re: Toasts are bad UX
#263> 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.
In this specific example you do have an Undo button: the checkbox itself. The issue here is that the checkbox doesn’t match the exact state it’s supposed to represent: if you check it, for a few seconds it’s checked but the video is not yet saved; if you uncheck it it’s not unsaved until the toast appear. If you repeatedly check/uncheck it you don’t know in which state you end up.
This can all be fixed. E.g. disable the checkbox while it’s processing; or show a small loading indicator; make it impossible to click the checkbox repeatedly. Etc.
A frontend update that doesn’t wait for the server is nice, but only when server state is irrelevant. If the user wants to know about the server state, then the UI should always indicate that.
Re: Toasts are bad UX
#264Earlier quoted context omitted.
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…
Toasts showing up far from where the action is take also makes them super annoying for people (like me) who use screen magnifiers. I'm oftne using a site while zoomed in, and will completely miss a toast, because it never enters the "viewport" on the screen I'm looking at.
Re: Toasts are bad UX
#265A 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…
Re: Toasts are bad UX
#266I agree YouTube example is pretty bad, but the gmail one is a really good use of a toast! What do you mean “you can see the email is removed from the list”?? Have you ever used email before? You usually have more than 3 messages, and seeing which one was removed, let alone that one was removed at all is not always obvious. And “undo” is incredibly important since you don’t have direct access to the removed item (and sometimes it’s a time sensitive action like undoing sending an email). The last one is not very helpful but not harmful either.
Also even if all the the examples were truly horrible and despicable uses of toasts, 3 bad examples are not enough to say a commonly used UI pattern is outright “bad”.
Re: Toasts are bad UX
#267Earlier quoted context omitted.
Why not both? A message log can always be consulted later, but it doesn't give you a live feed of things that are happening. I'm also ADHD and, like OP, I appreciate having the stream of toasts that lets me know what the software did. It's saved my butt a bunch of times when I accidentally do something I didn't mean to (deleting instead of archiving, for example). A message log would just get ignored, but toasts help…
A message log can also be visible...? The only differences between messages in toasts vs messages in a log is that toasts control the user rather than the other way around.
Re: Toasts are bad UX
#268I'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…
You missed the main point, which is that the "toast" is nowhere near where you're looking when performing the action.
Their examples are all arguments of where local information should have been displayed. I agree with them in general. I just think that a toast should also be displayed in each of the situations they identify.
What seems to have happened is that they correctly identified a problem with lack of local information and blamed it on the presence of non-local information, which is fallacious. You can have both, and I believe that a UI with both is generally more usable.
Re: Toasts are bad UX
#269For 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)
Where does the name toast come from anyway?
Re: Toasts are bad UX
#270I'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…
Now my presence is to use this grade A type of implementation because I like very solid software and I’ve done it so many times now that I can bang it out in a coding interview. Or explain it to a team so they can implement it.
But your average app is like a grade D. Even Instagram or Snapchat where I’m never too sure if my stories are going to be in order if my connection fails or even though it lets me cancel an upload, if I do it slightly too late the app fails to cancel because it can’t keep track of its own state through a state transition.
So for 99% of apps, I want them to put a redundant toast. I do not believe they can build solid software with proper state management. At least the redundant toast lets me know it did go through. A lack of toast doesn’t mean it went through because some people barely can implement error handling.