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

361–370 of 401 posts

Re: Toasts are bad UX

#361

Post by JamesSwift »

seanmcdirmid wrote: post #312
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.

Undo via ephemeral toast seems like a bad idea also. I guess if the toast hanged around until the next toast it might make sense?

Theres an implicit assumption that the actions being offered an “undo” are semi-important/permanent.

In other words, if you delete an email and it goes to the trash folder: good use of toast + undo

If you empty the trash, and there is nowhere the user can go to unempty it: bad use of toast + undo

Its also useful as a sleight of hand eg when cancelling an action you havent yet taken (which actually is generally what a toast + undo actually is). The best example of this being toast + undo for an email send

Re: Toasts are bad UX

#362

Post by sebtron »

dang wrote: post #256
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)

Thanks! I pinned the second link to the top: https://news.ycombinator.com/item?id=41304011 . Would it be ok to assign you as the author of that comment? I don't want to take credit for your link.

Yes that's fine for me :)

Re: Toasts are bad UX

#363

Post by Spivak »

catapart wrote: post #286
roninorder wrote: post #265

Earlier quoted context omitted.

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…

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.

Classic case of "My own opinions didn't require evidence but to convince me otherwise requires research."

Re: Toasts are bad UX

#365

Post by jayd16 »

lolinder wrote: post #311
jayd16 wrote: post #306

Earlier quoted context omitted.

"At best they're redundant" sounds pretty bad to me.

You apparently missed the bit where redundancy in communication is a feature, not a bug. "It ensures that even in less than ideal conditions the message still gets through."

I didn't give it much regard. Toasts ensure nothing as there is no guarantee the user saw them.

They are redundant as in superfluous not as in a back up.

Re: Toasts are bad UX

#366

Post by catapart »

Spivak wrote: post #363
catapart wrote: post #286

Earlier quoted context omitted.

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.

Classic case of "My own opinions didn't require evidence but to convince me otherwise requires research."

lol

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?

Re: Toasts are bad UX

#367

Post by dev213 »

_yb2s wrote: post #359
phito wrote: post #346

Earlier quoted context omitted.

It's just that it's a post made by a web developper for their web developper audience. Safe to assume they know what a Toast Notification is.

I’ve done a lot of web development and never heard the term. I even use them a lot but called them popup notifications or other terms. I’ve used lots of frontend toolkits that call these something else.

Pretty much every well-known UI library, including Bootstrap, Angular Material/MUI & Chakra UI, calls these Toasts.

Re: Toasts are bad UX

#368

Post by chimpy4 »

toasts are like those friends who always show up 2 hours late to the party and then stand in the corner. if your app needs them, at least make sure they're not doing the cha-cha in the wrong corner of the screen.

Re: Toasts are bad UX

#369

Post by [deleted] »

TeMPOraL wrote: post #213
digging wrote: post #122

Earlier quoted context omitted.

> I just disagree that leaving off the toast is (in the cases cited) valuable. But adding a toast isn't free. It's a distraction, and arguably a pretty intense one for ND folks -- especially when it becomes a standardized message center with multiple items queued up. In many cases the most useful toasts would also be better if they weren't toasts. For me, the most useful toast I interact with also demonstrates why to…

> But adding a toast isn't free. It's a distraction, and arguably a pretty intense one for ND folks -- especially when it becomes a standardized message center with multiple items queued up. Diagnosed with ADHD, so I'm guessing an ND folk here: modern applications in general, and webshit in particular, give me huge anxiety because of all the eventual consistency and optimistic actions bullshit[0], coupled with flakin…

[deleted]

Re: Toasts are bad UX

#370

Post by peeters »

zahlman wrote: post #259
peeters wrote: post #240

Earlier quoted context omitted.

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

>but why? 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.

Post reply on HN