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

31–40 of 45 posts

Re: Building a Toast Component

#31

Post by robin_reala »

ahallock wrote: post #15
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.

Zero effort, and they animate. Components that have animation baked in are drug-like in how they hook in designers and devs who are only thinking about the visual presentation.

Re: Building a Toast Component

#32

Post by toddmorey »

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…

When async notifications arrive from background processes… How is the user notified? (Not defending toasts, just curious how to do it better.)

Re: Building a Toast Component

#33

Post by toddmorey »

toddmorey wrote: post #32
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…

When async notifications arrive from background processes… How is the user notified? (Not defending toasts, just curious how to do it better.)

GitHub seems to suggest banners or “Also consider ways to notify the user in other communication channels such as email, notifications, or a push notification in the GitHub app.”

On MacOS… emails and push notifications create… toast messages

Re: Building a Toast Component

#34

Post by samsolomon »

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…

I’m the design leader for an enterprise software company and would love to get rid of toasts. Places where feedback is immediate don’t need them and simple forms can probably be fine with a banner or alert.

Reasons that toasts are difficult to get rid of:

- Easy for developers to implement consistently.

- Providing feedback where actions are taken on elements not on the screen (like bulk actions on a data grid, or within our workflow).

- Dense UIs where actions are taken frequently and injecting an alert or banner to be dismissed adds a ton of work for users. Also, causing the UI to jump isn’t great.

Would love to hear solutions to the above.

Re: Building a Toast Component

#35

Post by strogonoff »

nine_k wrote: post #19
jmercouris wrote: post #13

Earlier quoted context omitted.

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.

Toasts are popular, but not the only option if you want to notify the user about completion of a longer-running action when the user may have already switched away from where they started it. Consider a status bar[0] instead. You can make it cute and animated, too!

[0] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A....

Re: Building a Toast Component

#36

Post by chao- »

hungrymagnum wrote: post #28
varun_ch wrote: post #12

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)

This can be applied for a success (change the button to a green tick mark) or an unsuccessful action (change the button to a red x mark). But what if you want to give details on why the action was unsuccessful? How do you show it near the button or change the button itself?

>How do you show it near the button?

What stops you from placing these details you want as near as is reasonable to a button? Alternatively, placing the details near or in some container for the data/entity/element that the button relates to?

Re: Building a Toast Component

#37

Post by MrJohz »

robin_reala wrote: post #30
CharlesW wrote: post #14

Earlier quoted context omitted.

> 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 usabl…

Spectrum’s Toast docs don’t mention how they make Toasts accessible with screen magnifiers (more widely used than screen readers based on the last WebAIM surveys I saw), so I guess they didn’t consider them?

Everyone knows accessibility is just throwing aria tags at any element you see. The more aria tags there are, the more accessible it must be, right? /s

Re: Building a Toast Component

#38

Post by MrJohz »

samsolomon wrote: post #34
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…

I’m the design leader for an enterprise software company and would love to get rid of toasts. Places where feedback is immediate don’t need them and simple forms can probably be fine with a banner or alert. Reasons that toasts are difficult to get rid of: - Easy for developers to implement consistently. - Providing feedback where actions are taken on elements not on the screen (like bulk actions on a data grid, or wi…

I quite like the technique of adding a kind of "microtoast" right next to the element that's just been clicked/updated. So you'd click a button, and then directly above or below the button (or even on the button, depending on the notification), you add a bit of text saying the action has been completed. That disappears after a short delay, just like a toast. It's still got some of the accessibility issues that always come with popping up random elements in the UI, but at least it is directly next to where the user is interacting, so they can easily see that what they've done was successful, or failed, or whatever.

This works well for the last category, because it provides feedback but it doesn't need to be dismissed. But it also typically needs to be implemented afresh in each place it's used, which means more fiddly developer work.

All that says, I've lost this battle plenty of times and a lot of the stuff I've worked on ends up getting toasts in the end because they're just so much easier to implement than anything else.

Re: Building a Toast Component

#39

Post by akersten »

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…

GitHub is also limiting the new PR review page to only show 40 comments from reviewers. Who knows which 40. If you want to see more, they have a banner that tells you to switch back to the legacy view. No idea if they'll just silently lose the feature of "seeing all your PR's comments" once the legacy view is discontinued.

So I wouldn't take any inferences from their design system as gospel.

Re: Building a Toast Component

#40

Post by wildrhythms »

ahallock wrote: post #15
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.

Zero effort, and it's basically a crude visualization of a good old message bus :P
Post reply on HN