Post by Uncle Buddy on Dec 27, 2019 20:42:21 GMT -8
Here's something you hear a lot when shopping for genieware: "steep learning curve". In my book, a steep learning curve is an excuse for software written for computer nerds to use. Which leaves the rest of us out. Good software with lots of capabilities should be as easy to use, or easier, than bad software that barely does anything, no? This "steep learning curve" is doublespeak for software that was brought to market before the user experience problem was solved. Most of the developers' energy has been going into unnecessary bells and whistles, while the basic design of how genealogy gets done has been left to fall where it may.
The existing geniewares usually make it hard to do something simple when they should be making it simple to do something hard. For example you write a note or cite a source on an event, simple, but if you want to associate the note or source with more than one event or person, most software will not help you with that. You'll end up copy/pasting it where you want it, bloating the database with redundant information. A slightly more sophisticated database behind the scenes, and a developer who has put some thought into how easy this could be made for the user to accomplish, would make it simple to link the same note or citation to any number of entities. On this blog/forum I'll go into more detail on what should and should not be important to developers. I've tried dozens of geniewares and I won't use any of them, and I'm happy to report that there is a solution: write a better program. Treebard's purpose is to show functionalities which could be incorporated into a better program. It's not about my code. I'm an amateur Python coder, a novice. It's about the user experience and the kind of genealogy that could more easily be done with newly re-considered genieware features.
Treebard is not about next year's model because its main goal is to make it fun and easy to create an accurate and detailed database about a family tree. Instead of its primary purpose being to get a product to market before the market's tastes change again. So the project is a demo model, a set of user-experience patterns for developers to simulate, thus the 'GPS' after Treebard's name: 'Genieware Pattern Simulation'. Because Treebard is not made for daily use, but to demonstrate desirable functionalities, I can ignore the big distractions such as GEDCOM and DNA which take precedence over the basics when developers are pushing to get a product to market.
In software development, a pattern is a way of designing code structures, but the patterns I'm talking about, since I'm a novice coder, are ease-of-use patterns that users will love whether they know what they are or not. Treebard is made to be loved by everyone who loves genealogy, especially those who know little about computers. With the needs of genealogy and the needs of genealogists placed at the top of Treebard's priority list, there's no rent or salaries to pay, no advertising to do. Nothing wrong with having a great product to sell, but in genieware, no one has that great product yet. Current genieware is all about the product, not the genealogy, so those products don't cut the mustard.
The generic reason that genieware developers have failed to create the ultimate, universally appealing database tool is that computerized genealogy hasn't finished growing up yet. There are a lot of little problems piled at the feet of a developer that aren't his fault: GEDCOM being inadequate and out-of-date, popular websites lowering the bar by making it easy and natural to do bad genealogy, there's no end of distractions and things to complain about.
But I don't have time to complain because writing Treebard is too much fun.
The existing geniewares usually make it hard to do something simple when they should be making it simple to do something hard. For example you write a note or cite a source on an event, simple, but if you want to associate the note or source with more than one event or person, most software will not help you with that. You'll end up copy/pasting it where you want it, bloating the database with redundant information. A slightly more sophisticated database behind the scenes, and a developer who has put some thought into how easy this could be made for the user to accomplish, would make it simple to link the same note or citation to any number of entities. On this blog/forum I'll go into more detail on what should and should not be important to developers. I've tried dozens of geniewares and I won't use any of them, and I'm happy to report that there is a solution: write a better program. Treebard's purpose is to show functionalities which could be incorporated into a better program. It's not about my code. I'm an amateur Python coder, a novice. It's about the user experience and the kind of genealogy that could more easily be done with newly re-considered genieware features.
Treebard is not about next year's model because its main goal is to make it fun and easy to create an accurate and detailed database about a family tree. Instead of its primary purpose being to get a product to market before the market's tastes change again. So the project is a demo model, a set of user-experience patterns for developers to simulate, thus the 'GPS' after Treebard's name: 'Genieware Pattern Simulation'. Because Treebard is not made for daily use, but to demonstrate desirable functionalities, I can ignore the big distractions such as GEDCOM and DNA which take precedence over the basics when developers are pushing to get a product to market.
In software development, a pattern is a way of designing code structures, but the patterns I'm talking about, since I'm a novice coder, are ease-of-use patterns that users will love whether they know what they are or not. Treebard is made to be loved by everyone who loves genealogy, especially those who know little about computers. With the needs of genealogy and the needs of genealogists placed at the top of Treebard's priority list, there's no rent or salaries to pay, no advertising to do. Nothing wrong with having a great product to sell, but in genieware, no one has that great product yet. Current genieware is all about the product, not the genealogy, so those products don't cut the mustard.
The generic reason that genieware developers have failed to create the ultimate, universally appealing database tool is that computerized genealogy hasn't finished growing up yet. There are a lot of little problems piled at the feet of a developer that aren't his fault: GEDCOM being inadequate and out-of-date, popular websites lowering the bar by making it easy and natural to do bad genealogy, there's no end of distractions and things to complain about.
But I don't have time to complain because writing Treebard is too much fun.