Hacker News Reader

Comment by PeterisP | Hacker News Reader

To sum it up:

TL;DR - Names are complex, simply ask the person for an unicode representation of how they'd like to be called and use exactly that.

1. Any reasonable assumptions or generealizations that you could try to make about names are wrong for millions of people, so don't make any.

2. There is no reasonable way to automatically split a person name in meaningful parts, because there is no such thing as a single universal ontology of meaningful name parts that will fit everyone. Treat personal names as indivisible, immutable items; don't try to separate them in parts.

3. There is no reasonable way to automatically generate a short-polite-addressable form from a full name, aside from (a) asking the user or (b) limiting yourself to a whitelisted subset of names that won't work for millions of USA citizens, much less globally. So don't even try.

4. Don't assume that you can infer [non]existence of family relations from their names. You can't.

View on HN

> Treat personal names as indivisible, immutable items; don't try to separate them in parts.

Unfortunately, that's (often) not an option; as soon as you have to interact with external entities such as banks (but not exclusively them), you're going to be asked for the first and last name of the user.

EDIT: and, by the way, I think that's horrible. Mangling someone's identity like that is pretty bad.

Don't treat those as personal names, then. Expose the bank's interface to your user. If the bank is asking for "first and last name", then say, "the bank is asking for your first and last name; what do you wish us to tell them?"

The customer doesn't really care if it's going into a bank, CC processing (my case), a hotel registration system (also my case), or a soulless SAP installation somewhere in the guts of your company (yes, this is also my case). They're also used to dealing with this (in my opinion unfortunately), but usually not that interested in reading excuses.

FWIW, we only ask for first/last name where relevant (i.e. billing information), but splitting hairs and asking for both is more bother for the user than it's worth.

> but splitting hairs and asking for both is more bother for the user than it's worth.

Then don't. Be honest and don't ask for personal names at all. Ask for billing information.

The "name" fields in billing forms are not personal names. They're keys by which the billing system can correctly identify the account to access. Don't try to pretend that you know someone's name just because you have their billing information. That's lying.

Especially in cases as simple as a customer who is using someone else's credit card to pay for your service. That name is definitely wrong even if one is John Smith and the other is Jane Doe.

I can only agree. It's absolutely horrendous UI to ask for anything other than "what is your name?". It's incredibly unfortunate that various systems that one has to integrate with all have their own inadequate representation of names (given/last, given/middle/last, etc.) when everybody would probably be happier with a single Unicode string "name". :(

I agree, a "how should we address you field" is ideal. I'd like to add though that in case you might have to call them at some point, maybe ask them for a transliteration too where applicable (eg Japanese).

Yes, that's the correct solution for asking for a name. As an example of this, as a side project I'm building an app for my wife (or other teachers) to collect assignments from her high school students and mark their work. In this case, there are separate fields to ask teachers "What name do other teachers call you?" and "What name do students call you?". Both are single, free form text fields that take any UTF-8 text of a reasonable length.

This is especially important for the school environment because the same teacher might be "Joe Schmoe" to other teachers, and "Mr. Schmoe" to students. I also know of some women who married and changed their name, but still use their maiden name with students. Other teachers are casual with their students and have them use their first name. If they teach a Judo class at the school, they might want to be called something like "Sensei Joe".

At any rate, each use case for a person's name should be asked separately, and used verbatim -- without trying to break them up at all.

For some applications a single "name" is good enough, but in other cases, even if your application doesn't interpret it, some downstream consumer of that information (either a person or a computer) will interpret it, like it or not, and may well be more likely to screw it up if there's no additional information (family/given distinction etc).

I think there probably isn't any universal solution that will minimize screwups in all cases, and you do need to look at your usage and audience... ><

> Names are complex, simply ask the person for an unicode representation of how they'd like to be called and use exactly that.

Right, sometimes the best way to model a complex thing is to simply provide a free-text field called "description".

One more interesting implication of 2: you might want to let the user specify what to use for sorting. Although that seems problematic to me.

Internationalized sorting is a whole new can of worms, and there are mutually exclusive rules in different languages.

http://www.unicode.org/reports/tr10/

And (for names, at least) in the same language in different contexts. See https://en.wikipedia.org/wiki/Mac_and_Mc_together (poor article, but the gist is there)

I believe the same is true of de~ and van~ surnames, which are sometimes ordered by the first capital (i.e. van Houten comes before de Koninck), and sometimes not.

This means that offering a user the option of presenting a sort version of their name still leaves them in the dark as to what comes before or after it.

Which is why, I guess, going on 4 years now Mongo has has an open issue to implement unicode sorting and still has not.

No, this is overly simplified and W3C recommends nothing of the sort.

The article helps you analyze your project's requirements (what data do you need to capture? what is your audience? how much resources can be spent on nice UX? etc.) and come up with a solution appropriate for these particular requirements.

I was about to write the same thing, I'll add that the takeaway is basically: keep doing what you've been doing and handle outliers singularly/let people figure it out themselves. It worked pretty well this far, it will keep working well the future.

It did not work pretty well so far. It works horribly wrong for most of the people in this planet.

Reply on news.ycombinator.com