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

41–45 of 45 posts

Re: Building a Toast Component

#41

Post by wildrhythms »

chao- wrote: post #36
hungrymagnum wrote: post #28

Earlier quoted context omitted.

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?

Good idea, but impossible to do when the user switches away from where the initial async interaction began.

Re: Building a Toast Component

#42

Post by heystefan »

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)

Re: Building a Toast Component

#43

Post by bitbasher »

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.

Re: Building a Toast Component

#44

Post by bitbasher »

CharlesW wrote: post #14
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 usabl…

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

Post reply on HN