[HN Gopher] GitHub no longer uses Toasts
___________________________________________________________________
GitHub no longer uses Toasts
Author : samsolomon
Score : 76 points
Date : 2025-12-08 19:58 UTC (3 hours ago)
(HTM) web link (primer.style)
(TXT) w3m dump (primer.style)
| codingjoe wrote:
| Finally, I hope that trend catches on. God knows how many
| messages are missed thanks to toasts.
| Groxx wrote:
| > _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.
| Muromec wrote:
| >yeah. OBVIOUSLY. good fucking riddance.
|
| Are they really? Isn't it pretty normal "role status aria
| something something polite" thingy to announce feedback to
| user?
| JoshTriplett wrote:
| 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.
| herpdyderp wrote:
| 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.
| d3Xt3r wrote:
| 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.
|
| https://www.imab.dk/windows-10-toast-notification-script/
| pxc wrote:
| > 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.
| mnhnthrow34 wrote:
| 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.
| Jtsummers wrote:
| They also often show up in bad locations, requiring you
| to dismiss them explicitly so you can continue using
| other UI elements.
| madeofpalk wrote:
| There's no such thing as accessibility. Accessibility is
| just usability.
|
| Toasts have poor usability because its easy to miss them.
| This makes them bad for everyone, regardless of screen
| reader.
| mohsen1 wrote:
| Any toast can be an inline message in my experience
| layer8 wrote:
| Or a modal, for certain infrequent but important cases.
| xixixao wrote:
| Toast pros:
|
| - 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.
| gherkinnn wrote:
| > 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.
| twelvedogs wrote:
| 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
| anonymous908213 wrote:
| 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.
| ChrisArchitect wrote:
| An alternate take:
|
| _Why GitHub's War On Toasts Is Bad News For Accessibility_
|
| https://medium.com/offmessageorg/why-githubs-war-on-toasts-i...
|
| https://archive.ph/QMMye
| gherkinnn wrote:
| 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.
| samsolomon wrote:
| 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.
| layer8 wrote:
| 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.
| hendry wrote:
| Same as modals?
| bradleyy wrote:
| 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.
| herpdyderp wrote:
| 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?
| quamserena wrote:
| 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.
| awinter-py wrote:
| > 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
| gherkinnn wrote:
| 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:
|
| https://developer.apple.com/design/human-interface-guideline...
|
| https://developer.android.com/design
| jollyllama wrote:
| Modals, toasts. The UX set got very good at coming up with new
| words for pop-ups.
| jfengel wrote:
| 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".
| stuartd wrote:
| https://archive.ph/2025.12.08-211115/https://primer.style/ac...
| websiteapi wrote:
| what's an example website that doesn't require login that gets
| UX/UI right in most respects?
| clircle wrote:
| Yeah, probably a good idea to remove it since i use github
| everyday and have no idea what a toast is .
| bicx wrote:
| I like toasts as a non-obtrusive confirmation of an action, but
| not as a method to present important information.
| btown wrote:
| Among the various potential uses of a toast, IMO:
|
| - 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.
| franky47 wrote:
| Refined GitHub [1] still does (for things like PR approvals &
| automations), and it feels odd indeed. Still worth adding on top
| of the stock UI.
|
| [1] https://github.com/refined-github/refined-github
| ardit33 wrote:
| 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.
___________________________________________________________________
(page generated 2025-12-08 23:00 UTC)