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

Building a Toast Component

emilkowal.ski

Post reply on HN
Print view View original

11–20 of 45 posts

Re: Building a Toast Component

#11

Post by oulipo2 »

jmercouris wrote: post #8

Toasts are a great way to lose information. They are a terrible design and should not be used. They distract the user, are not dense with information, and provide no value. If a message is important enough for the user to read, it should be a dialog box.

Most of the time they're used for a quick visual confirmation that "your operation went right"

Re: Building a Toast Component

#12

Post by varun_ch »

I’m far from a UX designer but whenever I use something with toasts I feel like I don’t notice them pop up in my periphery. I think it would be better if the confirmation for an action I did just showed up wherever I performed that action (like a button changing state to a spinner and then either an error or a confirmation)

Re: Building a Toast Component

#13

Post by jmercouris »

oulipo2 wrote: post #11
jmercouris wrote: post #8

Toasts are a great way to lose information. They are a terrible design and should not be used. They distract the user, are not dense with information, and provide no value. If a message is important enough for the user to read, it should be a dialog box.

Most of the time they're used for a quick visual confirmation that "your operation went right"

The information that the user did something "right" should be responsive next to where the user initiated the action- not in a random corner.

Re: Building a Toast Component

#14

Post by CharlesW »

robin_reala wrote: post #7

Meanwhile, GitHub is removing Toasts from Primer, their design system.[1] They’re next to impossible to implement in a way that retains accessibility across all needs, and if you try to restrict their usage to places where accessibility doesn’t matter so much (simple ephemeral confirmations) people misuse them anyway. It’s notable that accessibility isn’t mentioned once in this post, or, in fact, in the component’s d…

> It’s notable that accessibility isn’t mentioned once in this post, or, in fact, in the component’s documentation.

It's a red flag for sure. That said, there's nothing preventing toasts from being accessible: https://react-spectrum.adobe.com/react-aria/useToast.html

I think it would be accurate for GitHub to say, "GitHub no longer uses toasts because we didn't want to make the effort to make them accessible or usable."

Re: Building a Toast Component

#15

Post by ahallock »

jmercouris wrote: post #8

Toasts are a great way to lose information. They are a terrible design and should not be used. They distract the user, are not dense with information, and provide no value. If a message is important enough for the user to read, it should be a dialog box.

Developers reach for Toasts because they're zero effort. Good user experience takes a lot of thought and you can skip all that with Toasts haha.

Re: Building a Toast Component

#16

Post by Waterluvian »

Despite being the first point made, i feel that it’s likely the name didn’t contribute to its success, and possibly worked against it. It’s not discoverable and it doesn’t tell the reader much of anything. It’s the kind of name you get away with when your product is established by other means.

Re: Building a Toast Component

#17

Post by jopicornell »

jmercouris wrote: post #8

Toasts are a great way to lose information. They are a terrible design and should not be used. They distract the user, are not dense with information, and provide no value. If a message is important enough for the user to read, it should be a dialog box.

Dialogs are a great way to lose information. They are often dismissed by users that want to do their job and are interrupted by modals. Users focused on their tasks blindly dismiss dialogs.

Read the above as a critique to your strong opinion and not an opinion of mine.

My opinion is that toasts are great for notifications that can be reviewed/checked later, like chat notifications or finished background tasks.

What should be avoided, just for the same reason as modals/dialogs, is an overuse, causing fatigue.

Re: Building a Toast Component

#19

Post by nine_k »

jmercouris wrote: post #13
oulipo2 wrote: post #11

Earlier quoted context omitted.

Most of the time they're used for a quick visual confirmation that "your operation went right"

The information that the user did something "right" should be responsive next to where the user initiated the action- not in a random corner.

That control may not be visible by the time the operation completes.
Post reply on HN