Parents biological, adoptive, foster, & guardians

[Uncle Buddy]

Here's a screenshot showing where the alternate parents feature stands today. There's a lot to do still on this feature.

The screenshot shows all four parent types and more types can be added if I forgot any.

The immediate family table or "nukes table" as I prefer to call it will show all parents, partners and children in the same table at the same time, including a vertical scrollbar if needed. This is just the parents area, at the top of the nuclear family table. Partner and children sections also work and just need a little more formatting.

In Treebard at this point, I'm giving every person a birth event automatically when they're added to the tree. I will assume that they were born at the age of 0 and have one mother and one father. The inputs for biological parents will appear automatically for each person. An offspring event will be auto-created to display on the events table of each parent. That's all in reference to biological parentage.

Adoptive parents as well as foster parents and guardians can play just as important a role in someone's life as their biological parents, so they're being given equal weight, but since the majority of people only have biological parents, the inputs for alternate parent types don't display till the user creates a guardianship, fosterage, or adoption event. Then the corresponding parent inputs appear automatically. Once alternative parents have been entered, the related parental events such as "adopted a child" will be created automatically when displaying the parent as current person.

All the parent inputs are sorted by date. For each parental event in the events table, a corresponding set of parents exists in the nuclear family table, in the correct order with biological parents at top. There can be any number of alternative parents and one set of biological parents. As with anything in Treebard, the way to show conflicting data is not with two sets of biological parents, but two sets of assertions and one conclusion. The events table is a conclusion table, while assertions require some sort of source.

The 2nd and 3rd screenshots show other varieties of alternative parent situations. Now that I look at the labels on the parent inputs, I see that for alternate parents I will have to label them in a unisex fashion since there's nothing in Treebard to prevent a pair of adoptive/foster parents from being the same gender.

I'm planning to add kintips to parent events listed in the events table. This already works for couple and offspring events. If you point at any kin event, the related kin's name and ID will display as a tooltip. In the case of a parent event, both parents' names and IDs will display. I used to have a separate column for kin names but it's redundant information so I got rid of the column. The kintips will help correlate kin events with people listed in the immediate family table.

My goal with this interface is to show plenty of information in an attractive, non-techy, well-organized, and uncluttered way. You can also see that if there's no birth name for a person, whatever name type is in the database will be displayed like this: "Mary Jones (married name)" or "James Woodland (also known as)", for example.

As my mama used to say when she finished knitting me a sweater or something, it looks pretty good, if I do say so myself.

Attachments:

[Uncle Buddy]

This screenshot shows the corrected results with unisex labels used for unknown adoptive parents etc. This demonstrates that persons of either gender can be input to either parent input for foster parent, adoptive parent, or guardian. The unisex alt parent types can be changed later, for example when the user learns the name of an adoptive mother, he can add the name as well as optionally change the type from "adoptive parent" to "adoptive mother" if he wants.

Gender will be limited to male or female only in the case of biological parents. Maybe even this restriction can be worked around by using the gender "other" but I haven't tried it yet.

These records now exist for parental kin types and events in the kin_type table and the event_type table of the database:

# kin_type_id|kin_types
# 111, 'adoptive mother'
# 112, 'adoptive father'
# 122, 'foster father'
# 121, 'foster mother'
# 131, 'legal guardian'
# 130, 'guardian'
# 110, 'adoptive parent'
# 120, 'foster parent'
# Instead of just birth event:
# event_type_id|event_types
# 1|birth
# 48|guardianship
# 83|adoption
# 95|fosterage

This extra work is an attempt to give alternate parents equal status to biological parents. If the user prefers, he can use the roles dialog to display, for example, foster parents of less importance, instead of adding them as a parent type.

Attachments:

[Uncle Buddy]

I've been positioning the mother to the left and the father to the right, which is contrary to what people will expect. Then under that I was trying to get foster mothers to display to the left of foster fathers, etc.

Once I asked myself how to arrange same-gender partners, obviously they have to fall where they may, randomly, or be sorted alphabetically, or as described below.

Here's the new arrangement. Biological father will be to the left and biological mother to the right, as the user will expect since it's done that way in all the other genieware.

Under the biological parents, alternate parents will display to the left or right with no regard for their gender. However, the user can indicate where they should display by entering them where he wants them to display.

Simple solutions are best, especially when they give the user more control and give the GUI designer less to keep track of.

Anyway, that's what I'm going to try. Another simplification.

[Uncle Buddy]

The parents section of the immediate family table or "nukes table" as I prefer to call it is getting closer to finished. I just finished the code that enables tooltips a.k.a. "kintips" to appear when the user's mouse hovers over an event type in the Events column of the events table that represents a multi-participant event.

