Live data from Hacker News

Toasts are bad UX

maxschmitt.me

181–190 of 401 posts

Re: Toasts are bad UX

#181

I agree with post and don't like toasts either. The thing is, they don't solve a UX problem as much act as a catch-all solution for "respond to user action". It is easier for orgs to shove everything in a toast than to think about more practical places to put the data.

Yeah, I'm not a huge fan of toasts. And I generally agree with the sentiment that it would be better to have indicators closer to where the action was taken. But, I'm not sure how else I would approach this? I think the main benefit is the catchall approach allows the team to focus on other customer problems.

I lead the design system team for an enterprise SaaS company—there are so many controls across so many views. It's hard to imagine including a feedback mechanism like this in every component.

And I still think we'd need some sort of toast confirmation for deleted records?

Re: Toasts are bad UX

#182

Earlier quoted context omitted.

It also would mean you would move the item eagerly, then put it back on error. Or alternatively make it a "ghost" item in the list then remove on success. But overall the eager-move + toast + undo is just a much faster feeling implementation and the overall UX is so much cleaner.

The undo button justifies the toast here IMO. Otherwise I'd prefer ghosting really. For the checkboxes, I'd say GitHub nailed it: for settings that are applied instantly (e. g. https://github.com/settings/appearance ), they show a spinner and then a single checkmark right across the section title. (It used to be next to the input element – both ways are fine, I think)

I agree they do a good job, but I think a toast without undo could also work there. Apply the UI eagerly, toast success or failure. As it is, I assume on failure it becomes an 'X' and shows an error? I just dont generally like very short transitions like the spinner is currently. In general, coming from app land, I prefer a deferred loading spinner that only shows if the action takes X ms. So in the happy path of a fast action the user never sees the loading state.

Re: Toasts are bad UX

#183
post #155

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 .

In some cases, the current user's focus is unrelated to the notification. For example: if the notification is alerting you to some foreign event like an incoming message, an app reading the clipboard on its own, an alarm, etc. -- some kind of standard positioning is needed for this.

I believe toasts should be confined to this scenario I'm describing, and indeed feedback directly coupled to user focus/input should be located near to that as you say.

Re: Toasts are bad UX

#184
Let me share the dark side of Toasts.

World of Warcraft has these, they're used for lots of things. Notably achievements and things like that. There's also add on that look for rare monsters and pop up when it detects one while you're flying about in the land, loot drop announcements

However, we just went through a special event called "Remix" which basically offered degenerate gameplay. Absurdly powerful characters, loot raining from the sky. And in this event, the common reward was a chest filled with gear and other things. These chests came from everywhere.

When you opened a chest, if it had piece of gear, you'd get a little toast.

Now, when you're boucing about collecting boar livers and rousting out hoodlums from their huts, it was quite easy to collect dozens of these things.

And, being WoW players, not known for their patience, you simply collect them all and open them all at once. Open your bags, and right click away. From this, your UI simply explodes with toasts. And they're all queued up, you can only see so many at a time, like, perhaps, 5. And they slowly fade, making room for others.

They dominate roughly 30% of the screen real estate (when presented in volume), smack in the center. And you can either wait it out (which takes a long time), or madly right click to dismiss them all. Me, I would simply go to the inn, open them all up, and log out (which is instant in an inn), and log back in. That would flush the queue of toasts.

Similarly, if you log into a zone, particularly a quiet zone, it's not uncommon for the screen to explode with alerts telling you of all the rare monsters that are simply sitting there because the zone is very quiet for players.

Finally, there a grouping queue you can join for group content, and you can queue for more than one event at a time. So, it's not uncommon to finish one event, kill the boss, the screen explodes with your loot, others loots, maybe a boss achievement, followed by a booming horn with a dialog telling you your new event is ready for you. The entire UI is just a cacophony of alerts.

Toast are mostly fine in my experience, but they do not work when applied in volume.

Re: Toasts are bad UX

#185
post #22

The solutions seem to rely on a user that doesn't navigate before the action is completed. Does he propose locking the UI in the meantime, or to optimistically show the user a success result?

Debouncing is a known development tool for most non-immediate actions. It's related UI concept of locking individual UI elements is also well understood by many users (not by that technical name, but by "it's working on my action" kind of understanding). > optimistically show the user a success result? I don't particularly like React, but this a core feature of such JS frontend frameworks, optimistically "succeed" wh…

Is this an LLM? :) The question was rhetorical. Both of these proposals have problems. But the main issue is that the author of the article is missing an angle of toasts as a UX concept.

Re: Toasts are bad UX

#186
post #133

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

In this specific example you do have an Undo button: the checkbox itself. The issue here is that the checkbox doesn’t match the exact state it’s supposed to represent: if you check it, for a few seconds it’s checked but the video is not yet saved; if you uncheck it it’s not unsaved until the toast appear. If you repeatedly check/uncheck it you don’t know in which state you end up.

> In this specific example you do have an Undo button: the checkbox itself.

That's false. The checkbox itself is not a viable undo button under any circumstances in this specific example (i.e., you accidentally clicked but have no idea where, and let's assume you have no idea of that particular checkbox's state prior to the accident). Any adjacent checkbox would have extremely similar plausibility for a user wondering how to undo.

That said, toast is not great either, because it may disappear before the user fully recovers from their accident (say, a spilled drink). Maybe the undo button (and any async success/error labeling for the original event) ought to be adjacent to the checkbox and persist until the next action taken.

Re: Toasts are bad UX

#187
A blog post about bad UX that has a video element with controls hidden and autoplay. With autoplay disabled, it can take a while to figure out this thing is a video that just isn't playing...

Re: Toasts are bad UX

#188
As long as the "toast" section is reused for many different messages, I don't get the problem? Ideally, you'd embrace that there is a common spot to see informational items. Even more ideally, you'd have a way to view all of the notifications that have been shown. (Emacs user entering the conversation...)

I confess I was completely at a loss as to what a Toast was, though. I suppose we went with that name because they pop up?

Re: Toasts are bad UX

#189
I did not like this. This is why:

* Embedded example video doesn't work on Firefox.

* Reasoning reads more like post-hoc justifications to me.

* Last and most important: does not explain what "toasts" are.

Aside: The word in its default English usage is not countable. Making a plural means it must be the usage of clinking glasses of alcoholic drink, to indicate a salutation to a person or thing.

They seem to mean "toaster notifications". I only know this as an option in Pidgin. I Googled it and found this:

https://bootcamp.uxdesign.cc/toast-notifications-how-to-make...

That page suggests that this bad, broken English is a standard usage in some niche community or communities. IMHO that doesn't excuse it.

Re: Toasts are bad UX

#190
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.)

Seems like it could live among these:

> We currently demand that users internalize several metaphors when interacting with Homebrew. These include:

> Formula (how to build a bit of software)

> Bottle (pre-built software)

> Cask (pre-built software on macOS)

> Tap (a collection of software)

> Keg (where software installs itself)

> Cellar (where all my software install themselves)

> As well as an additional number of less-common metaphors that contributors and maintainers need to know, like Rack, Tab, and Formulary.

https://github.com/Homebrew/brew/issues/10798

Post reply on HN