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

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.

oh, so a notification without priority?

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.

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

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.

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.

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.

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.

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

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

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

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

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.

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.