> But by archiving the email, the email disappears from the list, which already implies the action was successful.

> In this example, the button already includes a confirmation so the toast is entirely unnecessary.

I vehemently disagree with the idea that just because you're already communicating something one way it's bad UX to include another way of communicating the same thing at the same time. Redundancy in communication is a feature, not a bug, and it's present in all human languages. It ensures that even in less than ideal conditions the message still gets through.

In the case of toasts, having a single, standardized way of communicating the status of all actions (and if possible providing the undo) allows a user to quickly pick up on the pattern. Extra indicators closer to the action can be valuable too, but it's when they're paired with the toast that their meaning becomes entirely clear. To remove the toast in favor of a bunch of specific indicators is to force your user to learn several different ways of saying "it's done now" entirely from context (many of which will be small and subtle as in the examples given). This might work fine for you and me but isn't great for, say, the elderly or the vision impaired or children.

Unless they're actually getting in the way, toasts aren't bad UX, they're redundant UX, and a UX designer shouldn't be striving to optimize away redundancy.

Taking the YouTube example, the checkboxes are 100% optimistic while the toast notification indicates that the request to the backend that was fired off asynchronously was successful. With the archive message example, it is the same thing. The message is removed from the list optimistically and the toast message is representing that the message was actually archived.

I would much rather only get the toast if there is a failure to commit the change. Generally, them flashing up is a distraction from what I’m trying to accomplish. And being far on the screen from where I’m taking an action makes them even more of a distraction.

But wouldn't this situation be even worse with a failure-only toast? A request timeout could happen 30 seconds after the fact. You're likely in a very different UI state at that point, and unless the error message is very specific, you'll have no idea what even failed if you are quickly performing lots of actions.

- Put cause and effect close to eachother - Don't block my view based on mouse position. I hate video players that ofverlay the pause button when the mouse is over the video, or images that get obscured by some overlay when hovered. My zoom follows the mouse, so I can't move what I'm looking at and where my mouse is pointing independently.

This shit is super annoying for everyone. Even people who do not use magnifiers. Who decided that this was a thing to do and why? I would like this pattern to meet sudden death.

I get the annoyance, but especially on mobile, it conversely helps if you want to advance the video by as few frames as possible to catch a freeze-frame gag or something like that. If the UI immediately disappeared upon resume, you'd have to triple tap to immediately pause the video again. (On desktop you can just mash the keyboard or even use a dedicated "advance one frame" key, but on mobile that's not available.)

Agreed. This is exceptionally annoying! Who thought this was a good idea? Why don't people copy proven video interface behavior from Google. Why go out of your way to annoy your users?

I can see the argument that there are certain places where people use toasts that are unnecessary and provide information that the user doesn't need. But that's not the same thing as toasts being bad UX in the general case.

Not if they go away, and take their “[View item]” button with them, before you've had time to read the notification, decide if you want to click the button, and actually get your cursor there to click it.

Which they usually do. So nyaaah, dubious benefit.

Maybe your browser should could have an icon for same instead making it more standardized across different sites.

An action/activity log is just a reverse-chonological log of things that happened. You could make one by recording every would-be toast and putting it on that list, complete with a timestamp, and any of the context-relevant action buttons (like "undo", or "view item", etc.). The list should be a fixed recording[0], without any way to dismiss some or all of the entries. Add some attention-grabbing indicator whenever something is added there, and you get all the benefits of toasts with none of the drawbacks: the log lets you report completion of optimistically-executed actions, provide place for context-relevant buttons, and also is accessible, can be browsed at uses' own time, improves discoverability and learning, and can be upgraded to also enable undo feature.

--

[0] - Well, appended from top, and possibly unwinded by undo. Users understand that. Can't be append-only, because mixing that with undo gives you the undo system from Emacs - very powerful but also nearly incomprehensible to most people.

Ask for everything get nothing. I imagine most people click no

Now my presence is to use this grade A type of implementation because I like very solid software and I’ve done it so many times now that I can bang it out in a coding interview. Or explain it to a team so they can implement it.

But your average app is like a grade D. Even Instagram or Snapchat where I’m never too sure if my stories are going to be in order if my connection fails or even though it lets me cancel an upload, if I do it slightly too late the app fails to cancel because it can’t keep track of its own state through a state transition.

So for 99% of apps, I want them to put a redundant toast. I do not believe they can build solid software with proper state management. At least the redundant toast lets me know it did go through. A lack of toast doesn’t mean it went through because some people barely can implement error handling.

You don't want to stack them, or if you do you need some sort of inbox for them. You don't want to be spammed by them, you don't want them used as a stand-in for representing object state.

For a checkbox, I'd rather the info be communicated "inline" maybe by color/shape/shading. A toast could be used like an info popup, perhaps i.e. "why did my checkbox get reverted".

Or it could be for a high priority event, that just doesn't fit (well) in the current screen. But, again, care should be taken.

If you communicate with your user, don't spam them - provide them with prompts and visually appealing methods to obtain their data. Toasts can be a part of that but shouldn't be the first tool reached for (ideally). I think the reason they are so dangerous is because they are outside the main UI flow, its technically and visually "easy" to use them.

E.g. you can take action A on your laptop, followed by action B on your phone. Undoing action A may not be easily possible if it was followed by action B.

To make that work properly you need to activel sync states between all the users devices using e.g. websocket or what-have-you. Handling edge cases becomes quite the nightmare, e.g. phone has poor connectivity.

