Treebard Genealogy Software

Evidence-based genealogy... or conclusion-based?

Fortunately there's a way to resolve this conflict while retaining the benefits of each approach.

Accordion boy

Treebard is an open-source project that hopes to enable genealogists to demonstrate, create and test the software functionalities they prefer. Its purpose is to demonstrate design features that could inspire users and developers of genieware to expect a better user experience. It's not that nobody is trying; with all the competition, you'd think there would be some really superior programs available. The problem is simple: genieware (like the software industry in general) is still in its infancy. When I was young, did I ever suspect that I'd be spending my dodderage in front of a computer screen? Not on your life!

So with all due respect for their hard work, I venture to suggest that developers of genieware appear to be lost or in a hurry to sell a product. That amazing genieware just doesn't exist yet. My original goal had been "Source-First" genieware, i.e. enforcedly evidence-based. The article below explains why that changed.

In summary, the purpose of Treebard is to act as a showcase for genieware functionalities and as a working model which developers and wanna-be developers of genieware can use in any way they want. It's coded in Python, Tkinter and SQLite to make it easy for genealogists with software design ideas to participate by writing their own code. Treebard v. 0.0.0  could be written in HTML, CSS, JavaScript, SQLite and Electron, since this combination can handle big files and still run fast. The disadvantage to this combination is that it would help to spread the monoculture that is Chrome/Chromium/Google. And as for Python being too slow to run genealogy software? Try telling them that down at the Gramps project. They've been running full-blown genieware on Python for years. In the meantime, working in Python is a lot of fun and not much harder than writing a little website like this one.

Why Source-First wasn't good enough for Treebard


Ordinary conclusion-based genieware treats everything as a conclusion. So if there's conflicting evidence, two birth events might have to be shown, because the software doesn't offer a better way to do it. Genieware designers haven't differentiated between assertions and conclusions.

Genieware designers have made it tedious to enter sources, as if this functionality were added as an afterthought. Why are so many genealogists not bothering with sources? Everything is being entered as a conclusion, period. In response to this, some designers are now offering evidence-based software.

Extremes evidence-based and conclusion-based, moderated by assertion.
When I first learned that I wasn't the first wanna-be genieware designer to think of forcing the user to input sources, I had to ask myself whether it was such a great idea after all.

But in order to appeal to users, evidence-based genieware can't enforce sourcing. Users still have to be able to enter factoids one at a time and add sources later. Genieware that tries to force the user to enter sources first will not catch on, because it's not realistic. People have different needs than those imagined by software designers who try to enforce the "right" way of doing things.

Once again, designers have missed the important distinction between assertions and conclusions. Anything can be used as evidence including a hunch, theory, or opinion. Without this type of evidence, genealogy wouldn't be the fun treasure hunt that it is. When we're hot on the trail, we want to prove a hunch, and when that last bit of evidence falls into place, it's exciting. Who doesn't like being right?

But who wants to hold off on entering any data till the final proof finally shows up? This would make the database useless, because you couldn't use it to look up the intermediate steps, the tangled details that comprise a growing pool of evidence. We need to enter data when we need to enter it--not just when the proof is 110%--in order that the basis of half-formed conclusions can be checked and re-checked.

Treebard is here to dissolve the false dichotomy: it's not about evidence- vs. conclusion-based genieware. Each of the two types offers us about a third of what we need. Genieware should not be two-dimensional any more than it should be one-dimensional. Genieware should be three-dimensional. We don't make decisions based only on evidence, or based only on opinions. The third member is what holds the other two together. We have to record assertions too, not just conclusions and sources. An assertion is what the source says about a person, place or event. And to make things interesting, sources often disagree. This is where the either-conclusion-based-or-evidence-based dichotomy proves to be a limitation, a short-sighted assumption.

Continuing with the example of the genieware user who has to declare two or more birth events for the same person, because in order to enter conflicting data into the program, this is the only way to do it... The genieware of today has missed the critical importance of the assertion. Between the source and the conclusion is a mediating factor that designers have swept under the rug. An assertion is a claim based on evidence. It is not a conclusion, and that is where Treebard shows the way to a new framework for entering genealogical data.

No, Treebard is not annoyingly different from the way you expect software to work. It's not enforcementware. You can still enter everything as a conclusion like a lot of people do now with their unsourced trees. Or you can enter sources first and form conclusions very carefully. It's up to you how to use Treebard. Treebard can serve the needs of different kinds of genealogists because it doesn't exist to serve one or the other of the extremes. It exists to serve genealogy.

pink woman, 
        blue man, cartoonish clip art

