What a wounderful thread.


>>>I was looking at an application yesterday that was very annoying. Everytime you saved a data change a wait window came up with "Your data has been saved - press any key to continue".
>>>
>>>It got me thinking "why do we need a save button at all?" When I fill out a physical form I don't have to save it. It is saved by virtue of having filled it out. So why do we require users to 'SAVE'?

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.

Admittedly, the application would be harder to use the first few times, but in the long run, it would be better. Todays software is so *new user* friendly, it really seems to get in the way of the more profecient user.

For example: I don't know about your copy of VFP, but my system dialogs have 4 buttons OK, Set Defaults, Cancel, and Help. Help is cool. But Ok is *really* 'Apply', Set Defaults is *really* 'Ok', and Cancel pops a dialog asking/warning me that all my changes are going to be lost! We as VFP programmers are a fairly smart lot. We know how windows works. The message box on the Cancel is a little much.

>>
>>How do you know the user hasn't made a mistake and doesn't want to commit his/her changes. Depending on the appraoch you take, they could simply close the form or click on another button to bring back the original data.

Revert

>>
>
>If the mistake is a validation error, then it would be caught before the system decided to update the tables. If the mistake is a typo, then who would catch it and why would a save button make a difference? (see below)

I Second that logic.

>
>>A good example would be 2 people using the same program with their data files stored on a network. Now let's assume they both start editing the same record and one saves before the other. In a good program, you can tell the user what the data was originally, what the data has been changed to by the other user, and the what they changed it to, and let them select on a field-by-field basis which values to keep.
>>
>>
>
>If the system saved data intuitively, the only time it might need to interact with the user is during exceptions. That is, when a conflict arises. If there is no conflict, then closing the form, finding another record etc, intuitively saves what they have done.
>
>Now, some data entry forms are very complex and have many relationships between the data elements. Why not a sort of validation status that indicates how far towards completion the user is?
>
>This morning my wife asked me to fill out some forms but I didn't have time to finish them. She complained she couldn't send them out until they were complete. I said, so, I'll finish it when I get home. Now, in systems we build, the user usually has to complete the form/screen and save all or none. Otherwise, we complain, the database will be in a bad state. Should the user care? He should be able to easily say "I'll finish that tomorrow when I have time" We don't often build systems that meet these needs.
>

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.

You may be able to do it programaticly, a procedure can look at a table/view and generate a free table with the rules/non-rules of your choice. Then plug the generated table into the DE of the form.

>
>>>I'd like to think there is an elegant metaphor for intuitively saving data without asking the user to do it.
>>>
>>>If you look at some of the forms that change settings in Win95 or IE4 etc. You don't have to save. You can cancel, but the boxes you check etc are saved automatically.
>>>
>>>Does anyone build forms that save data without explicitly having a save button?
>>
>>If memory serves me correctly, most dialogs in Win95 and IE4 have three buttons on them: OK, Cancel, and Apply. these dialogs do not save the changes you made unless you click on OK or Apply.
>
>Yes, but I think it is worth going one step further and just do it! At least the Ok button closes the window and does the intuitive save. So I can make lots of changes and Ok closes the window and saves the changes. I have to close the window anyone. Apply just lets me see the changes without leaving.
>
>Just some thoughts!

Apply = Save ;)