Why Users Fill Out Forms Faster with Unified Text Fields
uxmovement.com
uxmovement.com
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?
[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.
I agree that splitting the city state is probably more complicated than it's worth though.
If you suggest otherwise, how do we know that they can spell their street correctly?
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?
Considering the Internets is a really really big place (not just America), that statement is rather quite false.
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.
I know, this isn't a particularly difficult thing to work around, but I was amused that you replaced one bad assumption with another.
We could always start taking from the back and doing look ups until we have a match or we finish the string.
Is "." a state? How about "75254"?
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.
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.
But the point is---code to check for misspellings already exists.
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.
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.
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.
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. You should never tell someone that their name is invalid. it's their name
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.
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.
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.
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.
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.
2. Probably should have an autocomplete feature.
3. Sometimes I see forms specifically mention what format they want.
I for one like this post.
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.
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"
>>> 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, USA- 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)
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'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.
http://digitalbush.com/projects/masked-input-plugin/ (click demo)
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).
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.
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.
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 4855507920748555
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.
If a website validates those two-box input fields, then surely it knows length of the prefix better than I do.
edit: and the grouping is as simple as you can do: digits are written in 5 groups of 2 digits.