new FamilySearch Beta2 Complete

I have heard from some testers that they didn't really see any errors, they did send in comments of things they would like to see changed or added, but overall the site seems to run smoothly.

Now that the Beta2 testing is complete, have any of you beta testers got any comments about how things went?

I thought it was great in general.

I only had one real serious problem that was never responded to. I could never get my own family correct always had to many children and could not combine them.

I sent in a feedback and got a response that it was being turned over to someone else but never did hear back.

But overall I think it is a great site.

Roger

Overall it is a great improvement to the current system. I'm still not sure how comfortable I feel with only using the online system when doing research. My biggest concern was that I had to manually merge my GEDCOM imports because it didn't automatically link them with the same records I submitted through Temple Ready. The dates and everything were the same. I hope they can find a way to merge my account with the arbitrary submitter accounts they have for my past submissions.

The sooner they release it the better! The pros definitely outweigh the little quirks.

Two major issues.

First, there's no "reality check". I was able to get it pretty wild things. Like I had someone who was my grandfather who was born in the 1500, and died the same year he was born. No red flags. No "error check" function to find those things.

Second, when you combine individuals, there's nothing to prompt you to combine the rest of the connected trees. That how you end up with duplicate spouses, children, etc. Combining those duplicates seems harder then it should be. At very minimum I'd like to see a "search for duplicate" that allows me to search by the unique ID.

Overall, my opinion is it's beyond magnificent! I'm looking forward to using it for real. It's going to be a very good tool.

I reported several things that appeared to be (minor) problems, but that's what testing is for. Some were not repeatable, and those have me a little concerned if they show up in the production system. I made some suggestions for improvements, but they were mostly convenience-level things I could live without if necessary. All of the concerns and issues below were reported.

One thing I'm really excited about is the API that's supposed to be made available for (open source and otherwise) desktop record managers. With the API, if the main system doesn't do things the way someone likes, it should be possible in many cases to make the desktop system work better. With luck, that may lead to improvements over time to the main system.

One thing I'm somewhat leery of is the massive (at least based on the beta experience) amount of manual merging that will be needed. Once you get more than a couple hundred years into the past, at least some lines have a large number of records for each real person. At least in the beta system, you have to combine the parents of a child (maybe each child) as duplicate parents, and go to the parents as individuals and combine records for each of them, and combine them as spouses of each other. Then, you have to combine each of the children of the combined parents. Then, you have to combine any new records for the parents that combining the children brought into the picture. Rinse, repeat, ...

My wife has one line that goes through the Roger Williams who founded Rhode Island. I combined individual and spouse records for him and his wife, and the system wouldn't combine one last "[Unknown Name]" spouse record. The support person told me to combine the children. About seven hours of work later, the children were combined (and that's not being as careful as I should be with the permanent system). There's still some amount of work to do in cleaning up that family, and that's just one family.

If people start blindly uploading GEDCOMs without doing the combining themselves, I'm concerned we could end up with a nearly intractible problem. I submitted a suggestion that the training materials strongly encourage each person who uploads GEDCOM files to do them a piece at a time and combine their records in as they go.

Another thing that could potentially be more difficult than merging records is unmerging records that have been merged incorrectly. If people are combining dozens of duplicate records for each real person, there are going to be some false positives. (I think I made a couple myself.) At least in the beta test, the facility for splitting apart incorrectly combined records is not nearly as streamlined as it needs to be for efficient splitting. I hope they improve that facility, or it may be necessary to use the API to write a client-side program to streamline that function.

To repeat, I think the new system is going to be very good tool, and I look forward to using it.

There, did that answer the question?

I found the new system to be unweidling and impractical. It will not deal with the garbage that members are dumping into the temple, infact it will make it worse. It is open season on the Temples. Duplications was what this system was about, and yes it will stop me from doing the same work that my sister in law in Britain is doing, but we have already taken care of that situation by talking to each other and sharing information, this system will do absolutely nothing to curb the thousands of garbage names that are dumped in enmass by some members. It will not stop Mr. Smith, or Mary born about 1849. As soon as I saw "before" "after" "about" as options I just wanted to shut the system down. We are talking about linking families etc., you cannot link Mr. Smith to Mr. Smith indefinitely. It is meaningless and an affront to the work of the Lord.

In the merge fields or duplication fields, instead of being able to pick what you want to transfer over, it is all or nothing. Then you have to go through and manually take out what you don't want included and try and combine.

Trying to add a gedcom was a nightmare. I ended up in the system twice and it would not let me remove myself because apparently I didn't put myself in in the first place. My great grandfather ended up the brother to my grandmother, even after I uncombined and redid according to the instructions received from Salt Lake. I eventually just gave up.

What about the name places. My parents where married: Gorbals, Glasgow, Lanarkshire, Scotland. It would not accept this, it was either Glasgow, Lanark, Scotland, United Kingdom. Or Gorbals, Lanark, Scotland, United Kingdom. No one that I know who does family history in Britain or comes from there even considers using the United Kingdom as part of the place name. Shortening the Counties is annoying, but we can live with it. However, the Gorbals is not an entity of its own, it is part of Glasgow. I was disappointed with that as an option. It means the place names will not be correct.

The user manual that they provided was next to...shall we say...not very helpful.

Overall, I am highly disappointed, and in talking to various others who tested and who are not technically literate, it provided to be an exercise in frustration. This seemed to be borne out by the older generation. They either could not use it and gave up or found it unwielding.

Sue Barnsley

sbarnsley wrote:What about the name places. My parents where married: Gorbals, Glasgow, Lanarkshire, Scotland. It would not accept this, it was either Glasgow, Lanark, Scotland, United Kingdom. Or Gorbals, Lanark, Scotland, United Kingdom. No one that I know who does family history in Britain or comes from there even considers using the United Kingdom as part of the place name. Shortening the Counties is annoying, but we can live with it. However, the Gorbals is not an entity of its own, it is part of Glasgow. I was disappointed with that as an option. It means the place names will not be correct.

In case it might help a little, I found a way around the (sometimes problematic) standardization of place names. I would type in my place name as I wanted it, then choose "none of the above" from the list of the system's guesses at a standardized place name. The system appeared to record the 'original text' and leave the standardized place name field blank.

I also submitted a problem or suggestion about the place name standardization scheme being problematic in at least some cases. If we're lucky, they'll improve that at least as much as they can before the system goes into production.

