The complexity of proper UX of web form

It seems so easy. Write some html for a form with some input fields and just submit the values. Sadly users will make mistakes in filling in your form and without proper validation and sanitization your website will give a very buggy and frustrating feeling. Since i'm trying to improve the auto-generated CMS of Apie I've been focused on getting the UX done well and it was time for me to dive into the wonderful world of forms.

Why can it not be handled by the web browser automatically?

So web forms are possible in web browsers since Internet Explorer 4 and Netscape Navigator, so you might expect that they will handle proper UX out of the box now. Sadly this is not the case for several reasons:

• Lack of control if we would let the browser handle it. For example file uploads are very rigid so often a designer will hack around it to make it look nicer.
• Good UX is OS and device specific. For example undo is ctrl+Z in Windows, but it's a different shortcut key on a Mac. And don't make me tell how it is done on every type of mobile phone.
• Backwards compatibility is also a thing. Forms still work the same way they did 10 years ago and still have the same confusing HTML design. It would break many websites if they discard this.
• There's no general rule on good UX as it's very subjective. It really depends on your user audience and culture.
• Often features that a web application should have, but are discouraged for usage are deliberately made bad in UX. For example canceling your subscription is often hidden or added with extra 'features' like upsell or cross-sell to get you back as a customer.

Traditional web form validation

In a traditional web form we submit the data to a server. If the fields are not properly filled in, we redirect to the same form and display the error messages.

Why the redirect? This is also UX-related. I can not safely refresh the page without getting a confirmation message from the browser if I want to submit the fields again.

Traditional web form validation is still the best solution especially if a project is low-budget. There has to be server-side validation because of security, so it's the minimum to add. Some validation can also not be handled client-side because you would have to expose too much information.

The least you could do is make sure to hide the validation error if the customer changes the form field again. There is nothing more confusing then a form input with a valid e-mail address still telling me the e-mail address is invalid.

This is very confusing for a user if you do not remove the error on editing after showing a validation error.

The programmer web form mistake

I see this a lot in people developing a web application. Programmers prefer to see direct feedback right away, so for them it's very normal to show a validation error that the e-mail address is incorrect when you are typing this. Often they even show an error that a field is required before the user has done anything at all. Don't do that!

Just imagine an user will see an error the moment they see the form.

For most users any error message is 'scary', so only show a validation error in case the user does something like filling in an other field or pressing the form submit button. It's better to show like a green check mark if they did it correctly unless they tried to submit the form incorrectly.

Since we are still typing, 'test' is not valid as an e-mail address, so we see a gentle gray marker

The moment we do type in a valid e-mail address we make the marker green as an positive acknowledgement to the user they did something well.

In case a user does not provide a correct one and tries to submit the form, we show the error! 

For complex fields with lots of restrictions, for example a password field, it's often better to show all the requirements as separate rules and show a positive green marker for the restrictions that are applied:

Dirty and touched status

• Dirty: a dirty form field means the form field no longer has the same value as compared to when you opened the form. Undoing your change often means this field is no longer dirty either (even though some people will debate this).
• Touched: a form field is touched if some user interaction was done, for example I clicked on it. It does not mean you modified the field. This is oten used to not show a validation error until you had some interaction with it.

Depending on your audience and use of technique (traditional form or SPA + REST) you will execute this differently. For example if an user tries to submit the form, but the form has invalid fields it might be a good action to mark all fields as touched. Again it's subjective what is the good solution for your application.

Is your form a traditional form? Then you might need a warning/help text on file upload fields that they have to be uploaded again if a validation error occurred. Other fields could also have help texts to give a little bit of context what they need to fill in.

Required or optional fields

It should be very important to mark fields as required or optional. The simplest solution would be to add a '*' to a label and display at the bottom of the form that * means the field is required. Better is to just add (required) or (optional) to the label. The guideline is that if there are more required fields, you will display all optional fields with an (optional) label and if it is the opposite you will mention the required fields as required.

But UX still stays subjective. For example there is no guideline if you should only apply the required or optional label if you look at all forms in a web application. It could be inconsistent if one form shows 'required' and the other one shows 'optional'.

Pitfalls and gotcha's

There are also some pitfalls and gotcha's I see a lot in web forms where validation is not handled well and is often forgotten in implementation. They are often about how to show error messages that are not part of the form.

Expired CSRF tokens

For example for security reasons it's good to have a CSRF token submitted with the form. However the token can be expired or invalidated. I've see many applications showing me the standard Laravel 419 session expired page when an invalid or expired CSRF token is used. It's better to do it like Microsoft does it in their logins by telling that their login took too much time and you need to try again. Another pitfall is to fill in the values you received on an expired CSRF token. This could be a security risk as now an attacker has the form filled in with fields they want and a valid CSRF token. Of course it could be frustrating for users if you do that!

Unmapped validation errors

What if we get a validation error on a field that does not exist or is not visible? If the field does not exist, the best solution is to show the validation error near the submit button or the top of the form. While you might think this never happens, it's possible I'm submitting a form when a new version of the application is being deployed where a new field was added.

It's also possible that the field is not visible because the form is complex enough to require tabs. In such a case it might be better to autofocus the tab with the first error or if that is not possible mark the tab in an error state. My advice would be to not have a multi-page/tab form in the first place!

Design system

It's always a good idea to have a design system including all form inputs and how they would look like. Besides dirty and touched, an input field could be readonly, mouse hovers over it, disabled, have a validation error and is required or optional. So that means there are 2⁶=64 number of possible combinations.  A good solution for this is to use a tool like storybook.js to show all input fields and how they should look in all situations. This also works as documentation for other developers how they should use the input fields. I'm working on a design system for apie/cms and to help me I have a working testing tool to get all possible situations:

I'll come back about how the design system worked out as I'm still improving and working on it. In modern web applications UX is very important, but also very time consuming to get done correctly. I try to make sure that in my Apie library the choices for good UX are made for you so you don't have to think about it.