41–50 of 401 posts
> The "Undo" button in the toast is unnecessary because the user can just click the checkbox again I disagree with this part, at least in general. Having an Undo is very good if you have accidentally clicked somewhere and don't know precisely where, and you don't know the application well enough to easily undo based on the message alone.
As a backend developer this stuff is mind-boggling, just call it "notification widget", or a "confirmation widget" etc.
Try explaining what toast is to an Indian subcontractor who has never eaten toasted bread in their life and then apply that to the UX usecase.
Removing these terms will also improve accessibility and understanding for junior developers entering the frontend world.
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 t…
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.
For undo-able actions, toasts disappearing too fast or colliding with other toasts badly is a real problem. An affordance to see the toast history with non-disappearing undo buttons may be more to implement but for a lot of apps, a viewable and editable history combined with toasts is a much better UX than either system on its own.
> But by archiving the email, the email disappears from the list, which already implies the action was successful.
> In this example, the button already includes a confirmation so the toast is entirely unnecessary.
I vehemently disagree with the idea that just because you're already communicating something one way it's bad UX to include another way of communicating the same thing at the same time. Redundancy in communication is a feature, not a bug, and it's present in all human languages. It ensures that even in less than ideal conditions the message still gets through.
In the case of toasts, having a single, standardized way of communicating the status of all actions (and if possible providing the undo) allows a user to quickly pick up on the pattern. Extra indicators closer to the action can be valuable too, but it's when they're paired with the toast that their meaning becomes entirely clear. To remove the toast in favor of a bunch of specific indicators is to force your user to learn several different ways of saying "it's done now" entirely from context (many of which will be small and subtle as in the examples given). This might work fine for you and me but isn't great for, say, the elderly or the vision impaired or children.
Unless they're actually getting in the way, toasts aren't bad UX, they're redundant UX, and a UX designer shouldn't be striving to optimize away redundancy.
His solution ignores the undo component of the toast. Simply adding it back to the playlist is not a solution as that reorders it in the playlists. Instead, undo puts it back into the playlist where it was. When you have longer play lists, this becomes even more critical.
I'd much prefer a consistent way of interact than a bespoke unique way of using every UI component. Consistency and correctness versus creativity and confusion.
Earlier quoted context omitted.
It’s almost like we need a semantic level where the developer says “I want to send the use this small transient text message” and then a presentation level where a user can decide which method of presenting this information works best for them…
Email is nice. >But I don't want so many mails in my inbox Then write mail rules. It's really easy and personally I couldn't survive at work without them. That's a big part of why it's nice: You can choose how it works unlike practically everything else these days.