Page Actions

FTDNA wish list

From ISOGG Wiki

The following is a list of suggestions compiled by the genetic genealogy community of features that we would like Family Tree DNA to develop in the short and the long term. The items are listed in each section roughly in order of priority.

Autosomal DNA top priorities

These items are listed in order of priority with the items at the top of the list being the ones that have been most requested.

  • Improvements to Family Matching. One of the main objectives of genetic genealogy is to assign autosomal DNA matches to the most distant possible ancestor through whom their shared DNA has descended. FTDNA's Family Matching tool has the potential to be the most powerful means of achieving this objective.
    • However, "Calculating Family Matching" (and the subsequent reporting) currently does not appear to be scheduled efficiently.
    • When a customer or project administrator loads the "Family Finder - Matches" page after creating new linked relationships, a spinning timer and the words "Calculating Family Matching" automatically appear for a very long time in the top right corner of the page.
    • The customer or project administrator's login session frequently times out before "Calculating Family Matching" completes, and the process apparently begins from scratch at next login. The timeout limit for the login session should be increased or suspended either while "Calculating Family Matching" is running or globally.
    • It is not clear to administrators of multiple projects whether or not switching to another of their projects in a new tab while the "Calculating Family Matching" process is running on a kit in a different project in a different tab kills that process.
    • If the servers cannot cope with the "Calculating Family Matching" load, then automatic (re)calculation on page load could be replaced with a button inviting the customer or project administrator to submit the kit manually to a queue for recalculation.
    • Furthermore, after the "Calculating Family Matching" procedure assigns a triangulated match with the customer and a "linked relationship" to the most distant individual ancestor through whom the customer is related to the "linked relationship" (e.g. the mother's father's mother's mother or MFMM), that information is not reported, but is then discarded and replaced with just "Maternal" (or "Paternal", as relevant). Instead of displaying a female icon in the red coloured flag to the left of the mailto: link, the system could display the full MFMM string, and likewise the male icon could be replaced with the full F... string. The inspiration for this idea was Louis Kessler's Double Match Triangulator (DMT).
    • Similarly, the Paternal and Maternal tabs above the match list could be replaced by dropdown menus or text boxes allowing the customer (or project administrator) to select matches related through not just parents, but grandparents, greatgrandparents, etc.
    • Customers of FTDNA's main autosomal competitor (AncestryDNA) are already using its coloured dot/custom groups facility to attempt this, albeit forced to depend on the competitor's identification of shared matches without any indication that the matches are triangulated. Other customers are attempting similar analysis with third party tools like DMT. (Suggestion first added 2020-12-16.)
  • Clustering tools. Provide clustering tools for sorting matches into genetic networks. This could be done with a coloured dot system as is used Ancestry. An auto-clustering tool such as the one offered by MyHeritage would also be useful. Family Matching would be much more powerful if it was based on shared matching rather than the currently very limited process of identifying matching segments.
  • Display of fully identical regions in the chromosome browser. See the ISOGG Wiki page on fully identical regions (FIRs) for screenshots of the chromosome browser views from 23andMe and GedMatch. The display of fully identical regions would help to clear up the confusion for siblings who test and who don’t understand why they don’t match on more segments, and would be very helpful for adoptees who wish to confirm close relationships. The feature might potentially be very illuminating for people who descend from endogamous lines (eg Ashkenazi Jews). It would also be helpful to have a table of the start and stop location of each of the FIRs and HIRs (half identical regions).
  • Phasing. Phase our raw data files and return results only for matches on phased data. The proper way to do the phasing would be to first phase the data using the data files from close relatives who have also done Family Finder and then secondarily by using Beagle, Fast IBD or a similar program to fill in data that can’t be phased from close relatives by using data from reference populations. Phasing would help to eliminate the large number of false positive matches and allow the match thresholds to be reduced. AncestryDNA are currently the only company who phase the data before returning matches. When their results were compared to parent/child trios they claimed an error rate of just ~1%. See the AncestryDNA Matching White Paper. Note. While there is universal support for parent/child phasing, some members of the genetic genealogy community would not like to see FTDNA introduce algorithm-based phasing.
  • Triangulation and segment matching tool. Family Finder desperately needs a triangulation tool. This could have various features which we could discuss in greater depth. This needs to be integrated with the family trees so as to display matching locations, surnames, and/or ancestors any time that two or more people share the same segment. This tool would display all of our matches on any specific portion of a single autosomal chromosome (eg, along the lines of Don Worth’s Autosomal DNA Segment Analyser on the DNAGedcom website). A partial solution would be to modify the In Common With list to indicate which Matches also share at least 7.7cM at the same location. Note, however, that not all members of the genetic genealogy community see the need for such a tool.
  • Chromosome browser comparisons. Allow one to compare their matches to each other in the chromosome browser. (See 23andMe’s browser for an example of this. This is a highly popular feature at 23andMe. It is also available on Gedmatch.)
  • Proper X-chromosome matching. X-chromosome matches are currently only reported when there is already an autosomal DNA match. This means that many legitimate matches are excluded, especially for more distant cousins beyond the second or third cousin level.
  • Improve myOrigins. Continue to improve myOrigins, adding more regions in areas such as North America, South America, Africa and elsewhere as feasible. Incorporate reference datasets from academic datasets such as the People of the British Isles Project, the Irish DNA Atlas Project and the Genomes of the Netherlands Project.
  • Include Family Finder projects in the project list. The project list can be found here.
  • Shared ancestor hints. On the match page we currently receive reports of ancestral surnames that are shared with our matches. It would be very helpful if we could also have a list of ancestor names that are shared in our mutual trees. For example, if two people have the name William Schlosser in their family trees, this name could be highlighted in their match lists. The facility could be extended to highlight shared ancestors who have the same birth/baptism and/or death/burial dates, and also ancestors who are from the same location.
  • Improved search facilities. Generate search capabilities for Family Finder that mirror Ancestry.com's current search capabilities for AncestryDNA, particularly when used with Jeff Snavely's Google Chrome app. For example, it would be helpful to have the ability to search the ancestors of our matches by surname and by location similar to the way that Ancestry.com does it. It would also be useful to have the ability to search by given name and by surname; by birth date and/or a death date; and by country of residence. See the RootsWeb WorldConnect Project for examples of the types of search fields that would be useful. This feature would allow matches to see how they are related to each other in an integrated genealogy database, similar to how the “Relationship Calculator” works in the Legacy genealogy program.
  • More matches per page. Create an option that would allow customers to increase the number of matches per web page in the “Matches” section. As of 11 June 2017, the maximum number of Family Finder matches that is displayed on one page is 30 and the default number of Y-DNA STR matches that is displayed on one page is 25. It would be helpful if FTDNA could create options to increase the number of Family Finder matches per page to 100, 500, or 1000, as it does for Y-DNA STR matches.
  • Allow individuals to be added to the Chromosome Browser directly from the Matrix page. This feature could be similar to the facility already provided to add matches to the Chromosome Browser directly from the Matches page.
  • Provide a surname search box on the Family Finder matrix. It is currently only possible to select match names from a long dropdown list. A facility to select names via a surname search would greatly speed up the process.
  • One-to-one comparisons. Add a facility for one-to-one comparisons along the lines of the one-to-one comparison entry form at GedMatch.
  • Browser for a single chromosome. Add an option to have a chromosome browser for a single chromosome, which allows a lot more than 5 individuals to be added (as is the case with the current Chromosome Browser). I can understand that more than 5 or so is a problem when looking at all chromosomes, but when looking at a single chromosome (or even a single segment), it would be helpful to have the option for more without having to use 3rd party or your own tools.
  • Match Filter by Projects: add a drop-down selection of a joined project to filter matches by membership in the selected project (as is currently available on the Advanced Matches page).
  • Implement an algorithm along the lines of AncestryDNA's Timber algorithm to downweight pile-up regions which have no genealogical relevance. At the very least, it would be helpful if overmatching regions could be highlighted in some way so that people can be wary of using these regions for assigning relationships.

Additional autosomal DNA suggestions

These are long-term suggestions which are of lower priority:

  • Chromosome mapping. Begin automation of chromosome mapping for anyone who has relatives as close as 2nd cousins in the Family Finder database. I would probably automate chromosome mapping down to people who share at least 2% of their genome provided that the genealogical relationship is known. Care would need to be taken with this process if the people involved were members of an endogamous population.
  • Everything possible should be done to induce parent/child pairs or two parent/one child trios to be tested. This significantly improves the quality of the phasing that can be done.
  • Allow skilled genetic genealogists to begin linking phased haplotypes to shared ancestors back further than the 2nd cousin level of genealogical relationship. Some of this could be automated provided that the origin of the phased haplotype is clear.
  • Create teams that would supervise the review of situations where haplotypes that have been incorrectly mapped to more than one ancestral line in a person's family tree.
  • Include a facility in the Chromosome Browser to highlight likely pile-up areas and warn that false positive matches may be present in these particular areas.
  • Include a utility similar to the In Common With (ICW) feature that allows Matches with overLapping segments (MOLS) to be identified so that they can easily be chosen for display in the Chromosome Browser.

Y-DNA

Y-STR marker / matching

  • More Matches: Increase GD step-wise limit for matching for 67 & 111 Y-STR markers by 40% to 100%:
    • 67 markers are currently limited to 7 steps; 10 to 14 would be more useful
    • 111 markers are currently limited to 10 steps; 14 to 20 would be more useful
  • Smart Y-STR matching to take account of SNP status and to eliminate false positive matches
  • Introduce colour coding for the 68-111 marker panel to indicate fast-mutating markers.
  • Adapt TiP Report to include TMRCA mid-range estimates (i.e. mean/average/median) with 95% Confidence Intervals to give values for 2.5%, 50%, & 97.5% percentiles.
  • Provide a page in the GAP for the Y-STRs from 112-450 with the ability to download the results into a spreadsheeet.
  • Implementation of the long promised NIST standard for Y-STR markers.
  • Report micro-alleles for all Y-STR results and not just the new ones
  • Introduce multiple TMRCA pair-wise comparisons to aid estimation of TMRCA mid-range estimates and associated 95% Confidence Intervals for small subgroups of related individuals (typically subgroups within specific lineages within Surname Projects).
  • Two men who have bought, say, Y-DNA111 and are deemed not to be Y-DNA111 matches (i.e. are more than genetic distance 10/111 apart) may still be deemed to be, for example, Y-DNA67 matches (if they are less than genetic distance 8/67 apart). Customers should have the option to hide such lower-level matches, both in selecting which e-mail notifications to receive and when using the Markers drop-down on the Y-DNA - Matches page. The non-match at the higher number of markers should be allowed to trump the "would-have-been-a-match" at the lower number of markers. (Suggestion first added 2020-05-29.)

SNPs and Y-DNA Haplotree haplogroups

  • Allow customers of BritainsDNA (and all their sister companies) to transfer their list of Chromo2 Y-SNPs to the FTDNA database. This would allow them to join Y-DNA haplogroup projects and encourage them to order Y-STR testing, and perhaps other tests as well.
    • Also add support to import qualified Y-SNP data from YSEQ & FGC customers.
  • Provide haplogroup frequency tables and distribution maps for all the major haplogroups and major subclades based on FTDNA data. This would provide customers with meaningful and helpful information about their haplogroup. As an example of how this could be done see the charts provided by BritainsDNA. e
  • Allow GAP-Admins to submit corrections and update proposals for the Y-DNA Haplotree based on evidence from FTDNA kits

BigY NextGenSeq / matching

  • On Y-STR match lists include an BigY icon to indicate that the match has taken the BigY test.
  • On BigY match pages provide an indication of the Y-STR testing level of the match.
  • re-instate .bai index files with BAM data.
  • make the “Download Raw Data” facility available to Project Administrators for 30 days.
  • Conversion/update of data to the current reference genome build GRCh38.p5 / hg38. Once the conversion has been done ensure that the input and output file converters support current older build 36 and build 37 formats for several years.

mtDNA

  • Provide haplogroup frequency tables and distribution maps. This would provide customers with meaningful and helpful information about their haplogroup. As an example of how this could be done see the charts provided by BritainsDNA.
  • Include an optional column for Country on the public results display page. This is included in GAP as default, and in the Y-results classic, but not for the public mtDNA results.
  • Fix the matching algorithms so that insertions and deletions are recognised.
  • The pins on the mtDNA map only display a colour when the haplogroup is a single letter. Whenever, someone has been further tested and the haplogroup has a subclade the colour is lost and the pin displays as white.

Genealogy and tree suggestions

  • Encourage GEDCOM uploads. Everything possible should be done to induce Family Finder customers to either upload a GEDCOM file of their ancestors or to link into a larger integrated database. Family Finder matches without corresponding pedigree charts are almost worthless. For non-techie people everything should be done to make it easy to construct an outline tree on the FTDNA website. The current tree is not easy to use.
  • Include a field on the Family Tree page where members can add multiple links to their online trees (e.g. on Ancestry, MyHeritage, Rootsweb, Familysearch, etc). Some members would prefer this option to uploading a gedcom or creating their tree (again) from scratch. This would likely increase the proportion of members with accessible trees from its current low of only 20%.
  • Use unambiguous date formats throughout the website, avoiding ambiguous expressions like 2/3/2020, and allow customers the option to display dates in their own preferred format, noting that day/month/year order is the preference for Europe and most of the world.
  • Include fields for baptisms and burials in the trees. This is standard practice on most genealogy sites and is the norm for UK researchers where birth and death dates are not generally known prior to 1837 but where baptism and burial dates are available. sometimes going back to 1538.
  • Provide a facility for a global search of trees by location.
  • Create an integrated genealogy database. Begin the development of an integrated genealogy database in which duplicates in people’s individual GEDCOM files would either be merged or would be in some way be identified as being duplicates. The Mennonite Grandma database is an example of an integrated database, but a much larger database such as the one Geni.com has or Family Search's Family Tree is needed for reference. Ancestry.com has created a "virtual" universal family tree using the data from everyone who has created family trees on their website.
  • Create teams of skilled genealogists who would be willing to help neophyte genealogists trace their family tree so that it can be linked into a much larger database such as the one Geni.com has or Family Search's Family Tree.
  • Place the cursor in the search box when a myFamilyTree window is opened, avoiding the requirement for three unnecessary clicks before entering a search string. Allow a choice between case-sensitive and case-insensitive searching of the tree, instead of the present case-sensitive only searching. (Suggestion first added 2020-06-19.)

General

  • Default to Advanced DNA Filter. Can the settings on the Member Information page be customised so that we can choose to have the page opening up by default with the Advanced DNA Filter accessible without having to click through.
  • Matches and email notifications. Can the settings for these two please be split!? Now the function/setting for email notifications and appearing in the match list is the same. There is one setting for two different things. Many people do not want or need email notifications for every HVR-match (mtDNA) and every Y12 or Y37 match. However, if the email notifications are turned off the person's DNA results do not appear in the matching list. Many people do not want to do that. People who have only tested mtDNA HVR or Y12 are also interested in seeing all their matches. The settings for email notification and seeing a match in the list should be split, so that it is possible to turn off all the emails without hiding those result s/matches in the Matches list. Many project admins manage a large number of individual accounts and receive many notifications so this is an important issue.
  • Privacy and sharing (personal accounts).
    • Provide clear navigation aids so that the customer is clear which settings can be changed and how to change them. Editable links, such as the ones in light grey under Privacy and Sharing, should be underlined or changed to a different colour so that it's obvious that they lead to a new menu.
    • Include a setting for all kits/accounts (as an alternative to the strict default settings implemented in Dec 2014 described above: "Always hide my Last Name in public project results lists" or "Never show my current last name/surname in project result lists" . Motivation: Current last name is a privacy concern for many, especially in certain European countries which have traditionally used a patronymic naming system. As a result a last name can sometimes be shared by only a few hundred people and the actual tester might be easily traced. Showing the Most Distant Ancestor is what is important to a project, where the line is from, and not the actual name of the tester. An option to always hide current name will better protect the privacy of the tester.
  • Provide a join request form that project admins can customize with functionality such as found at cognitoforms, i.e. objects such as check boxes to acknowledge project caveats or collect permissions, repeating sections to collect pedigrees and text boxes for explanations. Alternatively make the join buttons for a project capable of pointing to an admin specified URL so projects can use their own form.
  • On the GAP page for Join Authorization, allow filtering by unanswered join requests.
  • Change the example provided for the MDKA (most distant known ancestor) in the genealogy section of the personal pages to include locational information. The example currently reads "John Smith, b. 1850 and d. 1925". The preferred format used by many projects is "John Smith b.1850 Exeter, Devon" or "John Smith b.1850 Boston, Massachusetts". It would be even better if a facility could be provided for project admins to provide their own examples. Also, the number of characters allowed in this field should be increased to allow the inclusion of death and/or marriage data. Currently, only 50 characters are allowed - this should be increased to 100.
  • Change the FTDNA shopping cart to clearly display US$ rather than just $. The dollar is used in my countries and customers in Australia, New Zealand and elsewhere are getting confused when they receive their credit card bill to find that the test was 40% more expensive than they thought because they've been charged in US dollars and not Australian dollars.
  • Provide better updates on kit status. We are currently told when a kit has been received, batched and in progress with an expected date. It would be helpful to include information on some of the additional steps (eg, DNA successfully extracted, test complete, in Quality Control, integration to IT, waiting on database processing, etc.) See this thread in the FTDNA forums.
  • Change the wording on the main pages where we find the search field for project search, to use "search for name or place" instead of "search for a surname". In the Anglo-American tradition surnames (hereditary patrilineal last names) are essential in Y-DNA genealogy. However, for other cultures (and FTDNA is quite international) and other types of test (mtDNA, FF), the over-focus on surnames is a disadvantage. For the Norway DNA Project (and surely other projects) we find that many Norwegian testers do not join because they cannot find us! Instead they search for a surname, which is contradictory in Scandinavian genealogy (more about this in our webpages for those who wish to learn more). Changing the wording used on the webpages would improve FTDNA's international focus as well.
  • Encourage customers to join surname, haplogroup and geographical projects. Customers could be invited to join projects as part of the purchase process. A filtered script could be added that would suggest surname projects (based on the tester's name) for new Y-DNA customers who do not order their test through a surname project. Customers could be provided with a link to the ISOGG list of Geographical DNA projects. Customers who have ordered SNP packs or Big Y tests should be encouraged to join Y-DNA haplogroup projects. Customers who have taken mtDNA tests should be encouraged to join mtDNA haplogroup projects.
  • Include different shipping options at the checkout to allow customers to choose a priority tracked service. This facility would be particularly useful for international customers. If possible include an option for a prepaid tracked priority handled return shipping to the UK and other countries.

Projects Front- and Backend / GAP

  • Automated Grouping. With the demise of WorldFamilies.net (May 2018) and their excellent automatic Y-STR grouping tool, a similar (optional) utility should be introduced to allow Admins to have new members automatically grouped. It should operate like the WFN tool and run overnight each night such that new members will be automatically grouped by the following morning. This will be particularly helpful for new Project Administrators as they come to grips with their duties & responsibilities, and will also be essential for any Y-DNA surname project that does not have an active Admin. The tool can be supplemented by the current manual system, or can be turned off completely if desired (e.g. by more experienced Admins). See this YouTube video of Maurice Gleeson's presentation on Grouping (which discusses the WFN tool) from the 2017 FTDNA Annual Conference.
  • Post Your Pedigree page. WorldFamilies.net (WFN) had a very useful "Patriarch's Page" feature and a similar page needs to be introduced for all FTDNA-hosted Y-DNA projects now that WFN has been retired (May 2018). Preferably this page should be automated so that project members can post their own pedigrees to the project. This utility would save Admins time & effort ... and would be essential for those Y-DNA projects without active Admins. The data could be entered by the member on their own personal webpage (using a standard format/template) and then extracted automatically and published to any project that they join.
  • MDKA information. For Y-DNA projects, direct paternal MDKA (Most Distant Known Ancestor) information needs to be collected more systematically, esp. birth location. This is best done by creating specific fields for the following:
    • MDKA name
    • MDKA year of birth
    • MDKA place of birth … by 1. TOWNLAND/VILLAGE, 2. COUNTY, 3. COUNTRY - this specific information is essential for locating the likely origins of a genetic group and to assist members in making connections
    • MDKA year of death
    • MDKA place of death
    • MDKA date of marriage
    • MDKA spouse’s name
    • a free field for other information (e.g. terminal SNP, family ID, other specific info)

If space is limited, then only the first three items are essential. The current system only allows about 50 characters to be included and this is too small - it should be increased to 80 characters at least. But having a systematic approach to MDKA data collection will remove a lot of the variation we see in the MDKA field ... and will ensure that essential information about the MDKA’s precise birth location is included by everyone.

  • Additional columns on Results Pages. We need a column that identifies those project members who have done downstream SNP testing, either Big Y (BY), SNP Pack (SP) or single SNP tests (SS). We also need a column for the ID numbers that many Admins used on the WorldFamilies.net website.
  • Unique STR Pattern colour-coding. WFN had a unique utility that allowed Unique STR Patterns to be highlighted on the Y-STR Results Page. A similar system should be introduced by FTDNA as it is a great aid to correct grouping of project members and also helps identify sub-branches within genetic groups.
  • Associated blog pages for project updates. In order to help reduce the GDPR risk to FTDNA of people having off-site (external) blogs associated with their projects, FTDNA should supply pages that can be used for “blogging” about the project. These can be incorporated into the existing MyGroups pages and should allow the same kind of simple functionality that is used by Google Blogger / Blogspot.
  • Customised ordering of subgroups. DNA results currently appear in subgroups on results pages in alphabetical order. The order can only be changed by manually renaming the subgroups and providing alpha-numeric prefixes. It would be helpful to have the facility to click and drag subgroups from the GAP menu to arrange them in the desired order. The relevant reports are in the GAP menu can be found under Genetic Reports( Y-DNA Results Classic, Y-DNA Results Colorised, mtDNA Results and mtDNA Results).
  • Admin-defined filters. Allow admins to add up to 10 GAP admin-definable fields with the ability to sort on the field. This would allow admins to have the ability to track info that they normally do outside of the project or within the comment field. For surname projects fields could be assigned to various branches of a family. Within haplogroups we can track other test results. Sort and filter on what is configured in the fields.
  • Fast regrouping of kits. Allow to regroup kits by entering multiple kit ID's in the group were they should be listed.
  • Subgroup Linking and accessing: especially for projects with more than 200 members it would be helpful if projects groups could be organized in levels (example 1, 1.1, 1.1.1) and Results pages show a selection of such (sub)groups maybe with a remaining URL (example ?iframe=yresults&group=1-1-1) for such a selection so that it can be shared to interested group members and interesting kits. At least provide such a function for every group similar to the group filter on the map page.
  • MyGroups Search: Allow searching the timeline for keywords in earlier conversations.
  • Family Finder Projects: In projects with an autosomal component, allow project members to be attached to a "universal tree" within the project. Track shared autosomal segments back through the ancestors in the tree.
  • In the new My Projects websites provide the option for admins to display the details of contributors to the General Fund and the amount contributed (ie, the content shown at https://gap.familytreedna.com/general-fund.aspx). This facility is available in the old GAP but has not been transferred to the new system.
  • Provide admins with the option to receive match notifications for those members who choose not to receive match notifications. Reason - Admins do not receive notification of matches if members have notifications turned off. In some cases there are valid surname matches that are missed by both the member and the admin.
  • Add an email notification when unpaid kits are returned to FTDNA awaiting payment; rather than sorting through pages to determine it.
  • Make the display of the Country column on Y-DNA results pages an optional setting. The column is not needed in surname projects where the surname originates in one country.
  • On Y-DNA results pages remove the page size limitation so that all the data can be viewed on a single page by default or introduce it as an option.
  • Put the 12 marker test (and 25 marker one for consistency) back in the GAP options under New Member Order. I have a number of subgroups that are quite identifiable for genealogy purposes using 12 markers. For firm confirmation an single SNP is all that's needed. Beginning with 12 markers is also the only way I've been able to really grow my project, by getting people in the door and working from there. There are fewer hoops to go through when simply ordering it through GAP under New Member Order.
  • Bulk e-mails: When a project administrator sends out a bulk e-mail to the e-mail addresses of project members, customise the e-mail to include the member's name(s) and kit number(s), so that customers managing multiple kits under a single e-mail address will know to which one (or more) of their kits the e-mail refers. When FTDNA or a project administrator sends out a bulk e-mail to the e-mail addresses of project members, send just one copy of the e-mail per e-mail address, even if there is more than one kit in the project associated with the e-mail address, but list all the relevant names and kit numbers in that single e-mail. Currently, bulk e-mails from project administrators contain no identifying information and bulk e-mails from FTDNA contain the kit number but not the name, and one copy of the e-mail is sent per kit number, not just one copy per e-mail address. (Suggestion first added 2020-04-22.)

Changes that have been implemented

  • Increase STR markers offered from 111 to 500 (this will help reduce the 95% Confidence Intervals around TMRCA mid-range estimates). Implemented in April 2018 as part of the BigY test.
  • Provide reports on the Y-STR markers tested with the BigY test. Implemented with new orders from November 2017 onwards and to be retrospectively added to past orders.
  • Pedigree tree display (implemented October 2016). The family tree display for Family Finder is not optimal. Family Finder needs a traditional pedigree display like what Ancestry.com offers and/or like the pedigree chart display for the RootsWeb World Connect Project. The current tree display could be retained as an option for people who want to use that format. Simply add an option to switch over to a traditional pedigree chart view.
  • Update mtDNA haplogroup assignments to conform with the latest Phylotree build (implemented March 2017). Phylotree has already been updated to Build 17. See Van Oven 2015.
    • Change the settings in members’ accounts so that by default their Y-DNA and mtDNA results are publicly displayed in projects. This used to be the default setting until Dec 2014, when it unfortunately was changed. We were told that the change was a mistake, but it is still here over 1 year later. Motivation: a large number of testers NEVER change their default settings, as they have problems understanding their account and/or don't feel confident about IT in general. If for any reason it's not possible to change the privacy settings explanations should be provided so that customers are aware that their results will not be displayed if they do not check the appropriate boxes. Please see the blog post by Roberta Estes Family Tree DNA new privacy settings which explains very clearly the problems that are being caused and suggests some possible solutions. Fixed in 2019.
    • Autosomal transfer program. Periodically update the list of top-20 matches visible to people who have transferred but not yet unlocked their matches. Many would be willing to pay to unlock if they knew that new, closer matches had come in, but right now there's no way for them to tell. If the lists were updated quarterly, FTDNA would have a reason to maintain marketing contact with those unlocked transfers and encourage them to reconsider. Implemented ???
  • A chromosome painting view for MyOrigins. This feature is already provided by 23andMe, BritainsDNA and GedMatch. For advanced genetic genealogists it would helpful if the data from the chromosome painting could be downloaded so you could see the start and stop points for segments that have been linked to specific populations. (Implemented in 2021.)
  • Don't display half-identical regions which are likely to be half-identical-by-chance and/or so small that they are likely to be misattributed to wrong ancestors:
    • Don't use <= 5 cM segments as part of match totals. The inclusion of small segments in the match threshold is scientifically unsound. See the paper by Durand et al (2014) which showed that 67% of phased 2-4 cM segments were false positives. These findings have also been replicated in two independent studies by genetic genealogists. See the two tables in the ISOGG Wiki page on IBD. For clarification everyone would still like to continue to have reports of all segments down to 1 cM.
  • Educate customers. It is important that customers know the rates of IBS in relation to matching segment sizes. Misinformation hurts not only company credibility but the entire community.

(Implemented in 2021.)

See also

Retrieved from "https://isogg.org/w/index.php?title=FTDNA_wish_list&oldid=27575"