I have a friend who's a refugee from Afghanistan. Apparently they don't use surnames there (or at least his tribe doesn't). When he applied for a visa my city council shifted his first name to his last name and he had to come up with a first name on the spot. His name is officially Peter Abdullah now.
Immigrant officials at Ellis Island used to give people last names based on their father's first name, or the name of the city they come from.
Also, Armenians didn't have last names until recently, so you'll meet lots of people with names like "Gevork Gevorkian" or "Ohan Ohanesian", or their name will be shifted to the right, adding an "ian" to the end (think the prefixed O' in irish names), and give them anglicized names.
Oh man, I really feel for her. Dealing with the various immigration agencies must have been a nightmare. I bet they ended up officially changing her name to "Firstname Firstname", which is what we tend to do in the states..
This bugs me, because if a name is supposed to be a unique identifier, then part of it's existence is to feed the ego. "This is ME! I am Jean Valjean!"
When you then you change somebody's name to fit your short-sighted database constraints you're pretty much saying, "You don't matter as much as our programmers' decisions matter, now move along 9430"
I used to date a woman whose hippy mother decided that last names were slavery, she's the person who turned me onto this list. The experience really opened my eyes into the anglo/usa-centric nature of most app development best practices, and how complicated it must be to work as a localization engineer.
She suffered quite a bit, any call to a government agency, especially FASFA student loans (btw fuck you FASFA, fuck you), would often end up in tears after hours of pleading to them she was a real person, or explaining "just freaking search me this way, it's how they did it the last time I spent 2 hours on the phone with you). The only benefit is that having only one name makes it rather difficult to google/facebook stalk you.
tl;dr: Not everybody has a name like yours. Don't use "first name", "last name" for somebody's name. Just give it a 512-byte or larger UTF8 field, and move on.
Tangentially, I'm always slightly uncertain about what to put when asked about my "first name" on official forms. While I have a first name it is not and has never been the name anybody has used for me. I've always gone by my second name, and if you where to ask for me by my first name no one would know whom you are talking about.
Basically do you want the the string returned by name.split()[0] or do you want the string which is the most commonly used identifier for me?
I'd say you want to be consistent within the same context. Otherwise it's their own fault if they can't ask you for something more specific.
E.g. if they want a display name, they should ask for a display name. Most of the time people need only a few different roles, and you can always pre-populate default values based on doing a simple name split and letting people suggest more approriate alternatives.
Upside is that asking for specifically what they need addresses other concerns, such as e.g. parents signing up to something on behalf of their children, or someone needing to put another name of a shipping label.
In most official cases, what you they mostly want is the string which matches the one in other official documents about you. They will often also use it in communications, but having a separate field for chosen name would probably be more hassle than it's worth.
This makes me think you should maybe just have a few fields for names for different use cases and maybe provide an example next to it to see it in context.
Name on Invoices John Miller, PhD John Miller, PhD / Ocean Drive 13 / Tahoa 12345
Name for Phone Calls Mr. Miller Hello Mr. Miller, how may I help you?
Ugh this again.
No.
People have a first name, and they have a last name. Each name consists of a reasonable number of ascii characters. If they decide they are special and don't wish to conform to this scheme how is this my problem?
What if I decide my "name" is the first billion digits of PI? Are you going to add that to the list of names that you need to support? No?
In economics, people talk about the problem of 'sorting and labeling' and how that is an unconscious reaction (which does unfortunately lead to bias) but it helps immensely in the overall productivity of an entire system.
When people expect you to design special systems which increases the overall entropy, I wonder if they realize that you too incur a cost for creating that system. I say this as someone whose name is constantly butchered during my dealings with American entities, and I am not generally asking them to modify their system to accommodate my name so it remains unaffected. Thankfully, in most cases, I actually have a choice of whether I should continue having dealings with such entities. (I don't know what happens in cases where you don't, like, say the DMV).
If the argument is economics and system complexity you should favour a single name field over first and last name though. It's one of those rare occurrences where something is both simpler and the better option.
But is it the better option? Suppose x% of the human population has a name which can be reasonably decomposed into first and last names. I honestly don't know what x is, but say it is about 90%.
When you store it as a single string, which order will you choose? Will you have delimiters between them? Would they still be in effect when the person's name has more than 2 parts? If you are ever in a situation where you need to sort by name, will you do it by first or last name? What if there is a need for the other option to the one you chose? Can you reasonably guarantee that you can identify family members if you ever need to? When the customer tells their name over the phone, will it slow down your customer service people if you display the entire name in a way which they are not usually familiar with?
1. There is no order, just use whatever the user entered. In general don't get smart with this data just treat it as a single blob of text.
2. Sort by the whole thing
3. No you can't guarantee identifying family members any more than with a first name last name system. If you need that it should be an additional part of the system. Presumably for the 90% of people who does have a typical first name, last name combo you can still identify family members in the same way.
4. Just introduce free text search for this field if you need to find people.
I realized that I am in agreement on point number 1 - don't get smart with this data, in which case the other points are not very relevant.
But suppose you are working at a place where people are keen on getting 'smart with the data', your replies do increase the entropy if only to the extent that 'we have this idiot programmer who thinks he is too smart to use first and last names as we have always done and is breaking all our reporting systems and is causing hell for our customer service agents'.
Yeah if you are intent as a business on getting smart with the data it's much easier for everyone to just get smart upfront and ask the user for the data you want. This is not very inclusive though and has a clear anglo american bias. One might argue that this is a manifestation of the lack of diversity in the industry as whole. I think the list is aimed more at changing the perception and believes about names so that systems designed from scratch change rather than aiming to change existing systems that have a clear first name/last name convention established already
The list goes to far and makes people overreact like you with some kind of "Screw this! Get a normal name or get lost!".
That is the wrong way to handle this. You don't have to support everything in the list. If your product is only for people in America you can expect them to have a name written in latin letters. You can ask them for a surname and a given name, and they will be able to fill it in, but may be slightly annoyed. You should allow apostrophes and accented letters, but it's really not hard these days with UTF-8. ASCII is too limited.
As you support more countries you will need to support more kinds of names.
I'm curious why should you expect them to have a two-word name written in latin letters? You are the most diverse country in the world, every language, nationality and tribe is represented there.
At least in the states, legal regulations on names vary from place to place. In the state of Texas, if you're a lawyer, you are legally required to tell people this, most commonly done by adding the Esq abbreviation for Esquire at the end of your name. I have a friend who's official name (of course I've obfuscated this) is "Dr. Firstname b. Lastname PhD, Esq.".
One of the old classics, I think it was Plauger's book on POSIX, dealt with this in the l10n chapter. One of the examples was "the only customer for this software is the US government, so it only needs English" leading to "then they discovered that the US goverment includes that of Puerto Rico".
How many latin letters are there anyway, 26? 600? I read the latter number in an essay on what typesetters used to keep. Is ' an English letter, as in O'Malley?
It don't think that'll be true in any first world country that has had any form of immigration. Storing a single UTF-8 value is simpler than storing two ASCII values in any case, pick the lazy option.
Interesting that you chose to respond only to the part of the commenters' statement where you had a reasoned response and ignored the second part of their statement altogether.
I would functionally disagree with 40 - by the time someone is in a position to be referenced by a computer, they'll have some way of being referred to, even if it's just a number. It's hard to imagine a truly nameless slave that is kept off the grid, yet still has a computerised individual reference somewhere...
One could change #40 to: You need your customers' names. I look at a name the same way I look at a username, more frequently than not it's a hassle you don't need to solve. In many applications a username, or even better, an email address, is the best UUID for a user.
We design apps to collect names by default, even when we don't need them and will never use them for any purpose, or at worse, the purpose we use them for is violation of privacy.
Suppose someone calls in and tells you they want to cancel but forgot which email address they used for signup, what is the next piece of information you ask them?
Sure, that's a reasonable corner case to be concerned with. But, what if you forgot what fake name you gave them? Or what if your name is John Smith and so are 50,000 others in their database?
While designing or refactoring an app, ask yourself, "Do I really need her name or address? Will I risk their privacy and security if my database is compromised? What will I do with this information? Will I sell it to advertisers, or will I ignore it? Will I alienate any potential customers by following the first-name last-name standard?
Really, this has me thinking, WHY do we have a last name? It's basically nationalism for families. "I am Eric, the son of John Smith!" .. So what? Who cares what your family's name was? Think about it. The only time anybody has ever addressed me with my full-name it was in a government context. Are two names really required for a UUID? Why only two? Why not four?
And if there are multiple tenants (e.g. roommates), who will it be addressed to? Just wondering if the issue is as simple as leaving the entire name field as a nullable string.
Your address entry needs to be flexible enough to accommodate pretty much arbitrary text. There are no universally required fields for addresses. Zip/postal codes are almost universal, but not entirely. E.g. "name; town; country" is sufficient some places; "name; postcode + town; country" is very common, but it can also go to the opposite extreme of a ridiculous number of separate items, so it's best to just give a number of lines and width that is constrained by your address labels, and let people figure out how best to address things to themselves.
If you need to make you address pretty much free form anyway, it makes practically no difference to ask people to put their address including name. If you ask for a name, the problem is that the name they may want you to use in other contexts is not necessarily the same name that people they live with will recognise them by.
E.g. consider a trans person that want you to know them as one gender, but isn't out to their family.
The safest in general is to not ask for "just" a name, but ask "what should we call you in context X?" but in many cases you can forgo the name by not synthesising data items (such as an address) from multiple parts, but letting users provide the whole thing as one entity (you can still pre-populate based on most common patterns), which as a bonus saves you from other stupid mistakes.
I agree with everything you are saying, but you ended your comment with "what should we call you in context X?". "What should we call you in context X" is, at least in the context of the current discussion, the same as a non-nullable string for the name field. Or am I misunderstanding your comment?
To add to my previous comment, what if two or more people from the same address are signed up for your service? How would you help them distinguish between the correspondence each one gets from your company?
I'm saying that you need to be more specific. Just asking for name and having a non-nullable field for it runs straight into this problem, because the user will not know whether you are asking for their legal name, what they want to be called on the site, or what they want you to put an address label when physically mailing them, all three of which may be different.
> To add to my previous comment, what if two or more people from the same address are signed up for your service? How would you help them distinguish between the correspondence each one gets from your company?
By asking "what should we call you when mailing you?" (if you insist on a name field) or "which address (including name) should we use when mailing you?" You could then if you wish pre-populate any variation of name you might have on file for them in those fields; the point is that the more you focus on gathering the specific information you need for that specific context, the fewer wrong assumptions you will be making about what the user would actually prefer.
I have a very, very generic name. I lived in a hacker warehouse a lifetime ago where there were 3 of us with the same exact name, so yeah, the address part alone isn't that important.I always make up a fake address, often a police station or a garbage dump, and treat that address as a throwaway.
