I generally agree. In addition to the proposed toast replacement for networked bits of UI, in some cases even that becomes unnecessary if the app is designed in an offline-first manner that...
I generally agree. In addition to the proposed toast replacement for networked bits of UI, in some cases even that becomes unnecessary if the app is designed in an offline-first manner that resolves things like the odd failed network call silently unless there are repeated failures (after which the user is offered continued attempts at automatic reconciliation).
For toasts intended to provide a way to undo, I believe the better design is to make it hard for the major/destructive action to be accidentally performed in the first place, greatly reducing the chances of accidental triggering. It's also completely unnecessary in desktop apps where ideally you should have an Edit menu with its standardized Ctrl/Cmd-Z Undo that doesn't have a timer on it, as well on mobile platforms when an external keyboard is connected.
I used to have a similar viewpoint, but John Carmack (of making games fame) made the argument on Twitter recently that rather than making it hard to do the bad action, we should try and make it...
For toasts intended to provide a way to undo, I believe the better design is to make it hard for the major/destructive action to be accidentally performed in the first place[...]
I used to have a similar viewpoint, but John Carmack (of making games fame) made the argument on Twitter recently that rather than making it hard to do the bad action, we should try and make it easy to undo the bad action instead. He was talking about acting immediately on mouse press (as opposed to waiting for mouse up, which is usually the default), which I don't know that I fully agree with, but then pointed out that this isn't a problem if it's always easy to undo the action just performed.
In this regard, we're thinking of adding undo toasts to a project at work to make this undo process easier. There's already an undo system in place, but users aren't always aware that it exists or so comfortable using it, so when they do "big actions" (actions that would result in the loss of data or take a long time if you had to manually redo all that work), we'll show a little toast that (a) confirms that the action has been completed, and (b) gives them an immediate button to click if they want to go back and undo.
The benefit of this is that we can remove a bunch of confirmation dialogs, which means that people can get stuff done more quickly, particularly if there's a bunch of elements that need deleting.
That said, I agree that toasts should be used with a lot of caution, and only where they make sense.
Personally, I find it more irritating to have to undo things that I accidentally did and so I’d say I’m still inclined towards preventing slipups in the first place, especially if I’m using an app...
Personally, I find it more irritating to have to undo things that I accidentally did and so I’d say I’m still inclined towards preventing slipups in the first place, especially if I’m using an app for the first time and don’t know that I should be watching out for expiring undo buttons — it’s easy to miss those when attention is split.
I suspect this probably depends on how easy it is to undo things. If it's always there - like in Excel or a similar desktop application - then it's easier to rely on it and therefore easier to...
I suspect this probably depends on how easy it is to undo things. If it's always there - like in Excel or a similar desktop application - then it's easier to rely on it and therefore easier to remove the confirmation dialogs. Whereas if the notification is the only way to undo an action then yes, that's fairly irritating.
Lack of ease of undoing certainly makes it more frustrating, but removing things like confirmation dialogs and extra modifier keys on shortcuts, to me, feels a bit like removing sharp turn and...
Lack of ease of undoing certainly makes it more frustrating, but removing things like confirmation dialogs and extra modifier keys on shortcuts, to me, feels a bit like removing sharp turn and stop ahead signs on a winding, forested mountain road. Obviously the magnitude of the fallout isn’t going to be nearly as severe, but the feeling of scrambling to fix resulting error is similarly not great and makes any benefit feel dubious.
I am however a believer in “don’t show this next time” checkboxes in dialogs, along with a “reset warnings” button in settings. This lets users opt out of dialogs on a per-dialog basis, leaving the guardrails in place where the user finds them most valuable while waiving them elsewhere.
I find toast notifications useful for actions I didn't take (like a scheduled task or listening event), or that I was waiting on while doing something else. Bazarr scanning for subtitles and...
I find toast notifications useful for actions I didn't take (like a scheduled task or listening event), or that I was waiting on while doing something else. Bazarr scanning for subtitles and ticking through the list of movies/shows, duty finder/ready checks from FFXIV, new plugin updates available, file transfer completion while I'm doing other tasks, etc.
But it seems like a similar issue as hamburger menus. Some useful cases, but widely implemented in ways they shouldn't be, as the author points out. (Looking at you, GNOME/GTK apps)
Edit: apparently toasts are distinct from snackbars, with the distinction being toasts are non-interactable whereas snackbars are.
This is a tangent, but am I the only one who thinks UX designers keep making stupid names for things? Toast notifications, hamburger menus… and I’m still a bit upset that they are calling GUI “gooey”.
This is a tangent, but am I the only one who thinks UX designers keep making stupid names for things? Toast notifications, hamburger menus… and I’m still a bit upset that they are calling GUI “gooey”.
While i balked at hamburger menu as one of the dumbest things I'd heard, i've seen in person how much more effective it is than any nomenclature I was using when trying to teach to people who are...
While i balked at hamburger menu as one of the dumbest things I'd heard, i've seen in person how much more effective it is than any nomenclature I was using when trying to teach to people who are less UI inclined.
The concept needs to be taken out back and shot, then buried in a shallow grave, the gravesite nuked, and the whole planet dropped into a black hole. But as long as it exists, "hamburger" is...
The concept needs to be taken out back and shot, then buried in a shallow grave, the gravesite nuked, and the whole planet dropped into a black hole.
But as long as it exists, "hamburger" is definitely the right name for it.
Sure, but in my experience they screwed up almost every other name I used for it just as much. The difference was that hamburger menu they actually remembered a month later when I had to do it again.
Sure, but in my experience they screwed up almost every other name I used for it just as much.
The difference was that hamburger menu they actually remembered a month later when I had to do it again.
Sure, initially, until you explain what the hamburger menu actually is and why it's named that way and it'll stick. Don't underestimate the power of recognizable facsimiles.
Sure, initially, until you explain what the hamburger menu actually is and why it's named that way and it'll stick. Don't underestimate the power of recognizable facsimiles.
Huh, didn't know those had a name. I will say that the "undo" on those have saved me a number of times. Mainly on mobile, when I close a tab (or a group of tabs) by accident. The undo is probably...
Huh, didn't know those had a name. I will say that the "undo" on those have saved me a number of times. Mainly on mobile, when I close a tab (or a group of tabs) by accident. The undo is probably the most useful function they have.
Actually, they just seem generally more useful on mobile than desktop since it's such a small screen comparatively. They're not as far out of the way, and it's much easier to make a mistake when trying to tap something.
I generally agree. In addition to the proposed toast replacement for networked bits of UI, in some cases even that becomes unnecessary if the app is designed in an offline-first manner that resolves things like the odd failed network call silently unless there are repeated failures (after which the user is offered continued attempts at automatic reconciliation).
For toasts intended to provide a way to undo, I believe the better design is to make it hard for the major/destructive action to be accidentally performed in the first place, greatly reducing the chances of accidental triggering. It's also completely unnecessary in desktop apps where ideally you should have an Edit menu with its standardized Ctrl/Cmd-Z Undo that doesn't have a timer on it, as well on mobile platforms when an external keyboard is connected.
I used to have a similar viewpoint, but John Carmack (of making games fame) made the argument on Twitter recently that rather than making it hard to do the bad action, we should try and make it easy to undo the bad action instead. He was talking about acting immediately on mouse press (as opposed to waiting for mouse up, which is usually the default), which I don't know that I fully agree with, but then pointed out that this isn't a problem if it's always easy to undo the action just performed.
In this regard, we're thinking of adding undo toasts to a project at work to make this undo process easier. There's already an undo system in place, but users aren't always aware that it exists or so comfortable using it, so when they do "big actions" (actions that would result in the loss of data or take a long time if you had to manually redo all that work), we'll show a little toast that (a) confirms that the action has been completed, and (b) gives them an immediate button to click if they want to go back and undo.
The benefit of this is that we can remove a bunch of confirmation dialogs, which means that people can get stuff done more quickly, particularly if there's a bunch of elements that need deleting.
That said, I agree that toasts should be used with a lot of caution, and only where they make sense.
Personally, I find it more irritating to have to undo things that I accidentally did and so I’d say I’m still inclined towards preventing slipups in the first place, especially if I’m using an app for the first time and don’t know that I should be watching out for expiring undo buttons — it’s easy to miss those when attention is split.
I suspect this probably depends on how easy it is to undo things. If it's always there - like in Excel or a similar desktop application - then it's easier to rely on it and therefore easier to remove the confirmation dialogs. Whereas if the notification is the only way to undo an action then yes, that's fairly irritating.
Lack of ease of undoing certainly makes it more frustrating, but removing things like confirmation dialogs and extra modifier keys on shortcuts, to me, feels a bit like removing sharp turn and stop ahead signs on a winding, forested mountain road. Obviously the magnitude of the fallout isn’t going to be nearly as severe, but the feeling of scrambling to fix resulting error is similarly not great and makes any benefit feel dubious.
I am however a believer in “don’t show this next time” checkboxes in dialogs, along with a “reset warnings” button in settings. This lets users opt out of dialogs on a per-dialog basis, leaving the guardrails in place where the user finds them most valuable while waiving them elsewhere.
I read this comment in the context of real toasts people make in social situations. Up to a point, it holds up quite well.
I find toast notifications useful for actions I didn't take (like a scheduled task or listening event), or that I was waiting on while doing something else. Bazarr scanning for subtitles and ticking through the list of movies/shows, duty finder/ready checks from FFXIV, new plugin updates available, file transfer completion while I'm doing other tasks, etc.
But it seems like a similar issue as hamburger menus. Some useful cases, but widely implemented in ways they shouldn't be, as the author points out. (Looking at you, GNOME/GTK apps)
Edit: apparently toasts are distinct from snackbars, with the distinction being toasts are non-interactable whereas snackbars are.
This is a tangent, but am I the only one who thinks UX designers keep making stupid names for things? Toast notifications, hamburger menus… and I’m still a bit upset that they are calling GUI “gooey”.
I think Toast at least makes sense given the way it pops up... I think the alternative to naming things this way would be way worse jargon-wise.
They are just hungry all the time I think.
See also:
Bonus non-ux examples:
While i balked at hamburger menu as one of the dumbest things I'd heard, i've seen in person how much more effective it is than any nomenclature I was using when trying to teach to people who are less UI inclined.
The concept needs to be taken out back and shot, then buried in a shallow grave, the gravesite nuked, and the whole planet dropped into a black hole.
But as long as it exists, "hamburger" is definitely the right name for it.
I don't know about that. Just about every non-techie I've told "open the hamburger menu" had no idea what I was talking about.
Sure, but in my experience they screwed up almost every other name I used for it just as much.
The difference was that hamburger menu they actually remembered a month later when I had to do it again.
Sure, initially, until you explain what the hamburger menu actually is and why it's named that way and it'll stick. Don't underestimate the power of recognizable facsimiles.
Huh, didn't know those had a name. I will say that the "undo" on those have saved me a number of times. Mainly on mobile, when I close a tab (or a group of tabs) by accident. The undo is probably the most useful function they have.
Actually, they just seem generally more useful on mobile than desktop since it's such a small screen comparatively. They're not as far out of the way, and it's much easier to make a mistake when trying to tap something.
Love the solution - "hey, use a checkbox."