Only the big guys would have budget to do these sort of things (And make them work well).

In other words, if you delete an email and it goes to the trash folder: good use of toast + undo

If you empty the trash, and there is nowhere the user can go to unempty it: bad use of toast + undo

Its also useful as a sleight of hand eg when cancelling an action you havent yet taken (which actually is generally what a toast + undo actually is). The best example of this being toast + undo for an email send

The problem with notification only of failure is that one is left uncertain about success, though I would agree that striking a balance between distraction and uncertainty is difficult.

For the checkboxes, I'd say GitHub nailed it: for settings that are applied instantly (e. g. https://github.com/settings/appearance), they show a spinner and then a single checkmark right across the section title. (It used to be next to the input element – both ways are fine, I think)

I would much rather the sequence of commands issued through the ui be a declarative state change queued until committed without bugging me about an error I can’t directly fix. Toast that backend chaos monkey, not me.

It's bad UX. Put your damned messages where my attention has already been directed to BY YOUR UI.

It's pointless pretending there's one perfect guiding philosophy and all others are obviously wrong.

User notifications on MacOS are definitely standardized, but originally they were Growl notifications until Apple made it a first-party API and iterated on it.

And you are right in that the Growl-style notifications in Mac OS are standard now... but those are different from the ones in question here because they are not related to a control that the user was just manipulating. They could come from anywhere at any time, and thus they must be presented in a location independent of whatever the user is doing.

The Growl-style notifications work well because they're near the top of the screen, too. Users are used to status and information in menu bars and so forth, in accordance with the general top-down convention of presenting information.

Thinking it through, I did actually implement a "toast"-style alert for asynchronous issues in one application. It was at the top of the screen, though. I originally put it in there strictly for debugging, but I think I might have left it in the release. So I'm not entirely opposed to the idea, but mainly its placement in the examples discussed here.

I believe toasts should be confined to this scenario I'm describing, and indeed feedback directly coupled to user focus/input should be located near to that as you say.

Ok, so where does the toast go if you've already scrolled or otherwise navigated to a different area of the UI? These optimistic updated could take multiple seconds to succeed, and maybe as much as 30 seconds to fail.

Not to mention that, if the operation fails, isn't it likely that the user will want to re-try? And that'll require access to the original control in all likelihood.

If the user scrolls away and the information is important, use a modal alert.

These toast notifications just are a bad solution. I often miss them, because I'm, you know, doing work, not scanning my monitors for notifications I mostly don't care about. (Redundancy is not harmless. Redundancy also trains me that your messaging is mostly noise.)

We can have an indicator, then some icon or even a green bar in the "save this" modal, just fine. Or we can make the "archive" icon color different, or add an error, an undo-button, or other message next to it if we really need to convey this information. This could be a tooltip, something in the icon-bar, or anything really: as long as it right at the place where I made the change and expected the change to show up.

Wanted to mention in case you're not aware and maybe there's some tool somewhere (or some way to configure a screen reader?) so that you can keep your simple zoom workflow but still benefit from the ARIA alert pattern.

[0] https://www.w3.org/WAI/ARIA/apg/patterns/alert/

For a small regional golf court chain who want to build an online tool for reserving tee times? They most definitely won't have the budget to do things entirely properly.

There was some discussion in the article and elsewhere in the thread about how a toast with an undo button could be a very useful interface pattern. It wouldn't work for me, so I would hope that UX designers that want to use toasts would also design in other means to find and execute an undo action.

For you, my comments reinforce that toasts are "good UX" when they contain redundant information. I'm warming to the idea. In parallel, for me, this discussion is reinforcing my intuition that "actions and feedback as close as possible to the area of interaction" should be considered the primary vector.

The issue with the not seeing toast notifications is that in some apps it’s the only true notification that the request went through to the server so missing them when they failed for whatever reason is rather annoying

In other words, it's a crutch that is often taken when there isn't enough budget/resources to make a proper UI (Or enough care/love/interest/skill).

I have definitely myself gone down the quick path of implementing only server side validation + toast service for projects where the customer just does not have the budget to do things entirely properly.

A toast makes sense as a worst-case, last-gasp, no-context attempt to communicate with a user. In this example, if the user unchecked a playlist and dismissed the list of playlists while the save was happening, and then the save failed, a toast makes sense because the context of the action is gone. Might as well put the information at a random spot on the screen.

Even then, a toast probably isn't the best you can do, if you really want the user to understand the error. In a the-user-is-the-product adware application like YouTube, you probably don't care if the user misses errors like these (and might even prefer that they do), but in a business application you wouldn't want to gamble on the user missing the toast or confusing it with a different error. It might be more helpful for a normal user if you re-open the element and show them the error in context. Open up the list of playlists and animate something to draw their attention to the fact that their change didn't save. I'm probably getting pie in the sky here, because that sounds really difficult to do in a systematic way, but in an ideal world, you'd always see errors in context.

Taking the archive example: yes, the disappearing message successfully indicates that something happened. But it doesn't tell you if the message was deleted or archived, and misclicks are common. The toast unambiguously communicates what happened in addition to saying that something happened.

Additionally, I stand by my argument that consistency is valuable. By all means have in-context feedback, but also pick a standard way that you always use to communicate completion of all actions. It makes it a lot easier to understand and eventually make use of the in-context feedback which may not be as intuitive as you think it is.

