Why Users Fill Out Forms Faster with Unified Text Fields(uxmovement.com)
uxmovement.com
Why Users Fill Out Forms Faster with Unified Text Fields
http://uxmovement.com/forms/why-users-fill-out-forms-faster-with-unified-text-fields/
12 comments
1. Why do you need to extract forename+surname? The assumption that your users will even have a forename and a surname is invalid.
[http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...]
2. There are exactly 50 states, so 50 names and 50 abbreviations. You are expecting the data in "City, State" format, so you parse the form in Javascript when the user finishes typing. If the data after the comma matches one of 100 strings, turn the form green, otherwise turn the box red.
3. Put the expected representation in the label. Parse the form as the user is typing, and replace the date with your interpretation when the box loses focus ("01/23/12" => "January 23, 2012") Turn the box red if the month is > 12 or the day > 31.
If the user has Javascript disabled, display a verification screen after the form is submitted.
[http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...]
2. There are exactly 50 states, so 50 names and 50 abbreviations. You are expecting the data in "City, State" format, so you parse the form in Javascript when the user finishes typing. If the data after the comma matches one of 100 strings, turn the form green, otherwise turn the box red.
3. Put the expected representation in the label. Parse the form as the user is typing, and replace the date with your interpretation when the box loses focus ("01/23/12" => "January 23, 2012") Turn the box red if the month is > 12 or the day > 31.
If the user has Javascript disabled, display a verification screen after the form is submitted.
"You are expecting the data in "City, State" format"
This is a bad assumption. What you should do is throw away commas, split along whitespace, and then see if the last element split is a valid state or territory.
Because some lazy guy will type "new orleans la" and just ruin your day.
This is a bad assumption. What you should do is throw away commas, split along whitespace, and then see if the last element split is a valid state or territory.
Because some lazy guy will type "new orleans la" and just ruin your day.
And then some non-lazy guy types in Albuquerque New Mexico and you find that Mexico is not a US State.
I know, this isn't a particularly difficult thing to work around, but I was amused that you replaced one bad assumption with another.
I know, this isn't a particularly difficult thing to work around, but I was amused that you replaced one bad assumption with another.
Oh well, getting closer. ;)
We could always start taking from the back and doing look ups until we have a match or we finish the string.
We could always start taking from the back and doing look ups until we have a match or we finish the string.
Dallas, TX, 75254.
Is "." a state? How about "75254"?
Is "." a state? How about "75254"?
Why even bother with the state? Just get the postal code.
Hell, just let the user write in the postal code and use their IP address to match it with the country of residence. They can put any number in there and you can match it to some location. No states. No assumptions. Well, beyond the one about IP address being accurate, I guess.
Hell, just let the user write in the postal code and use their IP address to match it with the country of residence. They can put any number in there and you can match it to some location. No states. No assumptions. Well, beyond the one about IP address being accurate, I guess.
> 2. There are exactly 50 states, so 50 names and 50 abbreviations.
Quick, spell the state that starts with "M" and ends in "ets"! How about "M"-"pi"? "T"-"see"?
I know, it's almost trivial to guess at misspellings. But that's just another piece of code you have to write.
Quick, spell the state that starts with "M" and ends in "ets"! How about "M"-"pi"? "T"-"see"?
I know, it's almost trivial to guess at misspellings. But that's just another piece of code you have to write.
Not if you know what to look for. I came across code that implements the metaphone algorithm (http://en.wikipedia.org/wiki/Metaphone) and used it for a sample project I started, but never finished, years ago (http://boston.conman.org/cgi-bin/location/location.cgi). It could be modified to allow free form text, instead of the text field for the city, pull-down for the state, but that's an implementation detail.
But the point is---code to check for misspellings already exists.
But the point is---code to check for misspellings already exists.
"2. There are exactly 50 states, so 50 names and 50 abbreviations."
Considering the Internets is a really really big place (not just America), that statement is rather quite false.
Considering the Internets is a really really big place (not just America), that statement is rather quite false.
Strange to, on one level, make the valid and useful observation that forename + surname is a cultural assumption, then go right ahead and make the cultural assumption that the form should only accept US addresses (and even then ignoring DC, PR, Guam, and forces serving overseas...). Even with your scheme, you'd better hope nobody types in Beverly Hills, LA. And you'll need a spellchecker to help out people who can't spell Missississississippi.
It's not necessarily a "cultural assumption" -- many companies only do business in the US. However, people of any ethnicity may reside here. Seems consistent to me.
I agree that splitting the city state is probably more complicated than it's worth though.
I agree that splitting the city state is probably more complicated than it's worth though.
It seems like a reasonable assumption for a user to know the two-letter abbreviation of the state they live in.
If you suggest otherwise, how do we know that they can spell their street correctly?
If you suggest otherwise, how do we know that they can spell their street correctly?
The question here though is not whether people can spell things correctly or correctly identify what state they live in, as whether you can write a computer program to, given what someone claims is their address, reliably break it down into parts to, for instance, extract what state they live in.
If you give someone separate fields for 'city' and 'state' you have some chance of figuring out where they are located if they type 'Washington' into one of those fields. If you ask them just for 'city, state', some people will understand that as 'city or state' and just type 'Washington', and you have no idea what they mean. The example I gave before, LA, is an example of a city which shares its name with a state abbreviation.
An anecdote for you: I was once working with UK callcentre system which had a form for callcentre staff to update customer contact addresses. UK postcodes are combinations of letters and numbers, and certain letters are excluded from certain positions to prevent ambiguous handwritten letterforms causing confusion. I naively implemented strict postcode validation, thinking it would help catch data entry errors. What actually happened was that we ended up, in a significant number of cases, telling people that the postcode that they had been using as part of their address for decades was not, in fact their postcode - it couldn't be because it was an invalid postcode. This made the customers quite cross, and we had to change it.
Do you want your validation message to be the one to break it to some eighty year old guy that Nebraska is actually NE, not NB any more?
If you give someone separate fields for 'city' and 'state' you have some chance of figuring out where they are located if they type 'Washington' into one of those fields. If you ask them just for 'city, state', some people will understand that as 'city or state' and just type 'Washington', and you have no idea what they mean. The example I gave before, LA, is an example of a city which shares its name with a state abbreviation.
An anecdote for you: I was once working with UK callcentre system which had a form for callcentre staff to update customer contact addresses. UK postcodes are combinations of letters and numbers, and certain letters are excluded from certain positions to prevent ambiguous handwritten letterforms causing confusion. I naively implemented strict postcode validation, thinking it would help catch data entry errors. What actually happened was that we ended up, in a significant number of cases, telling people that the postcode that they had been using as part of their address for decades was not, in fact their postcode - it couldn't be because it was an invalid postcode. This made the customers quite cross, and we had to change it.
Do you want your validation message to be the one to break it to some eighty year old guy that Nebraska is actually NE, not NB any more?
But is it a reasonable assumption that they'll enter the abbreviation, instead of the state name?
There are actually 8 more non-states (like MP, AS, PR), and 6 for overseas military. Just to cover the US.
Often, you have to have a first name and last name due to various business / legal constraints. There is no way around it, even though, as you've correctly said, not everyone has a first name and a last name. Unfortunately lawmakers are often not culturally sensitive enough to understand that.
What is an example of such a legal constraint? (The only name-related legal compliance issues I can come with off the top of my head demand "full name".)
1. You just can't do it reliably, because there are people (entire nations/cultures) who don't even have names fitting first/last model.
It's a can of worms, very well explained here: http://www.w3.org/International/questions/qa-personal-names
and here's an interesting edge case: http://www.chaos.org.uk/~wookey/name.html
3. <input type=date> will use localized format for editing (browsers are free to use any format/calendar widget), but always send YYYY-MM-DD to the server.
It's a can of worms, very well explained here: http://www.w3.org/International/questions/qa-personal-names
and here's an interesting edge case: http://www.chaos.org.uk/~wookey/name.html
3. <input type=date> will use localized format for editing (browsers are free to use any format/calendar widget), but always send YYYY-MM-DD to the server.
Wookey's site moved to wookware.org, the new version of the name page has another paragraph. http://wookware.org/name.html
Is it really that had to fill in "Mr" or whatever in the other name box?
[deleted]
and the geeks will enter yy/mm/dd
More precisely, I think many geeks will enter YYYY-MM-DD — http://www.cl.cam.ac.uk/~mgk25/iso-time.html — having lived on two continents, I use this format whenever I can.
More precisely, I think many geeks will enter YYYY-MM-DD — http://www.cl.cam.ac.uk/~mgk25/iso-time.html — having lived on two continents, I use this format whenever I can.
Same here. I started using YYYY-MM-DD for my own use as soon as I learned of it, long before I was on the internet. Among other things even the simplest sort programs will get dates in the right order.
Being an old VMS fan, I always liked DD-MMM-YYYY (e.g. 29-Jul-2011). At least it eliminates the month day ambiguity which sometimes confuses me.
But then you lose most of the advantages mentioned in the linked summary.
Readability increases but sortability decreases with ddmmyy as opposed to yymmdd.
Readability increases. Dates we use in day-to-day work are probably power-law distributed going backwards with more recent dates being more common. That means if most of the dates will have year 2011, we can guess that, and the day and month become more important. And if most of the months will be current or previous month, we can guess that too and day emerges as the most important piece of info- we will want to read that first. The yymmdd is less readable because it gives us information we (probably, given the power-law distribution mentioned above) already know first, such as the year.
But you lose sortability, yeah.
Readability increases. Dates we use in day-to-day work are probably power-law distributed going backwards with more recent dates being more common. That means if most of the dates will have year 2011, we can guess that, and the day and month become more important. And if most of the months will be current or previous month, we can guess that too and day emerges as the most important piece of info- we will want to read that first. The yymmdd is less readable because it gives us information we (probably, given the power-law distribution mentioned above) already know first, such as the year.
But you lose sortability, yeah.
> 1. How do you reliably extract forename+surname from a single name field
You don't. It's their name, it is not broken. Instead, the "first name, last name" format is broken: what happens if that person has more than two names? If they're culturally written last, first instead? If their first or last name should never be used on its own? Or if only one of them should be used?
You ask for their name, and you use what they give you. Period, end of the story. You have no business fucking up somebody's name.
> 2. Same for the City/State field
That one's even easier: freeform address. Not everybody has a state, not everybody needs a city field, and not every address can fit in so simple a format. Ever seen a japanese address? There are 5 or 6 levels in the geographical hierarchy (country, prefecture — including prefecture type, municipality, optionally ward (depends on municipality size), district, block and house number) and it's written from the largest to the smallest element of the hierarchy (so prefecture to house number). With the business or person name at the end.
You may also note that japan does not generally use street-based addresses, though some local systems do (no, japan does not use a single unified postal addressing system either)
You don't. It's their name, it is not broken. Instead, the "first name, last name" format is broken: what happens if that person has more than two names? If they're culturally written last, first instead? If their first or last name should never be used on its own? Or if only one of them should be used?
You ask for their name, and you use what they give you. Period, end of the story. You have no business fucking up somebody's name.
> 2. Same for the City/State field
That one's even easier: freeform address. Not everybody has a state, not everybody needs a city field, and not every address can fit in so simple a format. Ever seen a japanese address? There are 5 or 6 levels in the geographical hierarchy (country, prefecture — including prefecture type, municipality, optionally ward (depends on municipality size), district, block and house number) and it's written from the largest to the smallest element of the hierarchy (so prefecture to house number). With the business or person name at the end.
You may also note that japan does not generally use street-based addresses, though some local systems do (no, japan does not use a single unified postal addressing system either)
1. How do you reliably extract forename+surname from a single name field
You don't. You should never tell someone that their name is invalid. it's their name
You don't. You should never tell someone that their name is invalid. it's their name
This is true in most cases but not all. I deal with data going onto government forms, see lots of work visas etc. The U.S. government is more than happy to tell you that your name is invalid, or data enter garbage into their databases to make the name conform to the standard. Then we have to enforce the same standards on our users even if it doesn't make sense because we have to exactly match what the governments records contain.
Can you provide an example of such a document from the US government that requires a split apart first/last name? I am not saying you are wrong: I am simply deeply curious (as the ones I have dealt with ask for "full name").
The Form I-9 is one example: http://www.uscis.gov/files/form/i-9.pdf
The Form W-4 is another. http://www.irs.gov/pub/irs-pdf/fw4p.pdf
For employers enrolled in the E-Verify program having incorrect name data on the Form I-9 can start a process where an employee is flagged as possibly not being eligible to work in the US.
For employers enrolled in the E-Verify program having incorrect name data on the Form I-9 can start a process where an employee is flagged as possibly not being eligible to work in the US.
So, the pattern that I found in all of the documents I dealt with, is that if you are filling in /your/ name, it might ask you to break it apart, but if you are filling in /someone else's/ name, it asks for "full name". As you are not supposed to be filling in the name field on an I-9 or a W-4 for your employees, so you should not end up in a situation where your internal wbaite (or whatever) that asked for "full name" screws you. However, note that the "new name" field on the I-9, which is an area of the document you fill out, is not broken apart by first/last.
I think the pattern is that if the name is relevant data to what the form is used for it's broken out, possibly to aid with data entry. When the name is attached to a signature then it's just so that there's a legible version.
With the I-9 specifically section one is done by the employee, section two and three are done by the employer. All of the data in the form pertains to the employees work eligibility and there are rules about what the name in section one says when compared to the documents that are presented for section two or three. So the name in section one is data. The name in section two doesn't really matter as it's just a witness, the company is ultimately responsible for errors in the form, unless there's a criminal issue (document abuse, fraud, perjury, etc). So as with pretty much every form they ask for the printed name since there's a good chance the signature will be illegible. The new name in section three also isn't really important as it's rarely used. You only update the I-9 form and fill in section three on a name change if the persons work eligibility documents need to be updated. Since it's a small percentage of the cases that section three will be used for the government doesn't care too much. What's more interesting to me is they don't even ask for the print name of the person signing section three.
With the I-9 specifically section one is done by the employee, section two and three are done by the employer. All of the data in the form pertains to the employees work eligibility and there are rules about what the name in section one says when compared to the documents that are presented for section two or three. So the name in section one is data. The name in section two doesn't really matter as it's just a witness, the company is ultimately responsible for errors in the form, unless there's a criminal issue (document abuse, fraud, perjury, etc). So as with pretty much every form they ask for the printed name since there's a good chance the signature will be illegible. The new name in section three also isn't really important as it's rarely used. You only update the I-9 form and fill in section three on a name change if the persons work eligibility documents need to be updated. Since it's a small percentage of the cases that section three will be used for the government doesn't care too much. What's more interesting to me is they don't even ask for the print name of the person signing section three.
Given that Section One of I-9 is done by the employee, I fail to see how this form (or the W-4) is a case that would force you to enforce any "standards on [y]our users [...] because [you] have to exactly match what the government records contain". It still seems like, when asking for other peoples' names, you can still go with "full name" and not run into any problems when filling out government forms related to that user.
Where you do run into problems is with people that have one name, or more than three names. Splitting those up wrong or putting them into the wrong fields can constitue a technical error on the forms, with the I-9 that means accruing civil liability. Also with the I-9 form, if the employer is in the E-Verify program you are increasing the odds that an employee will fail to pass verification. The documentation for employers on how to complete the Form I-9 is 65 pages. That doesn't include the full regulations that are in the federal register, guidance issued by USCIS, or the extra rules that are part of E-Verify.
I really hate to be bothersome, and I really am finding this interesting, and please do feel free to ignore my responses, but I will ask: isn't that part of the form filled in by the employee? How can you make a mistake filling it out, if you are not the one filling it out at all? The parts of the form you (the employer) are involved with only has blanks for "full name".
Just cause someone else does it doesn't mean that you should do it. If you need to match against another data provider, e.g. government database, then you should tell you users that. Tell them that you can't continue unless they "enter their name the same as it's in their passport". I assume you users are interested in your service, so they will want to enter the correct information.
> Just cause someone else does it doesn't mean that you should do it.
The same is true for the advice in this article. Our testing, combined with legal requirements, has shown that we get the best results when fields are split apart and match the paper version of the form we are digitizing exactly.
> If you need to match against another data provider, e.g. government database, then you should tell you users that. Tell them that you can't continue unless they "enter their name the same as it's in their passport".
We can't ask the user to "enter their name the same as it's in their passport" for a number of reasons including: we don't know what type of identity documents they have, foreign identity documents may contain name information in a different format than stored by the US government, it could be considered discriminatory.
The data is submitted to the government long after the users involvement with the process is complete. There's no way to have it checked in real time or while the user is still present. The government provides no useful feedback about what information collected was incorrect. We are simply directed to have the user contact one of several government agencies. Getting it right the first time is extremely important, trying to combine fields and break them out on the back end can lead to negative consequences for our users and liability for our clients if done improperly.
> I assume you users are interested in your service, so they will want to enter the correct information.
The users don't have much of a choice and when they were doing this process on paper they would routinely get it wrong. Making the electronic data collection process as error free as possible is much more important than a few seconds saved by unifying form fields. Especially if incorrectly processing those unified form fields may have negative consequences for the user as it can in our case.
The same is true for the advice in this article. Our testing, combined with legal requirements, has shown that we get the best results when fields are split apart and match the paper version of the form we are digitizing exactly.
> If you need to match against another data provider, e.g. government database, then you should tell you users that. Tell them that you can't continue unless they "enter their name the same as it's in their passport".
We can't ask the user to "enter their name the same as it's in their passport" for a number of reasons including: we don't know what type of identity documents they have, foreign identity documents may contain name information in a different format than stored by the US government, it could be considered discriminatory.
The data is submitted to the government long after the users involvement with the process is complete. There's no way to have it checked in real time or while the user is still present. The government provides no useful feedback about what information collected was incorrect. We are simply directed to have the user contact one of several government agencies. Getting it right the first time is extremely important, trying to combine fields and break them out on the back end can lead to negative consequences for our users and liability for our clients if done improperly.
> I assume you users are interested in your service, so they will want to enter the correct information.
The users don't have much of a choice and when they were doing this process on paper they would routinely get it wrong. Making the electronic data collection process as error free as possible is much more important than a few seconds saved by unifying form fields. Especially if incorrectly processing those unified form fields may have negative consequences for the user as it can in our case.
No answer for 2 or 3, but I have been thinking about 1 for awhile. My notion is to ask the user for a common name and a formal name.
So something like ...
Common name -> Joe
Formal name -> Joseph A. Smith
Common name would be used for interaction with the user, and formal for anything requiring it (e.g. legal, billing, shipping).
Just a thought and one that I have yet to try.
So something like ...
Common name -> Joe
Formal name -> Joseph A. Smith
Common name would be used for interaction with the user, and formal for anything requiring it (e.g. legal, billing, shipping).
Just a thought and one that I have yet to try.
I once saw a site that asked for full name and nickname. After I got over the shock of it being different, I quite liked it. It always knew what to call me, and never made assumptions.
Your point 1 is exactly the question I came here to see answered. The article actually claims "Another benefit to unified text fields is getting the user’s information in a format that you want without sacrificing ease of use or speed" - but I want to be able to use the forename only (so, for instance, I can address newsletters with Dear Jacob).
It's certainly not about validity / invalidity of names. And yes, that's not a perfect situation - some people may prefer Dear Mr Aldridge or Dear Jake (ugh). But as long as I recognise that shortcoming, and (which I do) only require a single name (so people with only one name are not ruled invalid), I don't see how a unified field gives me the format I want.
It's certainly not about validity / invalidity of names. And yes, that's not a perfect situation - some people may prefer Dear Mr Aldridge or Dear Jake (ugh). But as long as I recognise that shortcoming, and (which I do) only require a single name (so people with only one name are not ruled invalid), I don't see how a unified field gives me the format I want.
1. Good point.
2. Probably should have an autocomplete feature.
3. Sometimes I see forms specifically mention what format they want.
2. Probably should have an autocomplete feature.
3. Sometimes I see forms specifically mention what format they want.
For those who are interested, I wrote a post on the challenges of extracting forenames and surnames and shared some imperfect code that takes a stab at it:
http://www.onlineaspect.com/2009/08/17/splitting-names/
http://www.onlineaspect.com/2009/08/17/splitting-names/
[deleted]
Easy peasy. Use a good algorithm that is correct most of the time and present the results to the user in a way that's correctable.
Speaking as a decently computer-savvy person with a bit of attention problem - I often have to try to resubmit multiple times on non-unified text fields because I miss things, and then my password doesn't get saved. Then, rushing through it for the third time, my Captcha turns out to be wrong, etc. I've actually abandoned lots of forms I planned on filling out because of non-unification.
I for one like this post.
I for one like this post.
Do average users, let's say facebook's audience, use tab to navigate between fields? I always assumed tab usage was mostly reserved for the geekier keyboard/hotkey using crowd.
+1
Article says: "This is because users don’t have to tab as much."
Strongly disagree - 'average', non-technical users simply don't tab between fields. They mouse and click, mouse and click, etc.
I can't remember ever seeing a user in a field test (I do UI testing) use tab to traverse a form.
Article says: "This is because users don’t have to tab as much."
Strongly disagree - 'average', non-technical users simply don't tab between fields. They mouse and click, mouse and click, etc.
I can't remember ever seeing a user in a field test (I do UI testing) use tab to traverse a form.
Not sure if the article's been edited, but it now refers to the mouse using crowd (for whom this change is even more beneficial).
I think that too often form UX airs on the side of simplicity and that unified text fields are a pleasant counter to the bulk of forms. Re-checking this comments this morning led me to check out what kind of variations a developer might want to anticipate.
http://en.wikipedia.org/wiki/Address_(geography)#Current_add...
It can be tough to determine the point at which this will yield seriously diminishing returns in terms of development time as the domain of users goes international.
I realize the following question is fringe-related at best, but does anyone else like to have fun with the company field instead of (appropriately) leaving it blank? Thanks to me my friend now gets ThinkGeek catalogs for the 'his' company: "pornography inside"
http://en.wikipedia.org/wiki/Address_(geography)#Current_add...
It can be tough to determine the point at which this will yield seriously diminishing returns in terms of development time as the domain of users goes international.
I realize the following question is fringe-related at best, but does anyone else like to have fun with the company field instead of (appropriately) leaving it blank? Thanks to me my friend now gets ThinkGeek catalogs for the 'his' company: "pornography inside"
How does one maintain clean data in their database if they do this. Countless people will type things in their own way.
Miami,FL
Miami, FL
miami,fl
miami fl
etc.
would a city/state autocomplete be the best here, but what about other sections of the required data?
Services like Google's geocoding API (http://code.google.com/apis/maps/documentation/geocoding/) can help with this; it's pretty good about figuring out the address you mean and returning it in a normalized format:
>>> from geopy import geocoders
>>> g = geocoders.Google()
>>> place, (lat, lng) = g.geocode("10900 Euclid Ave in Cleveland")
>>> print place
10900 Euclid Ave, Case Western Reserve University, Cleveland, OH 44106, USAThe only problem, is that the TOS do not allow you to use it if you do not show the information on a map and there is a usage limit (it's per IP, so you could do it client side).
You can preprocess and normalize the data before you put it in the database. City/state is probably one of the easiest fields to do this with.
I like the idea this article proposes, but I believe the author and our commenters glance over some backend difficulties. Yes, there are exactly 50 states each with precisely one two-letter abbreviation. How would you handle, say, "Boston, masachusetts" [sic]?
I mentioned a method above (http://news.ycombinator.com/item?id=2825015) and since entering it, I've thought a bit more about the issue. Most instances will have only two words. If it's three or more and the last word isn't two characters, then if the second to last is one of "north", "south", "west", "new", "washington" or "puerto", then the last two words form the state and the rest is the city. And you can ignore any punctuation.
You should clean all data you get from the user. You are already doing it, unless Bobby Tables is messing with your database. You should just add in another layer.
To summarize everyone:
- Use 3rd party services to scrub data before storing data (phone numbers & addresses are particularly easy to scrub)
- Try to normalize your data yourself (turn everything into lower case when storing in the db, format on the way out to the html page. i.e. Try to convert the date to an object [in python] OR make sure phone number follows the right format with regex)
--
To add my own bit:
- Add visual cues to the form (like ajax validation, etc)
- Use 3rd party services to scrub data before storing data (phone numbers & addresses are particularly easy to scrub)
- Try to normalize your data yourself (turn everything into lower case when storing in the db, format on the way out to the html page. i.e. Try to convert the date to an object [in python] OR make sure phone number follows the right format with regex)
--
To add my own bit:
- Add visual cues to the form (like ajax validation, etc)
He should be validating the user's input before they are even allowed to submit the form (I use jQuery Form Validation). In addition to validation, he can mask inputs require his fields are entered a certain way.
However, this sorta falls apart when you think about internationalization. Phone numbers are a good example. There are so many ways a phone number can be entered that it's almost always best to let the user type in the number in whatever format they want and then validate based on most US/Canada and International formats.
However, this sorta falls apart when you think about internationalization. Phone numbers are a good example. There are so many ways a phone number can be entered that it's almost always best to let the user type in the number in whatever format they want and then validate based on most US/Canada and International formats.
I would think it would always be better to have more free-form input options for things such as names, addresses, phone numbers and such, and only force them into a certain form when you actually need it in that form. For sending packages and billing information.
It's really just another approach to data entry. Instead of ensuring that the data is good before submit, by using dropdowns and such, you accept the data and then verify it.
I've seen e-commerce sites do this with address. They let you enter three free form lines, then send it to their address verifier and give it back to you to confirm. You can either accept it (which then saves the company money because it has ZIP+4) or keep your input as-is.
I've seen e-commerce sites do this with address. They let you enter three free form lines, then send it to their address verifier and give it back to you to confirm. You can either accept it (which then saves the company money because it has ZIP+4) or keep your input as-is.
I wouldn't do ALL of these, but it is pretty easy to avoid multiple inputs for things like U.S. phone numbers. I like the approach of MaskedInput: the user can type parens and dashes or not; if they type them, they're ignored. In any case, we get the format we want.
http://digitalbush.com/projects/masked-input-plugin/ (click demo)
http://digitalbush.com/projects/masked-input-plugin/ (click demo)
My pet peeves:
Why can't the selection of country be simplified? Why do I need to scroll past Afghanistan, United States Minor Outlying Islands, etc to find the US? It should be easy to guess what country I'm in and let me correct.
Why do I have to pick "New York" from a listbox? Let me enter my zipcode (Apple does this on their store).
Why can't the selection of country be simplified? Why do I need to scroll past Afghanistan, United States Minor Outlying Islands, etc to find the US? It should be easy to guess what country I'm in and let me correct.
Why do I have to pick "New York" from a listbox? Let me enter my zipcode (Apple does this on their store).
I've actually discovered that only prompting for zip code and not city/state can be somewhat confusing for users.
We have a system that only requires 3 pieces of info to normalize your address, including city/state: Your street address, your apartment/unit/suite number if applicable, and your zip code. That gets submitted into a third party system that, among other things, normalizes the address to the USPS standard.
(For the record, this is for an application that only deals with US customers, so internationalized addresses aren't an issue here.)
We've typically only prompted on our localization pages for those three pieces of data, and it's surprisingly confusing to customers. It's not too unusual when we review the error logs to discover that people attempted to enter "19000 Euclid Ave, Cleveland, OH" into the street address field and "44112" into the zip code field. Unfortunately, the third party system we use doesn't like this, and will generally not return useful results in that case.
It's getting to the point I'm considering either adding city/state fields to the form or just a message saying "city/state not required." I'm actually not sure which is the better approach.
We have a system that only requires 3 pieces of info to normalize your address, including city/state: Your street address, your apartment/unit/suite number if applicable, and your zip code. That gets submitted into a third party system that, among other things, normalizes the address to the USPS standard.
(For the record, this is for an application that only deals with US customers, so internationalized addresses aren't an issue here.)
We've typically only prompted on our localization pages for those three pieces of data, and it's surprisingly confusing to customers. It's not too unusual when we review the error logs to discover that people attempted to enter "19000 Euclid Ave, Cleveland, OH" into the street address field and "44112" into the zip code field. Unfortunately, the third party system we use doesn't like this, and will generally not return useful results in that case.
It's getting to the point I'm considering either adding city/state fields to the form or just a message saying "city/state not required." I'm actually not sure which is the better approach.
Non-unified text fields do turn me off. There are some cases where it's absolutely reasonable. But the login to one of my accounts is four input boxes which could be consolidated into two. Drives me nuts and makes me reluctant on going back.
I don't know area code of my mobile phone number (mobile area doesn't even make sense!) and I don't have a landline.
What country are you from? In the UK and US area code is pretty obvious to everyone (even in the UK where the "area code" of a mobile is basically just how we split the number based on landline numbers, despite mobile numbers not being geographically based).
I'm in the UK, and I don't think it's obvious what part of a mobile number is the "area code". With a phone number of 11 digits, how many digits form the area code? In a world where numbers aren't even connected to specific provider, the concept of area codes for mobile phones is broken. (Technically, my area code should start with +44 as well, as that's my area from an international point of view).
With landlines, you know which part of your number is the area code, because it has significance. If you call people living near you, you don't dial that code. This behaviour doesn't translate to mobiles.
With landlines, you know which part of your number is the area code, because it has significance. If you call people living near you, you don't dial that code. This behaviour doesn't translate to mobiles.
On account of the vast majority (not all, but most) landline area codes being five digits, that is the convention for splitting mobile codes too, so 11 becomes 5,6. Maybe not everyone knows it, but pretty much everyone I know does, from people who spent most of their life pre-mobiles (e.g. my grandmother), to frinds, to young children.
Even if you didn't conciously think this was the case, would you agree with me on which of the following looks the most natural?
Even if you didn't conciously think this was the case, would you agree with me on which of the following looks the most natural?
07920 748555
0792 0748555
079 20748555
079207 48555I'd argue that the natural option would be
07920748555
When writing it you might choose to add spaces, but that'd be for readability, not because of some notion of area codes.
It's clear even from the name that area codes doesn't apply to _mobile_ phone numbers.
07920748555
When writing it you might choose to add spaces, but that'd be for readability, not because of some notion of area codes.
It's clear even from the name that area codes doesn't apply to _mobile_ phone numbers.
Oh sure, it's for readability that you split it (or the equivilent when speaking) - but because the standard for splitting up a mobile number is the same as the standard for splitting up a landline, it's pretty well known that, if a form (or whatever) were to want your number split in two, then you classify the first five digits of the mobile number as the "area code".
London area code is 020, so I'd bet on "079 20748555".
If a website validates those two-box input fields, then surely it knows length of the prefix better than I do.
If a website validates those two-box input fields, then surely it knows length of the prefix better than I do.
London is one of the few exceptions, not the rule. And even with the three digits, most Londonders I know split their phone number differently (for example "0208 XXX XXXX").
France does not have area codes, just so you know. The second digit (French phone numbers have 10 digits, and the first one has to be 0) is kinda-sorta related to a broad geographical area for some (1 is Ile de France, 2 is the north-west, 3 is the north-east, 4 is the south-east and 5 is the south-west), but not all (6 and 7 are mobile phones, 8 is free and shared-cost services and 9 is for VOIP and stuff which does not fit in the previous numbers)
edit: and the grouping is as simple as you can do: digits are written in 5 groups of 2 digits.
edit: and the grouping is as simple as you can do: digits are written in 5 groups of 2 digits.
From memory a 0 at the front of a phone number is a stand in for the + prefixed country code. So for example Australian numbers such as 0412 345 678 are actually +61 412 345 678. Same goes for international numbers.
As an 'area code' it now makes a lot less sense, but we still need that many numbers to be able to have 1 for everyone, so it'll still be that long, no matter what it's called.
2. Same for the City/State field
3. Half the world will enter dd/mm/yy and half will enter mm/dd/yy for date of birth (and the geeks will enter yy/mm/dd ;-). How do you check for that error?