Search doesn't first report results for the given string

[dmick]

Go search for "table". Why do I get nearly 7000 results, most of them for "tab"? Why is anything even shown that doesn't contain the five letters "table"?

Top result: https://addons.mozilla.org/en-US/firefox/addon/tabliss/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=search Even the addon page, if you click through, does not contain the string "table".

How hard is search? seriously?

[diox]

This happens because "tab" is one of the words that is so common that we try to look for it even inside other words, to help find add-ons about tabs that don't include it separately in their name (or the opposite: helping people that mistype "tab" or search for "tabsomething" find add-ons about tabs). I agree it's not ideal, a "did you mean" feature would be better but that's tricky to implement in a satisfying way too.

How hard is search? seriously?

It's hard to please everyone, and comments like these don't help. Pull requests are welcome if you think you can do better.

[smayer97]

I do not mean to be disparaging, and my intention is not to add to the sentiment, but I have to agree that the search results are not only NOT ideal, they are FAR from IDEAL. The problem that is being expressed is the fact that when you do search for a word or words, there is no apparent prioritization of the results such that you do not know where in the results you will find what you actually want that is a closer match.

The current solution seems to be an overthink of searching to provide better discoverability but it comes at the huge price of making simple direct searches nearly impossible. I'm a power user (case in point, I manage about 120 collections) and I find search often meaningless and impossible to achieve a desired search goal.

I am not a programmer (though I have done some in my lifetime) but how about considering one (or more) of the following that would DEFINITELY be MORE ideal than what things are now?

1. provide a simple traditional exact whole word match, that is contains ALL words typed. Include wildcards for those who want to increase discoverability (e.g. * for ANY additional character(s), to be used at start or end of a word)
2. if the current search design is kept, at last prioritize results, so exact matches show up first, then display the looser "matches" AFTER
3. provide a simple checkbox option in the search field (drop down menu?) to turn on/off the "discoverability" feature, where when turned off, behaves like 1.
4. add simple checkbox options for whole word matches, exact match, or partial matches

I'm not sure which would be the simplest and fastest to implement, and surely there are others, but I can assure you that ANY of the above options would significantly improve the usability of search WITHOUT compromising the scope of its current capability and please far more people than not.

Please do consider these options.

[diox]

Exact matches are already heavily boosted towards the top currently. If you have specific examples where it's not the case, please report an issue with the search terms you entered, the results you got, and the ones you expected and why.

We are generally against adding extra power-user features like special characters (that are pretty obscure for non power users) and extra UI that makes the whole thing more complex.

[dmick]

Did you actually try "table"? Thee are no exact matches in the first N results; in fact the string "table" does not even appear in the description page for the various tab add-ons, much less the title

[diox]

I have, and that's why I've asked for more specific details about what was expected. There are add-ons with "table" in the name in the first page of results - they could be higher, but we also skew results towards recommended add-ons as well by design - there doesn't seem to be any recommended add-ons about "Table", so that's why you see results about "tab" in the first few add-ons returned in the results.

[smayer97]

But dmick's example is EXACTLY the problem...and you acknowledge that the results are skewed based on "recommendations"... BUT as in this example, it makes it nearly impossible to find the targeted search term, since the results back are unrelated to the search ... tabs and tables have nothing to do with each other... yet there are FAR more add-ons, and therefore, recommendations for Tab-related add-ons, obscuring the desired results and forcing a user to either wade through a bunch of unrelated stuff (often PAGES worth) or just give up... Do those seem like desireable outcomes? And repeated experiences like that will accomplish the exact opposite of this algorithm... of increasing discoverability.

So this IS an example of how the skewing renders the search results useless... and there are many examples I have come across since this method has been applied...

BTW, why do you consider adding a simple on/off toggle to the algorithm as applying a "power user" type feature or it to be complex? I have seen this approach of clicking in the search field and an automatic dropdown below the field showing one or two options...it is unintrusive, is optional so no one is forced to use it but makes it at least possible to get the desired results when one needs it, especially when the algorithm fails to deliver.

The reply you give suggests that someone is wed to a complicated design because clearly A LOT of time was devoted to develop it (parsing the text, deciding what other words exist that could be searched on, adding those words to create an OR-type Boolean result list, sorting and applying a skewing criteria, etc) but is afraid to let go of, yet it often produces undesirable and poor results, as in the above example. It may be a "clever" design but it clearly is conceived and the making by a "power user". Unfortunately, it often fails to deliver adequate results with no clear sense of what the results are providing as to how they relate to the original search.

So why impose such a narrow and VERY unconventional approach to searching? It takes away all ability from the user to control the results they want/need, that may not fit. Seems like a forced solution instead of being open to listen to feedback based on real results and realizing and accepting that it is a design that needs to change.

