Genealogical Record Keeping Systems

Thinking about the user interface for my genealogy program, I thought it would be good to take a look at some of the existing record keeping solutions, as that is where I’ll be starting.  The record keeping systems allow you to store evidence, but do not include lineage-linked views.  In other words, you can store census records, birth certificates, etc., but you won’t be able to display a pedigree from them.

Here are some very quick overviews of what I’ve seen after playing with each one a few minutes each.

Clooz

Clooz is a package I’ve mentioned before, as it was the one package I had used briefly (years ago).  There is a list of object types (census, people, buildings, sources, research log) down the left side and a list view on the right side.  There is a centralized list of people, and adding a census entry consists of adding a census record and then linking folks into the census record.  All data entry is done in dialogs, making it easy to get a handful of dialogs open at the same time (census record dialog, link people dialog, add person dialog).

Clooz 2.1 Screen Shot

The Clooz home page describes the package as follows:

Clooz 2.1 is a database for systematically organizing and storing all of the clues to your ancestry that you have been collecting over the years. This is not another genealogy program. It is an electronic filing cabinet that assists you with search and retrieval of important facts that you have found during the ancestor hunt.

It uses an access database behind the scenes, and has some integration with Legacy, but that only works with version 6, and I’ve upgraded to version 7.  There is a free download on their site, limited to 29 days or 15 launches.

Custodian

Custodian is a program I hadn’t seen before.  I found it somewhat by accident in an article that contrasts it with Clooz.  Similar to Clooz, it has a list of object types down the left, but it is an MDI application, so when you go to add new items, a child window pops up, which is a big list view with buttons down the side.  Most data entry is done right in the list view, until you get to something like a name, which requires editing in a dialog.

Custodian 3 Screen Shot

The package is very colorful, using lots of backgrounds and shading, which I found made it hard to read at times.  The data is stored in password-protected access database files, under Program Files, of all places.  There is a free download on their site so you can try it before you buy.  The trial limits data entry to ten records per section.

Bygones

I found a link to Bygones on Cyndi’s list, which has a section for these types of packages.  It has an interesting look, in that it appears to be a piece of paper.  I found that made it a bit hard to know where to enter data.  It is written using FileMaker Pro, but I don’t know if the look is typical.

Bygones 0.9d Screen Shot

Their home page has a handful of slide show tutorials, which I probably need to watch, as I wasn’t quite sure how to use the package.  I did watch the first half of the introductory slide show, and it looked interesting.

It is a free download as a self-extracting zip, with no installer.

GenScribe

GenScribe is a Mac program that appears to be closer to what I had envisioned, in that it displays a nice representation of a census record.  The opening screen is a list of buttons for various operations.  It has a list of work to be done at a specific venue, source records, and index records.

GenScribe Census Screen

I’ll have to fire up the Mac I have on loan from work and experiment with how they do the data entry.

There is a free trial download, and the full product only costs $12.

Summary

I’m not sure if I’m really qualified to make any summary statements after just a few minutes of playing around, but I’m going to do so anyway.

My impression is that these packages, in general, suffer from the same problem as lineage-linked packages, in that they don’t adequately differentiate between evidence and conclusions; they just do it from the other end of the spectrum.  For example, in Clooz, you link individuals in your database to populate specific census records.  Well, what if the person named “John Doe” in the census isn’t really the same “John Doe” you have in your database?  This can be seen below, as the “Person” dialog has a list of the census records to which the person has been linked.

Clooz Person Dialog

My goal is to enter census data, birth certificates, and the like nearly verbatim so that the viability of the census record is intact, even if the person isn’t really part of my ancestry.  I should be able to link and unlink evidence and conclusions without “touching” the evidence at all.

Will I really be able to pull it off, and put together something that works better than these packages?  Probably not, but I hope to at least learn a lot along the way.

Trying to move forward on my genealogy app

I’ve been a bit stuck on the genealogy project, for a couple of reasons.  First, I’ve been spending a fair amount of time watching the olympics, which hasn’t left much time for coding fun.  Second, I’ve only been playing a bit with a domain model, and domain driven design just doesn’t quite feel right for this project.  It’s probably my lack of experience with the paradigm, but it seems more applicable to complex business models (lots of interactions and state changes) than it does to a single-user data repository.  I don’t regret spending time with it, as I’ve learned a lot, but I think I need to try a new tack.

Yesterday, I attended the Minneapolis Silverlight User Group meeting, which reinforced the fact that WPF is very cool, and I should probably try to use it for this project.  I played around a bit last night with Family.Show, which is a very cool, glitzy app, but it doesn’t even allow entry of sources.  (It’s a WPF reference app, and in that it succeeds very well, but it’s a long way from a full-blown genealogy app, and they readily admit that.)

My new approach is going to be to get something working, include plenty of unit tests, refactor mercilessly, and try to do the simplest thing.  I’m curious to see where that will take me.  The first thing I’m going to implement is the ability to store 1880 US Federal census records.  I know I want to use SQLite, so I’ll be using that out of the gate.  I’ll likely wind up using NHibernate as well, but I’m going to hold off adding it until I get something working (I’ve never used it, and I’ve got enough new things to learn).

I’ve only begun to explore WPF, so I’m sure the first incarnation will be ugly, smelly code, but hopefully I can refactor it into something decent.  In the very first iteration, I’m not even going to try to maintain a clean separation of concerns; I’m just going to hit the database directly, which will make writing unit tests nearly impossible.  That will be one of the first things I’ll need to fix.

Initially, the app may look and feel a bit like a WPF version of Clooz, but before I get too far, I’ll want to start hooking the evidence to the conclusions to fully realize the design I laid out in my previous post.