Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Toasts are bad UX

maxschmitt.me

Post reply on HN
Print view View original

161–170 of 401 posts

Re: Toasts are bad UX

#161

Post by ziml77 »

wruza wrote: post #129

Taking youtube as an example is like taking a dead horse to a race. Youtube is an utter garbage ux-wise, both in bugs and features. Even fringe porn tubes are 10x more competent than youtube ui team. Their latest “addition” was rewinding a video after a long pause. You watch a video, pause it at t=1:24:57 and go to sleep. Next day you start the video again and it goes for a while from t to t+n (depends on the buffere…

I don't think there's any feature there with the video jumping back. That purely seems to be a bug where it fails to resume the connection to the server to continue filling the buffer. It seems to hit the end of what is buffered and then refresh, causing it to jump back to some last saved position.

Re: Toasts are bad UX

#162

Post by CRConrad »

hombre_fatal wrote: post #145
lolinder wrote: post #59

Earlier quoted context omitted.

I disagree on that—in the YouTube example specifically this isn't necessarily a problem, but the toast serves a valuable purpose in the archive in that it tells you again which button it was that you pressed. There have been countless times in cases like that where the toast has saved me and allowed me to undo a misclick. I can see the argument that there are certain places where people use toasts that are unnecessar…

Toasts also give you a good place to put other shortcuts like “Item updated. [View item]” that make it much easier to act on state changes, like navigate to sensible places to view / react to those changes.

> Toasts also give you a good place to put other shortcuts like “Item updated. [View item]” that make it much easier to act on state changes

Not if they go away, and take their “[View item]” button with them, before you've had time to read the notification, decide if you want to click the button, and actually get your cursor there to click it.

Which they usually do. So nyaaah, dubious benefit.

Re: Toasts are bad UX

#163

Post by lolinder »

datavirtue wrote: post #158
hombre_fatal wrote: post #145

Earlier quoted context omitted.

Toasts also give you a good place to put other shortcuts like “Item updated. [View item]” that make it much easier to act on state changes, like navigate to sensible places to view / react to those changes.

All of that is inacessible.

How so?

Re: Toasts are bad UX

#164

Post by lolinder »

CRConrad wrote: post #162
hombre_fatal wrote: post #145

Earlier quoted context omitted.

Toasts also give you a good place to put other shortcuts like “Item updated. [View item]” that make it much easier to act on state changes, like navigate to sensible places to view / react to those changes.

> Toasts also give you a good place to put other shortcuts like “Item updated. [View item]” that make it much easier to act on state changes Not if they go away, and take their “[View item]” button with them, before you've had time to read the notification, decide if you want to click the button, and actually get your cursor there to click it. Which they usually do. So nyaaah, dubious benefit.

So there are badly implemented toasts that have bad UX. That's not the same thing as the whole concept being bad.

Re: Toasts are bad UX

#165

Post by CRConrad »

mannykannot wrote: post #87
cowsandmilk wrote: post #57

Earlier quoted context omitted.

The unfortunate thing is they aren’t communicating the same thing. Taking the YouTube example, the checkboxes are 100% optimistic while the toast notification indicates that the request to the backend that was fired off asynchronously was successful. With the archive message example, it is the same thing. The message is removed from the list optimistically and the toast message is representing that the message was ac…

Fair enough, but when they are not communicating the same thing, there are no grounds for objecting to them on the basis of redundancy. The problem with notification only of failure is that one is left uncertain about success, though I would agree that striking a balance between distraction and uncertainty is difficult.

> The problem with notification only of failure is that one is left uncertain about success

But that's less a problem with getting notified or not, and more a problem with software not doing what you've told it to do.

Re: Toasts are bad UX

#166

Post by berkes »

adamc wrote: post #155
lolinder wrote: post #46

I'm not convinced. Most of the argument seems to be that redundant UX is bad UX: > 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…

No, they're bad. Messages that are on the periphery of my vision/attention (imagine a widescreen monitor) are actively confusing. I'm working on THIS problem here and something flashes up over there. Half the time, as I refocus to read this annoying intrusion, it disappears. It's bad UX. Put your damned messages where my attention has already been directed to BY YOUR UI .

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.

Re: Toasts are bad UX

#167

Post by pc86 »

lolinder wrote: post #46

I'm not convinced. Most of the argument seems to be that redundant UX is bad UX: > 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…

> > But by archiving the email, the email disappears from the list, which already implies the action was successful.

Yeah this in particular bothers me. Someone that knows UI and UX should also know you can absolutely remove something on the front-end without a corresponding action on the back-end. If I click archive and the email disappears, that doesn't mean the back-end call succeeded or has even been made. How many times do you click move/delete/whatever in an app, the thing moves or disappears then a second later pops right back in? These things happen and the subsequent alert that it was actually successful is a good thing in my opinion.

Re: Toasts are bad UX

#169

Post by abirch »

JamesSwift wrote: post #117
cowsandmilk wrote: post #57

Earlier quoted context omitted.

The unfortunate thing is they aren’t communicating the same thing. Taking the YouTube example, the checkboxes are 100% optimistic while the toast notification indicates that the request to the backend that was fired off asynchronously was successful. With the archive message example, it is the same thing. The message is removed from the list optimistically and the toast message is representing that the message was ac…

I mentioned this in another comment, but the whole reason the archive is able to be optimistic is partially because they offer the undo via toast. Otherwise its likely they would add an 'are you sure' plus a loading-state when doing these "semi-destructive" actions.

I've accidently archived something only to realize it when the toast pops up. I'm grateful for the toast instead of having the 'are you sure' like you mentioned. It's a nice compromise.

Re: Toasts are bad UX

#170

Post by peeters »

julienmarie wrote: post #38

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

Post reply on HN