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.
To add to this. Some of them show important information the user needs, but it both disappears too quickly, and is incomplete, due to size limitations of the toast.
I often will click into my notifications to see what I missed (I knew it looked important, but I didn’t have enough time to read it all). When I get there I will click on what looks like a truncated message, with the expectation that it will take me to the full context. Instead, the notification disappears, so I lose it, and it opens an app without deep linking to the issue. I’m then left hunting around to try and find a problem, which may or may not be surfaced, in the app’s standard UI.
This has happened more times than I’d care to count and it always leave me upset with whoever designed these systems.
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.
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.
As a thought experiment, how long should a toast remain on the screen? Ideally you want the user to have time to read it, but since you don't know how long it will take for them to glance up, and you don't know their reading speed, there isn't a safe bound.
I ran into this with my son just today, he is working on his reading speed and we were using a new app together. I kept showing toasts and he was struggling to keep up with them and found them to be distracting. I ended up reading them aloud so he could keep up. A more persistent message would have let him succeed without extra support.
MacOS and phones do this well, the toast is up for what feels like enough time to read it, but if you didn’t catch it, you can slide open the notifications ui and see all the previous ones for as long as you want.
> 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.
The absolute worst implementations of toasts are ones that actually block user interface elements which become invisible and un-clickable until the toast goes away.
Toasts that only appear for 500 ms are bad UX because the cognitive processing time of people varies widely, and they are incompatible with more people who have disabilities. Furthermore, they are hard to see on very large screens or when that corner is clipped on a desktop browser window that is partially off screen.
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.