Partners in the Family Table

[Uncle Buddy]

The first draft of the families table is finished through parents and partners of the current person, leaving the children of each partner to finish as well as an input under the table where the user can enter names for new partners and children of the current person. In the description below, remember that everything in this table is supposed to be from the viewpoint of the current person only, not the family unit or the couple unit as such. Limiting the scope of the table prevents confusion and makes it harder for the user to mistakenly edit something with mysterious consequences that would then have to be tracked down and reversed one at a time.

In the parents section, I chose to make it possible to 1) add a parent to a blank parent cell or 2) delete a parent link from the current person by simply deleting the name of the parent from the cell. Trying to make existing parents editable in any other way would complicate the code and violate the principle of limiting the user to editing a person by first making that person the current person.

As it turns out, the code for partners was close to finished, and here's how that currently works in regards to the set of children indented under each partner, if any.

Each partner has a row flush left in the table. Under each partner is a set of children, if any, and the child rows are indented so the user can see the family unit(s) that have been entered for the current person. If needed, a scrollbar will appear, and it will be needed frequently because all the current person's partners and children appear in the table at once, a feature which might be unique to Treebard. Treebard does this because Treebard feels that the most basic element of genealogy is the individual (a biological unit) instead of a couple or family (social units). In order to tell the individual's story, we want to display all his partners and children together at the same time. Partners and children are sorted logically by any dates associated with marital events and childbirth events.

This gets interesting when there are children of the current person whose other parent is unknown. There are a few ways to handle this.

1) If the user enters nothing for some of the current person's children, these children will be lumped together under a partner row with no parent name.

2) But what if the user knows or suspects that the children didn't have the same two parents? In that case, the user can enter underscores, a question mark, or whatever symbol they prefer to create a person in the table with an unknown name. For example, Jed has two children and we don't want them lumped together because we have no reason to believe they had the same mother, and we don't know who either mother was. The user can change each child in turn to the current person and enter "_____" (or whatever he prefers) for each child's mother. Then there will be two separate unknown partners on Jed's family table and each will have one child.

3) If the user prefers to keep the two children under one unknown partner, Treebard will already have them listed this way. Codewise it's important to realize that this unknown partner is not a person in the database, and this happens because Python's `None` is being used as a dictionary key. This could be coded out of the GUI by replacing `None` with a programmatically-created key, but the result would be one unknown partner for each child. I'd prefer to let the user make this decision for himself.

I'm aware of the argument that users should not create fictitious names for their unknown people, and that's why I suggest using "_____" for each unknown person. By using the same symbol for all unknown persons in the tree, the user will make it possible to search all unknown people by searching names equal to the symbol or string of symbols.

Relatedly, it is bad practice to use words instead of symbols to denote a missing name. The common practice of using "unknown" or "UNK" when a name is unknown could conceivably lead a genealogist who is unfamiliar with English to assume that a person's name was actually "Unk". Since that is my name, I'd prefer you didn't use it to refer to missing people.

Attachments:

[Uncle Buddy]

A key design fact to know about the family table is that partners of the current person are discovered for inclusion in the table by querying 1) marital events and 2) children common to the current person and each partner. A partner who's included in the table only on the basis of a marital event such as divorce or marriage or wedding will be listed by "wife", "spouse", "groom" or whatever kin type the user selects. But if there are children for the couple, then the partner will be labeled in the table as "Children's Mother", "Children's Foster Father", etc. To see if there are also marital events for the couple, the user can mouse-graze the events table for kin tips, i.e. tooltips naming the partner. This is all somewhat unusual and can be improved later if it doesn't work out in practice, but I think it will. What I like about it now is that it tells the user how the partner was chosen for the table. A partner might be included in the family table because of marital events, because of children, or both. The choice of wording on the labels gives some information about this. But down the road a less unexpected system of labeling partners might be found.

What I won't ever do is to label a partner a "spouse" just because the partner and the current person have a child together. This is dishonest, or can be, say in the case where no marital events have been found. I think 1/5 of the way into the 21st century we can stop pretending that all parents of children are married to each other. But if you WANT to call all parents spouses of each other, you CAN.

