What features do all Family Tree Programs lack?

[smudwhisk]

It would be nice to attach a 'fact' to the individual to detail the parent(s) name(s) which the programme would interpret as being separate individuals when necessary or useful (e.g. searching for someone). I have a workaround of entering the parent's names into an unused text field (Occupation) but this only works as a note rather than having any functionality.

I use Family Historian.  To get around this and to make narrative reports a little more informative, I have amended the default Birth and Baptism sentence templates to include a section for Parents of a non-blood related tree.  This then appears similar to the sentences for a blood relative in the report.  The amended Baptism sentence template reads:

{individual}<, {=GetLabelledText(%FACT.NOTE2%,"Parents:")},> was <{=GetLabelledText(%FACT.NOTE2%,"Type:")}> baptised {date} at {_place}<. {=GetLabelledText(%FACT.NOTE2%,"Note:")}>

with the following in the fact note section of the attached example for the husband of Elizabeth Collett is a blood relative - Parents: son of Richard and Mary RAGG. 

The only difference in the display of parentage in the narrative report between the two individuals is the fact I don't have any dates for Richard and Mary Ragg, but these could be manually entered easily enough into the note section if known.  Although they won't appear in the people index for the tree, they could be found by the find functionality. 

While I could choose to use the Family Historian v6 Witness functionality to do the same and amend the fact and sentence templates accordingly, I have chosen not to  and even then they wouldn't appear in the person index as they do not have individual person records which is what I wanted to avoid as the trees are large enough anyway.

Edit - I appreciate that the sentence template won't mean much to anyone who doesn't use such functionality, but for anyone that does it is an example of what can be achieve in Family Historian.

[Mike Morrell (NL)]

Interesting comments Mike, but are you really such a dinosaur? Wouldn't relational databases be more bronze-age than stone-age?

I think I have, perhaps by accident, adopted a kind of hybrid approach in that I use both a family history programme (off-line) and a collection of databases which store sources of information and 'things to do'.
....

Hi Nick,

Thanks for your detailed reply - I've learnt lot from it! I've been developing a family tree on and off for about 5 years but I'm only just learning about some of the pitfalls and the discipline required to avoid these. A 'hybrid solution' definitely seems the best way to go! At the moment, this seems the only way to take control of record-keeping and the integrity of both factual data and relationship data.

Your reply - along with other posts I've read - has really changed my perspective on the practice of genealogy. Especially on record-keeping, workflow, websites and tools.

Like many beginners, I started out using one of the big websites (in my case Ancestry). I soon discovered that reviewing and applying plausible 'hints' had compromised my data in a big way! I went back and re-checked all the main links in the tree. Around the same time, I discovered that other websites provided data that Ancestry didn't bring to the surface. So I concluded that I at least needed a 'hybrid' set of sources.

A few days ago I discovered (via a Dutch genealogy forum) http://www.tamurajones.net and Tamura's 2012 posts on data consistency checking. I found out that while some websites and programs do this, many don't. So my conclusion was: I need to 'own' my data and use various tools and websites that help me store research, check and present this data (a hybrid solution).

Ancestry is now my main 'presentation tool' and one of multiple websites for research. I've been using FTM (in synch with Ancestry) to provide additional tools. But I discovered that other software such as 'RootsMagic' and MyHeritage's 'Family Tree Builder'' are better at checking for inconsistencies in the data.

My personal 'hybrid solution' will undoubtedly evolve much as yours has. But the principles of separating factual data en relationship data from each other and both from specific 'applications' used to be the theory and I'm finding out that this is good practice too.

And you're right Nick, compared to the pioneers of computing (https://en.wikipedia.org/wiki/List_of_pioneers_in_computer_science) I arrived in 1976 (with punched cards, paper-tape and computers that took up a whole room) pretty late on the scene. Still, it amazes me how relatively primitive the IT-world looked in the decennia leading up to the current one. I guess that will continue for some time to come!

Regards,
Mike

[Nick_Ips]

I absolutely agree with the idea of 'owing' your data Mike. I am gobsmacked at the way people trade their privacy for convenience and upload their life (even 'intimate' pictures) onto the data storage systems of corporations whose T&C's clearly state that whatever you upload becomes the property of the corporation who can use the data for whatever purpose they like.

A discussion about FTM on Rootschat right now also illustrates the risks/costs of conveninece. And something which is offered today as a 'free' service may well cost you dearly in future. But everybody is entitled to make their own chioce. 

