231–240 of 401 posts
Earlier quoted context omitted.
How so?
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.
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 t…
> 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 operat…
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 scr…
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…
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.
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 und…
OP doesn't actually identify what is problematic with the toasts! The `The Problems with the YouTube Toast` section merely describes what OP sees, not what is bothersome to OP. I'm guessing that the issue is all the different locations on the page where things happen: the control, the dialog, and the toast are all over the place, thus maybe that is distracting to OP. In that case the issue is about UI element placing…
While I'm in favour of asynchronous feedback like this, placing toasts nowhere near the button you've clicked is confusing when you get to bigger monitors. A toast in the bottom left on a large, widescreen 4k monitor can literally be half a meter away from the place you clicked, so the toast might as well not have been there. I myself have lost the progress notification for a file copy in KDE because it was placed al…
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 und…
> 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.
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.
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.
Earlier quoted context omitted.
Should complex websites have a notification center where you can look at prior notifications? Would this be alike enough to existing desktop metaphors to be easily recognizable or simply confusing. Maybe your browser should could have an icon for same instead making it more standardized across different sites.
I'd go for an action log . It's almost the same thing, but notifications imply ephemeral pokes about some of the stuff that happened, mixed with engagement boosting spam - there's a lot of unpredictability embedded in this concept, as the app is usually trying to guess what you may (or it thinks you should) find relevant. An action/activity log is just a reverse-chonological log of things that happened. You could mak…
Earlier quoted context omitted.
> 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 operat…
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.
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.