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

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).

• About entering multipart numbers: ux.stackexchange.com/questions/7100/…
– Inca
Commented Aug 20, 2011 at 8:50
• What about a single drop-down box, each row containing a height value: 5'0", 5'1", 5'2", etc.? I feel like I've seen that more frequently than #3. Commented Aug 23, 2011 at 21:08
• Implementation note: html does have support for a "range" input type, which does neat things like adding up/down buttons, allowing text input, and supporting restrictions on min/max values. On older browsers, it is treated as a text box. Commented Jul 9, 2013 at 17:07
• What if you'd like to, at some point in time, target users from parts of the world that use metric system? Commented Dec 12, 2014 at 13:36
• I've been giving this question (and concept) some thought for a few weeks now. I am working on a size input where the values are inches and fractions of inches with an (initial) range of 5" to 60". I like @icc97 answer, but that simply takes up too much space. Commented Feb 25, 2015 at 18:01

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.

• +1 neat idea. While it takes up more space than a drop down, it's quite clear to use. Commented Aug 21, 2011 at 19:44
• Perhaps with 0-11 inches instead of 1-12? Commented Jul 8, 2013 at 15:53
• @Mr.Jefferson I wonder if the zero is needed? How many people refer to themselves as 6ft 0"? So including it potentially conflicts with the user's mental model. On the other hand not to having may be confusing. User testing would be interesting. Thoughts? Commented Jul 9, 2013 at 0:06
• The revision is a great answer. If the expected input can be bound to a range then that makes the UI even easier to constrain. Huge ranges can still use this UI metaphor by using logarithmic scrolling, which is detailed here Commented Jul 9, 2013 at 13:48
• Love the idea, but may I suggest a touch of colour to seperate the 4-inch area from the 5-inch area? Think of us poor European continentals, who always tend to divde by 10 instead of 12. Commented Sep 14, 2014 at 6:19

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.

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).

# 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

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.

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.

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.

• +1 for focusing on the mental load on the user. I feel the "in what format do I enter my data?" obstacle is too great. The fact that code can parse the input doesn't stop the user from thinking about it. Free entry requires a lot of user thought that shouldn't occur when answering the target question of "how tall am I?". Commented Jul 9, 2013 at 1:13

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>
``````
• Hi Mhk. Unfortunately this is a UX site not a coding / dev site, so the audience of this site are also primarily not developers. Posting answers that are almost entirely code isn't really suited to such a site because we shouldn't expect such answers to be understood by this sites users. UX is concerned with what to do; for the how to implement it people would go elsewhere. Can you describe what this code actually generates, how it displays and how users interact with it? That's more how the answers on this site are structured.
– JonW
Commented Jul 8, 2013 at 9:46
• @JonW GOT it... (first time user :-( )
– mhk
Commented Jul 8, 2013 at 9:54
• for less code and hassle and more controlled approch use the basic HTML dropdown. the options/content of dropdown are to be generated by javascript or any service side language, like above code is php. it generates drop down from 3 feet to 8 feet with increment of 1 inch in between. The interfaces with radio-buttons or buttons separately for feet and inches and along covering friction of values between them is quite tedious task... yes my vote is for controlled dropdown...
– mhk
Commented Jul 8, 2013 at 10:07