Re-evaluating Everything - Sun, 9 Aug 2015

I’ve been bothered with the worry that I may have taken Behold in the wrong direction.

My original goals I believe were solid. Display the user’s information clearly and concisely in one report so that everything’s available and nicely cross referenced in the indexes. Behold was doing this task well and people liked it. The objective was to add editing to this and to allow source-based data entry and virtual merging.

But then I got side-tracked from that vision. I spent a couple of years on a different path to make the report “better”. I expected it would be useful to incorporate all the person’s important family events into their own timeline. Their parent’s deaths, children’s births and their marriage info was incorporated into their own information section with full details. Other events for siblings, parents, partners and children were optionally added as Life events (shown in green) and this option was ON by default. Then I threw in ages and how long married the person was at each event. On top of this, I incorporated some consistency checking mostly based on date comparisons and thought that including the message in red right there where the data was would result in the user best being able to see and correct it.

What did I get? I think I overwhelmed the report with everything but the kitchen sink. It was no longer just the information the person entered. It now included calculated information (like ages and relationships and messages) that interfere with the most important mission of seeing the data entered about the person.

The last few weeks, a few users contacted me and gave me a reality check. Basically, they liked the old pre-version 1.1 report better. They were able to work with it better and could tell what data they had entered and then see what they were missing.

I was myself wondering how I was going to handle this extra info in my database. It would take extra work for me to do it. I was wondering how I’d add editing to this extra info. It would take extra work for me to do it. I was wondering how I’d add source-based data entry and virtual merging to this extra info. It would take extra work to do it.

Not only that, but all this complicates my program, making it harder for me to make changes or find bugs. And it takes longer for the program to run, and produces much larger output.

It now seems so simple, actually. People have other genealogy software to produce fancy charts, make timelines of an individual’s life, do consistency checks, and do detailed analysis of their evidence.

What they don’t have is a simple program to show them all the data they entered, allow them to quickly and easily add to or update that data (in a source-based manner if they prefer) and virtually merge it with data they receive from others or from online family trees.

I’ve been working on the database for Behold so there will be a place to save your edits in version 2. This is the opportunity to take a step back and remove the extra unnecessary goop that I’ve added. It would actually take less time to remove those extras and build the database than it would to leave them in and incorporate them into the database.

I’m thinking of taking the goop out for the next version when I add the database.

I have heard the opinions of several users of Behold that have emailed me and commented on some of my other blog posts about Version 1.1. I would very much like to hear what the rest of you users (and you lurkers) of Behold have to say about this.

Which do you like better? The report in 1.0.5.1 or 1.1?

Version 1.0.5.1 is available here to anyone who wants it.

—

Update: Aug 14. Deciding how to order the information is interesting. It can be:
- age-date-place-event
- date-age-place-event
- event-date-age-place.  

There’s 4 x 3 x 2 = 24 possible orderings. No. I’m not going to let the user decide. I’m going to try to make it easier for you and pick the ordering that is likely the best for research purposes most of the time. I’m leaning towards:
- date-age-event-place

An example would be:

Sun 18 Nov 1951, age 61, married 26y (Mildred Nellie). Marriage of Son: Walter Francis McCARTHY MCC-12, age 20 and Adelaide Helena (LANNAN) McCARTHY LOCKNEY MCC-12, age 18, in South Boston, Suffolk, MA.

It is in one line now. There will not be multiple lines. The subject’s information will be first, so it will be more obvious that the age and marriage information is about the subject and not the relative.

I’m also flipping the person-event (Son Marriage) around to be “Marriage of Son” so that the son information can immediately follow “Son”. I think the new presentation above will be much better than the current display below.

Son Marriage: Sun 18 Nov 1951, age 61, married 26y (Mildred Nellie) in South Boston, Suffolk, MA
   Son: Walter Francis McCARTHY MCC-12, age 20 and Adelaide Helena (LANNAN) McCARTHY LOCKNEY MCC-12, age 18

—

Update: Aug 16. Darn! I still think the event must be given first. I just don’t like the date first. It hides what the event is really about. To avoid confusion between the subject’s age and the relatives ages, it might also be best to put the place before the date, which lists the date and ages last. I think I like this because the place is actually very important and moves up in the line and is easy to find because its a hyperlink. The dates and ages at all events should be easy to find at the end of each event line.

So now I’m going to have:

Marriage of Son: Walter Francis McCARTHY MCC-12, age 20 and Adelaide Helena (LANNAN) McCARTHY LOCKNEY MCC-12, age 18, in South Boston, Suffolk, MA, Sun 18 Nov 1951, age 61, married 26y (Mildred Nellie)..

There’s 240 ways to skin this cat. I’m trying to find the best way.

Oh, and while I’m looking again at that example, I’ve decided it best to cut down the family events that are listed to: Births of Siblings and Children, Marriages of Children, later marriages of Parents, and Death of Parents, Spouses and Children, which have the most effect on a person’s life. The “survived by” and maybe also a “pre-deceased by” section upon a person’s death will give a general indication as to what other events had transpired in the meantime.

Doing so also eliminates the need to number each type of relative. I had numbered them to help to see which person was involved in which events. But now, cutting down the number of life events shown, each person will not be shown more than once or twice and everything is simplified greatly. I also didn’t like the way I numbered sister 3 and brother 2 and child 4 when there were 9 siblings. Child 1 to 9 might have been better, but showing sister or brother is more descriptive. Again a no-win situation. So I’m really happy to take this out because counting the relatives in the program code was a real PITA requiring an extra pass to determine if there was only one, in which case the number wasn’t shown.

I’m now working very hard to get this done, and will release a version 1.1.1 as soon as I can with these improvements.