First Stab at the Assertions Dialog
Jun 12, 2022 19:46:01 GMT -8
Post by Uncle Buddy on Jun 12, 2022 19:46:01 GMT -8
Assertions are genealogy's long-lost cousin. An assertion is what a source says about an event. A conclusion is what a genealogist says about an event. Assertions do not morph into conclusions, in Treebard. They remain separate so the user can always go back and examine his basis for each conclusion he has drawn. Treebard didn't invent assertions, but most genieware ignores them, so this feature will be one of Treebard's most unique contributions to genealogy.
I've waited almost four years to start this feature. Sometimes I thought, if assertions are so important to the Treebard philosophy, why not deal with them first, and then build the whole app around them?
I think that's been tried before. The result would be specialty software, which turns most users off. I want the user to open up Treebard and instantly get drawn into it because its usefulness and simplicity is visually obvious. It should look generic without looking boring, its use obvious without being dumbed down. An app's underlying philosophy is not important to 90% of genealogists, and Treebard is for everybody, including users who will never record one source. Treebard is not about Treebard, it's about genealogy. It should work naturally for all sorts of genealogists.
Sourcing in Treebard is front and center. But without being in your face. While you don't have to search for a way to record a source, and you won't be intimidated by an interface that looks really technical, the feature will be flexible enough for technical genealogists to use. In each row of the events table (which is now going to be called the conclusions table), a SOURCES button opens the assertions/citations dialog for that conclusion. Other areas in the app such as the names tab will provide obvious ways to link citations to those elements.
One thing that Treebard won't do is to tell you how to write or format a citation. You can be as formal or informal as you want. I hope to use autofill again, as I've done with names, places, and event types, so that you can effortlessly use the same citation over and over. This or some other means of making sourcing less tedious is key to my hopes and dreams for Treebard. Copy-pasting citations is not good enough. And a citation should be an element of genealogy, with a unique ID in the database, so that when you link the same citation to multiple other elements, the citation's ID is used as a foreign key in a links table. The citation text should not be stored over and over in the database.
The first step in the new assertions dialog branch will be to rename "events" to "conclusions". The slogan of Treebard ("Evidence--Assertion--Conclusion") is finally getting real with this first attempt to create the assertions table. The term "event" will just be a generic term now, and the official treebard nomenclature for an event from now on is either "conclusion" or "assertion". In the code, a conclusion is called a finding and an assertion is called a claim. The general data relations are that each conclusion can be optionally linked to any number of assertions; each assertion has a one-to-one link to a citation; and each source is linked to any number of citations. As for cited elements, such as names, each element can be linked to any number of citations, while each citation can be linked to any number of elements.
The general idea for a long time has been that when the assertions dialog is finished, I'll move on to some other obsession and stop doing Treebard full time. We'll see how that goes. I could work on other features and little fixes/upgrades till the cows come home or I could burn out and fly away. One thing is for sure: I have no intention of ever finishing Treebard GPS. Unlike apps that are for sale, Treebard never has to pretend to be perfect.
I've waited almost four years to start this feature. Sometimes I thought, if assertions are so important to the Treebard philosophy, why not deal with them first, and then build the whole app around them?
I think that's been tried before. The result would be specialty software, which turns most users off. I want the user to open up Treebard and instantly get drawn into it because its usefulness and simplicity is visually obvious. It should look generic without looking boring, its use obvious without being dumbed down. An app's underlying philosophy is not important to 90% of genealogists, and Treebard is for everybody, including users who will never record one source. Treebard is not about Treebard, it's about genealogy. It should work naturally for all sorts of genealogists.
Sourcing in Treebard is front and center. But without being in your face. While you don't have to search for a way to record a source, and you won't be intimidated by an interface that looks really technical, the feature will be flexible enough for technical genealogists to use. In each row of the events table (which is now going to be called the conclusions table), a SOURCES button opens the assertions/citations dialog for that conclusion. Other areas in the app such as the names tab will provide obvious ways to link citations to those elements.
One thing that Treebard won't do is to tell you how to write or format a citation. You can be as formal or informal as you want. I hope to use autofill again, as I've done with names, places, and event types, so that you can effortlessly use the same citation over and over. This or some other means of making sourcing less tedious is key to my hopes and dreams for Treebard. Copy-pasting citations is not good enough. And a citation should be an element of genealogy, with a unique ID in the database, so that when you link the same citation to multiple other elements, the citation's ID is used as a foreign key in a links table. The citation text should not be stored over and over in the database.
The first step in the new assertions dialog branch will be to rename "events" to "conclusions". The slogan of Treebard ("Evidence--Assertion--Conclusion") is finally getting real with this first attempt to create the assertions table. The term "event" will just be a generic term now, and the official treebard nomenclature for an event from now on is either "conclusion" or "assertion". In the code, a conclusion is called a finding and an assertion is called a claim. The general data relations are that each conclusion can be optionally linked to any number of assertions; each assertion has a one-to-one link to a citation; and each source is linked to any number of citations. As for cited elements, such as names, each element can be linked to any number of citations, while each citation can be linked to any number of elements.
The general idea for a long time has been that when the assertions dialog is finished, I'll move on to some other obsession and stop doing Treebard full time. We'll see how that goes. I could work on other features and little fixes/upgrades till the cows come home or I could burn out and fly away. One thing is for sure: I have no intention of ever finishing Treebard GPS. Unlike apps that are for sale, Treebard never has to pretend to be perfect.