One of the interesting aspects of data structures in family history - which also touches on PaulStaffs comments and the discussion about 'possible relations' - are the limitations imposed by the gedcom structure. Although people think of gedcom files as a means of transferring data, they are in some ways databases in their own right. I think it would be feasible to build a family history database front end which used nothing but a gedcom file for data storage.

But as PaulStaffs notes, the inability to include different types of 'relationship' in a gedcom file means that any commercial software has to either stick rigidly to 'relationships' that gedcom can handle, or else renounce the use of gedcom as an import/export facility. It would be a brave commercial software house which advertised its new product as not compatible with the industry standard transfer protocol and in effect locks the user's data into a proprietary format.

Of course the way different software handles the import and export of gedcom does mean that data may be discarded during a transfer, but many users will be blissfully unaware that bits of their precious research are being thrown away, and be quite content that the universality of gedcom has allowed them to transfer their tree from software 'A' to software 'B'.

There are clearly 'politics' involved in the gedcom structure (which I won't go into here!), but until a new gedcom structure is agreed, or someone big goes it alone, then many of the additional features people may want from their family history software simply won't happen. I guess IT dinosaurs could look on it as family history's "640kb conventional memory limit". In the medum-term there will be many incompatible workarounds, in the longer-term people won't even remember what you are talking about 

[Mike Morrell (NL)]

Again, thanks for helping me along the learning curve, Nick! I'm just finding out more about GEDCOM, genealogical data exchange and some of the pitfalls. I take your point. I'm beginning to see why a desktop-based hybrid solution based is more manageable than trying to keep data fully syncyhed between desktop and multiple web-based trees GEDCOM!

Mike

[Nick_Ips]

Another missing feature, although a bit of a niche one, is something I've also developed my own approach to and call 'Relative Level' or 'RelLevel' for short.

It came about when my ability to regularly visit Kew was coming to an end. I wanted to prioritise who I was going to research while I could still easily access information at TNA.

I have to confess that I regularly add people to my database who are not conventionally related to me. Some people would regard this as a sin, but for both practical and interest reasons I prefer to add people who may not be directly related, but who do have a connection of some kind. For example, I would add the spouse of a cousin, but then also possibly add the parents and siblings of the spouse (depending on circumstances). This particularly applies to some of my Norfolk families where there are multiple connections and I found out quite early on that it saved a lot of time just to add the whole of each family in one go, rather than individually as and when I inevitably found another connection

I've looked, but never found a system which grades or measures the closeness of two people - most family history software seems to limit itself to blood relations and either reports the nature of the relationship (e.g. X cousin Y-times removed) or unhelpfully "Not related".

My rather crude approach (it was done in a hurry) assigns a RelLevel of '1' to blood relations. Those married to a blood relation get a RelLevel of '2'. The parents and siblings of a RelLevel 2 person get a '3', and the people married to a '3' will have a RelLevel of '4'. This repeats adding one to the RelLevel until all people related by blood or marriage or marriage+blood have been assigned a RelLevel. So in effect, all my "Not related" people are graded according to how close they are to being 'conventionally' related. I have written a Visual Basic module within an Access database to do the RelLevel calculations quickly, although not yet 'on the fly'.

I find this RelLevel useful in two ways:

Firstly the original purpose of prioritising my research - when a new dataset comes available I always start by looking for 1's then 2's etc. If I have limited time at an archive I order the jobs I want to do by RelLevel so the most important ones get done first.

Secondly, when adding new people to my tree (database) I use the RelLevel to help decide whether to add the whole family, to only add the parents, or to only record the names of parents in the person's 'notes' field.

As I said, something of a niche requirement! I'd be interested to hear if anyone else has done something similar, or indeed if there is a recognised methodology.

[StevieSteve]

Family Historian has an add-on which allows you to develop plug-ins in their terminology, using the LUA programming language. Though I haven't used it, it strikes me that you'd be able to create your Relative Level reports with it and give you the capacity to come up with all sorts of new ideas

It's not available in the trial version but the deposited plugins in the store may give you a flavour of the capability http://www.family-historian.co.uk/pluginstore/browse-all-plugins

I suspect that there's a lot of untapped potential in these plugins because of the learning curve in getting to grips with the programming but a bit of focus and effort would probably achieve a lot.

[Nick_Ips]

Thanks StevieSteve. I've had a look at the list of plug-ins and the source code for a few of them - very interesting! Although the existing list doesn't include anything similar to my Relative Level, you are right that Family Historian plug-ins would allow that kind of thing to be done.

It is great to see software that encourages users to develop their own tweaks, and share them, rather than having a rigid 'take it or leave it' approach.