[julienmarie]

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

[catapart]

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.

[roninorder]

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.

[catapart]

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.

[Spivak]

Classic case of "My own opinions didn't require evidence but to convince me otherwise requires research."

[catapart]

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?

[roninorder]

So... still an opinion? You forgot to include the results of your extensive A/B testing and links to research on the subject.

[JamesSwift]

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.

[peeters]

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

[zahlman]

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.

[peeters]

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

[zahlman]

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

[peeters]

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

[creeble]

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.

[sureIy]

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