This is the message

Experiment - a new way of validating forms

James Ing
Sunday 22 March 2015


Improving the way we fill out forms.

Filling out forms is never fun. I still remember filling out my end of year taxes and needing three paper copies due to the number of scribbles, crossed out numbers, miscalculations, and general malarkey that goes with tax returns.

Thankfully IRD now offers online forms which do a lot of the heavy lifting behind the scenes, a wonderful time and stress saving move. 

But simply having a form online doesn't instantly make it stress free. A badly designed online form can be just as troublesome if not worse than a paper form.

One particular benefit of online forms is the ability to validate data before it gets submitted, making sure the information being sent is relatively correct before being recorded as data.

In this blog post, I'm taking a look at two common form validation approaches and a potential third experimental approach that's been floating in my head.

Validating on submit

Traditionally most online forms use this approach where users enter data into the formfields then submit the data. The backend will process the information and return an error message if something isn't right.

The main problem with this is you're not providing users any feedback on information they're providing as they're filling in the form. 

If you're asking for a phone number, and the user types in "(+64)23 123 321" but the form is only set up to accept numbers, the form will report an error with the data only after they've tried submitting the form. 

If the user happens to enter a lot of bad data you potentially can return a long list of errors which is never a positive outcome for a user.

How could we improve this? You can improve the user’s experience by providing them with helpful information on what data we're expecting the user to input. Examples include using placeholder and hint text.

Some forms return an error box at the top of the form listing how many fields are incorrect. While this provides some feedback to the user on what they need to correct, it requires the user to manually sift through the form to find the right field. This becomes even more difficult in longer forms as there may be a big gap between the first error and the next one, requiring the user to scroll the form to find it.

One way to improve this experience is to include a summary at the top listing the errors, with a link to take the user to the appropriate field.

Validating after each input:

Another approach is to validate after each input field as opposed to after the entire form submission. After the user enters the data in each field the form will check the value and return an error message if invalid. 

Using this method, successful form submissions increase as the quality of the user’s inputs is improved before submission (source). 

There are still some caveats for using this method. In a worst case scenario, the user will need to jump back after each field to correct their mistake. Most users are unaware of 'tabbing' and additionally 'reverse tabbing' (holding shift and pressing ‘Tab’) to jump to the next and previous input field respectively. Typically a user will navigate with their mouse to click on the input field to correct the mistake. This can actually make a form that validates after each input longer to complete in some scenarios. 

The validating can normally be done on the client side for simple format checking like an email address. 

If the data needs to be validated against a particular system e.g. check if a member number is valid, it may be necessary to validate asynchronously with the backend system. This means that after you enter the input field, it will try and send the data to the backend server in the background, while the user continues to fill out the rest of the form.

If the validation fails it could potentially cause issues and will probably need to fall back to doing some validation on submission instead.

My experimental approach

This experimental approach combines aspects of the two previous approaches. This method is initially similar with the first approach, allowing the user to fill in the form and press submit before conducting any validation. But rather than simply returning a list of errors in the form, it provides the invalid form inputs directly in its place for the user to correct quickly. This should help speed up form corrections, especially in longer forms.

The downfall of such a system is that it still suffers from a bad edge case where if there are a lot of bad entries it could possibly just return the entire form.

Where this form could really be of benefit is that it allows for users to complete as much of the form as possible without interruption. This is especially useful if the form is split across multiple areas in a system, or the data needs to be entered quickly and corrections can be handled at a later date (time sensitive input).

This could also be potentially utilised in a modal window setup as that focuses the user of the necessary next steps for completing the form.

Conclusion

One core function of Frontend is looking for ways to constantly improve how users interface with online systems. Entering data in a form is one particular aspect that has slowly been refined by trial and error. But each form and user situation is different and sometimes an alternative method is required to fit the context the form is being used in.

We're constantly working on new innovative solutions to improve the end user’s experience.

One initiative we've been implementing is recording our ideas down and prototyping them quickly, they're not neccesaily refined or finished, but capturing that core idea can potentially lead to a solution for a future project.

This has a been an example of this, and we're hoping to release more blog posts and more experiments in the short future, as I've been doing a lot of thinking. More on this soon.

Experiment - a new way of validating forms