Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Toasts are bad UX

maxschmitt.me

Post reply on HN
Print view View original

21–30 of 401 posts

Re: Toasts are bad UX

#21

Post by ervine »

Manfred wrote: post #13
ervine wrote: post #7

Maybe bad UX, but global error / success handling of network requests is way easier than handling in every component that triggers one.

I don't think that's a convincing argument unless you are a tiny company that has to optimize for development time. You can also wonder why the frameworks you are using make this hard, because it's a pretty common to want feedback close to where the action happens.

I didn't say it was hard, it's just very nice to not have a bunch of extra error / success code in all of your components that make async requests.

Trade offs, as usual.

Re: Toasts are bad UX

#22

Post by Y-bar »

storafrid wrote: post #8

The solutions seem to rely on a user that doesn't navigate before the action is completed. Does he propose locking the UI in the meantime, or to optimistically show the user a success result?

Debouncing is a known development tool for most non-immediate actions. It's related UI concept of locking individual UI elements is also well understood by many users (not by that technical name, but by "it's working on my action" kind of understanding).

> optimistically show the user a success result?

I don't particularly like React, but this a core feature of such JS frontend frameworks, optimistically "succeed" while async network and back-end work happens to give the illusion of speed: https://react.dev/blog/2024/04/25/react-19#new-hook-optimist...

Re: Toasts are bad UX

#23

Post by jagged-chisel »

gr__or wrote: post #14
storafrid wrote: post #8

The solutions seem to rely on a user that doesn't navigate before the action is completed. Does he propose locking the UI in the meantime, or to optimistically show the user a success result?

Came here for exactly this, the post is proposing a solution while only understanding one half of the problem. Toasts are a global UI feedback mechanism for non-blocking/fallible/undo-able actions. That does make them out-of-place by default, but at least consistently so. A solution I'd accept is local-view-first with toasts-as-fallback when the view is dismissed. That said, loading indicators _might_ make users hesi…

The dismissal should communicate to the user in a way that indicates the process will continue without the view.

Re: Toasts are bad UX

#25

Post by qwertox »

YouTube has even better examples.

Go to https://www.youtube.com/feed/history and click "Comments" on the right side. Then delete one comment.

You will get one toast indicating that it will be deleted, and one a second or two later indicating that it got deleted.

If you delete multiple comments quickly one after another, you'll first get a bunch of toasts indicating that the comment will be deleted, and then, with that second or two delay, each confirmation, but they do get deleted sequentially, so you have to wait for all the confirmation toasts. Which for a deletion of 10 comments will take more than 10 seconds, even if you clicked them all in two or 3 seconds.

Same with the live comments at

https://myactivity.google.com/page?page=youtube_live_chat&co...

Re: Toasts are bad UX

#27

Post by Y-bar »

is_true wrote: post #17

Always = in Material design https://m3.material.io/components/snackbar/guidelines

They even acknowledge the limitations and problems with Toasts:

> 1. Add inline feedback

>

> Information in auto-dismissing snackbars must also be communicated using another accessible method inline or near the action that triggered the snackbar.

Re: Toasts are bad UX

#28

Post by teqsun »

Toasts can be bad UX (usually when they are the sole feedback), but they are great in conjunction with other elements.

A confirmation toast with a page-redirection is a great way to add additional indication to the user that their submission was successful.

A warning or error toast in addition to standard form validation indicators gives a great secondary indication to the user that they need to change something.

And if implemented in a catch-all for nonspecified errors, it'll allow the user to preserve the state of their page vs rerouting to an error page.

If used as one tool in the toolbox vs the only tool in the toolbox, it's a great option.

Re: Toasts are bad UX

#29

Post by epolanski »

Manfred wrote: post #13
ervine wrote: post #7

Maybe bad UX, but global error / success handling of network requests is way easier than handling in every component that triggers one.

I don't think that's a convincing argument unless you are a tiny company that has to optimize for development time. You can also wonder why the frameworks you are using make this hard, because it's a pretty common to want feedback close to where the action happens.

In my experience the overwhelming majority of teams out there are understaffed (especially when it comes to good and productive professionals) so your example is the rule, not the exception.

Re: Toasts are bad UX

#30

Post by perlgeek »

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

Post reply on HN