A Step in the Right Direction
Question: if this new Merge design isn't intended to supplant the old one, what would compel users to review this info after the fact?
If the new design IS intended to replace the old one, the 3-column Merge Analysis page ('Possible Duplicate,' 'Surviving Person Before,' and 'Result of Merge') is definitely a step in the right direction over the existing 2-column Merge page ('Possible Duplicate' and 'Surviving Person'). Giving the user the ability to see Result of Merge data in the aggregate beforehand should prove very useful in helping determine whether the Merge action should really be undertaken.
Fields like 'Initial Creation Date' might also help users make more informed choices about merging PIDs.
Having the 'Reason' for the merge at the tippy-top of the new page could also help highlight where users are simply choosing arbitrary reasons from the 'Suggested Reason Statements' or possibly encourage them to be more explicit in their reasons for undertaking a merge. The proviso here would be that, in order for the merge 'Reason' to be more instructive for the person undertaking the merge, this would need to be shown prior to his/her submitting the merge to the server.
의견
-
I think the intent is to help users undo bad merges by improving the view in the changelog.
What do you like about this changelog view that would be helpful when merging possible duplicates?0 -
As another user, who has also looked through the new Merge Analysis View, really like it, and do think it will be very helpful in evaluating old merges, I was wondering what the difference would be for merging?
The two column view is really the same as the three column view. That second column is the third column. Immediately do if you do not move over any information from the left to the right. As you move information from the left to the right, you create a new version of the third column each time you do.
I used the new view to separate a bunch of bad merges from a few years in which two brothers who were born ten years apart had been merged. The current merge screens would have been plastered with red warning signs about the difference in birth dates so either that feature was not present then or the user doing the merge ignored both the birth dates and the red warning when merging. I don't see how the three column view would have helped. I guess one procedure that might have made a difference would be if there were the three columns with the last one initially blank and users would have to move all the information they want to keep from either one by picking from each column. In other words, there would be no automatic transfer of information to the surviving record (except for sources - all of them always need to be moved over). However, that seems like a step backwards from the current procedure.
3