But adding a toast isn't free. It's a distraction, and arguably a pretty intense one for ND folks -- especially when it becomes a standardized message center with multiple items queued up.

In many cases the most useful toasts would also be better if they weren't toasts. For me, the most useful toast I interact with also demonstrates why toasts are bad UX: creating a new ticket in Jira. Since that can't happen instantly, it needs a delayed message to let you know when the ticket is created and you actually have a URL to open. A toast is useful in this case, but it's also far from optimal, because for some reason it's going to disappear in a few seconds, and it also won't tell me how many seconds I have left to read it.

Why would distraction be the primary mechanism? We figured out decades ago how to put a button in the header that opens a messages feed which the user can read and dismiss at will. While it's possible to implement such a feed badly so that it's annoying, it's difficult to implement toasts in a way that aren't annoying. Maybe even impossible.

Diagnosed with ADHD, so I'm guessing an ND folk here: modern applications in general, and webshit in particular, give me huge anxiety because of all the eventual consistency and optimistic actions bullshit[0], coupled with flakiness and bloat of entire modern software stacks[1]. Maybe "toasts" aren't the bee's knees, but they work as lagging indicator that something happened that I otherwise wouldn't notice, and in some apps even lets me undo the unwanted operation. That does a lot to relieve my anxiety and help me use software with less frustration.

--

[0] - That itself is a big antipattern. Software lying to user about its state is a form of gaslighting; it makes interaction more error-prone, and prevents users from building correct mental models of the application and its interactions with other systems.

[1] - My Android flagship lags often enough on taps and drags that every other day my input gets misinterpreted and does something unwanted. Similarly, I type faster than most software - webshit in particular - can react, so e.g. a small jitter can turn "ctrl+t n e w s " into "ctrl" (held, released) and then "n e w s ", which does $deity knows what in the current tab.

This. Also true for both my wife and me. One of the worst offenders here are contact forms - it's increasingly rare you get any copy or confirmation via e-mail that your message was actually recorded, so once you submit the form and see a success page, you really can't be sure if your message was delivered, or even if it left your browser in the first place. Takes one little JavaScript fuckup for the message to be lost, and your only indication may be an error message in development console.

Related, at one of my previous employer's, there were some documents I was interested in that had restricted access; when trying to open them, I'd get an access request form asking me to provide a reason. I filled it several times over couple of months, but never got any reply. Then one day, I mentioned it randomly to my boss, to which he told me that this form just goes straight to /dev/null...

All things that a message log does better than toasts!

I'm also ADHD and, like OP, I appreciate having the stream of toasts that lets me know what the software did. It's saved my butt a bunch of times when I accidentally do something I didn't mean to (deleting instead of archiving, for example). A message log would just get ignored, but toasts help a ton because they're visible.

In general, I think the best use of toasts are to present options for further action (if needed).

Take the example of deleting an email and getting a toast that lets you undo. Your action has already been completed and you can see it. But you have more context that can be acted on. In this case it's not redundant, even though it relays the action you just take.

In this scenario, it's ideal to move this away from the viewport the user was in. In most cases, they don't need it. But if they do, it's onscreen.

Simple confirmations that do nothing else are redundant. But toasts don't have to be used that way.

Redundancy in UX confuses them. The closer you can get to the whole UI being a single sentence and two buttons the better.

> The closer you can get to the whole UI being a single sentence and two buttons the better.

Sure, but this is kind of my point—clever UX tricks to communicate things without words don't work for them. A toast is valuable for the tech-illiterate precisely because it uses English text to communicate its point, and having it exist in the same spot for every action makes it easier for them to pick up.

It's not the be-all end-all of UX design for the elderly, but it's a heck of a lot better than the alternatives proposed in TFA.

The toast makes it clear.

Things disappearing with insufficient explicit feedback for what actually happened to the things is one of the most common issues I've encountered with older computer users. I think it's the most common issue. Toasts add persistency and visibility for users who barely or don't understand the UIs they're interacting with, which makes it easier to understand what happened.

If Outlook gave feedback to every user action in a toast, then provided a universal history of every toast, you would probably resolve a significant amount of issues caused by user actions leading to unintended changes (and being unable to recognize that the action lead to a particular change, or even how the current state differs from the previous one).

This is what message feeds are for. Toasts are just a worse implementation of message/notification feeds.

Toasts appear somewhere in the corner and then disappear very quickly. Not sure how useful that feedback is. It's distracting at best.

It's time to stop blaming "age" when the more likely explanation is EXPERIENCE. Many people learned to use computers in an age of well-understood GUIs that hewed to standards that evolved for very good reasons. For example, buttons that were depicted (in a clean, not cheesy "skeuomorphic") manner. You can tell at a glance if a well-depicted button is on, off, or disabled.

Then enter the idiotic "flat" design fad, where the entire screen was an Advent calendar of no controls at all... or is it ALL controls? Click on every piece of text and every rectangle to look for the hidden goodies.

Those conversant in (and tolerant of) more-recent UI have simply become accustomed to shitty UI. They've either forgotten how bad it is, or grew up not having experienced good design. Another great example that has disappeared in many areas is GREYING STUFF OUT. If something is not currently usable because it's not applicable, you don't just make it disappear. You grey it out, so users can learn

1. That the function exists 2. Where the function resides 3. What conditions must be satisfied to make it work

This discussion tells me we have not yet reached perfection in UI! Toasts are good for me, but definitely not good for the users you and others have described.

