Receiver filter matching incorrectly

[grobie]

The receiver dropdown/type ahead filter uses an algorithm to determine the weight of every receiver and bases the order of the results on that. It additionally caps the result set at 10 items. The mix in of filter properties made it harder for me to form a mental model of the behavior. I'd suggest to use a more straight forward approach, use a filter and always keep the alphabetical order. Like the file search in Github or most editors.

Example:

Type: prodeng
Expected: /p.*r.*o.*d.*e.*n.*g/
Unexpected:

• backend-engineering-productivity which includes all characters from prodeng, but in the wrong order
• osc-reporting doesn't even include all characters.

@stuartnelson3

[mxinden]

@grobie As far as I understand, the receiver dropdown is not filtering but just sorting. As backend-engineering-productivity is closer to prodeng then osc-reporting it is listed first.

Please have a look at my question here and @stuartnelson3 subsequent answer here.

[grobie]

Oooh, thanks for the clarification. That wasn't clear to me from the ux. Any reason to not just do plain filtering? Like in editors when searching for files.

…

On Sat, Jul 29, 2017, 15:56 Max Inden ***@***.***> wrote: @grobie <https://github.com/grobie> As far as I understand, the *receiver* dropdown is not filtering but just sorting. As backend-engineering-productivity is closer to prodeng then osc-reporting it is listed first. Please have a look at my question here <#910 (comment)> ans @stuartnelson3 <https://github.com/stuartnelson3> subsequent answer here <#910 (comment)> . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#933 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAANaHS9NMKRAslIKKei199wqmH1j1sBks5sSzoGgaJpZM4OnVZf> .

[mxinden]

Not sure. I would have to redirect this question on to @stuartnelson3.

[stuartnelson3]

What we currently do is find string similarity and sort based on that. There's absolutely no reason why we can't add on to this (basic) functionality to e.g. filter out results whose similarity value is below a threshold.

The starts to become difficult because we'll be more or less arbitrarily picking a similarity value as the cut-off, and seeing how it works.

@grobie would you be interested in running a branch at SC with this enabled? It would be super helpful to tune the threshold based on a large production deploy like what is currently there.

[grobie]

I'm unsure about that approach to be honest. If I type prodeng I don't expect to see results for engineering productivity. My personal expectation of that feature would be to use a simple search behavior without any weighting as written in the (updated) issue description.

[stuartnelson3]

Ok, I understand. The current search is matching because prod exists in both, but you expect as soon as you type prode that productivity would disappear from the list, because there's no match for the additional e.

[beorn7]

As long as the best matches are on top of the list, and the total amount of displayed matches is limited, I actually prefer to show the fuzzy matches, too.
That's also more and more common around the internet (I guess with fuzzy-searching large databases becoming more feasible), thus the moment of surprise @grobie encountered will become less common. The main use-case would be to be resilient against typos.