"Saving" Behavior of a data entry form 3

[seaport]

When I started using Access, all databases I built use Access data and all data entry forms are bound to the data table. There is no "Save" button on data entry forms. Any changes will be automatically saved whenever the "After_Update" form event occurs. (As you know, there is no "Save" button on any template databases that come with the Access software.)

Later on I built database using SQL server as the back-end database and the data entry form was not bound to a form. Somehow I got the idea adding the "Save" button in the form so a user needs to intentionally save the data. A user gets a warning if trying to move to another record before saving the data.This did not cause a problem to users because this "Saving" behavior is the same as Word or Excel.

Now I got a database having both Bound forms and unbound forms, and here are my questions.
1. Do I need to keep a consistent user interface? (I do not know much about UI design.) I might just tell users to use the Save button if there is one and not to worry losing the data if there isn't.
2. If I do need to create the standard, which way should I go, automatically saving the data without a "save" button or intentionally saving the data using a "Save" button? I would take the second option because it is the way for all Office software products. Since I am not using too many software products, I would like to hear others' opinions on this.

Any inputs are appreciated.

Seaport

 

[JoeAtWork]

1. Always try to be consistent in the UI. Otherwise the users will be confused and will almost certainly make more mistakes. It also is less confusing for the programmer who has to maintain the code.

2. Although in general my preference is to have explicit Saves, with Access I think the default behaviour is best. The main reason for using Access in the first place is because of all the things it can do automatically for you if you follow its conventions. I personally prefer other platforms than Access if I have the choice, but if you are going to use it, then at least play to it's strengths.

The comparison to Word and Excel isn't valid, because with those programs you are working on a "document". With Access you are working on chunks of data at a time, at most you are really only working on one record at a time.

 

[missinglinq]

A couple of things first:

"the data entry form was not bound to a form"

I assume you actually meant

"the data entry form was not bound to a table"

"A user gets a warning if trying to move to another record before saving the data"

There is no other record to go to in an unbound form; in point of fact, there is no record at all, only unbound data!

"Somehow I got the idea adding the "Save" button in the form so a user needs to intentionally save the data"

How else would you save data in an inbound? Access has no built in mechanism to accomplish this.

If you're going to mix bound and unbound data entry/edit forms within the same database or suite of databases, and to be honest, I've never really understood why anyone would, you owe it to your users to be consistent form form to form. Have a "Save" button on all data forms, unless they're Read-Only, and try to place it in the same area of your form. Consistency in User Interfaces is one of the compelling reasons to have apps that are Windows compliant; the end user doesn't have to learn 5 different ways to save a record for five different programs.

Access was designed to facilitate the fast development and deployment of database apps, and bound data forms are the backbone of Access. If you're going to go to the trouble of using unbound forms for data entry/editing, you'd probably be better off developing your front end using Visual Basic or C/C++, where it'd be complied into an EXE file and you wouldn't have the security issues you have with Access. Those languages are really better suited for this kind of thing, they just require more effort.

Unbound forms in Access should be reserved for such things as splash screens, switchboard/navigation forms and search forms.


The Missinglinq

Richmond, Virginia

There's ALWAYS more than one way to skin a cat!

 

[TheAceMan1]

How are ya seaport . . .

[blue]Do I need to keep a consistent user interface? . . .[/blue]

In reference to saving records, the [blue]logical interface of the forms[/blue] should fit whats expected from the user. Examples:
[ol][li]Data entry personnel, transfering data from hand written forms, need auto saving![/li]
[li]Purchasing & Banking forms where the [blue]user needs to show intent[/blue], require save buttons (most often labeled submitt!).[/li][/ol]
I believe you get the idea. [purple]Saving should fit the logical intent of the form![/purple]

[blue]Your Thoughts? . . .[/blue]

See Ya! . . . . . .

Be sure to see thread181-473997
Also faq181-2886

 

[seaport]

Hi,

Thanks for all your replies.

My plan is to use implicit saving, which does not need a saving button. This is certainly doable even for an unbound form. When there is a need for showing intent, I will add a "Submit". This plan is basically a combination of Joe and Aceman's inputs.

Missinglinq, I agree with your input for the most part. If I start a new client/server project I should choose VB rather than Access. However, for a company with small IT shop, it has to stick to Access if it starts with Access (usually with bound forms). Complete converting an Access database system to a VB/SQL Sever system takes long time and it is not an option for my company to freeze the user requirement for several months. Therefore, migration to the SQL Server has to be done gradually, a couple forms a time. Forms bound to big tables go first. That's why I end up with a database with both bound form and unbound forms.

As I said before, I do not know much about User Interface design. Could you recommend some good books or links for UI design?

Thanks a lot.

Seaport.