Lecturing about accessibility with latency so high that you have no idea if any clicks are actually meaningful. I click "banners" and there's no indication anything is happening until 3 seconds later, when it takes me to a page that doesn't directly talk about banners until later. Then there is a link there that says "banners", and takes me to a different page, 3 seconds later. No indication that anything is happening or waiting during that time.
that's just an <a href> link. the only latency is your browser pulling the (admittedly, unnecessarily large) page -- would you prefer some static hydration garbage?
- 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.
GitHub primer is an interesting resource to read through, thanks. You don't have to agree with everything that is said to gain something from it and certainly beats winging it based on vibes.
For comparison, Apple and Android have their own documentation:
> User and system-initiated actions that require more complicated interaction may need additional feedback mechanisms to help inform the user that their request was successfully enacted. An example of this is the bulk creation of Issues.
^ 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
>Toasts pose significant accessibility concerns and are not recommended for use.
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.
Accessibility is more than just screen readers. Toasts are also not accessible for folks with low vision, low peripheral vision, etc. And the time-based disappearance is unpleasant for many people, as one of many examples of "accessibility improvements are also often usability improvements".
A message that you have to explicitly dismiss, and that's stored in a "message history" somewhere, is much more accessible and usable.
> Toasts are also not accessible for folks with low vision
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.
Can confirm. I zoom and pan on lots of websites in my daily browsing and would have no idea if toasts are popping in and out. I'll notice system level toasts though.
That depends on the size of the toast, appearance and frequency. We (an MSP) used a Windows toast notification[1] to encourage people initiate the Win10 > Win11 upgrade at their own convenient time (before it gets forced down on them) - and we got a pretty high uptake. The overall feedback from both the project team and users were good: the toast was unmissable, the text explanation was clear, and the big banner image was eye catching.
Okay you are right, timer-adjustable disappearance and history is important too and if it's local to where user's fields of view it's better than a toast every time of the day.
Accessibility doesn't even need to be related to any disability or unusual user requirement. A user-hostile website can be inaccessible even to users with perfect visual and motor functions.
> once set up, very easy to build, no “design” required
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.
Generally I have treated toasts as reassurance rather than important information
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
This is a terrible overview. The actual primary benefit of toasts is that they provide feedback on low-importance events without requiring the user to interact with them and without permanently taking up UI space. The web application I use most frequently would be infuriating if I had to deal with a modal window every time a toast would have been used, and UI space is at a premium for useful functionality, so occupying a permanent spot to relay those messages isn't a good solution either.
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.
Modals are, IMO, the literal worst UX element you can hate your users with. There are certainly valid use cases, but _absolutely not_ should be the default.
I personally don't find modals inherently all that bad, though they can definitely be implemented poorly. Does anyone have specific reading material on the problems with modals?
Thank god, toasts are so annoying. Every little action in Google Calendar has an associated toast/snackbar to go with it that tells you exactly what you just did and asks if you want to undo it. Like wtf? I can’t use my calendar app without these stupid toasts flying in and out and trying to draw my attention to read some irrelevant text. They go away too quickly for anyone not technically literate to click on them, and they are too slow to keep up when you’re creating a ton of events (they just fly in and out). I hope these go away, they add nothing to the application.
Modals are different from toasts. Modals take over your screen; you go into a separate "mode" for them. Toasts are non-modal; they just take up screen space but you don't have to interact with them.
"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".
They say to replace them with Banners, which are just a different style of a "Toaster", just usually stay longer, or are permanent until the user takes an action.
No, it's different. A "toast" is a floating element, a "push notification" which is detached from the panel, e.g. can disappear quite quickly. The banner is placed closest to the context where the action is triggered, e.g. might require the user to close it. If you have some disability, e.g. cognitive, visual or motor, it's likely to be easier to perceive the information. When a user creates an "issue", the "issue item" is displayed in the list, meaning that you won't need a secondary notification process.
The main problem with toasts is that they disappear with no hope of recovery before you get a chance to read them, obscuring other content in the process. Banners don't obscure other content, don't disappear without user action, and could theoretically have a message history.
A strange take. Toasts don't work so GitHub (and by extension MS) should have gone through W3C to implement a browser-wide solution instead of replacing them with alternatives in their products?
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.
Honestly, the JIRA example points out one of the main cases where I'm not exactly sure how to replace a toast. You don't have to be on the board to create a ticket in JIRA—so it may not be obvious in context.
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.
I am lucky in that I haven't used Jira in many years, so here are some examples of how GitHub does it:
- 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.
The standard way in desktop GUIs is a status line or similar. In other words, a dedicated area that displays the results of the last action. It has the important property that it doesn’t disappear without user action, and also doesn’t get in the way of what the user may want to see or do.
reply