> 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*.

Here Word comes as a handy example - the number of automatic aids I usually have to switch off after reinstall is enormous. The only thing it needs is to use these preference without reinforcing the defaults after every reinstall. I guess it has gone far down the good road, in somewhat wrong direction. Many of the defaults are utterly wrong, and are set so that the user will notice the new features fast, and get annoyed with them equally fast. Still, the general idea of having several degrees of aid, being able to turn them on/off etc is neat, and it sure needs good thinking, specially on the matter of guessing the best defaults (a subject where a pair of dice beats M$). One nice implementation comes to my mind right now: remember the three or four levels of help in the ancient WordStar 3 (for CP/M, but it was the same on PCs, I think).

>>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.

Sure this is the way to go. I just said I've seen very poor implementations of it - and it doesn't prove the principle is bad, it just proves it needs serious thinking _and_ implementation.

>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.

I don't remember exactly what the theory says, but in better implementations, a database server is safe against power out - it writes the transactions into the log first, then rolls them on into the database, then writes it back to mark as done; logs are purged but not immediately, so they should be able to know, upon startup, if the last changes were completed, and if not, what progres did they make, and to decide to rollback or roll forward. It's probably a tool of the DBA. Don't know what system this applies to, though - maybe it was on a VAX a decade ago, but I guess the principles still hold.

>
>Savings account < appliances account :(

Well, nobody's perfetc :)