>My last spin on this issue:

OK, I won't expect an answer. :)

>My applications are *not* user-oriented apps, they are enterprise-oriented apps.

I don't feel these qualities are exclusive. If users don't like your apps, then they're going to make more mistakes. They're going to quit, and new, less experienced users will take their places. If you waste the users' time, you'll cost the company money. An attitude that pits users against data is going to cause problems, and I don't really think (based on your other messages) that you really design this way.

>I am not going to allow immediate edits and logical saves/reverts to make a user happy. I am going to make the enterprise happy; it is my job to protect enterprise data and business processes.

As long as you're designing user interfaces as well as implementing business rules, you have to try to accomodate both needs.

>If that means shoving the "inconvenience" of Edit and Save buttons down a users throat so that they take some measure of responsibility for their actions, so be it.

I don't think that's the point at all. This isn't a moral issue. :)

>I think that there is a vast difference between interfaces for users in personal productivity applications (where Cooper mainly applies) and interfaces for critical enterprise data.

I not only disagree about this "vast difference," but also about what Cooper is addressing. How does it violate data integrity to remember the user's last choice in a paged dialog? To let users customize their toolbars? To make sure that different command vectors are available to suit different user's experience levels? To make _programs_ more responsible for problems than just kicking hem back into the user's lap (I'm using a program at this very moment--I'll let you guess which one--that aborts when there's a problem!)

_No one_, not even Cooper, is saying that any program should permit incorrect output, I don't care if it's for a hospital or a classroom. If there's a legitimate need for asking the user if she wants to save a record (as I believe there is in database apps), then that's what should be done. The idea that Cooper is some tree-hugging user-coddler who thinks that programs shouldn't first and foremost Do The Right Thing is nowhere to be found in his book.

Before this thread ends, I can't resist citing Chris Crawford's (the game designer) user interface example:

Enter name of file to delete:
FOO.BAR
Are you sure you want to delete this file?
Y
You can't get it back again, you know:
I KNOW
Enter password:
*******
What was the name of that file again?