Features That I Would Like in TMG

Lee H. Hoffman

Some of the features that I would like to see added to TMG are (not in any order):

1. Allow for output of non-Primary relationships.
2. Show family numbering for persons born/raised in other countries.
3. Provide for a Last-Edited Date at the Tag level.
4. Include the ability to output the results of a Check for Duplicate People. 
5. Allow Source Types to be Grouped.
6. Provide for bibliographies of unpublished sources to be printed in largest to smallest place information (e.g., country, state, county, city, detail) as suggested in “Evidence!”.
7. Change Place Styles to have a Style ID# or name which may be entered as a Place Attribute. 
8. When Tasks are attached to a Tag with Witnesses, show the Witnesses in the Task. 
9. Provide for “Negative” Years in Dates. 
10. Provide an EOL (End-of-Line) Designator.
11. Provide Backup File Path Separate from the Backup File Name.
12. Provide for a "Keystroke/Event" Log.
13. Allow the Research Log and the Exhibit Log to be separate independent Windows.
14. Store ALL Logs, Error Reports, etc. in the Logs Folder. 
15. Ask if user wishes to open a created Log file.  
16. Add a Privacy Flag.
17. Add a New Sentence Variable for Roles.
18. Add a New Sentence Variable for Surnames.
19. Provide access to an event by Event Number or never display the number.
20. Provide a Next Page Printer Code.
21. Add Start Year/End Year to the MPL Picklist (from [F2]).
22. Provide a method of locking/un-locking projects by computer.
23. Creation of New or Revision of Current Reports. 

Many of these are nice to have while others would be of greater benefit to all users.  Some can be partially implemented now by the user, but most need to be implemented through updates or new versions of TMG.  In fact, a few of these may require a major design change of TMG   The list is no particular order except I put most report-type wishes into one and put that at the end.  Again, those report-type wishes are in no particular order. 

Many or even all of these may already be on the Wishlist at Wholly Genes Software for possible implementation in some future version of TMG.  Note that these are just my personal wishlist and has no official standing with Wholly Genes. Some items may never be implemented or even should not be implemented (at least in the way I suggest here).  As I think of other items or changes to these, I may update this list.  Again, this is my wishlist and does not necessarily mean that others would like the same items or the way I suggest implementation although most are the result of some discussion among users (including beta testers) and/or Wholly Genes staff. 

These proposals then are based on my view as to how they might be implemented.  But there may be other and better ways of implementation which would accomplish the same thing.  A few items here could only be implemented in TMG if others here were not – at least in the present description. 

The items listed above are each discussed below:

1. Allow for output of non-Primary relationships.  Currently, a user may employ various “work-arounds” to include adoptive/step/foster relationships, but those are very awkward and not understood easily by newer users.  Further, new users of TMG usually do not understand why the non-biological relationships (when non-Primary) do not print when the Tag shows the relationship and, when Primary, do not include the type of relationship.  This provision should follow the recommendations given by the National Geographic Society (NGS)[1] and/or others in the genealogy community. 

One possible method of doing this might be to provide for two Sentences for each Relationship Tag – one for the parent and one for the child.  Like Name Tags, the Sentences would not be active (e.g., would not print) if the Tag was Primary for a child’s parent (e.g., already provided for).  The parent Sentence might be something like “Jane Doe was the adoptive mother of John Smith.”  For non-Primary parent Relationship Tags, the child sentence might be like “John Smith was the adoptive son of Jane Doe.”  This might require some additional Variables: 

• The parent.
• The child.
• The relationship type, i.e., biological, adoptive, step, foster, etc.

And maybe another to indicate the relationship (father, mother, son, daughter, and unknown) – tied to which “end” of the Tag is the Focus.

In addition, the user should have control regarding whether to print or not print these non-Primary Relationship Tags/Sentences.  This option could be in the Report Definition ([_] Include non-Primary Relationships) for global control, and through the use of Exclusion Markers for Local Sentences.

