I do not like the new merge feature that is in place.

LegacyUser

Ann Monson said: I had no idea that the merge feature was changing. I don't like it.

LegacyUser

Jordi Kloosterboer said: Very informative post...

LegacyUser

Terra Flores said: I said the same last week with writing in a problem ticket to FamilySearch. The response was that I should follow the prophet and not question.

This has nothing to do with following the prophet. I gave feedback. If FS doesn't want feedback, don't set up the mechanism to get it and give the false impression that you care about feedback.

This change to merging was unnecessary. Very poor user interface. It takes 3 times as long, with the three screens, to merge. Very confusing. Years of merging from right to left is now flipped? With multiple additional changes. There's no need for this. If this change is super confusing for long-term members using FS, how can it be easier for new people (that was some of the reason that was given to me from my problem ticket) -- makes no sense.

Also, the font is very large -- harder for your eye to compare. More scrolling. Just very poor UX. It needs to be rolled back.

Note to FamilySearch, continuing to change just for change sake isn't helpful.

LegacyUser

Jordi Kloosterboer said: Wow, FS personnel should not have said that. BTW they didn't change it just to change. There are at least two reasons they changed it. 1) To lessen the amount of wrongfully made merges and 2) to help with loading it faster on slower connections. But yes, many changes should be made still to improve it including to make the site as one cohesive whole.

LegacyUser

Paul said: I agree with Jordi. This feature certainly needed a change as it used to be far too easy to make incorrect merges.

The longer process can only be a good thing if it provides more opportunity for users to weigh-up the correctness of the merge. Also, as shown at https://getsatisfaction.com/familysea..., there is now a warning header when the system picks up on a possible merge that needs particular examination before proceeding.

However, other users have highlighted some problems, which will hopefully be addressed. These include the (worrying) opportunity to "Undo" certain items, which will no doubt lead inexperienced / careless users into failing to carry across perfectly correct information during the process. Having the surviving person on the right side has also been criticised - perhaps unfairly, but one has to query if this change was really necessary.

Experienced users need to take a share of the "blame" for some of the problems, as I believe we were advised the new feature was being rolled out and available for testing in the beta version, yet I don't remember much negative feedback until it went "live".

Hopefully, the developers are open to positive criticism and will make the necessary tweaks to what is a well intentioned enhancement. I'm confident, with a few adjustments, there is a good chance this enhancement will lead to a lot less bad merges being carried out in future.

LegacyUser

Terra Flores said: Where do they announce beta testing? I've been on FamilySearch since 2013 and have no knowledge of where that would be announced.

There is also no recent blog post on the update, so people have to figure it out on their own. For a major change like this, one would think that a blog post with step by step would be a good post.

Developer recommendation: Many websites allow for you to toggle back and forth between old and new versions and give feedback. This would be highly recommended for FS. It would provide you with the next step after Beta and lead you to a better product.

Also, ultimately this is not about how long or challenging we make the merging process but rather how accurate. Making the merge process more complicated and lengthy to dissuade people from doing it does not achieve accuracy. Making it less user friendly does not achieve accuracy. Yet, complicated and more difficult can certainly dissuade people from ever getting on FS again. It can also make it more challenging to train people, again causing them to lose interest. Most people are tentative anyway (I've worked with so many as a family history consultant) when it comes to changes, and they will look for any excuse to not move forward once they don't understand. UX matters.

LegacyUser

joe martel said: You can use the beta.familysearch.org site most any time. Use your same login and password. 

Beta gets loaded with a snapshot of the production data a couple times a year. Since beta is not production you can try stuff out and learn how to do stuff with affecting the real familysearch.org site.

One thing, beta does not always operate well and may have way more bugs than the main site, especially when doing things that cross multiple services and features. Engineers use beta to test new code and requests to fix bugs on beta are very low priority. 

Rarely if ever has there been announcement about something new on beta. Sometimes users will discover new things under development and tell their friends to give it a try. When new features are being developed I enjoy welcome the feedback.

LegacyUser

Jeff Wiseman said: Terra Flores,

I don’t know who told you that, but I think it was ridiculously presumptuous of them to assume that President Nelson is looking over the shoulders of the FS developers and spelling out exactly what the User Interface should look like!

I’m sure the leadership of the church simply assigns general mandates to FS, and FS uses their own knowledge, skills, and inspiration to meet the goals set by the leadership of the church. We know that one of those mandates was to reduce the amount of duplicate temple work that was happening.

Another was to engage as many members of the church as possible in doing their Family history. That means providing a tool that can be used by anyone from their early teens and up. This includes MANY people who are NOT computer savvy to the EXTREME.

These are really tall orders, and are the reason you see changes like these being made by FS.

If this change is super confusing for long-term members using FS, how can it be easier for new people?

There are two VERY good answers to this:

The first is that it is always easier to start fresh in learning something, than to have to change from doing something that you know very well and has become habit. It is always far more difficult when learning how to do something new, if you first have to unlearn how you used to do it. You have to undo all of that previous training, experience, habit, and pre-conceived notions.

The second reason may simply be that FS has just made some mistakes! :-) There’s nothing wrong with that as it is just part of the learning experience that the Lord has always require of his people and their organizations. That is also why it is important for us to continue providing feedback on this forum to help FS in their design decisions and learning process.

Although my personal view is that FS has made MANY poor user interface decisions, I do know that the choice to make changes in the merge function is based on a few solid ideas. The following are what I understand so far:

1. Inexperienced or non-caring patrons can tend to buzz through the merge process without enough consideration to information that is available. In a few seconds a person can create enough damage in the database this way that will take many hours (if not days) to correct. The fact that it takes longer to go through the merge process is a new design decision to help mitigate the problems caused by bad merges.

2. Process and information flow diagrams typically move from left to right and top to bottom. Furthermore, the mobil apps already do this and so the reversal of direction in the merge windows is partly based on these facts.

3. FS is developing a new common set of user interface functions to be used across the whole website. The merge function is the first section to use these new routines (e.g., the squared off instead of rounded items in the display).

