New Source Linker feedback
Answers
-
Probably drifting away from the original discussion, but I found this interesting. Still the same subject as in my earlier post (William Potter 1828 burial), but the first screenshot shows I originally added an image for the event in his Sources on June 19, 2020. In the second screenshot you'll see how it looks when I click on "View Original Document" and the third screenshot shows what is found when clicking on "View Original Document" from the now indexed record. Notice that in the "unindexed" version it appears as image 140 of 418, but the link from the indexed one shows it as image 143 of 418. Is the "418" just coincidence, I wonder, as the images themselves are not the same. (Image in third screenshot straightened and cropped to remove "Marriages" page on the left.)
UPDATE - I just looked more closely and, sorry, I was mistaken in thinking both images were from the same collection / film. That both have 418 images does appear to be pure coincidence, as the shot above shows the page (24 / 25) from the Bishop's Transcript and the lower has a difference page reference (66/67) and appears to be from the actual Parish Register. What through me was that both have the same Essex Register Office reference at the top - D/CR 45.
0 -
@Paul W I had an instance a few days ago, using the New Source Linker, where the dreaded placename standardization reared its ugly head, putting a record in absolutely the wrong place.
In new:
In old - there is a warning that the placename is not standardized. No warning in new.
0 -
The last time I tried this new source linker I hated it. That was about a month ago. I had a very hard time seeing the color contrast of what was attached to each name and what was not. It looks a little better. We are used to the green color showing source is attached. I prefer the old green.
2nd issue. I used to unselect all tags at the same time, or select all of them at the same time. Now I am forced to choose one at a time. Another example of a time killer. For a few sources added a day I could live with it, but when I add over a hundred sources a week, and I have done many weeks all extra field selections that where not there before an update gets old in a hurry.
At least I don't have to unselect add to source box.
System still needs work on adding event place. I added a source from Social Sec. with parents. It tried to input cemetery info into birth field.
0 -
I am astounded that the 'Feedback' button doesn't 'contextualize'. What ever FamilySearch page I'm on if I select 'Feedback' I simply get sent to the community.familysearch.org homepage - this is useless, the active link needs to land on a relevant page (parsed subject area).
- When adding a ‘reason to attach source’, this entry is NOT saved on the person-record (see Other / Events entry).
- When the source-record is clearly a baptism, the source-tag is NOT updated to reflect the added source., this is also NOT recorded on the Other / Events entry.
- When amending the place-name, this correction is NOT saved on the updated person-record (nor the Other / Events entry).I'v
- Lastly, I am unable to exit the beta 'new Source Linker' and return to the original Linker.
1 -
-
@Caribbean Historian, it seems you've misunderstood some of FS's structures.
The "reason this source is attached" is shown on the source that's attached, not on some random event under Other Information.
Unfortunately, Source Linker is (apparently still) highly literal-minded about tags: if the index uses the word "baptism", then it does not offer the christening tag. Similarly, if the index has the event identified as a "death registration", then the linker does not offer the death tag. As to tagging the custom Baptism event, it appears that the new version has not added tagging of Other Information. You'll need to do that tagging after you finish with Source Linker, same as with the old version.
There appears to be a bug in the new linker: it fails to save the display values of places that you enter for events. I just tried one in Budapest and added the district, but it saved as just Budapest, as if I hadn't done anything to customize it. However, it saved the display value for the date exactly as I entered it (abbreviated), not as the standardized (unabbreviated) date. Something's funky, definitely.
The "Back To Old Source Linker" link is at the top of the page, at the right.
Regarding your first comment: the Feedback tab is generally only available on pages that use a new function, such as the new Source Linker.
For me, it results in a series of obscuring popups (grrr), starting with the (asininely stupid and juvenile) emojis.
Once I select one of them, I get a text box to enter my feedback, and a sometimes-optional email field.
I have so far gotten a response from one of these exactly once.
0 -
I've checked usabilla.com and the site often fails also as of 9 Dec was acquired by (redirects to) surveymonkey.com.
1 -
@Julia Szent-Györgyi. thank you for your reply.
I'v been a FS user since 1999 and stuck with them for numerous reasons. The new Source Linker does not offer me the "Back To Old Source Linker" link at all on my page. When using the new Source Linker it still does NOT carry across the corrections I make to any of the fields - if I correct the date, the original from the source data only is recorded, this is true for other fields including place-name [all this is more than 'funky']. Further, when adding a 'reason' this text used to be duplicated into the 'Events' which is used [for from 'randomly'] to record most timeline events and in which I principally transcribe in detail what was recorded on that event (since often sources are moved, removed, lost, or restricted) and inform other searchers of all the detail found on a person.
0 -
One of the hardest things about discussing the FamilySearch website is the tendency the developers have to release bits and pieces to limited sets of users as part of the final debugging process. Currently some users get the old source linker only. Other users get the option of switching between the old and new. I wouldn't be surprised if there is a third group only getting the new source linker. So before starting my first of several posts commenting on your first post, I'd like to see what differences there are between what I am seeing and what you are seeing.
When I am in the new source linker, this is the full window:
Can you confirm that you do not have the third menu line which starts with the info icon in a blue dot?
Is there anything else in your view that differs from I have posted here? If a direct comparison is easier, here is the source I'm using to test out the problems you bring up: https://www.familysearch.org/search/linker?pal=%2Fark%3A%2F61903%2F1%3A1%3A68QH-3F58&id=MFQD-QDL&hinting=%2Ftree%2Fperson%2Fdetails%2FMFQD-QDL&icid=fs-hinting (Please, everyone, let me fiddle with this source and record on my own. I'm going run through it a few different ways.)
@Maile L , I am remembering right that somewhere in this growing topic you stated that the engineers are tracking this topic? Or was that another post of Source Linker feedback? @Caribbean Historian has brought up several important points.
1 -
1) When adding a ‘reason to attach source’, this entry is NOT saved on the person-record (see Other / Events entry).
I don't think I've ever used the "reason to attach source" box in the source linker. So if you have always seen this add a reason statement to the Vitals page, I'll take your word for it and say that any change will have to be explained by a programmer.
What I can do is show the current behavior of the old source linker vs the new one.
Switching to the old source linker, moving over info, and adding a reason statement like this:
then attaching the record and going to the person's detail page, I see this:
The reason statement does indeed get added to the event. It also gets added to the source.
Now erasing everything I just did, I'll switch to the new source linker and do the same using a different reason statement to be able to clearly follow what happens:
The reason statement indeed no longer appears against the added event. It does, however, still appear on the source:
This confirms there has been loss of a function that was very useful for users that made use of it.
Then the question becomes whether this was intentional because there truly is a difference between "Reason this source is attached" and "Reason" which is a shortened form of the old person's detail page statement "Reason this information is correct." The first explains why someone attached a source. The second explains something about the data, not the source, entered as a research conclusion that could be highly modified from any of the sources tagged to that data.
There is also the problem of the inconsistent behavior of the old source linker. The reason statement is only applied to new information moved from the left-hand to the right-hand side. I add a lot of sources where there is no new information in the source. In that case, any reason statement is only put on the source and no where on the person's detail page. That could easily result in a reason statement added in the source linker regarding the person's name showing up on the detail page on an event under Other Information but not on the name where it belongs.
Based on these considerations, I think I favor the new behavior where the reason statement gets put on the source and if a user wants to also add it to any or all new or existing information on the Detail page, that the user is required to go to the source, copy out the reason, and put the reason under all appropriate entries on the details page.
But if there are a lot of users that consistently use the "Reason this source is attached" box to create a "Reason this information is correct" statement for information being newly added to the Detail page, they should certainly let the developers know they would like this lost functionality restored.
1 -
@Caribbean Historian @Gordon Collett @Julia Szent-Györgyi @Áine Ní Donnghaile @Bateman, Nolan I want to personally thank you for your feedback on the new Source Linker. The reason for the new Source Linker is that the previous Source Linker was built on very old technology. We had to make a change to continue offering this service.
We want to make the new Source Linker behave as close to the old Source Linker as possible. However, there may still be some things we missed or changes that negatively impact your experience. It’s complex software and our small team is trying to fix reported issues quickly (the issues you mention above are recognized and being worked on). We recently implemented a change to the place standardization experience that should now more closely resemble the old source linker with an alert and drop-down for options.
I hope you’ll continue sharing your feedback. Our team would love to see firsthand how you use the old and new Source Linker.
Thank you for your support and patience during this transition.
Mike Davis, Product Manager,
FamilySearch
6 -
2) When the source-record is clearly a baptism, the source-tag is NOT updated to reflect the added source., this is also NOT recorded on the Other / Events entry.
Just to separate issues: Attaching a source and tagging a source are two completely different processes. The functionality of each has not changed with the update to the source linker. Both the old and new source linkers can attach sources to profiles. Both the old and new source linkers can, in addition, tag the source being attached to corresponding data items in the Vitals sections. Neither of them can tag data in the Other Information section.
I agree that it is unfortunate that tagging to Other Information items was not included in this update and hope that it can be added in the near future.
Being able to tag data in Other Information at all is relatively new. It has only been available since the release of the new person pages about a year ago. At that time a developer explained under the new person page group, and I may be off a bit in this paraphrases, that Other Information could not be tagged because if was being newly created, it did not exist yet to be tagged during the source linking process. Also, there was no way to designate what existing information to tag. For example, if the source had a residence and there were five residences on the detail page, which should be tagged? We can only hope they overcome these challenges in some future update.
Now moving on specifically to baptism/christening events. There has been a change in the source linker with such sources.
Old source linker:
New source linker:
What they have done is make the source linker function consistent. You can now only tag sources to Vitals data that appear in the source.
The problem here actually stems from an action a couple of years ago that has been discussed back and forth repeatedly among users here in Community but has never been explained by anyone official.
In the past, all records that were for church rituals of naming and baptizing infants were call christening records. As christenings, the source linker matched them with the Christening field under Vital Records. A couple of years ago, all new collections for christenings were redefined as baptisms and declared not christenings. From that point on, the source linker creates an Other Information - Custom Event - Baptism for the christening date and place. The old source linker still matched tagging of such an event to Christening under Vital in violation of how it handles all other data. The new source linker just corrected that "problem."
In summary, this point really doesn't have much to do with the new source linker. Instead, it is a restatement of two very old, very frequently posted requests:
1) Please find a way to program the tagging of Other Information in the source linker.
2) Please, please turn baptisms back into christenings at least in those collections where 99.9% of the baptisms are for people under a month of age.
0 -
Gordon, my recollection/experience with the baptism-versus-christening problem is different from yours: I don't recall Source Linker ever offering a christening event, no matter the age of the index. All of the index-based christenings on profiles that I've ever worked on were legacy data. The fact that they are a verbatim match to the Custom Event offered by Source Linker just adds insult to the injury. And the problem is much older than a few years: a brief-and-random poke at my ancestors turned up an example from 2018.
I wonder if the programmers for Source Linker could coordinate with the programmers for the new viewer-and-editor, to make it possible for users to correct the type of record that Source Linker is using? That is, would it be possible to change "baptism" to "christening" in the index entry, thereby putting the event and the tags in the right place? (Or, similarly, if we could correct "death registration" to "death" -- with the corresponding change to the primary date -- it would save a lot of frustration.)
0 -
3) When amending the place-name, this correction is NOT saved on the updated person-record (nor the Other / Events entry).I'v
@Julia Szent-Györgyi has already confirmed this bug, but let's see what I get in Safari.
Going back to my source and record in the new source linker:
I correct the place name:
Link it to the appropriate standard:
Attach. Then check the display page to find that the correct place name is gone and only the linked standard remains:
@mikedavis2 this is a definite bug.
0 -
@Julia Szent-Györgyi , A few years ago, nothing I ran into was ever a baptism. They were all christenings like this one: https://www.familysearch.org/ark:/61903/1:1:N4BV-M57 which when I go to the source linker to attach, appears like this:
Every thing lines up perfectly fine, it does not suggest creating a new event, and I can tag the christening right here.
I haven't seen anywhere where they went back to existing collections and changed every christening to a baptism. I only run into baptism and the attendant source linker problems with collections published since about two years ago, at least for the record groups I work in. I couldn't say exactly when the indexing changed from calling these events christenings to calling them baptisms.
Being able to change event type is a great idea. But even better would be if they could go back and change it in bulk. The Norway Church Books collection has over 10 million birth records that have a baptism event. 99.999% of these should be christening events.
1 -
I agree wholeheartedly that a mass correction of baptism-to-christening would be vastly preferable, but what are the chances of that ever happening?
Just to illustrate the deep frustration that this false distinction causes in Source Linker, I found an indexed baptism to attach to a legacy profile that was based verbatim on said index entry, complete with misread mother's name (which I've corrected on the profile, but not in the index, lest the buggy new editor decide to eat it before I'm done with it).
And to be even clearer about the ...nonsensical nature of the distinction, I switched my interface language to Hungarian. So, I'm starting with a profile that was added in 2013. It has a christening, no birth. (I corrected the christening place to the name at the time of the event.)
Notice the label for the christening: Keresztelés. So I go to Source Linker to attach the source that all of this derives from. In both the old version and the new, there is neither hair nor hide to be seen of that christening.
Instead, Source Linker offers to add a christening (Keresztelés). Taking it up on the offer shows why I corrected the place last April: the standardization routine doesn't know what to do with that mishmash of a modern placename. So I fix it, and just to test the place-standard bug, I resolutely spell it without a dratted hyphen. (I also fixed the date, since it's quite clearly there on the image.)
Notice that every single label for this thing I'm adding is Keresztelés. So I attach, and go back to the profile, and check the christening, and it's exactly the same as it was before (see first screenshot, above). The real fun begins in the Other Information section.
In other words, Source Linker was lying through its teeth: the only thing labeled keresztelés anywhere on the profile's details page is the entry in the Vitals box, which Source Linker didn't touch. What it added wasn't a keresztelés at all. Instead, it created a custom event, inexplicably labeled in English. This is exactly the same behavior as the old Source Linker.
I find it highly disappointing that the new Source Linker has not corrected this false distinction.
(Oh, and my display values failed to save for both the date and the place, this time. Very definite bug.)
3 -
In order to see the christening in the source linker when attaching a baptism, you have to close the person's block, then click Details off on the left:
Here is the Norwegian version:
For some strange reason, the word Dåp (christening/baptislm) on the detail page has been changed to Barnedåp (infant baptism) within the last month or so. Barnedåp is not used in any of the parish registers. But in any event changing to that term makes the correlation with the Baptism events even stronger because Barnedåp is definitely not a christening.
0 -
I do not like the new Source Linker interface. The colors are too bold and distracting. The transitions are jumpy and annoying.
0 -
@Gordon Collett an @mikedavis2 thanks for the responses.
I confirm that I do NOT have the third menu line which starts with the info icon in a blue dot (offering an option to return to the old view).
I am very particular in using the "reason this source is attached" field, which previously was often duplicated into the "Events" timeline. Rather than to insert text that is inane (as I have seen thousands of times - notes like 'because this is My Grandfather', or 'I have seen the certificate', or 'this is my family', etc). I use the field to transcribe the text of the attachment - to remove inference or conjecture and better inform new users, so at a glance, a possible match of the person they're researching AND to keep a text copy of the attachments (since these attachments often disappear, or are view-restricted). These fuller descriptions in the timeline "Events" also helps to build the detail of the persons life - I've always been frustrated by the fact that the text used by FS (from the original transcription text, which they use in the matching system and also the text used to display in the Source-Linker screens - could't easily automatically have been attached to the timeline "Events" tracker.
To confirm - the new Source-Linker still FALES to copy the corrections of the fields a user fixes - it's simply posting the original data only.
Surely all the sources we find and attach clearly contain some data that assist in proving a piece of vital information and needs recording on the events and therefore entitled to an appropriate Tag (take the baptism/christening case - both prove the person was alive at that date and born sometime prior to that date - clear), this goes for the place-name also - they Were There.
Good to see Mike Davis responding - I appreciate the concept of the drop-down place-name to aid standardising places (specifically for record-matching), however if an experienced historian/user knows the actual place and edits the field - that 'edit' must be respected and then also copied across. This is true for other fields altered.
Tags have an underline part to play in the development of the records (surly they aid in the learning of what data is ascribed to which source - a kind of AI to teach the software what on mass researchers including professionals have taken years to learn).
"Only being to tag sources to Vitals data that appear in the source" is incorrectly - in actuality only offered Tag are seen of the data-fields that the first transcribers logged - this inherently misses / ignores many other vital facts recorded on a given source (because of early 'rules' prescribed by the first transcription monitors). I have worked on tens-of-thousands of family records and find it horrifying that not-a-jot of that has been used to develop the inherent understanding of the data-types I've worked on.
I agree with Julia that teams working on new 'Source Linker" and the new "viewer-and-editor" should coordinate with programming (in my ignorance I believed this Was how thing where done already) - why aren't select users offered more opportunities to correct vital record data (i.e. ascribing tags to fields on images to grow the accuracy of vital data out there).
Agreeing with davidwilliamnelson somewhat - the new look of Source-Linker has too many colours - data entry need fewer visual distractions - only the salient data-points should be highlighted (coloured or altered fonts), everything else needs to be muted/toned-down.
0 -
On the subject of Baptism v. Christening, this is a longstanding issue about which I have been requesting a change in categorisation (Baptism reverting to Christening) for around two years. I don't see a direct connection to the issue here with the new source linker, as the problem obviously predates its introduction. In fact, I see the issue as remaining exactly as before - with the inability to carry over the Baptism data to the Christening field in the Vitals, instead just going across into the Other Information / Custom Event section, as has been noted.
Nevertheless, I would hope that the intended "new, improved" functioning of the new source linker might cause some liaison between @mikedavis2 (and his team) and the FamilySearch team who are / were responsible for the whole fiasco in changing the categorisation of the (infant) christening event to one of a baptism.
If one of the main aims of the new source linker is to enable more items to be carried across to the profile / details page during the process, a word from Mike, or a colleague, to someone in that whatever-they-are-known-as "mystery" team (which deals with processing indexed records before they get to the Records database), might be of great benefit to all. (If only FamilySearch had assigned a genealogist to that team - one who knew that Baptism = Christening in 99.9% of the records involved - this would never have been a problem issue with the source linker: new or old.)
0 -
In case the importance of getting the Baptism v. Christening categorisation right (while work continues on the new source linker) is not being made clear, I am adding two screenshots below. They are of the exact same event, but - because of the relatively recent change of adding such records to the database as Baptisms - there is no direct way of them being carried across to the Christening field in the Vitals section of the Details (Profile) page during the source linking process.
If you could liaise with the FamilySearch team responsible for their unhelpful change in categorisation, it should lead to users being able to get this detail across to the Vitals section, as should be the case.
"Old style" record - categorised as a Christening, so could be carried across to the Vitals:
"New style" record that puts the event only to Other Information section if carried across:
It would be great if this issue could be sorted soon - hopefully by the time the old source linker is phased out.
The current process means that if a user carries across a "Baptism" it is treated (and appears on the Details page) as if it was a totally different event from the "Christening":
3 -
Although the question of Baptism vs. Christening is certainly a valid issue, it has nothing at all to do with the source linker, new or old. Rather, it is solely an issue of how the events are categorized in the record collection.
If you want to discuss the Baptism/Christening issue, that can be done in another thread. But the source linker has no choice but to use the vital event(s) designated in the record collection(s), so this thread should focus on issues that actually pertain to the source linker itself.
0 -
I'm afraid I have to disagree with you there, Alan, although I assume you are not aiming your remarks specifically at me, as I was adding to a discussion that was already underway on this thread.
My argument here is connected to the fact that I believe there should be far more coordination among the different FamiySearch teams. From what I have seen of the new source linker, one of its "enhancements" (although I admit, personally, I do necessarily not see it entirely as such) is the ability for users to carry more data across to the profile in question during the process. In which case, why not take this opportunity for two teams to liaise and sort out the categorisation problem that currently does not allow the christening (aka baptism) data to be carried over, but could by the time the new source linker is fully operational, if only the current categorising of christenings as baptisms could be fixed asap?
So, please do not tell me / us not to discuss problems directly related to the future of the source linker, especially if this is constructive comment directed to a person who appears to be in a position to help in resolving the problem. That is, unless you know for sure that there is no way of possibly getting different FamilySearch teams to communicate with each other in an effort to (1) correct existing faults and (2) in this specific case, to do such in connection with making the new source linker operate better than the current one does.
2 -
Since the dozens of other thread that have discussed the Baptism/Christening issues have not brought any official response, not even a "Sorry, we're working on it" or a "Sorry, there are new constraints on indexing that required this change and we all just have to live with it," letting the Source Linker team know that the Indexing team is causing problems with the source linker certainly is appropriate here. If the Indexing team can't fix the collections, maybe the Source Linker team can build into the source linker the recognition that baptisms can very frequently be christenings.
Two things would help.
The first should be relatively straight forward and that would be a return of the ability to tag a baptism source to a christening event as is possible in the old source linker.
The other would certainly be more complex and that would be to have a baptism event show twice in the source linker. Once matched with the Christening to allow adding or editing a christening event and tagging it and once as a new Other Information - Custom Event as it is doing now to allow the creation of a new custom event when the baptism is indeed not a christening.
2 -
@Alan E. Brown, I disagree that "the source linker has no choice but to use the vital event(s) designated in the record collection(s)". It should be entirely possible for users to change those designations. As I've written already, this applies not only to baptism/christening, but also to things like event-versus-registration. Also, it should apply to tags, too: very often, there are details in the record that are not in the index. The index should not be treated as if it were the data. It isn't. It's just a handy way to find the data.
I realize that the new and old versions of the Linker are behaving identically in this, but that's kind of the point: what's the use of re-doing the programming without fixing the problems with the process?
@Caribbean Historian, why do you find it necessary to appropriate the reason box for things that aren't reasons? Wouldn't a source's Notes/Description field be much better suited to, well, notes and descriptions? That's where I put my transcriptions/translations.
2 -
I too strongly disagree with Alan's suggestion that data movement (including baptism/christening) isn't precisely what the Source-Linker is meant to do - place the retrieved source and link it correctly to the given persons historic profile.
Julia, I appreciate the way you record information found on a given person - however I have seen thousands of records created by users who hardly read the person-view, let-alone any attached side notes/descriptions. As I pointed out I believe in building a fully descriptive timeline with all available data to help build the persons life one time, and my method seems to do this on FS adequately. It would simply be 100% more effective and efficient if the Source-Linker tool did much of the transcription for me (easily done) and only require editing for proper grammar/formatting and possibly adding further details hidden in the given source-record.
0 -
I love how you can make corrections before attaching the record but the corrections are not following through to the person page.
GG5Y-5W3 I added sources to this person and corrected the dates but it did not work. Had to change/correct the dates on the person page!!
0 -
One more suggestion:
Could you highlight the 'issue' that prevents a link from attaching?
In this example, I need to click 'deceased' or 'living'. This is the problem that MUST be resolved before the link can occur; however, it has the same color/intensity/font/font weight as everything else in the screen.
Clicking the +Add button does not illicit an error or popup or message, and leaves me wondering what the problem is until my brain finally kicks in and says -- doh! go mark 'deceased' or 'living'.
Please highlight the problem (background color change? font color change? -- something).
0 -
I agree with ScottStieg. I find the jumping around of the screen to be disconcerting and dizzying. The old method used scrolling--which was much easier to work with.
Secondly, the reason box does not handle multiple lines well. The old one functions much better.
I add about 2000 names a year and average about three sources per name. I work on a 17" laptop in Windows 11 and have a second screen.
I also had an issue with the Feedback button giving an error. I use UBlock and disabled it for FamilySearch.org and then the feedback button worked.
0 -
I wish I hadn't reacted to the "Try the new source linker" popup. It seems that I can't just try it, and then decide to stick with or not. Now I'm stuck with it and can't see how to get back to the older version. Can anybody tell me how to Untry the new source linker ?
@ScottSeegmiller Can you please attach a link to the Source Linker Group.
0