Finally, when a non-biological Relationship Tag is Primary then there needs to be some way to indicate the relationship type in reports.  For example, in the Journal Narrative (Descendants), when the parent is the focus, the children paragraph(s) needs to be specific regarding the type of relationship (adoptive, step, foster, etc.).  This may be nothing more than including the relationship type following the child’s name (e.g., adoptive son, step daughter, etc.), or it could be a separate paragraph showing the relationship type in the paragraph lead sentence – like ”The adoptive children of…” or “The foster child of .…”

This provision would allow true family histories to be produced rather than just genealogies or genealogies that are “faked” in order to include relationships that are not biological.  Many people with adoptive children just do not understand why their adoptive child or grandchild is not listed with their other biological (grand)children.  Explanations are given, but the child is their child, period, and they refuse to accept any other viewpoint.  If the report is edited to show the child (thus “faking” the report by changing the non-Primary Relationship to Primary or other means) then they are fine – even if “adopted,” “step,” etc. is included in connection with the child.

2. Show family numbering for persons born/raised in other countries.  The NGS numbers ancestors and descendants in different ways when a line spans travel from one nation to another. This is most easily seen by a change in the way individuals (ancestors or descendants) are numbered in the back references.  In such cases, the back reference generation numbers would be numeric for alphabetic for ancestors that lived in some other country and numeric for ancestors living in the current country.  Thus the back reference would “count down” ancestors to “1” being the first ancestor dying in the current country and then “count up” alphabetically for ancestors that only lived in another country.

TMG would thus “require” that all places have an entry in the Country place field.  This might be excluded to prevent printing as desired by the user.  But TMG would keep track of the “beginning” country for a report and then when the country changed then the numbering system would change.  Another method would be to have a standard Flag (say an “Old Country” Flag) which would be set to “?” until the user sets it as appropriate so that TMG would know to change from alphabetic designations to numeric designations. 

3. Provide for a Last-Edited Date at the Tag level.  This would assist the user by letting them know what work was done when.  This may help in analysis of the research by permitting the user to see the data for a person in the order the data was entered (probably close to when acquired).   It could also allow the use to produce reports of the details of the data entered on a specific date.  This may be helpful in data analysis and in data recovery after a crash.

One downside of this is that the size of the project files would increase.  For a small, one data set project, the increase would not be that significant.  But, a large (say 50,000 person) data set might increase by three megabytes.  In either case, the increase in size would not be all that bad considering the sizes of today’s hard drives.  

But the other negative aspect of this provision is that the program speed might decrease.  How much it would decrease is not known.  It probably would not be a great decrease in speed, but it may be significant enough to be noticeable.  For this reason, it might be that the provision be made optional to the user via Preferences.  If the option is made, a new project should default to the provision until the user "turns it off."  Also, the option would be applicable to all data set in a project.

4.  Include the ability to output the results of a Check for Duplicate People.  The “Check for Duplicate People” (CFDP) feature is one of the more powerful features in TMG.   It can help user discover when people have been entered more than once under different names or relationships.  The problem is that the result of a CFDP is a very long list of persons.  One could easily have hundreds or thousands of candidate pairs making it hard to see the candidate pairs that are truly duplicates.  If the user had the ability to see the candidate pairs on paper and/or in a file that could be sorted in various ways then true duplicates could be found more easily.  It is recognized that such a file may only be accurate

