Thursday, April 8, 2010

Electronic Forms - Inflexible?

Well, yes, they can be. The more "useful" an electronic form is with data validation, menus, and dropdown boxes, the less flexible it is. Users are forced to enter certain data in certain places. That is a rigid process. Wait, I can hear you say:

"Yes, this is what we want. This makes the data more accurate."

And yes, that's true. But the task I'm currently working on is converting a paper medical form into an electronic form - complete with data processing and storage. And the issue is that the doctor really can't describe how he uses the form. It's not rigid for him - he write one thing in column A one day, and write something else in column A another day. All he has to care about is communicating to himself and his circle of doctors. So it doesn't matter to him if he fills out the form exactly how it's liad out on paper. Just because a paper form has certain categories, names, and blanks to be filled in, doesn't mean the form actually gets used that way.

And what we're trying to do as developers is provide a tool that replicates how a form is used. So this is where the flexibility/inflexibility comes in. If the doctor enters data, and I validate the heck out of it, he or she can't use that field for anything else. Whereas on a paper form, you can use any field for anything you want.

Possible solutions? Extra programming - program in the flexibility. Make the form smart enough to know what the physician (or any user) is trying to do. But do you realize how much extra programming that will be? Nuances galore. It's a slippery slope (ha, yes - the ever-feared slippery slope of programming). Sure it's cool, and sure it can be done - but at what cost? How much extra time and creative design is needed to make a form both flexible and smart enough to validate and store the data properly? Part of the pros of data validation is that processing and handling that data afterwards is easier. So is it wise to spend the extra time?

Or, you can just make generic textboxes for data entry. You take all data, and you don't validate it.

So - as with many things - it's a balance. It's a judgement call on a per-situation, per-form basis. What kind of flexibility is needed for the data entry? If not much, then go ahead and make rigid data-validation routines. Then it's worth it. But if the form's user might sometimes enter alphabetic data, sometimes numeric, or sometimes something else (not sure what else, but I think you get the idea) - then it's advisable to scale back on the rigidity/validation. Remember that if you program in rigid validation, and you deliver the form to your customer (in my case, a doctor), and he can't enter the data he wants where he wants - he may come back and say "I need this changed." Whereas if you left it flexible in the first place, he may say, "Nice, this works how I need it."

Oh, and if you have other solutions, or think I'm wrong, or think I'm right - say so. Open it up.

No comments:

Post a Comment