Application: Family Tree Maker
Current Version: 2014 (Windows), 3 (Mac)
Supported OS: Windows, Mac
Mobile Apps: None
Price: $69.95 (Windows or Mac), $89.95 (Family pack including both versions, 3 computers), $29.95 (upgrade from previous version)
Publisher: Software MacKiev
GenSoftReviews: 1.85 (Windows)/1.62 (Mac) stars out of 5
Version tested: Family Tree Maker 3.1 184.108.40.2067 (for Mac)
After a two-month hiatus, Family Tree Maker (FTM) is back on the market, now sold directly by the developer, Software MacKiev. MacKiev used those two months to improve the performance of FTM, add artwork for charts and reports, and make needed changes to splash screens and icons to reflect the new publisher. Current owners of FTM 2014 or FTM 3 will receive a free update to their software. If they’re on the MacKiev email list (sign up at the link above), they should be notified by email. Eventually the auto-update mechanism in the software will begin working again, but due to the transition from Ancestry, for the time being it doesn’t work. Owners of FTM 2012 or Mac 2 or earlier can get an upgrade to the new versions for $29.95. To receive the upgrade offer, sign up for the mailing list. MacKiev will send out the upgrade offer on March 4th to everyone who has signed up by then.
+ I’ve already tested the update for Mac, mainly to ensure everything still worked, especially TreeSync, and I can report that TreeSync does indeed still work. Although I didn’t benchmark it, my tree and all its media seemed to upload faster than with the previous version. In addition, all media uploaded without any errors, which was often the case in the past. TreeSync, which provides the ability to synchronize a desk-top family tree with one at Ancestry.com, is probably the biggest selling point for FTM. It essentially keeps a back-up of a tree in the cloud. While this feature used to be unique to FTM, it will be no longer, since RootsMagic will soon also have a similar feature.
+ I tested several resource-intensive actions, to include merging two trees and exporting a tree to a FTM backup file, and again my impression was that the performance was faster. I benchmarked a few actions that show the improvements:
- Smart Story, add Personal Biography items, including source citations – was 45 seconds, now less than 2 seconds
- Resolve single place name – was over 60 seconds, now less than 2 seconds
- Merge two place names – was over 40 seconds, now about 1 second (but see Cons for problems)
- Switch to Places workspace from another workspace – was 5 seconds or more, now less than 1 second
However, be warned that FTM may appear to stop responding, depending on how much RAM your computer has (at least the Mac version), but it’s still chugging away and should eventually become responsive again. For example, finding 2680 missing media and attaching them using the copy method took about 20 minutes, but it would have taken Finder that long to copy them anyway. Also, FTM 3.1 has yet to crash on me after almost two weeks of use.
+ Several annoyances from previous versions have been fixed or mostly fixed in FTM 3.1:
- Most importantly, FTM GEDCOM files are now labelled as version 5.5.1, which is the latest version and which added support for the UTF-8 character set. FTM GEDOMS have been using UTF-8 for some time now but were still labelled as version 5.5. However, see the Cons section for problems with GEDCOM standard compliance (all of which I reported in Part 1: How to Scrub Your Data).
- The Incorrect Date Format warning was too aggressive. It was appearing even before I had tabbed out of the Date field. This appears to be fixed.
- Some user assigned media categories were disappearing from the media they were assigned to. This appears to be fixed.
- Behavior of pressing a letter key in the Add a Fact window was inconsistent. Clicking a letter key should take the cursor to the first field name beginning with that letter, but FTM was inconsistent about it. Now this is mostly fixed, although clicking the S key provides random results.
The fact that these things were fixed, based on user feedback, is promising.
+ The Web Merge Wizard has changed; you might say it’s been simplified (Fig 1).
Most notable is the elimination of the “Merged Result” column. Now you select the Preferred fact from either the left or right column. If the person from your tree is kept as the preferred fact, then you can select to discard the fact from the web (the default choice) or add it as an alternate fact (more about this in the Cons section). You can also choose to keep or discard the sources and, if there are any, the media and notes. Another change is that the column for the Person From Web Search is shaded. For comparison, the old Web Merge Wizard is shown in Fig 2.
+ FTM’s tight integration with Ancestry.com has always been one of its main features. In addition to TreeSync, FTM displays hints from Ancestry in the form of a green leaf on a person’s profile. These hints include a large collection of historical records, as well as the public family trees of other users. Furthermore, searching Ancestry from FTM is as easy as clicking one or two buttons, and the search form is automatically populated with the relevant data from your tree. As with the Ancestry website, the search criteria can be refined, and FTM displays the search results almost identically to Ancestry, down to the Search Filters and sliders. FTM makes it easy to add source citations when adding a record or other information from Ancestry.
+ In addition to Ancestry.com, any other website can also be searched from within FTM, since the Web Search workspace is a basic web browser (see the Cons for some of the limitations). The advantage of searching from FTM is that information can be copied and pasted fairly easily into your family tree.
Many of the problems with FTM deal with handling of place names:
– Sometimes place names are duplicated when adding events; this has been a problem since previous versions of FTM 3 (I don’t know about FTM 2014). For example, I added a new Residence fact using an existing place name, which I selected from the autofill suggestion. I checked the Places workspace and the place name was duplicated, with the existing place name and all its associated people and a duplicate place name with only the person associated with the fact I just entered. It makes no sense to have a place authority database and autofill if place names are going to be duplicated anyway. If a place name already exists in the tree, then it should be reused rather than being duplicated.
– Merging Duplicate Place Names Sometimes Results in Data Loss; this has also been a problem since previous versions of FTM 3. In the Places workspace, I selected the duplicate name with the least number of people attached to it. I right-clicked and selected “Replace with other place name.” From the dialog box I selected the other duplicate name and clicked OK. Sometimes the place names are merged, but the people associated with one of the duplicates are lost. For example, before merging, one place had 36 different people and the other had 3, so the merged place name should have had 39 different people. But after merging them, there were only 36, meaning the 3 people from one of the duplicates lost the place names that were attached to their events. I confirmed this by checking one of the 3 people who were affected, and the place name had been deleted from the associated facts. Fortunately, Undo works to restore the missing place names by restoring the merged place, but merging the place names should also work. If you try to keep your place names tidy like I do, you must keep an eye on this.
– When replacing one place name with another, sometimes FTM refuses to replace a name, although it will work the other way around, but then the problem of losing data is usually encountered. This seems to occur after the following steps are taken:
1. Replace one place name with another.
2. Add a fact using the place name that was merged. This usually causes a duplicate place name to be created.
3. Attempt to replace the newly created place name with the existing one. FTM will go through the motions, but after clicking OK, both place names are still there.
– Place names are not saving on new facts:
1. I added a new residence fact
2. I added the date without a problem
3. I typed a full place name (La Porte City, Black Hawk, Iowa, USA) and then pressed the Enter key and the place name was wiped out. (Note: prior to trying this, I had merged two duplicate entries for La Porte City in the Places workspace.)
4. I repeated entering the place name but pressed the tab key instead; the place name was still wiped out.
5. I repeated entering the place name but clicked on the autofill suggestion and then clicked on the Description field; the place name was still wiped out.
6. I entered a different place name (Waterloo, Black Hawk, Iowa, USA) and this time the place name save.
7. I closed my file and reopened it.
8. I deleted the Waterloo entry and changed it to La Porte City. This time it saved.
Needless to say, FTM must consistently save all data entered every time.
– On the Summary screen of the Web Merge Wizard, there is an option to edit the Source-Citation to be added. After clicking the Edit button, there is an option to choose a different Source title. After clicking this button, all of the source titles in the database are presented, but they are NOT in alphabetical order, which makes it very difficult to find the correct source title. The source titles need to be sorted alphabetically, not in the apparently random order they are currently presented. That way those genealogists who use Evidence Explained source citations can find them more easily. This has always been a problem with FTM for Mac. I reported it to Ancestry in 2012, but nothing was ever done.
– One of my longstanding gripes about FTM is that the Web Search workspace is a web browser with some irritating limitations. As a power user, I prefer keyboard shortcuts over clicking with a mouse or trackpad. Unfortunately, keyboard shortcuts don’t work in the FTM Web Search workspace. The following standard keyboard shortcuts should work (Mac / Windows):
Command-[ / Alt-Left Arrow – Go back one page
Command-] / Alt-Right Arrow – Go forward one page
Command-R / Ctrl-R – Reload page
Esc – Stop loading page
Note: portions of text in all capital letters that aren’t acronyms are GEDCOM tags, with the rest of the plain text field name in lowercase.
– FTM imports the ANSEL character set incorrectly. For example, it imported “Baumgèartner” as “BaumgËartner.” ANSEL is an old character set that predates UTF-16 and UTF-8; many old GEDCOM files still use it. There is no reason for FTM to import it incorrectly.
– FTM imports the NICKname tag incorrectly into the Also Known As field. It should be imported into a separate Nickname field, which does not exist in FTM.
GEDCOM Export (All references are to the GEDCOM 5.5.1 Standard dated 2 October 1999)
– In the GEDCOM file header, the SUBMitter record is missing the required NAME tag (p. 28).
– FTM exports the following fields incorrectly:
- Also Known As: improperly uses the ALIA tag in the GEDCOM file. The ALIA tag is to be used as a cross-reference to another individual’s record who may be the same person (p. 84). The 5.5.1 standard specifically states, “One or two systems used the ALIAs tag for representing multiple names. This form is not supported in the GEDCOM Standard” (p. 69). This can be easily fixed by changing Also Known As to a custom fact using the EVENt & TYPE tags.
- Address: incorrect structure. An address should contain a street address, city, state, country, and postal code in separate form fields (p. 31). The Address structure doesn’t use the Date or Place fields. It must be attached to an event (like a residence), not directly to a person (p. 32).
- Email: must be part of address structure (see above).
- Phone Number: must be part of address structure (see above).
- Web address: must be part of address structure and use the WWW tag (see above).
- Initiatory: While the GEDCOM standard does not include this field, FamilySearch expects GEDCOM files submitted to them to use the WAC tag, which is what PAF and many other applications use.
- Sealed to Parents (LDS): missing required child-to-family link (FAMC tag) (p. 36).
- Multimedia: missing required file format field (tag FORM), includes an illegal TEXT tag, which isn’t in the specification, and uses the wrong syntax for the date (must use CHANge tag, not just DATE) (p. 26).
– Sources citations in an FTM 3 GEDCOM file don’t include URLs from the Web address field of the Edit Source Citation form. These should be saved in the PAGE tag.
– The PAGE tag in source citations may not have CONC or CONT tags (p. 39). The character limit for the PAGE tag is 248, so if the Citation Detail field is longer than this, the remainder should be put in a NOTE attached to the citation.
– The Repository portion of a source record in FTM uses the wrong Address structure (see above and p. 27 of the standard).
– Sex: It is not permitted to include a source, media file, or note on the Sex field (p. 25), so FTM should not permit them either.
– Some Facts are Events that must have a date and/or place, or else include only the letter Y in the Description box. If either a date or place is listed, then the Description box must remain empty (pp. 34 – 36). The Description box also may not contain the letters N, U or anything else. FTM should not allow anything but Y in the Description box for events. Technically in the GEDCOM Standard, there are really two major types of facts pertaining to an individual: attributes and events (families can also have events). The following fields are attributes for which it is appropriate to use the Description box: Caste, Physical Description, Education, Nationality, Occupation, Property, Religion, Residence, SSN, and Title. These facts may but are not required to have a date and/or place (pp. 33-34). All other Facts are Events, as explained above.
– Lastly, FTM uses the CONC tag for concatenation incorrectly. The GEDCOM standard states, “The CONC tag assumes that the accompanying subordinate value is concatenated to the previous line value without saving the carriage return prior to the line terminator. If a concatenated line is broken at a space, then the space must be carried over to the next line” (p. 10). Furthermore, “There are special considerations required when using the CONC tag. The usage is to provide a note string that can be concatenated together so that the display program can do its own word wrapping according to its display window size. The requirement for usage is to either break the text line in the middle of a word, or if at the end of a word, to add a space to the first of the next CONC line. Otherwise most operating systems will strip off the trailing space and the space is lost in the reconstitution of the note” (p. 37). FTM does not do this. It breaks the text at the end of the word but does not add a space to the beginning of the next line.
Software MacKiev President Jack Minsky told me by email that the GEDCOM compliance issues will be fixed in the next update. In Parts 1 and 2 of this series, I explained how to scrub your FTM tree and make your FTM GEDCOM standards compliant. Based on what I’ve seen from MacKiev so far, I think you can hold off on any further scrubbing.
I’ve been using FTM on and off for almost 20 years, and I must say that MacKiev appears to be more responsive to user feedback than Ancestry was. For starters, they have easily accessible Bug Report, Feedback, and Request a New Feature forms on their FTM website page. They’ve responded directly and personally to the feedback I’ve provided, stating they would fix what was possible to be fixed, not just providing a canned response. Clearly they have an incentive: they’ve bought FTM outright and need a return on their investment, having done so when many users had already jumped ship to other applications. Now they need to retain the loyalty of the users who stayed with FTM (including the many who complained loudly about FTM’s impending retirement). For the Mac version at least, the latest software update is a step in the right direction. If MacKiev makes good on their commitments to fix the remaining problems, including GEDCOM compliance, and continues to improve, then FTM might be worth sticking with. But as with all the other apps I’ve reviewed so far, it’s still too early for me to render a judgment. For updates to this article and future articles in this series, please fill in the “Get Email Updates” form in the right sidebar.
GEDCOM 5.5.1 Test: FTM 3.1/2014.1 pass the GEDCOM 5.5.1 Test. While they have a few compliance issues, both with import and export, they export GEDCOMs using UTF-8 encoding and correctly label the files as version 5.5.1.
5 Mar 2016: Deleted the paragraph about the Web Merge Wizard default for information from the web search. Thanks to reader Geoff for pointing out that FTM 2014 allows users to change the default in the general program options. FTM 3 also has this option in the application Preferences.
30 Apr 2016: Added a statement about the GEDCOM 5.5.1 Test.
The Family Tree Software Alternatives Series
Part 1: How to Scrub Your Data
Part 2: How to Get Your Tree out of FTM
Part 3: RootsMagic 7
Part 4: Reunion 11
Part 5: MacFamilyTree 7
Part 6: Family Tree Builder 8
Part 7: Heredis 2015
Part 8: Gramps 4
Part 9: iFamily for Mac
Part 10: GEDitCOM II
Part 11: Legacy Family Tree 8
Part 12: Ancestral Quest 14
Part 13: Family Historian 6
Part 14: Should You Stick with Family Tree Maker?
Part 15: Brother’s Keeper 7
How Well Does Ancestry.com Handle GEDCOM?
Family Tree Maker to GEDCOM to Other Apps Crosswalk
The Perils of Following the GEDCOM Standard
Why All Genealogy Apps Should Support GEDCOM 5.5.1
*Information current as of the date of this post