My hope is that small AIs inside UX can help here. Can you tell your UI framework something like, "Give them a choice between X and Y." and then "Clearly indicate they have chosen Y." (with a fallback of "Tell them something went wrong, and they won't be able to make a choice right now after all.")

Or is it simpler than that, and we don't micro-manage the AI-powered UI engine? "Get answers to these questions, and submit them to this API." — and UI engine does all the rest? I'm not sure.

Anyway, an improved UI would adapt to the user — think of the way a person providing a service adapts to the customer, intelligently and empathetically. For example a teacher watching for signs of understanding in a student, adjusting explanations. A car salesperson being quick and businesslike with one customer and listening patiently to another.

Yeah this in particular bothers me. Someone that knows UI and UX should also know you can absolutely remove something on the front-end without a corresponding action on the back-end. If I click archive and the email disappears, that doesn't mean the back-end call succeeded or has even been made. How many times do you click move/delete/whatever in an app, the thing moves or disappears then a second later pops right back in? These things happen and the subsequent alert that it was actually successful is a good thing in my opinion.

I completely agree with you.

The article kind of confirmed to me that toasts are good UX.

And yet the discussion here seems to veer off from actual verification of whether toasts actually work, and all the discussion seems to be purely speculation. Granted, there is general argumentation too that's valid to some degree, and it's good to present that, and at the end of the day the only actual data that can guide this decision for a given user interface comes from user testing that is highly context sensitive.

Why? Because there exists no general answer to this question at all. It depends deeply on who your users are, and before the industry understands this basic fact that we as a species are mostly incapable of predicting what different persons from a different user group point of view will be, usability testing will be critically needed, and until we actually start doing it, we will keep creating user interfaces that marginalize everybody but ourselves.

They are redundant as in superfluous not as in a back up.

But the proposed solution is clearly worse, unless the loading circle turns into a tick to show completion

Their examples are all arguments of where local information should have been displayed. I agree with them in general. I just think that a toast should also be displayed in each of the situations they identify.

What seems to have happened is that they correctly identified a problem with lack of local information and blamed it on the presence of non-local information, which is fallacious. You can have both, and I believe that a UI with both is generally more usable.

I like the traditional desktop approach where error messages are shown modally, so can’t be missed, and success messages are shown as normal unobtrusive text in the permanently displayed status bar, without timeout. When not getting an error modal, the user can simply assume that the action succeeded, but can look at the status bar for confirmation (plus potentially some auxiliary information), without any time pressure.

Some applications also offer a popup showing the history of status bar messages. In that approach, the status bar is like the last line of CLI terminal output, and you can call up previous output.

I often will click into my notifications to see what I missed (I knew it looked important, but I didn’t have enough time to read it all). When I get there I will click on what looks like a truncated message, with the expectation that it will take me to the full context. Instead, the notification disappears, so I lose it, and it opens an app without deep linking to the issue. I’m then left hunting around to try and find a problem, which may or may not be surfaced, in the app’s standard UI.

This has happened more times than I’d care to count and it always leave me upset with whoever designed these systems.

I ran into this with my son just today, he is working on his reading speed and we were using a new app together. I kept showing toasts and he was struggling to keep up with them and found them to be distracting. I ended up reading them aloud so he could keep up. A more persistent message would have let him succeed without extra support.

Agreed; a better solution would be to assume success and show these messages only if an error occured.

In windows balloon notifications have been replaced by toast notifications that block ux you're working on as well.

there is also a toast notifications panel but it's frankly ugly and awful compared to iOS and androids notifications visually.

I don't have a ton of experience with Linux or MacOS

Go to https://www.youtube.com/feed/history and click "Comments" on the right side. Then delete one comment.

You will get one toast indicating that it will be deleted, and one a second or two later indicating that it got deleted.

If you delete multiple comments quickly one after another, you'll first get a bunch of toasts indicating that the comment will be deleted, and then, with that second or two delay, each confirmation, but they do get deleted sequentially, so you have to wait for all the confirmation toasts. Which for a deletion of 10 comments will take more than 10 seconds, even if you clicked them all in two or 3 seconds.

Same with the live comments at

https://myactivity.google.com/page?page=youtube_live_chat&co...

I disagree with this part, at least in general. Having an Undo is very good if you have accidentally clicked somewhere and don't know precisely where, and you don't know the application well enough to easily undo based on the message alone.

That's false. The checkbox itself is not a viable undo button under any circumstances in this specific example (i.e., you accidentally clicked but have no idea where, and let's assume you have no idea of that particular checkbox's state prior to the accident). Any adjacent checkbox would have extremely similar plausibility for a user wondering how to undo.

That said, toast is not great either, because it may disappear before the user fully recovers from their accident (say, a spilled drink). Maybe the undo button (and any async success/error labeling for the original event) ought to be adjacent to the checkbox and persist until the next action taken.

That the same for every single checkbox in every single form on the Web.

Even in the unlikely case in which you clicked on the lists button that opens the popin and then accidently clicked on a checkbox without seeing which one and without seeing the checkbox state change, you still have the list of lists on the screen and you can still choose if you do want this video in this list(s) or not.

In my experience, the majority of forms on the web don't commit until you decide to submit, so if you have an accident before then, you can recover (well, buy a sense of certainty at the cost of redoing some work) by reloading the form. In contrast to that majority, here we're talking specifically about forms where each component auto-submits immediately. I think that if a component auto-submits, then anything related to that submission (success/failure status, undo, etc.) should be presented within that very component.

