Falsehoods Programmers Should Not Believe About Names
April 10, 2022 4:39 PM Subscribe
I've been asked to consider expanding and improving how our organization handles names, in a database system I manage.
I want to avoid the mistakes described in Falsehoods Programmers Believe About Names
Motivations include:
* allowing users to choose their own name, before the "official" sources have been updated via a legal name change
* handling compound last names (hyphenated or not)
* avoiding using "deadnames" and avoiding other insentive processes
Current system:
* we have the "official name" which is provided by a state agency, is all ASCII with a limited width and assumes First Middle Last, and is vague when dealing with middle names, or compound or hyphenated last names.
* We have a Nickname field, but this currently only lets us substitute for the FirstName field, e.g. "Johan Smith" can be known as "Jojo Smith", but there's no way to know "Johan Smith" as "Foo Bar".
My grand plans:
* create a "ActualName" field, which will be a single UTF8 field, with no limit.
* our existing Nickname field will be merged with this (probably with another field, e.g. Boolean "IsTheNicknameFieldFirstNameOnlyOrWholeName" which will indicate if this is a FirstName or WholeName replacement)
We'll keep the official ASCII name internally, but many of the customer-facing things (website, mailing lists, etc.) will use the UTF8 field if present.
Our DBMS actually has really great UTF support, so we could probably handle emoji names.
What am I not thinking of?
Motivations include:
* allowing users to choose their own name, before the "official" sources have been updated via a legal name change
* handling compound last names (hyphenated or not)
* avoiding using "deadnames" and avoiding other insentive processes
Current system:
* we have the "official name" which is provided by a state agency, is all ASCII with a limited width and assumes First Middle Last, and is vague when dealing with middle names, or compound or hyphenated last names.
* We have a Nickname field, but this currently only lets us substitute for the FirstName field, e.g. "Johan Smith" can be known as "Jojo Smith", but there's no way to know "Johan Smith" as "Foo Bar".
My grand plans:
* create a "ActualName" field, which will be a single UTF8 field, with no limit.
* our existing Nickname field will be merged with this (probably with another field, e.g. Boolean "IsTheNicknameFieldFirstNameOnlyOrWholeName" which will indicate if this is a FirstName or WholeName replacement)
We'll keep the official ASCII name internally, but many of the customer-facing things (website, mailing lists, etc.) will use the UTF8 field if present.
Our DBMS actually has really great UTF support, so we could probably handle emoji names.
What am I not thinking of?
First off, I think it's awesome that you and your organization are trying to handle this in an inclusive way. But I also think your question is difficult to answer without knowing what, specifically, you're using these names for.
As I understand your description, the user accounts in your system are already closely linked to records from this state agency, which has its own idea of each person's "official" name, and you have no control over what that is. And your proposal is to add a field for another name, which can be anything the user wants, and which will be displayed in the UI, while leaving the existing field alone. Do I have that right?
If so, the main risk I see here is potential confusion between the two fields. Will you be able to explain (or otherwise clearly indicate) to your users which contexts in your system will use the "official" name and which ones will use the "actual" name? For example, imagine a trans user whose "official" name is a deadname. Are you confident that they would have enough information to avoid accidentally clicking a button that might somehow result in a message being sent or a document being printed with the wrong name on it?
Also, is there any conceivable situation where a user might be managing or otherwise interacting with an account that's not their own? What happens if they accidentally change the "actual name" on the wrong account? If you use the "actual name" in every prominent UI element, but you don't have any process to check that it bears some resemblance to the "official name", then the user might have no easy way of realizing their mistake. You may want some kind of human oversight to catch things like this, and if so, it will need to be managed in a way that's sensitive to the possible reasons for the names to intentionally not match.
My suggestion would be to limit the size of the field to something very large by human standards, but still small enough that any reasonable piece of software can easily handle it -- say, 1KB. They you just have to make sure that all of your UI elements gracefully degrade when given a name that's too long for the available space.
If you plan to support the full range of Unicode characters, and you care about them rendering correctly, you may need to store additional information beyond just a string. Han unification means that a single Unicode code point can correspond to multiple different glyphs, and in order to draw it in a way that doesn't look wrong, you need to separately know which language the text is written in. Right-to-left text might be another possible source of issues.
Finally, make sure you pay attention to any security/abuse issues that are relevant to your situation. Do you have to worry about users deliberately changing their names to impersonate someone else? Unicode has many invisible characters and homographs, so it's not trivial to prevent someone from choosing a name that looks visually identical to some other name.
posted by teraflop at 5:41 PM on April 10, 2022 [8 favorites]
As I understand your description, the user accounts in your system are already closely linked to records from this state agency, which has its own idea of each person's "official" name, and you have no control over what that is. And your proposal is to add a field for another name, which can be anything the user wants, and which will be displayed in the UI, while leaving the existing field alone. Do I have that right?
If so, the main risk I see here is potential confusion between the two fields. Will you be able to explain (or otherwise clearly indicate) to your users which contexts in your system will use the "official" name and which ones will use the "actual" name? For example, imagine a trans user whose "official" name is a deadname. Are you confident that they would have enough information to avoid accidentally clicking a button that might somehow result in a message being sent or a document being printed with the wrong name on it?
Also, is there any conceivable situation where a user might be managing or otherwise interacting with an account that's not their own? What happens if they accidentally change the "actual name" on the wrong account? If you use the "actual name" in every prominent UI element, but you don't have any process to check that it bears some resemblance to the "official name", then the user might have no easy way of realizing their mistake. You may want some kind of human oversight to catch things like this, and if so, it will need to be managed in a way that's sensitive to the possible reasons for the names to intentionally not match.
our existing Nickname field will be merged with this (probably with another field, e.g. Boolean "IsTheNicknameFieldFirstNameOnlyOrWholeName" which will indicate if this is a FirstName or WholeName replacement)Do you care about having a short form of the user's name, like how Amazon shows "Hello, [Name]" in the page header? If so, you'll probably want "actual name" and "nickname" to be separate fields.
create a "ActualName" field, which will be a single UTF8 field, with no limit.Practically, there must be some limit, if only to prevent situations where e.g. somebody pastes a gigabyte of text into the name field and crashes your server. If your intention is for there to be no limit, that just means the limit will be somewhere you don't expect.
My suggestion would be to limit the size of the field to something very large by human standards, but still small enough that any reasonable piece of software can easily handle it -- say, 1KB. They you just have to make sure that all of your UI elements gracefully degrade when given a name that's too long for the available space.
If you plan to support the full range of Unicode characters, and you care about them rendering correctly, you may need to store additional information beyond just a string. Han unification means that a single Unicode code point can correspond to multiple different glyphs, and in order to draw it in a way that doesn't look wrong, you need to separately know which language the text is written in. Right-to-left text might be another possible source of issues.
Finally, make sure you pay attention to any security/abuse issues that are relevant to your situation. Do you have to worry about users deliberately changing their names to impersonate someone else? Unicode has many invisible characters and homographs, so it's not trivial to prevent someone from choosing a name that looks visually identical to some other name.
posted by teraflop at 5:41 PM on April 10, 2022 [8 favorites]
As a trans person who at one point had to care a lot about a) databases having the same legal name for me that the government and my photo ID had and b) databases surfacing a name for me to other people that I didn't wince at, I really like "Legal Name" and "Preferred Name" for those two fields. I've also seen Preferred Name called "Display Name" or "Administrative Name."
In addition to gender reasons, in my experience the reasons why people don't want to be known by legal names include preferring to use a last initial to avoid caste discrimination - this means you may have several different guys who prefer to be known only as Rajesh N. They also include a lot of people of Chinese descent who prefer to use a Western name professionally and with Western colleagues and people (especially women) in the process of divorcing or fleeing terrible marriages.
If someone's legal name IS their preferred name or they leave the field blank, then you can just use legal name.
posted by All Might Be Well at 6:58 PM on April 10, 2022 [1 favorite]
In addition to gender reasons, in my experience the reasons why people don't want to be known by legal names include preferring to use a last initial to avoid caste discrimination - this means you may have several different guys who prefer to be known only as Rajesh N. They also include a lot of people of Chinese descent who prefer to use a Western name professionally and with Western colleagues and people (especially women) in the process of divorcing or fleeing terrible marriages.
If someone's legal name IS their preferred name or they leave the field blank, then you can just use legal name.
posted by All Might Be Well at 6:58 PM on April 10, 2022 [1 favorite]
Will you be able to explain (or otherwise clearly indicate) to your users which contexts in your system will use the "official" name and which ones will use the "actual" name?
An anecdote about messing this up... I used to use a pharmacy that, miracle of miracles, printed preferred names on prescription labels. God knows if that's legal, but they did it. This was a pharmacy that had a track record of serving trans people in a way that very few institutions can claim. Did I have to ask them to reprint the labels with my legal name because no way in hell was I carrying testosterone across a border with a label that didn't match my passport? Yep.
I think you may be falling for the fallacy (that might be in the list) that people have an "actual" name. You need to make it extremely clear what name field gets used in what context, as otherwise you just end up causing people stress. No one with even a mildly uncommon name situation, especially if they are marginalized in any way, is going to believe you're not going to fuck it up and cause them headaches.
Standard request that cis people think twice before using "dead name". You don't get to define my relationship to my old name.
posted by hoyland at 6:59 PM on April 10, 2022 [9 favorites]
An anecdote about messing this up... I used to use a pharmacy that, miracle of miracles, printed preferred names on prescription labels. God knows if that's legal, but they did it. This was a pharmacy that had a track record of serving trans people in a way that very few institutions can claim. Did I have to ask them to reprint the labels with my legal name because no way in hell was I carrying testosterone across a border with a label that didn't match my passport? Yep.
I think you may be falling for the fallacy (that might be in the list) that people have an "actual" name. You need to make it extremely clear what name field gets used in what context, as otherwise you just end up causing people stress. No one with even a mildly uncommon name situation, especially if they are marginalized in any way, is going to believe you're not going to fuck it up and cause them headaches.
Standard request that cis people think twice before using "dead name". You don't get to define my relationship to my old name.
posted by hoyland at 6:59 PM on April 10, 2022 [9 favorites]
It is very nice when a company properly handles names written “backwards” such as in, say, Hebrew.
posted by Bottlecap at 7:06 PM on April 10, 2022 [2 favorites]
posted by Bottlecap at 7:06 PM on April 10, 2022 [2 favorites]
People should also be able to use initials as they like -- such as using their first initial instead of their given first name.
posted by NotLost at 7:09 PM on April 10, 2022
posted by NotLost at 7:09 PM on April 10, 2022
I'm no programmer but have worked a lot with mailing lists etc and my biggest gripe was always lists of names where first, middle, last were all in the same field. While you can use logic to separate them, that often fails with multi-part names etc.
My only suggestion is that you break the names up so that a single name is in each field (if that's possible where you're getting the names from an external system). It's very simple to join names up in whatever format you want that way and there are few traps. Adding a 'preferred' name is good and some systems label that as 'what do we call you when we talk to you' or similar. At the risk of overcomplicating things, you could have a field for each of title, first, middle and last name (containing names matched with eg identification) and a second set of fields for the complete 'preferred name'. Make sure you don't make first and middle names compulsory because of people with only one name.
I don't pretend to know how to deal with deadnames, but there are lots of potential legal and logic issues here, particularly if you have to rely on external sources for your names and want to split the names up in different ways (for mailouts etc).
posted by dg at 9:04 PM on April 10, 2022 [1 favorite]
My only suggestion is that you break the names up so that a single name is in each field (if that's possible where you're getting the names from an external system). It's very simple to join names up in whatever format you want that way and there are few traps. Adding a 'preferred' name is good and some systems label that as 'what do we call you when we talk to you' or similar. At the risk of overcomplicating things, you could have a field for each of title, first, middle and last name (containing names matched with eg identification) and a second set of fields for the complete 'preferred name'. Make sure you don't make first and middle names compulsory because of people with only one name.
I don't pretend to know how to deal with deadnames, but there are lots of potential legal and logic issues here, particularly if you have to rely on external sources for your names and want to split the names up in different ways (for mailouts etc).
posted by dg at 9:04 PM on April 10, 2022 [1 favorite]
If you do break into separate fields, have a check box for when the family name should be presented before the first name.
posted by Bottlecap at 9:37 PM on April 10, 2022 [1 favorite]
posted by Bottlecap at 9:37 PM on April 10, 2022 [1 favorite]
my biggest gripe was always lists of names where first, middle, last were all in the same field.
Out of interest, can I ask what problems were caused by having these names in a single field?
posted by vincebowdren at 3:51 AM on April 11, 2022
Out of interest, can I ask what problems were caused by having these names in a single field?
posted by vincebowdren at 3:51 AM on April 11, 2022
Vincebowdren: for starters, sorting and searching. If you have names in, say, signature form, John Q. Public, it's hard to the point of impossible to sort into last name order. Some people have what you might call open compound last names like Ralph Vaughn Williams.
posted by SemiSalt at 4:31 AM on April 11, 2022 [2 favorites]
posted by SemiSalt at 4:31 AM on April 11, 2022 [2 favorites]
Do you ever have to compare your information with Official Information stored elsewhere? By an insurance company, by the DMV, by the Social Security Administration for employment eligibility verification, by someone running background checks, by another business in the same role as you who you're transferring records to/from, by a telemarketer or mass mailer, by a debt collector, etc etc etc...
If so, consider whether they'll expect the information in a traditional-for-the-US "First Middle Last" format, or in some other traditional format like "FamilyName PersonalName" or "First First Last Last" — and whether it will cause hassles when you can't provide that.
(My ex was born in Louisiana where "First Middle Last Last" is a totally legal name format, and then moved to a state where she had to chunk it "First Middle-Last Last" — and where it sometimes caused problems if someone mis-entered it as "First-Middle Last Last" or "First Middle Last-Last.")
It's shitty that this sort of situation forces you to mimic the bad practices of another organization. But for interoperability, you might have to do that, so you should investigate ahead of time whether that's the case.
posted by nebulawindphone at 6:14 AM on April 11, 2022
If so, consider whether they'll expect the information in a traditional-for-the-US "First Middle Last" format, or in some other traditional format like "FamilyName PersonalName" or "First First Last Last" — and whether it will cause hassles when you can't provide that.
(My ex was born in Louisiana where "First Middle Last Last" is a totally legal name format, and then moved to a state where she had to chunk it "First Middle-Last Last" — and where it sometimes caused problems if someone mis-entered it as "First-Middle Last Last" or "First Middle Last-Last.")
It's shitty that this sort of situation forces you to mimic the bad practices of another organization. But for interoperability, you might have to do that, so you should investigate ahead of time whether that's the case.
posted by nebulawindphone at 6:14 AM on April 11, 2022
Just wanted to say that changing your name"officially" for trans folks in the US is a multistep process that takes months at the very least even in liberal states like California. That's not including things like updating your mailing address, voting record, credit cards, transcripts, letters of recommendation, and that's just if you are from CA, not from another state, or another country. You may need to record past names for various purposes while this happens.
The actual name you get from that state agency, how do you deal with it being updated? What about for records after they leave the institution you are working at, if they transition afterward?
posted by Chrysopoeia at 2:15 PM on April 11, 2022 [1 favorite]
The actual name you get from that state agency, how do you deal with it being updated? What about for records after they leave the institution you are working at, if they transition afterward?
posted by Chrysopoeia at 2:15 PM on April 11, 2022 [1 favorite]
... what problems were caused by having these names in a single field?
As well as the sorting issue that SemiSalt mentioned, it creates problems where you want to do things like mail merges and use (eg) Title First Last in the address block (or envelope), then Title Last in the salutation. It's not impossible to create formulae to disconnect the names and create another list, but it's another step and far from foolproof in ways others have mentioned.
It's quite easy to join names together in all sorts of ways when they are in their discrete components in a logical format, but much harder to separate them when there's no clear divider that always works.
The issue of deadnames can, I guess, be solved by a further set of fields that describes a 'former name', but do you then only assume one former name or allow for multiple former names (eg multiple marriages)?
posted by dg at 4:00 PM on April 11, 2022
As well as the sorting issue that SemiSalt mentioned, it creates problems where you want to do things like mail merges and use (eg) Title First Last in the address block (or envelope), then Title Last in the salutation. It's not impossible to create formulae to disconnect the names and create another list, but it's another step and far from foolproof in ways others have mentioned.
It's quite easy to join names together in all sorts of ways when they are in their discrete components in a logical format, but much harder to separate them when there's no clear divider that always works.
The issue of deadnames can, I guess, be solved by a further set of fields that describes a 'former name', but do you then only assume one former name or allow for multiple former names (eg multiple marriages)?
posted by dg at 4:00 PM on April 11, 2022
Also possibly helpful and related;
Falsehoods Programmers believe about Names - With Examples (2018)
Falsehoods Programmers believe about Gender
posted by rozcakj at 7:55 AM on April 12, 2022
Falsehoods Programmers believe about Names - With Examples (2018)
Falsehoods Programmers believe about Gender
posted by rozcakj at 7:55 AM on April 12, 2022
It is generally nice to have one box per name. Would you have the ability to add as many boxes as needed? So that if someone has several last names or middle names or whatnot, you have a way to correctly enter that? Sometimes these will be hyphenated but often not.
posted by blueberry monster at 7:47 PM on April 22, 2022
posted by blueberry monster at 7:47 PM on April 22, 2022
« Older Your experience of intermittent fasting | How do I prevent from getting "device is blocked... Newer »
This thread is closed to new comments.
posted by jenfullmoon at 5:13 PM on April 10, 2022 [3 favorites]