1. How do you reliably extract forename+surname from a single name field
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?
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.
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.
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?
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".)
"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.
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.
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.
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.
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.
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.
> 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)
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").
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.
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.
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.
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:
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?