Web forms are one of the most functional aspects of a web page and the most common way to submit data back to the website. I am by no means an UX specialist, but I would like to share some tips and techniques I have learned about designing web forms, together with some of the logic behind them.
Forms
First of all, there are a few things one should be aware of when dealing with web forms. If you have several submit controls on your form, and the user submits it by hitting the Enter key on a text input field, the first submit control in the form’s markup will be used. If it is disabled, the form will not be submitted. This also means, that if the submit button has a name, it will be sent to the server as a parameter along with the rest of the data. This is a thing to watch out for if your backend cares about which submit button was used. If the user submits a form by activating a certain submit button, then only that button’s value will be sent along with the request. If you use an INPUT element of type submit or image, its label (the value attribute) will be sent with the form data, but if you use a BUTTON element, you can specify a different label than your submit value, because the button’s label is defined by its inner HTML. Another interesting thing is that you cannot nest one form tag inside another, so the inner form’s opening tag will be ignored and any controls after its closing tag will remain outside of the form.
Labels
One of the most important elements in a form is the LABEL. Some designers use placeholders inside their input fields in place of the LABEL element; however I am not fond of this approach in most cases. No matter how nice placeholders may seem, if you use them as labels, the customers might need to click away from a text input field or even remove any text they have typed into it, if they happen to forget its purpose once their browser focuses on it. However, this may not be an issue in a simple search form.
Labels are important for accessibility for your disabled audience, because they associate the label’s text with the relevant input control. They also improve the usability of your form by increasing the clickable area which gives focus to your input control. You can connect a label with your input control in two ways: by using the for attribute on the LABEL or by wrapping the control with it. I personally prefer wrapping the input with the label, because it can help you avoid the use of BR elements, by making your labels display as a block. Another reason is that the for attribute requires the input to have an id attribute specified. This makes the markup harder to maintain and more error-prone (the for attribute has to point to the right id and must be updated if the id changes later). However, using the for attribute is the only way to go if for some reason you need your label to be somewhere else in the markup than right next to your input.
A good idea is to also introduce a short but informative explanation for each of the input fields, especially if its purpose is not very clear to a new visitor of your website. For passwords and similar fields with special requirements, it could indicate their validation constraints.
Label Placement
I believe the problem of label placement has significant impact on the usability of a design and I also believe it should always be addressed by designers when they work on web forms.
For checkboxes and radio buttons, I find it most natural for the label text to be situated to the right of the input element. That is because this is the most common way of visually representing such elements. Just look at a typical configuration screen for your operating system — I am sure any checkboxes and radio buttons there will be displayed in the same manner.
For the other controls we have two logical alternatives: the label text could be above the element or to the side of it (to the left or right, depending on your audience’s reading direction). I personally prefer having it above the input field. This is because it makes it easier for the user to look from the label text to the input field (they are closer to each other visually and the eye of the viewer ideally needs to move only in one general direction — downwards). If you decide to put the label on the side, you may need to modify the alignment of the label text, so it would stick to the INPUT element, in order to compensate for the cases when the form is wide and leaves plenty of white space between the label text and INPUT element. Otherwise, it will be harder for users to follow visually which label points to which field, especially if they are close to each other vertically.
Submit and Reset Inputs
If you chose to include a reset input in your form, be sure to keep it at a sufficient distance from your submit buttons, so the users will not click it accidentally. You should also make sure to have the users confirm their choice, possibly using a confirm dialog, like in the following JavaScript code:
var inputs = document.getElementsByTagName('input');
if(inputs && inputs.length){
for(var i = 0; i < inputs.length; i++ ){
if(inputs[i].type != 'reset')continue;
inputs[i].onclick =
function(){return confirm('Are you sure you want to clear all the form fields?');};
}
}
The main submit button (in case you have more than one) should be the control which stands out the most. This can save the user some confusion while trying to submit the form. The most natural place for a submit button is the bottom right corner of your form, mainly because most people in western countries read from left to right and from up to down, however if the majority of your audience reads from right to left you might need to adjust the button’s position.
For long forms you could include a submit control both in the top of the form and in the bottom, for convenience, in case the users decide to go back and modify the data in one of the upper fields before they submit.
If your form starts getting too long you could organize the inputs in several columns or even split it into a several step process. In the latter case you should have a clear indication of which step you are in together with a list of all other steps, so the users can have an idea how many forms they have left to fill out. A notable exception is the concept of a one-step checkout form. In this case, you could visually collapse some parts of the form, like extra addresses, unless the user indicates they are different.
Validation
It goes without saying that every form should be validated on the server side. However, you should also perform validation when the user tries to submit, and even better, in real time as the user enters data in the fields. The optimal approach would be to use the HTML5 validation features. For example you could set the required attribute on the input fields which need to be filled in. If you are familiar with regular expressions you can also specify a validation expression using the pattern attribute. Just be sure to test it out. For the better known data types you could specify one of the HTML5 input types like email or url. For browsers which do not support these new features, you will have to resort to JavaScript, but you should not worry, there are plenty of resources out there. One way to go is just to use the HTML5 attributes on your FORM elements and load a JavaScript library like Modernizr to detect the support of these features and provide a fallback if necessary. This will be a good occasion to start learning JavaScript if you do not know it already.
When it comes to the placement of validation messages, I believe it is best if they are placed together with the relevant fields, instead of being at the top of the form. This saves the user a lot of time of going back and forth in order to read validation messages and then correct the errors. Therefore, I believe it should be easy to fill out and submit a form as well as correct any validation errors on it using only your keyboard.
All in all, I do not consider designing web forms difficult. I do not believe in a set of global rules, but I think designers should always know the reasons and logic behind their choices. Even if you do not agree with what is written here, it is okay, as long as what you are doing makes sense when you think about it, both as a designer and as a user.
