Entering imperial length measurements on a web form.

Question

I live in Australia and have not dealt much with imperial length measurements.

How would you go about getting users to enter imperial length measurements on a web form, with a precision of 1/64th of an inch? I have thought of several ways to do it, but I don't know if there is a standard way of doing it, that users in the building industry in the USA would be used to.

Option 1 One big text box that users would then type in 5'11" 63/64 (5 feet, 11.984375 inches), which I would then parse, and store in a DB in millimeters.

Option 2 One text box for feet, one text box for inches, and one drop down box with [1/64,1/32,...,63/64] for the fraction part of inches, which would then be stored in the DB as millimeters.

Option 3 Something else...

Answer 1

I'd go for option 2 for the following reasons.

• it simplifies your coding (and this is a big one for me, being intrinsically lazy).
• it gives you greater control over what is entered.
• it makes it clear to the user what they're allowed to enter.

How you store it in the database is a matter for you to decide. Millimeters can't describe 64^ths of an inch perfectly (at least as an integer), but that may not be an issue for you.

My own thoughts are that you should store things as accurately as you ask the user to enter and if, as you say, you really need accuracy to 1/64^th of an inch, losing that accuracy when you put them in the database is not going to be good when you have to explain it to your users.

You could do one of:

• store them as 64^ths of an inch (so that 5'11" 63/64 becomes 5x12x64 + 11x64 + 63, or 1007).
• store them as a float (mm or inches, up to you) but convert them back to imperial when displaying them.
• store them as three separate integer fields, feet, inches and 64^ths of an inch.

My own preference there would be the first one. It results in a simple integer field which can be indexed far better than separate fields, there is no loss of accuracy and, provided you convert all application measurements to 64^ths of an inch before comparing them with (and inserting them in, of course) the database, you should have no problems.

This conversion is a simple process (unlike the metric-imperial ones).

Answer 2

I don't know if this qualifies as an "answer", but if I were to do it, I would try to get by with just offering a single field in feet or inches, depending on the expected range.

But that might not be good enough, in which case one field for feet and another for inches should be sufficient. If someone needs to get precise, they can type in the decimals in the inches.

Answer 3

I would go for a text box for feet, and a text box for inches. Allow the user to put fractional inches separated by a space. Be sure to provide an example of usage near the input area. For example:

[5___] feet, [11 3/4_] inches
Example: [6] feet, [1 1/4] inches

This seems like a good compromise between natural input and parseability, so you don't have to worry about all the possible methods that people use to delineate feet and inches (ft, ', f, -, etc.), but people can still easily enter whatever unit they please.

Answer 4

I'm upvoting Paul Fisher's answer but I would like to offer my own anyway, partly because I feel I have more than 600 characters' worth of commentary to add. ;)

I like that his answer seemed to put at least as much emphasis on making things easy for the user as it did on making things easy for the programmer. I believe we should put the users first to the greatest extent that we can. Ideally, you'd make a mock-up of various solutions and ask actual building industry users (who deal with imperial units) to try them out and give you feedback, but for now you're asking us, not actual users, so...

I am also leaning toward the two-field UI. Personally, I would make the parser handle both decimal and fractional input (allowing either '11.25' or '11 1/4'). You'll have to figure out what to do when they pick something that's not a binary fraction, like 5/7 (when they probably meant 5/8, for example).

As for storage, I guess you could go with millimeters, as long as it's a float. I'd be more comfortable storing inches, because if your values are all multiples of 64ths of an inch, you shouldn't have rounding issues. I agree with Pax that it's important to be able to give it back to the user in imperial units, complete with reduced fractions. (Maybe it's a big assumption I'm making about the building industry. For all I know, they normalize everything to 64ths, and are happier to see '11 16/64' than '11 1/4'!)