I'm not convinced. Most of the argument seems to be that redundant UX is bad UX:

> 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.

For me the worse aspect is that they disappear (too quickly), and that they sometimes unnecessarily draw attention to themselves for success messages where you would trivially assume the action to succeed. The combination of the two is particularly vexing: Your attention gets unnecessarily diverted, but you don’t know if it wasn’t actually important because it disappeared too fast. Conversely, there’s also a variation where it stays on screen too long, obscuring a part of the UI you just wanted to see/use in that moment.

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.

YouTube has even better examples.

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...

> The "Undo" button in the toast is unnecessary because the user can just click the checkbox again

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.

A toast makes sense only in 1 case: when it's a notification that is unrelated with the current action of the user. Similar to OS types of notification that the defunct Growl (memories) invented.

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 ).

For anyone as confused as I was, this article is not about toasted bread [1], but about a type of UI widget [2].

[1] https://en.wikipedia.org/wiki/Toast_(food)

[2] https://en.wikipedia.org/w/index.php?title=Toast_(computing)

> The "Undo" button in the toast is unnecessary because the user can just click the checkbox again

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.

Toasts can be bad UX (usually when they are the sole feedback), but they are great in conjunction with other elements.

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.

There things worse than toasts: hidden slide panels. They are basically hidden toasts that are necessary for some actions and are completely unintuitive, unfindable and undiscoverable. My worst experience was with waze using the cellphone of someone else; I had to do something (don't remember what) and just stared at the screen (like a retard) trying to guess what I had to do; the person eventually got the phone, slid the hidden panel from the right and showed me what I had to do.

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?

IMO, not a great take.

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.

> When the loading indicator disappears, it implies the action has completed

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.

As always when there is a clickbaity title that you think cannot be true it just lacks any nuance. Toasts are for displaying updates on things that happen OFF SCREEN, eg when doing something that takes a while and navigating to another screen. In addition toasts require a home for context to work propperly. This can either be a stack of toasts for very simple applications or a notification sidebar that can be accessed from a bell icon or similar. Toasts need to be shown close to this entry point to their home, not on an opposite position of the screen. The 2 most common mistakes are: a) show toasts for things that happen on screen instead of showing feedback in the actual action UI (its fine to keep them in addition for consistnecy) b) not have a home where a user can see what happened combined with autohiding toasts after a few seconds. (i cannot count how often i saw some dangerous looking error toast but could not read it in time, leaving me with a bad feeling especially for important things like admin UIs)

Let me share the dark side of Toasts.

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.

I think the actual issue is that Google makes bad UX often, and not toasts in general.

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.

To play devils advocate:

- 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)

Toasts are bad UX for an app which is used in a casual context, yes. The odds that an untrained user missed them and becomes confused are quite high.

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.

I quite like the information side bar on the right hand side of the Civilization 6 game. You get a long queue of icons indicating some result/status/notification. You can hover the mouse over them or click on them to get more information. The icons will be gone in the next turn or later depending on how relevant they are to the current game play. They are for historic information and semi-transient.

Games can be the epitome of good UI feedback.

I did not like this. This is why:

* 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.

Strongly agree. I guess toasts work better for mobile screens as they are smaller and mostly vertical, so the element spans the whole screen width. If it needs to be there and should be responsive, I would prefer it to be an alert in the upper-right corner of big screens.

The solutions seem to rely on a user that doesn't navigate before the action is completed. Does he propose locking the UI in the meantime, or to optimistically show the user a success result?

It's not like we've had decades and decades of GUI experience where every problem has already been solved. Also, this week's "designer" is smarter than everyone before them -- time to reinvent the wheel!

I agree with post and don't like toasts either.

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.

How about just getting rid of all food related jargon; salad bars, burgers, toasts, heroes etc.?

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.

> The Solution: No Toast

His solution ignores the undo component of the toast. Simply adding it back to the playlist is not a solution as that reorders it in the playlists. Instead, undo puts it back into the playlist where it was. When you have longer play lists, this becomes even more critical.

I'd much prefer a consistent way of interact than a bespoke unique way of using every UI component. Consistency and correctness versus creativity and confusion.

I think there’s a critical distinction to make here.

Some UI can model what the users interacting with accurately enough that updating the state of the model is a great way to communicate changes. If you remove an item from a list, you can demonstrate success through that interaction without using a toast.

On the other hand, sometimes the UI doesn’t reflect the model at all and there’s no sensible way to communicate with the user what has occurred outside of something like a toast.