5. Allow Source Types to be Grouped.  This would be different than as currently given although similar and would replace Source Categories.  Currently, there are three groups (Source Categories) – Lackey, Mills, and a third group which is just user-created Custom Source Types based on one of the other two.  Most users select (usually by default on installation) the Custom Source “Category” and then (again, usually by default) Initialize to Mills or Lackey.  Following this, they can add, change, or delete Source Types as desired.  With some minor exceptions and one major exception, the Mills and Lackey Source Categories create the same citations.  They may have slightly different designs, but mostly they are the same.  The major difference between Mills and Lackey is in the handling of places for unpublished documents (Mills reverses the output – see the next requested item).  By grouping, the user would define how a Source Type would be handled – as Lackey, as Mills, as some other group, etc.  TMG would come “standard” with the Mills and Lackey groups pre-defined and the user could add new group definitions.  Possible other groups might be Source Types created for other countries or other style manuals.  These other groups would likely be designed by users and might be released to Wholly Genes for distribution with later versions.

6. Provide for bibliographies of unpublished sources to be printed in largest to smallest place information (e.g., country, state, county, city, detail) as suggested in “Evidence!”.  The purpose of the large to small sequencing is that places are grouped together making it easier for researchers to find documents.  Currently, the unpublished sources are sorted by places but in the small to large order making it more difficult for researchers to find items from the same place.  In other words, Repository Addresses would print as “Country, State, County, City, Detail” rather than as “Detail, City, County, State, Country” as is currently done. 

Some Source Types may use Location, Second Location, or Publisher Address instead of Repository Address.  These are usually not unpublished sources, but treatment as unpublished may be desired.  In such cases, there may be a recommended method for entering such place information similar to name-type Source Elements.

One possible method for this would be in the implementation of the proposal by John Cardinal of replacing the current Source Elements/Source Element Groups with “storage locations” (in the sense of Source Element Groups now) coupled with a data type designator such as: Text, Name, Date, or Place where the Place Data Type would be new and would be output based on the Source Template need.  This might also be coupled with Place Style and used in the Source Type definition or Source Definition to designation the output form for a place.  Position as a first element in a Source Template may trigger whether a place printed in greater to smaller or smaller to greater order.

7. Change Place Styles to have a Style ID# or name which may be entered as a Place Attribute.  When a place is added to a project data set, a Place Style is attached to that place forcing the user to always use that Place Style whenever that place is utilized even when a different style is desired in another use of that same place.  With a Place Style ID# or Style Name being part of a place, a Place could be copied and a different Style ID# or Name entered as an attribute of the place.  For example, add a [L0] place field in which to enter the Style ID# or Style Name.  This would force a new place record which would be different from others.  Some users are forcing TMG to accept multiple entries of the same place by entering the Place Style in the Temple (or some other less utilized place field.  This has the added benefit of showing the user which style is assigned to which place in the Master Place List (MPL) and in the List of Places report.  The user could then have the same place entered multiple times for use with a Source, a Repository, an event Tag, or a different event Tag – each place being the same geographic location but with a different Place Style.  The [L0] place field would essentially be automatically excluded (i.e., non-printable) except in reports such as List of Places and maybe other list type reports.  If Style Name is used, it might be desirable to limit the length of the name so that it could be added at the beginning of the place record and not take much space on the screen in the Master Place Record. A Style ID# would be preferable for this and speed sorting of the Master Place List, but might not be as recognizable to the user as a Style Name might.

8. When Tasks are attached to a Tag with Witnesses, show the Witnesses in the Task.  Many Tasks call for research that requires the researcher to go through the “back door” by research of a Witness rather than the person to which the Task is attached.  Thus, when a List of Tasks report is generated, allow for Witnesses attached to an event to be included in the report. See #20.I. below.

9. Provide for “Negative” Years in Dates.  Currently, valid dates in TMG provide for years in the range of 0100 up (second century or later) although a user may enter a date within the first century with some difficulty.  But year dates before 0001 (BC or BCE) are not accepted – or when accepted, do not calculate ages, etc. properly.  While this would probably not be a most used feature, many users would take advantage of it.  Not a few users can trace (or say they can) their ancestry back to before the year 0001 although most of those that do stop within that first century BC/BCE. But, some would go further. For example, historians (both professional and amateur) would find this useful. The provision might be made though the use of 9s math with the instructions on how to do this in Help.  Another method might be to place the year in parentheses since the dash is already used as the Exclusion Marker. Appending AD, BC, BCE or whatever as suffixes might also be good. Thus 9850, (0150), 0150 BC, etc. are examples of possible entries of the same year (with -0150 being excluded).

