Genealogists don't make names up
May 18, 2020 6:46:57 GMT -8
Post by Uncle Buddy on May 18, 2020 6:46:57 GMT -8
Once upon a time I decided I wanted a "display name" in Treebard which the user could create himself, at whim. This quirk in my thinking had something to do with the fact that in any large tree there will be name duplication. The user should have a unique name to call a person if he wants. Right?
Not if he has to invent the name. If there are nine John Smiths in a tree--or twenty-nine--so be it. The software should not enable the user to cheat by encouraging the use of nicknames in place of official names. Tamura Jones has a good essay on this topic in his blog at the page called "2017-01-08 Genealogy Name Basics".
In the past few months and especially in the past few days or weeks I've spent a lot of time trying to shore up the notion of a user-defined display name. I am now going to spend a day or more stripping this misfeature out of my code, and good riddance. Here are the reasons from my limited experience.
1. Genealogists don't make things up. We are after facts. We get facts or versions of them from sources, not from our imaginations.
2. People in the olden days had enough names, alternate names, and alternate spellings already. Adding another name at whim reverses the purpose of genealogy.
3. People copy other people's trees. Add a fictitious name for your own convenience and someone else will copy it assuming it's a real name.
4. Each person already has a unique ID number. Requiring a unique display name on top of that kinda circumvents the whole purpose of a database, which is to tell people apart on the basis of a variety of real traits, some shared and some of which distinguish one person from another.
5. A unique name is redundant. Use the ID. With two unique identifiers per person, there's more work to do.
6. It bloats the code. I was spending all my time trying to figure out elegant ways to shore up an inelegant idea. Code bloat generates more code bloat.
7. Lists of names need to be sorted. By what? If you have a John Smith with a fake nickname or suffix to distinguish him from other John Smiths, you either have to sort by fake info or sort by the real name that underlies the fake one. If you do the latter, the display name might appear in the wrong order in the list. This is what finally convinced me. I was working hard to sort the names by underlying real names and then creating dorky tooltips to say what the goofy fake names were actually sorted on... never mind.
8. The only semi-reasonable excuse I had for having the user create display names was that a few people have more than two middle names, so their names take up too much space in a table. It's not good to use initials if you know the full name, so I was going to give everybody a display name because of a few edge cases. In those cases it would be better, if necessary, to ask the user how many of the real names to display. But it would be wrong to add suffixes like "John Smith XpJR9" or other ugliness, it would be wrong to use initials when the full name is known, and it would be wrong to use less than the full name unless the person had a half dozen or more names. Even in an edge case like this, the complete full name should be used as a header on the main person tab. But there should be little or no call for shortening a name, ever. We're trying to find out as much as we can. Abbreviations are kinda anti-genealogical by their very nature.
9. It would encourage one of the ugliest of practices, which is that "Robert 'Bob' Dinkeldorf" thing. How many times I've cringed to see a nickname--even really obvious nicknames like 'Bob' for 'Robert'--inserted into a name every single time the name is displayed. The insertion of a nickname could be done in a report I suppose, but it would be more tasteful design in my opinion to say that Cecil Hartmann went by the name 'Gus' in a nickname field and leave it at that. It serves no purpose to make reports ugly and unreadable. Another bad practice is to include spelling variations like "Barbara/Barbra" every time a name is written. This is what alternate name fields are for.
The main idea is that writing code over to simplify it and strip out bad ideas is worth every bit of the effort it takes. This sort of effort has to be taken before the application is released as "Version 1" or else future versions will have to be backwardsly compatible with junk that should never have been seen outside the programmer's editor.
Not if he has to invent the name. If there are nine John Smiths in a tree--or twenty-nine--so be it. The software should not enable the user to cheat by encouraging the use of nicknames in place of official names. Tamura Jones has a good essay on this topic in his blog at the page called "2017-01-08 Genealogy Name Basics".
In the past few months and especially in the past few days or weeks I've spent a lot of time trying to shore up the notion of a user-defined display name. I am now going to spend a day or more stripping this misfeature out of my code, and good riddance. Here are the reasons from my limited experience.
1. Genealogists don't make things up. We are after facts. We get facts or versions of them from sources, not from our imaginations.
2. People in the olden days had enough names, alternate names, and alternate spellings already. Adding another name at whim reverses the purpose of genealogy.
3. People copy other people's trees. Add a fictitious name for your own convenience and someone else will copy it assuming it's a real name.
4. Each person already has a unique ID number. Requiring a unique display name on top of that kinda circumvents the whole purpose of a database, which is to tell people apart on the basis of a variety of real traits, some shared and some of which distinguish one person from another.
5. A unique name is redundant. Use the ID. With two unique identifiers per person, there's more work to do.
6. It bloats the code. I was spending all my time trying to figure out elegant ways to shore up an inelegant idea. Code bloat generates more code bloat.
7. Lists of names need to be sorted. By what? If you have a John Smith with a fake nickname or suffix to distinguish him from other John Smiths, you either have to sort by fake info or sort by the real name that underlies the fake one. If you do the latter, the display name might appear in the wrong order in the list. This is what finally convinced me. I was working hard to sort the names by underlying real names and then creating dorky tooltips to say what the goofy fake names were actually sorted on... never mind.
8. The only semi-reasonable excuse I had for having the user create display names was that a few people have more than two middle names, so their names take up too much space in a table. It's not good to use initials if you know the full name, so I was going to give everybody a display name because of a few edge cases. In those cases it would be better, if necessary, to ask the user how many of the real names to display. But it would be wrong to add suffixes like "John Smith XpJR9" or other ugliness, it would be wrong to use initials when the full name is known, and it would be wrong to use less than the full name unless the person had a half dozen or more names. Even in an edge case like this, the complete full name should be used as a header on the main person tab. But there should be little or no call for shortening a name, ever. We're trying to find out as much as we can. Abbreviations are kinda anti-genealogical by their very nature.
9. It would encourage one of the ugliest of practices, which is that "Robert 'Bob' Dinkeldorf" thing. How many times I've cringed to see a nickname--even really obvious nicknames like 'Bob' for 'Robert'--inserted into a name every single time the name is displayed. The insertion of a nickname could be done in a report I suppose, but it would be more tasteful design in my opinion to say that Cecil Hartmann went by the name 'Gus' in a nickname field and leave it at that. It serves no purpose to make reports ugly and unreadable. Another bad practice is to include spelling variations like "Barbara/Barbra" every time a name is written. This is what alternate name fields are for.
The main idea is that writing code over to simplify it and strip out bad ideas is worth every bit of the effort it takes. This sort of effort has to be taken before the application is released as "Version 1" or else future versions will have to be backwardsly compatible with junk that should never have been seen outside the programmer's editor.