BTW, there have been several other threads on this forum raising this issue, so it is not new nor uncommon... Please take a step back and consider what is being said.

[diox]

To be clear, as I said above I agree the current implementation is not ideal. I am in favor of changing it, and we have already done a lot of tweaks to improve it listening to feedback in the past. But we also don't have unlimited resources and there are a lot more parameters to take into account. For instance, we do want to skew results towards recommended extensions, because those are a lot safer for our users, and we do need something to handle typos, because we have data suggesting that users do make some.

[smayer97]

thanks for the clarification, and I do appreciate the limited resources (not sure how much your group was affected by the recent cutbacks at Mozilla)...

on the issue of typos and such, I get where you are coming from but again I emphasize, the results speak for themselves. When you frequently end up with a list of unrelated addons, as the above example shows, that either need to be waded through or the search abandoned, that should strongly suggest that this is not working as well as you think.

In other words, the attempts are well meaning but they do not deliver good results.

And when some makes typos and do not get desired results, I'm sure that more people figure it out and correct their mistakes. So to try to compensate for this seems like over-engineering.

Anyway, thanks for taking the time to respond. Hopefully some better (simpler?) solution will be implemented.

[dmick]

if I type "table", the top results should include the string "table", regardless of any other criteria. Any skewing or other sorting for recommended or any other criterion should act within that set. This seems really obvious to me. (and isn't "sort by recommended" already handled with the "Badging" dropdown?) Recommending a tab extension to me when I want a table extension does no good whatever; I'm not installing a tab extension. Correcting a nonexistent typo does no good either, as there's no action I can take as a user to convince search that I really did mean what I typed.

As it is, yes, 12 "table" hits do appear on the first page. Of 269, presumably with 25 entries each. With no way to show all entries so that I can sort them myself. So I'm left with no way to review all the 'table' entries, because I have no way of knowing which of those 269 pages of 25 entries has relevant results to examine.

The very limited change of "put the exact matches first before any other processing" would solve all of this in the expected way, the way all other search tools work.

[dmick]

(regardless, apologies for the grumpy venting.)

[smayer97]

Another thought.... why not imporve the tab vs table search as follows:

• perform search like Spotlight on Mac does.... do a CONTAINS search based on what the user types...that is a partial search, so tab = tab, table, tabulation, stable, etc (I know this is already being done) but if more than one word is typed, perform a CONTAINS ALL words, so tab AND for = tab, table, tabulation, stable, AND fortune, fortify, enforce, etc (so BOTH must be present), not OR as is currently being used.
• BUT if user types tabl, or table, results would NOT include tab, tabulation but ONLY a CONTAINS tabl, or CONTAINS table.
• then still apply the current prioritization you have now.
• and IF you still want to account for some typos (I still do not recommend this), at least sort these to be AFTER all the matching based on the CONTAINS and based on what is ACTUALLY typed.

I think this might give a balance between your prioritization but give at least some control to the user to be able to filter closer to what is actually desired.

BTW, other examples of very poor results.... Type "naus"... you get suggestions with the words cause, pause, etc. when one is trying to look for Nauseum. Or 'chute' giving results including "mute' and 'route' (huh?), but being presented with a list of 6 pages, the user has NO way to know if there are any useful results in the next 5 pages (it turns out there are NONE), so it becomes a HUGE waste of time for the user to scan through those pages only to be disappointed. Repeat that experience over and over and the confidence in the results decreases exponentially...again defeating the whole purpose of true discoverability, which is based on RELEVANCE to the user (and I do not mean your "RELEVANCE option).

Or type 'bitch' and you get lots of results with 'switch' or 'twitch', when one is trying to find Bitchute related addons, though I do see that it also gives "B!tch" in the results, which is not a bad thing (from a type-match perspective), but is a rare exception but the bitchute addons are lost in the SEA of switch and twitch.

So again, all these poor results in a LACK of confidence that the results are meaningful and useful. I do not think that is what you are trying to accomplish but that IS the effective result.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. If you think this bug should stay open, please comment on the issue with further details. Thank you for your contributions.

[smayer97]

This is an issue that STILL really needs to be addressed, please!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. If you think this bug should stay open, please comment on the issue with further details. Thank you for your contributions.

[dmick]

opinion remains unchanged

[dmick]

This is still an issue.

[smayer97]

WHy was the state changed back to stale after that state was removed? This force the automatic closure of this issue WITHOUT NOTICE and WITHOUT resolution!

Please RE_OPEN this ticket as this is STILL and ISSUE that needs to be addressed.