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.
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.
> 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.
I agree. If it's available, I always appreciate a toast + notification tray combo where you get non-blocking feedback on successes but you can also keep track of any past messages.
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.
- 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.
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?
> 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 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.
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.
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.
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.
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.
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.
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.
> 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.
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
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.
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.
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.
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).
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
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.
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.
> 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.
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.
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)
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.
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.
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.
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.
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.
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.
> 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.
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.
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.)
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.
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.
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.
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.
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
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.
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.
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.
> 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.
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...
> 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!
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.
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.
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.
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.
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.
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).
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
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.
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.
> > 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.
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."
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
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.
> 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.