Enhanced user experience with contextual error messages

[Tomi Maila]

I just posted a new ExpressionFlow article

Enhanced user experience with contextual error messages

Don't hesitate to comment and discuss here on the forums

Tomi

[AndyDm]

ZITAT(Tomi Maila @ Nov 2 2008, 12:18 PM)

I just posted a new ExpressionFlow article

http://expressionflow.com/2008/11/02/enhanced-user-experience-with-contextual-error-messages/' target="_blank">Enhanced user experience with contextual error messages

Don't hesitate to comment and discuss here on the forums

Tomi

I will continue here, because here we can start very nice and long discussion about usability issues for such simple dialog...

The use case for such dialog usually is following:

- Dialog appeared (user has clicked button somewhere, pressed hot-key, etc)

- User immeaditely start with text entering.

- When user ready, then he will press Enter and dialog disappeared immeaditely.

The main goal is reducing the number of actions (mouse clicks should be avoided anyway).

This logic assumed:

- when dialog with text field coming, then the focus should be set on the text field.

- For "OK" button we will set Return Key for toggle action, and for Cancel - Esc.

Now we needed to find better place for error checking inside of the dialog.

Well, error checking can be done when Enter key pressed, but how the realization of the logic above will be possible without setting "Update while typing" property?

In attachment quick example with illustration what I mean.

Andrey.

[Tomi Maila]

Andrey suggested to check for input errors while to user is typing the input. I was initially against this idea as it can be very distracting for the user if an error message is displayed when user is correctly entering a value into a control. However, we can alter the value validation algorithm slightly to be used with update value while typing. We can check if the string user is typing can lead into a valid value while user is typing the value. If not, we display an error message. If the beginning of the string is valid, we should not distract the user but let her continue. However, we should not allow user to continue until the value is fully completed.

I edited the example in accordance with these principles. The regular expression for checking partial string is constructed from the regular expression for full strings in the following way. Our full regular expression string consists of several components. A partial string user is typing is valid if it is 1) empty or matches 2) partial first part, 3) first part and partial second part, 4) first and second part and partial third part, and so on. You get the point.

The edited example can be downloaded from the blog.

QUOTE (AndyDm @ Nov 3 2008, 08:45 PM)

The main goal is reducing the number of actions (mouse clicks should be avoided anyway).

This logic assumed:

- when dialog with text field coming, then the focus should be set on the text field.

Ok. I added this functionality to my modified example as well. Thanks for good feedback.

QUOTE (AndyDm @ Nov 3 2008, 08:45 PM)

- For "OK" button we will set Return Key for toggle action, and for Cancel - Esc.

This can be risky as pressing Esc doesn't in general mean close and loose all my changes. I would force users to actually press cancel button to cancel.

[Yair]

You should note that I have actually seen people opposed to disabling OK buttons and instead describing the problem once the button is clicked. In any case, I don't think there's a single correct answer, as there will always be people who will find one method less usable than the other.

Incidentally, in many of the systems I do, errors and faults are not caused by the user, or at least by an action the user does in the PC. What I usually do is pop up an error message and also have a section of the UI which shows the currently active errors. Of course, this is also only relevant for certain cases.

[PaulG.]

Lately I've been doing a some equipment safety check coding. As long as there are operators there will be operator errors - and in our case a possible loss of an expensive UUT and wasted time and data if the operator makes a mistake. I'm sure there are dozens of ways to do it, and my application isn't that complicated, but in this situation comparisons and one button dialog error messages ("Error: test position already in use.") where the test software will not continue until the error is corrected seems to be working very well.