Same or different visualisation for validation errors and concurrency errors?

Question

In our application we use several forms for data input. Validation errors are shown beneath the corresponding input field (inline validation).

Now we will also introduce a concept for concurrency situations (two users changing the same data set at the same time). In case of a concurrency situation we will probably have some kind of warning message that tells user2 that user1 made changes to the same data entry. User2 will have to decide whether he wants to save his changes (and override changes made by user1) or discard his own changes and keep the changes made by user1.

Now the question: Would it be a good solution to use the existing validation error visualisation for these concurrency messages (consequence: the user wouldn't be able to visually differentiate between a validation error and a concurrency message)? Or should we use a separate message box for these kinds of concurrency errors?

Here is an example of a (inline) validation error message for an inpuut field: https://plus.google.com/photos/100025793446391279908/albums/5800923977393083297?authkey=CLKBofbap_7KzwE

Should concurrency 'errors' better be handled by a seperate message box above the form that presents the possible actions per error? Here's an example for a concurrency error message: https://plus.google.com/photos/100025793446391279908/albums/5800923977393083297?authkey=CLKBofbap_7KzwE

Answer 1

It would help alot if you posted the example of an error message.

However, i think there is no need to visually distinguish between validation and concurrent action messages, If your current error messages are enough alarming. You should make sure that the message is strongly visually emphasized as concurrency messages are of more severity than user's personal wrong actions.

Answer 2

Of course they need to be differentiated. The user needs to know what's going on and he needs to be able to classify the problem quickly. Experienced users are usually familiar with the validation rules, and they may provide invalid input just because they were distracted, or because of a typo. In such cases it's enough just to see that the input doesn't pass validation in order to say "oh, right, I can't use spaces here" - without the need to read the validation message itself. If the two types of messages look the same, it means that the user can't quickly tell the reason for the error message and he needs to actually read it.

Also, it can be frustrating to know that your input is correct but you still get an error message. People generally don't read error messages, they just dismiss them and try to correct the input. So if they can't tell the messages apart quickly, they'll be trying to correct their input when there's nothing wrong with it, so then they try to read it very very carefully, trying to locate the typo.

In addition, when you just dismiss an error message without reading it, by just pressing Enter, nothing happens. But when you blindly press a button on a concurrency warning, you either discard your own work or that of another user, so you want to avoid mixing them up.

Answer 3

I thi m you should differentiate. One one side the system does not know how to address the issue and the resolution is open ended. On the other side, you can provide a quick A or B choice.