Commentary on the New Change Log

LegacyUser

Gordon Collett said: With the recent up date to the change log, there have multiple posts about problems with the change in formatting and information in the previous change log no longer being present as was as it being much more difficult to use. There have been concerns about too much white space, changes in font size and color, and feature losses.

Taking advantage of the major bug that quickly appeared, during the repair of which caused the new page to come and go, to grab some screen shots of the same change log in both the old and new style, I’ve decided to do an in depth comparison of the two styles in an effort to identify what people may not like about the change when they have stated such with no details.

My example is, admitted, rather simple. I created a new child in a family from a census entry, found his birth record and added birth and christening information from that and added it as a source. Then discovered a partial duplicate for the family I added him to and merged first his mother with her changing to the ID for the duplicate mother, then his father with him keeping the ID of the father I originally added the child to.

Here are the two change logs side by side. The commentary will stretch over several posts so I don’t exceed text length constraints. In the following sections I have added a third column I have put my suggestions for what I would consider further improvements.

LegacyUser

Gordon Collett said: Just creating the person from the Add Child screen results in a change log entry for each piece of information added. Both styles take the same amount of room within a couple of pixels and have the same amount of white space. They just use it differently in that the date of the change and the contributor’s name have been moved from the left hand column to a third column that I don’t show here.

The text font and color of the actual data was not changed. In some places it looks a little bigger. It looks lighter in the new version due to the changed contrast with the label for the data which is a little bigger and is now darker and in bold.

The dark, bold label draws my eyes directly to the label which I like because it makes it easy to find.

I must say that I do not care for the change to the generic “Vital Added” in the left column. It was very easy to scan down the left column and read, as is normal, from left to right, “Name Added” and not bother reading the redundant but nice to have present data label. Now, I find myself scanning down the second column due the the intensity of the data label and needing to read backwards, right to left, to read “Name Added,” ignoring “Vital” because it gives no additional information.

I think this need to read right to left is going to be a long term annoyance. Otherwise this sections really has minimal changes.


(Click on image to enlarge)

LegacyUser

Gordon Collett said: The next sections show that adding this child to his parents created two entries in the change long. A nice improvement is that the IDs for the parents show and the relationship to the parents shows without have to click on the “Show Relationship” link.

The update, however, is confusing because “Father Added” and Mother Added” have been replaced with “Relationship Created” with no indication as to why there are two identical appearing entries and no indication of who the created relationship was with.
While there may have been a good reason to change the title to the generic Relationship Created, it would be very helpful to have some type of indication as to what that relationship was such as the check mark that was used when a relationship type was added.


(Click on image to enlarge)

LegacyUser

Gordon Collett said: The entries for changes to information, as with adding information, have not really changed except for replacing the specific title “Birth Changed” for the generic “Vital Changed” and putting the label “Birth” in bold font, once again triggering the somewhat awkward need for right to left reading.

The entry for having added a source also just has the mild changes in format. The only comment for here has been posted several times already. It would be nice if the source title was still a link to the source or if the source could be expanded and fully viewed. This would be more important for sources that have been detached since the only way now to evaluate such a source to see if it was detached in error is to reattach the source, examine it, then detach it again.


(Click on image to enlarge)

LegacyUser

Gordon Collett said: Finally, for now, this next section actually brings up a long standing point of confusion that existed in the old change log as well. Namely how a merge for a parent affects a child’s change log.

Unfortunately, I do not remember exactly the course of events, but I think it was that I found a duplicate of a sibling which I added to the family by first merging the duplicate mother and having the duplicate mother be the survivor then merging the duplicate father and having the existing father be the survivor.

Both the old and new change logs just show a somewhat mysterious sequence of added and deleted relationships. The new change log is worse in that it doesn’t even indication which relationship, to the mother or father, was added. The only thing that indicates this was a merge is that the reason statement for the merge appears.

Something else here that is just confusing is that the reason statement for the merge often does not make sense in the current context: “Relationship Removed.” Reason? “correct parents.” Changing the title for the section or some other modifications are still needed here. I need to do some more testing to see how various types of merges appear in the change log.


(Click on image to enlarge)

LegacyUser

Gordon Collett said: Sorry about any typos in the above series. I see a few already but as a multi-part post, I can't go back and correct them now.

LegacyUser

JT said: Any explanation / reason-statement that is only two words is way too lazy, despite how good or bad FSFT puts them into a context. This highlights the need for well-thought-out explicit (paragraph-size) reason statements. I refer you to the principles in the GPS (Genealogical Proof Standard).

LegacyUser

Paul said: Regardless of any standards (GPS or otherwise) I don't consider it "lazy" to use two or three words (say, "same family" or "same child / event") when undertaking a merge. Very often the two IDs have been created solely on the basis of a (duplicated) source. If I put "same event" I am confirming details against the individual match exactly - e.g. "John Brown, son of William & Mary Brown, baptised 13 April 1805 Hart, Durham" is the only detail attached (as / from a source) against both IDs. What more do I need to add to confirm the validity of the merge? Once merged, users will see the two sources with exact, matching detail, so I feel no extensive explanation is required at all in circumstances like this.

Where appropriate, I would provide a reasonably lengthy reason statement, but not where duplicates exist on a basis that was never envisaged by any external body (e.g. ten separate IDs being automatically created by a program for a William Brown, one for each time he appears in the christening source of one of his (ten) children.)

LegacyUser

Don M Thomas said: I will admit that when I was merging, (the 3 or 4 that I did), I just put in a period, which I guess makes me very lazy.

LegacyUser

Adrian Bruce said: I can't quite envisage exactly what would be done to add those parents but that left-column doesn't make sense. If there were 2 relationships created, one after the other (first the mother, then the father) then how can the first relationship show a father? He's not been added yet?

Conversely, if one "transaction" added both relationships, then why are there two entries?

I'm fairly certain I've looked at this sort of thing myself and wondered why on earth the creation was repeated? I just hadn't analysed it that deeply.

LegacyUser

Adrian Bruce said: "“Relationship Removed.” Reason? “correct parents.”"

Is that an artifact of the reason, i.e. "I am correcting the parents"
or is something awry, i.e. "These are the correct parents so I am removing them". Huh? No, surely not!!!

LegacyUser

Gordon Collett said: The "relationship removed" was the relationship to the parent that was deleted in the merge for that parent.

To keep this simple, I won't use names.

I had added child K to his correct family with parents Father A and Mother A.

Then I found a duplicate of K's older sibling who had parents Father B and Mother B. I'm fairly sure that I then merged Mother A into Mother B, with Mother B as survivor, then merged Father B into Father A, with Father A as survivor.

This gave to child K as parents Father A and Mother B. The relationship removed was child's K relationship to Mother A.

Since there is no indication in child K's change log that a merge had occurred, this is always going to be confusing unless we all remember to always begin the required reason statement on Page 3 of the merge process: "I am merging Mother A into Mother B because...." Which no one will ever do because why would anyone think one needs to announce one is performing a merge when one is sitting here?

LegacyUser

Adrian Bruce said: "Since there is no indication in child K's change log that a merge had occurred"
Ah - that seems like a good explanation. I have evolved a rule of thumb that says if something has been deleted or removed, then don't panic because that's probably a downright lie - it's probably a merge.

Explaining what's happened shouldn't be too controversial - I know that it's no longer just bang, bang, list the changes but it really is misleading right now. Your third column suggestion sounds good.

LegacyUser

W David Samuelsen said: The worst of all - hunting for the merges because there are BAD merges to undo!

They need to be clearly marked (the old method, shows green frame/brown frame for merges.

Now with that change, I had to use CNTRL+F and enter the word, to find them!!!

LegacyUser

JT said: Paul - it may not be obvious to the in-a-hurry reader to guess how you got to that conclusion of how they were the same. Please identify how many (& what) things did or didn't match in your mind at the time.

LegacyUser

Juli said: The problem with "same family"-type reason statements is that they get slapped on the change logs of relatives (usually children with merged parents) with no other context (and alarming labels like "relationship removed"), leaving one yelling at the screen: "WHAT is the same family as WHAT??".

Take the time to write it out: "Merging baptismal-index-based duplicate parent Fred Blogs PID1 into Fred Bloggs PID2." It'll still show up in weird places without context, but it'll be _useful_.

LegacyUser

Paul said: I guess that is the advantage of "copy and paste"! What you suggest is okay for one-off merges, but more often than not I have to merge father, mother and child(ren) duplicates. I suppose I get so exasperated that FamilySearch / GSU earlier programs have generally created this situation that I am reluctant to put too much effort into a situation I feel should never have arisen in the first place. I accept the earlier programs (nFS, etc.) worked in a totally different manner from Family Tree but, boy, have this created a tremendous amount of work with the resulting necessary merges!

LegacyUser

Adrian Bruce said: I do feel that it would be helpful for FS to put a starter text into the merger reason that reads "Merging PID1 Fred Bloggs into PID2 Frederick Bloggs because... " - then adding our specific reason would be easier. While this might be obvious from the Change Log for PID2, it can also be copied for others since normally I tend to merge a family trio of 2 parents and a child. All the hard identification work has been done with the first merge so it makes sense to refer back to that first merge.

LegacyUser

Paul said: Agreed - but did you have to respond so quickly? Called to the phone and didn't have time to correct my grammar / typos!

LegacyUser

Tom Huber said: What happened to the Merge filter on the new change log. It was there when I explored the log a week or so ago, but now, when I was looking for the merges with Andrew Cruikshank KNJD-D1W, It is no longer listed as a filter.

Chrome on a Windows 10 computer.

LegacyUser

Tom Huber said: Same issue in Firefox.

Person Not a Match is a filter, but not Merge.

LegacyUser

Tom Huber said: Starting a new thread.

LegacyUser

Tom Huber said: False Alarm. This was noted as missing when I first explored the change log. It is really needed for Andrew, since a lot has happened and I need to figure out if the Scottish Andrew was merged with the Andrew who is my ancestor.

LegacyUser

Paul said: Yes, I believe the omission of Merges from the Filter options was noted soon after the change log was revised. Perhaps it is "our" fault, if none of us noticed this while it was being trialled in the beta version. Essential this is fixed asap.

LegacyUser

Gordon Collett said: Sigh, OoooKkkkk, bigger sigh... I'll quit being lazy and design easily customizable
text shortcuts such as:

.m = Merging ID into ID due to duplicate copies of extraction records which show same parents, same birth and christening dates and places as confirmed by digitized parish records and transcribed census records as can be seen under Sources where all sources linking to the indexed records can be found as well as all sources linking to images the parish record images and links to some census records.

This is really simple on a Mac where such shortcuts are easy to make and unlimited in number:



Now I just wish you could still see the ID of the individual being deleted on Page 3 of the merge process. I'll have to remember to copy it while on Page 2.

I recently ran across a family with 13 children who had been indexed twice and all the family in both copies of the indexing had been placed in Family Tree and almost all the family had been submitted to Family Tree by two different researchers. It took about 100 merges to get this collection of four copies of each child and thirty copies of each parent (which included several duplicate marriage records) down to one copy each of these fifteen individual.

LegacyUser

Adrian Bruce said: 30!

I bet that's not a record though....

LegacyUser

Gordon Collett said: I'm going to be staring at the Change Log after different types of merges to see what things look like and posting commentary here just so I can get completely straight for myself how things look. A lot of this probably hasn't changed from the last version. I just never took the time to really study it out before.

Having found duplicate copies of a husband and wife, I merged the copy of the husband which has just the marriage record into the copy with a complete family. So this is quite simple. The marriage date and place did not exist on the complete family so I did move that over in the merge.

Here is the default, collapsed version:



Clean and straight forward. Two people were merged.

Here is the expanded version:



This is also very clear and pretty much self-explanatory. The duplicate of the wife was connected to the surviving copy of the husband and the marriage information came along.

Here is how it looks from the duplicate's wife side:



This is where things get a little tricky. I have to say it is very helpful to see the word "Merging" in the reason statement. I think I'll continue doing that. It helps because it explains that the relationship was removed because that husband was deleted in a merge.

Now the system does know when a modification is made to a person because someone else was merged because we can see that in the watch list e-mails:



where the notice that a spouse was merged explains why the spouse was deleted.

It would be very nice if there was a notification in the changes logs for people who were not being merged that the changes that occurred to them were due to a merge. This would also point out that it would likely be best to reverse these changes not by working on this person, but by finding the person that was merged and reversing changes there first.

In other words, something like this would be very helpful:



Extreme wishful thinking would be that one day the Change Log would look like this:

LegacyUser

Adrian Bruce said: Re: "This is where things get a little tricky."
Yes - because you didn't actually do anything to Cathrine in the User Interface - only to her husband(s). And yet to my inexpert eye, that log looks just the same as if you genuinely had Cathrine's profile before you, had removed one husband, added another and then added the marriage event. Three separate steps. Yet that's not what happened - oh, it is as far as the list of IT transactions goes, but not as far as the human being goes - potentially leading to confusion.

"I have to say it is very helpful to see the word "Merging" in the reason statement."
Looking at that, I'd agree. I'd like to say I'll do the same - if I remember.

One other possibility would be to add lines reading "Start of Merge" and "End of Merge" in front and after the three. That would also make it clear what was going on.

LegacyUser

Gordon Collett said: (Yes, I should be outside getting some gardening done, but it is 88°F out there.)

"Start of Merge" would help, but it would have to be "Start of Merge for Jørgen
Gjertsen and Jorgen Gjertson" to avoid even more confusion because she was never merged.

Or something like this could be nice (it includes a basic modification for merges I would like to see.):

LegacyUser

Gordon Collett said: Here is an interesting set of merges:



Notice the difference? The top one has no arrow.

In the first merge, the one on the bottom, there was information that I transferred from left to right.

However in the second merge, the duplicate record had no new information to offer and did not have any sources. There was nothing at all to move over.

So no arrow means no information was transferred during a merge. All that happened is that the deleted record was archived away. Of course, if there were any ordinances on the deleted record they would have been transferred over but there is never any sign of that in the Change Log.

LegacyUser

Adrian Bruce said: That's actually poor design. You worked out the reason for the lack of an arrow. Nobody else is likely to do that, I would suggest. As far as the rest of us are concerned, we're much more likely to think that there's a problem with the system.

This is a sin of omission that, I'm afraid, goes across FSFT's design. Rather than make a positive statement of absence, the design, too often, doesn't make any statement. As a result, we can't tell if there's actually nothing to show, if the system is broken or (in other circumstances) if the users have yet looked for the omitted information.

There should always be a positive statement of absence. At least in relation to critical matters.