GitHub no longer uses Toasts
Posted by samsolomon 1 day ago
Comments
Comment by projektfu 1 day ago
Comment by kurisufag 1 day ago
Comment by projektfu 19 hours ago
Comment by locknitpicker 1 day ago
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?
Comment by kurisufag 1 day ago
>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.
Comment by isleyaardvark 21 hours ago
Comment by ErroneousBosh 21 hours ago
Is it possible that your browser or internet connection are slow?
Comment by projektfu 19 hours ago
Comment by ErroneousBosh 18 hours ago
Comment by projektfu 14 hours ago
Comment by gherkinnn 1 day ago
For comparison, Apple and Android have their own documentation:
https://developer.apple.com/design/human-interface-guideline...
Comment by codingjoe 1 day ago
Comment by Groxx 1 day ago
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.
Comment by Muromec 1 day ago
Are they really? Isn't it pretty normal "role status aria something something polite" thingy to announce feedback to user?
Comment by JoshTriplett 1 day ago
A message that you have to explicitly dismiss, and that's stored in a "message history" somewhere, is much more accessible and usable.
Comment by pxc 1 day ago
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.
Comment by mnhnthrow34 1 day ago
Comment by d3Xt3r 1 day ago
Comment by Groxx 23 hours ago
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.
Comment by d3Xt3r 22 hours ago
You can see the API reference here: https://learn.microsoft.com/en-us/uwp/api/windows.ui.notific...
Comment by Jtsummers 1 day ago
Comment by licorices 1 day ago
Comment by Griffinsauce 12 hours ago
Comment by Muromec 1 day ago
Comment by herpdyderp 1 day ago
Comment by madeofpalk 1 day ago
Toasts have poor usability because its easy to miss them. This makes them bad for everyone, regardless of screen reader.
Comment by rileymat2 1 day ago
Comment by strken 22 hours ago
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.
Comment by bicx 1 day ago
Comment by btown 1 day ago
- 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.
Comment by 0manrho 1 day ago
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.
Comment by setr 1 day ago
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.
Comment by awinter-py 1 day ago
^ 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
Comment by outlore 1 day ago
Sonner does it quite well (https://sonner.emilkowal.ski/)
Comment by licorices 1 day ago
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.
Comment by xixixao 1 day ago
- 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.
Comment by gherkinnn 1 day ago
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.
Comment by twelvedogs 1 day ago
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
Comment by anonymous908213 1 day ago
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.
Comment by xixixao 1 day ago
There are also a lot of professional guis (think medical software), that use no toasts.
Comment by mohsen1 1 day ago
Comment by layer8 1 day ago
Comment by franky47 1 day ago
Comment by websiteapi 1 day ago
Comment by fs_software 1 day ago
Comment by clircle 1 day ago
Comment by JSR_FDED 1 day ago
Comment by jollyllama 1 day ago
Comment by jfengel 1 day ago
"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".
Comment by hendry 1 day ago
Comment by bradleyy 1 day ago
Comment by licorices 1 day ago
Comment by bradleyy 19 hours ago
Again, this is sometimes appropriate, but it's desperately wrong in so many places it gets used.
Comment by herpdyderp 1 day ago
Comment by quamserena 1 day ago
Comment by stuartd 1 day ago
Comment by butz 19 hours ago
Comment by ardit33 1 day ago
Comment by heldrida 1 day ago
Comment by SAI_Peregrinus 1 day ago
Comment by ChrisArchitect 1 day ago
Why GitHub’s War On Toasts Is Bad News For Accessibility
https://medium.com/offmessageorg/why-githubs-war-on-toasts-i...
Comment by gherkinnn 1 day ago
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.
Comment by samsolomon 1 day ago
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.
Comment by gherkinnn 1 day ago
- 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.
Comment by layer8 1 day ago
Comment by Groxx 1 day ago
... that's a somewhat odd stance to take.