1

So let's say that we have a form. This form has multiple inputs, many of which are required fields.

Understandably, we should not turn a required input red and show a validation message before the user has had a chance to submit a form. It is my understanding that we should wait for a form to be submitted before showing such messages.

So my question pertains to what to do after the user attempts to submit the form and the required-field validation message is shown. If the user now enters something, the required-field validation message should (in my opinion) go away before the form is submitted. However, if the user then goes back and clears out that field again, would it be proper to show the validation message again immediately (since the user has already attempted to submit the form once,) or should the required-field validation remain hidden until the user attempts to submit the form a second time?

Whether or not the required-field validation goes away once the user types something/makes a selection is not part of this question, though feel free to give your input on that as well. My main question pertains specifically to whether or not to re-show a hidden required-field validation message on a form which the user already attempted to submit, after the user has entered and then erased (selected/deselected) the input.

1
  • 2
    I think your initial premise is wrong. Warn the user as early as possible that his input is invalid. Jan 7, 2015 at 16:08

4 Answers 4

1

Having validation in place to check values when the form is submitted to prevent invalid input making it to your database or whatever is always a good idea, regardless of whether or not the form was previously submitted. If feasible, validating input as the user is filling out a form (i.e. after a user edits a field) is extremely useful as it let the user know right away there is a problem. This may not be possible/feasible from a performance perspective depending on how you are doing your validation.

Hope this helps.

1

A good guideline for validation is that it has to be the least strict as possible and right away. 2-steps validation as you describe combined with a very strict validation may result in the user feeling frustrated by your service. Meaning: "Make everything as simple as possible, but not simpler" A too strict validation may also reduce the overall elasticity of the service, an unexpected input that should be valid could result in an error to the user and this leads as said before to frustration, more clicks, more useless requests/post and as a consequence a reduced accessibility and usability of your service. A straight away alert for validation of the user input is best for many reasons like context, there is no change of context between the filling and correction. The user can proceed in a more "light-hearted" manner, knowing that all the content already filled in is correct, at least formally. Wasted time and waiting time, the user can succeed in posting the form in a smaller number of attempts in most of the cases.

So let's say that we have a form. This form has multiple inputs, many of which are required fields.

I don't know exactly how many fields you mean with many, but I can say that the relevance of a fast mechanism to let the user know there's been a validation grows at least accordingly.

My main question pertains specifically to whether or not to re-show a hidden required-field validation message on a form which the user already attempted to submit, after the user has entered and then erased (selected/deselected) the input.

Although, from your explanation it seems like you change your strategy to alert for validation errors from post-submission to immediate, since after the first failed attempt you are undecided to alert the user straight away if her/he still skips a required field when selecting/deselecting or erasing, I guess you should pick one and be consistent, consider that if you decide to completely switch to alert beforehand submission you will also avoid this issue.

1
  • I largely agree with your reply, but not the "as strict as possible" part. When users are typing a value, let them mess around until they indicate they're "done" by attempting to move the focus. For example, if the user wants to enter 2015, and they mistyped an extra 0, allow them to type the 5 – to make it 20015 – before they go back and delete the extra 0. When software tries to beat the user at data entry, the experience is like that annoying child in class with his hand up, saying. "Oh, oh, ME, oh, OH, I know!" Nobody likes that kid, and nobody likes software that behaves that way.
    – JeromeR
    Aug 22, 2015 at 23:17
1

This sounds like a "Visibility of system status" issue from 10 Usability Heuristics for User Interface Design

If the field is mandatory then communicate this to the user. Note that the "Error prevention" heuristic would say communicate a potential issue as early as practicable.

Now explicitly to question indicating it again, take the guidance from "Recognition rather than recall" heuristic would definitely say do not assume that user would remember if a field is mandatory.

While it may sound like a "smart UI" to react to a developing situation, vast majority of users (i.e. non-techies) prefer straightforward, repeatable, predictable and non-conditional UX.

0

Would it be proper to show the validation message again immediately (since the user has already attempted to submit the form once,) or should the required-field validation remain hidden until the user attempts to submit the form a second time?

I think if the user makes the same mistake again it's because your field (and the label) with the required-field validation message are not clear for him to do the good action.

For sure, I think it's a better solution for user experience to tell "be careful" before the user is disappointed. But, as much as possible, you have to avoid error messages and adapt your solution to the user habits. So if user makes the same mistake again, I think the problem comes from your initial solution. What do you think?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.