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

171–180 of 401 posts

Re: Toasts are bad UX

#171

Post by everybodyknows »

marcodiego wrote: post #53

There things worse than toasts: hidden slide panels. They are basically hidden toasts that are necessary for some actions and are completely unintuitive, unfindable and undiscoverable. My worst experience was with waze using the cellphone of someone else; I had to do something (don't remember what) and just stared at the screen (like a retard) trying to guess what I had to do; the person eventually got the phone, sli…

Fully agree. IOS of course, is full of them, even on tablets where screen space is abundant.

Re: Toasts are bad UX

#172

Post by CRConrad »

sebtron wrote: post #76

For anyone as confused as I was, this article is not about toasted bread [1], but about a type of UI widget [2]. [1] https://en.wikipedia.org/wiki/Toast_(food) [2] https://en.wikipedia.org/w/index.php?title=Toast_(computing)

Bah, you think you were confused? I thought it was about toasting, as in with drinks. (Yeah sure, "Are Bad UX" -- but since when is "Cheers!" a software metaphor? Weird AF.)

Re: Toasts are bad UX

#173

Post by michaelmrose »

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.

Should complex websites have a notification center where you can look at prior notifications? Would this be alike enough to existing desktop metaphors to be easily recognizable or simply confusing.

Maybe your browser should could have an icon for same instead making it more standardized across different sites.

Re: Toasts are bad UX

#174

Post by kccqzy »

CRConrad wrote: post #165
mannykannot wrote: post #87

Earlier quoted context omitted.

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.

That's the problem of whether the developer and the user have the same expectation of the max duration or timeout of an action. For example a developer might default all backend actions to have a timeout of 30 seconds. But as a user, if the action succeeds quickly (the usual case) I want to immediately see a confirmation of that. I don't want to wait 30 seconds just to see no notification about any failure.

Re: Toasts are bad UX

#175

Post by bigstrat2003 »

cynicalpeace wrote: post #100
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…

I totally agree with you... this is why Java being so verbose is actually not terrible either, lmao come after me

Honestly I think the perennial "Java is too verbose" complaints are completely overblown, and say more bad about the person complaining than the language.

Re: Toasts are bad UX

#176

Post by h1fra »

Toast are used for two reasons:

- An action has a destructive operation that you can't easily undo because the main button has disappeared (i.e: delete, reset, confirm a popup, etc.)

- Displaying a message would break the UI somehow (i.e: error message in a list, near a button in nav bar, in a tight UI, etc.)

I honestly don't feel like they are the best, and most of the time they are useless, but from time to time they are handy.

Re: Toasts are bad UX

#177

Post by Blot2882 »

Spivak wrote: post #157

The number of people and voracity that toasts are being defended in this thread is quite surprising given how terrible of a UI element they are. They don't exist anywhere in the document hierarchy so users have to mentally piece together what they're connected to, they carry no context, and they happen long (in computer time) after the action that that caused them. Toasts are a solution to "I did something async and…

> They don't exist anywhere in the document hierarchy so users have to mentally piece together what they're connected to, they carry no context, and they happen long (in computer time) after the action that that caused them.

To me, the context is the thing I just did. I can't say I'm particularly confused with toasts. Without them, I find myself looking for confirmation on page more often.

Also to the user, they happen instantaneously. Who cares if the fade-in is slow in computer time?

Re: Toasts are bad UX

#178

Post by JamesSwift »

ryandrake wrote: post #146
JamesSwift wrote: post #117

Earlier quoted context omitted.

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.

You can offer Undo via things other than toasts, though. In fact, I wish more software offered Undo--the Undo feature has kind of gone out of fashion since the early 2000s. You should be able to Undo anything (and follow the Undo chain back through many past actions). We somehow lost this ability from software.

For sure you can, but a toast is a tool in the toolbox. When it makes sense to use it, it definitely justifies its existence as a tool to keep around.

Re: Toasts are bad UX

#179

Post by jdiff »

lolinder wrote: post #163
datavirtue wrote: post #158

Earlier quoted context omitted.

All of that is inacessible.

How so?

Screen reader's probably not going to catch a transient element unless you just happen to stumble across it within that narrow window. Slow reader for whatever reason? Hope you don't take too long, or hope that toast wasn't actually important/actionable for you.

Re: Toasts are bad UX

#180

Post by nativeit »

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 .

The inevitable tradeoff here is having a somewhat standardized location for notifications versus allowing them to appear arbitrarily determined by the developer’s notion of where they are ostensibly drawing your attention. Maybe that’s worthwhile, but I think there are going to be a lot of cases where the ideal location is ambiguous, or where devs have an idea for where your attention will be that’s not always correct, or where bad actors exploit this flexibility to make it look like something it isn’t in an effort to trick users. I don’t know the right answer to what might be best, but I tend to think that standardized features should be preferred when in doubt.
Post reply on HN