I think Alan Cooper said it first. Good software is polite software. You're right, tough love is that same as saying, "deal with it".
There's another component to good software though and that has to do with how much your software anticipates what the person is trying to do. It has a little bit to do with programming in some intelligence but it has more to do with spending the time to really address what it is they're trying to do in the first place.
Reg Braithwaite
· 2 years ago
"While an Undo feature could be useful, isn't this just coddling people who should otherwise be paying closer attention to what they are doing?"
How shall I put this?
While a source code repository with version control could be useful, isn't this just coddling programmers who should otherwise be paying closer attention to what they are doing?
Sean
· 2 years ago
I'm glad I can undo all that murder and/then rape from last year with my New Years Resolution.
4chan
· 2 years ago
Epic Fail!
webwright
· 2 years ago
I'd add that oftentimes when users make mistakes, it's NOBODY'S fault. There is no user interface that doesn't fail sometimes for some people... I've been using Gmail for years now, and I _still_ make mistakes in it from time to time.
John K
· 2 years ago
What kind of mistakes though? The kind that you often repeat?
Neil Graham
· 2 years ago
The comment looks like a joke to me. The last sentence indicates that they have the interest of the user at heart. It just seems a misguided view.
The far more common experience that I get is the first half of the comment with "It's not my responsibility to cover for other peoples' failings". That's a view that is hugely prevalent in the open source world. I'm sure there's a psyc paper there as to why open source developers have more than their fair share of abrasive personalities.
Mike Shade
· 2 years ago
Undo is fine.
Are you sure? Are you REALLY sure? Press OK to confirm. Are you sure?
That's what I have a problem with. As long as it does exactly what I ask with as minimum fuss as possible, sure, include an undo feature. That's when it's most useful. In place of confirmation, use undo.
nivi
· 2 years ago
"One never learns from doing things right because, obviously, one already knows how to do it. What one derives from doing something right is confirmation of what one already knows. This has value, but it is not learning. One can only learn from mistakes, by identifying and correcting them. But all through school and in most places of employment we are taught that making mistakes is a bad thing. Therefore, we try to hide or deny those we make. To the extent we succeed, we preclude learning." – Russell Ackoff, http://tinyurl.com/ytb4q6
“All through school, from kindergarten up, you were taught that mistakes are a bad thing. You were downgraded for the mistakes that you made.
"It is perfectly apparent from what [schools] do in examinations where errors are identified, [that] education is not about learning. It is about grading. Because if they were interested in learning, they would give you the same examination back a week later, to see if you had corrected your mistakes. But they’re not interested in that, they’re interested in giving you a grade.
Ackoff talks about making mistakes in large organizations... I like the society angle you bring up... i.e. making mistakes in societies. Which takes us back to Ackoff who is all about examining the larger system through synthesis rather than simply examining the smaller system through analysis. Also good: http://tinyurl.com/2htbwz
Rhys
· 2 years ago
There's this thing called a pencil, that's been around a few hundred years, and which billions of humans alive and dead generally agree has an excellent user interface. It has an eraser on the end, so you can fix your mistakes. Having the eraser there makes you more creative because you aren't worried about screwing up. Anybody who wants to argue against undo in computer programs needs to argue against undo on pencils first.
Vasudev Ram
· 2 years ago
Great post.
Agree with the point, "To design great products, we must truly empathize with our users, and understand that if they are having problems using our products, is more likely our fault, not theirs.". Or anyway, if possible, figure out whose "fault" it is (e.g. it could really be the user's - maybe they didn't bother to read the instructions on the screen (talking about the app itself here, not the help docs - things like labels for edit controls), and fix it (if the user's fault, by educating them).
> "the disdainful or patronizing attitudes too often expressed by engineers and other technical people".
+1 on that - seen it in a lot of engineers.
As for your last paragraph, all I can say is, true again, and good generalization / abstraction ! :)
"Anybody who wants to argue against undo in computer programs needs to argue against undo on pencils first."
I use a pen.
The backspace does more to slow down my typing than any other thing -- when I'm trying to type fast, such as when I'm taking notes by typing instead of writing (with a pen), I have to make an effort to ignore the backspace key (and to go back later to correct errors).
However.
All that shows is that the issue is not as simplistic as we'd like it to be. There's a time, and there's a place, and there's the matter of intent. Most of the time, I _like_ the backspace key, because I'm not trying to type fast, I'm trying to say something clearly. I may fail, but the ability to correct errors as I make them eliminates a lot of congintive distress.
The thing to remember is, first and foremost, computers are boxes that do what we tell them.
Undo -- especially unlimited undo -- is a great thing, until it isn't. Deciding that point between is and isn't is a matter of weighing tradeoffs. We're all familiar with the horror stories about inadvertent information being disclosed because someone else "undid" revisions to a memo, notice, or contract. (If not, we should be.) Likewise with pulling data off of a hard drive, or passwords out of memory; sometimes, "gone" needs to be "gone", and "undo" is not desirable behavior.
What we need is a good rule of thumb for deciding when it is, and when it isn't (desirable behavior).
An example:
Years ago I aliased "rm" to "rm -i", but this just made me careless, and did not solve the underlying problem. I stopped doing that, and instead have tried to cultivate a zen moment of contemplation before hitting return for an rm command.
A friend of mine accidently trashed his data (rm and glob and an inadvertent space), and took another approach -- he changed rm to copy everything to a "trashcan", and then after a week, everything in the trashcan would be deleted. In effect, he gave himself an undelete.
When I tried it, I quickly ran out of space, and had to manually delete the items in the "trash" -- but I had started using the trash as a temporary shelf. It turns out I generate a LOT more "junk data" than my friend, and that I'm also desperately in need of that "zen moment".
We're not all the same, so the same solutions won't be equally useful.
Which is a long way of saying "Good idea, but..."
Sam
· 2 years ago
Isn't the wheel just coddling people who should just use their legs?
Well, then we wouldn't use cars, we would all be living in the stone age, and well at least we wouldn't have carbon emissions.
Yup, that guy sure is smart. He just solved global warming!
mattmaroon
· 2 years ago
I've had a few arguments with people over whether or not the back button on a browser should function only as a back button or be made, where possible, to function more like an undo. This is becoming increasingly relevant as AJAX proliferates and web pages turn into applications.
My contention was that even though the back button wasn't designed to be an undo, nearly everyone uses it as that and therefore it should be treated as such.
chmike
· 2 years ago
I totally agree with you.
BTW Paul, is there a way to send you a private message ? Could not find any.
Horst Henn
· 1 year ago
Everybody is talking about UNDO. However, we should also think about REDO. About 30 years ago I created a graphic software tool at IBM "BIGAM" which was capable of UNDOING an arbitrary number of actions in a graphical design system using a very early version of the IBM relational data base. The nice side effect of this transactional system was that you could change a few parameters including references to other objects, automatically REDO your sequence and create new objects. Thus you could automate very complex sequences of actions which required lots of interactions woth other objects. Imagine you could apply this method to all the daily chores you have to do to keep your PC up and running. This system was extremely helpfull to exploit mechanical construction methods with trial and error methods. The sytem was also extremely helpfull for e-Learning. Everything could be shown in an eMovie. Although the core of the system was used in an IBM Graphics Application (on those green Tektronix screens) it was not really successfull. The main problem was that there were not enough programmers around which could build truly transaction based systrems. This is still true today - it is really bring to do all that typing and clicking over and over again.
Good software should support safe trial and error exploitation but also automation of stupid command sequences.
listen_to_blogs
· 1 year ago
"To design great products, we must truly empathize with our users, and understand that if they are having problems using our products, is more likely our fault, not theirs."
==> I wouldn't generalize this for all software products. Its is definitely true for consumer application software. For system software, a lot of times it becomes necessary to do a tradeoff between usability and efficiency.
All Comments
There's another component to good software though and that has to do with how much your software anticipates what the person is trying to do. It has a little bit to do with programming in some intelligence but it has more to do with spending the time to really address what it is they're trying to do in the first place.
How shall I put this?
While a source code repository with version control could be useful, isn't this just coddling programmers who should otherwise be paying closer attention to what they are doing?
The far more common experience that I get is the first half of the comment with "It's not my responsibility to cover for other peoples' failings". That's a view that is hugely prevalent in the open source world. I'm sure there's a psyc paper there as to why open source developers have more than their fair share of abrasive personalities.
Are you sure? Are you REALLY sure? Press OK to confirm. Are you sure?
That's what I have a problem with. As long as it does exactly what I ask with as minimum fuss as possible, sure, include an undo feature. That's when it's most useful. In place of confirmation, use undo.
“All through school, from kindergarten up, you were taught that mistakes are a bad thing. You were downgraded for the mistakes that you made.
"It is perfectly apparent from what [schools] do in examinations where errors are identified, [that] education is not about learning. It is about grading. Because if they were interested in learning, they would give you the same examination back a week later, to see if you had corrected your mistakes. But they’re not interested in that, they’re interested in giving you a grade.
"So it is impressed on you, mistakes are a bad thing." – Russell Ackoff, http://www.nivi.com/blog/article/education-is-a...
Ackoff talks about making mistakes in large organizations... I like the society angle you bring up... i.e. making mistakes in societies. Which takes us back to Ackoff who is all about examining the larger system through synthesis rather than simply examining the smaller system through analysis.
Also good: http://tinyurl.com/2htbwz
Agree with the point, "To design great products, we must truly empathize with our users, and understand that if they are having problems using our products, is more likely our fault, not theirs.". Or anyway, if possible, figure out whose "fault" it is (e.g. it could really be the user's - maybe they didn't bother to read the instructions on the screen (talking about the app itself here, not the help docs - things like labels for edit controls), and fix it (if the user's fault, by educating them).
> "the disdainful or patronizing attitudes too often expressed by engineers and other technical people".
+1 on that - seen it in a lot of engineers.
As for your last paragraph, all I can say is, true again, and good generalization / abstraction ! :)
Vasudev Ram
Dancing Bison Enterprises
Software consulting and training
Biz site: http://www.dancingbison.com
Blog (on software innovation): http://jugad.livejournal.com
Quick and easy PDF creation toolkit: http://www.dancingbison.com/products.html
I use a pen.
The backspace does more to slow down my typing than any other thing -- when I'm trying to type fast, such as when I'm taking notes by typing instead of writing (with a pen), I have to make an effort to ignore the backspace key (and to go back later to correct errors).
However.
All that shows is that the issue is not as simplistic as we'd like it to be. There's a time, and there's a place, and there's the matter of intent. Most of the time, I _like_ the backspace key, because I'm not trying to type fast, I'm trying to say something clearly. I may fail, but the ability to correct errors as I make them eliminates a lot of congintive distress.
The thing to remember is, first and foremost, computers are boxes that do what we tell them.
Undo -- especially unlimited undo -- is a great thing, until it isn't. Deciding that point between is and isn't is a matter of weighing tradeoffs. We're all familiar with the horror stories about inadvertent information being disclosed because someone else "undid" revisions to a memo, notice, or contract. (If not, we should be.) Likewise with pulling data off of a hard drive, or passwords out of memory; sometimes, "gone" needs to be "gone", and "undo" is not desirable behavior.
What we need is a good rule of thumb for deciding when it is, and when it isn't (desirable behavior).
An example:
Years ago I aliased "rm" to "rm -i", but this just made me careless, and did not solve the underlying problem. I stopped doing that, and instead have tried to cultivate a zen moment of contemplation before hitting return for an rm command.
A friend of mine accidently trashed his data (rm and glob and an inadvertent space), and took another approach -- he changed rm to copy everything to a "trashcan", and then after a week, everything in the trashcan would be deleted. In effect, he gave himself an undelete.
When I tried it, I quickly ran out of space, and had to manually delete the items in the "trash" -- but I had started using the trash as a temporary shelf. It turns out I generate a LOT more "junk data" than my friend, and that I'm also desperately in need of that "zen moment".
We're not all the same, so the same solutions won't be equally useful.
Which is a long way of saying "Good idea, but..."
Well, then we wouldn't use cars, we would all be living in the stone age, and well at least we wouldn't have carbon emissions.
Yup, that guy sure is smart. He just solved global warming!
My contention was that even though the back button wasn't designed to be an undo, nearly everyone uses it as that and therefore it should be treated as such.
BTW Paul, is there a way to send you a private message ? Could not find any.
Good software should support safe trial and error exploitation but also automation of stupid command sequences.
==> I wouldn't generalize this for all software products. Its is definitely true for consumer application software. For system software, a lot of times it becomes necessary to do a tradeoff between usability and efficiency.