Toasts are bad UX(maxschmitt.me)
maxschmitt.me
Toasts are bad UX
https://maxschmitt.me/posts/toasts-bad-ux
400 comments
https://en.wikipedia.org/w/index.php?title=Toast_(computing)
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.
> 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.
The unfortunate thing is they aren’t communicating the same thing.
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.
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.
> I would much rather only get the toast if there is a failure to commit the change ... 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.
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.
I think it would be nice if the toast popped up and hid in a tray and you could expand it and see a toast history with timestamps.
Toasts showing up far from where the action is take also makes them super annoying for people (like me) who use screen magnifiers. I'm oftne using a site while zoomed in, and will completely miss a toast, because it never enters the "viewport" on the screen I'm looking at.
What kind of design choices do you find helpful with using a magnifier like that? It's not something I'd ever considered before, sounds tricky to design for but I'll try to keep it in mind now.
The two main things for me are:
- 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.
- 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.
> I hate video players that overlay the pause button when the mouse is over the video, or images that get obscured by some overlay when hovered.
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.
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.
Oh yeah those video players are awful for anyone on mobile too, always ends up somehow getting stuck active and the only way to dismiss it is tap the video, which of course is usually bound to some other disruptive action like pausing or exiting full-screen mode.
Adding to your examples, I hate when video players (both mobile or desktop) don't let me hide the video player controls when the player is paused! I also dislike having to wait a few seconds upon starting/resuming a video for the controls to fade away.
> I hate when video players (both mobile or desktop) don't let me hide the video player controls when the player is paused!
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?
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?
[deleted]
> I also dislike having to wait a few seconds upon starting/resuming a video for the controls to fade away.
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.)
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.)
I sometimes use a Bluetooth speaker on mobile just so I have a pause button handy. Playing a video full screen requires me to tap once to bring up the controls, and then again to pause.
Yeah. Put the controls in a corner.
Good questions - also note that fixes that would help magnifier people also benefit users who have overlapping windows and/or windows partially off-screen. (This is also an example of accessibility features helping people who are "fully-abled")
I disagree on that—in the YouTube example specifically this isn't necessarily a problem, but the toast serves a valuable purpose in the archive in that it tells you again which button it was that you pressed. There have been countless times in cases like that where the toast has saved me and allowed me to undo a misclick.
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.
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.
Toasts also give you a good place to put other shortcuts like “Item updated. [View item]” that make it much easier to act on state changes, like navigate to sensible places to view / react to those changes.
> Toasts also give you a good place to put other shortcuts like “Item updated. [View item]” that make it much easier to act on state changes
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.
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.
So there are badly implemented toasts that have bad UX. That's not the same thing as the whole concept being bad.
If something is so hard to implement that everyone who tries gets it wrong (to a first approximation), then maybe the concept is bad. Or, at least, the concept isn't fully baked and is missing something critical.
Most implementations of toasts-with-actions that I've seen don't have the problem OP described. I more often find myself manually dismissing them than wishing they'd have stuck around longer.
So because you are a fast reader and have a fast reaction time with your mouse, toasts are good for everyone? No.
Should complex websites have a notification center where you can look at prior notifications? Would this be alike enough to existing desktop metaphors to be easily recognizable or simply confusing.
Maybe your browser should could have an icon for same instead making it more standardized across different sites.
Maybe your browser should could have an icon for same instead making it more standardized across different sites.
I'd go for an action log. It's almost the same thing, but notifications imply ephemeral pokes about some of the stuff that happened, mixed with engagement boosting spam - there's a lot of unpredictability embedded in this concept, as the app is usually trying to guess what you may (or it thinks you should) find relevant.
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.
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.
I love this idea! And also I like how it implies dispensing with the wrong notion that I care about every so-called notification and thus that I have “unread” notifs.
I think the best UX for async actions with optimistic UI updates would be having an (attention-grabbing?) indicator when an action is added and then another when it completes as well as indicating the number of pending (i.e. unconfirmed) actions and a persistent indicator if any of the actions failed.
This sounds like something the browsers could standardize.
> Browsers that support JavaScript typically implement the Notification API. This API asks for user confirmation to allow popups and give the programmer the opportunity to display notifications with a text (body) along with an descriptive icon and header.
https://en.wikipedia.org/wiki/Pop-up_notification#JavaScript
https://en.wikipedia.org/wiki/Pop-up_notification#JavaScript
I only allow notifications from a tiny number of sites. The ability to notify me while on the page is different from notifying me while the tab is in the background and more so yet than the ability to bug me whenever.
Ask for everything get nothing. I imagine most people click no
Ask for everything get nothing. I imagine most people click no
Of course, this is just abused by sites to spew their garbage outside the confines of their own pages, which makes the API effectively dead.
Indeed. I would rather all browsers just disable it by default with not even the popup asking if I want it. If I install a webapp as a PWA then maybe ask me. Otherwise? Website operators are on crack if they think I want them to be able to spam my desktop multiple times a day even months or years after I visited them!
Yep, if this feature was limited to the window in focus, then the API could make sense. The way it is now, I know all savvy users will just block it, and many of the non savvy ones will too... Complete waste of time to dedicate developer resources too over e.g. in-line toasts.
Sometimes (as in a chat app) I want the window to notify me when anything changes, so I don't have to sit and look at it.
Sure! Unfortunately I am not sure I’ve ever seen the api used for anything other than what I’d call spam. To the point where as soon as I’m prompted I’m finding that “block” button before even speculating what it’s supposedly for.
All of that is inacessible.
How so?
Screen reader's probably not going to catch a transient element unless you just happen to stumble across it within that narrow window. Slow reader for whatever reason? Hope you don't take too long, or hope that toast wasn't actually important/actionable for you.
The spec has an answer for the "transient element" issue: https://developer.mozilla.org/en-US/docs/Web/Accessibility/A.... Of course, this doesn't eliminate the possibility of bad UX.
I mentioned this in another comment, but the whole reason the archive is able to be optimistic is partially because they offer the undo via toast. Otherwise its likely they would add an 'are you sure' plus a loading-state when doing these "semi-destructive" actions.
I've accidently archived something only to realize it when the toast pops up. I'm grateful for the toast instead of having the 'are you sure' like you mentioned. It's a nice compromise.
You can offer Undo via things other than toasts, though. In fact, I wish more software offered Undo--the Undo feature has kind of gone out of fashion since the early 2000s. You should be able to Undo anything (and follow the Undo chain back through many past actions). We somehow lost this ability from software.
Undo's (and especially re-do) are quite hard and resource intensive to code, especially for web apps that can be simultaneously accessed via multiple devices.
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).
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).
For sure you can, but a toast is a tool in the toolbox. When it makes sense to use it, it definitely justifies its existence as a tool to keep around.
Undo via ephemeral toast seems like a bad idea also. I guess if the toast hanged around until the next toast it might make sense?
Theres an implicit assumption that the actions being offered an “undo” are semi-important/permanent.
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
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
Putting an email in trash seems like exactly the kind of action that does _not_ need a toast, since it's easy and obvious to undo.
A grade A implementation would keep a local state that syncs to the server, indicates a sync is in progress, possibly stacks changes to reduce latency if there are a lot of changes + a slow connection and, to a user, gives me utmost confidence that I’m not going to lose data.
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.
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.
Even with your description of a gradee A webapp that uses local state management effectively + shows syncing + queues with stacking + connectivity detection and exponential retries etc. I still feel like toasts can be useful to indicate to the user when are not in the "normal" state. I feel like especially mobile apps fail horribly at this, it is very normal to walk around a city and end up in dead spots. Having a clear indication from the device that we are longer in Kansas can be very useful. IMO toasts that plop up for successfull actions are often quite useless and redundant.
I don't entirely hate toasts, I don't think your example is good, either. A toast is best for asynchronous, high priority, fleeting information.
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.
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.
> I would much rather only get the toast if there is a failure to commit the change.
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.
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.
Fair enough, but when they are not communicating the same thing, there are no grounds for objecting to them on the basis of redundancy.
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.
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.
It also would mean you would move the item eagerly, then put it back on error. Or alternatively make it a "ghost" item in the list then remove on success. But overall the eager-move + toast + undo is just a much faster feeling implementation and the overall UX is so much cleaner.
The undo button justifies the toast here IMO. Otherwise I'd prefer ghosting really.
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)
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 agree they do a good job, but I think a toast without undo could also work there. Apply the UI eagerly, toast success or failure. As it is, I assume on failure it becomes an 'X' and shows an error? I just dont generally like very short transitions like the spinner is currently. In general, coming from app land, I prefer a deferred loading spinner that only shows if the action takes X ms. So in the happy path of a fast action the user never sees the loading state.
> The problem with notification only of failure is that one is left uncertain about success
But that's less a problem with getting notified or not, and more a problem with software not doing what you've told it to do.
But that's less a problem with getting notified or not, and more a problem with software not doing what you've told it to do.
That's the problem of whether the developer and the user have the same expectation of the max duration or timeout of an action. For example a developer might default all backend actions to have a timeout of 30 seconds. But as a user, if the action succeeds quickly (the usual case) I want to immediately see a confirmation of that. I don't want to wait 30 seconds just to see no notification about any failure.
No, they're bad. Messages that are on the periphery of my vision/attention (imagine a widescreen monitor) are actively confusing. I'm working on THIS problem here and something flashes up over there. Half the time, as I refocus to read this annoying intrusion, it disappears.
It's bad UX. Put your damned messages where my attention has already been directed to BY YOUR UI.
It's bad UX. Put your damned messages where my attention has already been directed to BY YOUR UI.
The inevitable tradeoff here is having a somewhat standardized location for notifications versus allowing them to appear arbitrarily determined by the developer’s notion of where they are ostensibly drawing your attention. Maybe that’s worthwhile, but I think there are going to be a lot of cases where the ideal location is ambiguous, or where devs have an idea for where your attention will be that’s not always correct, or where bad actors exploit this flexibility to make it look like something it isn’t in an effort to trick users. I don’t know the right answer to what might be best, but I tend to think that standardized features should be preferred when in doubt.
It's not standardized. And putting notifications on or right next to a control you're INTERACTING WITH is not "arbitrary" at all; you must be looking at it, because you're using it.
Doesn't it depend on your platform, and isn't experimentation the way things become standardized?
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.
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.
Some conventions transcend platforms. The aforementioned greying-out, for example. And sure, we have to try something for it to become a standard. But in the end the standards percolate up because they're intuitive. The controversy over some of these "toasts" shows that they don't meet that bar.
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.
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.
What if another thing errors at the same time? If you put the error just where you clicked it, you may well miss it. If all things like that happen in the same place (e.g. bottom right) then you won't.
It's pointless pretending there's one perfect guiding philosophy and all others are obviously wrong.
It's pointless pretending there's one perfect guiding philosophy and all others are obviously wrong.
[deleted]
Depends on gap between the interaction and notification. If the person has already moved on from the page, then next to control is not possible. In which case notifications at some standard position makes more sense.
In some cases, the current user's focus is unrelated to the notification. For example: if the notification is alerting you to some foreign event like an incoming message, an app reading the clipboard on its own, an alarm, etc. -- some kind of standard positioning is needed for this.
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.
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.
> Put your damned messages where my attention has already been directed to BY YOUR UI.
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.
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.
If the "toast" can persist through that behavior, so can feedback positioned more sensibly. How does putting something on the other side of the (potentially huge) screen solve that "better?"
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.
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.
If you can't show me a spinner or other indicator that this is an ongoing operation (which I find preferable), and you think I will have moved away from the controls for this, then put it in a central location that I will see even if I am still on your control, not in a little box on the other side of the screen.
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.)
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.)
Yes! The problem isn't duplication of the message, nor is it that they convey slightly different things. The main problem is their lack of locality.
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.
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.
I use a computer mainly by using a zoom tool to magnify the area around my text and mouse/finger cursoe. I miss almosst all toasts and most notifications because they not where I’m working. For my use case, feed near the item I’m interacting with is the only valuable feedback.
I assume you don't want a full screen reader if you're not already using one, but if toasts are properly implemented (big if), screen readers can actually present them accessibly via the ARIA alert pattern[0].
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/
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/
Thanks for this! I visited your link and hadn’t seen such a nice demo with working code on w3.org before: whoever worked on these pages deserves kudos.
None of that invalidates what your parent comment is saying. They’re not saying you should use toasts to the detriment of other options, but in addition to them. If anything, your comment reinforces the notion that redundant information is beneficial because you don’t know where the user is looking.
Yes. For example: while OP uses a magnifier, lots of other people use a screen reader. "Loading indicator disappeared" is a tricky thing to communicate clearly with audio. "Toast: save successful" is trivial.
This is something that I think a lot of people miss. There is for sure a reason why google has that toast. One shouldn't just dismiss what the big tech guys do in terms of UI because they are among those who have the most resource to spend on it, and also the most amount of users. So for them it makes a lot of sense to spend effort to cater to people with various disabilities, as there is financial profit in there for them.
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.
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.
I was attempting to suggest toasts "are bad UX", but your points make a lot of sense. Thanks.
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.
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.
Same here, in the last 2 years, my eyesight has gone down a lot (combination of astigmatism and presbyopia is not great). I used to love the growl style notifications from macos, now I always miss them (and often miss the alert that I only have 5% battery left).
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
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
I think this is because a global toast service is trivial to implement, one service class / event listener, one UI component. It takes one ticket to make, and then it's just a matter of implementing the event publishes // serviceclass calls. This is much faster than implementing a plurality of ways to indicate loading and resulting success/fail.
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.
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.
>Redundancy in communication is a feature, not a bug
Too much junk information trains users to ignore them, which leads to hilarity ensuing if there also is valuable information every once in a while.
Moral is don't send information to a user if it's not strictly necessary.
Further reading:
https://en.wikipedia.org/wiki/Banner_blindness
https://en.wikipedia.org/wiki/Alarm_fatigue
https://en.wikipedia.org/wiki/Inattentional_blindness
https://en.wikipedia.org/wiki/Habituation
Too much junk information trains users to ignore them, which leads to hilarity ensuing if there also is valuable information every once in a while.
Moral is don't send information to a user if it's not strictly necessary.
Further reading:
https://en.wikipedia.org/wiki/Banner_blindness
https://en.wikipedia.org/wiki/Alarm_fatigue
https://en.wikipedia.org/wiki/Inattentional_blindness
https://en.wikipedia.org/wiki/Habituation
I think the suggested improvement clarifies what he means: if you're worried that the UI element the user is interacting with doesn't fully convey what's happening, then improve that element rather than adding a second element that divides the user's attention and challenges them to read quickly and make the connection themselves. Communicate the failure of their interaction in the context of the element they interacted with, so the connection is clear.
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.
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.
I get what they were saying and agree that in-context feedback should be added wherever possible. I just disagree that leaving off the toast is (in the cases cited) valuable.
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.
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.
> I just disagree that leaving off the toast is (in the cases cited) valuable.
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.
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.
> 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.
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 <ret>" into "ctrl" (held, released) and then "n e w s <ret>", which does $deity knows what in the current tab.
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 <ret>" into "ctrl" (held, released) and then "n e w s <ret>", which does $deity knows what in the current tab.
I don't even know if I'm neurodivergent, but apps that optimistically indicate success instead of using spinners give me a ton of anxiety. I see that in my wife and other family members, too. Even looking at something that explicitly says "Your order has been placed!" leaves people in a state of nervous suspense until we find a text message or an email to verify. In the absence of that, they just don't know. Part of my techie privilege is that I know a page refresh can usually reveal the truth.
> Even looking at something that explicitly says "Your order has been placed!" leaves people in a state of nervous suspense until we find a text message or an email to verify.
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...
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...
> 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.
All things that a message log does better than toasts!
All things that a message log does better than toasts!
Why not both? A message log can always be consulted later, but it doesn't give you a live feed of things that are happening.
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.
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.
A message log can also be visible...? The only differences between messages in toasts vs messages in a log is that toasts control the user rather than the other way around.
Isn't a toast just the tail of a message log that's visible for a few seconds after a new message is added? I don't always want the entire log to be occupying space on my screen, but I do want to see when new items get added.
The problem is that everyone implements toasts, and no one implements the message log, even though it's the latter that's more important to have.
Exactly - a toast is, at best, a nice add-on to a message log. Although I maintain a well implemented message log already serves every single purpose toasts do, better.
[deleted]
> redundant UX is bad UX
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.
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.
Have you worked with an old person?
Redundancy in UX confuses them. The closer you can get to the whole UI being a single sentence and two buttons the better.
Redundancy in UX confuses them. The closer you can get to the whole UI being a single sentence and two buttons the better.
Yes. And I've never once run into issues with redundancy of information being a problem. It's the clever things people do to hide information or to be concise that reliably get them confused.
> 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 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.
Have you?
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).
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).
> If Outlook gave feedback to every user action in a toast, then provided a universal history of every toast
This is what message feeds are for. Toasts are just a worse implementation of message/notification feeds.
This is what message feeds are for. Toasts are just a worse implementation of message/notification feeds.
> Things disappearing with insufficient explicit feedback
Toasts appear somewhere in the corner and then disappear very quickly. Not sure how useful that feedback is. It's distracting at best.
Toasts appear somewhere in the corner and then disappear very quickly. Not sure how useful that feedback is. It's distracting at best.
The whole point is that they DON'T add visbility, because they're not presented where the user is working. Age isn't even a factor.
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
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
If Outlook showed a toast for every action I take, I would immediately do everything in my power to make it stop, up to and including hermitage.
> If Outlook gave feedback to every user action in a toast
That would make me utterly crazy. I couldn't use an application that did this.
That would make me utterly crazy. I couldn't use an application that did this.
Toasts literally disappear..
The given examples seem pretty poor. An email disappearing from a list doesn’t tell me it was archived. Maybe it was deleted, maybe I accidentally hit some button and I’m not sure what happened.
The toast makes it clear.
The toast makes it clear.
For sure — I've seen that struggle.
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.
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.
With SPAs, stuff happening in your browser doesn't imply any action has been taken on the server. Gmail lets you delete without an internet connection. If it never reconnects before the page is abandoned your changes won't be committed. A toast that is only triggered by a server acknowledgement has value.
As someone with a human-computer interaction degree, this thread deeply saddens me. In general, human-computer interaction is considered a field of computer science, which I guess hn has a good representatin of.
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.
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.
> ” Redundancy in communication is a feature, not a bug”
I completely agree with you.
The article kind of confirmed to me that toasts are good UX.
I completely agree with you.
The article kind of confirmed to me that toasts are good UX.
> > But by archiving the email, the email disappears from the list, which already implies the action was successful.
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.
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.
"At best they're redundant" sounds pretty bad to me.
[deleted]
You apparently missed the bit where redundancy in communication is a feature, not a bug. "It ensures that even in less than ideal conditions the message still gets through."
I didn't give it much regard.
Toasts ensure nothing as there is no guarantee the user saw them.
They are redundant as in superfluous not as in a back up.
They are redundant as in superfluous not as in a back up.
I totally agree with you... this is why Java being so verbose is actually not terrible either, lmao come after me
Honestly I think the perennial "Java is too verbose" complaints are completely overblown, and say more bad about the person complaining than the language.
I agree. In the first example, you would assume the action completed even if you missed the toast. But in case you did notice it, that gives you a confirmation. Suboptimal? Maybe.
But the proposed solution is clearly worse, unless the loading circle turns into a tick to show completion
But the proposed solution is clearly worse, unless the loading circle turns into a tick to show completion
You missed the main point, which is that the "toast" is nowhere near where you're looking when performing the action.
I didn't miss that point, I'm arguing that that point doesn't prove anything about the merits of a toast.
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.
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 just think that a toast should also be displayed
As long as it can be disabled. I find toasts to be actively bad and don't want them to happen at all.
As long as it can be disabled. I find toasts to be actively bad and don't want them to happen at all.
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.
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.
To add to this. Some of them show important information the user needs, but it both disappears too quickly, and is incomplete, due to size limitations of the toast.
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 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.
To me, the imply that there's a hypothetical event log that I could view if I needed to look back to see what happened. In reality, that event log doesn't exist in an accessible way, and it's true that once the toast message times out, it's gone forever.
The log is just an optional added feature. The main point is for the current/last message not to disappear by itself, and to be displayed in a non-distracting and non-obstructive way.
As a thought experiment, how long should a toast remain on the screen? Ideally you want the user to have time to read it, but since you don't know how long it will take for them to glance up, and you don't know their reading speed, there isn't a safe bound.
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.
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.
MacOS and phones do this well, the toast is up for what feels like enough time to read it, but if you didn’t catch it, you can slide open the notifications ui and see all the previous ones for as long as you want.
There is no good answer, it's just not a good UI pattern for that reason.
> 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.
Agreed; a better solution would be to assume success and show these messages only if an error occured.
Agreed; a better solution would be to assume success and show these messages only if an error occured.
The absolute worst implementations of toasts are ones that actually block user interface elements which become invisible and un-clickable until the toast goes away.
Toasts that only appear for 500 ms are bad UX because the cognitive processing time of people varies widely, and they are incompatible with more people who have disabilities. Furthermore, they are hard to see on very large screens or when that corner is clipped on a desktop browser window that is partially off screen.
In android toasts are awful and pop over what I'm looking at. messages used to star wars ticker on the status bar which was out of the way and better
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
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
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...
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.
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.
In this specific example you do have an Undo button: the checkbox itself. The issue here is that the checkbox doesn’t match the exact state it’s supposed to represent: if you check it, for a few seconds it’s checked but the video is not yet saved; if you uncheck it it’s not unsaved until the toast appear. If you repeatedly check/uncheck it you don’t know in which state you end up.
> In this specific example you do have an Undo button: the checkbox itself.
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'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.
> 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
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.
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.
> That the same for every single checkbox in every single form on the Web.
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.
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.
"Until the next action taken" doesn't solve your "accident" scenario either, where you likely smashed multiple buttons.
I don't think a toast or any confirmation feedback mechanism is supposed to replace a log or undo list.
I don't think a toast or any confirmation feedback mechanism is supposed to replace a log or undo list.
> The issue here is that the checkbox doesn’t match the exact state it’s supposed to represent…
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.
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.
Yeah, I've encountered that in a few systems: I'm aware I accidentally just changed the wrong thing but I don't know which wrong thing, there are no clues. This is especially problematic when there's a chance nothing changed, but you can't be sure.
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?
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?
This is particularly annoying on Gmail, where sometimes while you type in the search bar, a few of your keypresses will trigger keyboard shortcuts instead.
Did you just archive or delete a couple of unread emails? You may never know!
Did you just archive or delete a couple of unread emails? You may never know!
[deleted]
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 ).
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 ).
I'd add one more scenario: when the UI element that would give feedback, normally, has been removed, yet you still want to show feedback.
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.
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.
A better UX is to show a confirmation in place. When you delete a task from the list - show a module in its place with a short message and the undo button. Showing a toast in a completely different part of the screen is hard to notice and hard to interact with as it's removed after a short delay. Also, if you delete more than 1 task quickly, toasts start stacking, and it becomes even less clear which one you want to undo.
I'm happy to look at your A/B testing and research on the subject, but I'm less interested in your unsupported opinions about what "better" UX is or how unmanageable multiple toasts become.
Classic case of "My own opinions didn't require evidence but to convince me otherwise requires research."
lol
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?
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?
[deleted]
So... still an opinion? You forgot to include the results of your extensive A/B testing and links to research on the subject.
Yes, a well tested and well researched opinion. Just like I'm sure your opinion was.
The difference is, I didn't say "Here's a better UX". I said "This is an appropriate use for the UX". I didn't back it up with testing because I wasn't saying anything that needed backing up. I wasn't making a value statement, or insisting on a quality of the UX; I just said that toasts were appropriate for certain functions - not that there was no better way to handle the UX.
You, on the other hand, absolutely did make a value judgement. You said "better". And okay! I'm fine with you having a better UX! I'd love to know more! Please, provide any information you have on why yours is better!
If you need more help deciphering the difference: I was arguing against the blog author's EXCLUSIVE argument ("actually, this is appropriate, so it's not that toasts are NEVER good UX"). You are arguing for your own EXCLUSIVE argument ("the good things about this way aren't available with your way"). If you don't understand why exclusive arguments merit more evidence than arguments for maintaining inclusion (as opposed to changing to be more inclusive), I'd recommend boning up on formal logic.
The difference is, I didn't say "Here's a better UX". I said "This is an appropriate use for the UX". I didn't back it up with testing because I wasn't saying anything that needed backing up. I wasn't making a value statement, or insisting on a quality of the UX; I just said that toasts were appropriate for certain functions - not that there was no better way to handle the UX.
You, on the other hand, absolutely did make a value judgement. You said "better". And okay! I'm fine with you having a better UX! I'd love to know more! Please, provide any information you have on why yours is better!
If you need more help deciphering the difference: I was arguing against the blog author's EXCLUSIVE argument ("actually, this is appropriate, so it's not that toasts are NEVER good UX"). You are arguing for your own EXCLUSIVE argument ("the good things about this way aren't available with your way"). If you don't understand why exclusive arguments merit more evidence than arguments for maintaining inclusion (as opposed to changing to be more inclusive), I'd recommend boning up on formal logic.
This is not a formal argument, it's a thread on a discussion forum.
If value judgments trigger you so severely, it could be healthier to log off and read a book instead.
In an informal conversation, it's common to voice an opinion and present an argument. It's also common for other participants to disagree and voice a different opinion.
Informal conversations can actually be wonderul, you should try!
If value judgments trigger you so severely, it could be healthier to log off and read a book instead.
In an informal conversation, it's common to voice an opinion and present an argument. It's also common for other participants to disagree and voice a different opinion.
Informal conversations can actually be wonderul, you should try!
lol
I can't tell if you actually believe that I'm somehow hyper-focused on this because I was able to scrawl out two paragraphs, or if you're just deflecting, but either way it's pretty funny!
I said a thing. You said a thing. I gave you honest and apathetic feedback. You're the one that got defensive about that. You could have left it there; you could have said "oh, I've got nothing formal, I'm just talking about case X, Y, and Z, as brought up in article W."; you could have done anything other than take it hard. Instead you got pissy about me not caring about your unsupported opinion (I make no value judgement on whether it's actually good or bad; just that it's unsupported).
I'm sorry that my immediate response, in informal conversation, is less charitable than you prefer. I don't have any interest in arguing about stuff that has accessible points of well-supported data. I prefer to argue about stuff like art and flavor and preference and anything that doesn't have some reference-able data to make one side or the other impractical to support. If you want to talk movies, or games, or food, I'm happy to volley back and forth about the "better" and "worse" things. But if you want to "argue" that you know of a way for me to do my job "better", I cannot stress this enough: I would LOVE to see your data. Because it will help me do my job better. It's not facetious; it's not smug; it's not a spit in your face. It's an honest offer for you to either provide something that does what you say (at least in your opinion!), or to leave this topic with me. There's nothing tempermental or nuerotically formalized about politely offering a path for the conversation, should it continue. You should try just ignoring the path if you don't want to walk down it.
I said a thing. You said a thing. I gave you honest and apathetic feedback. You're the one that got defensive about that. You could have left it there; you could have said "oh, I've got nothing formal, I'm just talking about case X, Y, and Z, as brought up in article W."; you could have done anything other than take it hard. Instead you got pissy about me not caring about your unsupported opinion (I make no value judgement on whether it's actually good or bad; just that it's unsupported).
I'm sorry that my immediate response, in informal conversation, is less charitable than you prefer. I don't have any interest in arguing about stuff that has accessible points of well-supported data. I prefer to argue about stuff like art and flavor and preference and anything that doesn't have some reference-able data to make one side or the other impractical to support. If you want to talk movies, or games, or food, I'm happy to volley back and forth about the "better" and "worse" things. But if you want to "argue" that you know of a way for me to do my job "better", I cannot stress this enough: I would LOVE to see your data. Because it will help me do my job better. It's not facetious; it's not smug; it's not a spit in your face. It's an honest offer for you to either provide something that does what you say (at least in your opinion!), or to leave this topic with me. There's nothing tempermental or nuerotically formalized about politely offering a path for the conversation, should it continue. You should try just ignoring the path if you don't want to walk down it.
You got it backwards. There is no way to argue about what music is "better". Or at least no productive way to do that.
When talking about UX, I am expressing an opinion based both on my experience as an engineer and as a user. In this case, I can state that something is better, at least in the sense that it's a more intuitive and an effective pattern.
If judgments like that trigger you - that's ok, I don't have to meet some unexpressed level of data-supported evidence.
> There's nothing tempermental or nuerotically formalized about politely offering a path for the conversation
Re-read your responses and imagine talking to someone in person with this level of nit-picking and animosity.
“You’re not wrong, Walter..." and so on.
When talking about UX, I am expressing an opinion based both on my experience as an engineer and as a user. In this case, I can state that something is better, at least in the sense that it's a more intuitive and an effective pattern.
If judgments like that trigger you - that's ok, I don't have to meet some unexpressed level of data-supported evidence.
> There's nothing tempermental or nuerotically formalized about politely offering a path for the conversation
Re-read your responses and imagine talking to someone in person with this level of nit-picking and animosity.
“You’re not wrong, Walter..." and so on.
lol
Thats one reason for them. The other is for "not important enough to block the user, but important enough to inform them of something". What was previously a popup with an 'ok' button is now a toast. Low friction, medium importance.
> 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 ).
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?
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?
If it's supposed to be a "modal operation", then it's supposed to complete before any of this becomes relevant. When that can't happen (e.g. because of an Internet hiccup), IMO the user should be able to take manual action to "minimize" (reversibly hide) the widget, but it shouldn't disappear until the operation is complete.
> it shouldn't disappear until the operation is complete
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.
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.
>but why?
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.
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.
> 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.
A toast notification doesn't preclude being able to recover state. Email applications still have an Outbox and Sent folder. 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.
A toast notification doesn't preclude being able to recover state. Email applications still have an Outbox and Sent folder. 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.
Another example related to the current action of the user, but outside the scope of the currently-viewed screen: inserting a USB stick, or some other hardware-related function.
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.
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.
> OS types of notification that the defunct Growl invented.
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)
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)
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)
[1] https://en.wikipedia.org/wiki/Toast_(food)
[2] https://en.wikipedia.org/w/index.php?title=Toast_(computing)
It's ironic that a person writing about poor communication paradigms didn't explain what "toast" means here.
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?
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?
It's just that it's a post made by a web developper for their web developper audience. Safe to assume they know what a Toast Notification is.
I’ve done a lot of web development and never heard the term. I even use them a lot but called them popup notifications or other terms. I’ve used lots of frontend toolkits that call these something else.
Pretty much every well-known UI library, including Bootstrap, Angular Material/MUI & Chakra UI, calls these Toasts.
Interesting... I am a longtime Bootstrap user, and they offer a large number of other things that can be configured for the same purpose- alerts, popovers, modals, etc.
I've never actually noticed the toasts component itself, but have done the same thing with other components. I wonder if the feature was added after I started using bootstrap ~14 years ago, and I mostly just kept using the components I was used to.
Looking at it, I don't see myself using it because of the 'dismiss' button. I don't like things that obscure the UI, or encourage unneeded extra interaction, when I can pass info to the user without doing that.
I've never actually noticed the toasts component itself, but have done the same thing with other components. I wonder if the feature was added after I started using bootstrap ~14 years ago, and I mostly just kept using the components I was used to.
Looking at it, I don't see myself using it because of the 'dismiss' button. I don't like things that obscure the UI, or encourage unneeded extra interaction, when I can pass info to the user without doing that.
Bah, you think you were confused? I thought it was about toasting, as in with drinks. (Yeah sure, "Are Bad UX" -- but since when is "Cheers!" a software metaphor? Weird AF.)
Seems like it could live among these:
> 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
> 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
It seems like they put a lot of effort into trying to create a coherent extended metaphor, yet it doesn't make any sense. You create a tap by putting bottles and casks together, and then it puts itself into a keg? Your own cellar is a prototype for someone else's keg?
The Homebrew nouns are one thing. It’s the verbs that trip me up: update/upgrade is different to everything else on the Mac but at least is familiar to me from Debian but then I mix up list, info, show etc.
the brew creator was just really into beer crafting.
I probably do the same with some of my passion projects without realizing it
I probably do the same with some of my passion projects without realizing it
Thanks! I pinned the second link to the top: https://news.ycombinator.com/item?id=41304011.
Would it be ok to assign you as the author of that comment? I don't want to take credit for your link.
Would it be ok to assign you as the author of that comment? I don't want to take credit for your link.
Yes that's fine for me :)
I'm sorry to say this, but I don't think it's fair that you (a moderator) should be allowed to pin comments to the top. There may be dozens of helpful links sharing or clarifying context in the discussion. The community can use the upvote feature to sort comments.
Exceptions might be made in cases of misinformation or abuse.
Exceptions might be made in cases of misinformation or abuse.
Don't be sorry - that's a great point!
I guess for me the "pin the comment" thing is a workaround for a limitation in the software that we haven't had a chance to fix it—that is, there should be a way in the standard HN UI to associate multiple links with a story (including the archive links that many users post into the threads). Whatever mechanism we build for that, it will certainly be community-driven in the sense that users will be the ones submitting alternative links, and perhaps voting on their relevance somehow. This is related to karma too, of course.
That doesn't resolve your objection, which I think is legit. But I wanted to share why I do that.
There are other forms of pinned comment too, such as the "if you're going to comment in this thread, please make sure you're follwing the site guidelines" admonishment that I sometimes put into threads on inflammatory topics.
I guess for me the "pin the comment" thing is a workaround for a limitation in the software that we haven't had a chance to fix it—that is, there should be a way in the standard HN UI to associate multiple links with a story (including the archive links that many users post into the threads). Whatever mechanism we build for that, it will certainly be community-driven in the sense that users will be the ones submitting alternative links, and perhaps voting on their relevance somehow. This is related to karma too, of course.
That doesn't resolve your objection, which I think is legit. But I wanted to share why I do that.
There are other forms of pinned comment too, such as the "if you're going to comment in this thread, please make sure you're follwing the site guidelines" admonishment that I sometimes put into threads on inflammatory topics.
One of my personal conventions on stories with many duplicate submissions is to try to list those sources within the first / main discussion.
Recent example: <https://news.ycombinator.com/item?id=41248551>
(I haven't hit on a standard notation for this though I've noted "other submissions" in some cases.)
Karma, schwarama.
Recent example: <https://news.ycombinator.com/item?id=41248551>
(I haven't hit on a standard notation for this though I've noted "other submissions" in some cases.)
Karma, schwarama.
[deleted]
Thank you! That did puzzle me, especially because I had pulled some bread out of a toaster just seconds before sitting down to read Hacker News this morning.
Where does the name toast come from anyway?
Toast "pops up" from the toaster when it's done.
In all of the years I've been dealing with "toasts", I never realized this until just now. I always thought it was some kind of weird reference to toasting with a drink or something.
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.
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.
That does make a certain amount of sense... much more sense than https://en.wikipedia.org/wiki/Toast_(honor) which for some weird, unexplainable reason my brain had decided was where the name came from...
It was originally the name of a popular CD burning application for the Mac. Only much later, following the discovery of bread, did the term become popular for describing a slice browned by radiant heat.
I assume based on this https://en.m.wikipedia.org/wiki/Toast_(honor)
> A toast is a ritual during which a drink is taken as an expression of honor or goodwill.
> A toast is a ritual during which a drink is taken as an expression of honor or goodwill.
> 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.
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.
OP completely missed the point of toasts. Some user actions can be
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.
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.
> So if you accidentally press something and suddenly the email is gone from your inbox, you want a toast with an undo button.
Why? If an email suddenly vanishes and you don't want that you don't need a popup to tell you what happened, you can just Ctrl-Z and the email comes back
Why? If an email suddenly vanishes and you don't want that you don't need a popup to tell you what happened, you can just Ctrl-Z and the email comes back
No, not for email. Tech illiterate people use email. They're not going to have the reflex to Ctrl+Z, but a toast with "undo" at least gives them the information that undoing is possible, even if they're not quick enough to click on it
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.
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?
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?
I think the slide left/right for sidebar is a nice UX, as long as the user knows about it, and as long as you don't go beyond 1 main + 2 sidebars.
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.
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.
I remember installing Snapchat one and immediately realizing how awful it was. Different corners had different functions. It needs to be illegal
Fully agree. IOS of course, is full of them, even on tablets where screen space is abundant.
I think most "toasts" (now I know the word for it!) are redundant and useless. I usually completely miss them. I think they are generally "harmless," but they should not be used to convey crucial information.
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.
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.
Apple's non-hotpath UX (and even UI) is incredibly bad. The entire experience configuring icloud and family sharing on a Mac is like entering another dimension with no relation to the surrounding OS.
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.
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.
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.
I like animating the checkbox most, but showing a loading symbol next to it is clearly also much better than the current behavior.
In the YouTube example, I don't think the last two options you mentioned would work very well.
In the YouTube example, I don't think the last two options you mentioned would work very well.
> is clearly also much better
I disagree. For a software developer, yes, because we understand a cut corner when we see one. But a user doesn't think like a software developer.
> I don't think the last two options you mentioned would work very well.
You're probably right about that. But I also think, loading icon wouldn't work better either. The messaging is vague in the first place.
I disagree. For a software developer, yes, because we understand a cut corner when we see one. But a user doesn't think like a software developer.
> I don't think the last two options you mentioned would work very well.
You're probably right about that. But I also think, loading icon wouldn't work better either. The messaging is vague in the first place.
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.
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.
In this case, this is a video game, it isn't meant to be productive, it is meant to be awesome, and an excessive number of toasts can be awesome, especially during an excessive event.
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.
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.
Hang on, there's a few inaccuracies here (I think, since I only played mainline Dragonflight but not Remix, but at a relatively sweaty level for a non-competitive m+ player)
> 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.
> 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.
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.
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.
I completely agree. Every time I open any Google product it takes me a good 60 seconds to figure out that the hamburger menu is not where I go to create a new sheet/doc/slides. And then I have to scan around the screen for another symbol that's on the complete opposite corner of the screen and tastefully hidden away. It's very frustrating. 95% of the time when I go to sheets.google.com I go there to create a sheet, and their information hierarchy prioritizes looking at existing sheets, then navigating to another product, and then everything else, and then finally creating a document.
> I think the actual issue is that Google makes bad UX often, and not toasts in general.
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.
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.
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)
- 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.
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 will say as someone with a limited visual field, toasts are very frustrating as they're almost always out of my field of view. Please keep indicators/notifications close to the thing that caused it.
Serious question…when saving a document on a mac, the only visual indicator that the save happened is the red “close” button loses an interior circle.
This is 10x more subtle than any toast.
Do you wish that were different? Or does that work for you?
This is 10x more subtle than any toast.
Do you wish that were different? Or does that work for you?
Saving, when instant, does not need to notify the user. Not every action needs to notify the user.
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"
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"
Do you have a video or screenshot of this? I don't daily drive a mac so I'm having trouble recalling (I also am not sure what you mean by saving a document, in which context?). But regardless, I don't think a toast would serve me better there, that doesn't mean that ux doesn't suck either :)
Aha fully-sighted and I've never noticed this... 15 years of mac use.
The pro will train himself to whatever good or bad thing you'll throw at him. The point is not about identifying generalization that works everywhere, it's just to have enough care for making the good choices at the right places.
Just because somebody will put up with it doesn't make it a good choice. That rationalization has been used to justify a lot of awful decisions and awful software.
I actually think the opposite. Toasts in my professional tools are even more objectionable to me. They're never where I'm concentrating, and by the time I realize one is happening and look at it, it's either already gone or is saying something trivial.
The end result is usually that I've been distracted for no reason.
In a casual app, none of this matters as much.
The end result is usually that I've been distracted for no reason.
In a casual app, none of this matters as much.
Classic. People that are bad at UX design using the “pro app” catch-all to justify all sorts of bad decisions.
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.
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.
You have also used a catch-all, but yours was personal and rude. The rest of your point is useful…just please remember that there are real people typing words into this app.
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.
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.
> bad at UX design using the “pro app” catch-all to justify all sorts of bad decisions
No, pro apps actually have completely different UX requirements.
In a pro app, the UX requirement is to be able to perform actions QUICKLY and RELIABLY, meaning it works the same way every time with a minimal number of steps.
This leads to "cluttered" interfaces with lots of information, because this way actions can be performed quickly AND results/data are always in the same place so it's reliable. Take an IDE with multiple panels with output going in/out. Quick to see what you need to, everything is sectioned off so you know right where to look, and everything is one or two clicks away.
However, casual apps have almost opposite requirements! They need to be non-intimating and simple. Simple is at odds with quick to use IF the use case is complex. Simple and quick to use can ONLY coexist in a scenario that is simple in it of itself, i.e. not a pro app but a simple app.
No, pro apps actually have completely different UX requirements.
In a pro app, the UX requirement is to be able to perform actions QUICKLY and RELIABLY, meaning it works the same way every time with a minimal number of steps.
This leads to "cluttered" interfaces with lots of information, because this way actions can be performed quickly AND results/data are always in the same place so it's reliable. Take an IDE with multiple panels with output going in/out. Quick to see what you need to, everything is sectioned off so you know right where to look, and everything is one or two clicks away.
However, casual apps have almost opposite requirements! They need to be non-intimating and simple. Simple is at odds with quick to use IF the use case is complex. Simple and quick to use can ONLY coexist in a scenario that is simple in it of itself, i.e. not a pro app but a simple app.
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.
Games can be the epitome of good UI feedback.
re: civ6, ime there are persistent and 1-turn transient notifications. if you deal with something related to a persistent notification, the notification doesn't go away. meanwhile many of the 1-turn transient messages have relevance well past that one turn.
so yeah, I get what you're saying but it may not be the best example
so yeah, I get what you're saying but it may not be the best example
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.
* 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.
I was also amused by a UX complaint on a site that is totally borked in a non-obvious way on Firefox.
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.
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.
> it shows the first frame of the 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.
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.
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?
Debouncing is a known development tool for most non-immediate actions. It's related UI concept of locking individual UI elements is also well understood by many users (not by that technical name, but by "it's working on my action" kind of understanding).
> 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...
> 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...
Is this an LLM? :) The question was rhetorical. Both of these proposals have problems. But the main issue is that the author of the article is missing an angle of toasts as a UX concept.
From my perspective there was nothing rhetorical about that question as I occasionally encounter it as a serious thing. Some colleagues really do not want optimistic UI events. Some swear by them.
I don’t have any strong feelings one way or another as long as there is proper inline feedback.
I don’t have any strong feelings one way or another as long as there is proper inline feedback.
Came here for exactly this, the post is proposing a solution while only understanding one half of the problem.
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.
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.
The dismissal should communicate to the user in a way that indicates the process will continue without the view.
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.
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.
It's hard to agree/disagree on UX without all the application and domain context, but I do feel like toasts are valuable when you are communicating information to the user that is not tied to a fixed UI location/time, but do not want to force interaction (like you do with a modal).
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 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.
Yeah, I'm not a huge fan of toasts. And I generally agree with the sentiment that it would be better to have indicators closer to where the action was taken. But, I'm not sure how else I would approach this? I think the main benefit is the catchall approach allows the team to focus on other customer problems.
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?
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?
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.
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.
While we're at it let's remove the jargon from other trades, too.
"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.
"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.
I get your reasoning but still why use food terms for jargon in UX instead of something else.
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.
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.
Why does it matter to you where the jargon came from? Why are vaguely shape-related jargon and military-derived jargon and acronyms okay but you draw the line at toast?
I would argue that FUBAR, P-trap, Dequeue, HALO are going to have a less likelihood of a context collision than borrowing an existing word that is ubiquitous in society.
For example in Google
"toast"
"toast menu"
"toast ux"
All yield different results
However "p-trap" gets you a narrowed list of results
For example in Google
"toast"
"toast menu"
"toast ux"
All yield different results
However "p-trap" gets you a narrowed list of results
"Platoon" turns up military answers until I specify traffic. And I'm actually not at all sure what meaning of "HALO" you're referring to—it must be jargon not in my vocabulary, but for me it refers to a thing angels have and to a video game.
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.
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.
High Altitude Low Open, of a parachute approach.
Hold on, how is "hero" a food metaphor? I mean, I understand that there are some regional dialects that use that name for a "submarine" sandwich (and there are many other names for it), but I can't fathom how a full-screen image at the top of a website has any metaphorical connection to that. To me, that makes even less sense than the idea that such an image somehow is supposed to do a heroic job of advocating for whatever is the main point of the page (unironically my prior mental model!).
It's not a food metaphor, nor is it about displaying something heroic, although that's much closer. "Hero image" comes from "hero props" which "are the more detailed pieces intended for close inspection by the camera or audience. ... The name refers to their typical use by main characters in a production." [0]
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_...
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_...
Off topic, but: what food (and indeed what UI element) is "heroes"?
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.
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.
To a backend developer, the appearance of the "notification widget" doesn't matter.
To a front-end dev or designer, it does. That's who the jargon is for.
To a front-end dev or designer, it does. That's who the jargon is for.
> As a backend developer this stuff is mind-boggling, just call it "notification widget", or a "confirmation widget" etc.
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.
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.
Rather than trying to solve that communication problem, why not just label the menu with an actually descriptive icon? I assume that this icon is supposed to convey "there is a menu under here", via the horizontal bars abstractly representing menu items. But to me that's a vastly less clear visual language than even MacOS 6 offered me in the 80s, even limited to 16x16 black-and-white icons.
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.
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.
I’ve been a developer (primarily back end) and I never heard the term toast until now. Perhaps I’m just simple, or maybe I stopped paying attention after “hamburger menu.” I’m probably too old to hang out with the cool kids anymore.
As a developer who started with jQuery and then Backbone.js it seems like frontend dev has become very rich but at the same time has developed some weird esoteric rituals and practices which don't seem to go with conventional software engineering.
I'm curious as to how you're defining 'conventional software engineering' here; can you give some examples of things that are not conventional software engineering in the front end?
Front end is more specific than conventional – it has a graphical output, and is thus closer to 2D game development than to the “conventional” data structures and algorithms way of programming.
I was definitely confused when I first learn that 'chip' elements in material design look like french fries.
> 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.
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.
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
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
HATEOAS is more about a standard, discoverable and consistent way to navigate around resources in a RESTful fashion. Which is nice, even if it didn't really catch on to a large degree. I think that's somewhat orthogonal to he point you're making.
I think your point is good though, that an ephemeral toast message is a cheap way to avoid having to manage and expose the underlying state. Exposing that via a HATEOAS REST API would be even better!
I think your point is good though, that an ephemeral toast message is a cheap way to avoid having to manage and expose the underlying state. Exposing that via a HATEOAS REST API would be even better!
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.
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.
While I'm in favour of asynchronous feedback like this, placing toasts nowhere near the button you've clicked is confusing when you get to bigger monitors. A toast in the bottom left on a large, widescreen 4k monitor can literally be half a meter away from the place you clicked, so the toast might as well not have been there. I myself have lost the progress notification for a file copy in KDE because it was placed all the way in the bottom right corner, and my screen isn't even _that_ big.
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).
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).
Right, so the issue is placement, not really toasts. I would prefer the pop-over you mention to toasts, but I definitely don't want to lose asynchrony.
this seems like an example of a mobile interaction pattern being blindly applied to desktop site
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.
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.
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.
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.
> 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.
To me, the context is the thing I just did. I can't say I'm particularly confused with toasts. Without them, I find myself looking for confirmation on page more often.
Also to the user, they happen instantaneously. Who cares if the fade-in is slow in computer time?
To me, the context is the thing I just did. I can't say I'm particularly confused with toasts. Without them, I find myself looking for confirmation on page more often.
Also to the user, they happen instantaneously. Who cares if the fade-in is slow in computer time?
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?
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?
I think they are called toasts because they pop up from the bottom, similar to a piece of toast popping out of a pop-up toaster oven.
I used these to display errors in an internal web app once, which was a major mistake. The users almost never saw them and when they did they didn't see them long enough to be able to communicate what the message said, often trying to paraphrase.
I agree they are bad UX for most things.
I used these to display errors in an internal web app once, which was a major mistake. The users almost never saw them and when they did they didn't see them long enough to be able to communicate what the message said, often trying to paraphrase.
I agree they are bad UX for most things.
> The users almost never saw them and when they did they didn't see them long enough to be able to communicate what the message said, often trying to paraphrase.
Theres an art to writing terse copy for the toast, and picking durations that make sense. I think this is likely more a poor application of the pattern rather than the pattern itself being bad.
Theres an art to writing terse copy for the toast, and picking durations that make sense. I think this is likely more a poor application of the pattern rather than the pattern itself being bad.
It’s extremely easy to get the “art” wrong. In my case, I didn’t always know what the errors were because they were returned from 3rd party API’s and many of them the application had never seen before. If there were a proper log somewhere, maybe, but toasts are very easy to use poorly.
Well, its simple to not just toast a string directly from a third party you dont control : D
I think it's called a toast because it (usually) appears by jumping from one of the edges, like a piece of toast jumps from the toaster.
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
- 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.
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
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
It’s almost like we need a semantic level where the developer says “I want to send the use this small transient text message” and then a presentation level where a user can decide which method of presenting this information works best for them…
Email is nice.
>But I don't want so many mails in my inbox
Then write mail rules. It's really easy and personally I couldn't survive at work without them. That's a big part of why it's nice: You can choose how it works unlike practically everything else these days.
>But I don't want so many mails in my inbox
Then write mail rules. It's really easy and personally I couldn't survive at work without them. That's a big part of why it's nice: You can choose how it works unlike practically everything else these days.
That ties the app to be usable only with network access (which is fine for, e.g., Youtube, but not for all apps!), and also includes a highly variable lag.
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.
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.
Status bars are a far superior option for this sort of thing than toasts. As another commenter said, toasts appear to be a UX compromise that was necessitated by mobile (where a status bar is tough), but has sadly infected desktops as well.
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.
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...
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.
Toasts which incorporate movement such as slide up are far more noticeable compared to fade in toasts since human vision is far better at recognizing movement. Even on large screens it is pretty good.
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?
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'd speculate that their overuse comes from convenience of displaying any message by throwing in a `showToast("Foo!")` opposed to altering each UI component to show the relevant feedback.
That cuts both ways IMO. At least with a toast system I know where feedback appear on a per app basis (or website or whatever). Imagine if every screen, view, list entry, checkbox had its own way of displaying feedback. It would be an enormous amount of overhead.
Toasts should be used if there is no direct relation to or interaction with a visible UI element: notification, heavily asynchronous processes, out-of-view modifications.
> Are toasts overused?
I think so, yes.
> In which cases do you use them in your own apps?
I don't. But I don't write mobile apps (where they make more sense) for distribution, so they don't address any need my applications have.
I think so, yes.
> In which cases do you use them in your own apps?
I don't. But I don't write mobile apps (where they make more sense) for distribution, so they don't address any need my applications have.
CRConrad(1)
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.
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.
> 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.
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 :)
I like error messages that I can copy-paste without worrying that they might disappear too fast, or worse, when I click on it. Also error messages that I can screenshot to show someone else without having to hurry because it might disappear after 50ms.
Always = in Material design
https://m3.material.io/components/snackbar/guidelines
https://m3.material.io/components/snackbar/guidelines
They even acknowledge the limitations and problems with Toasts:
> 1. Add inline feedback
>
> Information in auto-dismissing snackbars must also be communicated using another accessible method inline or near the action that triggered the snackbar.
> 1. Add inline feedback
>
> Information in auto-dismissing snackbars must also be communicated using another accessible method inline or near the action that triggered the snackbar.
Snackbars aren't toasts
do you have a source for that? I understand that Toast is the name given in Android
> Note that Snackbars are preferred for brief messages while the app is in the foreground.
https://developer.android.com/reference/android/widget/Toast
https://developer.android.com/reference/android/widget/Toast
That's the Android widget, not material design which is used for YouTube's UI
I fear we're talking past each other. Material Design doesn't have a Toast.
Material Design Snackbars aren't toasts:
* Snackbars are local, toasts are global
* Toasts don't receive focus, snackbars can (via the optional action)
* Toasts auto-dismiss. This is optional for snackbars
* Snackbars can explicitly be dismissed early by a user
Material Design Snackbars aren't toasts:
* Snackbars are local, toasts are global
* Toasts don't receive focus, snackbars can (via the optional action)
* Toasts auto-dismiss. This is optional for snackbars
* Snackbars can explicitly be dismissed early by a user
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.
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.
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.
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?
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.
Reminds me of how changing volume / brightness on macOS hides the damn subtitles.
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.
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.
- 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.
I don't think that's a convincing argument unless you are a tiny company that has to optimize for development time. You can also wonder why the frameworks you are using make this hard, because it's a pretty common to want feedback close to where the action happens.
I don't know anyone who isn't optimising for development time in some way. That said, most frameworks don't provide any worthwhile error handling infrastructure, and it's a problem.
In a Jetpack Compose app I wrote, I created generic "error barrier" components, so that error messages display over relevant parts of the app, with just a few lines each time, timeouts included. I think this is the best approach, easy for developers and informative for users. Too many apps just ignore errors.
In a Jetpack Compose app I wrote, I created generic "error barrier" components, so that error messages display over relevant parts of the app, with just a few lines each time, timeouts included. I think this is the best approach, easy for developers and informative for users. Too many apps just ignore errors.
I meant optimizing for developer time over usability in the context of the story, that mostly shows products from Google. Google being the opposite of a small development team that could be forced to choose developer time over usability.
In my experience the overwhelming majority of teams out there are understaffed (especially when it comes to good and productive professionals) so your example is the rule, not the exception.
I didn't say it was hard, it's just very nice to not have a bunch of extra error / success code in all of your components that make async requests.
Trade offs, as usual.
Trade offs, as usual.
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.
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
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'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 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)
- 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!)
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.
Result of promo-driven culture
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!
This is such a great callout.
We have to acknowledge that conversation around this is also platform dependent.
We have to acknowledge that conversation around this is also platform dependent.
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.
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.
I don't think there's any feature there with the video jumping back. That purely seems to be a bug where it fails to resume the connection to the server to continue filling the buffer. It seems to hit the end of what is buffered and then refresh, causing it to jump back to some last saved position.
This doesn’t explain why it does that after you jump elsewhere, why it does that only after several hours and why it started recently. This “some last saved position” doesn’t persist when you refresh and is always exactly -20s from where you paused. It’s not a single event I got my observations from.
[deleted]
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.
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.
[deleted]
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
+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."
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."
[deleted]
[deleted]
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.
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.
There's nothing more infuriating than going to click undo and the toast disappears.
It's the most annoying thing I felt when I using software too. So in my own project, I tend to just keep the message open and wait for user to decide what do to with it, but then that's not a toast anymore.
I don't think designers should put anything interactive in an arbitrarily timed interface aside from "Dismiss". A toast is the best when it's displaying what is currently going on, not as a pop up dialog box.
The best design for Undo I think is to make it a dedicated button, like the one in the text editors. When user clicked "Archive", a Toast pop up and displays message "Archiving N entries, please wait" and then change it to "N entries archived. You can press Control+C or click [Undo Icon] to undo if that was a mistake" then the Undo button lights up.
Also, IMO the message format "Archiving N entries, please wait" should be a standard, it tells the user in a clear way 1) what the software is doing, and 2) what should I the user do. On the other hand, the message "Conversation archived" don't really provide the same value, since user already saw it happened.
I don't think designers should put anything interactive in an arbitrarily timed interface aside from "Dismiss". A toast is the best when it's displaying what is currently going on, not as a pop up dialog box.
The best design for Undo I think is to make it a dedicated button, like the one in the text editors. When user clicked "Archive", a Toast pop up and displays message "Archiving N entries, please wait" and then change it to "N entries archived. You can press Control+C or click [Undo Icon] to undo if that was a mistake" then the Undo button lights up.
Also, IMO the message format "Archiving N entries, please wait" should be a standard, it tells the user in a clear way 1) what the software is doing, and 2) what should I the user do. On the other hand, the message "Conversation archived" don't really provide the same value, since user already saw it happened.
[deleted]
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?
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.
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.
[deleted]
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”.
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
* When forced down the users throat and hijacked by the marketing department
pet peeve: this blog seems not to have an RSS feed.
Created one for you!
https://api.feedless.org/f/c5f5ae53-16f1-4f67-b45f-1c3e8a92d...
https://api.feedless.org/f/c5f5ae53-16f1-4f67-b45f-1c3e8a92d...
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.
And it's partly because the screen clips don't play in firefox - it seems you have to scroll past them, then back up, then click, or something.