Building a Toast Component

Building a Toast Component(emilkowal.ski)

119 points by FragrantRiver 166 days ago | 42 comments

robin_reala 162 days ago |

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

[1] https://primer.style/accessibility/toasts/

CharlesW 162 days ago | |

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

thunderfork 162 days ago | | |

I think that toasts are kind of an attractive nuisance when it comes to accessibility.

They can technically, with ample constraints and a great deal of restraint, maybe end up complying with WCAG, etc., but all it takes is one developer saying "well a toast is easy" or "this isn't that important, make it auto-dismiss" and you're back in bad pattern town.

You see this with government web design systems - they have a very limited and constrained palette of patterns, because it allows for more consistency and reliable accessibility, versus having a bunch of tools that you just generally shouldn't use.

(The GitHub page linked above also makes a great case for how "making toasts accessible" isn't as simple as just having the right aria roles - lots of details the Adobe design doesn't seem to completely cover, unfortunately)

robin_reala 161 days ago | | |

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?

bitbasher 160 days ago | | |

> It's a red flag for sure.

The first red flag was the repeated screenshots featuring Theo Browne, as if his thoughts or ideas carry any kind of authority.

samsolomon 161 days ago | |

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.

MrJohz 161 days ago | | |

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.

chipheat 162 days ago | |

Not too hopeful with accessibility, as it isn't pleasant to use at all with reduced motion enabled. They flicker when added and linger around when swiped away.

akersten 161 days ago | |

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.

toddmorey 161 days ago | |

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

toddmorey 161 days ago | | |

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

jmercouris 162 days ago |

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.

jopicornell 162 days ago | |

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.

mhitza 161 days ago | | |

Dialogs don't have to be modal, and in the parent comments context they aren't.

oulipo2 162 days ago | |

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

jmercouris 162 days ago | | |

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

tyre 162 days ago | | |

That’s why confetti exists

ahallock 162 days ago | |

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.

robin_reala 161 days ago | | |

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.

wildrhythms 161 days ago | | |

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

varun_ch 162 days ago |

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)

hungrymagnum 161 days ago | |

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?

chao- 161 days ago | | |

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

heystefan 161 days ago |

Not sure where all the Toast hate is coming from in this thread, but I know two instances of Toasts that I use daily and they help a lot:

- macOS screenshots

- Linear toasts after every action (with common actions on them such as copy link)

bitbasher 160 days ago |

I always used flash messages instead of toasts. I'm not sure if flash is the right term-- it's the inline message next to or above the form/element that changed or was submitted.

I thought flashes were easier to see (not only for people with special needs). As it turns out, when you make things more accessible, everyone wins.

I went through a phase where I used toasts because it felt like everyone was using them and my product/design was "old". I happily went back to flash messages when I came back to my senses.

araes 162 days ago |

Was really hoping it was an article about making electronics out of fried bread products. "With electrodes wired to our margarine covered breadboard we were able to accomplish ... "

anilakar 162 days ago |

Scrolling that web site on mobile is really choppy.

tpetry 162 days ago | |

Perfectly smooth on iOS for me.

onion2k 162 days ago | |

Looking at the replies to your comment makes me think that maybe the browser software isn't the only factor that impacts website perf.

slig 162 days ago | |

Exploded my mobile browser on Android.

urban_alien 162 days ago | |

VERY laggy on Android FF.

leosanchez 162 days ago | |

Perfectly smooth on Android FF.

Waterluvian 162 days ago |

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.

nine_k 162 days ago |

> While I’m sacrificing discoverability and clarity, it feels elegant to me

Sigh. So much of modern "UX design" seems to be lured by this siren call :(

jgalt212 162 days ago |

> It’s now downloaded over 7,000,000 times per week

Why do all these packages have so many downloads? Are all the CI / CD routines always downloading a fresh copy and not caching?

mmarvin 161 days ago | |

Yes, exactly that’s the case.

djbarnwal 162 days ago |

This was a great read!