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.
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"?
Considering the Internets is a really really big place (not just America), that statement is rather quite false.
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?
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.
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.
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.