[HN Gopher] Toasts are bad UX
___________________________________________________________________
Toasts are bad UX
Author : Mackser
Score : 412 points
Date : 2024-08-20 10:57 UTC (12 hours ago)
(HTM) web link (maxschmitt.me)
(TXT) w3m dump (maxschmitt.me)
| Mackser wrote:
| I haven't heard many developers/designers talk about the overused
| practice of using toasts for UI feedback.
|
| The post shares a few real-world examples and illustrates some of
| the problems with how they use toasts.
|
| What do you think? Are toasts overused? In which cases do you use
| them in your own apps?
| unglaublich wrote:
| Toasts should be used if there is no direct relation to or
| interaction with a visible UI element: notification, heavily
| asynchronous processes, out-of-view modifications.
| Ukv wrote:
| I'd speculate that their overuse comes from convenience of
| displaying any message by throwing in a `showToast("Foo!")`
| opposed to altering each UI component to show the relevant
| feedback.
| maccard wrote:
| That cuts both ways IMO. At least with a toast system I know
| where feedback appear on a per app basis (or website or
| whatever). Imagine if every screen, view, list entry,
| checkbox had its own way of displaying feedback. It would be
| an enormous amount of overhead.
| JohnFen wrote:
| > Are toasts overused?
|
| I think so, yes.
|
| > In which cases do you use them in your own apps?
|
| I don't. But I don't write mobile apps (where they make more
| sense) for distribution, so they don't address any need my
| applications have.
| phartenfeller wrote:
| Strongly agree. I guess toasts work better for mobile screens as
| they are smaller and mostly vertical, so the element spans the
| whole screen width. If it needs to be there and should be
| responsive, I would prefer it to be an alert in the upper-right
| corner of big screens.
| iambateman wrote:
| Toasts are bad UX for an app which is used in a casual context,
| yes. The odds that an untrained user missed them and becomes
| confused are quite high.
|
| But there is nothing wrong with a toast in a pro app. The pro
| user will get used to where feedback comes from on the screen and
| find it is second nature to notice the toast.
|
| In practice, there are very few UX principles that generalize
| across every interface.
| tuyiown wrote:
| The pro will train himself to whatever good or bad thing you'll
| throw at him. The point is not about identifying generalization
| that works everywhere, it's just to have enough care for making
| the good choices at the right places.
| lylejantzi3rd wrote:
| Just because somebody will put up with it doesn't make it a
| good choice. That rationalization has been used to justify a
| lot of awful decisions and awful software.
| zachrip wrote:
| I will say as someone with a limited visual field, toasts are
| very frustrating as they're almost always out of my field of
| view. Please keep indicators/notifications close to the thing
| that caused it.
| iambateman wrote:
| Serious question...when saving a document on a mac, the only
| visual indicator that the save happened is the red "close"
| button loses an interior circle.
|
| This is 10x more subtle than any toast.
|
| Do you wish that were different? Or does that work for you?
| ervine wrote:
| Aha fully-sighted and I've never noticed this... 15 years
| of mac use.
| zachrip wrote:
| Do you have a video or screenshot of this? I don't daily
| drive a mac so I'm having trouble recalling (I also am not
| sure what you mean by saving a document, in which
| context?). But regardless, I don't think a toast would
| serve me better there, that doesn't mean that ux doesn't
| suck either :)
| cqqxo4zV46cp wrote:
| Classic. People that are bad at UX design using the "pro app"
| catch-all to justify all sorts of bad decisions.
|
| I spend all day in "pro apps". I am also visually impaired. The
| inappropriateness of toasts has nothing to do with my
| familiarity with the app. I may, eventually, learn that a
| particular UI is using toasts to indicate something. That
| doesn't suddenly make it okay. They're still a massive pain in
| the ass for me. They're still a massive pain in the ass for a
| lot of people. They're still a poorly thought out holdover from
| the days of 640x480 displays, and with a modern resolution
| they're even less appropriate.
| iambateman wrote:
| You have also used a catch-all, but yours was personal and
| rude. The rest of your point is useful...just please remember
| that there are real people typing words into this app.
|
| To respond to your point,
|
| (1) is it a PITA because it's hard to see something in the
| periphery or for some other reason? (2) Is there an example
| of a web app that you've noticed provides feedback very well?
| (3) would you consider a toast acceptable when the UX
| designer doesn't consider the information critical? As
| in...the user can safely assume their action was accomplished
| but a little feedback is a nice sugar.
| JohnFen wrote:
| I actually think the opposite. Toasts in my professional tools
| are even more objectionable to me. They're never where I'm
| concentrating, and by the time I realize one is happening and
| look at it, it's either already gone or is saying something
| trivial.
|
| The end result is usually that I've been distracted for no
| reason.
|
| In a casual app, none of this matters as much.
| ervine wrote:
| Maybe bad UX, but global error / success handling of network
| requests is way easier than handling in every component that
| triggers one.
| Manfred wrote:
| 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.
| ervine wrote:
| I didn't say it was hard, it's just very nice to not have a
| bunch of extra error / success code in all of your components
| that make async requests.
|
| Trade offs, as usual.
| epolanski wrote:
| In my experience the overwhelming majority of teams out there
| are understaffed (especially when it comes to good and
| productive professionals) so your example is the rule, not
| the exception.
| dvdkon wrote:
| 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 developers and informative for users. Too many apps just
| ignore errors.
| Manfred wrote:
| 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.
| yxhuvud wrote:
| Then refactor your app to make it easy. If it is hard in your
| tool, choose a different tool that make it easy.
| ervine wrote:
| Again, it's not hard - just being devil's advocate for when
| toasts are useful.
|
| Less code, centralized messaging.
| storafrid wrote:
| 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?
| gr__or wrote:
| Came here for exactly this, the post is proposing a solution
| while only understanding one half of the problem.
|
| Toasts are a global UI feedback mechanism for non-
| blocking/fallible/undo-able actions. That does make them out-
| of-place by default, but at least consistently so.
|
| A solution I'd accept is local-view-first with toasts-as-
| fallback when the view is dismissed. That said, loading
| indicators _might_ make users hesitant to dismiss a view.
| jagged-chisel wrote:
| The dismissal should communicate to the user in a way that
| indicates the process will continue without the view.
| Y-bar wrote:
| 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" while
| async network and back-end work happens to give the illusion of
| speed: https://react.dev/blog/2024/04/25/react-19#new-hook-
| optimist...
| storafrid wrote:
| 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.
| Y-bar wrote:
| From my perspective there was nothing rhetorical about that
| question as I occasionally encounter it as a serious thing.
| Some colleagues really do not want optimistic UI events.
| Some swear by them.
|
| I don't have any strong feelings one way or another as long
| as there is proper inline feedback.
| katzinsky wrote:
| My main complaint is that on Firefox on Linux anyway they
| actually steal the mouse position along with keyboard focus. So
| if you're using something like instagram's IM it's really hard to
| type while getting replies.
| Cthulhu_ wrote:
| Timed toasts are bad for accessibility too, see WCAG 2.2:
| https://www.w3.org/TR/WCAG22/#enough-time
|
| Basically, the user should be able to configure toast messages;
| they should not autohide, or the time they hide should be
| adjustable, or they should be extendable within 20 seconds.
| TL;DR, self-hiding messages, dialogs, etc are not good for a11y.
|
| That said, the toasts have a button where the user can undo the
| action taken, which is good for accessibility under criteria
| 2.5.2 and/or 3.3.4 / 3.3.6
| taneq wrote:
| It's almost like we need a semantic level where the developer
| says "I want to send the use this small transient text message"
| and then a presentation level where a user can decide which
| method of presenting this information works best for them...
| katzinsky wrote:
| Email is nice.
|
| >But I don't want so many mails in my inbox
|
| Then write mail rules. It's really easy and personally I
| couldn't survive at work without them. That's a big part of
| why it's nice: _You_ can choose how it works unlike
| practically everything else these days.
| JadeNB wrote:
| That ties the app to be usable only with network access
| (which is fine for, e.g., Youtube, but not for all apps!),
| and also includes a highly variable lag.
| is_true wrote:
| Always = in Material design
|
| https://m3.material.io/components/snackbar/guidelines
| david_allison wrote:
| Snackbars aren't toasts
| is_true wrote:
| do you have a source for that? I understand that Toast is the
| name given in Android
| david_allison wrote:
| > Note that Snackbars are preferred for brief messages
| while the app is in the foreground.
|
| https://developer.android.com/reference/android/widget/Toas
| t
| is_true wrote:
| That's the Android widget, not material design which is
| used for YouTube's UI
| david_allison wrote:
| I fear we're talking past each other. Material Design
| doesn't have a Toast.
|
| Material Design Snackbars aren't toasts:
|
| * Snackbars are local, toasts are global
|
| * Toasts don't receive focus, snackbars can (via the
| optional action)
|
| * Toasts auto-dismiss. This is optional for snackbars
|
| * Snackbars can explicitly be dismissed early by a user
| Y-bar wrote:
| They even acknowledge the limitations and problems with Toasts:
|
| > 1. Add inline feedback
|
| >
|
| > Information in auto-dismissing snackbars must also be
| communicated using another accessible method inline or near the
| action that triggered the snackbar.
| anentropic wrote:
| this seems like an example of a mobile interaction pattern being
| blindly applied to desktop site
| epolanski wrote:
| This does not consider errors, especially non-recoverable ones
| (server problems, bugs) where imho it's hard to design.
| qwertox wrote:
| YouTube has even better examples.
|
| Go to https://www.youtube.com/feed/history and click "Comments"
| on the right side. Then delete one comment.
|
| You will get one toast indicating that it will be deleted, and
| one a second or two later indicating that it got deleted.
|
| If you delete multiple comments quickly one after another, you'll
| first get a bunch of toasts indicating that the comment will be
| deleted, and then, with that second or two delay, each
| confirmation, but they do get deleted sequentially, so you have
| to wait for all the confirmation toasts. Which for a deletion of
| 10 comments will take more than 10 seconds, even if you clicked
| them all in two or 3 seconds.
|
| Same with the live comments at
|
| https://myactivity.google.com/page?page=youtube_live_chat&co...
| teqsun wrote:
| Toasts can be bad UX (usually when they are the sole feedback),
| but they are great in conjunction with other elements.
|
| A confirmation toast with a page-redirection is a great way to
| add additional indication to the user that their submission was
| successful.
|
| A warning or error toast in addition to standard form validation
| indicators gives a great secondary indication to the user that
| they need to change something.
|
| And if implemented in a catch-all for nonspecified errors, it'll
| allow the user to preserve the state of their page vs rerouting
| to an error page.
|
| If used as one tool in the toolbox vs the only tool in the
| toolbox, it's a great option.
| perlgeek wrote:
| > 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.
| hk__2 wrote:
| 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.
| hunter2_ wrote:
| > 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.
| hk__2 wrote:
| > 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
|
| That the same for every single checkbox in every single
| form on the Web.
|
| Even in the unlikely case in which you clicked on the lists
| button that opens the popin and then accidently clicked on
| a checkbox without seeing which one and without seeing the
| checkbox state change, you still have the list of lists on
| the screen and you can still choose if you do want this
| video in this list(s) or not.
| hunter2_ wrote:
| > That the same for every single checkbox in every single
| form on the Web.
|
| In my experience, the majority of forms on the web don't
| commit until you decide to submit, so if you have an
| accident before then, you can recover (well, buy a sense
| of certainty at the cost of redoing some work) by
| reloading the form. In contrast to that majority, here
| we're talking specifically about forms where each
| component auto-submits immediately. I think that if a
| component auto-submits, then anything related to that
| submission (success/failure status, undo, etc.) should be
| presented within that very component.
| thih9 wrote:
| > The issue here is that the checkbox doesn't match the exact
| state it's supposed to represent...
|
| This can all be fixed. E.g. disable the checkbox while it's
| processing; or show a small loading indicator; make it
| impossible to click the checkbox repeatedly. Etc.
|
| A frontend update that doesn't wait for the server is nice,
| but only when server state is irrelevant. If the user wants
| to know about the server state, then the UI should always
| indicate that.
| Terr_ wrote:
| Yeah, I've encountered that in a few systems: I'm aware I
| accidentally just changed the wrong thing but I don't know
| _which_ wrong thing, there are no clues. This is especially
| problematic when there 's a chance _nothing_ changed, but you
| can 't be sure.
|
| To illustrate the problem with "perfect storm" example, suppose
| a your back is turned and a ball rolls of the shelf and hits
| the keyboard. Did anything change? What changed? How do you fix
| it?
| choward wrote:
| "We do have to consider the undo-functionality and that the toast
| feedback can be useful when using keyboard shortcuts."
|
| There's nothing more infuriating than going to click undo and the
| toast disappears.
| nirui wrote:
| It's the most annoying thing I felt when I using software too.
| So in my own project, I tend to just keep the message open and
| wait for user to decide what do to with it, but then that's not
| a toast anymore.
|
| I don't think designers should put _anything_ interactive in an
| arbitrarily timed interface aside from "Dismiss". A toast is
| the best when it's displaying what is currently going on, not
| as a pop up dialog box.
|
| The best design for Undo I think is to make it a dedicated
| button, like the one in the text editors. When user clicked
| "Archive", a Toast pop up and displays message "Archiving N
| entries, please wait" and then change it to "N entries
| archived. You can press Control+C or click [Undo Icon] to undo
| if that was a mistake" then the Undo button lights up.
|
| Also, IMO the message format "Archiving N entries, please wait"
| should be a standard, it tells the user in a clear way 1) what
| the software is doing, and 2) what should I the user do. On the
| other hand, the message "Conversation archived" don't really
| provide the same value, since user already saw it happened.
| suyash wrote:
| It's an effective UX tool for smaller screens like how it was
| created for Android phones, in larger displays it doesn't work as
| effectively.
| mattdesl wrote:
| To play devils advocate:
|
| - if your app has a number of messages (eg: "image downloaded" or
| "message sent" or whatever) then there is a consistency in using
| toasts as they all appear in the same predictable manner
|
| - often "appear away from focus" is one of the intended goals of
| a toast; it's a message that is present, but more in the
| periphery (the user can ignore in most cases, and it doesn't
| obscure main content)
| julienmarie wrote:
| A toast makes sense only in 1 case: when it's a notification that
| is unrelated with the current action of the user. Similar to OS
| types of notification that the defunct Growl (memories) invented.
|
| Any feedback from a user action should be done within the context
| of the user action. If the action is async, it should be clear
| and the feedback should instantaneously indicate that the action
| is queued for processing. In that case, the feedback should give
| 2 options: cancel and access the queue (or better give a vision
| of its progress ).
| catapart wrote:
| I'd add one more scenario: when the UI element that would give
| feedback, normally, has been removed, yet you still want to
| show feedback.
|
| If I removed a task from a board, I can't show - on the task -
| how to undo that action. There's a keyboard shortcut to undo
| it, but how would the user know, visually?
|
| I'm not going to replace the task with a note because notes
| don't belong in task lists - only tasks do. I'm not going to
| come up with some derivative task that only displays a message
| because then I'm injecting intention that has no function for
| the task component. I'm not going to just not tell the user
| because while it is obvious that the task was removed, it's not
| obvious how to undo what could be an alarming action from a
| single click (and I'm certainly not going to nag people before
| deleting a task with a single click; it's a core functionality
| of task lists. It needs to be able to be done instantly, and
| undone instantly).
|
| So on and so forth. I'm sure people have tons of one-off,
| little, anecdotal examples like that. Toasts were invented for
| a reason. Just because people got cutesy with them doesn't mean
| they aren't specifically useful for specific scenarios,
| regardless of how contrived.
| JamesSwift wrote:
| Thats one reason for them. The other is for "not important
| enough to block the user, but important enough to inform them
| of something". What was previously a popup with an 'ok'
| button is now a toast. Low friction, medium importance.
| roninorder wrote:
| 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 undo.
| creeble wrote:
| Another example related to the current action of the user, but
| outside the scope of the currently-viewed screen: inserting a
| USB stick, or some other hardware-related function.
|
| There is no context for this, and often an action is required.
| And even if not, it is certainly useful to confirm with the
| user that their action was detected.
| peeters wrote:
| > If the action is async, it should be clear and the feedback
| should instantaneously indicate that the action is queued for
| processing. In that case, the feedback should give 2 options:
| cancel and access the queue (or better give a vision of its
| progress ).
|
| Where should that feedback be given for modal operations,
| acknowledging that 99% of the time when the user initiates the
| action they want to background the operation and move on to
| doing other things?
| zahlman wrote:
| If it's supposed to be a "modal operation", then it's
| supposed to complete before any of this becomes relevant.
| When that can't happen (e.g. because of an Internet hiccup),
| IMO the user should be able to take manual action to
| "minimize" (reversibly hide) the widget, but it shouldn't
| disappear until the operation is complete.
| peeters wrote:
| > 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.
| zahlman wrote:
| >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.
| zombot wrote:
| It's not like we've had decades and decades of GUI experience
| where every problem has already been solved. Also, this week's
| "designer" is smarter than everyone before them -- time to
| reinvent the wheel!
| joduplessis wrote:
| I would say the article is a bit nit-picky IMO. For every pattern
| there are probably dozens of poor-use examples. I personally
| really like the Gmail undo mechanism.
| tomaytotomato wrote:
| How about just getting rid of all food related jargon; salad
| bars, burgers, toasts, heroes etc.?
|
| As a backend developer this stuff is mind-boggling, just call it
| "notification widget", or a "confirmation widget" etc.
|
| Try explaining what toast is to an Indian subcontractor who has
| never eaten toasted bread in their life and then apply that to
| the UX usecase.
|
| Removing these terms will also improve accessibility and
| understanding for junior developers entering the frontend world.
| lolinder wrote:
| While we're at it let's remove the jargon from other trades,
| too.
|
| "P-trap" is a confusing word that plumbers use, we should
| instead have them say "gas barrier". And the word "fuse" makes
| very little sense in an electrical context--try explaining to
| someone who's never seen a stick of dynamite why the
| "overcurrent stopper" is named after a long gunpowder-infused
| cord! Traffic engineers shouldn't refer to "groups of cars" as
| "platoons" (they're not in the military!), and software
| developers should stop talking about "DDOS" and just say "lots
| of computers hitting my server at once"!
|
| In all seriousness: jargon exists because it's useful to be
| able to refer to something that you use a lot conscisely and
| precisely. Your proposed replacements are not concise or
| precise, and they only solve the non-problem of people not
| understanding the etymology of the jargon. Part of learning a
| trade is learning the jargon associated with it, and that's
| true for every trade.
| tomaytotomato wrote:
| I get your reasoning but still why use food terms for jargon
| in UX instead of something else.
|
| Your example of a "P-trap" is good but its not like plumbers
| are going around saying, get me the "slinky hotdog" to bend a
| copper pipe, or you need a "banoffee pie" to seal this joint.
| lolinder wrote:
| Why does it matter to you where the jargon came from? Why
| are vaguely shape-related jargon and military-derived
| jargon and acronyms okay but you draw the line at toast?
| tomaytotomato wrote:
| I would argue that FUBAR, P-trap, Dequeue, HALO are going
| to have a less likelihood of a context collision than
| borrowing an existing word that is ubiquitous in society.
|
| For example in Google
|
| "toast"
|
| "toast menu"
|
| "toast ux"
|
| All yield different results
|
| However "p-trap" gets you a narrowed list of results
| lolinder wrote:
| "Platoon" turns up military answers until I specify
| traffic. And I'm actually not at all sure what meaning of
| "HALO" you're referring to--it must be jargon not in my
| vocabulary, but for me it refers to a thing angels have
| and to a video game.
|
| Again, it seems like you're inconsistent in applying your
| frustration with jargon. You're frustrated with jargon in
| an adjacent profession to yours, but don't seem to apply
| the same logic to professions that are entirely unrelated
| or to your own jargon.
| ben_w wrote:
| High Altitude Low Open, of a parachute approach.
| fwip wrote:
| To a backend developer, the appearance of the "notification
| widget" doesn't matter.
|
| To a front-end dev or designer, it does. That's who the jargon
| is for.
| briandear wrote:
| I've been a developer (primarily back end) and I never heard
| the term toast until now. Perhaps I'm just simple, or maybe I
| stopped paying attention after "hamburger menu." I'm probably
| too old to hang out with the cool kids anymore.
| tomaytotomato wrote:
| As a developer who started with jQuery and then Backbone.js
| it seems like frontend dev has become very rich but at the
| same time has developed some weird esoteric rituals and
| practices which don't seem to go with conventional software
| engineering.
| wadadadad wrote:
| I'm curious as to how you're defining 'conventional
| software engineering' here; can you give some examples of
| things that are not conventional software engineering in
| the front end?
| lynguist wrote:
| Front end is more specific than conventional - it has a
| graphical output, and is thus closer to 2D game
| development than to the "conventional" data structures
| and algorithms way of programming.
| ben_w wrote:
| Off topic, but: what food (and indeed what UI element) is
| "heroes"?
|
| I've heard of "hero pictures" (detailed close ups, I think
| named via the highest quality film props), but not food or
| other UI uses.
| hk__2 wrote:
| > As a backend developer this stuff is mind-boggling, just call
| it "notification widget", or a "confirmation widget" etc.
|
| How would you call a hamburger menu? "menu widget with three-
| or-sometimes-a-different-number-of little horizontal lines"?
|
| As a backend developer you also have some jargon but you're too
| used to it to notice it.
| zahlman wrote:
| Rather than trying to solve _that_ communication problem, why
| not just _label the menu with an actually descriptive icon_?
| I _assume_ that this icon is supposed to convey "there is a
| menu under here", via the horizontal bars abstractly
| representing menu items. But to me that's a vastly less clear
| visual language than even MacOS 6 offered me in the 80s, even
| limited to 16x16 black-and-white icons.
|
| Menus are supposed to have _titles_ so that you know _what
| 's_ in them, not just _that there is_ something in them. It
| 's especially obnoxious to see a hamburger menu next to other
| icons that happen to be for other menus. First off, this
| fails to convey that they even are _menus_ , and not, say,
| buttons. But it's especially obnoxious trying to guess what
| menu items the hamburger menu might contain. Even if you
| decipher the _other_ icons, you 're left with speculating
| about all conceivable menu items, and then applying process
| of elimination.
| wolpoli wrote:
| I was definitely confused when I first learn that 'chip'
| elements in material design look like french fries.
| zahlman wrote:
| Hold on, how is "hero" a food metaphor? I mean, I understand
| that there are some regional dialects that use that name for a
| "submarine" sandwich (and there are many other names for it),
| but I can't fathom how a full-screen image at the top of a
| website has any metaphorical connection to that. To me, that
| makes _even less_ sense than the idea that such an image
| somehow is supposed to do a heroic job of advocating for
| whatever is the main point of the page (unironically my prior
| mental model!).
| hunter2_ wrote:
| It's not a food metaphor, nor is it about displaying
| something heroic, although that's much closer. "Hero image"
| comes from "hero props" which "are the more detailed pieces
| intended for close inspection by the camera or audience. ...
| The name refers to their typical use by main characters in a
| production." [0]
|
| Since the name arises from _use by_ a hero, then to extend
| the metaphor by direct analogy, the actual hero is the
| overall article /content in which a hero image is contained.
|
| That said, a "hero sandwich" is that which "one needed to be
| a hero to finish" [1] so does all tie back to the idea of
| heroism regardless.
|
| [0] https://en.wikipedia.org/wiki/Prop#Hero
|
| [1] https://en.wikipedia.org/wiki/Clementine_Paddleford#Writi
| ng_...
| shahzaibmushtaq wrote:
| YouTube toast is a bad UX and French toast is always a good UX.
| webdevladder wrote:
| I tend to agree but I think toasts can still be useful and good
| UX. Putting useful and actionable feedback in context instead of
| toasts is a rule of thumb that I try to follow but it's not
| always appropriate.
|
| For undo-able actions, toasts disappearing too fast or colliding
| with other toasts badly is a real problem. An affordance to see
| the toast history with non-disappearing undo buttons may be more
| to implement but for a lot of apps, a viewable and editable
| history combined with toasts is a much better UX than either
| system on its own.
| lolinder wrote:
| 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
| another way of communicating the same thing at the same time.
| Redundancy in communication is a feature, not a bug, and it's
| present in all human languages. It ensures that even in less than
| ideal conditions the message still gets through.
|
| In the case of toasts, having a single, standardized way of
| communicating the status of all actions (and if possible
| providing the undo) allows a user to quickly pick up on the
| pattern. Extra indicators closer to the action can be valuable
| _too_ , but it's when they're paired with the toast that their
| meaning becomes entirely clear. To remove the toast in favor of a
| bunch of specific indicators is to force your user to learn
| several different ways of saying "it's done now" entirely from
| context (many of which will be small and subtle as in the
| examples given). This might work fine for you and me but isn't
| great for, say, the elderly or the vision impaired or children.
|
| Unless they're actually getting in the way, toasts aren't bad UX,
| they're redundant UX, and a UX designer shouldn't be striving to
| optimize away redundancy.
| cupantae wrote:
| I agree. In the first example, you would assume the action
| completed even if you missed the toast. But in case you did
| notice it, that gives you a confirmation. Suboptimal? Maybe.
|
| But the proposed solution is clearly worse, unless the loading
| circle turns into a tick to show completion
| cowsandmilk wrote:
| 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 wrote:
| I 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 wrote:
| 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.
| datavirtue wrote:
| All of that is inacessible.
| lolinder wrote:
| How so?
| jdiff wrote:
| 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.
| jkaptur wrote:
| The spec has an answer for the "transient element" issue:
| https://developer.mozilla.org/en-
| US/docs/Web/Accessibility/A.... Of course, this doesn't
| eliminate the possibility of bad UX.
| CRConrad wrote:
| > 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 wrote:
| So there are badly implemented toasts that have bad UX.
| That's not the same thing as the whole concept being bad.
| exmadscientist wrote:
| If 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 wrote:
| Most 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.
| michaelmrose wrote:
| 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.
| hunter2_ wrote:
| > Browsers that support JavaScript typically implement
| the Notification API. This API asks for user confirmation
| to allow popups and give the programmer the opportunity
| to display notifications with a text (body) along with an
| descriptive icon and header.
|
| https://en.wikipedia.org/wiki/Pop-
| up_notification#JavaScript
| TeMPOraL wrote:
| Of course, this is just abused by sites to spew their
| garbage outside the confines of their own pages, which
| makes the API effectively dead.
| michaelmrose wrote:
| I only allow notifications from a tiny number of sites.
| The ability to notify me while on the page is different
| from notifying me while the tab is in the background and
| more so yet than the ability to bug me whenever.
|
| Ask for everything get nothing. I imagine most people
| click no
| TeMPOraL wrote:
| 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.
| michaelmrose wrote:
| This sounds like something the browsers could
| standardize.
| mannykannot wrote:
| 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.
| JamesSwift wrote:
| 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.
| notpushkin wrote:
| 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)
| JamesSwift wrote:
| 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.
| CRConrad wrote:
| > 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.
| kccqzy wrote:
| 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.
| JamesSwift wrote:
| 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.
| ryandrake wrote:
| 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.
| JamesSwift wrote:
| 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.
| abirch wrote:
| I'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.
| bigblind wrote:
| Toasts 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 wrote:
| What 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 wrote:
| The 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.
| cellularmitosis wrote:
| > 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.
| smaudet wrote:
| I 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 wrote:
| A 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.
| the_other wrote:
| I use a computer mainly by using a zoom tool to magnify the
| area around my text and mouse/finger cursoe. I miss almosst all
| toasts and most notifications because they not where I'm
| working. For my use case, feed near the item I'm interacting
| with is the only valuable feedback.
| kaoD wrote:
| I assume you don't want a full screen reader if you're not
| already using one, but if toasts are properly implemented
| (big if), screen readers can actually present them accessibly
| via the ARIA alert pattern[0].
|
| Wanted to mention in case you're not aware and maybe there's
| some tool somewhere (or some way to configure a screen
| reader?) so that you can keep your simple zoom workflow but
| still benefit from the ARIA alert pattern.
|
| [0] https://www.w3.org/WAI/ARIA/apg/patterns/alert/
| mceachen wrote:
| Thanks for this! I visited your link and hadn't seen such a
| nice demo with working code on w3.org before: whoever
| worked on these pages deserves kudos.
| latexr wrote:
| None of that invalidates what your parent comment is saying.
| They're not saying you should use toasts to the detriment of
| other options, but _in addition_ to them. If anything, your
| comment reinforces the notion that redundant information is
| beneficial because you don't know where the user is looking.
| lolinder wrote:
| Yes. For example: while OP uses a magnifier, lots of other
| people use a screen reader. "Loading indicator disappeared"
| is a tricky thing to communicate clearly with audio.
| "Toast: save successful" is trivial.
| the_other wrote:
| I _was_ attempting to suggest toasts "are bad UX", but
| your points make a lot of sense. Thanks.
|
| There was some discussion in the article and elsewhere in
| the thread about how a toast with an undo button could be a
| very useful interface pattern. It wouldn't work for me, so
| I would hope that UX designers that want to use toasts
| would also design in other means to find and execute an
| undo action.
|
| For you, my comments reinforce that toasts are "good UX"
| when they contain redundant information. I'm warming to the
| idea. In parallel, for me, this discussion is reinforcing
| my intuition that "actions and feedback as close as
| possible to the area of interaction" should be considered
| the primary vector.
| dkarl wrote:
| I think the suggested improvement clarifies what he means: if
| you're worried that the UI element the user is interacting with
| doesn't fully convey what's happening, then improve that
| element rather than adding a second element that divides the
| user's attention and challenges them to read quickly and make
| the connection themselves. Communicate the failure of their
| interaction in the context of the element they interacted with,
| so the connection is clear.
|
| A toast makes sense as a worst-case, last-gasp, no-context
| attempt to communicate with a user. In this example, if the
| user unchecked a playlist and dismissed the list of playlists
| while the save was happening, and then the save failed, a toast
| makes sense because the context of the action is gone. Might as
| well put the information at a random spot on the screen.
|
| Even then, a toast probably isn't the best you can do, if you
| really want the user to understand the error. In a the-user-is-
| the-product adware application like YouTube, you probably don't
| care if the user misses errors like these (and might even
| prefer that they do), but in a business application you
| wouldn't want to gamble on the user missing the toast or
| confusing it with a different error. It might be more helpful
| for a normal user if you re-open the element and show them the
| error in context. Open up the list of playlists and animate
| something to draw their attention to the fact that their change
| didn't save. I'm probably getting pie in the sky here, because
| that sounds really difficult to do in a systematic way, but in
| an ideal world, you'd always see errors in context.
| lolinder wrote:
| I get what they were saying and agree that in-context
| feedback should be added wherever possible. I just disagree
| that leaving off the toast is (in the cases cited) valuable.
|
| Taking the archive example: yes, the disappearing message
| successfully indicates that _something_ happened. But it
| doesn 't tell you if the message was deleted or archived, and
| misclicks are common. The toast unambiguously communicates
| _what_ happened in addition to saying _that_ something
| happened.
|
| Additionally, I stand by my argument that consistency is
| valuable. By all means have in-context feedback, but _also_
| pick a standard way that you always use to communicate
| completion of all actions. It makes it a lot easier to
| understand and eventually make use of the in-context feedback
| which may not be as intuitive as you think it is.
| digging wrote:
| > 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 toasts are bad UX:
| creating a new ticket in Jira. Since that can't happen
| instantly, it needs a delayed message to let you know when
| the ticket is created and you actually have a URL to open.
| A toast is _useful_ in this case, but it 's also far from
| optimal, because for some reason it's going to disappear in
| a few seconds, and it also won't tell me how many seconds I
| have left to read it.
|
| Why would _distraction_ be the primary mechanism? We
| figured out decades ago how to put a button in the header
| that opens a messages feed which the user can read and
| dismiss at will. While it 's possible to implement such a
| feed badly so that it's annoying, it's _difficult_ to
| implement toasts in a way that _aren 't_ annoying. Maybe
| even impossible.
| TeMPOraL wrote:
| > _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 flakiness and bloat of entire modern
| software stacks[1]. Maybe "toasts" aren't the bee's
| knees, but they work as lagging indicator that _something
| happened_ that I otherwise wouldn 't notice, and in some
| apps even lets me undo the unwanted operation. That does
| a lot to relieve my anxiety and help me use software with
| less frustration.
|
| --
|
| [0] - That itself is a big antipattern. Software lying to
| user about its state is a form of gaslighting; it makes
| interaction more error-prone, and prevents users from
| building correct mental models of the application and its
| interactions with other systems.
|
| [1] - My Android flagship lags often enough on taps and
| drags that every other day my input gets misinterpreted
| and does something unwanted. Similarly, I type faster
| than most software - webshit in particular - can react,
| so e.g. a small jitter can turn "ctrl+t n e w s <ret>"
| into "ctrl" (held, released) and then "n e w s <ret>",
| which does $deity knows what in the current tab.
| digging wrote:
| > Maybe "toasts" aren't the bee's knees, but they work as
| lagging indicator that something happened that I
| otherwise wouldn't notice, and in some apps even lets me
| undo the unwanted operation. That does a lot to relieve
| my anxiety and help me use software with less
| frustration.
|
| All things that a message log does better than toasts!
| lolinder wrote:
| Why not both? A message log can always be consulted
| later, but it doesn't give you a live feed of things that
| are happening.
|
| I'm also ADHD and, like OP, I appreciate having the
| stream of toasts that lets me know what the software did.
| It's saved my butt a bunch of times when I accidentally
| do something I didn't mean to (deleting instead of
| archiving, for example). A message log would just get
| ignored, but toasts help a ton because they're visible.
| digging wrote:
| A message log can also be visible...? The only
| differences between messages in toasts vs messages in a
| log is that toasts control the user rather than the other
| way around.
| lolinder wrote:
| Isn't a toast just the tail of a message log that's
| visible for a few seconds after a new message is added? I
| don't always want the entire log to be occupying space on
| my screen, but I do want to see when new items get added.
| arcbyte wrote:
| Have you worked with an old person?
|
| Redundancy in UX confuses them. The closer you can get to the
| whole UI being a single sentence and two buttons the better.
| lolinder wrote:
| Yes. And I've never once run into issues with redundancy of
| information being a problem. It's the clever things people do
| to hide information or to be concise that reliably get them
| confused.
|
| > The closer you can get to the whole UI being a single
| sentence and two buttons the better.
|
| Sure, but this is kind of my point--clever UX tricks to
| communicate things without words don't work for them. A toast
| is valuable for the tech-illiterate precisely because it uses
| English text to communicate its point, and having it exist in
| the same spot for every action makes it easier for them to
| pick up.
|
| It's not the be-all end-all of UX design for the elderly, but
| it's a heck of a lot better than the alternatives proposed in
| TFA.
| Sakos wrote:
| Have you?
|
| Things disappearing with insufficient explicit feedback for
| what actually happened to the things is one of the most
| common issues I've encountered with older computer users. I
| think it's _the_ most common issue. Toasts add persistency
| and visibility for users who barely or don 't understand the
| UIs they're interacting with, which makes it easier to
| understand what happened.
|
| If Outlook gave feedback to every user action in a toast,
| then provided a universal history of every toast, you would
| probably resolve a significant amount of issues caused by
| user actions leading to unintended changes (and being unable
| to recognize that the action lead to a particular change, or
| even how the current state differs from the previous one).
| jimmygrapes wrote:
| If Outlook showed a toast for every action I take, I would
| immediately do everything in my power to make it stop, up
| to and including hermitage.
| digging wrote:
| > If Outlook gave feedback to every user action in a toast,
| then provided a universal history of every toast
|
| This is what message feeds are for. Toasts are just a worse
| implementation of message/notification feeds.
| JohnFen wrote:
| > If Outlook gave feedback to every user action in a toast
|
| That would make me utterly crazy. I couldn't use an
| application that did this.
| thomastjeffery wrote:
| Toasts literally disappear..
| dsego wrote:
| > Things disappearing with insufficient explicit feedback
|
| Toasts appear somewhere in the corner and then disappear
| very quickly. Not sure how useful that feedback is. It's
| distracting at best.
| DidYaWipe wrote:
| The whole point is that they DON'T add visbility, because
| they're not presented where the user is working. Age isn't
| even a factor.
|
| It's time to stop blaming "age" when the more likely
| explanation is EXPERIENCE. Many people learned to use
| computers in an age of well-understood GUIs that hewed to
| standards that evolved for very good reasons. For example,
| buttons that were depicted (in a clean, not cheesy
| "skeuomorphic") manner. You can tell at a glance if a well-
| depicted button is on, off, or disabled.
|
| Then enter the idiotic "flat" design fad, where the entire
| screen was an Advent calendar of no controls at all... or
| is it ALL controls? Click on every piece of text and every
| rectangle to look for the hidden goodies.
|
| Those conversant in (and tolerant of) more-recent UI have
| simply become accustomed to shitty UI. They've either
| forgotten how bad it is, or grew up not having experienced
| good design. Another great example that has disappeared in
| many areas is GREYING STUFF OUT. If something is not
| currently usable because it's not applicable, you don't
| just make it disappear. You grey it out, so users can learn
|
| 1. That the function exists 2. Where the function resides
| 3. What conditions must be satisfied to make it work
| neolefty wrote:
| For sure -- I've seen that struggle.
|
| This discussion tells me we have not yet reached perfection
| in UI! Toasts are good for me, but definitely not good for
| the users you and others have described.
|
| My hope is that small AIs inside UX can help here. Can you
| tell your UI framework something like, "Give them a choice
| between X and Y." and then "Clearly indicate they have chosen
| Y." (with a fallback of "Tell them something went wrong, and
| they won't be able to make a choice right now after all.")
|
| Or is it simpler than that, and we don't micro-manage the AI-
| powered UI engine? "Get answers to these questions, and
| submit them to this API." -- and UI engine does all the rest?
| I'm not sure.
|
| Anyway, an improved UI would adapt to the user -- think of
| the way a person providing a service adapts to the customer,
| intelligently and empathetically. For example a teacher
| watching for signs of understanding in a student, adjusting
| explanations. A car salesperson being quick and businesslike
| with one customer and listening patiently to another.
| soneca wrote:
| > _" Redundancy in communication is a feature, not a bug"_
|
| I completely agree with you.
|
| The article kind of confirmed to me that toasts are good UX.
| cynicalpeace wrote:
| I totally agree with you... this is why Java being so verbose
| is actually not terrible either, lmao come after me
| bigstrat2003 wrote:
| Honestly I think the perennial "Java is too verbose"
| complaints are completely overblown, and say more bad about
| the person complaining than the language.
| nkozyra wrote:
| > redundant UX is bad UX
|
| In general, I think the best use of toasts are to present
| options for further action (if needed).
|
| Take the example of deleting an email and getting a toast that
| lets you undo. Your action has already been completed and you
| can see it. But you have more context that can be acted on. In
| this case it's not redundant, even though it relays the action
| you just take.
|
| In this scenario, it's ideal to move this away from the
| viewport the user was in. In most cases, they don't need it.
| But if they do, it's onscreen.
|
| Simple confirmations that do nothing else are redundant. But
| toasts don't have to be used that way.
| adamc wrote:
| 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_.
| berkes wrote:
| Yes! The problem isn't duplication of the message, nor is it
| that they convey slightly different things. The main problem
| is their lack of locality.
|
| We can have an indicator, then some icon or even a green bar
| in the "save this" modal, just fine. Or we can make the
| "archive" icon color different, or add an error, an undo-
| button, or other message next to it if we really need to
| convey this information. This could be a tooltip, something
| in the icon-bar, or anything really: as long as it right at
| the place where I made the change and expected the change to
| show up.
| nativeit wrote:
| 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.
| DidYaWipe wrote:
| It's not standardized. And putting notifications on or
| right next to a control you're INTERACTING WITH is not
| "arbitrary" at all; you must be looking at it, because
| you're using it.
| brailsafe wrote:
| Doesn't it depend on your platform, and isn't
| experimentation the way things _become_ standardized?
|
| User notifications on MacOS are definitely standardized,
| but originally they were Growl notifications until Apple
| made it a first-party API and iterated on it.
| DidYaWipe wrote:
| Some conventions transcend platforms. The aforementioned
| greying-out, for example. And sure, we have to try
| something for it to become a standard. But in the end the
| standards percolate up because they're intuitive. The
| controversy over some of these "toasts" shows that they
| don't meet that bar.
|
| And you are right in that the Growl-style notifications
| in Mac OS are standard now... but those are different
| from the ones in question here because they are not
| related to a control that the user was just manipulating.
| They could come from anywhere at any time, and thus they
| must be presented in a location independent of whatever
| the user is doing.
|
| The Growl-style notifications work well because they're
| near the top of the screen, too. Users are used to status
| and information in menu bars and so forth, in accordance
| with the general top-down convention of presenting
| information.
|
| Thinking it through, I did actually implement a
| "toast"-style alert for asynchronous issues in one
| application. It was at the top of the screen, though. I
| originally put it in there strictly for debugging, but I
| think I might have left it in the release. So I'm not
| entirely opposed to the idea, but mainly its placement in
| the examples discussed here.
| hunter2_ wrote:
| 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.
| cellularmitosis wrote:
| > 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.
| DidYaWipe wrote:
| If the "toast" can persist through that behavior, so can
| feedback positioned more sensibly. How does putting
| something on the other side of the (potentially huge)
| screen solve that "better?"
|
| Not to mention that, if the operation fails, isn't it
| likely that the user will want to re-try? And that'll
| require access to the original control in all likelihood.
|
| If the user scrolls away and the information is important,
| use a modal alert.
| adamc wrote:
| If you can't show me a spinner or other indicator that this
| is an ongoing operation (which I find preferable), and you
| think I will have moved away from the controls for this,
| then put it in a central location that I will see even if I
| am still on your control, not in a little box on the other
| side of the screen.
|
| These toast notifications just are a bad solution. I often
| miss them, because I'm, you know, doing work, not scanning
| my monitors for notifications I mostly don't care about.
| (Redundancy is not harmless. Redundancy also trains me that
| your messaging is mostly noise.)
| pc86 wrote:
| > > But by archiving the email, the email disappears from the
| list, which already implies the action was successful.
|
| Yeah this in particular bothers me. Someone that knows UI and
| UX should also know you can absolutely remove something on the
| front-end without a corresponding action on the back-end. If I
| click archive and the email disappears, that doesn't mean the
| back-end call succeeded or has even been made. How many times
| do you click move/delete/whatever in an app, the thing moves or
| disappears then a second later pops right back in? These things
| happen and the subsequent alert that it was actually successful
| is a good thing in my opinion.
| DidYaWipe wrote:
| You missed the main point, which is that the "toast" is nowhere
| near where you're looking when performing the action.
| lolinder wrote:
| I didn't miss that point, I'm arguing that that point doesn't
| prove anything about the merits of a toast.
|
| Their examples are all arguments of where local information
| should have been displayed. I agree with them in general. I
| just think that a toast should _also_ be displayed in each of
| the situations they identify.
|
| What seems to have happened is that they correctly identified
| a problem with lack of local information and blamed it on the
| presence of non-local information, which is fallacious. You
| can have both, and I believe that a UI with both is generally
| more usable.
| savolai wrote:
| As someone with a human-computer interaction degree, this
| thread deeply saddens me. In general, human-computer
| interaction is considered a field of computer science, which I
| guess hn has a good representatin of.
|
| And yet the discussion here seems to veer off from actual
| verification of whether toasts actually work, and all the
| discussion seems to be purely speculation. Granted, there is
| general argumentation too that's valid to some degree, and it's
| good to present that, and at the end of the day the only actual
| data that can guide this decision for a given user interface
| comes from user testing that is highly context sensitive.
|
| Why? Because there exists no general answer to this question at
| all. It depends deeply on who your users are, and before the
| industry understands this basic fact that we as a species are
| mostly incapable of predicting what different persons from a
| different user group point of view will be, usability testing
| will be critically needed, and until we actually start doing
| it, we will keep creating user interfaces that marginalize
| everybody but ourselves.
| jacknews wrote:
| Sorry I have no idea what he's even talking about after the first
| couple of paragraphs and screenshots, so while I'm very
| interested in good UX, I'm left thinking this author is not an
| expert practitioner.
| snarfy wrote:
| They are bad UX if I can't disable them. I universally hate all
| notifications. Stop stealing my attention. It's cognitive abuse
| bordering on violence. If I want to know I will go look, you
| don't need to shove it in my face.
| lagniappe wrote:
| > It's cognitive abuse bordering on violence
|
| Take a breath
| jasonlotito wrote:
| > The Solution: No Toast
|
| His solution ignores the undo component of the toast. Simply
| adding it back to the playlist is not a solution as that reorders
| it in the playlists. Instead, undo puts it back into the playlist
| where it was. When you have longer play lists, this becomes even
| more critical.
|
| I'd much prefer a consistent way of interact than a bespoke
| unique way of using every UI component. Consistency and
| correctness versus creativity and confusion.
| marcodiego wrote:
| 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, slid the hidden panel from
| the right and showed me what I had to do.
|
| I understand how much this saves space, but it is absolutely
| ridiculous! How does an UX expert expects someone to guess that?
| Are current UI's supposed to be used by people who behave like
| children poking everywhere to discover things?
| ChrisMarshallNY wrote:
| I think most "toasts" (now I know the word for it!) are
| redundant and useless. I usually completely miss them. I think
| they are generally "harmless," but they should not be used to
| convey crucial information.
|
| As for the "hidden panel," I have always assumed that this is a
| bug, but someone may have thought it was a good idea:
|
| I use the Apple Connect App (for managing apps on the App
| Store) frequently.
|
| If I use it on my iPad Mini, in portrait mode (how I usually
| use it), and select one of my apps, the back button often
| disappears, which means that I can't select another account (I
| have several), or another app within the current account.
|
| Until I physically turn the iPad sideways.
|
| Then, a Navigator appears on the left, and I can select other
| apps, or change accounts.
|
| Frankly, I'm really quite disappointed in the whole UX for the
| Apple App Store backend (I'm not so thrilled with the frontend,
| either, but I use the backend all the time). It's a bit
| jarring, when you think about how much care they put into the
| rest of the user experience on the platform.
| JamesSwift wrote:
| Apple's non-hotpath UX (and even UI) is incredibly bad. The
| entire experience configuring icloud and family sharing on a
| Mac is like entering another dimension with no relation to
| the surrounding OS.
| pphysch wrote:
| I think the slide left/right for sidebar is a nice UX, as long
| as the user knows about it, and as long as you don't go beyond
| 1 main + 2 sidebars.
|
| Discord mobile app used to have it for both left and right
| sidebars, and then a while ago someone had a brilliant idea
| that the "slide to reply" gesture was more important than
| navigating the app, and now you have to click a tiny ambiguous
| button to see the right sidebar.
| everybodyknows wrote:
| Fully agree. IOS of course, is full of them, even on tablets
| where screen space is abundant.
| max-throat wrote:
| I remember installing Snapchat one and immediately realizing
| how awful it was. Different _corners_ had different functions.
| It needs to be illegal
| replete wrote:
| Notifications are good. Notifications that are temporally
| disconnected from actions (e.g. debounced, cooled down) are
| suboptimal - but its what people are used to. Getting rid of
| notifications altogether is not an improvement. In his example,
| the notification is basically a confirmation of a direct action.
| Notifications don't always feedback instantly
| toxik wrote:
| Toasts on smartphones are worse, it happens so incredibly often
| that YouTube obscures part of the video that I want to see with
| an unnecessarily large toast to tell me I did a thing. Most
| notably, switching quality. Or just now I enabled a beta test
| feature, it gave me a toast. Why?! I know what I did. The same if
| I click the same button again to disable the feature. At least
| you can dismiss them by dragging them down.
| gherkinnn wrote:
| 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.
| gorjusborg wrote:
| It's hard to agree/disagree on UX without all the application
| and domain context, but I do feel like toasts are valuable when
| you are communicating information to the user that is not tied
| to a fixed UI location/time, but do not want to force
| interaction (like you do with a modal).
|
| I have seen modals used to communicate status and reaffirming
| information that does not require action, and between the two,
| toasts are a better fit. That said, you still need to be smart
| where the bar is in terms of what is worth communicating. None
| of us want applications to blather on about stuff we don't care
| about.
| samsolomon wrote:
| 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?
| sebtron wrote:
| 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)
| baking wrote:
| Should have been called "pop-tarts."
| youssefabdelm wrote:
| They're not fun enough for a name like that
| kzrdude wrote:
| Where does the name toast come from anyway?
| azornathogron wrote:
| Toast "pops up" from the toaster when it's done.
| gertrunde wrote:
| That does make a certain amount of sense... much more sense
| than https://en.wikipedia.org/wiki/Toast_(honor) which for
| some weird, unexplainable reason my brain had decided was
| where the name came from...
| JohnFen wrote:
| In all of the years I've been dealing with "toasts", I
| never realized this until just now. I always thought it was
| some kind of weird reference to toasting with a drink or
| something.
|
| Update: On consideration, I think my disconnect was because
| the plural of the notification method is "toasts", but the
| plural of the recooked bread slices is "toast". The plural
| of benedictions given prior to a drink is "toasts". So I
| mentally connected up with that.
| stoperaticless wrote:
| I assume based on this
| https://en.m.wikipedia.org/wiki/Toast_(honor)
|
| > A toast is a ritual during which a drink is taken as an
| expression of honor or goodwill.
| inopinatus wrote:
| It was originally the name of a popular CD burning
| application for the Mac. Only much later, following the
| discovery of bread, did the term become popular for
| describing a slice browned by radiant heat.
| marssaxman wrote:
| Thank you! That did puzzle me, especially because I had pulled
| some bread out of a toaster just seconds before sitting down to
| read Hacker News this morning.
| FatalLogic wrote:
| It's ironic that a person writing about poor communication
| paradigms didn't explain what "toast" means here.
|
| It's the most important word on their page, and it's obvious
| that some people, even technically-minded folks, don't
| understand the jargon.
|
| But could be they got extra engagement from readers who are
| interested in baking and breakfast recipes?
| CRConrad wrote:
| 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.)
| hunter2_ wrote:
| 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
| xyst wrote:
| the brew creator was just really into beer crafting.
|
| I probably do the same with some of my passion projects
| without realizing it
| zahlman wrote:
| It seems like they put a lot of effort into trying to
| create a coherent extended metaphor, yet it doesn't make
| any sense. You create a tap by putting bottles and casks
| together, and then it puts itself into a keg? Your own
| cellar is a prototype for someone else's keg?
| dang wrote:
| 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.
| Brosper wrote:
| OMG yes! I feel the same. I think that sometimes product owners
| don't use the products.
| supportengineer wrote:
| Result of promo-driven culture
| agumonkey wrote:
| Reminds me that old programs, be it Maya, Emacs, or even MFC days
| had a status bar for most simple notifications.
| JohnFen wrote:
| Status bars are a far superior option for this sort of thing
| than toasts. As another commenter said, toasts appear to be a
| UX compromise that was necessitated by mobile (where a status
| bar is tough), but has sadly infected desktops as well.
| loughnane wrote:
| > 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.
|
| Double-encoding information is good if the information is really
| important so long as the two ways you encode it always and only
| appear together. You see this in data visualization a bunch
| (think a bubble chart where larger circles also become a more
| saturated red).
|
| Sure it doesn't satisfy some platonic ideal of purity, but for a
| distracted user it can lessen their cognitive load and so can be
| good UX.
|
| The point about distance is interesting. Toasts popping up near
| the action could be neat.
| layer8 wrote:
| For me the worse aspect is that they disappear (too quickly), and
| that they sometimes unnecessarily draw attention to themselves
| for success messages where you would trivially assume the action
| to succeed. The combination of the two is particularly vexing:
| Your attention gets unnecessarily diverted, but you don't know if
| it wasn't actually important because it disappeared too fast.
| Conversely, there's also a variation where it stays on screen too
| long, obscuring a part of the UI you just wanted to see/use in
| that moment.
|
| I like the traditional desktop approach where error messages are
| shown modally, so can't be missed, and success messages are shown
| as normal unobtrusive text in the permanently displayed status
| bar, without timeout. When not getting an error modal, the user
| can simply assume that the action succeeded, but can look at the
| status bar for confirmation (plus potentially some auxiliary
| information), without any time pressure.
|
| Some applications also offer a popup showing the history of
| status bar messages. In that approach, the status bar is like the
| last line of CLI terminal output, and you can call up previous
| output.
| hk__2 wrote:
| > For me the worse aspect is that they disappear (too quickly),
| and that they sometimes unnecessarily draw attention to
| themselves for success messages where you would trivially
| assume the action to succeed. The combination of the two is
| particularly vexing: Your attention gets unnecessarily
| diverted, but you don't know if it wasn't actually important
| because it disappeared too fast. Conversely, there's also a
| variation where it stays on screen too long, obscuring a part
| of the UI you just wanted to see/use in that moment.
|
| Agreed; a better solution would be to assume success and show
| these messages only if an error occured.
| acjohnson55 wrote:
| To me, the imply that there's a hypothetical event log that I
| could view if I needed to look back to see what happened. In
| reality, that event log doesn't exist in an accessible way, and
| it's true that once the toast message times out, it's gone
| forever.
| layer8 wrote:
| The log is just an optional added feature. The main point is
| for the current/last message not to disappear by itself, and
| to be displayed in a non-distracting and non-obstructive way.
| JohnFen wrote:
| That's a decent list of some of the problems with them. Toasts
| are my second most hated UI element. The ribbon is my most hated.
| jFriedensreich wrote:
| As always when there is a clickbaity title that you think cannot
| be true it just lacks any nuance. Toasts are for displaying
| updates on things that happen OFF SCREEN, eg when doing something
| that takes a while and navigating to another screen. In addition
| toasts require a home for context to work propperly. This can
| either be a stack of toasts for very simple applications or a
| notification sidebar that can be accessed from a bell icon or
| similar. Toasts need to be shown close to this entry point to
| their home, not on an opposite position of the screen. The 2 most
| common mistakes are: a) show toasts for things that happen on
| screen instead of showing feedback in the actual action UI (its
| fine to keep them in addition for consistnecy) b) not have a home
| where a user can see what happened combined with autohiding
| toasts after a few seconds. (i cannot count how often i saw some
| dangerous looking error toast but could not read it in time,
| leaving me with a bad feeling especially for important things
| like admin UIs)
| authorfly wrote:
| If I am honest, the main reason I use toasts at first is because
| it ensures mobile compatibility. The problems with mobile UI
| (dismiss X offscreen, feedback off screen, user refreshed the SPA
| app page ruining state etc) are less likely to occur with a
| toast. They also bring some element of tolerable, expected
| animation (like 'page loader bars') which newbies often miss, and
| make the experience less jarring as a result.
|
| Yes it's not great UX but it functions consistently well.
| Although 80% of the applications we use day-to-day may be by big
| corps with excellent UX and time to spend on it, 80% of
| applications built never get round to even consistent and fairly
| error-free UX. So I consider reaching that stage more important
| that adhering to a beautiful, but more risky, cross-platform UX
| strategy when in early stages with limited resources.
| l5870uoo9y wrote:
| In the examples shown, toasts are misused to display low-quality
| notifications, e.g. "x has been copied!". Using toasts to display
| relevant error messages alleviates several problems:
|
| - they work well in an otherwise cluttered user interface (error
| messages often break layouts)
|
| - they allow the data layer to be substantially simplified, e.g.
| no need to store errors, error setters, error getters in Redux or
| similar
|
| - they allow programmers to implement error handling toasts once
| and use everywhere
| krysp wrote:
| I really like the short and visually descriptive layout of this
| article. It clearly conveys the message. I'm not in agreement
| that toasts are always bad though.
|
| It can be useful to follow an expected pattern; users are likely
| to understand that a toast gives feedback for an action they have
| taken. Although other ways exist to accomplish this, they will
| follow different formats depending on the action (by necessity).
|
| As with lots of design, expected patterns change over time.
| Although they are non-local, toasts are familiar.
| dagmx wrote:
| I think the actual issue is that Google makes bad UX often, and
| not toasts in general.
|
| Toasts themselves can be done well, but like every UI and UX
| element, they need to have some thought.
|
| I know Google have some good UI (sometimes UX on Android) every
| now and then but they are so fractured as a company, with so much
| product and feature churn, that their UX is all over the place.
|
| Every single Google app reinvents how things are done or
| communicated. Even within an app, it'll do things differently
| because different teams implemented different features in the app
| since sections of an app might be shared with other apps.
|
| Even Samsung offer a more cohesive experience. The most Google
| try and do is introduce new design guidelines every few years and
| then promptly have teams break them. Material design? Material
| You? Both barely touched UX but even with their own incredibly
| straight forward design rules, Google couldn't adhere to them.
| JamesSwift wrote:
| > I think the actual issue is that Google makes bad UX often,
| and not toasts in general.
|
| Yeah, its wild because they were the ones who introduced the
| pattern to the general audience. And it was so successful that
| others started integrating it in non-material contexts. Toast
| and toast + action are here to stay, and for good reason, but I
| think google has individuals willy-nilly making design
| decisions and not quite being fully aware of how these elements
| should be used.
| throwway120385 wrote:
| I completely agree. Every time I open any Google product it
| takes me a good 60 seconds to figure out that the hamburger
| menu is not where I go to create a new sheet/doc/slides. And
| then I have to scan around the screen for another symbol that's
| on the complete opposite corner of the screen and tastefully
| hidden away. It's very frustrating. 95% of the time when I go
| to sheets.google.com I go there to create a sheet, and their
| information hierarchy prioritizes looking at existing sheets,
| then navigating to another product, and then everything else,
| and then finally creating a document.
| hddqsb wrote:
| I thought this was going to be about Android (which makes heavy
| use of that term), and I was expecting completely different
| complaints:
|
| - The toast disappears quickly, so you might not have time to
| read it / take a screenshot
|
| - It's not possible to copy the text
|
| - Long text is truncated (e.g. exception messages)
| INTPenis wrote:
| If you're analyzing the youtube UI I can show you a lot worse
| issues than the toasts lol. That's a minor issue. I consider
| myself a heavy youtube user for over a decade and to summarize;
| Youtube doesn't care about UX.
|
| Yesterday they added a sleep timer, yesterday! A feature that
| shouldn't take more than a day to develop. But it's highly
| valuable to a large number of users, Youtube doesn't care. Good
| UX is only valuable as long as they can make a profit from it.
| KTibow wrote:
| I wouldn't want to implement the suggested YouTube UI (menu
| showing up next to button) because it's the kind of thing that
| has the most potential to glitch out. Dialogs generally don't
| glitch out as they're absolutely positioned and can be handled by
| the browser.
| JamesSwift wrote:
| Basically all of these are examples of 'bad UX is bad UX'. Sure,
| don't show a toast when another confirmation already appears. And
| dont make them async to appear. And dont include undo for
| something that is able to be easily undone. The toast for archive
| with the 'undo' _is specifically when you should be using this_.
|
| For context, I'm coming from the world of native apps. Toasts
| overall, especially with the 'undo' action, have been a very
| useful contribution by Google to UX. Compared to iOS's "show a
| blocking popup in the middle of the screen", they were so much
| nicer. Like I said, the "undo" for cases like the archive example
| are the whole point! Instead of asking "are you sure?" for
| everything, you just delay the action and offer an undo. Default
| to the user being sure they wanted to perform that action and
| dont gatekeep their flow. Dont overuse it, but dont blame its bad
| uses on the toast itself.
| icar wrote:
| I completely agree that it being far away from the interaction
| point is bad UX. That said, toasts by themselves are not bad, it
| depends where they are.
| seanvelasco wrote:
| I only use a toast for displaying error messages that otherwise
| displace UI elements on the page
|
| I never found toasts to be bad UX
|
| effective use of toasts is to confirm to that a big change that
| they initiated was successful. for smaller changes, like checking
| or unchecking a checkbox, toasts are redundant
| KenArrari wrote:
| I think a lot of this makes sense when it's made for mobile,
| while desktop users are using increasingly large monitors.
| wruza wrote:
| Taking youtube as an example is like taking a dead horse to a
| race. Youtube is an utter garbage ux-wise, both in bugs and
| features. Even fringe porn tubes are 10x more competent than
| youtube ui team.
|
| Their latest "addition" was rewinding a video after a long pause.
| You watch a video, pause it at t=1:24:57 and go to sleep. Next
| day you start the video again and it goes for a while from t to
| t+n (depends on the buffered data), until it jumps back to t-20s.
|
| Someone thought it's a good idea to -20s after a long pause, and
| it might be good, if they assigned a proper developer to the
| task. Instead someone pushed an obviously idiotic change, without
| anyone checking. It's not even an issue, it's clearly "job done"
| by someone who couldn't give a lesser fuck due to ieee754
| limitations.
|
| You cannot avoid that behavior. If you go forward/back or
| manually jump elsewhere, it still resets you to t-20s shortly
| after. You might think you just reload the page, but reliably
| saving the current position is not in their competence either.
|
| That and a dozen other stupid bugs they fiddle with constantly
| but can never fix. Literally on a site with a sidebar and a grid
| of equally-sized elements. Their thumbnail card alone takes 7.5
| pages (17KB) of html.
| ziml77 wrote:
| I don't think there's any feature there with the video jumping
| back. That purely seems to be a bug where it fails to resume
| the connection to the server to continue filling the buffer. It
| seems to hit the end of what is buffered and then refresh,
| causing it to jump back to some last saved position.
| jmull wrote:
| HM...
|
| The redesign of the "Save" operation _is_ better than the
| original, where the checkbox list is positioned in context, and
| there is an indicator for the async operation.
|
| But I think it would be better if it kept the toast. When the
| operation completes successfully, presumably the async indicator
| just disappears. That has no impact and a toast fixes that.
|
| Also, presumably the operation can fail. I suppose you'd replace
| the async indicator with a red X or something, and maybe revert
| the checkbox. But it would be useful if there could be a textual
| description of what went wrong, and a toast is a nice and
| consistent way to present that.
| hermitdev wrote:
| Just wait until the author sees the toasts in MS Teams. I expect
| his head will explode.
|
| Teams has, hands-down in my opinion, _the_ worst usage of toasts
| that I've seen. It's bad enough I get the OS toast from Teams,
| that may or may not disappear on its own after a time (on both
| Windows and Linux). However, there's also an in-app toast that
| blocks part of UI that is used the most: replying to messages.
| Literally, typing a reply, then boom, toast appears, blocks most
| of the buttons used to interact with your reply. (formatting,
| emoji/gifs, attachments and even the reply button!)
| TehShrike wrote:
| I agree with the article, but I think there's a greater principle
| here that it misses - UI that obscures other UI is bad UX.
|
| It's a lazy cop-out to avoid having to figure out how to
| integrate important elements into the design of your page.
|
| I find Google/Material Design's floating action buttons very
| frustrating.
| thomastjeffery wrote:
| It may not be as fun or polished, but a _log_ is much much better
| UX.
| plorg wrote:
| My biggest annoyance with toasts is when they are undismissible
| and cover other UI elements. Instagram (in their menu system) is
| a particular offender.
| adamc wrote:
| Good piece. I've experienced this in many contexts, and
| widescreen monitors make it a bigger problem.
| ilrwbwrkhv wrote:
| Toasts which incorporate movement such as slide up are far more
| noticeable compared to fade in toasts since human vision is far
| better at recognizing movement. Even on large screens it is
| pretty good.
| Spivak wrote:
| 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 don't know
| how to design an actually good UI to convey that." And having a
| UI element for that is pretty darn useful because of how often
| that situation comes up. All of our default UI metaphors
| buttons/checkboxes/input boxes are all synchronous-- either
| updating local state to be saved synchronously with a button or
| synchronously in real time (like setting a preference cookie).
| It's just that the web forced async-by-default on everyone
| without updating anything else.
|
| If you show a user a checkbox it's absurd that such a thing can
| fail or not apply immediately, you're emulating a paper form, how
| does checking a box fail? Same with flipping a switch. Even if
| the light doesn't come on the switch is still flipped. None of
| these elements make sense to be backed by a request/response.
|
| In the example in the article when the user changes one of their
| settings a save button appears, when you click it there's a
| progress bar or spinner, and when it finishes it says "Saved!" We
| figured this out in Windows 95. Quit trying to hide the form
| submission. The need for toasts is trying to tell you your
| abstraction is leaking.
| Blot2882 wrote:
| > 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?
| h1fra wrote:
| 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.
| whartung wrote:
| 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.
| GuB-42 wrote:
| In this case, this is a video game, it isn't meant to be
| productive, it is meant to be awesome, and an excessive number
| of toasts can be awesome, especially during an excessive event.
|
| The problem here is not that there are too many toasts, it is
| that they are annoying. Having a stylish way of dismissing them
| all could turn that annoyance into something awesome.
| brailsafe wrote:
| Hang on, there's a few inaccuracies here (I think, since I only
| played mainline Dragonflight but not Remix, but at a relatively
| sweaty level for a non-competitive m+ player)
|
| > They dominate roughly 30% of the screen real estate (when
| presented in volume), smack in the center.
|
| Pretty sure this is customizable. My loot toasts are relatively
| discrete, I can put them wherever.
|
| > 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.
|
| This sounds to me like you're using the addon SilverDragon
| which is deliberately obnoxious about alerting you to rare
| monsters, but with it you can control every aspect of the
| alert, when/where they occur, or disable them entirely.
| Ennea wrote:
| 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...
| taeric wrote:
| 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?
| lproven wrote:
| 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.
| steve_adams_86 wrote:
| I think there's a critical distinction to make here.
|
| Some UI can model what the users interacting with accurately
| enough that updating the state of the model is a great way to
| communicate changes. If you remove an item from a list, you can
| demonstrate success through that interaction without using a
| toast.
|
| On the other hand, sometimes the UI doesn't reflect the model at
| all and there's no sensible way to communicate with the user what
| has occurred outside of something like a toast.
|
| The trouble is, you get inconsistent feedback mechanisms if you
| leverage both online feedback and toast feedback.
|
| If this was an easy problem one way or the other, I'm fairly
| confident we'd have seen a convergence of implementations at some
| point and everyone would use a fairly common convention. It's not
| that easy, though.
|
| Good UX is really hard. People thinking it's this simple are
| actually why I stopped doing it as much. Back end programming
| gives you so much more freedom to explore problems and people
| respect it to some degree. With UI/UX, especially UI design,
| everyone seems to think they know better already.
| xyst wrote:
| I hate toasts too. I even dislike the name of this UI element -
| "toast". Unlike a hamburger menu, the toast element doesn't even
| resemble toasted bread slice. Or is it supposed to represent the
| short lived aspect of a toast between 2 parties?
|
| Some sites even have toasts on mobile which block content. Have
| even tapped some of those actions by accident.
|
| Also, since they are ephemeral. How does it impact a user on a
| screen reader? Is there an audio cue indicating a toast is on the
| screen?
| codazoda wrote:
| I think they are called toasts because they pop up from the
| bottom, similar to a piece of toast popping out of a pop-up
| toaster oven.
|
| I used these to display errors in an internal web app once,
| which was a major mistake. The users almost never saw them and
| when they did they didn't see them long enough to be able to
| communicate what the message said, often trying to paraphrase.
|
| I agree they are bad UX for most things.
| JamesSwift wrote:
| > The users almost never saw them and when they did they
| didn't see them long enough to be able to communicate what
| the message said, often trying to paraphrase.
|
| Theres an art to writing terse copy for the toast, and
| picking durations that make sense. I think this is likely
| more a poor application of the pattern rather than the
| pattern itself being bad.
| codazoda wrote:
| It's extremely easy to get the "art" wrong. In my case, I
| didn't always know what the errors were because they were
| returned from 3rd party API's and many of them the
| application had never seen before. If there were a proper
| log somewhere, maybe, but toasts are very easy to use
| poorly.
| apeescape wrote:
| I think it's called a toast because it (usually) appears by
| jumping from one of the edges, like a piece of toast jumps from
| the toaster.
| lawgimenez wrote:
| This is called a Snackbar now.
| cryptonector wrote:
| 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.
| jeroenhd wrote:
| 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).
| cryptonector wrote:
| Right, so the issue is placement, not really toasts. I would
| prefer the pop-over you mention to toasts, but I definitely
| don't want to lose asynchrony.
| mlsu wrote:
| 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
| switchbak wrote:
| 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!
| yieldcrv wrote:
| _those_ toasts are bad UX
| game_the0ry wrote:
| IMO, not a great take.
|
| Author's alternative suggestion isn't that that great either -
| the problem with having a loading indicator next to an actionable
| item in a list is that if you get an error, it would be difficult
| to communicate what went wrong to the user (if you wanted to do
| that).
|
| If the author considered why services like Google and almost
| every UI library, from Bootstrap to MUI, has some sort of
| toast/alert message, then I think the argument of toasts as bad
| UX could be better articulated.
|
| Seems like author's take is more personal opinion than analytical
| conclusion.
|
| Personally, I like the UX of toast + alerts.
| bluesmoon wrote:
| I came here thinking there was a new recommendation for making
| toast, or at least a recommended type of bread to use, but I
| found nothing edible.
| leke wrote:
| I think it's a middle path thing. I like toast error messages but
| for simple confirmation actions like Saved, Deleted and Copied,
| the text change is better. HTMX makes this really easy to do :)
| quectophoton wrote:
| I like error messages that I can copy-paste without worrying
| that they might disappear too fast, or worse, when I click on
| it. Also error messages that I can screenshot to show someone
| else without having to hurry because it might disappear after
| 50ms.
| fortran77 wrote:
| Watching my 91 year old mother try to use a computer, I can see
| that messages that flash up and then disappear are extremely bad
| for individuals with slower reaction and processing times.
| dejawu wrote:
| The worst toast I've seen is on Android Auto (itself already a
| veritable petri dish of awful UX) where, when the on-screen
| keyboard appears, a toast helpfully pops up informing you that a
| keyboard is also available on your phone... Thus blocking the on-
| screen keyboard from being used until the toast fades (and no,
| tapping it does not dismiss it).
| einpoklum wrote:
| Somehow, those YouTube "toasts" always manage toi come up over
| the play control, when I need to use the controls. I think
| they're magic.
| rkagerer wrote:
| Toasts would be alright if they showed up in a dedicated portion
| of the UI (eg. status bar) which had a notification history so
| that you don't feel like you're racing a clock to read an
| unwanted popup trying to steal your attention.
| athom wrote:
| You want to know what's REALLY bad? When the whole TOASTER pops
| up in your face!
|
| Here's the deal: I maintain a boatload of Visual Basic (yeah,
| yeah) in Autodesk Inventor. That program REALLY wants to make
| sure you're saving regularly, so if there's a document open
| that's been changed and left unsaved for awhile, it pops up a
| notification. This is fine when you're working on the model, and
| you just see this "toast" popping up in the corner. You make a
| note of it, maybe divert to the save icon, and get right back to
| work.
|
| On the other hand, if you happen to be using the VBA environment
| when Inventor decides you need a reminder, it absolutely insists
| on slapping ITS window over top of it, so it can notify you Right
| Now! That includes grabbing focus, of course, which leads to all
| sorts of fun when you're in the middle of typing, and suddenly
| find yourself starting You-Don't-Know-What-Command on the model.
|
| Fun times.
|
| So, yeah, "toasts" can get annoying, but grabbing focus... THAT's
| when the trouble starts.
| spandrew wrote:
| There are a lot of calendar mods I've made in GCal that I wanted
| to UNDO, but couldn't because it had evaporated by the time my
| cursor got to it.
| oasisbob wrote:
| > What's worse than a toast? No feedback at all.
|
| I'd argue that the YouTube iOS app found a more worse toast: the
| confirmation toast for removing videos from a playlist covers the
| original menu which triggered the action in the first place.
|
| Makes it very hard to perform the same action repeatedly.
| boraoztunc wrote:
| LinkedIn toasts are the worst.
| dang wrote:
| https://en.wikipedia.org/w/index.php?title=Toast_(computing)
| bbb651 wrote:
| Terrible article imo. You can't approach UI from the perspective
| of a developer using the UI you just wrote, you need to think
| about it from a user's perspective. That sometimes means having
| redundancy in the name of familiarity and legibility.
|
| I agree YouTube example is pretty bad, but the gmail one is a
| really good use of a toast! What do you mean "you can see the
| email is removed from the list"?? Have you ever used email
| before? You usually have more than 3 messages, and seeing which
| one was removed, let alone that one was removed at all is not
| always obvious. And "undo" is incredibly important since you
| don't have direct access to the removed item (and sometimes it's
| a time sensitive action like undoing sending an email). The last
| one is not very helpful but not harmful either.
|
| Also even if all the the examples were truly horrible and
| despicable uses of toasts, 3 bad examples are not enough to say a
| commonly used UI pattern is outright "bad".
| justinl33 wrote:
| counterargument: toast is unobtrusive by design. it's not part of
| the main workflow, and not causing the user to context switch.
|
| +1 to screen readers
___________________________________________________________________
(page generated 2024-08-20 23:00 UTC)