Genieware Features: Primary, Secondary and Silly
Apr 22, 2022 3:32:08 GMT -8
Post by Uncle Buddy on Apr 22, 2022 3:32:08 GMT -8
Let's take a quick peek at what are considered features in the world of genealogy database software.
A glance at the second table on this Wikipedia page suggests that features include stuff like this:
--views
--charts
--reports
--DNA charts
--research management/guidance
--mapping
In contrast, here at Treebard University we feel that most of these are secondary features, since we're talking about genealogy database software and none of these features address how data is stored and how the data can be manipulated. We feel that there is one primary feature for genealogy database software: getting data into a database in a way that the data can be used with great flexibility and in a way that the data accurately represents the real world circumstances that the software is ostensibly trying to record. I'll try to flesh out this remark below, in the "positivity" section, but first I should get the all-important negative remarks out of the way.
You could add import/export which is important but it's technically still a secondary feature because you can literally create a genealogy database without it. In fact, too much dependency on import/export might mean you either don't actually enjoy inputting data or else you don't want to redo work you've already done. Because your genieware makes it way too tedious. This is a valid concern, however GEDCOM appears to be a silly solution. (It's still needed but more-so it needs to be replaced by something that works well.)
To the list of features above, you could add scraping data off of websites and writing family history books, but that would be at least bordering on silly. Especially writing books. As someone who has actually written books, I'd like to suggest that the best application for writing books is the application of some good old-fashioned elbow grease.
Manipulating graphics? Since the Python module (Pillow) that Treebard's widget toolkit (Tkinter) uses allows some of this, I plan to build some graphics manipulation into Treebard, even though it's pretty darn silly when there are plenty of good dedicated graphics programs available that do it better. I have free programs GIMP, Krita, and Inkscape which I would learn to use except for the fact that the paint program I bought 25 years ago (JASC) still works so well that I'm not that motivated to switch. Incorporating graphics functionalities into Treebard is near the bottom of the do-list.
Mapping? Don't be silly. Between Google Maps, its competitors, and existing graphics software, mapping should only be offered in a genealogy program that is otherwise already finished in terms of the primary feature of genealogy database software. Trying to cover all possible bases in genieware is a waste of the developer's time. The focus of the developer should be the primary purpose of genieware: recording data accurately and usefully in a database. Until that feature is complete, the software is not finished and should not be used or sold to the public, no matter how flashily it can be represented in advertising.
Here are some details of what I mean by "the one and only primary feature of genieware".
It starts with recognizing what the elements of genealogy actually are:
--individual
--place
--event and attribute
--source and citation
--assertion and conclusion
--notes
DNA, mapping and fan charts don't belong anywhere in this list. They're offered in so many unfinished, useless programs because the developers are in a big fat hurry to sell your ancestors back to you, and an unfortunate trait of all things capitalistic is that the early bird gets the worm. That means no one has time to finish the primary feature of the program because they're too busy working on the secondary and silly features. One of the reasons that capitalism ruins everything it touches is that it forces everybody to be in a hurry. In case you haven't looked around you recently, I might mention in passing that our multitasking, rush-rush, us-against-us culture shows signs of being suicidally inept at providing us with a safe and happy home.
I'm not saying that secondary features are unimportant. I'm saying that providing them is a distraction to what should be the developers priority: the primary feature.
Some facets of the primary feature of genieware (and I want to acknowledge Mr. Tamura Jones' inspiring blog, although there's no guarantee he'd agree with everything I say):
Names of persons should be recorded accurately. Since the "first name, middle name, last name" arrangement is not pertinent to all cultures, and since it's complicated to get right in a database anyway, it should not be used in genieware. Treebard records a name as a single string like "Benjamin Plum Pudding" as well as a sorting string like "Pudding, Benjamin Plum". This way we don't have to redefine what first, middle and last names are from culture to culture. In one of the most civilized nations on earth (Iceland) there is no such arrangement for names. There should be no such restriction on name strings.
Places should be recorded as plain nested strings without any built-in jurisdictional categories like "county" or "township". Pairing each place nest with a jurisdiction is unnecessary and basically impossible to do with consistent accuracy if you research enough different places. There can be an input for these categories for those who can't live without them, but if the user is forced to pair each nested place to some preconceived category, it gets messy and there's no solution. The place names and locations are pertinent to genealogy, and the nesting is important, but you don't need to know or care about the jurisdictions to get places right. Jurisdictions should be optional.
More importantly, places must be able to have more than one parent. Smaller places like cities and towns don't get up and move across to the other side of the mountains. Even if this happened and even if the new town had the same name as the old one and the same people lived in it, it would be a different town. Localities have a pretty much fixed general location (though they can shrink and expand). But the larger place wherein a locality is nested can change all the time, and in the pioneer days, this happened all the time. Tracking county and township boundary and name changes is important to genealogy because so much research is based on where someone is living. Just because two census schedules list Samantha Jones in Dogwood County, Nebraska doesn't mean it should be the same Samantha Jones; the two places could be 300 miles apart. Each individual place needs its own ID which never changes, and a city in Texas can be nested in any number of precincts, counties or even nations. Some Texas cities we know today were once in a country called the Republic of Texas, which was not in the USA. I doubt there's more than one or two geniewares out there that make it possible for a single given place to have any number of parents. In Treebard, for each parent a place has, there's also a field in the database for the span of time during which this was true.
I'd have to guess that one reason places are over-simplified in existing genieware is that the developer, for a reason I cannot fathom, feels that he needs to pre-load the app with the world's places. This amounts to doing the researcher's hobby for him, which would have to be done badly under the circumstances. Take for example the apps that list my great grand-daddy's hometown by its zip code of all things. Sorry folks, just because it's on Google Maps don't mean it belongs in my database. Users cannot have an accurate database if it comes pre-loaded with over-simplified, rigidly nested place names from the wrong time period, and since the developer doesn't know the what or the when of my family history, the developer can't imagine what (accurate, exact) places to pre-load the app with. And I might not need 98% of the place names in the app anyway, so why are they there bloating the program?
While everyone is arguing about whether genieware should be evidence-based or conclusion-based, as usual with false dichotomies, both sides are missing the point. Evidence and conclusions are both elements of genealogy, but few if any geniewares 1) recognize that that both assertions and conclusions exist & are not the same thing, and 2) build that reality into their database structure. A conclusion is reached by the researcher based on whatever evidence that researcher feels is relevant. The evidence is woven into a source, and the researcher must decide what that source is saying, and he must be able to record, separately from his conclusion, the assertion that the source is making. But different sources will make conflicting assertions. So because current genieware doesn't recognize the difference between assertions and conclusions, we have more silliness: individuals with multiple births and deaths, for example. This isn't the researcher's fault; he's trying to enter all the information he has found, and there's no other way to give the sources and their conflicting assertions an equal opportunity to be heard except by burying a lot of unwanted prose in notes. Assertions and conclusions must be recorded separately in the database, and they cannot morph into each other. The software cannot draw conclusions. Only the researcher decides what happened way back when.
Notes have to be linkable to any number of other elements. In the past, trying to use the only genieware I ever had any affinity for, I used to write up detailed notes which would have to be copied and pasted from one person to another. This is not how software is supposed to work. It's certainly unnecessary, if the database is structured right. Double-entry of data is a pain. It makes data entry messy, and dis-spiriting because of the messiness. One can't help but feel, when entering the same data two or more times, that somebody forgot to finish the program before offering it for sale.
In case anyone has heard the one about artificial intelligence... maybe it's a thing and maybe it's not. I haven't seen any evidence that this is not a bad joke or a fairy tale spurned on by scary robot movies. I'd guess that about 3/4 of the decisions that "smart" software makes for me are opposite to what I would have done, and have to be reversed at twice the effort compared to... hey, software gods, stop wasting your time playing God, and let me make my own decisions. I don't really know anything about artificial intelligence as such, but I know what smart software is: it's artificial stupidity. Nobody knows how to enter a user's family data except the user himself, especially a dumb machine.
A glance at the second table on this Wikipedia page suggests that features include stuff like this:
--views
--charts
--reports
--DNA charts
--research management/guidance
--mapping
In contrast, here at Treebard University we feel that most of these are secondary features, since we're talking about genealogy database software and none of these features address how data is stored and how the data can be manipulated. We feel that there is one primary feature for genealogy database software: getting data into a database in a way that the data can be used with great flexibility and in a way that the data accurately represents the real world circumstances that the software is ostensibly trying to record. I'll try to flesh out this remark below, in the "positivity" section, but first I should get the all-important negative remarks out of the way.
You could add import/export which is important but it's technically still a secondary feature because you can literally create a genealogy database without it. In fact, too much dependency on import/export might mean you either don't actually enjoy inputting data or else you don't want to redo work you've already done. Because your genieware makes it way too tedious. This is a valid concern, however GEDCOM appears to be a silly solution. (It's still needed but more-so it needs to be replaced by something that works well.)
To the list of features above, you could add scraping data off of websites and writing family history books, but that would be at least bordering on silly. Especially writing books. As someone who has actually written books, I'd like to suggest that the best application for writing books is the application of some good old-fashioned elbow grease.
Manipulating graphics? Since the Python module (Pillow) that Treebard's widget toolkit (Tkinter) uses allows some of this, I plan to build some graphics manipulation into Treebard, even though it's pretty darn silly when there are plenty of good dedicated graphics programs available that do it better. I have free programs GIMP, Krita, and Inkscape which I would learn to use except for the fact that the paint program I bought 25 years ago (JASC) still works so well that I'm not that motivated to switch. Incorporating graphics functionalities into Treebard is near the bottom of the do-list.
Mapping? Don't be silly. Between Google Maps, its competitors, and existing graphics software, mapping should only be offered in a genealogy program that is otherwise already finished in terms of the primary feature of genealogy database software. Trying to cover all possible bases in genieware is a waste of the developer's time. The focus of the developer should be the primary purpose of genieware: recording data accurately and usefully in a database. Until that feature is complete, the software is not finished and should not be used or sold to the public, no matter how flashily it can be represented in advertising.
Here are some details of what I mean by "the one and only primary feature of genieware".
It starts with recognizing what the elements of genealogy actually are:
--individual
--place
--event and attribute
--source and citation
--assertion and conclusion
--notes
DNA, mapping and fan charts don't belong anywhere in this list. They're offered in so many unfinished, useless programs because the developers are in a big fat hurry to sell your ancestors back to you, and an unfortunate trait of all things capitalistic is that the early bird gets the worm. That means no one has time to finish the primary feature of the program because they're too busy working on the secondary and silly features. One of the reasons that capitalism ruins everything it touches is that it forces everybody to be in a hurry. In case you haven't looked around you recently, I might mention in passing that our multitasking, rush-rush, us-against-us culture shows signs of being suicidally inept at providing us with a safe and happy home.
I'm not saying that secondary features are unimportant. I'm saying that providing them is a distraction to what should be the developers priority: the primary feature.
Some facets of the primary feature of genieware (and I want to acknowledge Mr. Tamura Jones' inspiring blog, although there's no guarantee he'd agree with everything I say):
Names of persons should be recorded accurately. Since the "first name, middle name, last name" arrangement is not pertinent to all cultures, and since it's complicated to get right in a database anyway, it should not be used in genieware. Treebard records a name as a single string like "Benjamin Plum Pudding" as well as a sorting string like "Pudding, Benjamin Plum". This way we don't have to redefine what first, middle and last names are from culture to culture. In one of the most civilized nations on earth (Iceland) there is no such arrangement for names. There should be no such restriction on name strings.
Places should be recorded as plain nested strings without any built-in jurisdictional categories like "county" or "township". Pairing each place nest with a jurisdiction is unnecessary and basically impossible to do with consistent accuracy if you research enough different places. There can be an input for these categories for those who can't live without them, but if the user is forced to pair each nested place to some preconceived category, it gets messy and there's no solution. The place names and locations are pertinent to genealogy, and the nesting is important, but you don't need to know or care about the jurisdictions to get places right. Jurisdictions should be optional.
More importantly, places must be able to have more than one parent. Smaller places like cities and towns don't get up and move across to the other side of the mountains. Even if this happened and even if the new town had the same name as the old one and the same people lived in it, it would be a different town. Localities have a pretty much fixed general location (though they can shrink and expand). But the larger place wherein a locality is nested can change all the time, and in the pioneer days, this happened all the time. Tracking county and township boundary and name changes is important to genealogy because so much research is based on where someone is living. Just because two census schedules list Samantha Jones in Dogwood County, Nebraska doesn't mean it should be the same Samantha Jones; the two places could be 300 miles apart. Each individual place needs its own ID which never changes, and a city in Texas can be nested in any number of precincts, counties or even nations. Some Texas cities we know today were once in a country called the Republic of Texas, which was not in the USA. I doubt there's more than one or two geniewares out there that make it possible for a single given place to have any number of parents. In Treebard, for each parent a place has, there's also a field in the database for the span of time during which this was true.
I'd have to guess that one reason places are over-simplified in existing genieware is that the developer, for a reason I cannot fathom, feels that he needs to pre-load the app with the world's places. This amounts to doing the researcher's hobby for him, which would have to be done badly under the circumstances. Take for example the apps that list my great grand-daddy's hometown by its zip code of all things. Sorry folks, just because it's on Google Maps don't mean it belongs in my database. Users cannot have an accurate database if it comes pre-loaded with over-simplified, rigidly nested place names from the wrong time period, and since the developer doesn't know the what or the when of my family history, the developer can't imagine what (accurate, exact) places to pre-load the app with. And I might not need 98% of the place names in the app anyway, so why are they there bloating the program?
While everyone is arguing about whether genieware should be evidence-based or conclusion-based, as usual with false dichotomies, both sides are missing the point. Evidence and conclusions are both elements of genealogy, but few if any geniewares 1) recognize that that both assertions and conclusions exist & are not the same thing, and 2) build that reality into their database structure. A conclusion is reached by the researcher based on whatever evidence that researcher feels is relevant. The evidence is woven into a source, and the researcher must decide what that source is saying, and he must be able to record, separately from his conclusion, the assertion that the source is making. But different sources will make conflicting assertions. So because current genieware doesn't recognize the difference between assertions and conclusions, we have more silliness: individuals with multiple births and deaths, for example. This isn't the researcher's fault; he's trying to enter all the information he has found, and there's no other way to give the sources and their conflicting assertions an equal opportunity to be heard except by burying a lot of unwanted prose in notes. Assertions and conclusions must be recorded separately in the database, and they cannot morph into each other. The software cannot draw conclusions. Only the researcher decides what happened way back when.
Notes have to be linkable to any number of other elements. In the past, trying to use the only genieware I ever had any affinity for, I used to write up detailed notes which would have to be copied and pasted from one person to another. This is not how software is supposed to work. It's certainly unnecessary, if the database is structured right. Double-entry of data is a pain. It makes data entry messy, and dis-spiriting because of the messiness. One can't help but feel, when entering the same data two or more times, that somebody forgot to finish the program before offering it for sale.
In case anyone has heard the one about artificial intelligence... maybe it's a thing and maybe it's not. I haven't seen any evidence that this is not a bad joke or a fairy tale spurned on by scary robot movies. I'd guess that about 3/4 of the decisions that "smart" software makes for me are opposite to what I would have done, and have to be reversed at twice the effort compared to... hey, software gods, stop wasting your time playing God, and let me make my own decisions. I don't really know anything about artificial intelligence as such, but I know what smart software is: it's artificial stupidity. Nobody knows how to enter a user's family data except the user himself, especially a dumb machine.