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

201–210 of 401 posts

Re: Toasts are bad UX

#201

Post by xyst »

hunter2_ wrote: post #190
CRConrad wrote: post #172

Earlier quoted context omitted.

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 l…

the brew creator was just really into beer crafting.

I probably do the same with some of my passion projects without realizing it

Re: Toasts are bad UX

#203

Post by cryptonector »

OP doesn't actually identify what is problematic with the toasts! The `The Problems with the YouTube Toast` section merely describes what OP sees, not what is bothersome to OP. I'm guessing that the issue is all the different locations on the page where things happen: the control, the dialog, and the toast are all over the place, thus maybe that is distracting to OP. In that case the issue is about UI element placing, not really about the toasts.

Toasts help communicate that an operation completed asynchronously after giving control back to the user without making them wait in a modal dialog. This is a very good UI/UX, especially now that users are trained to understand that asynchrony.

Re: Toasts are bad UX

#204

Post by mlsu »

The need for this sort of disappears if the thing being displayed (client) is actually coupled to the application state. Toasts are bad UX, yes. But the reason they exist is that we have one state on the server and then another pseudo-state on the client. Keeping them in sync via code locality in every component is extremely difficult.

So we come up with a workaround -- put async server updates in only one place in the application -- to get around this fundamental issue. In 99% of cases, this isn't about UX, it's about engineering. Nobody wants to put toasts in; they must, because managing state is too difficult otherwise.

It's a symptom of the larger issue.

If instead what's displayed on screen is simply the server's application state returned by the server, the user will always know what's happening with the server.

HATEOAS

Re: Toasts are bad UX

#205

Post by jeroenhd »

cryptonector wrote: post #203

OP doesn't actually identify what is problematic with the toasts! The `The Problems with the YouTube Toast` section merely describes what OP sees, not what is bothersome to OP. I'm guessing that the issue is all the different locations on the page where things happen: the control, the dialog, and the toast are all over the place, thus maybe that is distracting to OP. In that case the issue is about UI element placing…

While I'm in favour of asynchronous feedback like this, placing toasts nowhere near the button you've clicked is confusing when you get to bigger monitors. A toast in the bottom left on a large, widescreen 4k monitor can literally be half a meter away from the place you clicked, so the toast might as well not have been there. I myself have lost the progress notification for a file copy in KDE because it was placed all the way in the bottom right corner, and my screen isn't even _that_ big.

A little popover near the button makes more sense. Or, in this case, simply disabling the checkbox until the asynchronous action has completed, and using the non-disabled state to indicate success (or show a useful error message when the operation fails).

Re: Toasts are bad UX

#206

Post by cellularmitosis »

cowsandmilk wrote: post #57
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…

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 would much rather only get the toast if there is a failure to commit the change ... And being far on the screen from where I’m taking an action makes them even more of a distraction.

But wouldn't this situation be even worse with a failure-only toast? A request timeout could happen 30 seconds after the fact. You're likely in a very different UI state at that point, and unless the error message is very specific, you'll have no idea what even failed if you are quickly performing lots of actions.

Re: Toasts are bad UX

#207

Post by cellularmitosis »

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 .

> Put your damned messages where my attention has already been directed to BY YOUR UI.

Ok, so where does the toast go if you've already scrolled or otherwise navigated to a different area of the UI? These optimistic updated could take multiple seconds to succeed, and maybe as much as 30 seconds to fail.

Re: Toasts are bad UX

#208

Post by TeMPOraL »

michaelmrose wrote: post #173
CRConrad wrote: post #162

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

I'd go for an action log. It's almost the same thing, but notifications imply ephemeral pokes about some of the stuff that happened, mixed with engagement boosting spam - there's a lot of unpredictability embedded in this concept, as the app is usually trying to guess what you may (or it thinks you should) find relevant.

An action/activity log is just a reverse-chonological log of things that happened. You could make one by recording every would-be toast and putting it on that list, complete with a timestamp, and any of the context-relevant action buttons (like "undo", or "view item", etc.). The list should be a fixed recording[0], without any way to dismiss some or all of the entries. Add some attention-grabbing indicator whenever something is added there, and you get all the benefits of toasts with none of the drawbacks: the log lets you report completion of optimistically-executed actions, provide place for context-relevant buttons, and also is accessible, can be browsed at uses' own time, improves discoverability and learning, and can be upgraded to also enable undo feature.

--

[0] - Well, appended from top, and possibly unwinded by undo. Users understand that. Can't be append-only, because mixing that with undo gives you the undo system from Emacs - very powerful but also nearly incomprehensible to most people.

Re: Toasts are bad UX

#209

Post by switchbak »

mlsu wrote: post #204

The need for this sort of disappears if the thing being displayed (client) is actually coupled to the application state. Toasts are bad UX, yes. But the reason they exist is that we have one state on the server and then another pseudo-state on the client. Keeping them in sync via code locality in every component is extremely difficult. So we come up with a workaround -- put async server updates in only one place in t…

HATEOAS is more about a standard, discoverable and consistent way to navigate around resources in a RESTful fashion. Which is nice, even if it didn't really catch on to a large degree. I think that's somewhat orthogonal to he point you're making.

I think your point is good though, that an ephemeral toast message is a cheap way to avoid having to manage and expose the underlying state. Exposing that via a HATEOAS REST API would be even better!

Re: Toasts are bad UX

#210

Post by Manfred »

dvdkon wrote: post #33
Manfred wrote: post #13

Earlier quoted context omitted.

I don't think that's a convincing argument unless you are a tiny company that has to optimize for development time. You can also wonder why the frameworks you are using make this hard, because it's a pretty common to want feedback close to where the action happens.

I don't know anyone who isn't optimising for development time in some way. That said, most frameworks don't provide any worthwhile error handling infrastructure, and it's a problem. In a Jetpack Compose app I wrote, I created generic "error barrier" components, so that error messages display over relevant parts of the app, with just a few lines each time, timeouts included. I think this is the best approach, easy for…

I meant optimizing for developer time over usability in the context of the story, that mostly shows products from Google. Google being the opposite of a small development team that could be forced to choose developer time over usability.
Post reply on HN