Post by Uncle Buddy on May 25, 2022 17:22:17 GMT -8
According to this video (which is outdated but might still be generally accurate), Gramps lets each single place have multiple parents, or as it's said in the video, "enclosing places". For each place, its span of existence can be entered.
The example I always use is any city in Texas which already existed when Texas was the Republic of Texas and not a state in the USA. According to this video, if you enter an event and say it happened in the city of Dallas, the nested place will be displayed as either "Dallas, Texas, USA" or "Dallas, Republic of Texas" depending on when the event took place.
Bravo to Gramps for doing something sensible with places. Multiple enclosing places/parents are essential to accuracy, and I believe this feature is missing from almost all the genieware out there.
I'm not sure I agree with auto-selecting a nested string to associate with an event based on the date. For one thing, what if the event is undated? Which nesting is going to be selected by the program? I should research this on my own by opening up the newest version of Gramps and seeing what it does. My point is that when a developer goes down the road of building chains of logic that make the user's decisions for him, there are going to be problems that the user didn't cause himself. The user will end up on some forum asking what to do about it, instead of being able to just enter his input the way he'd like to see.
Places are a huge topic. For the genieware to make any decisions about them is a big risk, because there's too much to know about too many places. The road doesn't have many branches, it has infinite branches. Better to not start down that road. (Including pre-loading the app with any places at all. The places that the user enters should be available for all his trees, but he should be the one to enter them, not the developer of the app.)
Gramps also uses jurisdiction levels, which can also be seen in this video where it causes the video's creator some consternation twice. He's being asked to say whether a "German" or "Danish" place is a county or a nation or
This is irrelevant to genealogy, and hopefully the use of this feature is completely optional in Gramps. I have to open the program and see for myself. This part of the world has been broken up into so many different nations over the centuries, you might say it's been owned by everyone from Tom to Jerry. Problem is, USA-centric jurisdiction levels are not relevant when you're researching old European places. Philippines jurisdicion levels aren't relevant when you're studying places in Tibet. Tibetan jurisdiction labels are meaningless in Finland, and I wouldn't be a bit surprised to learn that Icelandic jurisdictions are just so much babble in Greenland.
The solution is to not build any jurisdiction levels into genieware at all; to give the user a field he can fill in himself with any jurisdiction label he wants; and to base no logic on these levels whatsoever, making this field completely optional. It's basically there to placate those genealogists who want to count the hairs on the heads of the dead, and no doubt there are plenty of those, so let's give them what they want but put them in control of it instead of trying to control something we will never get right in a million years. Even a GEDCOM specification I've seen admits that this field is superfluous and was added only because so many geniewares use it for some reason. I think the GEDCOM spec used the phrase "too much detail" and I agree with that.
In contrast to Gramps' click-heavy place input routine, Treebard opens a dialog which I will try to describe from memory since I haven't worked on this feature in a long time. The dialog is a New and Duplicate Places dialog.
In Treebard, you enter a nested place as a string, e.g. "Paris, Lamar County, Texas, USA". You enter the whole string with nests separated by a comma. If the string is already in the database, it will autofill so you don't have to retype more than a few characters in most cases. The most recent match will fill in first, instead of the suggestions coming in alphabetical order. If there are no places in the database called "Paris", the data goes straight in. (This is from memory. I need to do a video on it for the YouTube tour. What really happens I think is a bit more complicated.)
But if there's already one or more places called "Paris" in the database, the dialog will always open. Why always? Because Treebard doesn't insult its users by guessing. "Smart" software is a big pain in the behind about 65.17% of the time. All software is stupid. The user is trying to be smart, and he might hopefully succeed if the software he's trying to use isn't in competition with him. I've had to try and go back and fix things up after a tree which came loaded with "Paris, France" didn't have any way to differentiate that place from "Paris, Texas." The genieware pretended to be easy by not opening a dialog for duplicate place delineations, and in the end it was harder than it should have been since so many mistakes snuck in silently.
The dialog lists all the places named "Paris" and all their known parent places. While creating this feature I entered about 32 places named Paris, so the dialog has a scrollbar. For every nest in the input place, the user has a choice of creating a new place or selecting any of the existing places by the same name. We go by exact spellings only. If the user entered "Parris", the dialog for Paris would never open.
I'll have to make a video tour of this feature since it's hard to describe from memory. It doesn't try to do everything, but it does also include a field where the user can optionally input a hint for each place to help him know instantly which "Israel" he's talking about. There's also a place tab where the user can display all the details for any existing place, or create new places in advance of using them. Here a span of dates could be input, for example, during which a place had a certain parent or a certain name variant.
One of my main goals with Treebard is to provide a GUI that looks simple and does the detail work in the background. A GUI like Gramps' which looks techy and overly detailed and not particularly intuitive will appeal to some people. Since I propose Treebard's underlying data structure as an outright replacement for GEDCOM (i.e. a data structure that all genieware products could use in common), in order to try to get that point across, I have to pair up this data strucure with a GUI that the noobiest of noobs would not find intimidating. Since Treebard is completely un-owned and absolutely in the public domain, licensed only by the Unlicense, anyone can build their own GUI on top of my data structure and call it anything they want, with or without acknowledging me and/or paying optional, voluntary "royalties". I mean, donations. Because I won't ever sign a contract regarding Treebard, so you won't have to either, in order to use some part of it for your own project.
I can't end this post about Gramps without asking why I haven't given Gramps a dark background yet, so I can actually look at it, and so I can actually look forward to looking at it. Could it be that the dark theme option doesn't exist, is only partially able to change backgrounds, or is hard to use? Maybe I'll make a video about that too.
The example I always use is any city in Texas which already existed when Texas was the Republic of Texas and not a state in the USA. According to this video, if you enter an event and say it happened in the city of Dallas, the nested place will be displayed as either "Dallas, Texas, USA" or "Dallas, Republic of Texas" depending on when the event took place.
Bravo to Gramps for doing something sensible with places. Multiple enclosing places/parents are essential to accuracy, and I believe this feature is missing from almost all the genieware out there.
I'm not sure I agree with auto-selecting a nested string to associate with an event based on the date. For one thing, what if the event is undated? Which nesting is going to be selected by the program? I should research this on my own by opening up the newest version of Gramps and seeing what it does. My point is that when a developer goes down the road of building chains of logic that make the user's decisions for him, there are going to be problems that the user didn't cause himself. The user will end up on some forum asking what to do about it, instead of being able to just enter his input the way he'd like to see.
Places are a huge topic. For the genieware to make any decisions about them is a big risk, because there's too much to know about too many places. The road doesn't have many branches, it has infinite branches. Better to not start down that road. (Including pre-loading the app with any places at all. The places that the user enters should be available for all his trees, but he should be the one to enter them, not the developer of the app.)
Gramps also uses jurisdiction levels, which can also be seen in this video where it causes the video's creator some consternation twice. He's being asked to say whether a "German" or "Danish" place is a county or a nation or
This is irrelevant to genealogy, and hopefully the use of this feature is completely optional in Gramps. I have to open the program and see for myself. This part of the world has been broken up into so many different nations over the centuries, you might say it's been owned by everyone from Tom to Jerry. Problem is, USA-centric jurisdiction levels are not relevant when you're researching old European places. Philippines jurisdicion levels aren't relevant when you're studying places in Tibet. Tibetan jurisdiction labels are meaningless in Finland, and I wouldn't be a bit surprised to learn that Icelandic jurisdictions are just so much babble in Greenland. The solution is to not build any jurisdiction levels into genieware at all; to give the user a field he can fill in himself with any jurisdiction label he wants; and to base no logic on these levels whatsoever, making this field completely optional. It's basically there to placate those genealogists who want to count the hairs on the heads of the dead, and no doubt there are plenty of those, so let's give them what they want but put them in control of it instead of trying to control something we will never get right in a million years. Even a GEDCOM specification I've seen admits that this field is superfluous and was added only because so many geniewares use it for some reason. I think the GEDCOM spec used the phrase "too much detail" and I agree with that.
In contrast to Gramps' click-heavy place input routine, Treebard opens a dialog which I will try to describe from memory since I haven't worked on this feature in a long time. The dialog is a New and Duplicate Places dialog.
In Treebard, you enter a nested place as a string, e.g. "Paris, Lamar County, Texas, USA". You enter the whole string with nests separated by a comma. If the string is already in the database, it will autofill so you don't have to retype more than a few characters in most cases. The most recent match will fill in first, instead of the suggestions coming in alphabetical order. If there are no places in the database called "Paris", the data goes straight in. (This is from memory. I need to do a video on it for the YouTube tour. What really happens I think is a bit more complicated.)
But if there's already one or more places called "Paris" in the database, the dialog will always open. Why always? Because Treebard doesn't insult its users by guessing. "Smart" software is a big pain in the behind about 65.17% of the time. All software is stupid. The user is trying to be smart, and he might hopefully succeed if the software he's trying to use isn't in competition with him. I've had to try and go back and fix things up after a tree which came loaded with "Paris, France" didn't have any way to differentiate that place from "Paris, Texas." The genieware pretended to be easy by not opening a dialog for duplicate place delineations, and in the end it was harder than it should have been since so many mistakes snuck in silently.
The dialog lists all the places named "Paris" and all their known parent places. While creating this feature I entered about 32 places named Paris, so the dialog has a scrollbar. For every nest in the input place, the user has a choice of creating a new place or selecting any of the existing places by the same name. We go by exact spellings only. If the user entered "Parris", the dialog for Paris would never open.
I'll have to make a video tour of this feature since it's hard to describe from memory. It doesn't try to do everything, but it does also include a field where the user can optionally input a hint for each place to help him know instantly which "Israel" he's talking about. There's also a place tab where the user can display all the details for any existing place, or create new places in advance of using them. Here a span of dates could be input, for example, during which a place had a certain parent or a certain name variant.
One of my main goals with Treebard is to provide a GUI that looks simple and does the detail work in the background. A GUI like Gramps' which looks techy and overly detailed and not particularly intuitive will appeal to some people. Since I propose Treebard's underlying data structure as an outright replacement for GEDCOM (i.e. a data structure that all genieware products could use in common), in order to try to get that point across, I have to pair up this data strucure with a GUI that the noobiest of noobs would not find intimidating. Since Treebard is completely un-owned and absolutely in the public domain, licensed only by the Unlicense, anyone can build their own GUI on top of my data structure and call it anything they want, with or without acknowledging me and/or paying optional, voluntary "royalties". I mean, donations. Because I won't ever sign a contract regarding Treebard, so you won't have to either, in order to use some part of it for your own project.
I can't end this post about Gramps without asking why I haven't given Gramps a dark background yet, so I can actually look at it, and so I can actually look forward to looking at it. Could it be that the dark theme option doesn't exist, is only partially able to change backgrounds, or is hard to use? Maybe I'll make a video about that too.