I don't think a toast or any confirmation feedback mechanism is supposed to replace a log or undo list.

This can all be fixed. E.g. disable the checkbox while it’s processing; or show a small loading indicator; make it impossible to click the checkbox repeatedly. Etc.

A frontend update that doesn’t wait for the server is nice, but only when server state is irrelevant. If the user wants to know about the server state, then the UI should always indicate that.

To illustrate the problem with "perfect storm" example, suppose a your back is turned and a ball rolls of the shelf and hits the keyboard. Did anything change? What changed? How do you fix it?

Did you just archive or delete a couple of unread emails? You may never know!

I’ll start by saying that I particularly appreciate this feature. There are countless times where I archived an email, only for the toast to tell me that I clicked the report spam button. I’d have been completely unaware otherwise.

The other issue underlying toasts that the OP is missing: Web operations are async. There is no telling whether your operation succeeded, failed or did even register with the server it’s communicating with. A toast gives you an async update about the state of the server.

I do agree that some toasts are obnoxious and for example can’t be dismissed while they are hiding an important UI content.

1) done accidentally

2) don't lend themselves to confirmation boxes because they are often also done repeatedly

So if you accidentally press something and suddenly the email is gone from your inbox, you want a toast with an undo button. Or if you're just idling and you suddenly see a toast because you were leaning on a button, you'll be glad it's there too. Preferably with a description of what action was performed, and an undo button.

In Gimp when you press Tab, it hides the whole UI with no way to go back if you don't know the shortcut. This is desirable for artists who want a focused view on their image. I can't tell you how much I would've liked a Toast with an "undo" button at that moment when I pressed it accidentally and had to google "gimp how to fix interface disappeared", and if I was computer illiterate I don't even know how I would have reacted.

Any feedback from a user action should be done within the context of the user action. If the action is async, it should be clear and the feedback should instantaneously indicate that the action is queued for processing. In that case, the feedback should give 2 options: cancel and access the queue (or better give a vision of its progress ).

If I removed a task from a board, I can't show - on the task - how to undo that action. There's a keyboard shortcut to undo it, but how would the user know, visually?

I'm not going to replace the task with a note because notes don't belong in task lists - only tasks do. I'm not going to come up with some derivative task that only displays a message because then I'm injecting intention that has no function for the task component. I'm not going to just not tell the user because while it is obvious that the task was removed, it's not obvious how to undo what could be an alarming action from a single click (and I'm certainly not going to nag people before deleting a task with a single click; it's a core functionality of task lists. It needs to be able to be done instantly, and undone instantly).

So on and so forth. I'm sure people have tons of one-off, little, anecdotal examples like that. Toasts were invented for a reason. Just because people got cutesy with them doesn't mean they aren't specifically useful for specific scenarios, regardless of how contrived.

My case is a reference to a real-life, literal sitaution that I was involved with. The "opinions" expressed as why I would or would not do certain things had PLENTY of A/B testing and research done on them. Not only internally, within my company, but externally out on the open internet. Nothing I said conflicts with extremely common understandings of these UX patterns. And, far more importantly, our internal testing and research backed all of our findings up.

So when someone says "here's a better way to do your UX", they are specifically saying that they have some insight that beats out all of the research and testing I have seen on it. In which case, I am MORE THAN HAPPY to see any of it. I love to learn that certain patterns don't work the way I thought they did! Sometimes it just means they've gone out of style and we need to update with a trend. I'm very interested in making UX the most reasonable I can for the most users. So if I'm doing something wrong, I'd love to see data to support that!

What is less interesting to me is someone saying that their opinion is better without any evidence of that claim. But, hey, I'm open to new ideas: please explain to me what concrete actions I should take based on the reply I got? I should go research it because ne said it, even though it's a very common thing that is said in these discussions and I've never seen it supported? Do you chase down every single lead without asking for the minimum amount of effort to be put in by the propositioner? If this person was earnest about helping me achieve a better UX, rather than just stating their opinion out loud, why is it difficult to follow up with practical data?

Where should that feedback be given for modal operations, acknowledging that 99% of the time when the user initiates the action they want to background the operation and move on to doing other things?

Says you, but why? There are many workflows where this would be an unnecessary slow point in the user's work.

It's all about balance. If 99.9% of the time a non-instananeous operation will succeed, and the user has faith that it will succeed, leaving the modal up is a terrible UX. But quietly notifying them on success might not be.

Because otherwise I wouldn't be able to get it back. But if I have some kind of temporary hiding feature, I can easily use that as soon as I notice that the operation hasn't immediately completed. (And again, the common case should be that it completes immediately.)

And if something isn't supposed to be instantaneous, I hold that the interface shouldn't be modal anyway.

A toast notification doesn't preclude being able to recover state. Email applications still have an Outbox and Sent folder, e.g. A UI that allows you to place orders can still have a Pending Orders list.

> (And again, the common case should be that it completes immediately.)

In the real world, not all operations initiated by the user can complete immediately.

> And if something isn't supposed to be instantaneous, I hold that the interface shouldn't be modal anyway.

Why not? The two things are orthagonal. Collecting information about the user's intent and acting on that intent can often have differing workflow implications and timings.

