Displaying errors to a user - One at a time or all at once?

Question

For context: This is a desktop application interacting with a service running on W7.

I'll try and leave all the technical details out of this, but here goes:

Part of my application has to send a large amount of data to the server which is then validated server side. Any errors found are sent back to the client to handle.

My 'problem' is that this large amount of data (in this case, a person) can have a lot of things 'wrong with it' which can be summarised into two main errors:

• Required fields not being filled in. (Name not provided)
• Data being entered but still invalid due to a business rule (person is under the age of 18, phone number entered as ABC123, assessment was completed, but no completion date was entered, etc.)

Now even with all the client side validation I can put in, there still might be cases when a number of errors that aren't detected. (business rules, mostly) How should these errors be displayed to the client? I only see three real options here:

1. Displaying the server side errors into the UI somehow. I'd like to avoid this possible since I'm not 100% sure on how to code this without writing a mass of spaghetti code to determine which error is for which field.

2. List one error at a time. When a user submits the data, show the first error that is returned and ignore all the others. When the user resubmits, shows the next one, and so on. I have a feeling this could annoy some people who will probably send me angry emails along the lines of 'Why don't you show me all the errors at once?!?!?'

3. Show them all at once. I could have all the errors showing at once, but this is going to cause a few problems:

   • The dialog box should potentially be huge if they've somehow got 15 or so errors.
   • No one is going to remember all 15 problems unless they screenshot the message or write them down.
   • The API on Windows might not allow me to fit all message in one dialog leaving users to click through an unknown amount of dialogs.

How should I approach this?

Answer 1

I'll agree with you, showing errors one by one could be really annoying and might have a negative impact on your business or users.

A form is like a conversation with your users. Why not be a great communicator and use inline form validation that's delivered at the right place and at the right time? For example, take a look at Twitter's sign up form:

In cases where the errors were not detected until the form was actually submitted, you can do a couple of improvements:

• Show inline errors to each form-field, instead of a block of errors that don't relate to the actual form field.
• Display qualifying sets of requirements next to the question once the user has clicked into the field, giving them a visual overview of whether their input meets the business requirements

• If inline error messages are not possible, allow a scroll-link in the error message that will scroll the user to the exact form field where the error exists.

Answer 2

You want your users to pass validation as soon as possible and in as few attempts as possible.

If I understood your option 1 correctly, you're talking about providing on-the-fly validation for server errors. Purely in terms of UX this would be the best solution because it helps to achieve the goal above. It is however perfectly legitimate to say that that's not a feasible solution for you, that's up to you to decide.

Option 2 is probably the worst - again, assuming the goal above. Sounds like it can cause them to submit many times, causing considerable frustration.

Option 3 is the second best, it lets them gain considerable progress after each submit, probably getting it right by the second submit. The problems that you raise are good ones, but they all stem from the assumption that it must be a dialogue box. That's not necessarily so. You can allocate some real-estate in your app for error handling, and solve all these problems at once. You can display all errors but let them handle them one by one, jumping to the relevant place in the app for the next error. Look at your IDE - you submit your code and it returns a large bunch of errors in a very efficient way, letting you go through all of them in context.

The answer depends on how many errors are they likely to get. If you have a way of checking or guesstimating this, do that. If a large number of errors is a common scenario (complex/unpredictable business rules, difficult data, stressful work conditions), then I would go with the last option, even thought it means considerable development effort. But if that's just an edge case, you might be fine with a dialogue.