Fuzzy autocomplete problems

[nonamethanks]

The latest autocomplete change seems to be a huge regression in terms of usability.
Some examples Unbreakable and I have experienced:

"shampoo" showing "shadow", "shamal", "shawl" first.
"wet_h" showing wet_hair only as the third result after "wet" and "wet_shirt". If I type "wet_hair", "white_hair" ends up being the first result instead.
"no_hu" returning "no_bra" instead of "no_humans" first
"blue_h" returning "blue_eyes" instead of "blue_hair" first. If I type "blue_hair", I get "blonde_hair".
"starry_" has "starry_sky" as the fourth result
"green_hair" shows "green_hair" as the second result after "green_eyes"

Autocomplete loses a lot of efficiency if one has to check where the tag is every time they need to tag something. Right now it's faster to just type the whole tag instead of using it at all.

[evazion]

The previous behavior was that fuzzy matching only kicked in when regular autocomplete didn't return any results. I think at the least, fuzzy matches should be ranked below regular matches.

[nonamethanks]

Yeah, I agree, they shouldn't be higher than matching results.

Some more examples:

[BrokenEagle]

ars said (forum #149984):
Looks like the tag autocomplete is now case sensitive, starting a word with an uppercased letter will not display any results.

[BrokenEagle]

iridescent_slime said (forum #149996):
The new autocomplete is far too aggressive in "correcting" less-common tags into more-common tags, even when they are complete words without typos. Just a few quick examples I've already encountered:

• cooking turns into covering
• from_below turns into from_behind
• looking_back turns into looking_at_viewer
• white_bra turns into white_background

This represents a major setback in usability. I pretty much have to type out all but the most popular tags in their entirety now, which defeats the purpose of having autocomplete. Hopefully the next revision doesn't give nearly as much weight to post count when determining the intent of the user.

[BrokenEagle]

Found another issue. Multiple aliases with the same consequent get shown, whereas before only one was being shown. If results do end up getting sorted by method, it makes more sense to me at least to put those toward the end.

The following is how I would order them based on specificity of intent:

1. Exact: The most direct and most likely intent, therefore the highest priority.
2. Prefix: The likelihood of prefix being intent is high given non-normal word combinations of letters.
3. Alias: I don't find myself using this option too often, although perhaps there are those that do.
4. Fuzzy: The least specific, and therefore the most unlikely of a user's intent.

2 and 3 could be argued, but 1 and 4 are pretty much spot-on IMO.

Just as a pie-in-the-sky type of request, but it would be nice if fuzzy and prefix results got some kind of visual indicator (like aliases) to show that they are not exact matches. Doing so would IMO better direct the user's attention, and lead to quicker learning of the autocomplete patterns for more efficient tagging and searching.

[deusexcalamus]

Yeah, this is a big setback, I can see how it'd be useful, but its kinda clunky right now.

[r888888888]

The trigram index has a crucial weakness that I think affects usability: underscores are treated as word boundaries. So when indexing "black_dress", it won't form trigrams over "k_d". That may not even be desirable since you'd want "blackdress" to match.

I think a more sophisticated algorithm is probably needed (even Levenshtein would probably be better).

[BrokenEagle]

The current limit of only 3 exact matches increases on average the amount of keystrokes needed to find a particular tag, and additionally it hinders tag discovery. For myself, there are many tag terms that I only know about because of autocomplete, or it keeps them fresh in the mind.

Right now, it's a bit like driving with low-beams instead of high-beams on an unfamiliar road.

[r888888888]

I've increased the return count for exact matches.

[r888888888]

I'm getting fairly good results from turning the fuzzy autocomplete into a kind of spellcorrect which is constrained by the length of the matches. It's not perfect (the gen_2_pokemon example still fails because the results are limited to 2), but it's nice for common 1-3 character misspellings. And the results are always low-weighted.