> 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.
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.
> 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.
> 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.
> 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.
> 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.
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?
This is particularly annoying on Gmail, where sometimes while you type in the search bar, a few of your keypresses will trigger keyboard shortcuts instead.
Did you just archive or delete a couple of unread emails? You may never know!
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.