If the user points at a birth, adoption, fosterage or guardianship event in the events table, a kintip gives the name(s) of the respective parent(s) corresponding to that event.

If the user points at a couple event, a kintip gives the name of the partner in the corresponding couple.

If the user points at an offspring event, a kintip gives the name of the current person's child which corresponds to that event.

These kin names used to have a column of their own, but the existence of the names attracted functionalities unto themselves which were redundant and therefore unnecessary, along with the column itself, since the same names exist (now) in the nukes table. The kintips help the user to quickly correlate which kin event in the events table goes with which person in the nukes table.

Treebard is opposed to redundancy and feels that it becomes an excuse for writing hopelessly ugly, visually noisy interfaces.

Since we avoid displaying redundant information, we have more space to display, for example, multiple sets of guardians, foster parents, and adoptive parents when the user wants to do this. The user also has the option of relegating these folks to the Roles functionality instead of putting them in the family table. Either way, the persons input are fully tracked through the database and will be searchable. Role persons are real database elements equal to related persons, equally linkable to other elements, so upgrading a role person to a related person will be effortless.

Next I will finish the code that lets the user unlink a parent from the current person by pressing the delete or backspace key.

When the whole nukes table area is finished, I'll post some more screenshots. It's already looking pretty lovely.

[Uncle Buddy]

The alt parentage feature works now. It's straightforward and clear in the typical case, but I'll show screenshots of an atypical case where Treebard should only try to do so much vs. doing too much. This atypical case could be described succinctly in a report:

Marge Robinson married Jack Swelto and they had a son named Terrence. They were divorced after a short time and Marge kept the boy, marrying Dwayne Franck shortly thereafter. Dwayne adopted Terrence whose name was legally changed to Terrence Franck. Marge and Dwayne had a child, Vespa Franck.

This is a case where a few simple facts can be reported simply in prose but become messy in a table if you try to do too much. If you think the table would look messy, wait till you see what that code would look like.

This case shows a limit to Treebard's family table as it exists right now. I don't think it's a serious problem but it threw me at first. I assumed it was doing something wrong but now I think it would be an unnecessary complification to "fix" it.

The problem, if that's what it is, is that when you display Marge's current person page, Terrence is shown in the family table as Jack's son (correct) and Dwayne is shown as Marge's partner (correct), but Terrence is not shown as Dwayne's adopted son. This latter could be right or wrong depending on how you look at it. In Dwayne's event table, Terrence's adoption by Dwayne is shown as an event and Marge is shown as a partner in Dwayne's family table, with one child Vespa. But Terrence is not shown as a child of Marge in Dwayne's family table. Once again, this could be seen as either right or wrong, depending on what you expect.

People have been trained by other genieware to expect couples to be treated as an entity and for data to be repeated redundantly. Treebard doesn't necessarily treat all couples as singular entities in every case, and Treebard tries to avoid redundancy.

The reason Terrence's adoption doesn't show in Marge's family table under her partner Dwayne, and Terrence doesn't show as a child in Dwayne's family table under Marge, is that only Dwayne adopted the child. In terms of Terrence's adoption, Marge and Dwayne have little to do with each other, genealogically. Legally, she would have signed a paper to approve the adoption, but what I'm saying is that she didn't adopt the child like her 2nd husband did.

So I feel that this feature is working correctly. Treebard does not go in for redundancy. All the facts can quickly be gleaned by looking at the family tables and events table for the four people involved. Treebard sees everything from the point of view of the current person. The report feature (see above inset) would state this all quite succinctly.

This could be changed so that Terrence would be listed under Dwayne on Marge's family table and Terrence would be listed under Marge on Dwayne's family table. This would result in the following questionable GUI features:
--Terrence would be listed twice in Marge's family table; once for each of her two partners.
--On Dwayne's family table, Terrence would be listed as Marge's son when Dwayne is not the child's father.
--On Marge's family table, Terrence would be listed as Dwayne's adopted son when Marge is not the adoptive mother.

What it boils down to is attempting to adhere to the current person point-of-view to a reasonable degree. By "reasonable degree" I mean you'd never want to show a whole table full of editable information about someone who's not the current person. To make substantial edits to a person's story, you have to first make that person the current person.

Since Treebard is showing only true things about all four people, and since the "problem" is that it's not lumping unrelated and/or redundant information in with the right stuff, I don't think there's a problem that needs to be addressed right now. All the pertinent facts are displayed in the tables. A table can't be expected to do what a report can do, or vice versa, and that's why both features exist.

Attachments: