“If your so-called genealogy editor does not offer consistency and reasonability checks, you should upgrade to something better.”

But then this struck me:

“The approach most vendors take today is merely providing the checks through some menu item, and hoping the user has already taken advantage of this feature when they generate a report. That’s understandable, but many users never take advantage of that menu item, because it takes time and isn’t very enjoyable, and because no one reminds them that they should.”

That is true, and the suggestion is made that programs prompt you every so often to do the consistency check. But I don’t think that carries it far enough. Instead, I suggest that the consistency checking not be an option, but always be done and be shown alongside the data so the user can fix it right then and there.

Here’s an example of what Behold’s consistency checking will look like:

The consistency problems are highlighted in red. Why did the husband die before the wife was born? Why was she married between the ages of 1 and 2? Why was no death date given or estimated?

Of course, Behold will have the advantage that the “report” will also be (when editing is added in Version 2) the input mechanism for entering and updating the data. So you’ll be able to correct the inconsistencies right there in the report. Correct the marriage year from 1513 to 1533, and the consistency problem will vanish and so will the message in red.

I suspect the reason why Tamura does not suggest that the checking always be done is the time it might take:

“Although it would be nice to ensure that data is consistent before creating a report, consistency checks do take time, and may take considerable time for large databases. Trying the user’s patience by making them wait on a complete database check every time they want to generate a small report would not provide an enjoyable user experience.”

Well, my argument here is if it’s done right, it shouldn’t add more than a small fraction of time to the processing. If the overhead is small, then the consistency checking can be done while the reports are being displayed. The check need only be done completely once the first time the report is being generated and can thereafter be reused for other reports. When an edit is made, the closely related people are the only ones that need to be rechecked.

With Behold’s life events and integrated consistency checking, the next release should result in Behold becoming one of the very best data checking genealogy programs, for both GEDCOM validation and for consistency checking.

November 8 note: Tamura has added another article: Integrated Consistency Checking, which suggests remembering results and using background checking in order to always provide results. Those are good ideas.

Not sure to congratulate you for the 10 years Louis, or again reiterate my support for your product. I am very keen to see the next version and subsequent after that.
Good luck for the future of Behold. And good luck for the cruise presentations.
Brett - Forum member since 12 Jan 2009

Ideally consistency checking should be happening at all stages. Checking at data entry or import helps cut down on new errors. Checking prior to report production reduces the need to proof read the report. The seemless, non-irritating incorporation of checking is the challenge.

Presumably you have decided on criteria for the checks. What data have you used to arrive at the limits for flagging? There will always be some data that fails the checks, but is correct e.g. a tiny minority of children are born to women over 50.

I’ll have an initial (and hopefully close to comprehensive) set of checks with some based on age criteria that will be user-settable. When I add editing to Behold, I’ll be including a way to easily override a reported problem for a specific individual and mark it as “confirmed”. There’s no use in adding that yet, because currently there is no way to save that info between runs.