>>When I first read Cooper, I agreed. Then, in a discussion on another network :), someone (it may even have been Jim Booth) mentioned the case where, in a multiuser app, a user makes a change to a record and wants to go out to lunch. She wants her change applied, but without an explicit save command, she'd have to realize that to save the record, she has to navigate away from it, or close the form.
>
>What's the problem with that ? When he or she comes back again. she could still save the record.

But in a multuser app, it could be important that she save that record as soon as possible. Otherwise, her client, who ordered an item first, might not get it, because someone else took the last one while she was at lunch.

>An other approach is to fire a automatic save mode after some minutes (like wordprocessors) or display after some minutes a warning ("These changes have not been saved yet, do you want to save them ?").

Yes, I thought about that. Not a bad idea, actually. The question is determining the amount of time such that data is updated in a timely manner, but the user doesn't get too annoyed when she has to spend a few minutes on the phone.

>>>This seems to me to be just the kind of thing that Cooper argues against: forcing the user to understand the implementation of the program.

>Cooper is just telling us to crawl in the user mind, and learn how users look at the problem.

But he goes farther than that. He believes that (most) users do not look at a problem the same way the computer, program and programmer do.