What's the best and most intuitive way to have a user enter a height value in feet and inches into a web form?

Question

What's the best and most intuitive way to have a user enter a height value in feet and inches into a web form? The major choices seem to be:

1. Have one text field where they can enter values. This becomes a moderately complex parsing problem if more than one or two formats are allowed, but it's doable.
2. Have two text fields, one for feet and one for inches.
3. Have two dropdowns, one for feet and one for inches. This disallows fractional inch values, though, unless there are lots of options in the inches dropdown.

I suppose this question also concerns entering any data item that is often seen as multi-part (phone numbers).

Answer 1

How about two radio buttons (created with jQuery Aristo UI):

Update: Given that height is actually a continuous line I think the following is an improvement and takes on board the comments below that it should be from 0-11 and that you would say 6' not 6' 0":

I've created a jsFiddle for this using the jQuery UI Slider.

Answer 2

Ultimately, the User portion of UX will depend on your users.

The best approach will change based on conditions like:

• What deployment targets you're looking to support / optimize (touch vs keyboard)
• If users are doing data-entry from a pre-existing form that has a certain look/feel
• What cultural background / units are common / supported
• The range of values you're looking to collect (babies vs full-grown adults)

Option 1 - Free Text / Parser

This is essentially a micro-grammar, which has advantages and disadvantages. It's somewhat uncommon so there's some inherent discoverability problems, but if you have repeated users, it can offer a powerful way to enter data into a single field without the interaction cost of changing fields/contexts. To aid in discoverability, you can use placeholder text to suggest the correct format for data.

By far, this will also require the most development work to implement compared to other options, but is still relatively feasible based on how many languages / cultures you need to support

Option 2/3 - Collect information in pieces

Collecting information separately is certainly the easiest to code in almost any case, so you might want to optimize your dev cycle for some rarely used features. Then it's up to you how you want to collect numeric values (using a stepper, dropdown, radio button, or button group as some examples). Each input metaphor has advantages / disadvantages over different demographics / deployment targets.

Option 4 - Slider - If you're collecting height across a small range of values (for small children for instance), you could use a slider, but note that as the number of values increase, the precision required to correctly select a value from a slider becomes increasingly hard, especially on mobile. If precision is important (as it typically is for height/weight) then I would likely avoid this option.

---

Examples

Just as a thought experiment, here are several different mockups.

• Which would you prefer to use yourself?
• Which do you find easiest to read?
• Which would take the least time to enter (keyboard / phone)?
• If you can, borrow 5 end users of the product and ask them too.

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 3

Option one is good if validation is possible. The only problem is that faced with a blank text field, users aren't sure how to format their data - they assume the machine only handles a finite range of formats, and they have to guess which. Not a good user experience.

The usual workaround is to suggest a potential value. Some are doing this with default text in the textbox, sometimes greyed out for best effect.

Another good idea is to parse the data the moment the field loses focus, replacing the user's text with your application's "interpretation" of what they mean. For instance, after entering the text "3.6", your app substitutes the text "3 feet 6 inches". That way, the user can be confident that there's no formatting issues. They can also spot any actual formatting issues earlier (the later the user is told of an error, the harder it is for them to remember the context and their decision, and so the greater the cognitive workload).

Answer 4

Make things easy

People know how to record height:
In Imperial units it's always feet and inches.

Two separate units, two separate fields.
Easy for them to enter.
Easy for you to parse.

Making things hard

Radio buttons, sliders, menus, etc just make users think about your controls.

You're also presenting them with a whole bunch of irrelevant numbers to scan through.

Let me see ... 0, 1, 2, 3, 4 ... 5 ... that's the one I want.
Okay, now 0, 1, 2, 3, 4, 5, 6, 7 ... 8!
Man, am I glad that's over.

😥

As the saying goes, don't make your users think.

Answer 5

Option 2 is the easiest, they are just entering a maximum of two values in each window. Option 1 would be confusing and difficult to parse and option 3 would take longer to hover / scroll to the proper option.

Answer 6

I have approached this by taking the difficult initial parsing option (with lots of unit tests) in order for users to type in whatever format they want - but I had a very big range to cater for including negatives.

If the range is not too great the drop downs to the nearest inch might serve better as it stops the user from having to think about format to enter the freeform text eg with spaces hyphens fractions etc.

Answer 7

i faced the same situation and i ended-up using php-generated dropdown... here's my solution:

<select name="height" id="height">
   <?php
        for($foot=3;$foot<=7;$foot++){
            for($inches=0;$inches<=11;$inches++){
                if($inches==0){
                   echo "<option value='$foot feet'> $foot feet </option>"; 
                 }else{
                    echo "<option value='$foot feet $inches inches'> $foot feet $inches inches </option>";
                 }
            }
        }
   ?>
</select>