Progressive Validation and Disclosure

Question

I am trying to find an example of progressive validation. We have a UI for a a visual editor where a user does things like indicate dimensions in pixels or percent.

The editor properties are in sets of tabs so not all fields are visible at the same time. We have been discussing how and if we do validation in this UI.

I come from the perspective that: a) Validation is useful because it will create a communication channel where the user can learn the expectations of the software and "get better" at what is required. b) It is always better to indicate validation errors on input fields directly (whether or not a summary is used elsewhere) so that users have a visual cue for what needs to be changed.

My colleague, for whom I have nothing but the utmost respect disagrees. His logic is as follows: a) It will be more expedient to either prevent certain types of entry or, in the case of some entry to change it to a more appropriate value if it is invalid. For example, if someone uses a percentage value greater than 100 the UI would reset the value to 100 in a lost focus event. b) Because we are in a tab environment, some of the errors will not be visible to the user. Using a summary is futile since there can potentially be "a lot" of validation errors.

I thought a solution around this might be a progressive disclosure of invalid values. As a user inputs values that may be incorrect they are flagged in some kind of summary. The summary allows users to navigate to the fields in question as well without them being visible.

I wish I was an original person but I'm sure there are precedents here. My questions are as follows:

1. Anything to add to the perspectives of either me or my colleague?

2. Any examples of a UI like this with complex entry that does progressive validation?

Answer 1

We are currently grappling with the same issue for a desktop app, though not tab-based. You can try an approach like this:

where a small icon appears if something requires the user's attention. Maybe even use two colors: yellow for warnings, and red for things that must be fixed before the user can go further.

Answer 2

The best thing you can do in this complex situation is create a prototype of as much of the UI as you can and test it on your user base to see what happens. You can use HTML in combination with something like jQuery UI to quickly get a lot of interactive controls available and ready for testing quickly.

Your tab system sounds complicated so I have to suggest a couple of things to simplify:

• Create "apply" buttons within each tab so the state can be saved only for the properties the user can see right now. If that would result in an invalid application state, redesign your tabs so users have properties grouped together that can be saved independently from one another.
• If you can't do that, you could highlight tabs with an "invalid" icon and a color to indicate properties in that tab need attention. While any tabs are invalid, the "apply" button is disabled. You could consider adding a notification to the button if it gets clicked to display a message indicating that there are still errors. Summaries for what's wrong would be displayed within each tab as opposed to having an overarching summary.
• A global summary might work, but I'm hesitant to suggest it as it seems like there wouldn't be an immediately obvious location to put it, and unless that's the case, are users going to notice?
• How are properties grouped? Likely functionally? Try looking at them from a different angle, for instance by likelihood of use. This is part of how Microsoft approached the Ribbon design for its Office 2007 products. Pehaps you could design your tabs in such a way that most users only need to mess with properties in the first, or immediately visible, tab and the other tabs could be considered "advanced" or contextual.

Ultimately, and I already said this, test your design! :-)

As far as handling errors goes, my experience has been that if you prevent certain input, users are going to be confused. For instance, if it's not clear from an input field that only numbers are allowed, but you disallow any other characters anyway, that's going to be frustrating to the user - they won't experience it as an intelligent form that's trying to help them out. So I suggest you use clear microcopy throughout if you decide to go down the path of using events and input detection to automatically correct things.

But all this is anecdotal - I haven't done any research in this area. Instead of taking my word for it, refer to Luke Wroblewski's book, Web Form Design: Filling in the Blanks, and his research into error handling for some useful insights into how to deal with situations like this (for instance, this post on Apple's checkout form redesign discusses how they handle errors in detail).

Answer 3

I recently worked on a project that encountered a similar problem. You can see a screenshot of how we solved it in my "Minimizing Complexity" article from last year.

Answer 4

I thought of a case where a summary for many errors is used and kind of works, perhaps.

In any IDE like say Visual Studio there's potential for endless amounts of errors either when building or using any static analysis tools while writing code. Generally there are dozens or hundreds of files and many of them open in tabs, with one or two visible at any one time,

The errors are then listed in a scrollable resizeable list that slides out (by default) below the main UI. This could be done as soon as an error is trapped. When an error is clicked or double-clicked it takes you to the right place and focus to correct it - and the error disappears from the list when it's not valid any longer.

(In reality, many of these errors need a user-initiated action to be re-assessed but there are plenty of static analysis add-ins that does this in the background and actually update the error list dynamically while editing code).

Answer 5

a) For example, if someone uses a percentage value greater than 100 the UI would reset the value to 100 in a lost focus event.

Good point, but then you need to make sure:

1. The user realizes that his input has been fixed.
   Maybe, for example, make the field flash for a second if you fix the value.
   
   
2. You can reasonably guess what the user really meant.
   For example, take a color picker I wrestled with yesterday. I wanted a few elements to match those from another site, so I got myself the hex values and copy pasted them into the tiny ad-hoc textboxes. The first value was #202040, but for some reason I only pasted #20204, which was promptly "fixed" to #020204. The second value I pasted in was #BCD (shorthand for #BBCCDD), which also was "fixed" to... #000BCD. Sigh.