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.
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?
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.
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!
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.
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.
“You’re not wrong, Walter..." and so on.
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?
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.
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.
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.
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 ).