Genes feature wish list...

• Allow the user to create any arbitrary number of application databases. The user may be researching completely separate families.
• Allow the user to enter data into text fields of an arbitrary length. The user will always find some data that runs beyond the length of the field.
• Everything that can happen to a person (e.g. birth, marriage, death) is an event. Allow multiple instances of every event, including birth and death to enable the user to record conflicting data found during research.
• Everything that can describe a person in discrete terms that does not necessarily involve a date (e.g. military service yes/no) is an attribute.
• Automatically rule out impossible or extremely unlikely attributes.
  • Died before turning 10 == no marriage (probably) == no children
  • Born after attribute time period == no to that attribute
  • Died before attribute time period == no to that attribute
  • Born more than 75 years before an attribute == no to that attribute
  • Died more than 75 years after an attribute == no to that attribute
• Almost never set an attribute to Yes automatically
• Mark automatically-assigned attributes like those above. Make it easy to pick out which attributes have not been proven
• Allow the user to create event or attribute types.
• Make some data entry forms look that like the reports (e.g. Family Group Sheet or pedigree) for easy input.
• Incorporate census data into the application database.
• Allow each event or attribute to be referenced in multiple sources.
• Include a default surety level for each event and attribute, but let the user decide the range of sureties. The surety range should be a global option.
• Allow the user to specify if he wants to open a person's record by default upon starting the program. Also, along the same lines, allow the user to specify which person's record to open by default.
• Allow searching on almost every field in the database. Start with person names and record numbers, expand to places, then to dates and finally attributes.
• Provide a way for the user to link an arbitrary number of photos to any person's record. These photos should not be stored in the database, but their location on the user's hard drive should. The user should be given the option of storing the photo in a location of the application's choosing or any arbitrary location the user wants. The user should be able to instantly spawn a photo viewer from the person's record.
• Allow the user to associate any arbitrary number of person records to a photo. This would be helpful for group shots where more than one person in the database is included in the photo. It would be nice if there were a way to store the person's location in the photo (e.g. third person in the top row) in the database as well and have the viewer highlight the person's image in the photo, but this would not be practical yet. If nothing else, there should be a field for the user to specify the person's location in the photo as noted previously.
• Include a "search by example" where the user can specify criteria for multiple fields at once and the program will combine the criteria in an "and" combination when searching the database.
• Provide a calculation for elapsed time. Many death records (like obituaries or tombstones) will say that a person lived to be X years and Y days old. The program should automatically calculate either birth or death based on this elapsed time, but allow the user to override and input his own data (the physical record could always be wrong).
• Every source record should have a repository and/or last referenced date.
• Need to provide a way to list adoptive parents as well as birth parents.
• Allow the user to enter partial dates (any combination of month/day/year) Also allow the user to enter date qualifiers (e.g. before, after, circa or a possible date range). Also, allow the user to enter a double date for the period when two calendars where in use and January through March could be in either of two years (but never assume which if the user only supplies one of the two years).
• Provide different data fields for resources depending on the type of resource that was referenced. A book will have, typically, a page number while a personal letter will have a sender's name.
• Store place names in separate tables and link to place name records in person records. This will help avoid data duplication, reducing the size of the application database, and also help avoid spelling mistakes.
• Create an autofill feature where the user need only enter a few characters of a name and hits a key to autofill the rest of the record.

Reports wish list...

• Family Group Sheet. Can have multiple styles like the different styles of hard copy forms available to the researcher.
• Pedigree. Either forward or reverse.
• Ahnentafel. Either forward or reverse.
• Names and/or Places Lists
• Biography
• Family History. The program attempts to write the database in book form. This should probably only export to a text or word processing file to prevent the user from accidentally sending a 2000-page report to the printer with no easy way to stop it.
• Blank Forms. Should at least include FGS and Pedigree. Should also write forms for census information.
• All reports should include the option to print to file rather than to the printer directly.

Import/Export wish list...

• GEDCOM import and export. This import is planned to be one of the first features implemented. Need to provide a way for the application to merge information on the same person (if the person is already in the database but is included in the GEDCOM file as well, we should put the person's data into the person's existing record rather than create a new person record).
• Read and display a GEDCOM file
• Import and export from/to other application databases. This is a bit more difficult, but there should be a way to do it.

These are all that I have at the moment. If there's a feature that you want to see in the program, please email me.