Live data from Hacker News

Toasts are bad UX

maxschmitt.me

261–270 of 401 posts

Re: Toasts are bad UX

#261

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?

Front end is more specific than conventional – it has a graphical output, and is thus closer to 2D game development than to the “conventional” data structures and algorithms way of programming.

Re: Toasts are bad UX

#262

Let 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,…

Hang on, there's a few inaccuracies here (I think, since I only played mainline Dragonflight but not Remix, but at a relatively sweaty level for a non-competitive m+ player)

> 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
post #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.

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.

> The issue here is that the checkbox doesn’t match the exact state it’s supposed to represent…

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

#264

Earlier 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.

What kind of design choices do you find helpful with using a magnifier like that? It's not something I'd ever considered before, sounds tricky to design for but I'll try to keep it in mind now.

Re: Toasts are bad UX

#265

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…

A better UX is to show a confirmation in place. When you delete a task from the list - show a module in its place with a short message and the undo button. Showing a toast in a completely different part of the screen is hard to notice and hard to interact with as it's removed after a short delay. Also, if you delete more than 1 task quickly, toasts start stacking, and it becomes even less clear which one you want to undo.

Re: Toasts are bad UX

#266
Terrible article imo. You can’t approach UI from the perspective of a developer using the UI you just wrote, you need to think about it from a user’s perspective. That sometimes means having redundancy in the name of familiarity and legibility.

I 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

#267

Earlier 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.

Isn't a toast just the tail of a message log that's visible for a few seconds after a new message is added? I don't always want the entire log to be occupying space on my screen, but I do want to see when new items get added.

Re: Toasts are bad UX

#268

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…

You missed the main point, which is that the "toast" is nowhere near where you're looking when performing the action.

I didn't miss that point, I'm arguing that that point doesn't prove anything about the merits of a toast.

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

#269
post #76

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)

Where does the name toast come from anyway?

It was originally the name of a popular CD burning application for the Mac. Only much later, following the discovery of bread, did the term become popular for describing a slice browned by radiant heat.

Re: Toasts are bad UX

#270

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 grade A implementation would keep a local state that syncs to the server, indicates a sync is in progress, possibly stacks changes to reduce latency if there are a lot of changes + a slow connection and, to a user, gives me utmost confidence that I’m not going to lose data.

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.

Post reply on HN