Improve Source Linker
When linking sources to persons in the Source Linker If the information for some item (Birth Dates, death dates, names) is more precise than the current information, give the user an option to update the information by either replacement, or directly editing the person's information within the source linker page.
Presently the user must go to the person's details page and re-type the information which was shown on the left panel.
This idea would make the update more efficiently, and avoid typo's.
Thank you,
Jim Robinson
Comments
-
There is a new version coming of the Source Linker. You can try it out in the Beta platform.
0 -
Speaking of that new version of Source Linker: does anyone know the best way to provide feedback on it? (Yes, I've done the Feedback tab thingy, but it feels like I'm shouting into the void.)
The ability to edit the vitals directly from Source Linker has been an often-repeated suggestion, but I am badly disappointed in the implementation: you still can't see the collaboration or Other Information sections when you're making such an edit. That more-precise-looking data you're editing in may be precisely wrong, and it's not showing you the long screed in Notes explaining exactly why you shouldn't be doing what you're doing.
2 -
I have been arguing for quite the opposite: that there should be less opportunity to carry details across in the process. This example explains my reasoning. Most users would probably carry across the marriage details here, but this will lead to incorrect data replacing the correct event that currently appears on the Details pages of the two parties. This 18 May 1879 "event" (as is often the case) represents the date of banns (or the issue of the marriage licence), yet as it is earlier than the date of the actual marriage - 2 June 1879 - it will replace the correct, existing data on the Details page. I'm very disappointed (especially given FamilySearch's poor record in categorising associated events - banns and licences - as actual marriages) that it appears this problem will continue to be perpetuated by allowing for this behaviour (even after the new version gets released).
I maintain the Details page is the best place to work from, in comparing (seemingly conflicting) data before deciding which (of the different offerings) is the correct to input. The Source Linker page is not the place to make judgements on the integrity of the indexed data.
2 -
I'm in full agreement with you there, Paul. I try to do any needed editing to dates/events/places before I use the Source Linker to connect the record to the profile.
1 -
@Paul W That's not really a fair comparison. The additional marriage event will just be added without affecting whatever's already there, and somebody who doesn't understand the reasons behind the different dates will probably just copy it manually, maybe assuming the latter was a registration date.
There's not really going to be anything that common and frequent with names, birth or death dates. Discrepancies there may be due to the reliability of the source (or lack thereof, see: Find a Grave).
If nothing else, updating the fields during tagging should absolutely be allowed for:
- Name fields that are blank. And preferably women's surname field where the name is the same as the husband's since that's usually a married name.
- Any date/place field where only one of the two is populated.
- Any date field where the source has more precise information, meaning if the existing data is just a year or estimated date but the source has the day and month.
0 -
Quoth @RTorchia: "Any date field where the source has more precise information, meaning if the existing data is just a year or estimated date but the source has the day and month."
But, see, that's exactly the problem. Sometimes, that more precise date is precisely wrong, and that's why the field has just a year -- and if the explanation for that is in a collaboration note, then it's completely invisible in Source Linker.
As I said, this suggestion has been made over and over. Every time it came up, I and others (such as Paul and Gordon) explained why, without drastic changes to Source Linker's functions/setup, it would be a Bad Idea. Source Linker simply does not show you everything you need to see in order to make good decisions.
It is very, very unfortunate that FS appears to be adding this capability without making the necessary other changes to Source Linker.
3 -
"The additional marriage event will just be added without affecting whatever's already there...."
Not so, unfortunately. The earliest dated of an attached source for any Marriage event always appears on the Details page. So, to make it clear, if I added that 18 May 1879 date / event when attaching the source it would immediately take the place of the correct 02 June 1879 event. Okay, the earlier date has been incorrectly indexed as a marriage, I believe - although I haven't checked other sources to confirm if it involved marriage banns or licence. At present, we have to delete such data from the Couple Relationship area (especially to keep it off the Details page), as there is no provision to indicate sources related to the marriage OR the option to choose from a pick-list.
My argument stands - that you can only properly assess the nature / accuracy of these sources whilst working directly from the profile pages - carrying unconfirmed details across whilst linking the source can remove correct / proven data from the Details page: especially in the case of marriages.
1 -
Looking at the beta, it appears that they have taken a feature from the Merge page where you can choose to have the data on the "left" replace the data on the "right", and then they added another feature, allowing you to pop up the full Details Edit to edit items where the Source data differs from the Tree. The all-or-nothing data replacement of the Merge page is sometimes useful, but Merge also needs the ability to do a full edit, as seen in this new feature. Unfortunately, opening a Details Edit from within the Linker has no idea that you are wanting to selectively copy some of the source data. You have to copy everything you want ahead of opening the Edit and then do awkward partial pastes, or do an awkward back-and-forth partial-copy-open-paste-save-close-copy-some-more... They don't seem to be considering the actual mechanics of reaching the end goal but rather just "implement the feature request". In the case where the data only exists on the Source side, and not in the Tree, they still seem to only offer the all-or-nothing approach, even when often you want only part of the Source data; in this case you can only Add, not Add AND Edit as desired.
It is useful to be able to do the edit at the point in time that the new data is seen, but as noted above, the realization of this feature is still awkward. Many times, I have said while linking: "oh, I have to copy that data and remember to update the Detail when I am finished linking..." and I copy it, but then get distracted and totally forget to do it! This helps with that, if awkwardly. Editing the data before I go into the Source Linker is sometimes possible, but for me, this is usually "putting the cart before the horse". Going into the Linker, copying the desired data and then backing out to edit first, or opening another window to do the edit: just more awkwardness, and more steps increases the chances of errors.
At the same time, I understand the arguments against editing directly from Source Linker and "blindly" copying/replacing data without considering it in context. However, I don't think the answer is to prohibit editing from within Source Linker, but rather to provide the needed context. Unfortunately, this is easier said than done. It would require the proper implementation of Notes. Rather than the current Notes which are only linked to a single Person or a single couple relationship (and only available from limited contexts), Notes need to be "Hyper-Notes" that can be linked to multiple, individual Detail items (like the tags of a Source or like the fact that Memories can be linked to multiple persons.) Then you can write a single note about a "situation", with full explanation, and link that Note to ALL the data items to which it applies (across multiple Persons, as well). These notes would be available in the Detail Edit boxes just like source tags are now. That would go a long way in providing the needed context for making informed decisions about editing/replacing data.
This still doesn't solve the existing edit context problem that you have when editing on the Details page: once you go into the editing box, you cannot look at any other data for the Person for reference or to "double check" that your editing is in line with other data. You have to abort your edit, scroll or otherwise display the other data, then go back and start your edit from scratch. Again, you can open another tab for reference (not easily done when you are already in the middle of an edit box...), but it is just another obstacle to a valid workflow.
Since you can't easily get all the context you want while editing, then there (also) needs to be an easier method to save "excerpts of data" in some type of a "pop-up notepad". I sometimes awkwardly do this using a notepad outside the browser, or even on a piece of paper, but it would be so much easier if I had a little pop-up within FamilyTree to capture multiple little temporary ad-hoc notes like "John's full birth 20 Aug 1865" or "Jane's ID WWWW-111". The operating system is woefully inadequate for this, because it typically only let's you copy one item at time and doesn't let you annotate what you have copied. Yes, there are add-on utilities that can potentially do this, but why not have a small, built-in, multiple-note notepad that is accessible from anywhere within FamilyTree?
Editing of the Couple Relationship Details have always operated differently (for somewhat complex reasons) and it has always been a source of confusion. They should make more effort to apply, wherever possible, the same editing principles, whether it is a multi-valued entity like Relationship or a single value entity like Birth. In this case, instead of just offering to add another marriage event date to whatever is already there, it should also offer to pop up the full Couple Relationship editing box so that full(er) context is available and appropriate editing can be done.
Many of these challenges are not huge game-changers, but a lot of little hassles add up when you are doing a lot of editing.
0 -
@David Peterson, the source data is accessible from the details edit that you get to from the Beta site's Source Linker: it adds the proposed new source (with a dotted-line box around it) in the right-hand column of the editing popup. You can click the "v" at the right to open that source and copy-and-paste things from it.
Sorry that it's not a particularly good example. Most of the collections I'm accustomed to using do not work in Beta, and the ones that do just offer the usual nonsense of adding a custom "baptism", instead of showing the christening field where it's already entered. (Why they've gone to all this work without addressing this long-standing and oft-mentioned fault of Source Linker, I cannot figure out.)
1 -
But, see, that's exactly the problem. Sometimes, that more precise date is precisely wrong, and that's why the field has just a year -- and if the explanation for that is in a collaboration note, then it's completely invisible in Source Linker.
Is that really a situation you run into frequently, that a linkable source has incorrect information in a vital info date field? I honestly can't recall any time when an internal FS source (besides Find a Grave, which shouldn't be one) had faulty date information -- not saying never, but it's rare, and infinitesimal compared to the amount of time people could save in regular editing and profile creation with this feature.
The kind of warnings you describe are generally on mature profiles that have already had a lot of attention -- they've had at least enough time and energy expended on them that somebody noticed some obscure problem with dates and then researched it to figure out what it was. Those kinds of profiles aren't going to be a problem because they're already going to have all their FS-internal sources linked. There isn't an endless supply of linkable FS sources, let alone ones with full-date vital info fields, specifically ones with incorrect information that was discovered and flagged by an editor, who didn't then just attach the source themselves.
Where the feature will actually be used is when newer and underdeveloped profiles and families are built up, when editors are going through all the hints, finding more detailed information and rapidly improving the profile. This is where the feature is needed.
The most frequent times where the just a year is more correct than a sourced full date is when people are entering it into the wrong field: entering christening dates as birth dates, or will, probate or burial dates as death dates. Those are entered manually from off-site sources, not from linker, and even with all the alerts, warnings, notes, discussions and constant reversions it still keeps happening. Even if you explicitly say "don't do this, here's why" people are going to ignore it and do what they want, either because they're using some piece of software like Ancestral Quest that doesn't even show the edit comments or alerts (and yet is FS-approved and endorsed), or people will just insist their personal tree or GENI or Ancestry or Find a Grave are the unquestioned unmost-correctest and whatever this warning somebody put here is nonsense.
And they keep doing it because, for all the pretense about this being a global collaborative tree, not a personal tree, and all the bluster in the various Terms and Agreements about providing true and accurate data, there's no enforcement of any of it. There's no consequences for ignoring those alerts, using software to overwrite a profile with an old local copy without ever even looking at the changes, prioritizing disreputable secondary sources over attached primary sources, uploading the same error-riddled GEDCOM for the third time in a year, adding every suggested source from Ancestry without even checking whether they're from the right century, or ripping apart a family because one source attached to the father belonged to a different person -- all things I've seen this week alone. Sorry, I just don't buy that this is going to cause even a millionth of the damage editors can do with the tools and features they're allowed to used unregulated right now. This is not going to be what makes bad editors edit badly.
As I said, this suggestion has been made over and over. Every time it came up, I and others (such as Paul and Gordon) explained why, without drastic changes to Source Linker's functions/setup, it would be a Bad Idea.
If the suggestion keeps getting made, maybe it's because it's a good idea? That people know it will help their workflows and they want it? Maybe take a moment from lecturing the masses on why their ideas are dumb and wrong and consider that maybe people just don't find these arguments against it reasonable or compelling? The location standardization icon was removed to the under similar esoteric concerns. A lot of users were disappointed with the functionality loss and, given the lengthy threads still being regularly posted complaining and it, predictably had essentially no effect on the problem it was supposed to solve.
0 -
(What functionality loss from the removal of that completely-misunderstood location icon? The function of people intentionally sitting there removing good data in the name of achieving that false gold star?)
It doesn't actually apply to Source Linker, since they haven't fixed its fixation on labeling, but the most common source of more-precise but less-accurate data is baptismal records. This applies not just to the date, but also to the place. Most of the time, I don't much worry about it: in the places where my relatives lived, babies were baptized as close to immediately as possible, and the church was usually no further than the next village over, so putting the date and place of baptism in for the birth isn't very wrong. However, sometimes the baptism is actually a conversion, meaning that neither the date nor the place have anything to do with the person's birth. This is why a bare year and just a county can be more accurate than a month and day and a precise street address.
The source of error that does apply to Source Linker is misindexing, and I disagree about the lack of an endless supply: new indexes are constantly appearing on FS. My Lutheran families that I laboriously researched by paging through images, back when the Catholic and Reformed baptisms were all that was available indexed, now suddenly have all sorts of record hints. Many of them are indexings of the images I've already attached, but quite a few of them are wrong: the index misread a name or date, or the hinting system is ignoring locations (or the locations aren't in the index -- many of the new ones stop at the country), for example. Various "helpful souls" apparently spend a large proportion of their time on FS going along and attaching these newly-indexed sources to the profiles that the hinting system suggests, transferring everything that Source Linker offers for transfer. I shudder to think what will happen once such attachers can also edit the existing conclusions to match the hinted record. How many correct-but-vague birthdates (based on, say, the order of names on a funeral notice, which usually listed siblings chronologically) will get replaced with calculated dates based on age reported at death?
2 -
I've been too busy with some other projects to comment as much here in Communities or to look at the beta version of the Source Linker update, but have been following this conversation.
If the suggestion keeps getting made, maybe it's because it's a good idea? That people know it will help their workflows and they want it? Maybe take a moment from lecturing the masses on why their ideas are dumb and wrong and consider that maybe people just don't find these arguments against it reasonable or compelling?
It is a good idea if done properly. Restating and repeating time and time again why, when this idea was first posted years ago, the production manager for Family Tree said this was never going to happen in the current state of the Source Linker is not lecturing or calling ideas dumb. It's explaining to other users why FamilySearch was going to be ignoring the idea at least until there was a total overhaul of the Source Linker.
2 -
Not so, unfortunately. The earliest dated of an attached source for any Marriage event always appears on the Details page. So, to make it clear, if I added that 18 May 1879 date / event when attaching the source it would immediately take the place of the correct 02 June 1879 event.
We're splitting hairs over the meaning of the word "replace". What I meant was that the data isn't lost; all values may not be displayed, but unlike any vital info date field, fields aren't expunged from the profile when a new event is added. Yes, it might be "replaced" in that it it might no longer the event shown by default; no it's not "replaced" because the data is still there and only takes a single click to see.
But the point I was making was that the marriage field behavior isn't a good analog to use as an argument against the vital info date fields because it allows multiple stored value and there are so many associated dates and events around the marriage itself which are sometimes found in records and sometimes aren't sufficiently documented. These unique issues make the marriage field unsuitable for a straight comparison to the other vital fields.
The concern that somebody might add a date during source linking that knocks a carefully-vetted marriage date out of the default position seems like it comes from a narrow focus on profiles that are already fairly well-developed and polished. If someone has put in the effort to collect all the records for these supporting events and researched them to determine which one has Thee Marriage Date, then almost certainly they'll have already attached all the linkable FS sources. There's not much risk of overwriting during linking if there's nothing left to link.
But most pages aren't like that. A lot are either stubs that don't have enough available sources to fill out, or they're being built up, which is when editors could use the ability to add and edit information as more and better sources are found. In either case, ironing out these minor inconsistences isn't a high priority.
My argument stands - that you can only properly assess the nature / accuracy of these sources whilst working directly from the profile pages - carrying unconfirmed details across whilst linking the source can remove correct / proven data from the Details page: especially in the case of marriages.
It's pretty ironic then that we're already allowed to do it only for marriages. But actually, that's a good thing.
Yes, you're right in that, particularly with marriages, there are a lot of associated events and dates: banns, bonds, intentions, licenses, the ceremony, recording, publication, registration dates and of course good old transcription errors between derivative sources. But if there's a situation where, say, an editor finds one marriage record with a May 18, 1879 date and another for June 2, 1879, and neither source specifies what event it represents, but the editor suspects it might be possible to find by digging through the archives parish by parish, church by church, page by page until they track down the original source... "Why bother?" is an perfectly acceptable reaction to that.
An editor might not understand the intricacies of all the archaic matrimonial processes well enough to understand the date inconsistencies. Or they might not have access to the resources needed to identify the events. Or maybe they just don't consider a two-week window from a century-and-a-half ago as being so torturously ambiguous that it demands sacrificing several hours on a frenzied quest for precision --"May-ish 1879" is good enough for them.
As long as it's the correct profiles for those sources, there's no requirement for editors to resolve every inconsistency before they are allowed to attach the source; we're never going to let that block a valid source from being linked, which is why adding the events to the list is the way to go: if there is some unresolved inconsistency, all the evidence is in one place easily visible to anybody who looks at the relationship events list. And who knows, maybe it'll pique who does have the expertise and enthusiasm and absurd amounts of excessive time to go spelunking through microfiche.
Anyway, while playing around with how dates affect the Events list, I found some interesting behavior that might be interesting to... I dunno, somebody, maybe.
- Regardless of Event type, the earliest event is shown first, which means if a couple lived together for a decade before getting hitched, the Lived Together event will be default. This means if we ever do get events for banns, bonds, intentions and licenses, those will be shown by default unless dev prioritizes the Marriage event.
- If two or more events have the same date, the last one edited is put at the bottom of the list (which seems counterintuitive to me since you'd probably want the one you improved to be shown). Location has no effect on order, other than that editing the location causes the event to lose the date tiebreaker.
- Incomplete dates will be listed higher than complete dates, with the exception that the first of the month or first month of the year will get ranked higher than a date without a day or month. (Events without dates are shown last.) For example, if these were the event dates, here's the order they'd be in:
- 1 Jan 2023 // Jan 2023 // 2023 // 2 Jan 2023 // 1 Feb 2023 // Feb 2023 // 2 Feb 2023
0
