> 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?
Building a Toast Component
21–30 of 45 posts
Re: Building a Toast Component
#22Meanwhile, 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…
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.
Re: Building a Toast Component
#23Toasts 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"
That’s why confetti exists
Re: Building a Toast Component
#24Was 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 ... "
Re: Building a Toast Component
#25Meanwhile, 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…
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)
Re: Building a Toast Component
#26Earlier 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.
There are certainly times where this must be the case, but I think it's broadly better to have designs avoid this.
Re: Building a Toast Component
#27Toasts 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 s…
Dialogs don't have to be modal, and in the parent comments context they aren't.
Re: Building a Toast Component
#28I’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?
Re: Building a Toast Component
#29> 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?
Yes, exactly that’s the case.
Re: Building a Toast Component
#30Meanwhile, 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…
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?