Why do HTML forms have to be death by a thousand tiny textboxes?
The classic example of this is phone number, which typically forces you to tab through three annoying little textboxes to enter a single number:
They want to collect metrics based on the address information for the separate fields. Although it’s possible to parse the values programatically, it is never going to be consistant 100% of the time with a free form text field.
is never going to be consistant 100% of the time with a free form text field.
It’s never going to be consistent 100% of the time with human beings entering data, period.
And Google is clearly able to parse an address entered in a single line. G’wan. Type an address in the Google search box like you would on a mailing label. This is even HARDER to parse because it lacks carriage returns!
“Everyone has filled out an address label before. It’s completely and utterly intuitive, even if you live in another country.”
Hmm, not really. At least in Czech Republic (and I’m quite sure that German address conventions are similar) the address is entered slightly different:
Alan Smithee
Peach Pit Lane 431
Hollywood
90210
USA
I strongly support optimizing for users, but it could be quite difficult when your audience is global or when you don’t know who will use the app.
What about classical example with date formats? Consider entering date - is it DD/MM/YYYY or MM/DD/YYYY? 23/2/2006 is easy. But what about 2/3/2006?
I’ve saw quite a lot wanna-be-smart datetime controls trying to guess … and fail… :-/
Hear hear! I hate all the fields, particularly address fields. Devs need to try harder to let people enter data in a way they find natural. Maybe I have the address on my clipboard for some reason. Please please please let me use my clipboard!
It was one of the things that drove me bonkers about Mapquest, I’d find an address listing online and copy it to the clipboard, but Mapquest wouldn’t have it. I’d have to type or paste each individual address component in its own field. Uggghhh, at least try Mapquest!
Martin and Space, you are both guilty of making you’re own lives easier at the expense of the user. You say, we can’t parse it 100% of the time, so just give up.
There are ways around this, for one you can give them a big old text area, and then parse it out and show the user how you interpreted it, with all the parts(street, zip, etc) dropped into fields and labeled. Then, if you completely screwed the pooch parsing it, the user can still enter it in manually the slower, multiple field way.
I think it depends on how the address is going to be used. If it’s mainly as a shipping address, how it is entered, stored, and retrieved doesn’t matter a whole lot. If it’s used as a data source (e.g. showing sales data in a given region, or possible study participants in a given state/city). Then you need to take a little more care in how the data is entered and especially stored.
I used to live and work in Albuquerque, NM. We had to enter a lot of address data for people. Guess how many different spellings of Albuquerque we had? Our solution? tah-dah. Autocomplete text boxes. Creating an autocomplete text area is a little more difficult. But if you’re running a query that says “select * from People where city = ‘Albuquerque’” it sure helps everyone if you help the user enter as much as you can.
Well if the address is a real address, it is possible to parse with as pretty much the same accuracy as separate text fields, but it requires getting postal data from the USPS.
I once worked on code that parsed free-form address fields and it relied on USPS data.
For addresses alot of the time you only need housenumber and postcode. That’s all you strictly need if your mailing something localy. However, this isn’t really practicle for global shipping etc.
Another problem that my girlfriend was telling me about. One of her friends has legally changed their name so that it is now just one name. No forename or surname, just the one. How are they meant to fill out the “Firstname Lastname” forms? Though that problem extends further to the fact they can’t get stuff like insurance, because they simple won’t accept that they don’t have at least two names.
it could be quite difficult when your audience is global or when you don’t know who will use the app
How so? You’re filling out a shipping label. We’ll print it out EXACTLY as you fill it out, and that’s where we ship what you ordered. What do we really need to parse?
Probably just enough to calculate shipping costs.
That said, parsing all the world’s shipping formats is definitely more daunting than just the US.
Maybe I have the address on my clipboard for some reason
Oh man, I mean to keep blogging about this, but forgetting. Beyond Compare checks the clipboard for your registration info and AUTOMATICALLY ENTERS IT FOR YOU when you enter the dialog.
Swoon. I’m in love all over again.
For the record, clipboard integration and the web browser is a different story. IE has some basic clipboard support, but I don’t think Firefox/Mozilla allows any access whatsoever.
while I agree on the phone edit box, I don’t know about the contact information, I work on a field where I see a lot of user entered contact information and I can tell you that
of course in the specific case of the USPS, they have all the data they need to recognize any US address, even tell you if such address exists
Replacing address fields with freeform text areas is a bad idea because it prevents autocomplete functions from working.
What you should do is use single-line input boxes with sensible name attributes (like “name”, “email”, “street”, “city” etc.). If a form is properly designed this way, the client’s browser ought to be able to help filling it in.
If the user enters a zip code, then the state and city are already known. All that is left is the actual street address.
There are very few sites that use this method. Why?
I beg to differ Jeff, data normalization and data cleaning are very important processes of any Marketing, Analisys or classification of a database.
If you give a “textbox” only, your’re opening your database too much and the users can (and will) enter inconsistent data.
The more, the merrier. There are webtechnologies that can help a user complete a form without much hassle. I agree that the phone should be a string and period, but the address?
Try to later perform a data segmentation, mining and classification on a huge filled with crap textbox.
Nonsense. I worked with very large databases (companies like Kellogs for example) that pay zzziilllions of dollars to clean their db. It’s a hard job. Believe me.
My two cents.
John: even “zip codes” are more complicated than you think. So your software can handle “90210”; that’s lovely. What about SL6 7AA, 2042 or K1A0B1? And even if you decide to limit yourself to the former British colonies that have lately begun styling themselves “the United States”, there will still be problems. I know, for example, that there’s not a strict 1:1 mapping of postcode to state in Australia; there are about a dozen postcodes that straddle state lines, usually on some of the smaller sheep stations that are about three times the size of your average US state. There’s likely a similar problem around the edge cases and extremes in the US zip code system.
Edge cases make programming hard.
Edge cases make programming hard.
No, programmers make edge cases hard by focusing on them instead of the other 99%.
FWIW, Google maps does a good job in parsing a one-line textbox and extracting enough information from it to be able to find you on a map. (Although sometimes it has to ask you to disambiguate.)
Jeff, I think you might be overstating the case for how inconvenienced users are by separate boxes for discrete info. Is it REALLY so horrible to have to enter a separate first name and last name? I can assure you that I can throw a volume of Knuth down the hall here and hit someone whose name is exotic enough that I don’t know whether they’re giving me the family name or given name first. So why don’t I let them tell me instead of me having to guess?
Besides, we’ve already raised a generation or three of people who know the drill, heh. We’re just following the lead of those trendsetters, namely government bureaucrats.
I’m with you on phone numbers and postal codes, maybe even city/state/zip (maybe), because if those need to be parsed, the variants are reasonably finite. But street info … man. I deal with lists of only a few hundred names, and even then it’s unbelievable how many ways users can come up with to enter information wrong. 
John: zipcodes can span more than one city, mine for instance. Occasionally I get mail addressed to the adjacent town. My SO likes it, since the other town is much nicer than ours 
I’ve almost forgotten about this problem. The Auto-Fill feature on my Google toolbar makes quick work of the very forms you are talking about. In fact its almost fun to see a form covered with tiny, text boxes because I know I can fill them in with one click.
Users are idiots. If we don’t hold their hands, the second they get in front of a computer they forget how to do the most basic of tasks they normally take for granted.
Frankly, I am surprised that choking on your own tounge isn’t lead cause of death amoung computer users.
Give them a box maked phone number and you can EASILY expect to get a poem instead. Not expecting extension numbers? Why give them the change to enter it.
Need a address? Gotta use it for 2 different forms such as shipping label and a commercial invoice? Forget free form entry. Again, the data will be hopelessly and endlessly manged beyond all hope of being useful.
We ask for data in an organized fashion because it narrows a user’s expectations of what to provide, giving US a better change of not only getting the right information but also being able to use it too.
Take, for example, you idea of a postal code, or state/province. How do you know where one ends and the next begins for say, croatia, jamaica, norway, france, fiji?? You don’t.
You think that just because most americans fill out an address a certain way that the whole world does it? Forget it.
Your way doesn’t allow for ANY type of data validation whatsoever and easily promotes the exact type of data manipulation that fraud artists THRIVE on.
Worse, users would generically have no clue what to do. The fact that it is a 100% parallel to something do without the computer not withstanding.