Mary D. Green (born Jenkins) was born May 19, 1879 & died May 20, 1920. Her father was Andrew Berry Jenkins her mother was Rebecca Rhyne.Philo Jonas Green(her husband) was born Oct. 28, 1874 and died Dec. 13, 1949. His father was Stephen Green and his mother was Eliza Jonas. For all you that are posting family trees, please get the facts. I have hard copies of birth and death certificates for the above dates.
When I confirm/reject matches in FTB, does this syncronize with the webpage? So if I confirm a match in FTB can I see the same confirm at the webpage?
What will happen with all the mathes I confirmed/rejected when I upload all my change to the tree at the webpage? Will I receive new match for match I allready confirmed/rejected?
How do I hide all matches I allready confirmed/rejected in FTB? in the list of persons I can see how many matches each person have (Total match), I can all so see how many matches I confirmed, But I can not see how many matches I have rejected so I can not see if there are any new matches.
Will there beasynchronizationbetweenFTBand the familysite in the future?
I do all the work in FTB, and use the family site to publish the information to others. And it is a little frustrating to see all the match at the family site then you have allready confirmed/rejected the match in FTB.
Are there a way to hide smart match at the family site? without disableing the smart match function.
SmartMatches are not yet fully synchronized between FTB and your site. You must reject them in both places separately.
We do plan on developing this feature in the future.
Okay....... So this was written ten months ago, has the situation been resolved yet?
I have been using Family Tree Builder (only) to build my family tree, using SmartMatches from mainly family member trees, via the merge function, to add members and amend or add to their details. And it seems to be working and updating on the tree on the website.
Now, I am a complete computer illiterate. Is it that there will be a heap of SmartMatches on the Web site that do not show as being confirmed or rejected, though I have already done that on FBT?
And will there be members and member details not updated from Family Tree Builder?
Or do the current versions of both softwares now work around this problem?
Information that is entered in your tree in Family Tree Builder, manually or through merging matches, will be published to your site.
However, unfortunately, Smart Matches™ are not fully synchronized yet between the Family Tree Builder software, and the family site. Even if you are using Family Tree Builder, you are encouraged to use the new Enhanced Smart Matching™ on your family site, and enter new information you learn using Family Tree Builder.
In the future we are planning on releasing a full sync between the site and Family Tree Builder which should make this easier, so stay tuned- it's worth waiting for!
There are different algorithms for SmartMatching on the site and in Family Tree Builder, so you could have similar matches and also different ones in each place - so it is possible that certain matches on the site will not appear in FTB.
Information that is entered in your tree in Family Tree Builder, manually or through merging matches, will be published to your site, but information that you learn and confirm from matches on the site will have to be entered manually in your tree in Family Tree Builder. You can try to copy and paste if you find it more comfortable.
At least I have a better understanding of how it works in the two different 'venues'. I have spent a lot of time and effort in Family Tree Builder with Smart Matches but I have not yet tried to manipulate the smart Matches on the web site.
I have around four thousand matches on FTB and six thousand on the web site. So whatever I do it will be onerous. Your recommendation to use the web site (even though I use FTB to build the tree) would seem to be because of the enhancements there, which should make the process many times faster.
(Yes or no, please!)
So what I think will work best (despite the algorithms being different and the matches therefore being derived independently, so that the results may or may not give the same matches) is to ignore the matches in FTB in the first instance.
If I first do the Smart Matching on the web site, that will clear a lot of the backlog there relatively quickly (please tell me if that is not right). And if I find a match that adds a family member, or more information, I will first go to the Smart Matches in Family Tree Builder to see if that match is also there. If so I will merge from there; if not I will do it manually. But I expect that most will be in both places.
Please tell me if this is the most efficient way to go. Thanks,
I don't have a specific recommendation for how to manage SmartMatches. It is really a matter of what is most comfortable for you. So I suggest you start working through them like you said, and adjust your methods as you go along.
Hi. This was set out as a reply to my own comment originally 'Smart Match Webpage Vs. FTB' but that was 127 days ago so will not come to the top. Maybe this will or maybe it will disappear, perhaps I have not done it right....
At the moment this is what I do: I have two screens, Family Tree Builder, Smart Matches by People, on the left. I bring up FOUR family trees in different tabs in Internet Explorer on the right screen. And I display the family tree, smart matches (People by surname), and Relationships (to me). In the fourth tab I can look up forums, inbox, etc.
I look up the web-based SmartMatches and the same person in Family Tree Builder, confirm or reject matches in BOTH, send comments in the web-based system and update my tree (new information, new family members) using the FBT merge function. Line by line, the auto merge is too haphazard and not precise.
Now all I need is a new fast computer and that will happen, the old one has a noisy fan and it is not worth repairing.
I can easily understand why the system would not want to dilute the accuracy of confirmed SM's, and you may not want to make it easier to be lazy, but it would be a big help for people managing very large databases and huge candidate SM lists to be able, in some circumstances, to confirm or reject blocks of candidate SM's instead of one-by-one, or all. Some circumstances that might be suggested:
* Selecting displayed candidate SM's =, <, or > a particular accuracy estimate percentage, e.g., confirm all SM's > 90%, or reject all SM's < 50%. This would save time to devote to candidate SM's that might need a bit more careful checking.
* Selecting all candidate SM's that are currently displayed on a screen to be confirmed or rejected with one keystroke.
* Using a standard CNTL-Select function to select a number of entries (not necessarily absolutely consecutively) to confirm or reject groups.
While these would ultimately cause some sloppiness and errors in confirming/rejecting, it is likely that the lack of such features contributes to at least as many and possibly many more errors when users confirm "all" without even looking at them, when faced with 10,000 candidate SM's, for lack of time, or simply refuse to take the time to confirm or reject any of them and let the numbers build up.
No reply to this is needed. Just a suggestion that might help many users at all levels.
Another related suggestion that might be a bit easier to implement.
Under SMART MATCHES / Confirmed by Others / Review and Confirm:
When you select a particular site, only the first 20 matches are shown. Your choices are to edit them individually, or Confirm All / Reject All / Ignore Tree. Unfortunately, the "Confirm All" is set to confirm ALL the preconfirmed SM's on that site, which is likely to have more (lots more!) preconfirmed SM's than the 20 you are allowed to see and check out. The only way to see the whole set of SM's by clicking out of the Preconfirmed SM's subprogram, and it is cumbersome to say the least to get back.
What this needs is an added command to Confirm These 20 / Reject these 20. Use of "all" in this particular function is pretty much useless, unless you're into approving lots of things you can't easily examine. But if you can process those 20 normally, mass (or selectively) approve/reject them as needed, then somehow load the "next 20" for processing, you can get through approving preconfirmed SM's quite efficiently and accurately. This is really important in dealing with sites that have hundreds or thousands of preconfirmed SM's waiting. And since you'd already be limiting the mass approval or rejection to only 20 at a time, it would actually improve accuracy since the entries are in %chance level.
Without that fix, I pretty much have to limit myself to using this subprogram in cases where the site has 20 or fewer preconfirmed SM's awaiting me. The program change that would fix this problem could also be applied to my other mass SM suggestions above.
I would be great if it will be possible to multi select "matches" and then reject the match.
I got many matches where my person is dead before the match person is born or the bord/dead date differ with more then 20 years
When loading SM's in response to an email from a large database, and the number of SM's exceeds about 2,000, it can cause a Server Timeout. Timeouts also totally disable the "display candidate SM's by name" function on my own very large database. While this is an inconvenience, I understand that it might be unavoidable due to scaling (my db = 400,000 people, and has amassed 1,200,000 SM's), and it can be lived with.
But a possible solution might be to use something like the segmenting function you use in the family trees, and display only the next 500 and provide a "next 500" button rather than a timeout. That way the user can begin to whittle down overly large SM lists rather than just ignoring them.
No reply necessary. Just a thought that might help those with very large databases get SM's under better control.
i am having trouble in family tree builder i could go to matches then merge then it would do so but i cant do it now wounder if that is happening to any one else and if so is there anyway to fix it it saves a lot of typing regards Denise