I believe Treebard is the first genieware that provides a simple, obvious and stable separation between assertions and conclusions. Let's say you have three different birth dates for someone, and they're radically different, obviously not variations of each other, and definitely/probably/possibly for the same person. No longer do you have to create three birth events for the same person. You have evidence for all three, so you create three assertions. Anytime you want, you can enter a single conclusion about that birth event. (By the way: Treebard doesn't even allow multiple birth or death event conclusions for the same person, since it's physically impossible, besides being ugly in a family tree. This is actually one of the few things that Treebard doesn't allow.)

Events are listed in a simple table on Treebard's front page, one row per event. This is the conclusions table, which refers to one person. Each row has a button denoting how many sources back up your conclusion that the event happened as you say it happened on the events table, which is really a conclusions table.

If the sources button in an event row says "4", you can click on it and the assertions tab opens up, populated with those four assertions. The assertions tab shows you all four sources as well as what those sources say. This is a simple and useful way to display evidence. We no longer have to lump our evidence and our conclusions together to get them into the database. By keeping assertions and conclusions separate, we can finally do justice to the backbone of genealogy: that which the evidence suggests.

If the source button in an event row says "0", you can click on it and the empty assertions tab opens up. You can enter your assertions and sources right here. No conclusions are drawn by Treebard. We don't like smart software. We like simple software that makes people smarter and more capable, not software that tries to make our decisions for us.

OK, so you have three birth dates for the same person, and each one is from a different source. You can choose the one you like best and enter it as a conclusion, ignoring assertions completely if you just want to make a big tree without keeping track of your sources. Or you can create a separate assertion for each source: Assertion 1: "Frank Johnson was born on the SS Magnificent on his way to Australia on October 1, 1882." Connect the assertion to a source and you're done. Assertion #2: Frank Johnson was born in Melbourne, Australia..." Connect to the source and you're done. Assertion #3: "Frank Johnson was born in London two days before his parents left for Australia... etc." Assertions can't be made without a source, but you can enter any source you want, any way you want to enter it. Even "my pet theory" could be a source. And since assertions require a source, if it's a theory you get to name your theory explicitly.

Conclusions and assertions in Treebard are forever isolated from each other, yet instantly accessible. Assertions are not sources, they are what the sources claim. Assertions link conclusions to sources. By going straight from source to conclusion, designers of evidence-based software would be missing the boat. By treating sources as an afterthought, designers of conclusion-based genieware have been missing the boat for a long time.

painting 'The Storyteller' by Giovanni Domenico Tiepolo 1727-1804
Treebard is here to show the way.
painting: The Storyteller by Giovanni Domenico Tiepolo, 1727-1804

There's no magic process by which conclusions form, except for the one between your ears. Assertions in Treebard never morph into conclusions. They're always assertions. You, the software user, draw your own conclusions. Anything else would be mud. If you want to know what you've based a conclusion on, just click the source button in the row for the event in question and your assertions will be there for you to inspect, in case you want to review or change your conclusion. Changing a conclusion has no affect on the assertions. They're completely separate. All the assertions for a single event are displayed together so they can easily be compared.

The Treebard philosophy is that complex tasks should be made to look simple. Treebard doesn't show you a scary, crowded, jumbled-up interface with too many ways to do everything and no way to do genealogy. The simplicity of the interface hides the built-in complexities, because we're making every effort to code real-life complexity into the database and then not show you anything but simplicity. People, places and events are not simple. But to make genealogical data entry fun, we have been working extra hard to make Treebard easy and intuitive to learn and use.

Treebard is a free, portable, open-source project in the public domain. I've been working on it off-and-on since 2015 and full-time since 2018. Since it's portable, it requires no installation. (Except currently you would install Python and `pip install` Pillow to use it.) Just copy the Treebard files anywhere you want on your computer. Since it's free, you can be assured that our purpose is not to sell your ancestors back to you. Since it's open-source, if I have to stop working on the project, you can pick it up and finish it yourself. Since it's public domain, you can borrow ideas from it and do what you want with them. I like getting credit for my work but I don't demand it.

If it's still anywhere near 2022 where you live, Treebard is not close to completion at this time. Its current functionalities can be sampled by installing Python, which is easy, and double-clicking the file name to run the code. Eventually we plan to make Treebard able to import and export GEDCOM files, but the early inspiration to write this program was that the program could replace GEDCOM as a file sharing utility. At least for us radicals who consider GEDCOM the lowest-common denominator approach to sharing family trees. Treebard is designed to be easy to love, and loving Treebard will encourage users to give each other copies of the program as a new way to share files. Since Treebard is not for sale, there's nothing to stop the whole genealogical universe from adopting Treebard, or an offspring of Treebard, as the new standard in file sharing. In fact, if the marketers of genealogy software would all please just go ahead and convert their respective proprietary data structures into the same format--preferably a common SQLite database structure--we could all leave GEDCOM in the dust right now.

GEDCOM lowest common denominator since 1984 old illustration by 
      Clara M Burd
Is GEDCOM here to stay? Treebard is. Because Treebard is open source, public domain, and designed for amateur programmers to maintain and extend, Treebard can't be stopped. Would you believe I started Treebard on a dare? I noticed genealogists complaining endlessly about the lack of good software, and dared myself to do what I thought the complainers should do: create their own genealogy software.

It's always been my goal to make Treebard the new normal in genieware, the app that everyone will accept and use practically by default. I expect that far-out ideal to translate into something useful if I work long enough to finish it. If I can't finish it, then it's out there in the public domain and anyone can carry the project to completion.

Tree playing harp
from "Flowers and Trees" a Silly Symphony cartoon by Walt Disney, 1932