I broke it...
[Edit to clarify: This is a bug report for escalation to the engineering team. I'm not in need of help. I also don't need to be notified when it is fixed. Thanks!]
My first sight of the new Search on the web interface, after struggling with it for months on the mobile app, and I broke it:
Best Answer
-
Since you can work around the error message by only selecting an "Exact" match when something is in the field that is marked, we hope you will still be able to continue your research. We will report your concern in the hopes that if this is a "bug" you will be notified. Thank you for reporting your concern. When your issue has been forwarded to a specialty team that can verify whether or not this is a bug, you will be notified by email.
0
Answers
-
I noticed that you checked the exact box for a life event, but you didn't add a life event. I believe that is what caused your error message. I removed the "exact" option from eveything including the life event and got results.
Even leaving the "Exact" checked in the Surname field netted results...
You are welcome to use the "Exact" options, but perhaps be sure you add something in each field that you have checked as "Exact".
1 -
We were able to replicate this issue and found that if you look to the left side where the Advanced Search options are and scroll to the bottom, toggle the "Show Exact Search" bottom so that it is turned off, we were able to get 245 pages of results.
We hope this helps!
2 -
Yes, the search result is failing when I turn on the exact search.
Sometimes I know the birthdate but not place; I still want to be able to "exactly" match that much information.
1 -
Have you tried to just turn on the "Exact" match for only the fields where you have entered something? It seems that since you can chose the exact match for various section that rather than toggling every section on when you have nothing in a specific field, it might be better to just use "Exact" where you have entered information.
My investigation has led me to believe that since the software is sophisticated enough to read each section, it considers nothing in a field that is marked as exact as an error. That makes sense to me.
You may certainly do your research in a variety of different ways, and I wish you success with your efforts but doubt if the program will be changed to allow an empty field to be marked as exact with results.
Thank you for sharing your concern as others are also just learning about the recent Search changes.
0 -
I can't test this, since the actually-working interface has apparently been taken away entirely, but I believe Search used to simply ignore the checkbox if the place field was empty. (For some reason, FS refuses to apply "exact" to dates.) Returning an unexplained error instead is not an improvement.
2 -
Exact searching on date ranges absent a place has generally worked, but not always. I use it a lot. It was apparent to me that a lot of programming revisions were going on in the background.
Even if my using exact search this way isn't the expected user behavior, the result should not be a system error message.
The behavior of the historical records search interface has been so erratic for so long that I now often edit the PID strategically to use the FT hints system instead of the search interface. I am excited to try out the new interface on the web; using it (its parallel) on the mobile app has been difficult.
3 -
I had this screen displayed today, relating to similar circumstances.
This is bad programming - a screen should appear that gives some indication of a possible cause that the search was unsuccessful. This screen suggests reloading, or returning later, might solve the problem, which appears to be highly improbable.
Regarding the specific issue, the way an "Exact" search now appears to work (or rather not work) with this new interface is yet another backward step in our efforts to narrow down results..
2 -
@Paul W can you share your URL? The error I got is reproducible but for debugging it also helps to have other instances.
0 -
As a follow-up to this discussion, what you have reported is not a "bug". You chose the exact search for birth place, and left the place blank--so the system correctly returned an error message. This follow-up information came from the team that is developing the new Search feature, and is a great reminder not to use the "Exact" options if we don't enter something into field that is marked as exact. Even just a country for a location would have eliminated the error. Best wishes in your continued research.
[Note: A "bug" is a process that was not intended through the software we use, and while the current process is different that what has been used in the past, we have been assured that when you use "Exact" in your research, the system relies on what is found in all fields for specific information. ]
0 -
As I have commented elsewhere, not being able to leave the place name blank is a backward step. I did this frequently (using the old search) and was still able to get results with just a date range.
An example where this is useful is in searching for death records when the year of birth is known. Inputting the approximate date of birth (range) allowed for all those records where an individual's age at death did not match to be excluded from the results page.
Even if this behaviour is not considered a bug, the "error" page that appears is completely inappropriate, as it implies results might be found, in a later search, using the same criteria.
3 -
@Paul W, you are simply welcome to share your opinion. You are also welcome to go to Ideas to the left to share your concerns as explained about how to post formal feedback that you wish to be considered for future enhancements.
We are also aware that in some browsers users can see a Feedback tab on the right of the new Search Historical Records page and on results pages. Clicking that tab allows a user to share their experience, and this goes directly to the developing team to consider as they continue to fine tune changes that are made to specific programs and features.
0 -
The new Search interface makes it clear that the exact checkbox on an event is intended to apply only to the event place name, not to the event date (or date range).
This is counter-intuitive, and a deficiency, but at least now it is clear.
It is a deficiency because very, very often search users want to do an exact search on a date range, without guessing the event place. For immigrants birth place often is a significant ambiguity but birth year is known.
And quite apart from how Search is supposed to work, the resulting error message is in fact a bug.
2 -
I also disagree with the mod's/engineer's opinion. This is very much a bug. A nonspecific, unhelpful, and untrue error message is never, ever, in any case or in any format whatsoever, an appropriate response to a form being filled out in an unexpected way. If an option is selected without a necessary condition, then either the option should be ignored, or the error message should clearly specify the missing condition.
0 -
This exemplifies the problem with the new engine and the "More Options" section. Frequently the place name of a birth does not match the standard, therefore exact cannot be used, however the user wishes to return results ONLY for the years in the range, therefore requiring the exact option. The current mechanism does not allow this.
In a correctly designed user-centred query interface, a blank field will be treated as a wildcard, so leaving the birth place empty and simply entering a date range then switching on exact would work as intended. This is not the case here, which indicates that the query formatting code is wrong.
The only occasion when anybody would want to search for empty values is for database integrity checking, and that is well outside the realm of the user. So we must conclude that, either the system we are compelled to use is badly coded, or was intended for another purpose.
0
