3 ms·

> You'd just have a dashboard full of invites instead of a dashboard full of add notices. I don't participate on github so I did't think you'd just stuff all o

by ktsmith 15y ago

> You'd just have a dashboard full of invites instead of a dashboard full of add notices. I don't participate on github so I did't think you'd just stuff all of those notices on the dashboard. That sounds like a pretty broken UI IMHO. > But remember that Undo > Confirmation. Always. That's your opinion and it's very clear from this thread that a significant number of people strongly disagree with it. I will concede that Undo in this context has much less friction, likely for most github users. I wouldn't necessarily agree that it's better and certainly not always.

teach 15y ago
I would argue that in almost all cases, a confirmation is far inferior to undo from a usability standpoint. I must admit to having been persuaded by Aza Raskin, in his widely-read article "Never Use a Warning When You Mean Undo". [0] http://www.alistapart.com/articles/neveruseawarning http://www.alistapart.com/articles/neveruseawarning
- ktsmith 15y ago
  It depends on the context. In the last two years I've worked on apps where undo would mean incurring liability or potentially losing money immediately following a change. In the first example where liability would be incurred allowing the user to undo a change would actually mean that two changes were made and both have to be tracked, with full audit trail etc. By prompting users for confirmation you have an opportunity to ensure that the user understands the consequences of their decisions. That may not matter for adding a contributor to a github project but it does when changing a federal form or legal document for example.
  - teach 15y ago
    So in this case, you're not talking about making the software easier to use, you're talking about about making a cleaner legal audit trail. Which I'll still argue makes the application in question harder to use and is a worse software choice. But a worse interface that makes the software easier to code is one thing; a worse interface that makes the software more easily comply with the law is an entirely different trade-off.
    - ktsmith 15y ago
      > you're talking about about making a cleaner legal audit trail. Not exactly, the legal audit trail can be messy and it doesn't matter one bit so long as it's accurate. In the case described change one is logged and the undo constitues a second change which is also logged. Change one incurs liability for the user and change two simply increases the liability for the user (sorry I can't go into specifics) even though it's correcting a problem. In my experience it's very difficult to create a user interface where the "undo" action clearly indicates the consequence of the change in these scenarios. Preventing unnecessary changes via a combination of up front documentation and confirmation provided the better user experience, and legal liability reduction, in my experience and based on some user feedback. > But a worse interface that makes the software easier to code is one thing; a worse interface that makes the software more easily comply with the law is an entirely different trade-off. Believe me, not confirming user actions would have been less code and easier to build and maintain in this case. Legal compliance on my part would have been maintained in either case. Allowing my users to quickly and easily build up liability would be doing them a disservice however. Adding some friction to those transactions was agreed to be the better option by everyone involved. I think the idea that confirmation vs undo is subjective. We can go on and on for hours and come up with examples and counter examples. The particular context of the action likely determines which provides the better user experience in total (not just on that one screen or interaction but via the consequences of the action as well). I would certainly prefer that if I'm using a system like facebook that it confirm I really want to make my home address and phone number public before it does so rather than letting me check a box and it's done. The same goes with a money transfer where an undo may not even be possible after some amount of time. Not prompting for confirmation certainly makes the transactions move faster (less friction) and undo is easy enough in many cases, but does that frictionless transaction have the best outcome for my users? Not always. The blanket statement that "undo > confirmation. Always." is just plain wrong, not that you made it of course.

by ktsmith 15y ago

teach 15y ago

I would argue that in almost all cases, a confirmation is far inferior to undo from a usability standpoint. I must admit to having been persuaded by Aza Raskin, in his widely-read article "Never Use a Warning When You Mean Undo". [0] http://www.alistapart.com/articles/neveruseawarning http://www.alistapart.com/articles/neveruseawarning

ktsmith 15y ago
It depends on the context. In the last two years I've worked on apps where undo would mean incurring liability or potentially losing money immediately following a change. In the first example where liability would be incurred allowing the user to undo a change would actually mean that two changes were made and both have to be tracked, with full audit trail etc. By prompting users for confirmation you have an opportunity to ensure that the user understands the consequences of their decisions. That may not matter for adding a contributor to a github project but it does when changing a federal form or legal document for example.
- teach 15y ago
  So in this case, you're not talking about making the software easier to use, you're talking about about making a cleaner legal audit trail. Which I'll still argue makes the application in question harder to use and is a worse software choice. But a worse interface that makes the software easier to code is one thing; a worse interface that makes the software more easily comply with the law is an entirely different trade-off.
  - ktsmith 15y ago
    > you're talking about about making a cleaner legal audit trail. Not exactly, the legal audit trail can be messy and it doesn't matter one bit so long as it's accurate. In the case described change one is logged and the undo constitues a second change which is also logged. Change one incurs liability for the user and change two simply increases the liability for the user (sorry I can't go into specifics) even though it's correcting a problem. In my experience it's very difficult to create a user interface where the "undo" action clearly indicates the consequence of the change in these scenarios. Preventing unnecessary changes via a combination of up front documentation and confirmation provided the better user experience, and legal liability reduction, in my experience and based on some user feedback. > But a worse interface that makes the software easier to code is one thing; a worse interface that makes the software more easily comply with the law is an entirely different trade-off. Believe me, not confirming user actions would have been less code and easier to build and maintain in this case. Legal compliance on my part would have been maintained in either case. Allowing my users to quickly and easily build up liability would be doing them a disservice however. Adding some friction to those transactions was agreed to be the better option by everyone involved. I think the idea that confirmation vs undo is subjective. We can go on and on for hours and come up with examples and counter examples. The particular context of the action likely determines which provides the better user experience in total (not just on that one screen or interaction but via the consequences of the action as well). I would certainly prefer that if I'm using a system like facebook that it confirm I really want to make my home address and phone number public before it does so rather than letting me check a box and it's done. The same goes with a money transfer where an undo may not even be possible after some amount of time. Not prompting for confirmation certainly makes the transactions move faster (less friction) and undo is easy enough in many cases, but does that frictionless transaction have the best outcome for my users? Not always. The blanket statement that "undo > confirmation. Always." is just plain wrong, not that you made it of course.