4. In the old merge, when duplicate parent or children relationships existed on both PIDs being merged, people were not bringing those duplicate relatives across during the merge. As a result, all of those records were being cut free from the tree and left to float forever in the database, unattached to anyone. With their relationship information now gone, there frequently is not enough information left to identify them as duplicates in order to merge them into where they belong. If they had already had ordinance work done, that work will now be done again for their duplicates. The new merge now defaults to always bringing those duplicate relatives across the merge so that they will now be seen in an obvious fashion in the family memberships area. When entire families have been duplicated (especially from data loaded from outside of FS — e.g., GEDCOM or syncing from 3rd party sources… [truncated]

LegacyUser

Jeff Wiseman said: Terra,

Please see my Reply below...

LegacyUser

Jeff Wiseman said: Remember that speed bumps can save lives. Some places need to mandate that people slow down in different areas to mitigate damage.

LegacyUser

Tom Huber said: The older we get, the more resistant to change we become. We often see change as "change for change's sake" and express dislike.

Whenever we offer feedback, it needs to be precise and to the point, and not a generalized, "I don't like it." The I don't like it is something we all understand, but there is no response that can be given to address the actual concern or problem.

On item 2 of Jeff's excellent response -- the source linking feature has used the left-to-right process for a very long time and we've been told (I don't remember which FamilySearch representative said this) that the left-to-right process was instituted to provide the user with a consistency.

But even more important is that there are a number of new features that will help immensely -- one of them is date consistency -- especially with the birth date. I did a merge a day or two ago and the duplicate I was merging had a difference of three years in the birth date -- the system flagged that difference!

That's a good thing because there are instances where a child is born to a family and dies and then the next child that is born gets the same name. We see, from time to time, those two children merged, when they should not be. The flagging of the difference in birth dates is crucial in getting the user to rethink their actions.

That's just one example that points out how good this new process can actually be.

We resist change and eventually when we see the benefit of the changed system, we accept it.

I"m in my 70s and do not like change, but some change is very, very good, so I'm open to it. If it doesn't work, I tend to be very vocal until I either accept it or a specific problem gets fixed.

LegacyUser

Ann Monson said: I kind of jumped too fast in saying I didn't like the change. Since I've used it for a few days, I have become more used to it now ...my only frustration is it's 3 pages now. I like how it's merging everything over so information isn't lost. I like the notice of the timing difference.

I just wish it hadn't sprung on me and took me by surprise. No tutorial. No notice.
I was surprised to see all the above responses and learned a thing or two.

My next situation....standardization. I wish people were taught at the beginning how to enter places and dates. I hope every one knows...full spelled out dates...no shortcut on months...no solid capitalization. On place, it's city, county, state, country. I do alot of standardizing. There is a link to push to make it standardized. I enjoy doing genealogy, it makes me happy.

LegacyUser

Brett said: Ann

As an aside ...

"Standardisation" ...

In regard to 'Dates' ...

I hope that your implication is that a 'Date' [ie. Full 'Date' = 'Day' (numeric) 'Month' 'Year'] with other "Details" is ACCEPTABLE, as entered (which remains); and, then, "Standardised" as/to just a " 'Day' (numeric) 'Month' 'Year' ".

I have 'Dates' that include the "Time" of, 'Birth'; and/or, 'Death'; plus, other "Details"; where, those 'Dates' (as entered) are "Standardised".

In regard to 'Place' names ...

I hope that your implication is that a "Full" Address with 'Street Number' (and, sometimes, 'Building'; or, 'Hospital'; or, 'Nursing Home'; or, 'Institution'; or, 'Cemetery', name included) and 'Street' and 'Suburb' with the 'City'; 'County'; 'State' and 'Country', is ACCEPTABLE, as entered (which remains); and, then, "Standardised" as/to just a 'City'; 'County'; 'State'; and, 'Country'.

I have many 'Place' names that include the "Full" Address with 'Street Number' (and, sometimes, 'Building'; or, 'Hospital'; or, 'Nursing Home'; or, 'Institution'; or, 'Cemetery', name included) and 'Street' and 'Suburb', with the 'City'; 'County'; 'State'; and, 'Country'; where, those 'Place' names (as entered) are "Standardised".

Of course, those aforementioned 'Place' names as entered and "Standardised" do not have the "Map" 'Pin' beside them; but, they are still "Standardised"; and, they do appear on the "Time Line".

Just curious.

Like you and many others, I too like doing Family History/Genealogy.

Brett

.

LegacyUser

Juli said: You do realize that the displayed place or date does not need to match the standardized value, right?

LegacyUser

Jeff Wiseman said: I've started trying to use those terms more consistently in explaining things. This just gets to be confusing for the uninitiated since FS does not use them consistantly, so I hope that this shift in explaining things helps others :-)

The Standards database contains all of the the "Standard" places with their associated names and alternates. You "Standardize" a place by attaching a "Standard" name from the database to it.

After you have done this, you then have a "Standardized" name being displayed. As Juli pointed out of course, you do NOT have to make a display name identical to a "Standard" place name from the database in order for it to be "Standardized". It only needs a "Standard" name attached to it.

You do NOT need the map pin icon to be present for a place name to be "Standardized"

An "unstandardized" display name for a location or date will ALWAYS be marked as a data error (i.e., the red exclamation mark). A Standardized location will not have the red mark. A "Standardized" location MIGHT have a map pin icon, but frequently, it will NOT have a map pin icon

Now of course, the website and articles discussing these things will haphazardly scramble the use of those terms in an inconsistent fashion such that it totally confuses everyone.

And lastly,

If you are walking through the system changing place names just so that they will have a map pin icon being displayed, then you don't know what you are doing, and you are likely DESTROYING useful and important information!

LegacyUser

Tom Huber said: Ann, unfortunately, the three-letter all caps month indicator is somewhat of a standard for GEDCOM files. Because of this, I often see dates using the three letter designation (either as all caps or as upper/lower case).

FamilySearch does not use text for dates, but it does use a number designation when the computer can use in searches, comparisons, and so on. In addition, dates can be expressed as year ranges -- such as "from 1615 to 1625" and that is represented as a standardized date (see the birth year for Pieter Claesen 9312-XFX. When you press edit, you'll see that the date is set to that range as a standard. -- It is a rather uncommon situation because of a fraudulent genealogy (by Gustave Anjou -- see https://en.wikipedia.org/wiki/Gustave....

There are details as to why a range is being represented and it has to do with no surviving sources (Pieter was born during the 30 years' war right in the middle of the conflict), and circumstantial evidence.

I tend to correct dates to the standard, unless it is a situation like that of Pieter. But for places, I go for the most accurate place, even down to a street address, if known. The standard that I use is the most accurate I could find. In the case of Pieter's birth place, I standardized it to The Holy Roman Empire because nothing else came close to the most likely place where he was born and/or lived.

LegacyUser

Paul said: With use, the new merging tool is proving to be much better than the previous one. Okay, I still don't see the advantage of the "Undo" feature, as it can discourage further investigation about the person(s) / facts being rejected. The place to "undo" relationships must always be on the person page.

But, apart from making us give much more detailed consideration to the correctness of the merge, there are positive features like the warning illustrated below. Overall, I think it offers a good opportunity for more accurate merges and - with a few tweaks - it will prove to be the best enhancement since the "Exact Searching" feature was updated about 5 years ago. (Please don't take a backward step on that one, developers!)

LegacyUser

Paul said: Further to comments above, here is an example of what I believe is a negative part of the new feature - the "Undo" option. Why should I not carry over Frances Hepplewhite? She is a duplicate (same marriage event) in the same way as Magnus Miller, so I believe she needs to be moved across and merged with her duplicate later. Rejecting children at this stage could be far worse, as many users would forget to go back and try to find their true parents (if they are not part of the family). If they are duplicates, again I believe the merges are best carried out (one by one) from the relevant person pages.



Same applies to being able to reject parents - the way to investigate all relationships should be by careful examination from the person page(s).


(Sorry if I am wrong about being able to reject children by using "Undo". I can't find any examples so can't be sure if the user IS able do that. Doesn't alter my general worries about "Undo", though.)

LegacyUser

S. said: A happy middle would be let People choose their own Font and size on the page, but due to Programing Languages, not sure if they can do that.

LegacyUser

Andrew McMurry said: Hi Terra, can you share the whole context of the response?

LegacyUser

Jordi Kloosterboer said: You can easily do that with javascript depending on how they have implemented their fonts. I just don't think they would do that. But I think it is a cool idea.

LegacyUser

Andrew McMurry said: Hi Terra, can you share the whole context of the response you got?

LegacyUser

Terra Flores said: The poor customer response at this point is not the point. The point is better UX and to meet the accuracy goal with the most ease possible.

LegacyUser

Jeff Wiseman said: The undo is necessary because it is on ALL the carry-overs including the ones you accidentally carry over.

However, I wouldn't complain in the least if they REMOVED the Undo from relationship Specific vitals. That would force the users to "merge then cleanup", "merge then cleanup", etc. without accidentally losing PIDs (possibly carrying completed ordinance work) in the system.

LegacyUser

J. Matthew Saunders said: An issue I just encountered that shows further inconsistency and maybe already has been brought up is 1st page showed siblings of the person I'm working with, then on the second page the siblings do not appear and then they appear on the 3rd page. Too much inconsistency still exists with this merge tool! I've taken a few days away from it just to keep my head on....

LegacyUser

Jeff Wiseman said: I suspect that on the second page, they were automatically moved over to the right side already (they would show up in green on the right side). This was a very intentional feature (that we certainly need to keep) because people kept forgetting to bring ALL relations over during the merge.

However, there is a problem with the left-side and right-side not lining up right now, so the fact that they may have been shifted a long ways down on the right side (and out of sight, probably hid the behavior, exacerbating the issue that you saw.

The automatic carry across for relations is totally intended.

The misalignment of left and right columns is a problem FS is aware of I believe. It really does need to align the way the old merge did.

Now if they really were NOT on the second page (in either column), that would be a significant problem that would need to be fixed.