New Direction for Attributes & Events

[Uncle Buddy]

Last night I started to write the code that will add adoptive parents, foster parents, and guardians to the immediate family table as potentially equal participants in the current person's life story. The result, as is so often the case when dealing with relationships, is another blooming of immediate goals, a deepening of the project, and the need to add to and rewrite code I thought I was already satisfied with.

The simpler roles system can also be used for foster parents and the like which had a lesser influence. For example, I had an aunt who lived to the age of 98 who had a career as a foster parent. Hundreds of babies and children passed through her home on their way to adoptive parents. She played a role in their lives, and she would be listed on the roles dialog.

Another couple I know are unofficial foster parents who paid for a pregnant woman's medical expenses after her first month of pregnancy and have raised her child as theirs since the child was born. The biological parent, "Aunt Rose", lives next door and the child is well aware that she's his "real" mother, but his "foster" mother is the one he calls Mama. So Treebard doesn't tell the user where to enter their data in cases like this. A foster parent can be treated either as a person who played an adjunct role, or in the latter case, they could be given as much weight in the interface as a biological parent.

So I set out to expand the immediate family table to include alternate parents, and quickly found a mistake in the code. Since the EventsTable class is instantiated to create both an events table and an attributes table, some code was accidentally being run twice which should have been run once. This sort of thing happens a lot. I've refactored the events table from scratch maybe four times and it's good code as far as I know, but this troubling finding made me think. Experience suggests that when code gets too confusing to easily extend, instead of struggling with it, I should refactor it. Good solutions should simplify the code if possible, even when adding functionality.

The category of "events & attributes" delineates one from the other by whether or not the event is dated. This is a contrivance hoping to keep undated events out of the events table since the events table is nicely sorted by date. I've used software that interfiles dated and undated events/attributes and it's ugly. So I put the two tables on separate tabs. But now when I add a date to an attribute, it disappears. Maybe because I'm an old fogey and maybe because it's a questionable design, I have to ask myself, "Where did it go?" Then I remember--eventually--that it got up and moved to the events table.

I really like this dated/undated contrivance but it's anti-intuitive to have something disappear from sight when I modify it. And it makes the code more complicated, since I have to juggle two instances of a complex class. So I decided to put the attributes at the bottom of the events table, sorted alphabetically. This will simplify the code and make it more efficient; it will run faster and be easier to work on. The user will see the whole story all at once, even though he'll have to scroll down if there's a lot of attributes and events to show. But having a lot to show for our research is a good thing, and that's what scrollbars are for. And it will soften the mental noise that comes about when users legitimately feel that something is wrong. This will happen because some things belong on an events table, dated or not, and some things belong on an attributes table, dated or not. Showing them together will allow me to use my contrived "dated or not" delineation with fewer objections from purists. A feature that doesn't cause confusion will draw fewer complaints from users.

The line between events and attributes is not always clear. It's often fuzzy. I think to design software that's not fuzzy and unclear, a line has to be drawn somewhere, a decision has to be made. So I used "dated or not" to separate the factoids from each other. But I've changed my mind about having to click away from one set of factoids to see the other.

[Uncle Buddy]

I'm glad I merged the events table and the attributes table. As I went through the code in an initial sweep to comment out anything involving the attributes tab and the table it contained, I found lots of cases where code and procedures were repeated because two identical tables with different content existed. There's no reason to have two identical tables with different content, and it doubles the time taken to load the app. A single table with the common columns can have two sections. At the top, dated events & attributes sorted by date. At the bottom, undated events & attributes sorted alphabetically.

This new arrangement will also mean that purists who find it distasteful to use estimated and approximated dates won't have to do so in order to get their events all on the same view. I like using estimated and approximated dates, but there are some real perfectionists in genealogy, which is a good thing.***

I've tried a program called Family Historian which apparently combines events and attributes into a single table called "Facts". Well, OK, "facts" is a nice clean label for something, a nice short word, but it's not factual. There aren't any facts in genealogy, just evidence, assertions and conclusions.

***(Perfectionism would be a better thing if genealogists who have created that perfect tree would share more of their work and stop worrying about their work being stolen. Part of the reason that bad genealogy is always being propagated by copying is that many of the best genealogists don't share, so folks who are just looking for something to copy aren't copying the good stuff; they're copying the other stuff. I sympathize with the perfectionist's unrealistic plight or hoarding habit or whatever it is, but what the heck, you can't take it with you. Seems like people would want to share their pride and joy, their happy hobby, but it takes all kinds. As for actual researchers vs. copiers, I for one wouldn't copy someone's research if they paid me to. I love doing my hobby myself, that's why it's my hobby. There's nothing more boring than copying factoids from someone else's family tree instead of conducting my own treasure hunt. Tried it, didn't like it.)

Attachments: