>>This concept is great. 'Trust the user' if he/she know's what they are doing, then the work is smooth and seemless. If they don't hmmm, there is always the cancel button. But I bet a user spends more time in the 'I know what I am doing' "State" than in the 'what am I doing' state, in the long run.
>
>New user is mostly in "what am I to do now" mode, and experienced user will never admit he was in "I thought I knew what I was doing" when he blew it.

How long is a user new? versus How Long is a user experienced? Although I am a big fan of trusting the user to know what they are doing, I know that it is not for every application. For home software that get pulled out of the closet to create a birthday card every few months, give the (most likely) inexperienced user all the 'user aids' you can, but for specialized software that is used every day, such as head down data entry, optimize the trust factor for the sake of *task flow*.

>
>>You need a double buffered table. One table has the same information but no rules. The user fills out the form, on the unprotected table, at their leasure, then when thay want to commit, copy the record into the rules protected table. Report any errors back to the user. And for bounus points, focus the field with the problem. Here a Save button would work nicely. 'Save (for later)' 'Commit (Apply? to disk.)' 'Cancel (last changes)' and 'Abort (the whole thing)' The names need work, but the concept is there.
>
>I've seen accounting apps done with this double buffering scheme. The records were added to a daily table, and once verified, they were copied to the master table, which was read only, and marked as untouchable. It worked, but set lots of new rules upon the user, which they didn't like. Needles to say, they still managed to pass the controls regularly, and commit unbelievable errors. Formal control is not omnipotent, so it's kind of equal whether it happens on-the-fly, or at some later stage. There will always be an user who will bypass it this way or other.


Admittidly this is no easy undertaking. The programming concept is simple, and the user interface is more natural (depending on the data you are trying to capture of course). But, if there is push, stronger more correct methods will elvolve. Perhaps strengthing the database integerity rules can help in most situations. Simply don't allow the data in if its wrong, and let the Database decide via the field/table rules. The DBC is a great step for Fox.

>
>Another thing - these apps had great problems if they didn't develop a bulletproof method of copying the records. Once the copying didn't work (power surge, accidental reset), or it worked partially, they were in trouble, and had to call the programmer.

I can not wait to see the influence of 'transactions' in this area. Theoritcly one can wrap the updating in a transaction and if it fails they can simply back out the changes. Of couse if wraping it in a transation does not help this failure (power out) they will have more problems than bad data.

>
>>Apply = Save ;)
>
>Savings account = Appliances account :)

Savings account < appliances account :(