Some thoughts on forms

I've been doing front end for a series of forms for the last few weeks, which has involved working quite closely with the UX guy on how they should be laid out and operate. I've worked on forms before, but somehow have gained a deeper understanding of the complexities involved this time around. I'm not sure I've fully decided what's right or what I would do given the opportunity to design a form myself, but there's definitely some food for thought here.

Here's a simple example. The form needs a field for gender, which will contain two options to choose from, male and female. In the wireframes this was shown as a select dropdown, but it was implemented as two radio buttons. Radio buttons in this situation only need one click to select one of the two options. A select dropdowns introduces an extra click, once to show the list of options and once to choose one, so surely the radio buttons are the better choice? Well no, as it turns out. The reason for this is that apparently one aspect of radio buttons is that their initial state should have one option selected by default, whereas a select dropdown can have a blank option at the start saying 'Please select'. We don't want people skipping over this question by accident and putting in the wrong gender. Also there are people in this world who might organise some kind of protest against a website that specified a gender by default, and we don't want to go upsetting them.

The radio button discussion doesn't end there, though. Having established the rule above, we come to another question on the form that also has only two options - 'Do you have a disability?'. Here our design called for radio buttons and by default 'no' was selected. At this point I start to get confused - is it okay to have a default option here (and therefore use radio buttons rather than a select) because the two options are less evenly weighed than in our previous question? That is, the number of people with a disability is smaller than the number of people without? Of course technically speaking there's nothing to stop a form using radio buttons and not having one of them selected by default, but it is impossible to deselect a radio button once one of them has been chosen.

If these two questions result in conflicting rules for the type of form field that should be used, what about an alternative form field type? Obviously there are situations where controlling the options the user inputs is desirable - having a text field for gender would produce nothing you could make a useful statistical graph out of (can you imagine a bar chart of gender with 1500 columns including 'wolfman'?). We also don't want users to choose more than one option so that rules out checkboxes and select multiples, and somehow the idea of a select with a size set (so both of our two options are visible already but you can only choose one) feels wrong and also takes up more vertical space, so we might have to re-consult our graphic designer.

Some things to think about there, then. If that was a simple example, I don't want a more complicated one. Oh wait, here it is - date of birth.

I've seen date of birth (DoB) fields implemented in a range of ways over the years. My preference is a date picker, but they need JavaScript and designing and are sometimes fiddly and annoying to use (ever seen one with no year select that defaults to today's date? Yes, I'd love to click backwards from the current year to find the one I was born, that sounds like great fun). The nice thing about a date picker is that the format of the date is handled by the system and not the user, so the British and the Americans don't end up arguing about what date 1/12/2001 is.

In the case of our form, the wireframes called for three separate text boxes, for day, month and year, using a format of DD MM YYYY, no date picker. That sounds simple, but the design also called for an automatic tabbing feature between these fields once one had been completed. I've seen this done on other forms before with some success but only for fields where the input is a known length, such as bank account sort code. In that situation it's quite logical to type two digits then find the focus has automatically shifted to the next box. For DoB I was less convinced, because the input is not of a fixed length e.g. '1' could represent January or the first number of October, November or December, so we can't enforce an auto tab until at least 2 digits have been entered, meaning that some users will not experience this functionality at all.

Also is it reasonable to have auto tabbing for the DoB field but no other fields? Isn't that inconsistent behaviour? I'm undecided, but one thing I do know is that the JavaScript for this is a little more complex than it at first appears, particularly allowing for users wanting to SHIFT TAB back a field to correct an entry. Here's a solution in case anyone's interested.

if($('.multitext').length > 0){
    var inputs = $('.multitext').find('input');
    var executeAutoFocus = 1;
            executeAutoFocus = 0;
            executeAutoFocus = 1;

        if(executeAutoFocus){ //auto tab to next field once complete
            if($(this).val().length > 1){
                //when in the last element this will not work, intentional
        //if user tabs into field and deletes the text, 
        //we need to re-enable the autofocus functionality
        if($(this).val().length == 0){
            executeAutoFocus = 1;

As a final thought I'd like to touch on address fields, this time from the perspective of a user rather than a FE developer. Our form used a country select and a postcode box, which once complete would give the user a choice of addresses to select. As someone who's lived in some fairly unusual addresses (including one place where when I tried to get a phone working the phone company first connected in someone else's line and then had to send an engineer round to find what line I actually had) I've found these frustrating in the past unless there's a manual option. Even then it can be a bit of a dark art to get the right address entered (pay attention at the back, DVLA). My preference? Manual fields or an address finder. Put them both on the screen, side by side, no priority for which one should be used, let the user decide.

Ramble over. It'll be interesting to look back on this in a year's time to see if I have any different opinions. In the meantime, remember: if you find a bad form on a website, let the owner know.


This article is tagged with