Thursday, February 26, 2015

Why I'm Going to Switch My Genealogy Software

Contemplating the re-evaluation needed on my existing family tree, I have (very) reluctantly come to the conclusion that I need to switch to different genealogy software. I dread making such a change, while at the same time I know that it will help me prune out some of the distant – quite possibly unrelated – branches that I have introduced based on questionable sources, and make it much easier to document my sources.

My current software is Reunion. I've been using this Mac-only package for some 20-odd years, since maybe version 3 or 4, and it's now at version 10. There's a great deal I love about Reunion, not least the fact that I'm so familiar with it, data entry is fast and easy. It's Mac-native and thus works flawlessly on my MacBook Pro; although I also have a Windows 7 laptop and use Windows at my job, I'm a Mac user at heart and have been for 25 years. Reunion's family view is highly customizable, allowing the creation of multiple saved layout definitions and letting you display whatever facts, events, and notes you want for an individual, along with source numbers, so you can see what you have sources for without even opening up the detailed person screens. In the person view you can see all source citations for a fact just by clicking on the fact; you don't have to open a separate window. You can specify any "default facts" you want to be created whenever you add a new person, i.e., you're not limited to just birth, death, and burial. You can display as many columns as you wish in the People List, sort by any of them, and filter the names. And I think it just plain looks good, both the database application itself, which is clean and simple, and the (again, highly customizable) charts.

Reunion 10 Family View (customized)

That said, Reunion does have deficiencies. For example:
  • It separates data somewhat arbitrarily into "events" (with a date, place, and note field, but no description field) and "facts" (with a description field but no date, place or note fields), which appear on two separate tabs. Events have an extremely limited set of options for creating rudimentary narrative sentences for reports, but facts have no narrative options at all. Thus, an Occupation fact has no date range attached to it and cannot be sorted with events. You could create an Occupation event, with the occupation itself in the note field, but the note field is not included in the narrative options and so will not appear in a narrative report.
  • You can assign a "child status" such as adopted, twin, died as infant, stepchild, or anything else you want to add to the list – but only one status per person, and the status doesn't appear anywhere except in the child list in the family view. Sources cannot be attached to child statuses.
  • There's no logical place to document proof of parent-child relationships, other than in a generic Notes field.
  • The only method of handling alternate names is via an "AKA" fact, with no provision for separate first and surname fields (so they don't export correctly in a GEDCOM), and alternate names do not appear in the People List. 
  • There are no "place details", so cemeteries, for example, must be entered as distinct place names, and there's no option for long and short versions of a place name. If you enter a place, for example, as "Lewiston, Androscoggin County, Maine, United States", that's how it's going to appear everywhere it's displayed or printed.
  • Reunion can recognize and sort dates qualified by "before", "after", and "circa" or "about", but not "between" or "" (it considers these "custom dates" and you must supply a "sort date").
  • Reunion's GEDCOM implementation is not very "standard". It uses some standard tags in non-standard contexts, and many custom tags that don't use the underscore prefix to identify them as such. Custom events and facts are given their own custom tags, rather than using the EVEN CustomName format.
But perhaps the most crucial deficiency is that sources and citations are rudimentary at best. You can create a so-called "source template" with fields labeled anything you want, and designate whether a field should appear in quotation marks or italics/bold/underlined, but you have no control over how the fields are put together for a citation; they are simply strung together, separated by commas, in the order the fields appear in the "template". Each actual citation has a single "Detail" field, which is appended to the source.

Each source, regardless of "template", includes a single free-form text field, which can be used for research notes, source text, comments, etc., but if you use it for more than one of these purposes and want only, say, the comments to appear in endnotes, you can exclude the rest only by enclosing it within "privacy" delimiters (the default is {curly brackets}). If you want to create a free-form source, it uses that same free-form text field as well. There is no provision for attaching record-specific source text or notes to an individual citation.

Also, the GEDCOM export of source fields is completely non-standard; the only way you're going to get transferable sources is by using either exclusively free-form sources, or a very basic template populating only the ABBR, TITL, AUTH, and PUBL tags, with the PAGE tag coming from the citation detail field.

Because of Reunion's source/citation limitations, I have ended up putting what should be "detail" fields into the source templates, and creating separate sources for what should be just records within a source. For example, instead of having one source for the 1880 census in Knox County, Maine, with a citation for each family, I have created a separate source for each family of interest in that county's census (and mind you, I have a lot of ancestors in Knox County!), that being the only way to get details such as the town, dwelling and family numbers, and so on, in the right place in my citations. Likewise, I have a separate source for each record I have cited in Ancestry's databases of Maine birth, death, and marriage records. About the only kind of source that I don't treat this way is published books, which generally need only a page number or range for citation detail.

As a result, I now have over 2000 sources (not citations) in my database for only 6000 people. And that's true even though I started out treating some of my earlier database sources, such as FamilySearch's Maine Vital Records, as a single source with individual records cited just in the citation detail field. Although I eventually decided this didn't give me enough detail, a great number of these early sources have never been updated. If I did update them to the scheme I've been using more recently, I might have closer to 3000 or 4000 sources. While this kind of "extreme splitting" has its adherents, I find it cumbersome, and really feel a need for a program with more state-of-the-art source documentation features.

Having reluctantly accepted the need to move on, I've found my biggest problem with making a change is deciding which application to use going forward. None of the candidates has all the features I'd like to have, and all of them have at least some drawbacks. I'll look at the main contenders in another post.

No comments: