new FamilySearch Beta2 Complete

[rmrichesjr]

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.

[KathrynGZ]

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

[rmrichesjr]

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.

[russellhltn]

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.

[KathrynGZ]

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

[KathrynGZ]

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

[garysturn]

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.

[kennard]

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

[rmrichesjr]

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.

[JamesAnderson]

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?