I look(ed) forward to the opportunity of collaboration, but I'm not sanguine about this working out as it currently exists. I had a number of "it doesn't work the way I expected" comments. One of the support team was very helpful (at least he tried) when I said I was unable to "print to file". I tried all his suggestions, but still no go.
I also think that the instructions/help menu/user manual (if there's going to be one) need a LOT of work, before "naive" computer and/or genealogy users will be able to overcome the learning curve.

Joyce

I have a tendency to agree with Sue concerning her comments about her concern the Temple ramifications of the program. To many members of the church are in to much of a hurry to rush through the preparation of their family names for temple work that they refuse, forget, or choose to not go through the process of providing accurate information or worse, not verifying the information prior to the temple work being completed. This responsibility rests solely on the individual members to properly prepare their names but to often people refuse to do what is necessary. I think that they have not yet caught the vision of why we really do Family History work. I am sure that they have a cursory understanding of the principle, but to often they do not go the next step in realizing that they are actually affecting families. It was not to long ago that I found an instance where a professional genealogist made the mistake of misunderstanding a will and ended up adding a child to the family and sealing the child to the parents, when in fact it was the family's cow named "Daisy". I am sure that this is a source of frustration to our Heavenly Father. Members truly have to make this work a matter of study and prayer.


Next, adding a GEDCOM can be a nightmare as Sue stated. I spoke with my sister-in-law who had trouble with adding in a GEDCOM file. She went through the help center to find her answers and then she ended up having to email for assistance. She stated that the email response indicated that what she was trying to do was not up and ready for this test. Needless to say she was extremely frustrated over the request to do something that she could not perform. I think that some of her frustration is due to the lack of knowledge. We have to assume that most people do not know how to do something and are totally computer illiterate (which she is not).

I think that the merge features could be upgraded as Sue mention so that you can pick and choose the things that you want to merge. Having said this, I am not sure that this would be defeating the purpose of the design of the program in that it is supposed to help decrease the duplication by combining the records. This is a bit reminiscent of Ancestral File, so I am a little concerned about this aspect of the new FamilySearch. The consolation that I take in the new FamilySearch, is that you can always see what has been combined and you can dispute the information if you disagree.

The next issue that Sue discussed was the place names. I wonder if their is a way to make this area a little less strict. I too have ancestry that has issues with this. I don't know if it is because we are basing the information space because of the way that the US of A has the geographical set up, but when you get into other countries, it does pose a problem. For example I have an ancestor that is from Morpeth, Northumberland, England, United Kingdom that was not accepted. I had to change the information which results in an inaccuracy in the location. I am not sure if the solution would be to take the country off of this line, or to allow the place name to include 5 names in the place name.

The online help was ok, but at times confusing as was experienced by my sister-in-law. I am fairly computer literate and know how to work around problems. The general population may not be as comfortable with the computer and may find that the help sections are not as intuitive becoming frustrated and quitting trying to figure things out. We need to make this site experience very user friendly. The older generation appears to have more difficulty with the web site and this may be where the Family History Consultants are going to need to focus most of their efforts when they are training members on the website.

Overall, I am happy with the site, but it still needs some re-working, refining. I look forward to the roll out of the site. The internet and the computers were and are being designed because our Heavenly Father wants the sealing of families to occur and these tools will help with this process. The computer/internet have made researching for family more accessible and easily done. We are truly blessed to be able to be living to see this time. It is amazing to me to watch how our Heavenly Father cares for his children.

Regarding the issue of wanting to combine some but not all of a duplicate record, I had understood thatt the basic architecture of the system has a "record" as an atomic unit, and that combining part but not all of a "record" would not be possible. It appears there are two ways of dealing with that aspect (could perhaps be called a limitation) of the system. One would be to combine the record but go back and dispute and/or correct the wrong information. The other would be to manually enter the correct information and either dispute the existence of the person described in the partly-wrong record or leave it alone to be combined with something else if that would be more correct. Additionally, if the partly-wrong record in question is made up of a combination of other atomic records, they could be split up as needed.

Regarding the issue of the system wanting to incorrectly standardize place names, did you try using the "none of the above" option at the end of the list of standardized names, as I had mentioned in an earlier posting in this thread? Some of the ficticious entries I made (as instructed) have births and/or deaths in highly abnormal places like Neptune, Phobos, Mars, North Pole, and Antarctica. The system had tried to standardize many of those places, but I told it not to. As far as I could see, it kept the original text exactly as I had entered it, with the standardized place name blank. I agree it would be nice if the standardization were improved, but it seems it can be worked around fairly nicely.

rmrichesjr wrote:Regarding the issue of wanting to combine some but not all of a duplicate record, I had understood thatt the basic architecture of the system has a "record" as an atomic unit, and that combining part but not all of a "record" would not be possible. It appears there are two ways of dealing with that aspect (could perhaps be called a limitation) of the system. One would be to combine the record but go back and dispute and/or correct the wrong information. The other would be to manually enter the correct information and either dispute the existence of the person described in the partly-wrong record or leave it alone to be combined with something else if that would be more correct. Additionally, if the partly-wrong record in question is made up of a combination of other atomic records, they could be split up as needed.

I think that some sort of Ranking of entries or sources would be the best method to allow the system to ignore incorrect information. I saw several different spellings of my Great Grandfathers name. If the patrons had the ability to vote or rank the sources this could solve the problem by showing the version with the most votes as the default version.

The problem with names being sent to the Temple without enough research is not a problem relating to new FamilySearch, that problem has always existed. The only way to cut down on that would be to tighten the requirements on what information is required to clear a name. I don't think it is fair to say that this is a problem related to new FamilySearch.

I think that the GEDCOM merging function which creates a lot of merging work will only be something we will have to deal with until syncing software is available, which will allow working with the data without having to upload an entire GEDCOM everytime we have a little new information. The FamilySearch Desktop open-source program which is mentioned in the Q&A question about PAF will be able to have syncing capabilities. Also PAF add ons will be able to do this syncing function when they become available.

GarysTurn wrote:I think that some sort of Ranking of entries or sources would be the best method to allow the system to ignore incorrect information. I saw several different spellings of my Great Grandfathers name. If the patrons had the ability to vote or rank the sources this could solve the problem by showing the version with the most votes as the default version.

I also saw a few cases where I wanted to see a different name spelling than what it was showing as the default. I did the "add another opinion" operation, giving the spelling I wanted to see and the source for that spelling. At least for me, the system seemed to show my new added opinion as default.

If the system actually works the way it appears it might, showing the patron's own opinion as default, that might even get around cases where equal groups of patrons have different opinions (and documentation to support their opinions).

One related thing I didn't get a good feel for was how pedigree mode is going to show the default spouse in a multi-spouse situation. If you and I are descended from different wives of a given common male ancestor, each of us is going to want to see the wife through whom we descended as default when navigating around the pedigree. I found when I selected a given "spouse to view", then navigated back in time a few generations, then navigated forward to the same place where I had selected the spouse to view, my selection had not stuck. I sent that in as an issue, that it's going to be problematic if the system is always defaulting to the 'wrong' spouse. The response was that my feedback would be taken into consideration. Maybe that's something the 'desktop record manager' is going to have to take care of.

Jacksbox4you wrote:This responsibility rests solely on the individual members to properly prepare their names but to often people refuse to do what is necessary.

Yeah, but look on the bright side. With the new system, anyone who gets out of hand can have their ability to submit names turned off. <evil grin> THAT will get their attention!

Under the current system, they just need to find another FHC or another staffer to do a TempleReady run. It's hard to stop them. Because the new login is tied to membership info, it's not easy to get another login.

Uh, oh. If this beta is accurate, I think I see a bigger problem. I was able to do a random search for a person, look at their tree, and submit some names for the temple. I did not have to make that tree part of my tree.

Does this mean what I think it means? I was always under the impression that one of the goals of the new system was to limit the name submission to your own family.

Tom W.,

Is there someone from FamilySearch that is or could be reading this thread. I would think this particular thread would be of great interest...

The new familysearch as presented by the beta2 is headed in the right direction but it is not "there" yet. I was frustrated that I could not jump to an individual in my pedigree whether or not they were direct line. I also wished I had more control over the merging process. Putting 'all" the info about a person in one folder so to speak has its drawbacks. For example, when I come to the spouse and children screen and/or the individual screen, the program defaults to a name of the certain individual that I do not want to appear. The name I want to appear is in the "folder,' but I have to go deeper with an extra click to see it. I want to be able to control what first appears on the screen when I go to that person.
One last thing, I wish that when I leave me and my family tab, whether or not it is in the same oline session, and then come back to it, I would be in the same place/person as when I left. Or at least the history remains so that I can go to the history and go back and resume whatever project I was doing.
That said, I still enjoyed the experience of beta2. My fav: Temple submissions!
Sandra Raymond Jarvis

mkmurray wrote:Tom W.,

Is there someone from FamilySearch that is or could be reading this thread. I would think this particular thread would be of great interest...

Yes, people from the FH department are moderators on this forum.

Tom

the few problems that i found were handled over the phone very well. i have used the 24 hr phone info system --i'm up late many nights so at 2am edt i was alway able to get an answer or any other time of day
i do hope that some teaching on how to use the new system will be sent out. our present FHC director doesnt understand computers
anyway this will be a big step forward when it comes out

rmrichesjr wrote:In case it might help a little, I found a way around the (sometimes problematic) standardization of place names. I would type in my place name as I wanted it, then choose "none of the above" from the list of the system's guesses at a standardized place name. The system appeared to record the 'original text' and leave the standardized place name field blank.

I also submitted a problem or suggestion about the place name standardization scheme being problematic in at least some cases. If we're lucky, they'll improve that at least as much as they can before the system goes into production.

I had similar issues with place names. I submitted names through TempleReady a year ago... The town names for this particular family of several hundred records were different then than they are now. So, somehow the standardization dropped the village/town name and left it at the state level only. When I uploaded a GEDCOM of the same family, the full place names were accepted, but they were not deemed to be the same individuals (by my guess) either because my submitter name from a year ago was not tied to my membership or the place names were different since my earlier submission got cropped by the place standardization system.

Sandrajarvis wrote:
One last thing, I wish that when I leave me and my family tab, whether or not it is in the same oline session, and then come back to it, I would be in the same place/person as when I left. Or at least the history remains so that I can go to the history and go back and resume whatever project I was doing.


Sandra Raymond Jarvis

That was one of my frustrations, too. I submitted a suggestion to have "bookmarks" or favorites so I could return quickly to someone several generations back and over a couple of removes without having to click so many times.

ghoffman wrote:That was one of my frustrations, too. I submitted a suggestion to have "bookmarks" or favorites so I could return quickly to someone several generations back and over a couple of removes without having to click so many times.

I just used the regular browser bookmarks feature in Firefox 1.5.0.11 to bookmark a place on my pedigree, signed out from NFS, shut down the browser, fired up a new browser, signed in, and went to the bookmark on my pedigree, and there it was, just as when I had first visited the place.

As a participant in both beta tests, I was happy to see the many improvements in Beta 2. But I have one major concern that goes along with concerns others expressed (Sue and Russell, if I remember correctly). One of the most important stated purposes of the new Family Search is to eliminate duplicate ordinances. However, during beta testing we were never asked to try on purpose to enter duplicate names and perform duplicate ordinances. This key test would have revealed important gaps that need to be closed. I would strongly recomend that this test still be done.

When I tried, I was surprised at how easy it was to add duplicate individuals. I was able to do so both manually and via a GEDCOM file. The GEDCOM page said it would warn me if there were duplicates, but it didn't (I reported this).

Bottom line is that the new FS has a lot of cool features. However, the fact that it doesn't yet meet its stated purpose is a major drawback and one that is essential to resolve before the system goes live. Otherwise, we're back where we started.

Kathryn

It appears the key, at least from what I could see, to eliminating duplication of real ordinances is the system won't let you schedule ordinances until you have combined the duplicate records. Even though I didn't receive email about the last two or three beta challenges, I went ahead and did them (after doing the survey that had questions about those challenges). For most of the people for whom I tried to print a Family Ordinance Request, the system first required me to go through the step of combining duplicates.

There will probably be a few duplicate ordinances done, even with the new system. However, it appears to me the duplicate rate will be much less than without the new system.

I think I will prefer to do the combining first, because it's more flexible and possibly more thorough, and attempt to print an FOR only after doing all combining that appears to be possible.

rmrichesjr wrote:It appears the key, at least from what I could see, to eliminating duplication of real ordinances is the system won't let you schedule ordinances until you have combined the duplicate records.

When I did a test run for ordinances, it automatically did a "TempleReady" type run. I had to reject several "matches". In my case, since I was testing the limits, I had to reject several that the computer indicated was a match. (Matching information, matching spouse, children's names etc.) Yet, it allowed me to override.

So in my experience, the new system will help a great deal with inadvertent duplicates, but won't stop a misguided member. One thing I realized is that in my testing I think I used a rather old name - one that's old enough to be "fair game". Given the opportunity, I'll have to see if it lets me do a newer name that's not connected to my tree.

rmrichesjr wrote:It appears the key, at least from what I could see, to eliminating duplication of real ordinances is the system won't let you schedule ordinances until you have combined the duplicate records. Even though I didn't receive email about the last two or three beta challenges, I went ahead and did them (after doing the survey that had questions about those challenges). For most of the people for whom I tried to print a Family Ordinance Request, the system first required me to go through the step of combining duplicates.

There will probably be a few duplicate ordinances done, even with the new system. However, it appears to me the duplicate rate will be much less than without the new system.

I agree that the duplicate rate in the new system will probably be lower than without it. But given that one of FS's main purposes is to eliminate duplicate effort and duplicate ordinances (and the word "eliminate" was used more than once in Help documents), I still feel this aspect did not get the testing it needed, and it's not living up to its potential.

It's a true principle (in repentance as well as computer systems ) that when a mistake is made, it is least time-consuming and costly to correct the mistake as close to the source as possible. As you move farther from the source of the mistake, the consequences become greater, and it costs more money and/or time to clean it up. And it doesn't always get cleaned up.

Rather than letting patrons easily add thousands of duplicate names and then take the time to combine them all, why not stop them from entering the duplicate names in the first place? If FS can catch duplicates at the time ordinances are requested, then it has the capability to catch duplicates at the time names are added.

Note that I'm not suggesting duplicates don't need to be checked at the time of ordinance request as well. I just feel strongly the FS needs to (and technically it clearly can) do a much better job of eliminating duplicates from even entering the system.

Kathryn

Two other things would go a long way toward reducing duplicates:

* Require users to submit more than just minimal information.

I cringed when I went to the temple once and the name I received was Maria (no last name) birthdate 1845, if I recall correctly (no month/day), in Germany. There is no way another researcher could determine, from that scant information, whether this Maria is the same as any other Maria.

I had expected the new system to eliminate entries like this, but it doesn't. In fact, I was surprised that the system doesn't require a death date in order to do ordinances. The death date is important because children who die under age 8 only need to be sealed to parents, and this frees up time to do other ordinances for those who need them.

I suspect most of the time a bit more careful research would yield more complete information.

* Put more emphasis on using and documenting sources.

Sources are essential in careful research! They are also helpful to other researchers. They shouldn't be optional. In fact, I think disputes should be able to be cleared if a source document provides correct information. (That would be much better than a long list of disputed/alternate names, places, etc.)

I got the feeling from the new FamilySearch that the intent is to make family history sound as simple and quick as possible so that people will get involved. Getting people involved is a worthy goal. The trouble is, good research is often not simple or quick. That false expectation will only lead to shortcuts and more duplicates. We'd be ahead in the long run to require more complete and accurate submissions for temple work.

Kathryn

The shortfalls being mentioning are not shortfalls of newFamilySearch. The amount of information required to preform an ordinance is upheld by the newFamilySearch software, if someone has a problem with the amount of information required to preform an ordinance they need to discuss that with those who make those rules. The programmers and the people at the Church Family History Department do not make the rules. The ability to by-pass the steps and clear a duplicate name is not the problem of the software either, that is a human decision, all decisions can not be given to the software, newFamilySearch is a tool and if used correctly supplies the correct result. The software does a great job in what it was designed to do. Yes, there is always room for improvement and I am sure that improvements will continue to be made. I think the people at the Family History Department are on the right track, and this system is a great improvement over the current system.

I agree that more needs to be done to teach people how to do research and submit accurate complete information, but this site is discussing the technology aspects of family history. I would hope that we can all do better in encouraging and teaching others in proper methods.

Some people may not like to hear this, but to be honest, I think the best way to handle the massive duplicates that we are otherwise going to see when I (and each of my many relatives, and anyone else who connects into my line of ancestors) upload a gedcom file into the New FamilySearch, is to NOT allow us to upload our gedcom into the New FamilySearch. It will be a little painful to enter the information from my gedcom one-by-one into the new system, but as I enter it, each individual can be merged into the big tree one at a time, prompting me for possible duplicates. I can also be urged to provide sources for what I am entering, and hints can be given to me as I do things, and explanations can be given to me as to why it is important to merge my person with the information already in the tree when possible, why it is important to provide sources, etc. and I will be less likely to propegate unreliable information that hampers everybody else's research.

This will be cumbersome for the first couple of generations' worth of my tree, but after a couple of generations, I (and most other people) will link into common ancestors that somebody else has entered. Instead of having to merge all of those common ancestors together with everybody else's versions and following many un-merged lines, I can just compare to the one (or very few) versions already in the tree, instead of potentially hundreds of unmerged versions of mostly the same information uploaded by different people who haven't gotten around to going through and combining the individuals from their gedcom with all of the other info in the tree.

I am willing to accept that in order to make the new tree more reliable for us, and managable for people who are new to family history, we need to NOT allow people to upload massive amounts of uncombined information into the system. It is MUCH easier to prevent as many duplicates from the start than to have to go back and try to constantly be combining individuals later, evey time another person decides to upload data that should connect into my line. Automation will never be able to take over the final decision of who really is to be combined or not, and every time somebody else decides to upload a gedcom, there will be another set of duplicates to deal with if the person who uploads doesn't properly clean up after themself.

I think that applies also to the synching of third-party applications that use the API to interface with NFS. An application shouldn't be able to upload large amounts of data into NFS via the API.

If I were a person just getting started with genealogy, and I logged on to NFS and found that there were dozens of versions of each of my ancestors, all with basically the same data, but following different "lines" (because they aren't merged together yet), some having more data than others, and some having more accurate data than others, it would be frustrating and difficult to see what is already known and what isn't.

Please note, this does not mean we shouldn't be able to have our own view of what is correct or not, provide alternate views, etc., or that things shouldn't be able to be combined or uncombined. I am just talking about getting the data in there to begin with. I see no problem with allowing people to download massive amounts of data (other than bandwidth) for synching in their offline applications, but as far as keeping the NFS tree in a usable form, I think we are asking for a mess if we just allow people to upload all of the data they have and count on them taking the time to make sure duplicates get merged in or combined.

-Doug

I agree almost entirely that uploading of (large) GEDCOMs without mandatory merging is likely to create a (bigger than already exists) problem. I had sent a suggestion or two relating to that potential problem.

Here's a wild and crazy idea that might avoid the feared problem while still allowing uploads in a reasonable manner: When uploading a file, it is put in a box on the sidelines. Then the uploader, or someone else willing to be a glutton for punishment, has to merge in the duplicate records (those not handled automagically) before the uploading takes effect. Another way of looking at the idea is to create two classes of records: 1) the main database; 2) stuff uploaded from GEDCOM but not yet merged into the main deatabase.

Trying to look on the bright side: even if the system allows blind uploading without mandatory merging (as in the just-finished beta), and even if a number of people go hog-wild and upload a bunch of GEDCOMs without merging their stuff as they go, the problem may be self limiting. A lot of stuff will likely be uploaded initially, but I would guess there won't be too much more uploaded through NFS than is already there. So, the number of duplicate records to merge won't be much more than twice what we already have. There's a chance it might be less than twice if the system does (more) automatic merging where there is no question. Then, people who have uploaded will find the duplicate record problem, catch the vision, and stop blindly uploading massive files. (Okay, I'm a dreamer.) Over time, if/as client-side software starts using the NFS API to do incremental manual data entry or merge-as-you-go uploading, merging of duplicates can be done as part of that process.

Actually, one of my larger concerns is the difficulty of _UN_merging combined records. In the beta, it was a tremendous pain. I hope they fix that, and allow more efficient checking of the records than waiting 30 seconds or more just to see only the next five of maybe a few hundred combined records. If the system doesn't fix that, I hope software that uses the NFS API will.

One thing that helps calm my fears of potential problems with the new system is that President Hinckley wants it done and believes it can work well. Considering where he gets his guidance, I'm guessing it's probably going to work out okay.

I read the last several posts and recalled some things that were said as the NFS project was announced, and it was not with alot of fanfare either.

It was announced at the time they closed Ancestral File to new submissions. What they said about NFS was that it would be a system that would have the best of what Ancestral File had and the best of what Pedigree Resource File had.

1. Ancestral File allowed people to update the file with new information, which made it different in some cases with each printing of the CDs.

2. PRF was a 'snapshot' of anyone's data. The only way to change it was to enter a new submission. That latter fact is why we will be needing to do all the combining when NFS goes live in our respective areas, you can find similar data with slightly different info across mutliple discs right now already.

3. Given they want the best of both systems, that is where the web-based system being tested for NFS will be useful. You'll be able to view all the old duplications, combine them into one person, although you will always apparently be able to see any of the other entries along the way, whether they be IGI/OI entries, AF entries, or PRF entries, or even data from the Vital Records Indexes or other older databases that were created, add on top of that the growing Indexing database that has yet to go live, and there will be loads of work to do on just about any line out there.

I've also thought of a feature that might prove very useful. Why not, when someone puts up a tree and combines an entry from the pool data from all the old legacy databases into it, put a small indicator that it is now on someone's tree? That way we know that someone has a tree with the same data on it, although it may be one of a number of entries on the tree viewable from the combining, and that will also point us to trees people have created. I've heard the old data may be part of what is being called 'family finder' by some, and that will include indexed images as well as the old databases, and having an icon next to a name that will take you to the tree or trees with that name in it could be a an extremely useful feature indeed.

What is everyone's thoughts here on such an idea?

In reading these posts another idea came to mind... It would be nice to have a notification feature of individuals in one's personal tree that have potential duplicates to be viewed and potentially merged.

Garysturn wrote:The shortfalls being mentioning are not shortfalls of newFamilySearch. The amount of information required to preform an ordinance is upheld by the newFamilySearch software, if someone has a problem with the amount of information required to preform an ordinance they need to discuss that with those who make those rules. The programmers and the people at the Church Family History Department do not make the rules. The ability to by-pass the steps and clear a duplicate name is not the problem of the software either, that is a human decision, all decisions can not be given to the software, newFamilySearch is a tool and if used correctly supplies the correct result. The software does a great job in what it was designed to do. Yes, there is always room for improvement and I am sure that improvements will continue to be made. I think the people at the Family History Department are on the right track, and this system is a great improvement over the current system.

What a great discussion! I'd like to respond to several comments.

First, Gary, I absolutely agree they're on the right track and NFS is a fantastic improvement. I don't want anything I say to be construed as devaluing the wonderful work that has been done. You're also right that human factors are involved, and if good data is entered in NFS, it will supply the correct result.

But let me explain why I think the things we're discussing are shortfalls of the new system. I see this often in my work: A problem is perceived (in this case, duplicates), and a plan is formulated to solve the problem (design the system in such a way that duplicates are “eliminated”—NFS’s term, not mine). However, after the plan is put into effect, there’s a disconnect between the results of the plan and the original problem. Attention may be distracted from the disconnect by other features which are good, but which don't address the original and most important problem.

I'm evaluating NFS not based on my own criteria, but based on one of its major stated purposes: eliminating duplicates. I respectfully stand by my original concern that this aspect was not carefully tested in beta 1 or beta 2. I still feel strongly that serious testing needs to be done in this area—testers need to enter duplicates on purpose and report the results---and the system then improved based on what is learned from these tests.

I also feel that information required for ordinances is valid as part of this technological discussion. Just to make sure I wasn’t too far off base I discussed this last night with the director of the Family History Training Center), who said that submission rules have in fact been changed as a result of beta testing. Second, the system’s rules appear more lax than the actual rules, which he summed up as follows: "Make them [names, dates, places] as complete as possible, but less than complete is accepted if you cannot find the information with a serious attempt."

Granted, the system can’t evaluate a “serious attempt.” However, Russell put it well when he said that NFS currently has no "reality check" and he was able to enter "wild" data. While NFS cannot guarantee that data entered is complete and accurate, it can provide strong encouragement by including more “reality checks” and cautions for obviously incomplete data. The place to eliminate duplicates is at entry, as much as possible, rather than downstream.

I really like rmrichesjr's idea of having GEDCOMs put in a holding area until the submitter checks for duplicates. I'm not sure I'd go along with banning all GEDCOM uploads, but I would limit them in size to help reduce the likelihood of mass contributions of questionable research. I'm not being negative, just realistic based on experience. (And I don't think the problem will ever go away, although it may be worse at first as everyone starts using the system.)

The time to make sure NFS meets its stated purpose is now, before it’s rolled out. How well we do our work here quite literally affects the situation of those beyond the veil waiting for ordinances (described by Elder Christofferson as "less than desirable." Not only that, Brigham Young taught that corps of temple workers will work themselves almost to exhaustion during the Millennium (can’t locate the source on that one right now but I will look for it if anyone’s interested). These two things make me feel that we need to do everything we can now to make our time count.

To that end, I hope these thoughts are helpful!

Kathryn

...The problem with names being sent to the Temple without enough research is not a problem relating to new FamilySearch, that problem has always existed. The only way to cut down on that would be to tighten the requirements on what information is required to clear a name. I don't think it is fair to say that this is a problem related to new FamilySearch...

I agree with this in that the problem is not the program, I guess I hoped that the program would address this important issue. I also agree that the requirements on what information is required to clear a name needs to be tightened up. I had suggested that the source information should be mandatory, so that those who view the information know from whence the information came and can agree or dispute. :p

I was talking to one of our sealers today and he was telling me about a name they had to do yesterday in the Temple:

A.L. Thorton married to C.

Both of the sealers just crinched.They did not want to do it. This is the type of information that needs to be challenged and dealt with in an appropriate way.

While the beta did allow you to enter names that had nothing to do with your family, the new site does encourage you to do the work for people in your own tree.

Put in another way, we are typically submitting names that are attached to a pedigree and not detached "just the information needed to do the work".

In this way, while the names submitted might be sketchy, they should be connected to better documented trees. To use your example, if this couple had a child Bill Thorton, Born 1860 in New York, (whose work had previously been done) that would make "A.L. Thorton married to C" much clearer.

As for doing names that are not part of your tree - I'm hoping that the approach the church is doing is monitoring the situation from the other side of the screen and arranging for follow-up action from the member's bishop or temple president if an "abuser" is found. I say this by way of pure speculation without any evidence. But I can say the beta system links the submissions to the members and can hold them accountable, even suspend their abilities much better then the current system can.

One concern I would have if the system forced names to belong to your tree before their work can be done is that someone who would ignore the existing screens to follow procedures, would likewise work around any restrictions the computer places in their path (the computer is not a spiritual authority figure). The result would be purely fictitious trees with real people in them. That would be a much bigger problem then we have now.

We'll see a few trees like that already from what they have been doing to try to link up families based on information submitted to the present IGI/OI.

Someone told me of a man who got a large amount of information on his ancestors, did the work, and about a year later discovered that the information he had been given was completely bogus.

So what might be done in the case where someone didn't know at the time, it all looked good then, only to find he had done things for nonexistent people, not even real people's names that were not on his family lines anyway? And in the above case, the person had no idea the data was bum until some time after all the work was done.

JamesAnderson wrote:So what might be done in the case where someone didn't know at the time, it all looked good then, only to find he had done things for nonexistent people, not even real people's names that were not on his family lines anyway?

My guess is the right thing to do would be to dispute the existence of the bogus people with a note sufficient to explain the situation to anyone who might stumble upon the bogus records later on. Depending on the situation, it might be better to leave the disputed records there or for the original patron to apply for ownership of what he had (unwittingly) submitted and delete the bogus stuff. Based on the NFS overviews, the key to that decision would be whether it is likely someone else will get the bogus info and try to use it as if it were true.

NFS is outsanding:)
The Guide for NFS needs work
Didn't get to work on the Last 2 Challes
Notification of Cut off is sill Lost! Oh well got my Christmass Card from support in Apr:rolleyes:
Ran into under Construction in "Help somone else use NFS"

For those of us that have been doing genealogy for any length of time, and have very neat and well maintained genealogy databases the process of using "new FamilySearch" (NFS) seems like we are going back to the dark ages. You have so much combining and organzing of your families to do in this system. The system doesn't work as efficently as our personal genealogy software programs do. Some seasoned researcher have concerns over people messing up their records and "stealing" their family history work.

BUT, to those that have never done genealogy (newbies) they will look at this as their way of finally doing genealogy, painlessly and from the convenience of their own homes. I watched my sister-in-law get so excited about genealogy when she sat and combined her family members together. (The key is to instruct them on what is a "good" match.) She could sit for hours just matching and combining her family members, a lengthly and frustrating project for me. Afterwards she felt a great sense of having done something - a feeling of Elijah. She heart was definitely turned to her fathers.

The "newbies" to genealogy will become the saving grace of this system. They will be the ones to share and contact other researchers to do more work on their lines and prevent duplication. I'm afraid I hear comments from more seasoned researchers that they don't intend on contributing all their information to NFS, only those names they want to clear and do temple work for. This will defeat the whole purpose of the system.

We will have to wait for the new generation to take over before this system mets it's full protential. The advancement of newer technology - the FamilySearch desktop project using FamilySearch API will have to be online and working before the more seasoned researcher will be convinced to use NFS. By the time the "newbies" to genealogy realize what real researching means they will be blessed to have the FamilySearch Scanning results online to access.

Just seeing the response by the youth in doing FamilySearch Indexing alone shows us how technology, the youth and those open to new ideas are the hope for the future. (Hopefully we all can fall into one of those categories!):)

Renee

rzamor1 wrote:For those of us that have been doing genealogy for any length of time, and have very neat and well maintained genealogy databases the process of using "new FamilySearch" (NFS) seems like we are going back to the dark ages. You have so much combining and organzing of your families to do in this system. The system doesn't work as efficently as our personal genealogy software programs do. Some seasoned researcher have concerns over people messing up their records and "stealing" their family history work.

If I have seen correctly, one option in NFS is to show only the user's own contributions rather than showing all available records. Perhaps that might be a solution for those who have their own clean data and don't want to see the other (messy for now) stuff.

Yes, that could be part of the 'viewing options' one could have available.

But it has its drawbacks, in that if you have a partial record and want to find out if anyone else has other information, or someone submits information you need, then it would not show that information right away and one might miss out on the data needed.

This will be more crucial when the world gets the system, and many more users than we might be thinking of in scaling the system up submit data and other users find the information useful in their research So there has to be a way to 'turn on' viewing the other records or the references to them. This feature might be considered like using freemails like Yahoo Mail or Hotmail. Those two services allow you to 'show full headers', or to only show the to, from, subject, and date lines as well as the body. I keep full headers up so I can properly report spam. But many more don't need that feautre activated right then, but have the option to show full headers if needed.

I am a new member of the forum, but an old family history teacher. All this discussion of more controls of what people can enter is a worthwhile concern, but as long as the member has the minimum data required and has done their best at finding it, their data should be accepted. Research is very important. Better training of those submitting names is the answer, but let's not discourage those who are trying to learn the system . Help them to understand what is needed and do the best they can. Just because all we know is the name is Maria and an approximate date should not keep her from her blessings.

My understanding is that one of the reason for such "low" requirements for approving a name for temple ordinances in the system is because people from all over the world will be using it to clear their names. The example given was countries like Africa where genealogy has not been written down but given orally. Only names are given and no dates or places so you need to be able to estimate that type of information so everyone in the world can submit their names for temple ordinances. If you put a lot of error messages and warnings about needing more information to clear names you are not thinking of the impact it will have to everyone in the world using the system.

The Church is already having the difficult task of deciding on time limits names can be held for temple ordinances. The needs are different around the world, not everyone can go to the temple on a frequent bases. I think right now it would be difficult to add the problem of different requirements for information needed for temple submissions because the impact is world-wide.

I think desktop interfaces will be the only solution to information requirements for temple ordinances. You could have requirements then based on the locality of the person submitting the information. Or the time frame in which records are available. For example: you should be able to get a wife's maiden name after the 1900s but maybe never get it in the 1700s.

You also need to have the ability to do sealings for people where the original records do not give madain names. You can have a good source record stating that there was a marriage of: Jane Hatch daughter of William and Anna Hatch on the 16 Apr 1662 with a spouse name, but all you have for the mother is Anna. In many cases this is the only record available with the mothers name. Should Anna not have temple work done for her?

Tthis is a common scenario, even in extraction work they found the records simply didn't give the maiden name of the wife. We'll see this come out more as we get some of those records indexed. Was seen alot in European and Spanish/Mexican records.

That being said, I've seen the opposite too, some records are very detailed. some of the Mexican records I loaded into the computer in the late 80s regularly had grandparents as well as the parents listed. And those will come out of the woodwork when they put up the trees they extrapolate from the data. And the wife's full maiden name was often listed on top of all of that.

I've been anxiously awaiting the rumored "online version of TempleReady" -- and, as a local FHC libriarian and ward family history instructor, fielding many questions from FHC patrons and others about all the rumors. This thread has been very illuminating.

My concern relates to the merge function which has been described by the beta testers. Although I use PAF as my primary genealogy program, I consider the PAF merge function to be its weakest function. I've spent (literally) hours rejecting "potential matches" such as Anna Smith matched with Amber Smelling -- but cannot get PAF to find such matches as Amber Smelling, born 1823 in KY with Amber Smelling, born 1823 in KY (yes, same parents, etc.). Thus, when I need to perform a merge, I port my data into Legacy, merge, then port back to PAF (am currently test driving Family Tree Maker for same function).

I am assuming that the match finding aspect of the merge function on the new Familysearch will be, fundamentally, the same code as PAF. Please tell me that I'm wrong -- that the match finding algorithm for Familysearch will be more accurate and efficient than PAF. I'm not hopeful, given the descriptions already provided on this thread. For example, Legacy will re-evaluate the data after every merge, offering additional suggested matches (vis-a-vis, "if these two individuals are the same person, perhaps the spouses, parents, and siblings of each are also duplicates . . ."); an earlier post suggests this feature is not built into the merge function for Familysearch.

This concern may seem trivial, but the fundamental purpose for this endeavor is to reduce duplication -- and without a good clean merge, duplicate data will not be eliminated, it will be proliferated. As one with many ancestors who have had their ordinance work performed more than 100 times, I'm very invested in reducing duplication and increasing efficiency.

Shanna

I have not used the merge functions in PAF, but what I saw in NFS is much better than you described. The code in NFS has to be drastically different from the code in PAF. For one thing, it is clear NFS has a much more complex data model. For another, NFS is said to be written in Java and running on Linux servers, and I seriously doubt PAF was written in an object-oriented language, let alone in Java.

NFS does do some re-evaluation as you seem to want. After merging a batch of duplicate records, NFS would find more potential duplicates for me to evaluate. When I would combined a person down to a single record, then combine his/her parents or children, sometimes that would bring in more potential duplicate records to consider for the first person.

Combining the duplicate records will be an iterative, time-consuming job. (It will be worse if a bunch of patrons blindly upload huge GEDCOMS without merging in their records themselves, but that issue has already been discussed.) The heuristics in the beta weren't perfect, and the system presented a few obviously wrong cases (but not very many). Based on what I saw in the beta that just ended, I think most of us will be reasonably to very pleased with it. And, the API and open-source client record managers will give opportunity to potentially improve upon the base web-based system.

The newFamilySearch function is much different than PAF. You are shown several possible matches at a time and can put a check mark next to the matches, then you are shown a split screen for each match to confirm that they are the same. Merges also do not actually merge the data, it just links all the duplicates together. There are links to some screen shots in some of the other threads, you can see some of the merge screens in those.

Here are some screen shots of the Merging: Screens More Screens

Gary's screenshots are great. There is one cool thing about merging that is not apparent from the screenshot. As you mouse over the names of the person, the spouse(s), the parents, and the children, all names that represent the same Person ID (PID) number are highlighted. If you combine as you go back, the children will be (mostly) combined as individuals before doing the parents. As you check possible duplicate parents, you can use the highlighting to see that the child named Son Smith on both sides is definitely the same person, which adds a bit more assurance that the possible duplicate records for Mother Smith or Father Smith are the same people. The highlighting is done by javascript in the browser, so it's very fast.

I looked at the screenshots posted, but find them lacking. Possible matches in Legacy indicate where information differs--relationships, various notes, places, templework, etc. With an automatic split screen to review the notes & sources too, I feel much more comfortable about my merging decisions.

While the formatting and handling of the information on the two sides in NFS may not be the same as you may be familiar with, basically all the information is there for you to compare. For many things, the user is better than software at comparing. For example, for a place name (birth, for example), one side may show a mix of city,nation and county,nation while the other side shows city,county. A human with at least a little familiarity with the location in question can decided almost instantly whether they are the same. Because NFS shows all submitted entries for names, dates, and places, this kind of sort-of-fuzzy matching happens a lot.

Another cool thing I did not see in the screenshots is the way to compare related people who don't (yet) have the same PID. Let's say you're comparing two versions of Son Smith vs. Sonny Smith. The two sides of the compare-to-merge panel show Son/Sonny's dates, places, parents, spouse(s), and children. If you click on a name, say his parent Father Smith or Papa Smith, that panel/window splits into a top half and a bottom half. The top half is all the same information for Son/Sonny as before. The bottom half is split left vs. right, too. Now, you click on a name from the upper-left part, Father Smith for example, and it shows Father Smith's info in the lower left. You click on Papa Smith in the upper right, and it shows Papa Smith's info in the lower right. This lets you compare in more detail the parents, spouse(s), and children of the records you're considering merging. I found it to be useful and believe it will be very useful in hard-to-decide cases.

Your comparison only addresses people and places. That is consistent with other descriptions that I have read and concerns me greatly. What about all of the other info in the database? I want to see --- side by side verically, so I can readily compare details line by line --- my various notes & sources. Some families choose from such a small selection of names that the notes are vital to determine one line from another.

You will be able to see much of what it sounds like you want to see. I have definitely seen things like life events, titles, and such in the main comparison panel. I did not specifically look for notes, because most of the existing records I saw in the system did not appear to have much in the way of notes. Of course, as diligent researchers upload GEDCOMS or enter data with notes and sources, that will change, and more notes and sources will be in the database.

I don't remember specifically testing bringing up the lower-half of the panel on the person being merged, but provided that works it would give you access to all the other individual details and other tabs to compare.

Worst case, you could make a note of the PIDs of the records being combined, go to those PIDs in the main window, and look at all the info on them one at a time.

As I have mentioned before, if the basic web-based system isn't entirely to your liking, the NFS API and open-source desktop record manager(s) will give opportunity to make a system that works as well as you want it to. My suspicion is the open-source record manager is going to end up being the method by which many of future enhancements make it into NFS as time goes on.

When you compare to merge, all the vital information is there. NFS (newFamilySearch) does not combine information, it links it together, so any notes and sources are added as additional information.

The API will allow programs like Legacy to add functions to their software to work with the NFS data, so you may be able to do all your work on NFS directly in a future version of Legacy, Family Tree Maker or some other desktop program, without ever needing to go to FamilySearch.

GarysTurn wrote:Here are some screen shots of the Merging: Screens More Screens

All I see are a bunch of Red Xs.

Edit: Now I'm getting "Undergoing maintenance". Must be something with the web site.

Those two links are working for me now as far as the slideshows, so what was not working?

scion wrote:Your comparison only addresses people and places. That is consistent with other descriptions that I have read and concerns me greatly. What about all of the other info in the database? I want to see --- side by side verically, so I can readily compare details line by line --- my various notes & sources. Some families choose from such a small selection of names that the notes are vital to determine one line from another.

Did you see this screen shot (top half) and this one (bottom half)? If you click on the Contributed By, I think you can get the details on the sources.

JamesAnderson wrote:Those two links are working for me now as far as the slideshows, so what was not working?

Working fine now. Site must have been down.

RussellHltn wrote:Did you see this screen shot (top half) and this one (bottom half)? If you click on the Contributed By, I think you can get the details on the sources.

As much as I'd like to help the poster seeking access to sources while comparing, I'm not sure this will suffice. During the beta, whenever I clicked on 'Contributed by', I got only a list of the people who had contributed the data, not the real _sources_ such as whether the birthdate came from a government birth certificate, a church birth record, or (a hypothetical) Aunt Sally's failing memory.

However, I do think we will be able to get at that information in at least one of several ways that I think I already mentioned.

rmrichesjr wrote:During the beta, whenever I clicked on 'Contributed by', I got only a list of the people who had contributed the data, not the real _sources_ such as whether the birthdate came from a government birth certificate, a church birth record, or (a hypothetical) Aunt Sally's failing memory.

I think that may have been a limitation of the Beta. Of all the databases pulled from, only PRF allowed anyone to say what the real source was. Had you pulled from another NFS user you probably would see their source notes.

RussellHltn wrote:I think that may have been a limitation of the Beta. Of all the databases pulled from, only PRF allowed anyone to say what the real source was. Had you pulled from another NFS user you probably would see their source notes.

The real sources (certificate, gov. or church books, etc.) were available by clicking on the link to the right of the datum (place, date, name, etc.). That should be available in the 4-way split panel, in the 'individual details' tab of the lower sub-panels, when comparing to combine duplicate records.. In any case, I'm looking forward to the real, live system!

Here are some more screenshots showing sources and notes in NFS. Screenshots

GarysTurn wrote:When you compare to merge, all the vital information is there. NFS (newFamilySearch) does not combine information, it links it together, so any notes and sources are added as additional information.

The API will allow programs like Legacy to add functions to their software to work with the NFS data, so you may be able to do all your work on NFS directly in a future version of Legacy, Family Tree Maker or some other desktop program, without ever needing to go to FamilySearch.

Question: Can you "unlink" people?

The New Family Search has been rolled out to at least two Temple Districts so far. Was the beta testing that was done just a stamp of approval? Or was it a simple case of the developers really believing that it was ready?? I know that there would have been pressure from further up the line to get this out ASAP. Would the programmers have had time to fix all the issues that it had in such a short turn around time?

thedqs wrote:Question: Can you "unlink" people?

Yes, you can unlink people. Given the likelihood that some (hopefully small) fraction of the merge operations will be wrong, an unlink facility is necessary.

However, in the Feb-April 2007 beta, the unlink facility was not very easy to use. A lot of people are made up of over 100 records (I saw about 360 on one). The unlink facility shows you five at a time, and during the beta it took a good 10-20 seconds to move one step. Then, you can only separate out one of the records. So, if you need to remove the last three records of somebody made of 150 records, it's going to take a couple of hours.

During the beta, I submitted a suggestion for improvement, so let's hope something is done, either in the basic web-based system or through the API.

sbarnsley wrote:The New Family Search has been rolled out to at least two Temple Districts so far. Was the beta testing that was done just a stamp of approval? Or was it a simple case of the developers really believing that it was ready?? I know that there would have been pressure from further up the line to get this out ASAP. Would the programmers have had time to fix all the issues that it had in such a short turn around time?

That's cool that the system is going live now!!! There is a "special" beta going on April 30 through May 2 to check specific things in the "final data load." Somewhere, I heard it will take about 18 months to from first temple district to last district to go live with the new system. I also heard that there were a number of issues with the system (and saw and reported a few) but a decision was made to go with what they have. The response to some of the issues I reported was that the issue would be fixed before release of the final system. I hope most of the fixes made it (or will be added before too long).

While I have expressed concerns about the beta, I think some of the bigger ones are being handled at a different level then the technology visible in the beta. I think everyone agrees there is room for improvement, but I think the second beta probably showed that it's "close enough" to get started.

Keep in mind that in the current situation, not all of the FHCs may be checking against the on-line IGI resulting in a lot of duplicates. The "cost" of a premature roll-out has to be balanced against the "cost" of delay.

Over all, in it's current state, I consider it a step forward for reasions that may not be obvious.

Someone who I know who tested NewFS had two issues that are to me rather glaring, who can I contact to get the word to about the problem as that person got no response during the beta. The bigger one has to do with combining names.

JamesAnderson wrote:Someone who I know who tested NewFS had two issues that are to me rather glaring, who can I contact to get the word to about the problem as that person got no response during the beta. The bigger one has to do with combining names.

I don't know anyone to contact. My guess would be that the report(s) your acquaintance apparently made through the beta test feedback mechanism will do the most good that can be done.

Yes, there are a few issues related to combining. I reported a number of issues and have described in this forum a few I saw.

If you would be willing to describe exactly what the two issues are, perhaps those of us who were/are beta testers could tell you about any response we may have received if we reported the same or similar issue. Or, perhaps we could explain a workaround we may have found during the beta test.

Here then are the two issues.

1. Combining names when the order of the names was entered into a previous submission by mistake. This person had a hispanic husband who is long since deceased. He entered some things into PAF and sent them into one of the legacy databases where the records now sit, awaiting proper combining. Basically, it's like John Smith was entered Smith John, and she wanted to find some way of combining them so that others know this was the same person, John Smith rather than Smith John.

2. There was an excommunicated member in her line that had the work done for them after the individual involved died. Apparently it would not let her combine the record for some reason. If this isn't enough I'll be talking with this person tonight and I'll be able to get more on this particular issue.

JamesAnderson wrote:Here then are the two issues.

1. Combining names when the order of the names was entered into a previous submission by mistake. This person had a hispanic husband who is long since deceased. He entered some things into PAF and sent them into one of the legacy databases where the records now sit, awaiting proper combining. Basically, it's like John Smith was entered Smith John, and she wanted to find some way of combining them so that others know this was the same person, John Smith rather than Smith John.

2. There was an excommunicated member in her line that had the work done for them after the individual involved died. Apparently it would not let her combine the record for some reason. If this isn't enough I'll be talking with this person tonight and I'll be able to get more on this particular issue.

I don't see enough information about issue 2 to have an understanding of what might have been wrong or what could be done as a workaround. I do know there are were some issues in the Feb-April beta (beta2, I think) that prevented combining of some records. I reported one such case, was instructed to combine the children and try again. (I would also make sure the parents and spouse(s) were combined, too.) In the regular beta, it never did let me combine the "Unknown name" wife with the named wife. I plan to revisit that case this afternoon in the special test of the "final data load".

Let me see if I understand issue 1: Is it the case that both records are in NFS, but the names are different enough that NFS is not finding them as possible duplicates? Is it also safe to assume that one of them is in your pedigree, with children listed? I would try a few things, and I think they would eventually allow the records to be combined. First, I would add another opinion to both records giving the exact same name.

Second, and probably more likely to succeed, I would use the "find a ..." links to connect _from_ the one not on your pedigree _to_ someone who is, preferably a child. I think that should turn on the "multiple parents" asterisk. I would use that to combine the records as a parent of the child you linked to. I'm fairly confident that should allow combining as individuals, and from there you're home free.

Third, I would use the "find a ..." links to connect _from_ someone who _is_ on your pedigree _to_ the record that needs to be brought into the fold. Between these three methods, I'm pretty confident you can bring the record into your pedigree and combine it up.

I think something is going to work regarding my item 1. Thanks on that.

For the second item, it's a little tricky. The person was baptized and endowed, etc., in this life but at some point was excommunicated, then after his death he was rebaptized at a temple.

The problem comes when they wanted to combine the two records. One shows that the person was excommunicated, that was in the Deceased Member Records. The other record showing the rebaptism in the temple was on the IGI.

What seems problematic is combining the two to show that they are the same person. It's the excommunication information that is tripping things up although the person is dead. Is there a way to combine the records but leave the gory details regarding the fact that the person had before death been excommunicated?

The system will combine the records, but makes everything private because of the above matter. They didn't want to make things private since the individual was dead, so they are awaiting anything that might help in the matter although they would be OK if the excommunication note was left out .

That sounds like a question/issue to be brought up with the support folks. There's a chance the system might not yet handle those more difficult cases in the way everyone concerned might prefer.

I'll have the person that gave me these two things call the support people then. Given the Beta 2 is over, who or what area should she ask for?

JamesAnderson wrote:I'll have the person that gave me these two things call the support people then. Given the Beta 2 is over, who or what area should she ask for?

I don't know. I suspect the next opportunity to work with the support folks on that issue will be after the system goes live for real.

Earlier, I believe you said they could combine the records, but then everything went private. I would guess the worst case would be that they would have to take that situation (everything went private) and add as notes the information they wanted to be visible.

By the way, I ran into a case that will probably require manual fixing of Church membership records to get things right. One person has a possible duplicate (a total of two records for one person). The system won't let me combine them, because they both contain Church membership info. Everything shows him with a marriage date in 1867, all records pointing to the identical spouse. The main record shows him born in 1844. The (other) Church membership record shows him born in 1884. I'm guessing that was caused by a slip of the finger on the keyboard during data entry from paper membership records. The training materials said something about a process for having support look at fixing errors in Church membership records for deceased people. I'm guessing that's what will need to be done.

How does one go about becoming a beta tester for the church. Specifically, the family search site?

Mr. M wrote:How does one go about becoming a beta tester for the church. Specifically, the family search site?

During the times when beta testers are requested, a survey is available for interested volunteers. It asks both demographical questions & computer system (i.e.: type of computer, internet connection type, etc.) questions. Those not selected never hear from anyone regarding their application. Those selected are then contacted for the beta. To my knowledge, there is no present beta testing for the general public.

Actually the New Family Search is live and if it is avaliable in your area (they say your priesthood leaders will inform you that it is) then you can go to http://beta.familysearch.org and register. (You can also go there and try to register but if it is not avaliable in your district yet it will tell you so).

So in 18 months it should be avaliable for all to use.

Mr. M wrote:How does one go about becoming a beta tester for the church. Specifically, the family search site?

You can register to participate in future testing at: Register Hereto help test newFamilySearch improvements. I have noticed that some of the questions links don't work all the time in IE7. They work for me in Firefox but not in IE7, sometimes they work sometimes not in IE7. If the questions links don't work for you, there is more info about testing here. There are also links to more information about newFamilySearch here.

You can also see future projects for newFamilySearch at FamilySearch Labs.

Thank you for all the links and information. I will look forward to helping if I am allowed.

thedqs wrote:Actually the New Family Search is live and if it is avaliable in your area (they say your priesthood leaders will inform you that it is) then you can go to http://beta.familysearch.org and register. (You can also go there and try to register but if it is not avaliable in your district yet it will tell you so).

So in 18 months it should be avaliable for all to use.

I have read on other sites that some Temples are online. Does anyone live in a Temple district that is online.

I did not get to the NFS beta in time so the only information I have to go on is the screenshots from this forum. Can anyone update me on how historic placenames/placename changes are being considered? I am unaware of any historic placename mapping/tracking applications.