Hinting subtly at user errors in UI

All of us have used UI at one point of time or another where a user error usually results in an error message box. This is definitely good in places like a dialog box with few controls or say a wizard. The message box must contain the error code, the error message and the potential cause and fix of the issue. I would think that all controls must do as much validation as possible soon after the user enters the value. Of course, there are practical limitations to such an approach - sometimes you need to bunch validations to minimize server calls or reduce perf hits etc. The build configuration wizard dialog does a good job of balancing throwing errors later and performing validations asap. For instance, build type name, build directory, drop location, build machine are all validated for credible values in the same page whereas errors that are hit upon server calls like build machine unreachable or permissions insufficient errors are shown at the end.
But imagine a document window with several controls throwing message boxes each time the user enters a potentially invalid value...ugh! It feels like getting honked at by every single car on the road! (I am learning to drive a car lately - I hope that explains the lousy analogy :) Well, the windows forms have a nice way to work through this - the error provider controls that pop up the red exclamations next to the controls containing the error with the tool tip text describing the error message. That is an unobtrusive and less noisy way of alerting the user to an invalid entry. But if you have used the VSTS work item tracking, you would have observed the elegance with which errors are pointed out and users prompted for required entries.
The required fields are shaded with a pale yellow background and have <Required> written in the field area to draw the user's attention that these fields HAVE to be filled. If an invalid entry is made in any field, a pale yellow bar pops up on top of the title field and contains the error code with a descriptive error message. Upon multiple errors, the user is not bombarded with error messages all at once, but instead only one error message is shown. Once that is fixed, the next field's error message displayed. Of course, for users who still prefer the message box error, upon saving inspite of errors being highlighted, a message box is thrown up with the error message and code. Expected formats for each field are filled up in the field space, like the integration build field.
I just loved this error hinting policy in WIT. Let me know if you have seen nicer examples of hinting at user errors! :)

Comments

• Anonymous
  December 20, 2005
  Last June I blogged about the background color trick to prompt for required fields in http://blogs.msdn.com/abhinaba/archive/2005/06/26/432832.aspx. Even though some of our tools including Work Item tracking in VSTS uses it, our usability folks pointed out that its real bad for the visualy impaired.
  
  Similar reasonings exit for error provider. Study show that people do not read pop-up messages and even less can be expected for the unobtrusive error provider. However, I still think that the error provider is real cool, specially when used in grid controls. You can mark each row with wrong entry with it.
  
  I think being consistent is more important than being correct or better all the times. VSTS ui is very consistent and play along real well with the VS shell. However like all big projects there are small inconsistency here and there. Like only WIT has color coded required fields and only Team Project notification uses the error provider when you do not enter the email id and so on....