I would expect items with a contiguous selection of the search characters to be found
Actual result
The search results include items with any non-contiguous set of the search characters
Environment
Web browser - latest version of Chrome
No third party scripts
Additional information
Here I am trying to search for the term âCrestviewâ. Crestview is in the search results, but about 10 items down from the top. The top of the list is populated with terms that have any non-contiguous set of the search characters.
Your problem is very much like my post Item Finder Results. I think it is better now than when I posted, but I still have some strange situation. Like when I search for âErieâ, in the third letter âiâ it starts showing âSerialâ & âVerifyâ, and I have âErieâ the exact word.
It does seem like the same, or similar, problem. Thanks for providing a link to your prior bug report.
I agree that fuzzy search is nice, but exact phrases should be at the top of the list, then partial matches with a significant number of contiguous characters matchingâŚand near the end of the list should be items with only one or two contiguous character matches.
Right now, items that clearly are not the target of the search drown out the item being sought.
UmmmâŚwhy is this marked âfixedâ? As far as I can tell, itâs still very broken.
I know I said âthank youâ a few days ago, I meant âthank you in advance for the fix you are going to implement.â
The search results still favor results with non-contiguous characters from the search phrase over exact matches â which is nonsensical. This feature is broken.
Iâm still in the middle of tweaking the weighing but it shouldnât completely eliminate non-continuous results. Thereâs still a few cases that fuzzy search is useful: initials (âsfâ matching San Francisco Airport), typos, reverse letters, sometimes you only remember a part of the word, etc.
@David_Goggin
I do completely agree that continuous results should be ranked on top - if you have cases that doesnât do that, please show me what the query and matched texts looks like and Iâll check why my algorithm isnât working properly.
@KC Iâll check the @Pablo case in your first screenshot.
BTW, I didnât expect this to be fixed overnight or even be that high on the priority list. But I became concerned when I saw it marked as fixed this morning and I was still getting non-contiguous search results listed above exact matches.
I tested it again just now and it appears to be listing exact matches first! Yay!
BTW, are the search results supposed to be a scrollable list? For me the list is static â showing a few top results, but I cannot scroll down to see if there are any other search results further down in the list that are of interest.
Thanks for the reply. I never said that fuzzy search should be completely removed. But for my examples, I have over 20 Pablo and 4 Santos, and the Item Finder only shows 6 results (yes, I only see static results too), should continuous results be on top of the list? I think the ideal results should show as follow.
Search - San for Santos
1 - San Diego
2 - Santos
3 - MorningSanDiego
4 - s a n
5 - a n s
So the way the algorithm works is really just penalizing each result based on a number of criteria:
How close the matches are (more distinct pieces gets punished)
How well the search matches word initials (characters that only match middle-of-words gets punished)
How far back the result was (if the match happens more at the end of the text, it gets punished)
And a few other edge cases like misspelling a word, which all get penalized in the final scoring.
In my opinion, to get accurate results, you should use at least 4~5 letters. Itâs more difficult to say whether âsaâ matches more closely to âI feel very sadâ or âSouth Americaâ.
In our previous iteration of the algorithm, there were times where typing a full word (5+ characters even) would lead to results matching individual characters spread across a sentence, before the almost-exact match which happened to be near the end of the text. A good example is in the original post. That should be fixed now though.
It is interesting to looking at this situation from the perspective of a programmer. And even I totally donât understand why âItâs more difficult to say whether âsaâ matches more closely to âI feel very sadâ or âSouth Americaâ.â, but I thank you for all the time you spend on tweaking and explain it to me. Have a great weekend and stay safe.
Thanks for working on this â Iâve often had problems with irrelevant results in the Item Finder, which is partly why Iâve resorted to workarounds like prefacing important items with . or \. Iâm looking forward to being able to scroll, as well as seeing how the prioritization can be improved (so hopefully I wonât have to scroll, and maybe I wonât even have to mark important items).
One related wish: would it be possible to include results where the words are in a different order?
(I have many items whose name includes two or more keywords whose order is somewhat arbitrary. Examples: âCSS Customization / Customizing CSSâ âMusic Reading Apps / Apps for Music Readingâ âMedical Philosophy / Philosophy of Medicineâ âDynalist tools for Chrome / Chrome extensions for Dynalistâ. It would be nice if a search for two or three of the relevant keywords â or the beginning of the keywords, e.g.: custom & css, music & reading & app, medic & philosophy, chrome & dynalist â in any order would suffice to locate the item.)
While Iâm dreaming, let me add one more wish: for Item Finder to also search path names. If this were combined with the above wish of flexible word order, then I could use the Item Finder (or Move Item function) to search for, for example, notebook software reviews and find the relevant item no matter whether itâs currently named and filed as Notebook Software Reviews or Software > Notebooks > Reviews or Notebook Software > Reviews or anything similar.
Regarding word order, thatâs something we can consider although it could be a pretty big change to the algorithm, and could have some conflicting behaviors in terms of ranking the results. What youâre suggesting more closely resembles our search (filter) algorithm for searching within a document.
As for searching the file path, I think thatâs a possibility too. Iâm pretty sure itâs been posted somewhere in feature requests before.