10. Provide an EOL (End-of-Line) Designator.  This might be as simple a creating a standard Flag with settings of ?, N, and Y.  The operative part would be that reports (or filters?) would see the Flag and, if set to Y, would end further processing with that person.  The person would be included in the report, but would not be carried further back or further forward.  There would probably be both ancestral and descendant EOL Flags. For example, a descendants report would include the person whose descendants EOL Flag was set and an ancestral report would include the person whose ancestral EOL Flag was set, but stop there. If other processing was needed (other biological lines), it would continue. The idea would be that when a person is added as an ancestor or a descendant, the appropriate indicator would be set automatically.  Then, if an ancestor or descendants of that person was added them the EOL Flag would be reset for the existing person and the Flag would then be set for the new person.  The user could, of course, override the Flag if desired. Thus processing of a line would end when the line ended (and is currently done) or would end when the set EOL Flag was reached -- whichever comes first.

11. Provide Backup File Path Separate from the Backup File Name.  Separate File Path and File Name in the Backup Wizard so that File Paths can be changed and saved with the Backup Configuration.  A new or default configuration would pick up the Backup File Path from Preferences, but once given a new Configuration Name, the File Path would remain the same as saved until changed.  This would allow users to have multiple locations for backup files based on the configuration.  There might be a location for multiple backups during a day, a location for a single daily (end of day) backup, a location for a weekly backup, etc., and each of these would be in a different location (File Path).

12. Allow the Research Log and the Exhibit Log to be independent Windows.  These windows should be able to be held open at all times.  Their focus like other windows at present would determine how/if changes are made to their content when the focus of the Details window is changed.  If the focus of a log window is the same as the Details window then change the log window focus to the new focus of the Details window if Link Project Explorer to other windows is selected.

