| ▲ | GitHub no longer uses Toasts(primer.style) |
| 60 points by samsolomon 3 hours ago | 25 comments |
| |
|
| ▲ | gherkinnn 30 minutes ago | parent | next [-] |
| 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 |
|
| ▲ | stuartd 15 minutes ago | parent | prev | next [-] |
| https://archive.ph/2025.12.08-211115/https://primer.style/ac... |
|
| ▲ | websiteapi 9 minutes ago | parent | prev | next [-] |
| what's an example website that doesn't require login that gets UX/UI right in most respects? |
|
| ▲ | clircle 9 minutes ago | parent | prev | next [-] |
| Yeah, probably a good idea to remove it since i use github everyday and have no idea what a toast is . |
|
| ▲ | codingjoe 2 hours ago | parent | prev | next [-] |
| Finally, I hope that trend catches on. God knows how many messages are missed thanks to toasts. |
| |
| ▲ | Groxx 2 hours ago | parent [-] | | >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 an hour ago | parent [-] | | >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 an hour ago | parent | next [-] | | 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. | | |
| ▲ | d3Xt3r 18 minutes ago | parent | next [-] | | 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/ | |
| ▲ | Jtsummers 8 minutes ago | parent | prev | next [-] | | They also often show up in bad locations, requiring you to dismiss them explicitly so you can continue using other UI elements. | |
| ▲ | pxc 15 minutes ago | parent | prev | next [-] | | > 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. | |
| ▲ | herpdyderp 18 minutes ago | parent | prev [-] | | 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. |
| |
| ▲ | madeofpalk 19 minutes ago | parent | prev [-] | | 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. |
|
|
|
|
| ▲ | awinter-py an hour ago | parent | prev | next [-] |
| > 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 |
|
| ▲ | xixixao an hour ago | parent | prev | next [-] |
| 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 an hour ago | parent [-] | | > 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. |
|
|
| ▲ | jollyllama 16 minutes ago | parent | prev | next [-] |
| Modals, toasts. The UX set got very good at coming up with new words for pop-ups. |
|
| ▲ | mohsen1 an hour ago | parent | prev | next [-] |
| Any toast can be an inline message in my experience |
|
| ▲ | quamserena an hour ago | parent | prev | next [-] |
| 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. |
|
| ▲ | hendry an hour ago | parent | prev | next [-] |
| Same as modals? |
| |
| ▲ | herpdyderp 14 minutes ago | parent | next [-] | | 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? | |
| ▲ | bradleyy 40 minutes ago | parent | prev [-] | | 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. |
|
|
| ▲ | ChrisArchitect an hour ago | parent | prev [-] |
| 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 38 minutes ago | parent [-] | | 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 11 minutes ago | parent [-] | | 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. |
|
|
