The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

UI navigation when validation fails.

We are having a lively debate on the following issue and I would appreciate any opinions...

When a person is using a data entry screen of a business application like an employee details form what should happen if they enter incorrect information in a textbox such as a future birthdate?
1) The user is stuck in the text box until they either enter  valid information or use an undo sequence/button to revert to how they found it or:
2) The UI provides a error indication and message next to the  offending control but lets the user carry on filling in stuff. They can save only when all controls are fixed up.

I'm on the (1) team.
Kim McCoy Send private email
Tuesday, January 11, 2005
 
 
Oh no, you should let the user continue entering. If I am zipping through entering a form, I don't want to lose the rhythm because someone decided it wouldn't be good for me to move on without fixing that right now.

The only exception is if the field is needed for additional fields. Then I expect to be stopped before I continue.
Cory Foy Send private email
Tuesday, January 11, 2005
 
 
I agree with Cory, (2) is much better and more Windows like.
Craig Send private email
Tuesday, January 11, 2005
 
 
I expect the fields to be validated when I commit the operation, not sooner.  I don't want the form to popup a dialog box while I'm in the middle of typing.

So I guess that puts me in the (2) camp.
Almost Anonymous Send private email
Tuesday, January 11, 2005
 
 
#2 camp for me also.

Don't interfere with the user.  Let them get the rest of it typed in, and validate the data at the end. You can put the focus back in that field if it's not correct.
MarkS Send private email
Tuesday, January 11, 2005
 
 
Not windows like ? Isn't the user stopped if they enter text in a text box with a date mask? MS Access stops the user if the field validation fails.
If they leave the control how they found it (including blank) then they can move on.

Some reasons for the (1) team...
- Consistant approach. How does the user know which fields are dependant on other fields? I know as the programmer that's why I stop them.

- If my form is the 'view' of a business object and the controls are bound to the object then should it not remain consistant?
Eg, 3 text boxes. Quantity, Price, Total. User enters the first two, third is bound result of Qty x Price. If a user enters "Hello" for the price, what is the total? Null, Error or what is was before the user changed the price. Do they still get a warning that a credit limit is exceeded?

- If using the (2) approach, validation that depends on other controls being valid can not occur until the primary control is correct. In such a way it would be possible to contruct a form where the user must attempt to save several times before all errors are known.
eg) 3 controls, A, B, C that are dependant in that order. The user edits the form and changes A and B. User reviews what they've entered and fixes A which was invalid. This makes B invalid on the next validation test. They fix B and that breaks C on the next validation test.
Kim McCoy Send private email
Tuesday, January 11, 2005
 
 
You have some valid points... 

"How does the user know which fields are dependant on other fields?"

Can you give an example of this? 

"Eg, 3 text boxes. Quantity, Price, Total. User enters the first two, third is bound result of Qty x Price. If a user enters "Hello" for the price, what is the total?"

Well first of all, you shouldn't even allow text characters in a numeric input field so problem solved.  Alternatively, if all the fields began as blank, then the total would remain blank until valid values are entered into Qty and Price.  Of course, for best feedback you might actually want to drop "Error" into the field --  people can correct their errors then without some horrible message box popping up.

"3 controls, A, B, C that are dependant in that order. The user edits the form and changes A and B. User reviews what they've entered and fixes A which was invalid. This makes B invalid on the next validation test. They fix B and that breaks C on the next validation test."

This seems pretty contrived.  I can't imagine a UI where this would happen.

In any case, what normally happens is I've entered a bunch of fields and I have a typo in one.  In this case it's A so validation occurs and I correct it.  But I have correct values for B and C so on the next submission I'm good.
Almost Anonymous Send private email
Wednesday, January 12, 2005
 
 
I think the validation errors I refer to are more logical ones that apply to the underlying business object.

