New Source Linker feedback
Answers
-
@LDS Search Test When in the Source Linker, in both Firefox and Chrome, I see the option "Back to Old Source Linker" at the top right. YMMV
0 -
@Áine Ní Donnghaile Thanks for the response, but I don't see that option in my browser.
I've had a look at the code and there is no element between the Menu Items "Records Images Family Tree Genealogies Catalog Books Wiki" and the separator above "VIEW THOMAS WILLAMENT" and "TIPS AND RESOURCES" It seems that the entire section is missing.
For those who can see the "BACK TO OLD SOURCE LINKER" option and are technically adept enough to drill into the code to locate the element. Can you please let me know where the element content is sourced or served from ?
1 -
@LDS Search Test , you are the second person to report that the menu bar that contains the link to return to the old source linker is not there.
I can't see any difference in the URL between the old and new source linker.
I tried closing all my browser windows, deleting FamilySearch cookies, then going back to a source linker page. This did make the old source linker pop up for about a second, then the page reloaded with the new one, so it is something in our account settings, not a cookie.
I don't know enough about complex page coding, but could you give some directions as to how to find the information you mention and maybe post something you need to get out of the new source linker?
1 -
@Gordon Collett Thanks for that. Today I tried again from a fresh start with all stored data cleared. The source linker opened initally in the normal (old) format. I was happy for only a few seconds because the page then went completely blank, except for the spinner, for over ten seconds until it loaded the experimental (new) linker. I think this confirms your suspicion that the Old/New determination is connected to the account and not a cookie.
I suspect that trying the new linker sets a flag to "Opt-in", and this can only be reset by selecting "return to old linker" which I can't do. So now I'm stuck.
How can I get somebody with the correct privilege please unset the "Opt-in" on my account. ?
1 -
@Gordon Collett I appreciate that the coding rework takes time (and forgive me but I'm also somewhat at a loss to understand how previously constructed fairly-successful / working algorithms / functions are not simply transferred to the new coding / library as a first priority (before worrying about the cosmetics and newer functions). It is extremely demoralising to correct all the field entries for a new attached source only to find that none of the corrected data nor text is transferred (as it had in the old Source Linker).
0 -
@Stephanie V. . You responded in an earlier comment regarding the feedback button and mentioned a 3rd party called Usabilla.
Is this the same as....
"Usabilla is a self-service, cloud-based enterprise software-as-a-service platform helping category leaders capture real-time visual user feedback and deploy hyper targeted micro-surveys to measure customer, user, and employee experience on the web, in iOS and Android apps, and within emails."
Hmm... lots of words, and yet I remain unenlightened.
I am one of the users for whom the "return to the old Linker" option is not visible, but the Feedback button is visible, so I conclude that it is nothing to do with Usabilla. I would appreciate it if you would please enquire with the engineers who responded concerning Usabilla, and ask them which 3rd party is responsible for the provision of the "return to the old Linker" section of the new source linker, so I can try to search for whatever is causing it to not exist.
0 -
@A Andrews Certainly is discouraging but I suspect that no simple transfer of algorithms was involved. From the statements regarding the person pages at RootTech last year and in the community group for the new person page feedback, part of the reason for updating the source linker was that the supporting technology for the source linker was so out of date, to the point of rapidly becoming non-sustainable. This makes me wonder if the old code simply would not work on the new platform, whatever that is, and had to be re-written, not ported.
In addition, there were recurring complaints here which you could find if Community had a functioning search routine (I've never been able to find any here using the search) in which the place name function in the old source linker did not work well. Many people found that when standardizing a place name in the source linker and saving it, they would then go to the person page find that the place name was not actually standardized.
I do look forward to the completion of the new source linker when I expect that the place name problem will be solved.
1 -
I do look forward to the completion of the new source linker when I expect that the place name problem will be solved.
I wish I had your optimism, @Gordon Collett. I truly hope that will be the case, but I have serious doubts.
0 -
@Gordon Collett It just seems that no one 'in the know' joins and liaise with us on Community. We need a voice that has direct contact with tech staff and for them (in plane English) to explain broadly what is 'actually' happening behind the scenes (rather than leaving the Community speculating).
The outline you described with the functionality on the 'standardized place name' field I have not found to be true for a long time - until another change recently made this January. It seems 'place-name' has reverted to some old coding error reasserting itself - if I edit the place-name entry to reflect the full place-name the auto-standardizer overrides my edit and forces only a near match standard place-name. This is totally unacceptable for two reasons - firstly (unless I make a typo) what I write GOES, secondly the proffered forced place-name is often incorrect (there is for example a place-name 'Spencers, Saint Philip, Barbados' which is missing from the standard-list, offered is 'Spencers, Christ Church, Barbados'. If I edit the field to correct the entry I am forced with the entry 'Spencers, Saint Philip, Antigua and Barbuda'. As I have said this is new since newyear (although I had seen it sometime very early last year).
An additional issue I found is that an informative page was created on FamilySearch and then quickly gets removed (without an auto redirect being created to lead a searcher to a revised or new page on the requested subject) - the example - in March 2021 the page "How do I request an update to the database of standardized places?" was written and quickly removed without explanation or an alternative - this is childishly poor in this day an age. Importantly on that page was described how to contribute to adding missing or correcting Standardized Place-Names (you can do this by accessing www.familysearch.org/research/places/).
0 -
@Stephanie V. Problem attaching sources for parents in the 1841 England and Wales Census
The 1841 England and Wales Census does not contain relationship data.
When attaching sources from the 1841 England and Wales Census starting by attaching a parent of a family. It is then not possible to attach another person from the same record as spouse. The linker will only allow attaching the person as a child even though the person's age is clearly an impediment.
The only workaround is to open the linker for one parent, attach them, then close the linker and open it again for the other parent to attach them. After that the children can be attached. Significantly more time, effort and web traffic.
0 -
@A Andrews someone "in the know" had responded in this thread. https://community.familysearch.org/en/discussion/comment/537951#Comment_537951
0 -
@LDS Search Test , we already know you are stuck with a broken version of the source linker page because you can't change back to the old one, but regarding:
When attaching sources from the 1841 England and Wales Census starting by attaching a parent of a family. It is then not possible to attach another person from the same record as spouse. The linker will only allow attaching the person as a child even though the person's age is clearly an impediment.
Can you do the following?
If I take a 1841 census hint and go to the source linker:
I can drag anyone I want to to the spouse field:
Then add that person as the spouse so I can attach the source:
(Which I'm not really going to do since I was just looking for a random example.)
If the person already has a spouse, the dragging is even easier:
(This is on Macbook Pro, Apple M2 Pro, Retina Display 14-inch (3024 × 1964), MacOS Sonoma 14.1.1, Safari 17.1.2. )
Is this kind of dragging also broken on the source linker page you see?
I can even drag any of those Others On Record to the upper parent of focus person fields without any trouble:
Establishing any relationship I want even though the source itself has no relationships. Just for completeness, here I've drug the last two Others On Record to be children and siblings of the focus person:
0 -
@Gordon Collett Great workthrough, but sadly I am unable to do as you describe.
When I drag the 'person who would be spouse' from the person in record (left lower) section to what would be their correct position as spouse on the left or right section, the graphic element bounces back to the left side section for children. I can drag it back to the persons in record section and start again, but any attempt to drag it to the spouse section fails to connect and it moves to children.
If the code is attempting to read relationship data and failing, I would have thought that it could also check the validity of the age of the person in the selected record and compare it with the focal person to validate the presumption that they are a child. In the last case that I tried, the two people differed in age by 3 years, clearly not mother and son.
If I perform the same type of operation on a later census which has relationship data included, then as soon as I open the source linker for a record that has a person attached, but not their spouse, then the source linker automatically positions the unattached spouse in the correct location on the left side ready to be added.
However, in one record where there was a family with three generations and two married daughters, the relationship data was obviously being used preferentially, and age ignored. The linker predetermined that mother and son were brother and sister so I had to drag the reluctant pony into the box to create the correct relationship. I think the intention is laudable, but the implementation still needs refining.
Incorrect selection of candidate after selecting another person from the record.
In Source Linker starting with a record with some unattached persons and the focal person already attached.
Close the tab
From history, Reopen the last closed tab
Select View Record
-> The right hand side bar Opens
Select one of the unattached persons
The Source linker now opens with the previous focal person as the target and the selected person as the person to be added. It has taken the person selected from the right hand side bar as the target, and now attempts to attach them to the focal person. This is not the desired outcome.
What was expected, was to open the source viewer with the selected person as the focus, but unattached, so that they could be attached using the chooser or by entering the Person ID.
The workaround is to not choose another person from the side bar, or if you have done already, then,
While in Source Linker, select view record -> the right hand side bar opens.
Select View Record at the top of the right side bar. -> the record opens in the Source Viewer.
Ensure that the intended target is the focal person then select Open in Source Linker and attach the person as you would normally.
0 -
@LDS Search Test So you can't leave the new source linker and you can't drag items properly. That brings up some questions. Have you gotten stuck with a bad copy of the routine or are you trying to work with an incompatible browser? What is your operating system and version and your browser and version?
1 -
@Gordon Collett Not quite so.
True, I can't opt-out of the new Source Linker, because the section of the page that would provide that option is not present. I'm still waiting for a response about the source of that section so that I can try to determine why.
Not true that I can't drag items and attach them. I can drag things around all day long, and I can attach them *if the conditions are right* but it seems that the new source linker will not allow a person it cannot predetermine to be a spouse to be attached as a spouse. If you can locate a suitable record in the 1841 E&W census for an experiment, please let me know if you can do this without any problem.
1 -
It might be a better experiment, and more quickly done, if you already have a Family Tree record where you have not been able to do this and the corresponding source. I could try on that specific record by detaching any parts you have attached and then starting from the beginning to try to attach everyone correctly.
0 -
New Source Linker reverts to previous spouse after attaching a child to a changed spouse
Starting with a record with step children, and the mother as the focal person.
Select change spouse, and select the parent of unattached step children.
Attach the step child in the normal way.
After completion, the source linker reverts to the initial couple relationship. This is not the expected situation.
This behaviour means that the "change spouse" routine has to be repeated for every step child.
In the old Source Linker, the chosen couple relationship would persist, so that all step children could be attached.
0 -
Or is this equivalent to what is not working properly for you? In the census record I am attaching, the indexed record does not provide the daughter-in-law or granddaughter relationship to the source linker and so those two record remain under Others On Record even when the husband/father of the two is moved to be the focus person. But I can drag and attach them just fine: https://youtu.be/Fsbn6HMikHQ
0 -
I don't know whether it is only occurring on my machine/browser because I have nothing with which to compare it. Previous posts show that @Caribbean Historian has been experiencing some of the same problems, I don't know if they are all common. If I could be allowed to revert to using the non-experimental source linker I'd jump at it, but until someone resets the latched opt-in I can't.
I don't do youtube.
0 -
Behavior when attaching sources to families with half-siblings is definitely not working properly. I can confirm that bug. See it in action here: https://youtu.be/G8Gm5_FoOD4
What is your machine and browser?
0 -
Hooray I've been able to attach a person from an 1841 census record to a spouse - * when the spouse already existed *
I just kept trying and eventually after dragging up and down and sideways all over the spouse section, the background changed to a pinky purply beige colour, and it held fast.
I'll keep going on other records to see if the same dogged persistence will work for a case where there is no existing spouse.
0 -
So basically, the target area for the dragging is too small in your set up or something is not getting triggered properly. That is why the programmers need to be reminded of your specific conditions with enough detail to be able to duplicate and determine the problem. If they cannot determine the situation that causes the dragging to fail and can never reproduce the problem, they'll never be able to fix it. With my set up as soon as the spouse from the Others on Record section gets about halfway into the grey missing spouse box, the box changes color and I can drop the spouse into the box without any trouble.
If I work really hard and wander all over the page first, I do have to get the box being dragged completely into the grey box before the highlighting gets triggered.
0 -
On a positive note:
I like the fact that the new Source Linker automatically converts dates with a numerical month into dates with the name of the month.
Update: Oh no, I spoke too soon. It only appears to reformat the date while using the Source Linker. The actual date stored in the record is wholly numeric.
0 -
Re-iterating the 'Edits not saved' subject raised earlier by @Caribbean Historian
This is not only limited to the 'reason to attach source' section.
For example, in a census record, if I correct a place name from simply 'Norfolk, England' to 'King's Lynn, Norfolk, England' the linker appears to accept the data, but examination of the person record afterwards shows that the original uncorrected data is written into the 'Residence' entry within Events section. The correction made from within the new source linker is either ignored, lost or overwritten by the original data from the source.
The same issue occurs if a new person is created, and the birth date editted. The editted date is not stored.
This is extremely frustrating for me because I cannot revert to the old source linker to perform these corrrections.
UPDATE: After a number of trials with different format of place names, I conclude that the new source linker is only storing the standarized place name in the 'Standard Place' field. There is no attempt to store the residence place in the 'Place of Residence' field of the Residences of the Events section of the person record.
Also: after attaching with added data in the 'reason to attach source', then detaching and reattaching, the added data is still present in the field, so it's not getting lost, it's just not getting written to the section in the person record.
1 -
New source linker not triggering some updates to current status.
After a number of updates to data in person records using the new source linker, then returning to a person page. The fields which have been added will be present, or will appear very quickly as a result of refresh triggers within the page. But the hints in 'research help' or 'similar records' sections of sources do not get triggered so remain out of date: i.e. hints are still present even though the sources associated with the hints have been attached.
0 -
Fails to attach for no valid reason
Adding spouse to "https://www.familysearch.org/search/linker?ark=%2Fark%3A%2F61903%2F1%3A1%3A7X9R-F4W2&id=GH43-7SH" will not complete. Error "Something went wrong try again later"
0 -
Not picking up birth data from birth registration record to use for comparison.
When attaching a Birth Registration document, the linker appears to ignore the date in the record. The effect is that there is no matching person. The match may be selected from history, but it would be an improvement if it offered a match based on name and year of birth.
0 -
I don't think this is new, but Source Linker is completely and utterly literalist. If it's labeled "birth registration", then it's not the same as "birth", and the algorithm makes no connection between them. They may as well be labeled "arglebargle" and "Burt".
2 -
Since the Test is still only 70%, we will want to wait a few days before making the new Source Linker Test Group available to everyone.
0 -
@ScottSeegmiller Thanks. Yes I know about the group, but as you state, it is private, therefore no other users would be able to see what issues are being picked up. This open forum is available to anyone to review and to provide their contribution to either confirm or refute the issues that are posted. Thanks to help from @Gordon Collett at least one reported issue has been reduced from "bug" to "finger trouble" or perhaps "could be made easier for the user". That additional input is valuable and should help to reduce the number of reports that need to be passed on the the developers.
1
