FamilySearch Employee Responding to Search Page Feedback
Answers
-
This site is now just about impossible to use.
Very disappointed in the changes made as it is no longer user friendly and very frustrating for us common ordinary folks. I sure am glad it wasn't like this 10 years ago when I was working on a family book!!!
7 -
Your observations are perfectly valid. It is undeniable that the new search format shares a great deal in common with the old one. It would have to, otherwise it wouldn't be a search interface. It then begs the question, why did it have to change so significantly?. Until it was inexplicably removed, I had posted an idea about making subtle changes to the new interface that would appease the vociferous and disappointed users who have all expressed the same reaction that it is not just different, it is significantly worse. I was editing that posting with a revocation citing all the errors I am continuing to find when the entire idea was mysteriously erased and is now lost forever.
Until the errors are corrected, the new search will continue to attract adverse reaction, regardless of the change in the format. But, from what I can see, the greatest proportion of the negative response is not with the failure of the engine to work as expected, but with the poor useabilty of the new "Look and Feel". That still needs to be addressed with some urgency or contributors will just be put off. Not only by the awkwardness of it, but by the continous worry that learning to use it will be pointless when it is spontaneously changed again. I have read numerous postings from people like myself who have seen the detrimental effects of "improvements" over the least 25 years.
It is good to hear that you are managing to work with the new format. At least it means that some positive work is being done. For the rest of us, it is a severe disappointment, and contributions are suffering.
On the bright side, now that I can't get as much genealogical research done, I have become an avid contributor to the Ideas boards. Until it gets improved, this can be done with ease.
2 -
I have used this site for years and loved how easy it was to navigate and use for the most part, now I can't even look at it without cringing, IMO this was not good idea to implement all at once. I will no longer use the search it is too much of a mess. I will come back once in a while to see if changes have occurred, until then I will not use the search.
7 -
Like many others have said, There is way too much scrolling necessary to use the Search Criteria area. On a full size monitor I would think zero scrolling could be achieved.
7 -
Here is another example of why the new search is so hard to use. Even when using the 'datasheet' view, the scroll bar does not always appear. Making it impossible to scroll over and see the rest of the results.
See image below - there's no scroll bar:
It requires pulling the right scroll bar all the way to the bottom before the horizontal scroll bar can be seen.
I'm using a 1920x1080 monitor, I shouldn't have to hunt around for the horizontal scroll bar. The window should have been sized so that the horizontal scroll bar is always visible.
It took me a while to figure this out, It's not intuitive at all, especially when there are 3 window 'panes' and 3 vertical scroll bars.
4 -
That's a slow pitch softball response: We are the beta test group. It was available on beta.familysearch.org well before the change - now it's live. Unfortunately most of us didn't use it before it was released. They really needed all this feedback before...
...and even then the beta database wouldn't be an adequate test for production Search> Records issues...maybe...
I don't claim to be an 'expert user' - I need FamilySearch to educate me on the Search Parameters in this 'new Search'...
General Comments:
SAME COLLECTIONS + SAME SEARCH PARAMETERS => SAME SEARCH RESULTS ...
... but I'm seeing all kinds of posts that this is not the case...
Educate me ... please ...
Parameters part of the equation:
There appear to be indications that the Life Event Search Parameters are functioning differently. Why would that be the case? What is the difference between Life Event: Any Place and Record Options: Location? Obviously one could input a Year(Range) - but a year range for what? The Search>Records splash screen default options say "Year: Birth or Death Year". Any place meaning - any place of birth, marriage, residence, death Events? That's certainly what I would assume...that's the intuitive meaning...but is that what the Search> Results are showing? Perhaps, I do get results from people scattered from all different locations - so maybe some of them or all of them either were born, married, resided or died in the place I input... I don't know I haven't had the patience to sort through the Results well enough yet... but that's certainly the apparent functioning as far as I know to this point. SO if I change the Life Event: Any: Year (Range) for the span starting year- when I think the person was born - and end date - when I think they died - I should get any record recording any Life Event within that Year (Range). From the research I have been able to do I believe the 'old Search' default parameters differ in that 'Search with Life Event: Birth' was the default. And of course the 'relevancy' ranking - why was 'old Search' Results seemingly resulting in better relevancy to my Search - what has changed in the algorithms? Do I need to slide Exact Results on and check the Name Boxes so I get more relevancy to the name I am searching rather than relevancy to the Life Events? Wouldn't Any: Place theoretically return more Search Results not less as some users 'appear' to be stating?
So if this is the case and I only want to see records from the place I am inputting for a Life Event - I guess I need to add the Record Options: Location which only allow two levels (as far as I understand it currently) - Country or Location and State or Province. Does this mean if I want to restrict records to any other level I just enter that in Country or Location? Chicago a city for example - ore would I need to put Chicago, Cook, Illinois, United States - that's a Location?
My suggestion for Search> Records Parameters to match 'old Search' defaults - if users were typically using the defaults: change the Life Events from' Any' to 'Birth'. This default setting is verified through Internet Archive: Wayback Machine prior to rollout of 'new Search' (note: the order of Life Events has changed defaults in 'new Search' I believe).
if the parameters are truly the same and you were using default settings this should do the trick. If you weren't using default settings and typically were not entering Life Events - I don't know...
Why would any of these parameters be functioning differently than in 'old Search'?
Collections part of the equation:
Are there database optimization issues going on behind the scenes that are removing Search Results?
Have we 'lost' collections? Are the indexes in a state of flux?
I don't know... educate me...
A better way to get these Search problems fixed:
https://community.familysearch.org/en/discussion/104538/more-comments-about-changes-in-search
3 -
I have to wholeheartedly disagree with you I’m sorry @dontiknowyou I’d say I’m what @LDS Search Test referred to as a ‘power user’ and a long time contributor to the platform who has been working primarily from my tablet the past few years (it can be done!). I have been encountering so many issues on my tablet, that I was starting to suspect the new UI was undertaken with little testing done with tablet use in mind.
Many of the issues I’m having are the same as have been voiced here and in other threads, but arguably some are magnified due to the smaller screen size. These include:
- Buffering time - the screen lags and has to reload every time I add or clear a search parameter; the “more options” is clunky, jerky and takes a long time to slide out and load every time I need to alter something; about 60% of the time the results don’t even load and it just gets stuck on the buffering circle or results in the “something went wrong” message, this also happens 90% of the time if I click back to results from viewing a record.
- A page having to reload every time I click away to another tab and come back, often again resulting in the never ending buffering symbol.
- Screen realestate - with no more than four search fields utilised (eg. birth range, birth place, name and location) I get no more than 3 hits fitting on my screen at once (fixed view, all information), when I start narrowing down with further parameters (parents, spouse, marriage, general date range etc.) those blue search field bubbles in the fixed top menu monopolise screen space to the point it was reduced to half a hit fitting on my screen at a time when trying to perform a detailed search the other day. This is worse in data sheet view (three screens width to view a single result). That was a painful couple of days before I found the fixed view option, which thankfully it now defaults to since I selected it.
- The three separate search menu sections (fixed top, sliding top, side advanced) - takes more unnecessary realestate as mentioned. The blue search field bubbles are literally just repeating what is entered in the advanced menu which, lets be honest, for any kind of specific returns in results are really necessary basics and not advanced at all. But specifically to tablets, splitting the search fields like this seems to just be creating more processing drain, creating longer processing times and opening the door to more system bugs (I’m not a tech but this is the closest I can get to explaining my user experience).
- Responsiveness - the new UI has difficulties differentiating between if I’m trying to scroll the “more options” menu or the results, even if I’m scrolling on the menu; the search button at the bottom of that menu gets ‘stuck’ below the screen and more time needs to be spent trying to pull it up to hit search. When viewing the pop out summaries of records and the “more options” menu the close icon has to be tapped to minimise these rather than being able to tap/click away anywhere else on the screen as is intuitive.
- Clicking and scrolling - there is so much more of it!!! This is really not what you want when your working on a small screen without a mouse.... and even then, the consensus is not good. And do we really need so much white space?
- Collections - you can no longer click straight on a single collection in the collections menu and it will perform that search. You now need to tick the box next to it (as you would for multiple selections) and then scroll all the way down to the search button (again, more clicks). Also the collections menu seem to default to whatever submenu you performed your last search in. So if I perform a BDM collections search and then a CENSUS search I have to click out of the BDM sub-menu wait for the main menu to load, click on the CENSUS sub-menu, wait for it to load, make my selection and then search. It’s all round more laborious.
- The Residence/Event Location information seems to have been removed from search results - is this happening for desktop users also? It makes searching through census records in particular a painful exercise of viewing every hit to find a match. I don’t know about anyone else but I don’t have the time to look through 600+ results individually.
- Results - I know @Casey Robinson 001 has said we should be getting the same results as before if we are performing the same searches, so I can only assume there is either a glitch or the algorithm has been changed. For example, if I search a date range and county, I’m getting top results outside of both parameters. Another example, it took me the better part of two hours to locate a census record that was the second hit in an Ancestry search. I’m also getting far more results per search over all, which is false economy when so many of the returns are irrelevant.
Needless to say, I never had any of these issues with the old interface and found it quick, responsive, generally accurate and easy to use on my tablet. And yes, I have tried clearing the cache/deleting cookies and rebooting etc. it didn’t help.
I’m actually not opposed to updates and improvements... but they do need to be improvements.
I also understand the impulse to want to encourage new users - we were all new users once and it doesn’t hurt to have generosity of spirit towards them - however, if everything is constantly oversimplified to accomodate the inexperienced, it denies them the opportunity to competently grown into meaningful contributors as there’s no impetus to learn the more complex (but still, not that hard) search methods.The messaging I keep seeing from the family search team on here can be summarised by “everything you use is still there, but it takes more clicks, more scrolling, more steps (more time!) to find it”.
My concern here — and I’m digressing from my initial point about tablet use, I know — is the ripple on effect this change will have. This gearing toward new users is alienating the experienced users (as evidenced here in the forums) by making the search process laborious. There is no way around the fact that it is the experienced users that are responsible for the majority of accurate and reliable information and research, particularly within the family tree/PIDs. There is a learning curve for new users in which, no matter how enthusiastically, they will make errors and it is the experienced users that take the time to untangle these errors. Without them, the accuracy and reliability of information on FamilySearch is going to take a hit. I can’t tell you the amount of time and energy I’ve spent, in good will, untangling multiple individuals from erroneous merges and inaccurate relationships, but without a quick, accurate and efficient search option to be able to efficiently check sources to verify changes, I just don’t have the time needed to contribute in this way on top of my own research.
I’m under no illusion that we will get the old interface back, but I sincerely hope the development team are receiving our concerns and planning adjustments accordingly. We were asked for feedback, I hope for there part they take it on. As it stands I have a lot of trepidation over the continued rollout of these updates throughout the site. I saw the proposed new profile format a while back and was not a fan. Thankfully it has stopped showing up...for now.
9 -
Are you using the browser on your mobile tablet or the app or both? It might be good to put what device and browser or FamilySearch app your experience is documenting. Sorry I haven't used the mobile app to see how the updates have affected usability. I think I saw a 'mobile' icon version of Search around here on one post somewhere - it did change the screen size so just wondering if you are using that or 'desktop website'?
Usability test of Search> Records on Android phone - wifi connection - Chrome browser:
FamilySearch Family Tree app: Ignoring whether the Results are relevant -with some tweaking of Data Sheet Preferences - it almost seems 'easier' to search on the phone than with a laptop. Because yes, on a phone you expect to have to scroll - so I hope the results are relevant.
Browser: Results were similar to the app. Ignoring Search Result relevancy the functionality is 'pretty slick'. Yes, plenty of scrolling, etc.
1 -
Slow loading: I used to type in what I wanted, click - and results would be on the page in <2 seconds. It now takes 15-20 seconds with the screen waiting and pulsing and fuzzy before results are presented.
Slow loading: If I wanted to look at a record I'd click and <1 second there it'd be - it now takes 15+ seconds for a record panel to appear on the right.
Copy/paste: I start with doing some searches and copy/pasting information into Notepad, so I can sort out if I've got the right records. Only then do I start to think about trees/attaching. When a record loads in the right hand panel I can't copy/paste the information any more.
Copy/paste: Looking at a Census I used to just select/copy/paste the results into notepad while I worked out, across 2-3 censuses if I'd got the right people. I don't build trees for everybody; sometimes I'm just compiling a quick and dirty time line for now. I can no longer select/copy/paste the census data as each item is on a separate line. e.g. instead of a husband/wife pasting as two lines, they now paste as about 20 lines in a vertical stack.
How I Work: I flit around the records, looking for the backbone of evidence that I've got the right person. I copy/paste that into Notepad to see if I can quickly find: birth, each census, death. At this point I can ascertain either "I have the right person/family", or, "This is going nowhere/I'm going to abandon this".
I do a LOT of "quickly dip in, find and present it" searches for new people, for those struggling. They are stuck, so I quickly see if I can find who they're after, by building a quick timeline in Notepad - and I'd then present them with their missing piece of the puzzle by linking them to the relevant FamilySearch record. I will now not bother as what used to take me "Just 5 minutes to find the missing grandfather you have not been able to find in your 20 years of searching" would now take me 2-3 hours to be unsure. That is too long for me to be "interested" in helping people (specifically online, where 10 others might also be looking); I have a high success rate at finding people, using only the FamilySearch search page that I could load/search/get results in SECONDS before, with confidence I'd found the right person.
I suspect my "volunteering" days are now over.
4 -
Here's some more evidence that the search engine or prioritization of search results is not working the way it used to:
William Joseph Wilson (GMS1-NLK)
1900 census is attached to him as a source.
I click on 'Search Records'. I know for sure familysearch has the 1900 census record in its database since it is attached as a source.
But what comes up? A bunch of records of people born in Canada.
At approximately record 250 I find one buried in the midst of all of the people born in Canada that actually is for the person I am looking for (but it's not the 1900 census record). The 1900 census record may be in there somewhere but after scrolling through 250+ records I will have given up:
Now I select 'Mexico' as 'exact search'. I get another 600 records of people born in Canada, with the same record from Mexico around 250.
The 'exact search' did nothing that I can tell.
Then I select the filter for 'birthplace' of Mexico and get the same result. No filtering has happened.
OK. So now I filter by collection. I KNOW there is a 1900 census record for this guy.
And here it is item number 3 out of 8, after 2 records with a birthplace in Canada (the other 7 are also all birthplace of Canada).
Before the search engine changes I would have found this record near the top of the list first try. Now it is still hard to find it even when I know exactly where to look.
The 'exact search' box did nothing, and the filters for birthplace did nothing.
But besides that, why is Canada birthplace being pushed to the top?
Here's another version of the search, this time with 'residence' of 'new york' from 1900 to 1900. That should help narrow down the search, but I get a bunch of junk that barely fits.
The first entry is for someone born in Canada, whose residence in 1900 is North Dakota. How could that possibly be the top entry given birthplace of Mexico and residence of New York?
The record I was looking for shows up at approximately number 50, after dozens of records with no birthplace or residence place. Why are my search parameters of birthplace and residence not being considered when ordering the search results?
5 -
That's some serious research and documentation - hats off - thanks! It makes me wonder right off the bat - was a switch flipped so that Search Results rank 'all ready attached to Tree' records so low or something? Shouldn't the Results return the record being searched for whether already attached? I don't know ... just a guess ...
0 -
Good question. It doesn't seem to have anything to do with being attached or not. That last search the record I was looking for was approximately 60th in the list. There were 7 records attached out of the 59 or so above it in the list, in no apparent pattern related to the ranking.
There are many records near the top of the list where birth date, birthplace, and residence are all blank. Why would those be listed above records where the search parameters of first/last name, birth year, birthplace, and residence place and year all meet the search criteria?
3 -
But with comments like yours it has to get fixed quicker... Hopefully it will give the engineers something to work with.
In your search parameters for last search - sorry i don't recall - did you try Record Options: Location: United States: New York? If you restrict those does that help/get rid of Canada results?
I still think there is something going on with the ranking of Life Event: 'Any Place' ahead of any other Life Event ... I don't know ... maybe all the other people had a Life Event in that place??
By the way, there may be a bug in Life Event.
If you remove the default Life Event: Any and then add any other Life Event and continue entering the parameters - I am seeing that an Any event is auto-populated... I don't know if this is related to the Search issues but would seem to be ... maybe ...
0 -
The relevance of the results is now good again. Thank you.
1 -
You make a very good point, I should have been more specific, thanks.
To clarify I’m on an iPad using safari to access the ‘desktop website’.
I’ve not tried it on my phone, so I can’t speak to whether there is a https://m. version of the website or not, but I’ve never had any issues with the full web version working on my iPad before now.
I haven’t checked the app since the update, so I can’t speak to that either. But I did used to have the app and found it far too simplified for the work I was doing; it wasn’t a value-add so I have stuck to the full website, particularly as I frequently work across multiple tabs in my research.
I did post some screenshots of what it looks like on an iPad using data sheet view (prior to finding the fixed view option) back in Casey’s original thread, for reference. It’s very similar to what the desktop grabs are showing but far more claustrophobic: https://community.familysearch.org/en/discussion/90536/hello-familysearch-community-try-out-the-new-update-to-record-search/p4
It’s good that it seems to be working for mobile users, and for casual users I guess I can see how mobile browsing might be appealing. But for anyone doing solid research, I personally can’t see the viability of doing serious research on a phone — functionality or ergonomically.
I’ve been trying to acclimate to the new UI for over two weeks now and I still keep coming up against those issues I mentioned and ending up frustrated. I’m doing the majority of my source checking on Ancestry now.
2 -
How do we get these Search problems 'fixed'?
I hope to be educated by FamilySearch in Community about how to use Search> Records successfully...
0 -
Good find on William Wilson US Census 1900, New York. Since the Search could not find the Result I added index Edit 'William Wilson' alternate name - that should help find in Search Results after that is updated.
0 -
On genthusiasts suggestion I tried setting the record location to New York. And it did not find the 1900 census record at all! It only found one 1900 census and it is not the right one.
Same thing with spelling of name as 'Willson' with 2 L's. Using the record location fields in the search seems to have broken it completely. Or maybe I should have used record location of 'Washington DC' since the US census records physically reside in the National Archives? (that was a joke)
0 -
A further indecipherable Search Result for your William Wilson
Even when giving it Exact Search options which should return the correct Search Result - it doesn't...
0 -
Can you please examine the feedback element shown on the right hand side in some of those screenshots and let me know what the element source is. It doesn't appear on my browser and I want to find out why. If I'd had one of those I would have been using it a lot.
0 -
These Search Results seem sticky even if using RESET ALL the Search Results stay on the screen - usually - i did see once when they were cleared... testing...
@JeffLuke Removing Record Options: Location and using Exact Search does show correct results??
Time to clear FamilySearch cookies/cache - logout and log back in? You should have the Feedback button - especially on Search Results. Are you located not in USA?
0 -
The best search parameters I can determine for searching your William Wilson (at this time)
NOTE: See how the default Life Event: Any has been replaced with Birth event?
Comment: For incorrect Search Results please give Specific page Feedback to FamilySearch engineers. This should help them understand our frustrations as users and help them correct the Search algorithms.
0 -
The first time I tried the new search screen I hated it. So I walked away and fumed for a while and then I came back and studied the screen. I began finding new ways to access the same information I had found in the past. I still don't love it, but I think with time I will learn to use it without getting a headache. And I assume you will continue to work out the bugs. I know you have good intentions and are working hard to give us the tools we need to find our elusive ancestors. After all, isn't that the point?
1 -
When I said the mobile device FS web interface is much improved (above), I was talking about smartphone devices. On them usability is hugely improved.
Most of the outcry here is about the desktop web interface to Search, which is recently changed. However, we are also discussing that the search algorithms themselves are broken. In my experience they have been broken for months. Searching on event places and date ranges has become very frustrating for me due to the results including so many non-matching records. For this reason I have mostly abandoned Search in favor of just working on PIDs and letting FT hints search for me.
0 -
Are you finding that the FT hints are good quality with the Search being so squirrelly right now?
0 -
I believe the text turned a different colour after viewing an entry before, a slightly paler version of the original?
Although it was not as prominent as the red example shown below
0 -
Are you finding that the FT hints are good quality with the Search being so squirrelly right now?
Yes.
Historical records Search and FT hints clearly are independent systems. Think about it. Search works on the FS historical records database without reference to any information in FT. FT hints works from the tree and attached sources that are FS historical records. Of course, where the tree is bad, hints will be bad too. When I first began genealogy work I read the "expert" advice to search, search, search in FS historical records and ignore FT. I tried that and soon abandoned it in favor of cleaning up FT. FT is a genealogy power tool; how it is used, badly or well, makes all the difference.
Hints are excellent if the person's details are standardized, relationships are correct, related sources are fully attached, and unrelated sources are fully detached.
It is my impression that once a PID is fairly well filled out, the vital details become least important. If I am not getting hints but expect to, because related PIDs are well sourced, then I remove any unsourced details from the PID. That removal usually triggers a flood of good FT hints. So many unsourced details are guesses, most guesses are wrong, and wrong details on a PID end in conflations on the one hand and brick walls on the other.
4 -
On the exact matching front, an exciting development: in the Q&A topic Download results from exact searches a user reports seeing "Validation failed. [Unsupported parameter=exactSearching=[true]]"
0 -
The Validation error for exporting exact matches (through More Options: Preferences) I believe is separate from problems with Search Results.
I hear what you are saying about hints in FT and that Search could be 'better' from there - but take a look at @JeffLuke posts on the previous page - that's an example (without inspecting FT too much) where the Search Results did not return well...
0 -
Strange. I've let the team know about this issue, from your screenshot it certainly seems like something has gone awry. If we can identify the issue quickly, it shouldn't be long until this gets addressed.
1
