Post by Uncle Buddy on Jun 30, 2020 1:35:44 GMT -8
Treebard is unique in that it keeps assertions and conclusions separate forever. Assertions have to be linked to a source. Conclusions can be linked to an assertion but this is optional. This allows the source to be theoretical or whatever.
In the events table on the person tab, the last column on the right shows how many sources are linked to that event. Clicking the button opens the assertions for that event. So the events shown on the person tab are really conclusions, and to see what you based the conclusions on, you click the sources tab. This is a simple system that works for everybody including that rare genealogist who tracks none of his sources (that was a sarcastic slam, sorry). The point being, a genieware which forces people to track their sources in some certain way will never catch on.
The fields in the events table are active. They can be typed into. As soon as you leave the field, what you typed goes straight into the database. If you enter a new event in the bottom row, it stays there until you click Save, then it will be interfiled in the right part of the table by date.
Age and date fields are independent, they don't have to agree. I thought about making one calculate from the other but you can't force the records to conform to your expectation. We have to keep track of what the records actually say, not what we wish they would say.
All the screenshots so far show a good-sized font which results in the app covering most of my computer screen. I haven't written the code yet to change the size of the font. Well I did once but that was an earlier reincarnation of Treebard. If you like to see tiny dialogs with teeny letters and shiny white backgrounds, this is easy to do in Treebard but not the default. I'll have it set up to show letters I can see on a background that doesn't blind me, and users can change it to look how they want.
Another reason this simple interface covers the computer screen is that I don't like resizable columns. They should be used when the amount of data is too large for the space where it will be displayed. Instead, what happens is that a developer doesn't provide enough space for the kind of data being displayed, then sweeps this design deficit under the rug by providing resizable columns where they shouldn't be needed. I have a popular genieware somewhere on my computer that opens up in an unreadable state. To read each column, you have to resize it. Then you have to resize another column to read that. This is only necessary because there's too much going on in one view.
But Treebard opens up showing the basic snapshot of a person: name, events, pedigree, photo, attributes. Other things are on other tabs. This allows me to use fonts that I can read. What would you think of an interior decorator who crammed too much furniture into a room and put wheels on it all, instructing you to move aside the chairs you weren't currently sitting in? That's how I feel about resizable columns. Treebard won't use them. When you are reading something, you should be able to read the whole thing without wearing out your mouse hand. I don't know why people who despise horizontal scrolling put up with resizable columns. In computery geekish applications, like a file directory or a data table that needs more space than it will ever have, resizable columns are appropriate. Resizable columns in genieware are for designers who have skimmed over some design decisions. Genieware doesn't have to be data-esque and geekish. It should honor our ancestors' humanness by being beautiful and sweet, like a well-designed home interior that is about people. Instead of focusing on the computer and the application and the data-ness of it all.
The events table is sorted by date with the exception of birth, death and burial events which are always positioned in the right place. Undated events will show right below birth but if it was me, I'd assign an estimated or approximate date to all events on the conclusion table so that they are in about the right part of the table. An estimated date is your best guess based on common sense. An "about" date is based on a source. That's how I tell "est" dates and "abt" dates apart, I don't know how others do it. Dates can be entered as ranges (btwn Jan 1860 and Feb 1860) by typing "1 1860 and 1860 2". Treebard knows what that's supposed to mean and reformats it according to your preference settings. Dates can be entered as spans (from 1900 to 1910) by typing "1910 to 1900". Treebard will fix it and display it in the right order. One of the dates in a span can be a question mark: entering "? to 1 18 1845" will display "from ? to 18 Jan 1845" in your preferred format.
I've worked literally for months to make a date validation procedure that will allow you the kind of flexibility hinted at above. Entering "1 1 1" will automatically display "January 1, 1 AD" in your preferred format. Entering "1 2 3" will open a clarification dialog so Treebard can ask you which is day, which is month, and which is year. But entering "ja 2 0003" will prevent the clarifier from bothering you. "Apricot"--even if you mis-spell it, as long as it starts with "ap" and is typed into a date field--will be interpreted as "April". To get a "September" out of Treebard, you can type an "s" into a date field or you can type "sylvester" into a date field. Either way, it will be displayed as September, Sept, or 9, whatever you prefer.
No, change that. You can enter a month as a numeral but they won't display that way. You can choose to display a month as Sept or Sept. or September but not as 9. The reason for this restriction is that Treebard is for sharing and sharing between continents will confuse people if they use numerals for months. But enter dates as numbers if you want.
The input fields in the events table are read-only till you click them. The user won't be aware of this, but it keeps the data from being accidentally changed when you fall asleep on the keyboard. If you don't thrash around too much in your sleep, your data is safe. If you click in a field but tab out without changing anything, Treebard doesn't waste its energy re-validating the data. If you do change something, the data is re-validated. For example in date fields, no bad dates are allowed. It's not possible to enter a bad date in Treebard.
Having the input fields read-only till you click in them or tab into them is also a good way to keep the data from changing if you look at it cross-eyed. I'm not really kidding. Data is input to the database when you tab out of a field. If you're tabbing through the table, you don't want to hit the database every time you hit tab. The fields are built to know what they contain, so tabbing out doesn't trigger a validation or database entry event if the contents of the field were not changed.
Place fields will automatically fill in with recently used places that start with the same letters you're typing. This is the first functionality I wrote in my current project when I started this phase about two years ago. The Particulars field is for details, short notes. The Kin field fills in automatically with the spouse's name for couple events such as wedding or divorce. If you create a couple event, it will automatically appear on the spouse's events table, you don't have to do it twice. If you create a birth event, the Kin field will automatically show the parents' names if known. For each parent an offspring event will automatically appear on their events table with the name of the child in the Kin field.
I'm currently working on getting input from the events table in and out of the database. This is taking forever and has generated several dialogs and functionalities shown in some of the other screenshots. I'm looking forward to moving on to the next phase which I suppose is to tackle relationships, pedigree charts and the like. That should be tricky.
In the events table on the person tab, the last column on the right shows how many sources are linked to that event. Clicking the button opens the assertions for that event. So the events shown on the person tab are really conclusions, and to see what you based the conclusions on, you click the sources tab. This is a simple system that works for everybody including that rare genealogist who tracks none of his sources (that was a sarcastic slam, sorry). The point being, a genieware which forces people to track their sources in some certain way will never catch on.
The fields in the events table are active. They can be typed into. As soon as you leave the field, what you typed goes straight into the database. If you enter a new event in the bottom row, it stays there until you click Save, then it will be interfiled in the right part of the table by date.
Age and date fields are independent, they don't have to agree. I thought about making one calculate from the other but you can't force the records to conform to your expectation. We have to keep track of what the records actually say, not what we wish they would say.
All the screenshots so far show a good-sized font which results in the app covering most of my computer screen. I haven't written the code yet to change the size of the font. Well I did once but that was an earlier reincarnation of Treebard. If you like to see tiny dialogs with teeny letters and shiny white backgrounds, this is easy to do in Treebard but not the default. I'll have it set up to show letters I can see on a background that doesn't blind me, and users can change it to look how they want.
Another reason this simple interface covers the computer screen is that I don't like resizable columns. They should be used when the amount of data is too large for the space where it will be displayed. Instead, what happens is that a developer doesn't provide enough space for the kind of data being displayed, then sweeps this design deficit under the rug by providing resizable columns where they shouldn't be needed. I have a popular genieware somewhere on my computer that opens up in an unreadable state. To read each column, you have to resize it. Then you have to resize another column to read that. This is only necessary because there's too much going on in one view.
But Treebard opens up showing the basic snapshot of a person: name, events, pedigree, photo, attributes. Other things are on other tabs. This allows me to use fonts that I can read. What would you think of an interior decorator who crammed too much furniture into a room and put wheels on it all, instructing you to move aside the chairs you weren't currently sitting in? That's how I feel about resizable columns. Treebard won't use them. When you are reading something, you should be able to read the whole thing without wearing out your mouse hand. I don't know why people who despise horizontal scrolling put up with resizable columns. In computery geekish applications, like a file directory or a data table that needs more space than it will ever have, resizable columns are appropriate. Resizable columns in genieware are for designers who have skimmed over some design decisions. Genieware doesn't have to be data-esque and geekish. It should honor our ancestors' humanness by being beautiful and sweet, like a well-designed home interior that is about people. Instead of focusing on the computer and the application and the data-ness of it all.
The events table is sorted by date with the exception of birth, death and burial events which are always positioned in the right place. Undated events will show right below birth but if it was me, I'd assign an estimated or approximate date to all events on the conclusion table so that they are in about the right part of the table. An estimated date is your best guess based on common sense. An "about" date is based on a source. That's how I tell "est" dates and "abt" dates apart, I don't know how others do it. Dates can be entered as ranges (btwn Jan 1860 and Feb 1860) by typing "1 1860 and 1860 2". Treebard knows what that's supposed to mean and reformats it according to your preference settings. Dates can be entered as spans (from 1900 to 1910) by typing "1910 to 1900". Treebard will fix it and display it in the right order. One of the dates in a span can be a question mark: entering "? to 1 18 1845" will display "from ? to 18 Jan 1845" in your preferred format.
I've worked literally for months to make a date validation procedure that will allow you the kind of flexibility hinted at above. Entering "1 1 1" will automatically display "January 1, 1 AD" in your preferred format. Entering "1 2 3" will open a clarification dialog so Treebard can ask you which is day, which is month, and which is year. But entering "ja 2 0003" will prevent the clarifier from bothering you. "Apricot"--even if you mis-spell it, as long as it starts with "ap" and is typed into a date field--will be interpreted as "April". To get a "September" out of Treebard, you can type an "s" into a date field or you can type "sylvester" into a date field. Either way, it will be displayed as September, Sept, or 9, whatever you prefer.
No, change that. You can enter a month as a numeral but they won't display that way. You can choose to display a month as Sept or Sept. or September but not as 9. The reason for this restriction is that Treebard is for sharing and sharing between continents will confuse people if they use numerals for months. But enter dates as numbers if you want.
The input fields in the events table are read-only till you click them. The user won't be aware of this, but it keeps the data from being accidentally changed when you fall asleep on the keyboard. If you don't thrash around too much in your sleep, your data is safe. If you click in a field but tab out without changing anything, Treebard doesn't waste its energy re-validating the data. If you do change something, the data is re-validated. For example in date fields, no bad dates are allowed. It's not possible to enter a bad date in Treebard.
Having the input fields read-only till you click in them or tab into them is also a good way to keep the data from changing if you look at it cross-eyed. I'm not really kidding. Data is input to the database when you tab out of a field. If you're tabbing through the table, you don't want to hit the database every time you hit tab. The fields are built to know what they contain, so tabbing out doesn't trigger a validation or database entry event if the contents of the field were not changed.
Place fields will automatically fill in with recently used places that start with the same letters you're typing. This is the first functionality I wrote in my current project when I started this phase about two years ago. The Particulars field is for details, short notes. The Kin field fills in automatically with the spouse's name for couple events such as wedding or divorce. If you create a couple event, it will automatically appear on the spouse's events table, you don't have to do it twice. If you create a birth event, the Kin field will automatically show the parents' names if known. For each parent an offspring event will automatically appear on their events table with the name of the child in the Kin field.
I'm currently working on getting input from the events table in and out of the database. This is taking forever and has generated several dialogs and functionalities shown in some of the other screenshots. I'm looking forward to moving on to the next phase which I suppose is to tackle relationships, pedigree charts and the like. That should be tricky.
Attachments:
