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 ).
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.
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.
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.
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?
Yes, a well tested and well researched opinion. Just like I'm sure your opinion was.
The difference is, I didn't say "Here's a better UX". I said "This is an appropriate use for the UX". I didn't back it up with testing because I wasn't saying anything that needed backing up. I wasn't making a value statement, or insisting on a quality of the UX; I just said that toasts were appropriate for certain functions - not that there was no better way to handle the UX.
You, on the other hand, absolutely did make a value judgement. You said "better". And okay! I'm fine with you having a better UX! I'd love to know more! Please, provide any information you have on why yours is better!
If you need more help deciphering the difference: I was arguing against the blog author's EXCLUSIVE argument ("actually, this is appropriate, so it's not that toasts are NEVER good UX"). You are arguing for your own EXCLUSIVE argument ("the good things about this way aren't available with your way"). If you don't understand why exclusive arguments merit more evidence than arguments for maintaining inclusion (as opposed to changing to be more inclusive), I'd recommend boning up on formal logic.
This is not a formal argument, it's a thread on a discussion forum.
If value judgments trigger you so severely, it could be healthier to log off and read a book instead.
In an informal conversation, it's common to voice an opinion and present an argument. It's also common for other participants to disagree and voice a different opinion.
Informal conversations can actually be wonderul, you should try!
lol
I can't tell if you actually believe that I'm somehow hyper-focused on this because I was able to scrawl out two paragraphs, or if you're just deflecting, but either way it's pretty funny!
I said a thing. You said a thing. I gave you honest and apathetic feedback. You're the one that got defensive about that. You could have left it there; you could have said "oh, I've got nothing formal, I'm just talking about case X, Y, and Z, as brought up in article W."; you could have done anything other than take it hard. Instead you got pissy about me not caring about your unsupported opinion (I make no value judgement on whether it's actually good or bad; just that it's unsupported).
I'm sorry that my immediate response, in informal conversation, is less charitable than you prefer. I don't have any interest in arguing about stuff that has accessible points of well-supported data. I prefer to argue about stuff like art and flavor and preference and anything that doesn't have some reference-able data to make one side or the other impractical to support. If you want to talk movies, or games, or food, I'm happy to volley back and forth about the "better" and "worse" things. But if you want to "argue" that you know of a way for me to do my job "better", I cannot stress this enough: I would LOVE to see your data. Because it will help me do my job better. It's not facetious; it's not smug; it's not a spit in your face. It's an honest offer for you to either provide something that does what you say (at least in your opinion!), or to leave this topic with me. There's nothing tempermental or nuerotically formalized about politely offering a path for the conversation, should it continue. You should try just ignoring the path if you don't want to walk down it.
You got it backwards. There is no way to argue about what music is "better". Or at least no productive way to do that.
When talking about UX, I am expressing an opinion based both on my experience as an engineer and as a user. In this case, I can state that something is better, at least in the sense that it's a more intuitive and an effective pattern.
If judgments like that trigger you - that's ok, I don't have to meet some unexpressed level of data-supported evidence.
> There's nothing tempermental or nuerotically formalized about politely offering a path for the conversation
Re-read your responses and imagine talking to someone in person with this level of nit-picking and animosity.
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.
> 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?
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.
> 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.
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.
> 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.
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.
> 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)
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 ).