The trouble is, you get inconsistent feedback mechanisms if you leverage both online feedback and toast feedback.

If this was an easy problem one way or the other, I’m fairly confident we’d have seen a convergence of implementations at some point and everyone would use a fairly common convention. It’s not that easy, though.

Good UX is really hard. People thinking it’s this simple are actually why I stopped doing it as much. Back end programming gives you so much more freedom to explore problems and people respect it to some degree. With UI/UX, especially UI design, everyone seems to think they know better already.

Notifications are good. Notifications that are temporally disconnected from actions (e.g. debounced, cooled down) are suboptimal - but its what people are used to. Getting rid of notifications altogether is not an improvement. In his example, the notification is basically a confirmation of a direct action. Notifications don't always feedback instantly

I would argue there's definitely bad implementations of toast notifications. On iOS I wish I could have more control over them to where I can almost automate them, I have notifications that if I haven't looked at it in like 12 hours, just remove it. It is also too easy to dismiss them, and never get them back. I want a "History" panel somewhere, so I can recover accidental dismissals, maybe let it live for 24 hours before it wipes forever. Sometimes I get a notification I'm interested in and dismiss by mistake, from an app I can't remember, or somewhere impossible to find within the app (I'm looking at you Nextdoor). App devs, if you're going to send me a push notification, please archive them within your app if the OS wont.

The need for this sort of disappears if the thing being displayed (client) is actually coupled to the application state. Toasts are bad UX, yes. But the reason they exist is that we have one state on the server and then another pseudo-state on the client. Keeping them in sync via code locality in every component is extremely difficult.

So we come up with a workaround -- put async server updates in only one place in the application -- to get around this fundamental issue. In 99% of cases, this isn't about UX, it's about engineering. Nobody wants to put toasts in; they must, because managing state is too difficult otherwise.

It's a symptom of the larger issue.

If instead what's displayed on screen is simply the server's application state returned by the server, the user will always know what's happening with the server.

HATEOAS

OP doesn't actually identify what is problematic with the toasts! The `The Problems with the YouTube Toast` section merely describes what OP sees, not what is bothersome to OP. I'm guessing that the issue is all the different locations on the page where things happen: the control, the dialog, and the toast are all over the place, thus maybe that is distracting to OP. In that case the issue is about UI element placing, not really about the toasts.

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.

this seems like an example of a mobile interaction pattern being blindly applied to desktop site

They are bad UX if I can't disable them. I universally hate all notifications. Stop stealing my attention. It's cognitive abuse bordering on violence. If I want to know I will go look, you don't need to shove it in my face.

A blog post about bad UX that has a video element with controls hidden and autoplay. With autoplay disabled, it can take a while to figure out this thing is a video that just isn't playing...

I tend to agree but I think toasts can still be useful and good UX. Putting useful and actionable feedback in context instead of toasts is a rule of thumb that I try to follow but it's not always appropriate.

For undo-able actions, toasts disappearing too fast or colliding with other toasts badly is a real problem. An affordance to see the toast history with non-disappearing undo buttons may be more to implement but for a lot of apps, a viewable and editable history combined with toasts is a much better UX than either system on its own.

What I mostly dislike about toasts is how they can obscure other elements (actions or information).

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.

The number of people and voracity that toasts are being defended in this thread is quite surprising given how terrible of a UI element they are. They don't exist anywhere in the document hierarchy so users have to mentally piece together what they're connected to, they carry no context, and they happen long (in computer time) after the action that that caused them.

Toasts are a solution to "I did something async and don't know how to design an actually good UI to convey that." And having a UI element for that is pretty darn useful because of how often that situation comes up. All of our default UI metaphors buttons/checkboxes/input boxes are all synchronous— either updating local state to be saved synchronously with a button or synchronously in real time (like setting a preference cookie). It's just that the web forced async-by-default on everyone without updating anything else.

If you show a user a checkbox it's absurd that such a thing can fail or not apply immediately, you're emulating a paper form, how does checking a box fail? Same with flipping a switch. Even if the light doesn't come on the switch is still flipped. None of these elements make sense to be backed by a request/response.

In the example in the article when the user changes one of their settings a save button appears, when you click it there's a progress bar or spinner, and when it finishes it says "Saved!" We figured this out in Windows 95. Quit trying to hide the form submission. The need for toasts is trying to tell you your abstraction is leaking.

I hate toasts too. I even dislike the name of this UI element - “toast”. Unlike a hamburger menu, the toast element doesn’t even resemble toasted bread slice. Or is it supposed to represent the short lived aspect of a toast between 2 parties?

Some sites even have toasts on mobile which block content. Have even tapped some of those actions by accident.

Also, since they are ephemeral. How does it impact a user on a screen reader? Is there an audio cue indicating a toast is on the screen?

In the examples shown, toasts are misused to display low-quality notifications, e.g. “x has been copied!”. Using toasts to display relevant error messages alleviates several problems:

- they work well in an otherwise cluttered user interface (error messages often break layouts)

- they allow the data layer to be substantially simplified, e.g. no need to store errors, error setters, error getters in Redux or similar

- they allow programmers to implement error handling toasts once and use everywhere

“[Element XY] is bad UX” is a nonsense and a misunderstanding what UX is. The particular YouTube example is indeed a poor use and poor implementation of toasts. You can find poor examples of pretty much any element on plenty of high profile websites. The element itself is rarely the culprit. The whole point of UX is the context and the flow in which each particular element lives.

Basically all of these are examples of 'bad UX is bad UX'. Sure, don't show a toast when another confirmation already appears. And dont make them async to appear. And dont include undo for something that is able to be easily undone. The toast for archive with the 'undo' _is specifically when you should be using this_.

For context, I'm coming from the world of native apps. Toasts overall, especially with the 'undo' action, have been a very useful contribution by Google to UX. Compared to iOS's "show a blocking popup in the middle of the screen", they were so much nicer. Like I said, the "undo" for cases like the archive example are the whole point! Instead of asking "are you sure?" for everything, you just delay the action and offer an undo. Default to the user being sure they wanted to perform that action and dont gatekeep their flow. Dont overuse it, but dont blame its bad uses on the toast itself.

Timed toasts are bad for accessibility too, see WCAG 2.2: https://www.w3.org/TR/WCAG22/#enough-time

Basically, the user should be able to configure toast messages; they should not autohide, or the time they hide should be adjustable, or they should be extendable within 20 seconds. TL;DR, self-hiding messages, dialogs, etc are not good for a11y.

That said, the toasts have a button where the user can undo the action taken, which is good for accessibility under criteria 2.5.2 and/or 3.3.4 / 3.3.6

If I am honest, the main reason I use toasts at first is because it ensures mobile compatibility. The problems with mobile UI (dismiss X offscreen, feedback off screen, user refreshed the SPA app page ruining state etc) are less likely to occur with a toast. They also bring some element of tolerable, expected animation (like 'page loader bars') which newbies often miss, and make the experience less jarring as a result.

Yes it's not great UX but it functions consistently well. Although 80% of the applications we use day-to-day may be by big corps with excellent UX and time to spend on it, 80% of applications built never get round to even consistent and fairly error-free UX. So I consider reaching that stage more important that adhering to a beautiful, but more risky, cross-platform UX strategy when in early stages with limited resources.

Reminds me that old programs, be it Maya, Emacs, or even MFC days had a status bar for most simple notifications.

I agree with the article, but I think there's a greater principle here that it misses – UI that obscures other UI is bad UX.

It's a lazy cop-out to avoid having to figure out how to integrate important elements into the design of your page.

I find Google/Material Design's floating action buttons very frustrating.

Microsoft Windows' notifications are basically all toasts. Horrible UX.

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...

Good piece. I've experienced this in many contexts, and widescreen monitors make it a bigger problem.

I haven't heard many developers/designers talk about the overused practice of using toasts for UI feedback.

The post shares a few real-world examples and illustrates some of the problems with how they use toasts.

What do you think? Are toasts overused? In which cases do you use them in your own apps?

I find this interesting is games (and the development thereof). While playing people are usually concentrating really hard on something of their own choice, so they will often miss various popups trying to tell them vital things about how to play the game.

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.

I wonder if having a dedicated area for all kinds of toasts from all kinds of websites will help? Like some websites have a top-sticky toasts where important messages appear. Dedicated area will also ensure that (after a small one-time learning curve) user will get accustomed to such toasts and may even look forward to them as a form of validation and particularly when they need to really use that toast because they want to revert a certain action. Those stickies can be made optional if user wants to opt out of them since they will by nature drag the whole webpage downwards by some pixels and can feel jarring to some.

> 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.

Double-encoding information is good if the information is really important so long as the two ways you encode it always and only appear together. You see this in data visualization a bunch (think a bubble chart where larger circles also become a more saturated red).

Sure it doesn't satisfy some platonic ideal of purity, but for a distracted user it can lessen their cognitive load and so can be good UX.

The point about distance is interesting. Toasts popping up near the action could be neat.

HM...

The redesign of the "Save" operation is better than the original, where the checkbox list is positioned in context, and there is an indicator for the async operation.

But I think it would be better if it kept the toast. When the operation completes successfully, presumably the async indicator just disappears. That has no impact and a toast fixes that.

Also, presumably the operation can fail. I suppose you'd replace the async indicator with a red X or something, and maybe revert the checkbox. But it would be useful if there could be a textual description of what went wrong, and a toast is a nice and consistent way to present that.

To me, toast is a mobile-first design concept, where all information on screen can be perceived in a glance. The assumption which supports this concept is no longer true on a larger screens.

I think it's a middle path thing. I like toast error messages but for simple confirmation actions like Saved, Deleted and Copied, the text change is better. HTMX makes this really easy to do :)

Always = in Material design

https://m3.material.io/components/snackbar/guidelines

Watching my 91 year old mother try to use a computer, I can see that messages that flash up and then disappear are extremely bad for individuals with slower reaction and processing times.

I really like the short and visually descriptive layout of this article. It clearly conveys the message. I'm not in agreement that toasts are always bad though.

It can be useful to follow an expected pattern; users are likely to understand that a toast gives feedback for an action they have taken. Although other ways exist to accomplish this, they will follow different formats depending on the action (by necessity).

As with lots of design, expected patterns change over time. Although they are non-local, toasts are familiar.

If you're analyzing the youtube UI I can show you a lot worse issues than the toasts lol. That's a minor issue. I consider myself a heavy youtube user for over a decade and to summarize; Youtube doesn't care about UX.

Yesterday they added a sleep timer, yesterday! A feature that shouldn't take more than a day to develop. But it's highly valuable to a large number of users, Youtube doesn't care. Good UX is only valuable as long as they can make a profit from it.

The only case where I see a reasonable toast case is for asyncronous events that are a response to a recently applied change.

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.

As long as the "toast" section is reused for many different messages, I don't get the problem? Ideally, you'd embrace that there is a common spot to see informational items. Even more ideally, you'd have a way to view all of the notifications that have been shown. (Emacs user entering the conversation...)

I confess I was completely at a loss as to what a Toast was, though. I suppose we went with that name because they pop up?

My only problem with YouTube toasts is when the toast to confirm you've enabled closed captions covers up the closed captions you were trying to see.

Counterpoint: toasts offer a great pressure release valve, are easy to have a single standard implementation of for a system, and avoid having to tackle high-level design questions when the feature in question doesn't really ask it.

Youtube has a lot of people on payroll to naval-gaze the problem described. Most systems don't. Having the GUI-equivalent to logging be easily available is a win for system usability.

I completely agree that it being far away from the interaction point is bad UX. That said, toasts by themselves are not bad, it depends where they are.

Toast are used for two reasons:

- An action has a destructive operation that you can't easily undo because the main button has disappeared (i.e: delete, reset, confirm a popup, etc.)

- Displaying a message would break the UI somehow (i.e: error message in a list, near a button in nav bar, in a tight UI, etc.)

I honestly don't feel like they are the best, and most of the time they are useless, but from time to time they are handy.

Maybe bad UX, but global error / success handling of network requests is way easier than handling in every component that triggers one.

The worst toast I've seen is on Android Auto (itself already a veritable petri dish of awful UX) where, when the on-screen keyboard appears, a toast helpfully pops up informing you that a keyboard is also available on your phone... Thus blocking the on-screen keyboard from being used until the toast fades (and no, tapping it does not dismiss it).

Ok, but how do you avoid toasts when you have a lot of 24x24 action buttons in different places like in MS Word toolbars? Basically author assumes one can add loading indicators into every modal that appears with the buttons, or to the longer buttons themselves, but what if you have no modals and buttons aren't long enough?

What if you click an action in a popup and closed the popup or navigate to another page in the SPA all-together. Without a toast you have no way of knowing if an async action failed. I agree though that we should try to put the info closer to the user's attention, but still Toasts should be used as a fallback.

The save button on youtube mobile app is annoying. Clicking save shouldn't automatically add to watch later, with adjusting have to click the toast popup and set where you want it to save.

Its also hard to see the popup if you click the save button because your finger is blocking the bottom of the screen when you click.

This does not consider errors, especially non-recoverable ones (server problems, bugs) where imho it's hard to design.

Exactly. State transition should be expressed, managed, and kept synchronized with the control itself to indicate that the backend has recorded the change or not. Another consideration is how to handle disconnected operation: should a change attempt that cannot reach the API time out or retry indefinitely?

It's a bit unfair, to toasts, to use two examples from Google products, they are terrible at UX.

I can’t reply to dang’s comment with a Wikipedia article but I was laughing when the link they posted resulted in a toast notification.

https://i.postimg.cc/bvSk0fzj/IMG-7616.png

I wouldn't want to implement the suggested YouTube UI (menu showing up next to button) because it's the kind of thing that has the most potential to glitch out. Dialogs generally don't glitch out as they're absolutely positioned and can be handled by the browser.

> What's worse than a toast? No feedback at all.

I'd argue that the YouTube iOS app found a more worse toast: the confirmation toast for removing videos from a playlist covers the original menu which triggered the action in the first place.

Makes it very hard to perform the same action repeatedly.

I only use a toast for displaying error messages that otherwise displace UI elements on the page

I never found toasts to be bad UX

effective use of toasts is to confirm to that a big change that they initiated was successful. for smaller changes, like checking or unchecking a checkbox, toasts are redundant

I thought this was going to be about Android (which makes heavy use of that term), and I was expecting completely different complaints:

- The toast disappears quickly, so you might not have time to read it / take a screenshot

- It's not possible to copy the text

- Long text is truncated (e.g. exception messages)

Just wait until the author sees the toasts in MS Teams. I expect his head will explode.

Teams has, hands-down in my opinion, _the_ worst usage of toasts that I've seen. It's bad enough I get the OS toast from Teams, that may or may not disappear on its own after a time (on both Windows and Linux). However, there's also an in-app toast that blocks part of UI that is used the most: replying to messages. Literally, typing a reply, then boom, toast appears, blocks most of the buttons used to interact with your reply. (formatting, emoji/gifs, attachments and even the reply button!)

OMG yes! I feel the same. I think that sometimes product owners don't use the products.

Toasts would be alright if they showed up in a dedicated portion of the UI (eg. status bar) which had a notification history so that you don't feel like you're racing a clock to read an unwanted popup trying to steal your attention.

My main complaint is that on Firefox on Linux anyway they actually steal the mouse position along with keyboard focus. So if you're using something like instagram's IM it's really hard to type while getting replies.

Design for mobile and this is less of a problem. Toasts are right there!

It may not be as fun or polished, but a log is much much better UX.

Absolutely. Toasts, like any overlaid UI, is just a cheap and easy way to add information to the screen without affecting the layout. Cheap and easy doesn't make it good

Taking youtube as an example is like taking a dead horse to a race. Youtube is an utter garbage ux-wise, both in bugs and features. Even fringe porn tubes are 10x more competent than youtube ui team.

Their latest “addition” was rewinding a video after a long pause. You watch a video, pause it at t=1:24:57 and go to sleep. Next day you start the video again and it goes for a while from t to t+n (depends on the buffered data), until it jumps back to t-20s.

Someone thought it’s a good idea to -20s after a long pause, and it might be good, if they assigned a proper developer to the task. Instead someone pushed an obviously idiotic change, without anyone checking. It’s not even an issue, it’s clearly “job done” by someone who couldn’t give a lesser fuck due to ieee754 limitations.

You cannot avoid that behavior. If you go forward/back or manually jump elsewhere, it still resets you to t-20s shortly after. You might think you just reload the page, but reliably saving the current position is not in their competence either.

That and a dozen other stupid bugs they fiddle with constantly but can never fix. Literally on a site with a sidebar and a grid of equally-sized elements. Their thumbnail card alone takes 7.5 pages (17KB) of html.

Various forms of popups, using catchy names. All popups are evil. We learned this in the 1990s. It is utterly shameful that today's webdevs have resurrected them.

I would say the article is a bit nit-picky IMO. For every pattern there are probably dozens of poor-use examples. I personally really like the Gmail undo mechanism.

There are a lot of calendar mods I've made in GCal that I wanted to UNDO, but couldn't because it had evaporated by the time my cursor got to it.

Somehow, those YouTube "toasts" always manage toi come up over the play control, when I need to use the controls. I think they're magic.

My biggest annoyance with toasts is when they are undismissible and cover other UI elements. Instagram (in their menu system) is a particular offender.

I have never seen the UI of YouTube as shown in the article (information panel on the right). How did the author get that?

For me it's always on the bottom.

It's an effective UX tool for smaller screens like how it was created for Android phones, in larger displays it doesn't work as effectively.

Gotta disagree. Toasts are still ideal for the background operations and opt-in status updates.

I came here thinking there was a new recommendation for making toast, or at least a recommended type of bread to use, but I found nothing edible.

counterargument: toast is unobtrusive by design. it's not part of the main workflow, and not causing the user to context switch.

+1 to screen readers

That's a decent list of some of the problems with them. Toasts are my second most hated UI element. The ribbon is my most hated.

I think a lot of this makes sense when it's made for mobile, while desktop users are using increasingly large monitors.

Toasts on smartphones are worse, it happens so incredibly often that YouTube obscures part of the video that I want to see with an unnecessarily large toast to tell me I did a thing. Most notably, switching quality. Or just now I enabled a beta test feature, it gave me a toast. Why?! I know what I did. The same if I click the same button again to disable the feature. At least you can dismiss them by dragging them down.

Strongly disagree with this. Toasts/alerts/etc. are a valid form of feedback in the UI. Inline feedback can be helpful/good (e.g., the copy/paste example in the article), but it can also be confusing if applied incorrectly.

A toast is a universal, out of the way confirmation of a user action. They shouldn't just be blindly waved off as "bad UX."

the fact people are discussing and writing articles about something taken as true (toasts are bad) by all interaction designers who actually studied at some point...

that must be what astrophysicists feel like reading a flat earth discussion.

toasts are like those friends who always show up 2 hours late to the party and then stand in the corner. if your app needs them, at least make sure they're not doing the cha-cha in the wrong corner of the screen.

"We do have to consider the undo-functionality and that the toast feedback can be useful when using keyboard shortcuts."

There's nothing more infuriating than going to click undo and the toast disappears.

I truly despise toasts. They slide up or fade in in all corners or center top/bottom. But never in my visual field. Add to that 2x27” monitors and they are either missed or a distraction. Unraid have them, but they are customizable and offer history. Thats ok.

How difficult can it be to put a message next to the task, or in the center of the screen? Or offer a proper log of messages, such as Unraid does?

You want to know what's REALLY bad? When the whole TOASTER pops up in your face!

Here's the deal: I maintain a boatload of Visual Basic (yeah, yeah) in Autodesk Inventor. That program REALLY wants to make sure you're saving regularly, so if there's a document open that's been changed and left unsaved for awhile, it pops up a notification. This is fine when you're working on the model, and you just see this "toast" popping up in the corner. You make a note of it, maybe divert to the save icon, and get right back to work.

On the other hand, if you happen to be using the VBA environment when Inventor decides you need a reminder, it absolutely insists on slapping ITS window over top of it, so it can notify you Right Now! That includes grabbing focus, of course, which leads to all sorts of fun when you're in the middle of typing, and suddenly find yourself starting You-Don't-Know-What-Command on the model.

Fun times.

So, yeah, "toasts" can get annoying, but grabbing focus... THAT's when the trouble starts.

A UX take without backing data is just a design opinion.

Terrible article imo. You can’t approach UI from the perspective of a developer using the UI you just wrote, you need to think about it from a user’s perspective. That sometimes means having redundancy in the name of familiarity and legibility.

I agree YouTube example is pretty bad, but the gmail one is a really good use of a toast! What do you mean “you can see the email is removed from the list”?? Have you ever used email before? You usually have more than 3 messages, and seeing which one was removed, let alone that one was removed at all is not always obvious. And “undo” is incredibly important since you don’t have direct access to the removed item (and sometimes it’s a time sensitive action like undoing sending an email). The last one is not very helpful but not harmful either.

Also even if all the the examples were truly horrible and despicable uses of toasts, 3 bad examples are not enough to say a commonly used UI pattern is outright “bad”.

LinkedIn toasts are the worst.

those toasts are bad UX

This is called a Snackbar now.

* When forced down the users throat and hijacked by the marketing department

pet peeve: this blog seems not to have an RSS feed.

YouTube toast is a bad UX and French toast is always a good UX.

So are modals

Sorry I have no idea what he's even talking about after the first couple of paragraphs and screenshots, so while I'm very interested in good UX, I'm left thinking this author is not an expert practitioner.