Blanket rules are almost always useless in UX. Say you have an interface made to place an order. You collect a bunch of details about the order modally. The user confirms and submits the order. But it'll take a minute or two for a vendor to confirm it. What should happen next is COMPLETELY dependent on the context of the application. If this site is where the user is ordering dinner, it makes complete sense to leave the user in a modal state until confirmation occurs, because it's unlikely they're going to be placing another order for dinner immediately after, unless the first order fails. If this site is made for a procurement professional placing 20-30 orders one after another, it makes complete sense to background the confirmation and report status non-modally.

There is no context for this, and often an action is required. And even if not, it is certainly useful to confirm with the user that their action was detected.

No. Growl came out in 2004, Windows XP had notifications in 2001. If you consider Clippy's messages notifications, we can go back to at least Microsoft Bob (1995)

It's the most important word on their page, and it's obvious that some people, even technically-minded folks, don't understand the jargon.

But could be they got extra engagement from readers who are interested in baking and breakfast recipes?

> We currently demand that users internalize several metaphors when interacting with Homebrew. These include:

> Formula (how to build a bit of software)

> Bottle (pre-built software)

> Cask (pre-built software on macOS)

> Tap (a collection of software)

> Keg (where software installs itself)

> Cellar (where all my software install themselves)

> As well as an additional number of less-common metaphors that contributors and maintainers need to know, like Rack, Tab, and Formulary.

https://github.com/Homebrew/brew/issues/10798

Exceptions might be made in cases of misinformation or abuse.

Update: On consideration, I think my disconnect was because the plural of the notification method is "toasts", but the plural of the recooked bread slices is "toast". The plural of benedictions given prior to a drink is "toasts". So I mentally connected up with that.

No. The author assumes that it implies that. For the user though, it can imply many things:

- Something loading in the area next to the text, indicating something's coming up to that region soon, and when it disappears, it might be interpreted as a loading error.

- UI is doing something, so not responsive anymore.

- UI is doing something, and if the user does something, they might disrupt that process.

- Internet connection is slow.

In general, a loading indicator that starts running when a checkbox is selected is bad UX.

Better UX alterntives would be:

- Directly animate the checkbox itself when clicked (like pulsating it, or the checkbox square starting to rotate in a pattern, etc), and show a stationary checkbox when the operation is complete.

- Don't show user anything at all, let the checkbox show that it's been checked right away. If the user wants to leave before it's processed, just warn them about unsaved changes. (FastMail does that, for example)

- Don't use checkboxes for asynchronous UI actions that can take time. Use buttons instead, so the user understands the UX language. Then, you can use loading animations as much as you want.

In the YouTube example, I don't think the last two options you mentioned would work very well.

A confirmation toast with a page-redirection is a great way to add additional indication to the user that their submission was successful.

A warning or error toast in addition to standard form validation indicators gives a great secondary indication to the user that they need to change something.

And if implemented in a catch-all for nonspecified errors, it'll allow the user to preserve the state of their page vs rerouting to an error page.

If used as one tool in the toolbox vs the only tool in the toolbox, it's a great option.

Author's alternative suggestion isn't that that great either - the problem with having a loading indicator next to an actionable item in a list is that if you get an error, it would be difficult to communicate what went wrong to the user (if you wanted to do that).

If the author considered why services like Google and almost every UI library, from Bootstrap to MUI, has some sort of toast/alert message, then I think the argument of toasts as bad UX could be better articulated.

Seems like author's take is more personal opinion than analytical conclusion.

Personally, I like the UX of toast + alerts.

I understand how much this saves space, but it is absolutely ridiculous! How does an UX expert expects someone to guess that? Are current UI's supposed to be used by people who behave like children poking everywhere to discover things?

Discord mobile app used to have it for both left and right sidebars, and then a while ago someone had a brilliant idea that the "slide to reply" gesture was more important than navigating the app, and now you have to click a tiny ambiguous button to see the right sidebar.

As for the "hidden panel," I have always assumed that this is a bug, but someone may have thought it was a good idea:

I use the Apple Connect App (for managing apps on the App Store) frequently.

If I use it on my iPad Mini, in portrait mode (how I usually use it), and select one of my apps, the back button often disappears, which means that I can't select another account (I have several), or another app within the current account.

Until I physically turn the iPad sideways.

Then, a Navigator appears on the left, and I can select other apps, or change accounts.

Frankly, I'm really quite disappointed in the whole UX for the Apple App Store backend (I'm not so thrilled with the frontend, either, but I use the backend all the time). It's a bit jarring, when you think about how much care they put into the rest of the user experience on the platform.

Games can be the epitome of good UI feedback.

so yeah, I get what you're saying but it may not be the best example

Toasts themselves can be done well, but like every UI and UX element, they need to have some thought.

I know Google have some good UI (sometimes UX on Android) every now and then but they are so fractured as a company, with so much product and feature churn, that their UX is all over the place.

Every single Google app reinvents how things are done or communicated. Even within an app, it’ll do things differently because different teams implemented different features in the app since sections of an app might be shared with other apps.

Even Samsung offer a more cohesive experience. The most Google try and do is introduce new design guidelines every few years and then promptly have teams break them. Material design? Material You? Both barely touched UX but even with their own incredibly straight forward design rules, Google couldn’t adhere to them.

Yeah, its wild because they were the ones who introduced the pattern to the general audience. And it was so successful that others started integrating it in non-material contexts. Toast and toast + action are here to stay, and for good reason, but I think google has individuals willy-nilly making design decisions and not quite being fully aware of how these elements should be used.

