1

I am in a bit of confused state in terms of how to design flows for forms.

Let's consider a scenario

I have a form with fifteen fields(it is pretty normal in my application). All these fields have their respective validations and corresponding error messages.

Now given that there is a high probability that there can be multiple erroneous fields, there will be multiple error messages returned from the API. I also have control over how the API returns those errors. Where I am stuck right now is do I return only first error encountered or do I process the entire form and then return the set of errors. For me both of them have it's pros and cons.

But I am unsure of how others deal with it in general. What would be a good practice? Would it be to process the entire form and then return set of errors in one go to save consequent multiple requests to complete the cycle of correction-submission-validation or just return the first encountered error?

  • What benefit is there to the user for you to only return one error at a time, even if the form has multiple errors? – JonW Jan 27 at 9:21
  • No benefit as such. The only benefit that could be is that the focus can only be on one error at time. I am very keen on showing all the errors as it would save a user consequent cycles of filling and submitting. – Rajesh Yogeshwar Jan 27 at 9:47
2

If you can return all errors you should return all errors. Returning just the first error encountered is a side effect of lazy or time restricted implementation where it's easier to just return a string and have a single error field somewhere in the form. Returning just the first error will only frustrate the user when they have to submit the form multiple times especially if there are fields that can't be saved such as password fields that need to be re-entered every time.

  • I totally agree with you James. The further question is, is it a norm to do it in such a way when the forms tend to be longer? – Rajesh Yogeshwar Jan 27 at 9:49
1

Some surrounding considerations to this problem:

  • Security: the API should definitely be doing the validation, even if the client-side does it well.
  • Radio usage/data cost: especially on mobile, requiring the User submit the form multiple times to get the full feedback of invalid fields for a single form is inconsiderate of radio usage (battery drain) and data costs. E.g. if the form were one for setting up international roaming on a Telco website, many users may be roaming while trying to use it.

Technically, your software client can receive the validation response indicating multiple fields are invalid yet choose to only display feedback for one field at a time. That is quite normal for large forms, and it is the way that setError works natively on Android (all invalid fields will be highlighted but only the last one (make sure to programmatically call setError in reverse order, bottom to top) to have setError called will display the error balloon.

Many years ago I wrote an open-sourced library that aimed to help Android developers do abnormal things with the setError mechanism, I doubt it works well out-of-the-box now but you may find some solutions in the code and resources: https://github.com/coreform/android-formidable-validation

  • Thank you @straya . The considerations on mobile client is really helpful, I was unaware about it. – Rajesh Yogeshwar Jan 28 at 6:02
0

I second @James Coyle's answer, return all error messages. I would also have to add that the client itself should validate the information before sending the information to the server if its possible. That way, it would take off some load of the server and the response of client errors would be immediate rather than waiting on the server to tell the client that it sent invalid data.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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