The ability to unmerge individuals would be a nice to have. Basically an undo feature for merging.
What I am suggesting is not quite a full undo facility for merging such that just clicking a button will undo a previous merge. What am suggesting instead is the ability to select various events/attributes/features of an individual and move them into a new individual's record - more a seperation rather than an unmerge. After this unmerging process you would have two indidivuals with different pieces of data but possibly the same name or part of the name.
I see this being used in cases where an asuumption you might have made turns out to be invalid and you need to backtrack. For instance you might have made an assumption about a person's death event when after further research you find that the death was not related to that person after all. To fix this invalid assumption the normal process is to update the death event for the individual concerned. But you still have a valid death event which you now don't know who it belongs to, so you need to create another individual (with the same name) with just the death event.
For a single event/attribute this isn't too bad to do manually, but when a number of events from a source are found to be incorrect it's a bit of a bother to copy each event over to the new person.
In fact just selecting the source of various events/attributes for an individual and moving the events/attributes to a new indiviudal would be an nice optimisation, but a manual selection method would still be needed to allow for complex unmergings.
Example:
An Annie Axtell is in the database born in ~1803 sourced from source X. This is Annie #1.
Source Y states an Annie Axtell was buried in 1877 aged 73. This gives 1804 as a estimated birth. This is Annie #2
An assumption is made that the death & burial in 1877 is related to the Annie born in 1803 since the dates match up pretty closely and no other negatory information is known.
Sometime later it is found that the Annie #2 who died in 1877 was in fact married to William Axtell so the allocation of a death event to Annie #1 was wrong.
Annie #1 must then be created with just the birth event and Annie #2's birth event removed leaving only the death event and marriage.
The name of Annie #1 would be Annie Axtell and the name Annie #2 would be Annie (Axtell) or whatever is used to indicate a married name.
Being able to select source X and remove the associated events for Annie and place them in a new record would be the optimisation.
ID:2691
* Unmerge individuals
-
NickWalker
- Megastar
- Posts: 2401
- Joined: 02 Jan 2004 17:39
- Family Historian: V7
- Location: Lancashire, UK
- Contact:
Unmerge individuals
It is actually very quick and easy to select multiple events and press copy, click on the other person and then paste. Its a shame that you can't cut and paste. I just tried this and assumed I could select the events, press copy, then delete the events and then paste into new person but actually deleting the events also removed them from the paste buffer which was a bit unexpected but I can understand why it has been implemented that way from a programming viewpoint.
Unmerge individuals
I'm not disagreeing that it can be done, but I'm taking into account that it can be quite a long winded process and mentally challenging task to do all this manual creating and copying. Because of the many little gotchas scattered around FH it can require a lot of thought which should be used in thinking about the issue at hand rather than how to execute it within FH.
For instance, first the new person's record has to be created. No problem. Now because you can't have to two record windows, you somehow have to make the two records close together or easily selectable so that you can easily switch between the two records as you copy and paste between them. No problem with only a few records, but when you get into the hundreds and thousands it gets a buit more long winded. You could have one person in the record window and the other in the property window's all tab. But here you have to remember to make sure that pin mode is cleared so that it doesn't track what you're clicking in the record window. This is because the pin mode is not remembered and ALWAYS resets to pinned mode everytime the property dialog window is opened. Another gotcha.
Secondly, you copy your events from the first individual and move to the second individual and paste in the events. Assuming the two records were close together on the screen you can now go back to the first individual and delete the events. But, here you have to have remembered the events you copied since the highlighting will have disappeared unless you use the property dialog window method where they stay highlighted. Another gotcha.
It is as you copy and paste that you have to think about FH's implementation since its different from ALL other Windows programs as you can't cut and paste and so you have to think even more about how to execute the task within FH rather than doing it without thinking because you've learnt how ALL other Windows programs work.
As you mention, attempting to be clever and copying the events, then immediately deleting before pasting doesn't work. I too can understand why this has been done from a programming viewpoint but it's wrong. I also understand that the Windows clipboard exists for a reason - so that you can carry out such tasks by actually using a paste buffer rather than seemingly copying direct from record to record. This means that FH does not seem to be using the Windows clipboard for any copy/paste tasks and has instead seemingly re-invented the concept known throughout the world as copy/cut/paste as copy/paste only. This probably explains the inability to copy records between different instances of FH because the Windows clipboard is not being used.
Basically I want to think about the Annie Axtells and which bits of information I want to copy/delete/keep and not about all the gotchas and special cases and so on. I can only keep so much inforamtion in my brain at any one time and Annie Axtell is more important than FH's idiosyncrasies.
If FH carried out copy/pasting and other similar tasks in the same way as ALL other Windows programs I would probably make less calls for these nice to have features. This is because I can think more about the actual task rather than how to execute it.
For instance, first the new person's record has to be created. No problem. Now because you can't have to two record windows, you somehow have to make the two records close together or easily selectable so that you can easily switch between the two records as you copy and paste between them. No problem with only a few records, but when you get into the hundreds and thousands it gets a buit more long winded. You could have one person in the record window and the other in the property window's all tab. But here you have to remember to make sure that pin mode is cleared so that it doesn't track what you're clicking in the record window. This is because the pin mode is not remembered and ALWAYS resets to pinned mode everytime the property dialog window is opened. Another gotcha.
Secondly, you copy your events from the first individual and move to the second individual and paste in the events. Assuming the two records were close together on the screen you can now go back to the first individual and delete the events. But, here you have to have remembered the events you copied since the highlighting will have disappeared unless you use the property dialog window method where they stay highlighted. Another gotcha.
It is as you copy and paste that you have to think about FH's implementation since its different from ALL other Windows programs as you can't cut and paste and so you have to think even more about how to execute the task within FH rather than doing it without thinking because you've learnt how ALL other Windows programs work.
As you mention, attempting to be clever and copying the events, then immediately deleting before pasting doesn't work. I too can understand why this has been done from a programming viewpoint but it's wrong. I also understand that the Windows clipboard exists for a reason - so that you can carry out such tasks by actually using a paste buffer rather than seemingly copying direct from record to record. This means that FH does not seem to be using the Windows clipboard for any copy/paste tasks and has instead seemingly re-invented the concept known throughout the world as copy/cut/paste as copy/paste only. This probably explains the inability to copy records between different instances of FH because the Windows clipboard is not being used.
Basically I want to think about the Annie Axtells and which bits of information I want to copy/delete/keep and not about all the gotchas and special cases and so on. I can only keep so much inforamtion in my brain at any one time and Annie Axtell is more important than FH's idiosyncrasies.
If FH carried out copy/pasting and other similar tasks in the same way as ALL other Windows programs I would probably make less calls for these nice to have features. This is because I can think more about the actual task rather than how to execute it.
-
NickWalker
- Megastar
- Posts: 2401
- Joined: 02 Jan 2004 17:39
- Family Historian: V7
- Location: Lancashire, UK
- Contact:
Unmerge individuals
The point I was trying to make is that rather than having a very specific feature (unmerging) that would have to be learned and would probably confuse people and lead to lots of questions as to how to use it, etc. if Cut and Paste was implemented then it would make the unmerging very easy. So perhaps support for Cut and Paste would be a better wishlist item.
Unmerge individuals
Ah, I see what you're saying. True, cut and paste would remove a lot of the arguments for an unmerge facility. Admittedly I was thinking it more an advanced feature. Still a nice to have for a future release, maybe V9? 