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.