GitHub no longer uses Toasts
primer.style
primer.style
I fail to see the relevance of your comment. So you came up with an explanation of why the page might have awful accessibility. How does this make the accessibility problem any better?
> would you prefer some static hydration garbage?
I think everyone would prefer to not wait 3 seconds to get feedback on what they clicked. We're talking about accessibility, right?
>How does this make the accessibility problem any better?
it's not a UX decision to load slowly on poor uplinks (fwiw it's near-instant on my machine). obviously nobody would /choose/ to do that.
toasts, though, are a definitely conscious UX choice.
Is it possible that your browser or internet connection are slow?
For comparison, Apple and Android have their own documentation:
https://developer.apple.com/design/human-interface-guideline...
yeah. OBVIOUSLY. good fucking riddance.
they wouldn't be half as bad if they always came with a notification center for seeing the ones you missed... but the other half is still incredibly bad and isn't worth using at all.
Are they really? Isn't it pretty normal "role status aria something something polite" thingy to announce feedback to user?
A message that you have to explicitly dismiss, and that's stored in a "message history" somewhere, is much more accessible and usable.
a "big banner image", buttons that are required to interact or dismiss, doesn't go away on its own after only a couple seconds, and might(?) also exist in the notification center
I think it's pretty safe to label that "definitely not a toast". That's just a notification, or maybe a "non-modal alert". Toasts are distinct from those by being brief and ephemeral.
You can see the API reference here: https://learn.microsoft.com/en-us/uwp/api/windows.ui.notific...
To make this a little more concrete with one example: if you are using fullscreen magnification, odds are toasts will literally never appear on your monitor. By the time you pan over to their little corner of the screen (if you ever do), the toast will be long gone.
Toasts have poor usability because its easy to miss them. This makes them bad for everyone, regardless of screen reader.
- quick, in response to a clicked button -> why not just show feedback on the button?
- quick, in response to a keyboard shortcut -> ok
- seconds or more after an action, say, if your import/export is done -> fine, but have a more persistent notifications inbox or send the user an email too, because if you dismiss the toast, how do you get back to that result?
- when you've just navigated to a page, as a way to present an alert or advisory about the new page -> if it's important enough, why not show it as a persistent alert on the page itself?
Far too many toasts are used for the last use case. Part of the reason for this, I think, is because if you detect something weird in a React callback, you'd need to wire up a whole new state variable to show it, vs. just calling a global toast() function at the time where you learn about the weird thing. But is it really much more work than toasting to roll something like const {alertElement, addAlert} = useAlerts()? And have it speak your design language?
Your 50-tabs-open multitasking users will appreciate you.
IMO a toast showing up shouldn't be a direct/immediate response to user action at all, ever. Toasts are purposely designed to steal attention. Don't try to steal attention from the user performing an action just to confirm that the action occurred; you already had their attention!
> if it's important enough, why not show it as a persistent alert on the page itself?
Because it's a crutch against bad design in an era when many companies don't employ designers, or arguably even as an exploit to be leveraged by marketing to try to brute-force the conversion of users to sales.
While there's nothing inherently wrong with them, I've become so accustomed to toasts being misused/abused that my instinctual response to that visual stimuli is that it's focus-friction and tantamount to being spammed, even when they're being used in benign or debateably useful ways.
You could have the button do some fancy transformation into a save button but I prefer the core page being relatively static (and I really don’t like buttons having state).
It’s the only reasonable scenario for toasts that I can think of though.
^ this is a great idea and please add it to github actions where it takes like 10 seconds for the new thing to show up on the list after you trigger one
E.g. you join a project with little to no error handling or success feedback. Slap some default toasts on everything! And then remove them page by page as you fix the horrible UI you inherited.
GitHub is large enough that they don't benefit from or want such a crutch, but not everyone is GitHub.
Sonner does it quite well (https://sonner.emilkowal.ski/)
- once set up, very easy to build, no “design” required
Toast cons:
- easy to miss
- at risk of layout issues (overlaying other information)
The tradeoff is real, but if the resources allow, I’d drop all toasts.
Which is why they then get thrown around thoughtlessly. It becomes easy to pretend to have solved a problem using a toast instead of actually solving it.
Like little 'saved' notifications when clicking through tabs, or email sent after clicking a send email button that might leave you on the same page
Web sites tend to over inform you of what's happening I like toasts (though I no longer use them since they're it of fashion) simply because you can disregard them
I wish software developers could drop this dogmatism. Same as the old Goto considered harmful trope outliving its usefulness and all that. It's always black and white - "people can misuse this tool, so this tool is inherently bad and should be eliminated from usage completely" - rather than acknowledging that many tools have great use cases even if they can also be abused.
There are also a lot of professional guis (think medical software), that use no toasts.
Some implementation that allows for browser level customization(timing, etc), as well as a notification center in the browser, and that integrates well with screen readers.
I like toasts from a visual perspective. They can look good(not always, of course), and they can convey small bits of information that could otherwise be displeasing to view in some designs. However, god have I missed a ton of notifications because of them disappearing too quick, and no way to view previous ones, or anything like that. I'm not visually impaired or anything, so I can't really comprehend the extent and issues people who do may have with toasts, and see what would be needed to make them accessible for them(if it's even possible), but would love to hear about it.
Why GitHub’s War On Toasts Is Bad News For Accessibility
https://medium.com/offmessageorg/why-githubs-war-on-toasts-i...
From the GitHub doc:
> User and system initiated actions that are direct and straightforward should be successfully completed as a matter of course. An example of this is creating an Issue, and then seeing the Issue show up on the list of Repo Issues.
The alternative proposes:
> Doing something, even as simple as adding a Jira ticket to a backlog, is not something I want to assume happened. I need to know it happened.
I fail to understand how seeing the created item in context does not let me know beyond any reasonable doubt that it was indeed created. Showing an additional toast adds nothing but noise and only showing a toast even more so.
I understand there are accessibility issues, but if the thing I am attempting to create will not be visible on the current view, what's the best approach?
Honestly, the same could be set for a large list or Kanban board. Just because of the number of records it may not be evident that the intended action occurred.
- create an issue: redirect to the created issue
- create an issue from a project view (kanban board): close the creation modal, stay on the view, and let the newly created issue show up in the list
- create a sub-issue from within an issue open in a side panel of project view: close the creation modal, stay on the parent issue and render the newly created sub-issue in the section called "sub-issues"
Within the awkward constraints where GitHub projects clash with the old UX of issues this is works very well and I know way beyond any reasonable doubt that the desired action has indeed been performed. Error states like failure to create an issue can be rendered in the modal and I can retry right in context too. I fail to see how toasts would add anything.
In a product based on different principles this might not be possible but then the GitHub doc is internal guidance and not a universal rule.
As an aside, GitHub's issue creation modal used in the project view is well executed.
... that's a somewhat odd stance to take.
"Toast" usually implies something that goes away on its own, though that's generally considered bad UX.
It's just jargon. Every field does that. In this case, you can really tell that it's two bits of jargon made up at different times, because one is dry and technical, and the other is a pun on "pop-up".
Again, this is sometimes appropriate, but it's desperately wrong in so many places it gets used.