An example of dependant fields would be:
-A form for employee details. It has a field for birthday, date hired, date terminated.
Where birthday < date hired < date terminated
{Hopefully not in quick succession if the labour movement is getting somewhere}
These fields needn't be on the same bit of the form. Birthday could be in personel bit and the others in employment history bit.
If the birthday is changed to 03/05/3070 then i would get warnings indicating the birthday is wrong, the date hired is wrong as can't be after the birthday and nor can the date terminated. After comming back from lunch, which one do I remember to fix?
The program could have known that this was going to fail at the point the birthday was changed, so I think it should be fixed then.
In a much less contrived example, imagine also that the form includes a grid list of training courses. Using the 'keep going even with errors approach', I can put in an incorrect termination date, then add training courses for some time before this date. I go to save and the termination date is wrong but the courses are ok because they only have to be before the termination date. I fix the termination date then all my courses are invalid :(
It might be obvious to a person who likes puzzles but may be a little 'disconnected' for some people.

The answer would be to not let people enter training courses unless the rest is ok. ie, don't let then keep going when it's broke.

Not allowing characters in numerical text boxes or date boxes is an example of stopping the user at the problem. Combo boxes limited to the list choice are another example. You can't leave till it is ok.
Why should this not be extended to logical tests as well?

Another example would be entering line items on a sales form. Before allowing the quantity sold to be entered I would verify the part number is ok and the stock level is ok.

I guess it depends on the complexity of the form as to whether it matters or not. If consistancy across a whole application is important then I prefer to stick to forcing the correction of mistakes as they happen.

I hate message box popup to. Maybe a status bar type warning would be better. .net forms have a nice error thingy.
Kim McCoy Send private email
Wednesday, January 12, 2005
 
 
We have a lot of people who are answering phones while doing the data-entry so we can't stop what they're doing because they don't have the contents of a mandatory field right now and no way of getting it because they have a customer on the phone.

So we've done a lot of work on making the forms so you can quit out of them and leave half-completed or invalid forms "open" and get on with other things while you sort out the information you need to finish them.

From there it's really simple to make the forms assignable -- you can send a half completed form to a co-worker if they have information you don't.

It's turning out these are far more useful than flat DB forms in constructing workflow systems.
Katie Lucas
Wednesday, January 12, 2005
 
 
(1)
- Doesn't scale well to traditional www use.
- Irritates me.
- Shows a high coupling between the UI and business logic.  Often this is not a good thing.

Go with (2).
Mark Jerde Send private email
Wednesday, January 12, 2005
 
 
At one past place I worked at, their standard was #1.
If there was a validation error on a field, the on-blur event would fire coercing the focus back to the offending field. This led to some entertaining 3-finger salutes when there was bad data in the field that the user had just tabbed TO.
Field 1, on-blur fires: come back and fix this data. Focus moves to Field 1, from Field 2.
Field 2, on-blur fires: come back and fix this data. Focus moves to Field 2, from Field 1.
Field 1, on-blur fires: come back and fix this data. Focus moves to Field 1, from Field 2.
Field 2, on-blur fires: come back and fix this data. Focus moves to Field 2, from Field 1.
Field 1, on-blur fires: come back and fix this data. Focus moves to Field 1, from Field 2.
Field 2, on-blur fires: come back and fix this data. Focus moves to Field 2, from Field 1.
Field 1, on-blur fires: come back and fix this data. Focus moves to Field 1, from Field 2.
Field 2, on-blur fires: come back and fix this data. Focus moves to Field 2, from Field 1.
Field 1, on-blur fires: come back and fix this data. Focus moves to Field 1, from Field 2.
Field 2, on-blur fires: come back and fix this data. Focus moves to Field 2, from Field 1.
Field 1, on-blur fires: come back and fix this data. Focus moves to Field 1, from Field 2.
Field 2, on-blur fires: come back and fix this data. Focus moves to Field 2, from Field 1.

...and so on....

Until the user hits control-alt-delete to kill off the browser.

I would highlite the field in red or some other visible color, indicating that the user ought to fix the data. Although, sometimes, fixing that data means making a phone call or getting up and looking in the filing cabinet, so my preferences are to let them save it, but not submit the stuff to the next stage in the workflow. Nothing misspells "fun" more than filling in a 200 field form, finding that one of the fields has invalid data, then having to type it all in again in a couple of hours (or days) when the correct data is obtained.

sample US realestate form.
http://www.efanniemae.com/singlefamily/forms_guidelines/selling_servicing/1003.jhtml 
look for the "interactive form"

Here is a link to another post I made, might be useful, maybe not:
http://msmvps.com/williamryan/archive/2004/11/24/20575.aspx
Peter
Wednesday, January 12, 2005
 
 
Peter's got it: indicate the error without the use of a dialog box, but don't force the user to fix it immediately.

Dialog boxes are evil.  They force the user to stop what they're doing and pay attention to something else.  Don't make me change what I'm doing, I'll hate you for it.

That same line of reasoning is why you don't force the user to fix the problem right away.

Indicate the error by highlighting the field in some way.  Provide a way to get more information on what the error is, such as a tooltip or a status bar.  Let the user decide when and how they want to fix the problem.

Eclipse has a nice way of doing this.  If you're in one of the wizards and you enter invalid data, it tells you at the top of the window what the problem is.  For example, if you have to enter a package name and you type in "com.joelonsoftware.", it lets you know that valid packages can't end in "." and disables the "OK" button.  If you have to enter a class name and you type in "myClass", it warns you that the convention is to start a class name with a capital, but doesn't disable the "OK" button.
Eponymous
Wednesday, January 12, 2005
 
 
Excellent opinions - thank you.. I think Eponymous sums it up well. I've changed to (2).
- Don't annoy the user.
- Give them the information asap to make their own decisions.
Kim McCoy Send private email
Wednesday, January 12, 2005
 
 
Camp #2 for me.

Highlight the offending field a nice shade of pink, disable the "OK" button and move on.
bpd
Thursday, January 13, 2005
 
 
"Well first of all, you shouldn't even allow text characters in a numeric input field so problem solved."

So if I type 'four' instead of '4' in the Quantity field you don't know how to deal with it? I'm the user - problem is your problem.
MT Heart
Thursday, January 13, 2005
 
 
"So if I type 'four' instead of '4' in the Quantity field you don't know how to deal with it?"

Actually, if you type "f" nothing would happen.  If I was really on the ball I'd popup one of those non-model balloon help windows that says "this field accepts only numbers" -- but even if I don't, I'm sure you'd figure it out.
Almost Anonymous Send private email
Thursday, January 13, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz