Post by Uncle Buddy on Mar 14, 2023 0:59:57 GMT -8
What happens when you input a couple to some/most/all genealogy apps? The two persons are then called "spouses". But having a child together doesn't make spouses of two people.
Because of this dumbing-down of the facts, Treebard has long included a category "kin type". These types fall into four categories: parent, child, partner, sibling. For example, the partner category includes bride, husband, fiancee, common-law-wife, etc. The parent category includes mother, father, foster parent, guardian, etc.
Designing for this has always been a pain. Currently for example, the families table still has a parent section at top and under that a progeny section with each of the current person's partners listed. Under each partner is an indented list of children which the current person and that partner had together. No problem there, that's good stuff.
The problem lies in what to call the partner. See the above complaint wherein we don't want to assign the "spouse" label until we know the two people are married. Genieware has been brushing this detail under the rug for a long time, but is it necessary to keep doing so?
The design of the Treebard GUI currently uses "partner" as a generic label when there are no couple events or children to define the relationship. This is a baseless couple; the user just says they're a couple. But when the user adds events, he can also add kin types, so that the members of the couple will be displayed in the families table according to the user's wishes.
The problem is that the user and/or the reality of the couple's events can cause a partner to end up with compound labels. For example, if the current person is Mary Dutton, the partner can be labeled "father of children and husband". This is only a little klunky, I could live with it. But with more couple events added, you could end up with "husband and spouse and ..." which starts getting silly fast.
Then due to Treebard's insistence on allowing the user to create types... it could get pretty bad. I've spent about a week writing and rewriting code that I've already written and rewritten several times in the past. I wonder if I'm starting to see the light on this. If kin types are a real element, I don't want to exclude them just for being inconvenient, or for not being recognized by GEDCOM, and I definitely don't want to label everyone "spouses" just because it's easy. On the other hand, if kin types are just the flip side of event types--and I'm starting to suspect that they are--then now's the time to find an expedient way to solve this problem and pretend the category never existed.
I'm starting to get tired of dealing with kin types, and I'm starting to suspect that recording kin types in a database where event types are already recorded is a double-recording of the same data from different perspectives. Recording the same data twice in a database is a recipe for disaster. It's a form of denormalization and it leads to unmanageable code. Maybe that's what I'm going through right now. For example, if there's a fosterage event, there's obviously a foster child, there would have to be at least one foster parent... point being, Treebard already knows there's a fosterage event and already has a person_id for the child and two person IDs for the foster parents, so why can't Treebard see the fosterage event and decide what to call the couple who did the fostering? They could both be called foster parents. The real trick is not in the parent section at top, but in the progeny section below that, where the current person's partners and children are listed. There are so many things a partner can be called, and given the opportunity, some users will want to create more.
Possible solutions: 1) don't use partner labels; put one label at the top of the progeny table "Partners and Children of the Current Person" (labelframe--like parent section); 2) don't do anything--keep it like it is as long as a label doesn't say the same thing twice 3) hover kintips; 4) get rid of kin types completely and call everyone "partners".
I think the best thing to do is Option 4: eliminate the kin types category, use one label in a labelframe that says "Current Person's Partners & Children".
This kin type element hearkens back to the earliest days of Treebard. It came into being in hopes that I could devise a simple way to calculate the relationship between any two people in a tree, and ended up being used for this labeling purpose instead. When I saw the members of a couple all being called "spouses" in other genieware, maybe I should just have changed that to "partners" and let it go at that. See the screenshot for the objectionable situation that I've worked so hard to create.
Because of this dumbing-down of the facts, Treebard has long included a category "kin type". These types fall into four categories: parent, child, partner, sibling. For example, the partner category includes bride, husband, fiancee, common-law-wife, etc. The parent category includes mother, father, foster parent, guardian, etc.
Designing for this has always been a pain. Currently for example, the families table still has a parent section at top and under that a progeny section with each of the current person's partners listed. Under each partner is an indented list of children which the current person and that partner had together. No problem there, that's good stuff.
The problem lies in what to call the partner. See the above complaint wherein we don't want to assign the "spouse" label until we know the two people are married. Genieware has been brushing this detail under the rug for a long time, but is it necessary to keep doing so?
The design of the Treebard GUI currently uses "partner" as a generic label when there are no couple events or children to define the relationship. This is a baseless couple; the user just says they're a couple. But when the user adds events, he can also add kin types, so that the members of the couple will be displayed in the families table according to the user's wishes.
The problem is that the user and/or the reality of the couple's events can cause a partner to end up with compound labels. For example, if the current person is Mary Dutton, the partner can be labeled "father of children and husband". This is only a little klunky, I could live with it. But with more couple events added, you could end up with "husband and spouse and ..." which starts getting silly fast.
Then due to Treebard's insistence on allowing the user to create types... it could get pretty bad. I've spent about a week writing and rewriting code that I've already written and rewritten several times in the past. I wonder if I'm starting to see the light on this. If kin types are a real element, I don't want to exclude them just for being inconvenient, or for not being recognized by GEDCOM, and I definitely don't want to label everyone "spouses" just because it's easy. On the other hand, if kin types are just the flip side of event types--and I'm starting to suspect that they are--then now's the time to find an expedient way to solve this problem and pretend the category never existed.
I'm starting to get tired of dealing with kin types, and I'm starting to suspect that recording kin types in a database where event types are already recorded is a double-recording of the same data from different perspectives. Recording the same data twice in a database is a recipe for disaster. It's a form of denormalization and it leads to unmanageable code. Maybe that's what I'm going through right now. For example, if there's a fosterage event, there's obviously a foster child, there would have to be at least one foster parent... point being, Treebard already knows there's a fosterage event and already has a person_id for the child and two person IDs for the foster parents, so why can't Treebard see the fosterage event and decide what to call the couple who did the fostering? They could both be called foster parents. The real trick is not in the parent section at top, but in the progeny section below that, where the current person's partners and children are listed. There are so many things a partner can be called, and given the opportunity, some users will want to create more.
Possible solutions: 1) don't use partner labels; put one label at the top of the progeny table "Partners and Children of the Current Person" (labelframe--like parent section); 2) don't do anything--keep it like it is as long as a label doesn't say the same thing twice 3) hover kintips; 4) get rid of kin types completely and call everyone "partners".
I think the best thing to do is Option 4: eliminate the kin types category, use one label in a labelframe that says "Current Person's Partners & Children".
This kin type element hearkens back to the earliest days of Treebard. It came into being in hopes that I could devise a simple way to calculate the relationship between any two people in a tree, and ended up being used for this labeling purpose instead. When I saw the members of a couple all being called "spouses" in other genieware, maybe I should just have changed that to "partners" and let it go at that. See the screenshot for the objectionable situation that I've worked so hard to create.
Attachments:
