Type search in location form: prioritise prefix matches

[wbazant]

User experiences:

• "Apple" currently doesn't show apples, but a Fraser island apple, an unrelated species whose scientific name is before "M". I've learned to just type Malus in, but I know that the list is ordered alphabetically by scientific name.

• I watch a friend try to input a location of an elderberry, and he typed "elderflower". It was irrelevant and stopped matching after f, so he was confused and felt like he doesn't know plants - had to close the site, go to google, find the Latin name Sambucus nigra, and put that in.

This issue proposes preferring prefix matches over substring matches when there's a search term entered - easy change but should improve the experience.

[ezwelty]

I watch a friend try to input a location of an elderberry, and he typed "elderflower".

This is an interesting case, because "elderflower" is a synonym English name returned by the API. If we expanded the search to all common names (or at least those in the currently selected language), it would have worked as expected in this case, although also maybe confusing because the match would be "invisible".

@wbazant Thanks for these reports. I'm open to change but I'm not sure I understand what you are suggesting. If matches are only allowed from the start of the string, then searching for "elderberry" would fail to match "black elderberry". Are you suggesting sorting search results by (prefix match, substring match, pending type, original order)?

p.s. Random thought about sorting: The API /types endpoint could return a count of (user-added) locations per type as a way to sort the dropdown?

In the long run, I wonder if this search shouldn't be more like searching through type profiles, where search results are more like tiles (maybe a photo, the taxonomic rank, a link to the profile page, matching synonym names) and the option to view that profile page before making the final selection. But that's for another epic.