>I sometimes make changes in a document to see the result (an Excel spreadsheet for example), but I don't want to save that information.

The key word there is "sometimes." Cooper says that default behavior should take care of "probably" not "possibly."

>How many undo do I have to press to put it back to it's original state? I'd rather make a copy, work on it and throw it to trash, but that's not a beginner's task!

You should really read Cooper. He believes that simple versioning capabilities should be built into programs. For example, to make a copy of a document, what do we typically do? We bring up the original in the word processor, then we do "Save As..." This is a trick that some users never learn, simply because it's based on the way the file system works, not how people think. Cooper asks why not add a "Make Copy" menu item?

>I think not informing the user that his data is about to be saved is even more confusing. For example, if someone changes data in a record, presses Next to see data in the second record, comes back to the first, make other changes, decides to undo, he will expect *all* his changes to be undone, but it has been saved when he changed record.

Cooper would say that undo should be incremental. (He has a great many more interesting things to say about undo; for example, that one should be able to undo a prior action without necessarily undoing all the actions between that one and the most recent.)

>Result: people would power off their computer if they entered the wrong data... Some already do!

They wouldn't if there were an Undo button sitting right in front of them.

>That is a Human problem, and no programming will solve it.

All programming is in order to solve human problems.

>If my program asks me if I want to delete my document and I stupidly tell him yes, how is he supposed to know I didn't want to?

The program doesn't. When you order a ham sandwich when you really wanted a chicken sandwich, you wouldn't be surprised if you got a ham sandwich. This is an understandable situation, and no user would complain when that document got deleted. Instead, we provide things the Recycle Bin to make dangerous actions reversible.

It's kind of funny that Xbase has always had this capability in the way it deletes records. Of course, Ratliff wasn't thinking about the users when he wrote it this way, but efficiency. Hey, sometimes users' and programmers' needs coincide. :)

>There are people that complain that there aren't enough confirmations when you try to delete a file!

Only because it's difficult or impossible to get it back again. It's a simple programming problem.

>Thing is that users want the application to do what they want, not what they tell them. Sorry, but I still can't make a program that will read the user's mind.

But you can write a program that more closely _matches_ the way the user thinks. That's all Cooper is saying.

>Okay, let's say we make a program that will adapt to the user: We ask questions first, then, after say, 10 times, we understand that the user always wants to save his document. Then one day, that user realizes that he doesn't want to save his document this time, but the program saves it, like every time. How mad do you think that user will be?

It depends if you've offered a way out. Cooper urges that no action be irretrievable if it's not necessary.

>You'd be surprised at how many people close a program (or do an action) by accident, especially since the close button (X) in Windows 95 is so close to the Maximize button...

But what's the big deal if they do? Just start it up again. If this is for some reason a really tedious process, _then_ I can see confirming exit.

>And the mouse is nothing precise - far too easy to hit just next to your target, and produce an unwanted effect. I have sometimes selected "Save" instead of "Save As...", and I knocked my head on the wall each time!

If this is a problem, then you simply shouldn't use the mouse. If the program offers you different ways to execute a command, and you select one that you're not good at, I agree the program isn't at fault.

>... and help them realize they've made a mistake! *EVERY* error is human in origin, and the computer make those changes permanent faster than the human can realize he made a mistake.

Only if we don't also offer undo capability.

>How much productivity have you gained when you just erased last month's financial transactions? Why do you think backups even exist?

Backups are a way of protecting against human frailty. Computer programs should too, but that doesn't mean asking the user stupid questions. :)

>Using Cooper's advice, there's no need for a safety belt in my car since I don't intend to crash! And there's no need for a safety lock on a firearm, since I won't press the trigger if I don't mean to shoot!

What Cooper is suggesting is that we make the safety belts automatic. This doesn't work well in cars (it's been tried). But computers are infinitely more flexible than cars.

>Sorry, but I am certainly not going to read that book!

Too bad, because otherwise you might find out that you really don't understand what he's saying.