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.

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

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.

This sounds like something the browsers could standardize.

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.