DesignAday: Tales from the Field: Data Entry Automation and Validation
lindsaytabas
· 2 months ago
I agree that auto-completing is a nice addition to data forms. I would also add tab-orders and other cues to give to hardcore data entry specialists. For instance, knowing that they rarely look at the screen when entering data, tells us auto-completing, and tab orders are important, but visual feedback might not be as useful until they are finished the form. One designer I worked with suggested using audio cues when data entered was invalid. I liked that idea, and apparently jQuery has a plugin for that!
Jack L. Moffett
· 2 months ago
Those are good points for general form design. However, tab order is useless when you are entering data with a stylus on a tablet PC. And many industrial environments are noisy enough that audio cues may not be heard. Always design to the context in which the users are working.
D Stephen Haynes
· 2 months ago
This is probably one of the biggest challenges I face when I'm designing a system for a client. You're never going to know 100% of the business cases for the application, and you don't want to lock yourself into a system that prevents the user from performing a required action for those few cases that are overlooked or so uncommon that nobody remembered to mention them when I was gathering requirements. Because of the unknown, I tend to target 80% of the business cases in my design and plan workarounds for anything else that might come along. In reality, I probably hit closer to 95% of business cases being caught.
Still, how do you create a field that should be a static data element for the majority of the time, but it needs to be dynamic for say 1% of the time?
Let me give an example. I have a scheduling tool I'm working on for a client. In most cases, they have a start time. I have a field for the day, date, and time. All of these are static elements, and I know the finite set of possibilities for each field. My problem comes when they need something more flexible in their start time such as, "Start when I tell you to (most likely just before you need to perform the work)."
In this example, I can't leave the scheduled start fields blank, because the system double-checks each job to ensure there are start and stop times on each item on the schedule. Without a start, the line errors out as needing attention, or "Fill in your start time, or I can't send this job out to the field."
My first reaction was to just put a "TBD" as an acceptable response in the field, but the alpha TBD isn't accepted in a numeric field. Putting 0:00 as the time makes the program bomb out, so I can't use that. Or maybe I've gone down a rabbit hole that I just need to pull back out of and re-think.
Jack L. Moffett
· 2 months ago
I don't have the complete context of your system, so I don't know what your constraints are, but it sounds to me like the validation of your fields is too stringent. If the start time can’t be filled initially, it shouldn’t be required. Does this form travel through a workflow? If so, the validation could be different for each step in the workflow. The start time wouldn’t be required when assigning the job to a technician, but would be required for that technician to sign off and submit the job as complete.
D Stephen Haynes
· 2 months ago
Yeah, I think it's more of a business rule that needs to be modified, because it's a requirement to have a start time for the majority of cases before they're sent to the field. Otherwise, you have situations where sales isn't setting customer expectations on start times, and it causes headaches with the field managers.
One of the main reasons for putting this system in place is to hold sales accountable for what they promise to the customer. This specific scenario is where sales asks for a start time, and the customer can't answer until probably the day of the job. I would love to add a checkbox or something that signifies that sales at least tried to obtain a start time, but the client doesn't want to add more fields, because they're afraid of confusing everyone with too many fields. I get that concept, but there comes a time where you have to somehow tell the system details of the transaction at hand. The system can't figure everything out when key pieces of information are missing.
We found two more bugs with this specific scenario, just today. Bottom line is, you can design a perfect system for the business, but it will fail if the business still tries to apply broken processes to the system. I've seen it over and over with SAP implementations, so it's no surprise. Time to start politicking and working this from the business process optimization angle.
Either way, I'm TOTALLY on-board for smarter forms and fields for end users to use and perform their jobs. Simple, organized page-flow makes a world of difference, and I don't think people get how much work goes into a simple form. But then again, that's the point. :-)
Jack L. Moffett
· 2 months ago
Another possibility, to avoid the addition of fields, would be to have two different fields for start time that are dynamically displayed or hidden. When the sales person is filling it out, there is an optional field for "requested start time". A value entered in this field could then be displayed as read-only text in the form when the field guy views it. The actual start time field, which is required, would only be shown to the field guy.
All Comments
Still, how do you create a field that should be a static data element for the majority of the time, but it needs to be dynamic for say 1% of the time?
Let me give an example. I have a scheduling tool I'm working on for a client. In most cases, they have a start time. I have a field for the day, date, and time. All of these are static elements, and I know the finite set of possibilities for each field. My problem comes when they need something more flexible in their start time such as, "Start when I tell you to (most likely just before you need to perform the work)."
In this example, I can't leave the scheduled start fields blank, because the system double-checks each job to ensure there are start and stop times on each item on the schedule. Without a start, the line errors out as needing attention, or "Fill in your start time, or I can't send this job out to the field."
My first reaction was to just put a "TBD" as an acceptable response in the field, but the alpha TBD isn't accepted in a numeric field. Putting 0:00 as the time makes the program bomb out, so I can't use that. Or maybe I've gone down a rabbit hole that I just need to pull back out of and re-think.
One of the main reasons for putting this system in place is to hold sales accountable for what they promise to the customer. This specific scenario is where sales asks for a start time, and the customer can't answer until probably the day of the job. I would love to add a checkbox or something that signifies that sales at least tried to obtain a start time, but the client doesn't want to add more fields, because they're afraid of confusing everyone with too many fields. I get that concept, but there comes a time where you have to somehow tell the system details of the transaction at hand. The system can't figure everything out when key pieces of information are missing.
We found two more bugs with this specific scenario, just today. Bottom line is, you can design a perfect system for the business, but it will fail if the business still tries to apply broken processes to the system. I've seen it over and over with SAP implementations, so it's no surprise. Time to start politicking and working this from the business process optimization angle.
Either way, I'm TOTALLY on-board for smarter forms and fields for end users to use and perform their jobs. Simple, organized page-flow makes a world of difference, and I don't think people get how much work goes into a simple form. But then again, that's the point. :-)