13. Provide for a "Keystroke/Event" Log.  This may be an true keystoke/event log or just the basics of data entry work as to what is done.  The Log should be optional, and would be "turned off" by default as it is likely to be a resource "hog" slowing down TMG operation (and maybe other programs).  The basic  recorded data should be the person (ID#) (of Principal 1), Tag Type (Label), Date, and the Citation Source# added/edited  (if any).  Except for the P1 ID# and Date (and Citation Source#), other data entry would not be recorded.   Data entry for other than people/Tags would be mainly that a record was edited.  For example, places, Sources, Repositories, Exhibits, and Tasks would only record that creation or editing was done.  Each recorded Log event would be time-stamped with the date and time as taken from the computer clock. The user could use the expanded Last Edited Date (item # 3 above) to help find the data that was added/changed/deleted.  If the action was to deleted the entire record then an indication would be set to that effect.  The log would be recorded for a session with a filename indicative of the session or for the session portion if the user turned on and off the log multiple times in a session.  A notice might be displayed that the log had been created when the log is closed

14. Store ALL Logs, Error Reports, etc. in the Logs Folder.  This would place all logs, error listings (including from GEDCOM imports, Last VFI.LOG, etc.), and any other maintenance type report in a single place.  At the same time, give each such created file at unique name using say the first ten characters of the project name and the present file name. 

15. Ask if user wishes to open a created Log file.   As reports are created, the user is asked if the file should be opened.  This is the case for most reports output to word processor, spreadsheet, etc., and for the Error.lst file created for a GEDCOM import.  The same request should be made for other created files including the Last VFI.log.

16. Add a Privacy Flag.   With the concern about privacy and identity theft today, many countries have enacted laws preventing the publication (to print or on line) of personal data of living persons.  The restrictions set forth in these laws are based on various criteria including age of the person, voluntary permission by the person, etc.  Many such laws provide for different restrictions for certain groups.  To fit this, it is suggested that a Privacy Flag be added as a standard Flag with default settings as follows:

• ? - Not set (acts like the P setting), allows the user to know when the Flag has been set or is just the default.
• P - private; the person is completely excluded from all reports that honor the privacy flag. It's the same output as if the person was deleted from the project.
• X - semi-private (severe); the person's existence is acknowledged, but all information including gender, name, and event data is suppressed.  
• S - semi-private (less severe); the person's existence and gender is acknowledged, but all other information including name and event data is suppressed.
• N - name-only; the person's primary name and gender are shown, but all other information including primary name memo, other names, all events, etc., are suppressed.
• Y - year-only vitals; the person's primary name, gender, and primary BMDB tags are included, but the primary name memo is excluded, and the event data is restricted to year-only, and excludes places, roles, and memos.
• V - full-vitals; the person's primary name (excluding memo) is shown, as are the full display of primary BMDB tags (excluding memos);
• U - unrestricted; the person's full information is shown.

Reports/charts should follow this Flag setting by default although the user may de-select or turn the option off for the report/chart.  Data from programs having similar indicators should be considered upon import.   The above basically follows a proposal suggested by Robin Lamacraft with modifications by John Cardinal. 

It is likely that more discussion is needed to determine exactly how various reports apply the settings.  One thing that should be considered is if the setting should be changed with the addition of a Death or Burial Group Tag.  Further, should an option be added to Event Tags as to whether the Tag should follow the Flag setting in certain reports/charts.

17.  Add a New Sentence Variable for Rolenames.  Users often want to use the Rolename in a Sentence.  Having a Variable for a Rolename would help the user create Sentences tied to the person assigned the Role.  Most users would probably never user a Rolename like “Principal” in a Sentence, but it should be available if desired.  Many users have Roles like “Sister,” “Son,” “Granddaughter,” etc. in the Census Tag and creates Sentences containing essentially the Rolenames.  Then there are “Heir” and “Executor” in the Will Tag where persons assigned these Roles are included in Sentences in ways that could use Role Variables.  A possible way to do this might be to have the Variable as [RN:{Rolename}] where the Rolename itself would be output rather than the person’s name (similar to how age and exact age are treated).  This may require that creations of Roles would also require entry of the plural version of the Rolename for cases when multiple persons are assigned to the Role and the Sentence is such that all assigned persons are included in the output sentence.

18.   Add a New Sentence Variable for Surnames.   A few users would like to have a Sentence Variable that produced only the person’s Surname.  In effect, this would be similar the [PG], [POG], [RG:{rolename}], etc. Variables  except that it would produce the Surname rather than the GivenName.  While many users would not use this, many other would find it useful, giving users a way to vary the style of their writing.

19.  Provide access to an event by Event Number or never display the number.  In a number of places in TMG (e.g., Exhibit Log), reference is made to the Event #.  However, there is no real provision for finding that Tag.  Either such a provision should be made (maybe through a search option in the Master Event List?), or the Event # should never be displayed and only the person ID and Tag label displayed instead.  It is often frustrating to the user to see what initially appears to be a person’s ID# only to go to that person and not be able to find the desired object (Exhibit, Tag, or what ever).  The present search for an Event in the Master Event List by Event # is awkward at best and for many users not a viable option at all.  So the Event # should be fully useable or not used/displayed at all.

20.  Provide a Next Page Printer Code.   A Printer Code to force a next page in a narrative report is needed.  This would be useful in various places.  A good example would be at the end of some JournalIntro Memo field text entries.  The length of such text will vary from one or two paragraphs to multiple pages.  The resulting report may then appear illogically paginated, such as leaving just enough room on the page to contain the regular report title.  Thus, having a Printer Code to force a new page on which to start the remainder of the report would make the printed results much more professional looking.

21. Add Start Year/End Year to the MPL Picklist (from [F2]).  The Master Place List (MPL) allows the user to mark a place record with Start and End Years indicating the place is valid for use within the range of those years and gives a warning when the place is used outside that range. However, the user has no way of knowing if a specific place record is so marked.  There is no practical method to display this information in any of the Repeat files (either [F3] or [Ctrl]+[F3]) and even if there were, the other place fields being entered may negate such information.  However, if the user uses the Place Picklist [F2] function, then the Start/End Years could be displayed and be useful.  Of course, if the Picklist only displayed place records that matched the prior place fields then it may be that Start/End Years could be useful in all cases of the Place Picklist.  Still, having the Start/End Years displayed would be a big help and allow many more users to take advantage of the Start/End Years in place records.

22. Provide a method of locking/un-locking projects by computer.    A data set newly imported to a project will be locked and may remain locked if the user wishes.  This locking would prevent the user from inadvertently changing another user's data.  Once un-locked, a data set cannot be re-locked.  Many users have wished for a method of locking an entire project for shorts periods of time.  Usually this locking would prevent working in the wrong "copy" of the project when the current "copy" is on a different computer.  Note that the lock would be for the project on a specific TMG installation (a specific computer. A TMG Backup would not contain any indication of the locking status of the project.

23. Creation of New or Revision of Current Reports.   There are many report types that are needed or would be useful.  Some of these already exist, but could be enhanced by various changes.  Following are some of them:

1.  List of Exhibits.  This would be a new list type report.  Similar reports are available (TMG Utility & PathWiz), but (1) they are external to TMG requiring the user to close TMG to get the report & (2) are not always in the format desired. This would essentially be just a listing with the following as a suggested content:
   1. File Name of the Exhibit (or just the designation “Internal”)
   2. Caption
   3. Description
   4. Type – Person, Event, Source, Repository, Place or Citation
   5. Person ID(s) to whom attached or to which the Event Tag is attached, Source ID#,or Source #. 
   6. Person Name(s), Place name, Source Abbreviation, Repository Abbreviation, or Event Label(s) to which attached
   7. Event Date.
   There could be other columns to the report.  The user should be able to sort the report as desired similar to other list type reports.  As with other reports, the user should be able to choose the focus of the report.  Since Exhibits can be attached to persons, events, Sources, and Repositories and can be Internal or External, and Primary or non-Primary (for person Exhibits), these should be part of the Focus selection capability.  Finally, a thumbnail print of the Exhibit could be included or not as the user desires.

2. List of Places. Add Place Style as an optional column. Currently there is no way a user can determine from a List of Places report which Place Style is associated with a place.  In conjunction with this, the user should be able to filter by Place Style.

3. List of Relationship Tags.  This is a new report.  It would list the various Relationship Tags associated with the person(s) included as the Focus of the report.  The columns would be for both parent and child of a Relationship Tag giving their ID#s, names, Tag Label, and indicate whether the parent is Primary or non-Primary.  Birth and/or death dates of the child would also be optional columns.

4. List of Source Elements. A new report type, this would be a listing of all Source Elements (including Custom ones added by the user) by Source Element Groups.

5. List of Sources.  Add Reminder as an optional column to this report. Also provide for filtering by Source Element [including Custom] (or Source Element Group).  This filtering would allow the user to find Sources whose Output Forms were customized and thus different than the default Source Type Templates.

6. List of Source Types.  This is a new report.  The report would list the Source Types by name, giving the three Source Templates and the Reminders.  Further, it would indicate if a Source Type was standard or custom, the basic Source Category from which it was derived (Lackey, Mills, Custom), and if custom, the ‘most similar to’ Source Type. This report might need some revision if #5 above was implemented.  Also provide filtering by Source Element [including Custom] (or Source Element Group).

7. List of Tag Types.  Add a “column” to this report providing for the printing of Reminder data. 

8. List of Tag Types.  Add a Tag usage “column” to this report to allow the user to determine the number of times a Tag Type is used in a project or data set.

9. List of Tag Types.  Add a “column” for Role names.  If selected for the report, each Role would be a line entry, along with the Sentence and Witness Sentence for that Role.

10. List of Tasks report. For Event Tasks, list any Witnesses to allow researching through those persons.  See #8 above.

11. DNA Values List.  This is a new report.  This would probably be best if output to a spreadsheet with the name (and ID#) of the Focus person(s) as well their Haplotype shown at the left and the y-DNA allele values to the right in columns.  Many DNA projects use this format for comparing different persons’ tests.  For mtDNA, the line entries would be similar except that only the difference values to the Cambridge Reference Sequence (CRS) would be given by position number.  The mtDNA would probably be given as a line for each section (HVR1, HVR2, HVR3).

12. Timeline Report.  This would be a new chart type report.  Brothers Keeper had this report long ago and it was very nice. Basically the chart had years on the X-axis and listed persons within a “bar” positioned along the Y-axis based on lifespan or start/end considering birth/death date.  In addition, events from Timeline(s) would be placed in the same way (probably at the top or bottom, or even interspersed with persons).  Accent coloring of persons and/or Timeline events would be helpful in reading the chart.

13. List of Styles.   This is a new report or rather two new reports in one.  The user would choose as the Subject of the report whether it would be for Name Styles or Place Styles.   There would be no filtering as all Styles of the selected type would be included.  The content of the report for any type Style would be very similar to that shown on the edit or view window for that Style.  The resulting report would likely be only one or two pages for most users with a few users having more than that.  A report much like this is available through TMG Utility; but this would require closing the project in TMG, opening it in TMG Utility, closing the Utility, and re-opening the project in TMG.

14. Individual Narrative.  This report needs to be modified to allow the user to select to include children of the person.  This might be tied to the request above to add Sentences to Relationship Tags or a new standard Tag (say “NarrativeIndividual”):
    1. If the option to include children is selected and Relationship Tag Sentences were used then the Relationship Tag Sentence related to the parent would be used. 
       1. This would then be a series of sentences – one for each child, or,
       2. The report writer would print a beginning sentence and then add the names of the children (oldest to youngest with or without reference to the mother).
    2. If the option to include children is selected, the NarrativeIndividual Tag Sentence would be included in the report using a Sentence like:
                      The children of [P] were: {comma-separated list of children’s Given Names). 
       In the case of children having different Surnames, the same Surname children would print together; e.g.,
                      Amy, Joe and Jill Smith, and Bill and Mary Jones.
       This last method might be a “cleaner” report than using the Relationship Sentences option above, but may not include birthdates/years which the Relationship Sentences could include.  Further, this option would require the user to add the NarrativeIndividual Tag to those persons desired.
15. List of Events.   Provide for a Role Column in both reports.   This would allow the user to review Role usage for a project.
16. List of Places.  If Place Styles are tied to place records rather than to Tags, provide for filtering by Place Style, and add a Place Style column (for the style name).
17. Various Narrative Reports.  Incorporate any non-Primary relationships into a person’s narrative.  As noted in item one above, this could be accomplished in many ways.  For a Journal report, the inclusion would be in the second paragraph if the birth, marriage, death, and burial information is in a separate paragraph.  For further discussion, se item one above.
18.  List of Names.  Add Name Style as an optional column. Currently there is no way a user can determine from a List of Names report which Name Style is associated with a name.  In conjunction with this, the user should be able to filter by Name Style.

    ---

    [1] Joan Ferris Curran, Madilyn Coen Crane and John H. Wray, Numbering Your Genealogy, Basic Systems, Complex Families, and International Kin (Arlington, Virginia: National Genealogical Society, 1999).

---

Return to the TMG Tips Main Page.

Last revised:



Webpage design by Lee Hoffman