World of Warcraft has these, they're used for lots of things. Notably achievements and things like that. There's also add on that look for rare monsters and pop up when it detects one while you're flying about in the land, loot drop announcements

However, we just went through a special event called "Remix" which basically offered degenerate gameplay. Absurdly powerful characters, loot raining from the sky. And in this event, the common reward was a chest filled with gear and other things. These chests came from everywhere.

When you opened a chest, if it had piece of gear, you'd get a little toast.

Now, when you're boucing about collecting boar livers and rousting out hoodlums from their huts, it was quite easy to collect dozens of these things.

And, being WoW players, not known for their patience, you simply collect them all and open them all at once. Open your bags, and right click away. From this, your UI simply explodes with toasts. And they're all queued up, you can only see so many at a time, like, perhaps, 5. And they slowly fade, making room for others.

They dominate roughly 30% of the screen real estate (when presented in volume), smack in the center. And you can either wait it out (which takes a long time), or madly right click to dismiss them all. Me, I would simply go to the inn, open them all up, and log out (which is instant in an inn), and log back in. That would flush the queue of toasts.

Similarly, if you log into a zone, particularly a quiet zone, it's not uncommon for the screen to explode with alerts telling you of all the rare monsters that are simply sitting there because the zone is very quiet for players.

Finally, there a grouping queue you can join for group content, and you can queue for more than one event at a time. So, it's not uncommon to finish one event, kill the boss, the screen explodes with your loot, others loots, maybe a boss achievement, followed by a booming horn with a dialog telling you your new event is ready for you. The entire UI is just a cacophony of alerts.

Toast are mostly fine in my experience, but they do not work when applied in volume.

The problem here is not that there are too many toasts, it is that they are annoying. Having a stylish way of dismissing them all could turn that annoyance into something awesome.

> They dominate roughly 30% of the screen real estate (when presented in volume), smack in the center.

Pretty sure this is customizable. My loot toasts are relatively discrete, I can put them wherever.

> Similarly, if you log into a zone, particularly a quiet zone, it's not uncommon for the screen to explode with alerts telling you of all the rare monsters that are simply sitting there because the zone is very quiet for players.

This sounds to me like you're using the addon SilverDragon which is deliberately obnoxious about alerting you to rare monsters, but with it you can control every aspect of the alert, when/where they occur, or disable them entirely.

- if your app has a number of messages (eg: “image downloaded” or “message sent” or whatever) then there is a consistency in using toasts as they all appear in the same predictable manner

- often “appear away from focus” is one of the intended goals of a toast; it’s a message that is present, but more in the periphery (the user can ignore in most cases, and it doesn’t obscure main content)

But there is nothing wrong with a toast in a pro app. The pro user will get used to where feedback comes from on the screen and find it is second nature to notice the toast.

In practice, there are very few UX principles that generalize across every interface.

This is 10x more subtle than any toast.

Do you wish that were different? Or does that work for you?

As seen in the article, do we need a notification following a click to every checkbox? In most cases, the user should assume that the action is completed the moment it's taken. If not, you can add an inline loader and show a regular, maybe modal error if it happens.

"Save" actions, with the exceptions of large data, does not need further UI. Particularly the circle should be seen as a marker of the current state, not as a way to tell whether your action has completed successfully, so you shouldn't view it as a "10x more subtle notification"

The end result is usually that I've been distracted for no reason.

In a casual app, none of this matters as much.

I spend all day in “pro apps”. I am also visually impaired. The inappropriateness of toasts has nothing to do with my familiarity with the app. I may, eventually, learn that a particular UI is using toasts to indicate something. That doesn’t suddenly make it okay. They’re still a massive pain in the ass for me. They’re still a massive pain in the ass for a lot of people. They’re still a poorly thought out holdover from the days of 640x480 displays, and with a modern resolution they’re even less appropriate.

To respond to your point,

(1) is it a PITA because it’s hard to see something in the periphery or for some other reason? (2) Is there an example of a web app that you’ve noticed provides feedback very well? (3) would you consider a toast acceptable when the UX designer doesn’t consider the information critical? As in…the user can safely assume their action was accomplished but a little feedback is a nice sugar.

Probably the best way to do it is to force show them a handful of elements center screen, and then where those go into the smaller overall view. This is really intrusive though and you don't want to present too much information too quickly this way.

After that maybe if they're not interacting with a side segment for a while make it perform some action to draw attention, but its a fine line between not enough and too over the top.

On Android, toasts often obscure the keyboard making it hard to type while the toast is being displayed (and still no way of swipe dismissing it after all these years).

On Gnome, various notifications get displayed as central top toasts which obscures the window directly underneath. No swipe to dismiss either, and only by putting the whole system in 'Do-not-disturb' mode do they go away.

> optimistically show the user a success result?

I don't particularly like React, but this a core feature of such JS frontend frameworks, optimistically "succeed" while async network and back-end work happens to give the illusion of speed: https://react.dev/blog/2024/04/25/react-19#new-hook-optimist...

I don’t have any strong feelings one way or another as long as there is proper inline feedback.

Toasts are a global UI feedback mechanism for non-blocking/fallible/undo-able actions. That does make them out-of-place by default, but at least consistently so.

A solution I'd accept is local-view-first with toasts-as-fallback when the view is dismissed. That said, loading indicators _might_ make users hesitant to dismiss a view.

