Michael Hait’s Perfect Genealogy Software Program - Mon, 22 Oct 2012

I just came across this: Michael Hait’s vision in his April 2, 2012 blog post.

Well, let’s see how Behold is doing.

The software would have two separate, but interconnected, modes: Evidence and Conclusion. Switching between the modes for data entry would have to be seamless, and there would have to be the ability to view both modes simultaneously.

Sounds good so far. 

The Evidence mode would have the following features:

This mode would focus on individual records. A full citation would be entered, free-form, prior to any other information. Citation templates are not used, but example citations for various record types can be referenced. (In an ideal world, there would be a “citation help” menu linking directly to an embedded or online version of Evidence Explained.)

I personally hate forms. Slow. Inefficient. Free form is the way to go. This is planned when I add editing. I like Michael’s idea of example citations and citation help. Very implementable and likely what I’ll do.

Digital images of records can be imported. Names in the records can be directly linked to individuals in the Conclusion mode. (This technology can already be used in The Next Generation of Genealogy Sitebuilding.)

The digital images of records should be with the source list. The way Behold does sources is by displaying the people, events and places that the source provides evidence for. These are linked to the people and places. This is already implemented.

Use of split-screen for transcription of record, similar to Transcribe. The transcription would be linked directly to the image or the citation of the record.

Interesting. A bit of a frill. You can easily view the record in an image browser while transcribing it into any genealogy program.

Again, I think the image of the record should be kept with the source. And the transcription is the data for the source. So they’re already together.

Extraction templates, such as those used by Clooz, could be utilized, and linked directly to images or citations of records. Free-form word processor could also be used for extraction. Each extract also has fields for recording the Informant (which would be linked to the individual in Conclusion mode) and their knowledge of the event (primary or secondary).

To heck with that. Just free form it all. Formality leads to inefficiency.

Creation” field for each record would allow for the recording of citations to and/or transcriptions of relevant laws.

I have no idea what this means, but when editing is implemented, Behold will allow you to create any custom fields you want … although I wouldn’t recommend you get carried away with this. Other programs will not be able to read your custom fields.

Related records could be directly linked to each other. For example, a military pension record could be linked to the compiled service record and the draft registration record.

I don’t see the purpose of this. If a person is connected to all three records, then you’ll have the connections needed from the person’s events. Why would you want to cross-link records? It’s not necessary.

Better is to enable Sources of Sources like I plan to do. When you have a derived source, you can link to the source it was derived from. Then one day, you can go to the original source and check it out for yourself.

A land record tools would provide ability to plat land based on federal or “metes and bounds” land descriptions. (Such as what is done in Deedmapper and other surveying software.) Neighboring lands can be linked together through their shared borders. Lands would have independent timelines through which ownership history could be entered, with independent citations. Both Google maps and historic/USGS topographic maps can be imported. Federal land descriptions may have built-in geocodes, allowing plats to appear in correct location on Google maps. All lands can be manually placed on any imported maps. Geographic features could be linked to USGS Geographic Names Information System for assistance in locating land.

How about if we supply KML (Google maps file) support. That’s what’s really required. The above system seems better in an independent program like Deedmapper.

All records or analysis entries can be “tagged” with relevant events and individuals, but would not be exclusive to single events or individuals.

Already implemented. The sources show all people, events and places. The analysis entries are normally placed with the event. They are event specific. If you have analysis about the source, then it is with the source.

What other features would be useful in the Evidence mode?

Well, repositories should link to sources. Sources should be subdivided by source detail. They should automatically be smart-sorted by source title.

And this should all work with Source Based Data Entry.

The Conclusion mode would have the following features:

This mode would focus on individual people, using a “life timeline.”

Hmmm. Just what I’m finishing up now for Version 1.1

Individuals would have a “profile,” in addition to the timeline, allowing the recording of status tags: gender, race, occupation, free/slave status, etc. Changes in status would also appear in the timeline.

I sort of disagree here. Changes in status are events. You should record them as such. All events will appear in the timeline.

Events or facts would be entered into an individual’s timeline. The events/facts entry would allow creation and use of common verbs in addition to the “genealogical” actions commonly contained in software.

IOW flexible data entry with custom tags if necessary. Yup. Coming with editing.

Only a single instance of each vital event can be entered. Rather than cluttering the timeline with multiple entries based on conflicting evidence (which would be able to be recorded in the Evidence mode), the individual timeline would contain only the conclusions.

That should be up to the user. If you have multiple pieces of evidence supporting multiple birthdates and only want one shown, then add the others as notes to the one. If not keep them separate. But don’t forced this one way or the other onto anyone.

Events would be able to be recorded as specific (or approximate) dates, or ranges of dates.

Powerful and smart handling of dates. Yes!  Age calculations. Yes!  With ranges. Yes! With approximate dates. Yes! Maybe the program could even estimate dates for you – planned!

What about comprehensive logic checking of dates? Put it right into the “timeline” and show the problems so they can immediately be fixed right there, where you see the error. I’m adding the logic checking for Version 1.1, and the in-place editing is coming when editing is implemented.

Events or facts would cite either individual records or proof arguments. Citations link directly to records contained in the Evidence mode. Proof arguments would be composed with a full-featured word processor (not some plain-text “Notes” field) that would allow formatting, table-creation, and internal reference notes (which could also be linked directly to records in Evidence mode).

That’s what I’m doing. Right in what will be a full-featured word processor designed for genealogy.

Except, the formatting and table-creation is something you probably don’t want. Notes should be simple and not made to look too fancy. It just won’t look good in a report and will cause problems. If you want something more complication, link to an object (a spreadsheet, a word-processing document, etc) with a small note about what is in the object
.

One would have the ability to view timelines for separate individuals side-by-side.

I think he’s thinking of this as a graphical timeline. Graphics and charts are really more difficult for visualization than you thing. They’re really more for show and display.

What’s really wanted is to include the “life events” of family members in an individual’s timeline. Then you get everything in context – again with ages, which illustrate illogicalities in an obvious way.

Timeline events could be linked between multiple individuals. For example, a land transaction would appear as a linked event in both the grantor’s and grantee’s timelines.

Those are two participants in an event. GEDCOM used to have a Witness tag to handle this. They changed that and in 5.5 it is now a Relationship. None-the-less, that is already coded into Behold. There’s just too few GEDCOM datasets that include it.

In addition to Individual Timeline, Family Group Sheet, and Pedigree Chart Views, one could also access information through Kinship Network and Associate Network Views. These two “network” views would have a graphic interface similar to that used by GenoPro. They would allow connections to be made directly between people regardless of biological relationship.

More relationship tags.

Associate Network View would automatically import connections based on shared events. Manual connections could also be made. Descriptions would be entered for different kinds of connections. Connections would be cited and linked to records in Evidence mode. Association connections can be tied to timelines, to represent the development or destruction of specific connections. Connections could also be weighted by strength (for differentiation between “strong ties” and “weak ties”).

Huh?

What other features could be useful in the Conclusion mode?

C’mon. Lots of important things you’re missing. Immediate logic checking. WYSIWYG display. In-place on-report editing. Formless. Modeless. Ribbonlike simplicity for data type selection. Extensive integrated help. Fast navigation with hyperlinks. Undo/Redo. Unicode everywhere and anywhere.

You’ve put together a good list, Michael. Behold will probably meet many of your goals, but I expect in a very different way than you’d imagine.