5 ms·
The unfortunate thing is they aren’t communicating the same thing. Taking the YouTube example, the checkboxes are 100% optimistic while the toast notification
by cowsandmilk 2y ago
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 actually archived.
I would much rather only get the toast if there is a failure to commit the change. Generally, them flashing up is a distraction from what I’m trying to accomplish. And being far on the screen from where I’m taking an action makes them even more of a distraction.
- lolinder 2y agoI 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 unnecessary and provide information that the user doesn't need. But that's not the same thing as toasts being bad UX in the general case.
- hombre_fatal 2y agoToasts 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.
- datavirtue 2y agoAll of that is inacessible.
- lolinder 2y agoHow so?
- jdiff 2y agoScreen 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.
- jkaptur 2y agoThe spec has an answer for the "transient element" issue: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions https://developer.mozilla.org/en-US/docs/Web/Accessibility/A.... Of course, this doesn't eliminate the possibility of bad UX.
- CRConrad 2y ago> 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.
- lolinder 2y agoSo there are badly implemented toasts that have bad UX. That's not the same thing as the whole concept being bad.
- exmadscientist 2y agoIf something is so hard to implement that everyone who tries gets it wrong (to a first approximation), then maybe the concept is bad. Or, at least, the concept isn't fully baked and is missing something critical.
- lolinder 2y agoMost implementations of toasts-with-actions that I've seen don't have the problem OP described. I more often find myself manually dismissing them than wishing they'd have stuck around longer.
- TRiG_Ireland 2y agoSo because you are a fast reader and have a fast reaction time with your mouse, toasts are good for everyone? No.
- michaelmrose 2y agoShould 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.
- mannykannot 2y agoFair 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.
- JamesSwift 2y agoIt 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.
- notpushkin 2y agoThe 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 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)
- JamesSwift 2y agoI 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.
- CRConrad 2y ago> 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.
- JamesSwift 2y agoI 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.
- ryandrake 2y agoYou 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.
- JamesSwift 2y agoFor 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.
- Maxion 2y agoUndo's (and especially re-do) are quite hard and resource intensive to code, especially for web apps that can be simultaneously accessed via multiple devices. E.g. you can take action A on your laptop, followed by action B on your phone. Undoing action A may not be easily possible if it was followed by action B. To make that work properly you need to activel sync states between all the users devices using e.g. websocket or what-have-you. Handling edge cases becomes quite the nightmare, e.g. phone has poor connectivity. Only the big guys would have budget to do these sort of things (And make them work well).
- abirch 2y agoI'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.
- seanmcdirmid 2y agoUndo via ephemeral toast seems like a bad idea also. I guess if the toast hanged around until the next toast it might make sense?
- bigblind 2y agoToasts showing up far from where the action is take also makes them super annoying for people (like me) who use screen magnifiers. I'm oftne using a site while zoomed in, and will completely miss a toast, because it never enters the "viewport" on the screen I'm looking at.
- xelamonster 2y agoWhat kind of design choices do you find helpful with using a magnifier like that? It's not something I'd ever considered before, sounds tricky to design for but I'll try to keep it in mind now.
- bigblind 2y agoThe two main things for me are: - Put cause and effect close to eachother - Don't block my view based on mouse position. I hate video players that ofverlay the pause button when the mouse is over the video, or images that get obscured by some overlay when hovered. My zoom follows the mouse, so I can't move what I'm looking at and where my mouse is pointing independently.
- xelamonster 2y agoOh yeah those video players are awful for anyone on mobile too, always ends up somehow getting stuck active and the only way to dismiss it is tap the video, which of course is usually bound to some other disruptive action like pausing or exiting full-screen mode.
- hn_acker 2y agoAdding to your examples, I hate when video players (both mobile or desktop) don't let me hide the video player controls when the player is paused! I also dislike having to wait a few seconds upon starting/resuming a video for the controls to fade away.
- 2y ago
- cellularmitosis 2y ago> 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.
- d0gsg0w00f 2y agoI think it would be nice if the toast popped up and hid in a tray and you could expand it and see a toast history with timestamps.
- smaudet 2y agoI don't entirely hate toasts, I don't think your example is good, either. A toast is best for asynchronous, high priority, fleeting information. You don't want to stack them, or if you do you need some sort of inbox for them. You don't want to be spammed by them, you don't want them used as a stand-in for representing object state. For a checkbox, I'd rather the info be communicated "inline" maybe by color/shape/shading. A toast could be used like an info popup, perhaps i.e. "why did my checkbox get reverted". Or it could be for a high priority event, that just doesn't fit (well) in the current screen. But, again, care should be taken. If you communicate with your user, don't spam them - provide them with prompts and visually appealing methods to obtain their data. Toasts can be a part of that but shouldn't be the first tool reached for (ideally). I think the reason they are so dangerous is because they are outside the main UI flow, its technically and visually "easy" to use them.
- treflop 2y agoA grade A implementation would keep a local state that syncs to the server, indicates a sync is in progress, possibly stacks changes to reduce latency if there are a lot of changes + a slow connection and, to a user, gives me utmost confidence that I’m not going to lose data. Now my presence is to use this grade A type of implementation because I like very solid software and I’ve done it so many times now that I can bang it out in a coding interview. Or explain it to a team so they can implement it. But your average app is like a grade D. Even Instagram or Snapchat where I’m never too sure if my stories are going to be in order if my connection fails or even though it lets me cancel an upload, if I do it slightly too late the app fails to cancel because it can’t keep track of its own state through a state transition. So for 99% of apps, I want them to put a redundant toast. I do not believe they can build solid software with proper state management. At least the redundant toast lets me know it did go through. A lack of toast doesn’t mean it went through because some people barely can implement error handling.
- Maxion 2y agoEven with your description of a gradee A webapp that uses local state management effectively + shows syncing + queues with stacking + connectivity detection and exponential retries etc. I still feel like toasts can be useful to indicate to the user when are not in the "normal" state. I feel like especially mobile apps fail horribly at this, it is very normal to walk around a city and end up in dead spots. Having a clear indication from the device that we are longer in Kansas can be very useful. IMO toasts that plop up for successfull actions are often quite useless and redundant.
- adolph 2y ago> I would much rather only get the toast if there is a failure to commit the change. I would much rather the sequence of commands issued through the ui be a declarative state change queued until committed without bugging me about an error I can’t directly fix. Toast that backend chaos monkey, not me.