Let's say the user wants to import some data source, and it says something like "Importing...". Sure, you can leave a notification in the menu, but if he did that import 1 minute ago, probably he wants to see some hint immediately. It's the same with the floating notifications in the phone.

The thing is, they don't solve a UX problem as much act as a catch-all solution for "respond to user action". It is easier for orgs to shove everything in a toast than to think about more practical places to put the data.

I have seen modals used to communicate status and reaffirming information that does not require action, and between the two, toasts are a better fit. That said, you still need to be smart where the bar is in terms of what is worth communicating. None of us want applications to blather on about stuff we don't care about.

I lead the design system team for an enterprise SaaS company—there are so many controls across so many views. It's hard to imagine including a feedback mechanism like this in every component.

And I still think we'd need some sort of toast confirmation for deleted records?

The all time you are actually interested in one and want to react to it, it doesn't stick around long enough.

I hate how the bubbles capture an area around them. If you need to click on something close to a notification, the click goes to the notification instead of that thing. That's sneaky and shitty. The border you see rendered in pixel should be the border and that's it.

This extra click area is not adjustable. There's an unanswered SO question about it:

https://superuser.com/questions/1490776/is-it-possible-to-ad...

As a backend developer this stuff is mind-boggling, just call it "notification widget", or a "confirmation widget" etc.

Try explaining what toast is to an Indian subcontractor who has never eaten toasted bread in their life and then apply that to the UX usecase.

Removing these terms will also improve accessibility and understanding for junior developers entering the frontend world.

"P-trap" is a confusing word that plumbers use, we should instead have them say "gas barrier". And the word "fuse" makes very little sense in an electrical context—try explaining to someone who's never seen a stick of dynamite why the "overcurrent stopper" is named after a long gunpowder-infused cord! Traffic engineers shouldn't refer to "groups of cars" as "platoons" (they're not in the military!), and software developers should stop talking about "DDOS" and just say "lots of computers hitting my server at once"!

In all seriousness: jargon exists because it's useful to be able to refer to something that you use a lot conscisely and precisely. Your proposed replacements are not concise or precise, and they only solve the non-problem of people not understanding the etymology of the jargon. Part of learning a trade is learning the jargon associated with it, and that's true for every trade.

Your example of a "P-trap" is good but its not like plumbers are going around saying, get me the "slinky hotdog" to bend a copper pipe, or you need a "banoffee pie" to seal this joint.

For example in Google

"toast"

"toast menu"

"toast ux"

All yield different results

However "p-trap" gets you a narrowed list of results

Again, it seems like you're inconsistent in applying your frustration with jargon. You're frustrated with jargon in an adjacent profession to yours, but don't seem to apply the same logic to professions that are entirely unrelated or to your own jargon.

Since the name arises from use by a hero, then to extend the metaphor by direct analogy, the actual hero is the overall article/content in which a hero image is contained.

That said, a "hero sandwich" is that which "one needed to be a hero to finish" [1] so does all tie back to the idea of heroism regardless.

[0] https://en.wikipedia.org/wiki/Prop#Hero

[1] https://en.wikipedia.org/wiki/Clementine_Paddleford#Writing_...

I've heard of "hero pictures" (detailed close ups, I think named via the highest quality film props), but not food or other UI uses.

How would you call a hamburger menu? "menu widget with three-or-sometimes-a-different-number-of little horizontal lines"?

As a backend developer you also have some jargon but you’re too used to it to notice it.

Menus are supposed to have titles so that you know what's in them, not just that there is something in them. It's especially obnoxious to see a hamburger menu next to other icons that happen to be for other menus. First off, this fails to convey that they even are menus, and not, say, buttons. But it's especially obnoxious trying to guess what menu items the hamburger menu might contain. Even if you decipher the other icons, you're left with speculating about all conceivable menu items, and then applying process of elimination.

To a front-end dev or designer, it does. That's who the jargon is for.

* Embedded example video doesn't work on Firefox.

* Reasoning reads more like post-hoc justifications to me.

* Last and most important: does not explain what "toasts" are.

Aside: The word in its default English usage is not countable. Making a plural means it must be the usage of clinking glasses of alcoholic drink, to indicate a salutation to a person or thing.

They seem to mean "toaster notifications". I only know this as an option in Pidgin. I Googled it and found this:

https://bootcamp.uxdesign.cc/toast-notifications-how-to-make...

That page suggests that this bad, broken English is a standard usage in some niche community or communities. IMHO that doesn't excuse it.

It's not totally broken, it shows the first frame of the image, there's just no indication at all that the image is actually meant to be a video, there is no play control, and it just looks like a static image.

Not for me. Big blank black space.

Could it be there is a correlation between poor use of human language and poor use of markup language? Between poor UI and poor cross-browser testing?

I lived with 2 different programmers for 2 extended periods of my life. Both were professional software developers. Both were startlingly poor at understanding how PCs worked, chose poorly and bought poor hardware, and then were unable to fix their own problems or install their own upgrades. Both were intolerant of alternative OSes or app choices because they were wedded to specific apps on specific OSes.

Now I can't safely generalise from that to all programmers, obviously, but it's a strong hint.

Toasts help communicate that an operation completed asynchronously after giving control back to the user without making them wait in a modal dialog. This is a very good UI/UX, especially now that users are trained to understand that asynchrony.

A little popover near the button makes more sense. Or, in this case, simply disabling the checkbox until the asynchronous action has completed, and using the non-disabled state to indicate success (or show a useful error message when the operation fails).