So it seems autocomplete prioritises firstly any exact names.
In this case, “Ac” is the common name for a plant in Huastec language.
Then it prioritises according to the taxon with the largest number of observations.
Byrsonima cacaophila has a common name of Aca in Portuguese, but not only is it from an entirely different kingdom, it has 0 observations globally!
Feature request details:
Could it not be a little more advanced and prioritise descendant ( or proximate ) taxa instead/as well somehow? Most of these suggestions are highly unlikely for me to be making in this instance as an identifier.
I think some sort of weighting or priority toward descendant taxa would significantly help streamline work for identifiers. It would also reduce the number of accidental IDs where an identifier adds an ID for something from another kingdom with a similar name.
I’ve thought about this as a solution, but I think that any changes to the way suggestions are sorted will lead to accidental mis-IDs. For instance, if the observation taxon is wrong, an IDer might very well be searching for a species that is in a different taxonomic group. These kinds of misclicks would be less-obviously misclicks and thus harder to catch and correct.
I’ve resorted to copying and pasting in cases where I must type in 5 or more letters before the correct option appears in the dropdown menu. For instance, many of the Misumenini crab spiders start with “Misume,” so my optimal workflow is to copy and paste the one species/genus name, simply skipping over observations that do not belong to that species, and then I go through the same dataset again pasting a different name. This specific example is more of a problem with annoying taxonomic naming conventions than with iNaturalist.
At the very least, it’d be nice to have the option to disable results for common names in other languages - if my account is set to English, it’s pretty unlikely that I’m searching by the Portuguese common name.
Is there a list for the autocomplete that works from a single letter?
For me L for Lepidoptera is useful.
I toggle between scientific names and common names in English or Afrikaans to find the shortest clicks to autocomplete for the same old same old.
(Plant genus Crassula is hidden at the bottom of a list which always starts with seashells - no - this is a flower / plant)
I agree. I do see the benefits of @sbushes’s suggestion, but the flip side is that it would mean that autocomplete would work differently depending on previous IDs for a particular observation. So, an identifier who gets used to a desired taxon corresponding to a particular sequence of letters will now find that different taxa may appear at the top of the list from one observation to the next.
That’s a good point. I think there is a balance here in terms of how much weight is given to number of obs of a particular taxon vs proximity to the current ID. I could imagine too much weighting towards proximity might well be problematic for the reason you mention. But it’s at the other end of the spectrum atm to ignore proximity completely…
I guess in an ideal world ( ignoring computational complexity for any of the options )… I would just want to lock autosuggests at a particular point. For me, I just work in winged insects.
Really, I just want to lock out the non-winged-insects autocompletes, and prioritise anything within my order. So perhaps another solution (theoretically)…would just be to choose to identify within an iconic taxon.
Even more ideal though would be yes - for the autocomplete to log your most commonly used options and prioritise them. That would solve everything for me!
It doesn’t sound wholly complex to me to take the top 20 most identified taxa for an identifier and give them extra weighting within the autocomplete.
I want a homonym filter.
Yesterday Lessertia - took me a few ID notifications rolling in to notice, planty person had chosen a spider. Plant identifiers all saw what they expected to
I like the IDea, but I agree with @rupertclayton that I think implementing this suggestion might cause issues because ID suggestion behavior would become unstable/unpredictable. I think the most important thing is for users (in this case, IDers specifically) to be certain what they are going to get when they type in certain sets of keystrokes, and having the result be context dependent is likely to lead to both errors and frustrations.
In cases of concentrating IDing on a fairly defined set (say <25 taxa), I think just memorizing the shortest entry that gives a species works best. Most of my IDing is within a genus, and I have the keystrokes down at this point. I wouldn’t want that to change based on whether the original IDer entered a more specific ID (Anolis, the genus) or a broader ID (Lizards). Having to examine the current ID each time or double check each of my entries would be much more effort/time consuming. And don’t get me started on how it can be hard to tell what the CID is at times if this is what the suggestions would be based off!
Of the other suggestions above, I do think that giving the option to prioritize autocomplete suggestions to some version of names in a given language or scientific names or some combination could help. This would still give consistency but would reduce some of the more egregious non-relevant results.
One way to address the original issue that I probably should have suggested earlier is to use some kind of autocomplete app. This allows you to type a brief keystroke sequence and have it automatically expand to a much longer text string.
For example, I use TextExpander and have lots of shortcuts set, such as “;dcc”, which expands to “Dipterostemon capitatus capitatus”. There are several other similar apps, and I think some operating systems may offer this functionality built-in.
Pro tip: These apps typically still need to identify the start of the shortcut keystrokes and can get confused at the start of a field, so I find that when you enter the Species Name field I need to hit the right arrow before typing my shortcut.
