Louis Kessler’s Behold Blog

I think I’ve got it right this time. Life Events have been cut down to include only the really relevant events that will be important in your research.

Children and parent birth, marriage and death events are important. Siblings are as well until the person of interest gets married. Half-family, stepfamily and adoptions are displayed as they should be. Too many programs make it hard to see what’s going on between half and stepfamily. These were very tricky relationships to set up. I think I got it all correct, but let me know if something doesn’t seem right.

I am quite pleased with two sets of information that Behold now presents that few other programs do. I think they are both valuable for research:

Survived By / Predeceased By

For each person who has died with a known death date, there’s a “survived by” and “predeceased by” section designed to present the names somewhat like they would be presented in an obituary. If you have the obituary, you can check it with this list to see if it matches, and update or correct your genealogy data so that this information does match.

Current Relatives

If the person is still living, the report will show a list of all the close relatives of that person with you ages and length of marriage if possible. You can use this list to call the person up and intelligently ask them how everyone’s doing, and verify with them that the information is still correct.

There are still a few niggling things to fix up, and I saw them as I made up some screenshots. I’ll get those right as I prepare an update to the User Guide which I’ll release very soon along with what will be Version 1.2.1. 

If you find any problems with the new version, or have some simple suggestions that I can squeeze into Version 1.2.1, please let me know.

But the bottom line is, hopefully you’ll like this version much better than 1.1.

You can upgrade to Version 1.2 from within your current version of Behold. Go to the menu and select Help –> Check Online for New Version.  Or you can download it from the Behold download page.

Its been a while since my last post so I wanted to let you know I’m still here. I’ve been working quite hard to finish off Version 1.1.1 which will be much, much, much better than 1.1. Hopefully not more than a couple of weeks left (but I know I’ve said that before).

I’ve removed piles of code and what’s left will be just what’s needed. For me, it’ll be streamlined with cleaner code and more efficient. For you, the information will be easier to read and I’m including what you as a family researcher need to know, with information that most other programs don’t give you.

This includes half-family and step-family as well as an “obituary” list, with the names of both living and pre-deceased relatives that you can use to cross-check an obituary. For each living person, there will also be a current relatives list, so that when you contact one of them you’ll have a cheat-sheet of their family enabling you to ask about each of their relatives and not miss anyone.

Now you see some of my out of the box thinking. And let me reassure you that I’m not forgetting my main goal to get to version 2 and editing.

Back to work.

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.