A happy side-effect of the family table is that if a partner has both marital events and children with the current person, and the user unlinks the partner from the children by deleting the partner's name from the family unit that has those children indented under it, then a new row will appear in the table listing the partner by kin type such as "spouse" or "husband".

Attachments:

[Uncle Buddy]

Treebard lets the user unlink either partner from any couple event they're in together with a single simple dialog. The partner-unlink dialog opens if you delete a partner's name from the current person's family table. The dialog lists all the couple's common events and lets you unlink either or both the current person and/or the partner from any or all their events.

This is in contrast to other genieware in which deleting a person from an event literally deletes all the couple's common events. Which is probably acceptable at times but not a decision Treebard should make; that should be up to the user. Since the user has to make these decisions, Treebard makes it easy. Deleting the partner name from either person's family table lets the user deal with both partners and all their couple events at once. Unchecking all the selections is the same as pressing CANCEL. Checking only one person on one event will just unlink that person from the event without deleting the event. Checking all the choices will delete all the events completely. Checking both partners on one event will delete that single event only. (Another way to delete an event is to delete the event label from the EVENTS column in the events table.)

The screenshots show James Woodland and Selina Savoy with a marriage event. James has several partners and Selina just has the one. (James has a parenthetical after his name because we don't know his name at birth and Treebard denotes when a non-birth-name is used to refer to someone.)

When deleting James from Selina's family table, her family table redraws with a blank partner input where James had been. But when deleting Selina from James' family table, sometimes there's no longer a partner input at all corresponding to the event in James' table.

The reason this happens is better explained by this resulting dict data:

None: {'sorter': [1906, 0, 0], 'partner_name': 'name unknown', 'parent_type': "Children's Mother", 'partner_kin_type': 'Partner', 'inwidg': None, 'children': [{'fpid': 95, 'birth_id': 872, 'order': '2-1', 'gender': 'unknown', 'birth': '1925', 'sorter': [1925, 0, 0], 'death': '', 'name': 'Ulrike Macie Deann Theriault', 'id': 5587}, {'fpid': 96, 'birth_id': 671, 'order': '2-1', 'gender': 'male', 'birth': 'Sep 30, 1929', 'sorter': [1929, 9, 30], 'death': '', 'name': "Joe-John O'Keefe", 'id': 5732}], 'marital_events': [{'fpid': 264, 'finding': 1154}]},

What happened above is that when the partner id became None upon Selina's deletion from the only event she shared with James, the missing partner data (finding id, fpid, date sorter) was merged into the existing None partner who had 2 children, since there can only be one None as key for the same dict.

Maybe the best thing to do is to inform the user that ALL marital events and children which aren't given a named partner or parent respectively (even if the name were "" or "_____") will be found in the SAME family unit in the current person's family table. Which is not that bad in my opinion. The nice thing is that it accurately represents what's stored in the database. GUI-wise it's confusing but I think I'll keep it this way long enough to use it and see if it leads to any serious trouble. Complicating everything with a separate partner for each unclaimed child and marital event would be ugly. (A man I once researched had married at least eight women. Possibly to support his lifestyle conveniently, he lived in Nevada.)

If the user doesn't want children with no parent lumped together, the way for him to prevent this is to make each child in the lumped-together-family-of-none the current person one at a time, give him the parent he should have even if the parent's name is "_____", and the problem will disappear. By doing that for the two unclaimed children, I was able to make the blank partner field reappear. This is a reasonable method because all people have parents, it's reasonable to assume it and give them a storable name such as "_____".

The confusion exists in the GUI, not the database. The database is perfectly clear. Trying to display all of a person's many partners and children in a single table is not easy, GUI-wise. In the case of an ordinary nuclear family with two known parents, there is no ambiguity at all. I'd venture to say that giving all unknown persons the name "_____" would solve the problem completely, so I'm not going to "fix" this by making the code more complicated than it already is. The good news is that if the user WANTS to pool all his unknown partners into a family unit with None as the missing partner/parent-of-children, he can do so.

Attachments: