Please fill out the following sections to the best of your ability, it will help us investigate bugs if we have this information at the outset. Screenshots are especially helpful, so please provide those if you can.
Platform (Android, iOS, Website): Android
App version number, if a mobile app issue (shown under Settings or About): 1.20.25 (456)
Browser, if a website issue (Firefox, Chrome, etc) :
Description of problem (please provide a set of steps we can use to replicate the issue, and make as many as you need.):
Step 1: Have a clear ID from a label placed by a professional botanist.
Step 2: Species is unknown to iNat.
Step 3: Species is entered in to Android app.
Step 4: User selects the âfull leafâ option (see last option in screenshot) to preserve their input.
Step 5: After upload, species information is lost.
According to https://www.inaturalist.org/pages/help#names it should be possible to âsearch external name providersâ and then select an entry. I have had success doing this post-facto on the computer but in some cases nothing appears on android. In these cases, information entered by the user and saved with the observation appears to be lost.
External name providers cannot always provide the name youâre looking for. It almost never works for me anymore. Are you saying that for a given name, external providers find it on desktop but not Android?
What is lost? If you mean the placeholder entered by the user, then that will be superseded by any ID that is suggested.
External name providers cannot always provide the name youâre looking for.
Yes I would assume this behavior.
It almost never works for me anymore.
Me neither.
Are you saying that for a given name, external providers find it on desktop but not Android?
I am not sure.
What is lost? If you mean the placeholder entered by the user, then that will be superseded by any ID that is suggested.
This is the problem.
User view:
I am entering highly trusted information - species name provided by a botanist - and I am entering it correctly.
I do not want to have to go back and find this information and enter it again, for example on another platform.
Nowhere does it say âwe will treat this as a placeholder and supersede itâ.
Someone suggests anything, no matter how vague, as untrusted information.
The platform apparently deletes the originally specified, trusted information entirely as it is no longer visible.
Conclusion:
Superseding behavior is wrong.
Possible fixes:
Change DB/app/site to preserve and display original âplaceholder IDâ
Improve app/site user interface to clarify âplaceholder IDâ related superseding behavior at the time of entry and clarify for each use whether the displayed information is a placeholder or not
Analysis:
Option 1 appears to be the neatest resolution as it guarantees no information is lost and does not place needless cognitive load on the user
Option 2 appears to be a poor solution as it relies upon the potentially non software literate user learning about the difference between two different algorithmic treatments of the same information and two different representations throughout the iNat interfaces which essentially represents needless complexity for that user
It seems many people are finding issues with the current implementation.
itâs not a bug
I disagree. Fundamentally, if a user enters information in to iNat they expect it to be preserved. This is the basic trust that users have in the platform. If it is lost, this erodes user trust in the platform which will reduce user time and data investment and is therefore a bug, even if it is the currently or previously designed behavior.
i guess you can disagree, but iâm not sure thatâs going to change the fact that iNat staff have already decided to make no changes related to placeholder retention.
iâm not sure thatâs going to change the fact that iNat staff have already decided to make no changes related to placeholder retention.
That quote, with whose context I am not familiar, seems to claim that the species name originally entered by the user (what you term âplaceholderâ) is not retained by the platform. And indeed, that was precisely my understanding when posting this bug.
However, a related thread, it seems that placeholders are retained. However, they are not displayed. This is, in my opinion, completely nonsensical.
Rationale: Good science is about open collaboration and open process. Itâs OK to make mistakes and get things wrong, however we should be able to see the evolution or opinion of participants and consensus over time. This creates trust. A major part of the value add of open collaboration platforms such as Wikipedia, iNaturalist, and so on is that smaller, more iterative steps can be made toward a common goal. Frankly, maintaining an arbitrary distinction between an initial âplaceholderâ identification and any subsequent identifications strikes me as somewhat arbitrary and smells more like an artifact of historic systems architecture than a feature derived of scientific need.
For example, for the two observations referenced, apparently the original correct, trusted, species name is allegedly preserved in their relevant hidden JSON files here and here as the species_guess field.
After all is said and done, then, my opinion of this issue remains unchanged:
The claim the current system âis not a bugâ is irrelevant to users, who remain confused and frustrated
The current interface frustrates users by hiding data they have entered even though it is preserved
This needlessly erodes trust in the platform
The quickest fix is to preserve and display the information, as per my original suggestion. Apparently, the information is already preserved, so it only needs to be displayed.
You always can add comment or write it in the description if you see the taxon isnât being added.
That may very well be true, however the user does not know and is not shown which fields will be respected and which will not. Therefore they are not going to know they should duplicate information across multiple fields. Most users will therefore not do so.
So, while there is a technical ability to preserve the information in another field, it should be fair to say that:
The user interface does not prompt them to do so
Educating the user costs time and adds complexity and needless cognitive load
We can see that the user expectation seems to be (as multiple threads on the forum have shown) that their species name is preserved. By default they have no knowledge of what a so-called âplaceholderâ is or related algorithms for display, preservation and so forth.
default user behavior coming from other software applications and platforms is unlikely to be to spend energy duplicating information across fields
Duplicating information across multiple fields is not generally considered good database behavior
As per the analysis above, educating the user as to these labour-intensive and clunky workarounds is one option, but simply displaying the information seems the better and faster fix.
The source/authority of the ID being proposed shouldnât matter when discussing how placeholders are treated. The scenario above noted that the ID was
However, the system has no way to distinguish between correct/incorrect placeholder IDs - all will need to be treated the same.
On a side note, in general iNat users shouldnât submit identifications based on someone elseâs authority or perceived (even if correct) expertise. iNat identifications should be a representation of the identifierâs own expertise, not that of someone else that they are trusting and giving a proxy identification for.
If the identifier can concur with the expertâs ID based on their own expertise, that is great. However, if the identification is only being added because of that other expertâs knowledge (ie, that of someone who is not on iNat) then this isnât ideal.
Providing an initial ID may be more open to the source of the ID than a confirming ID - however it means that the source of the expertise for the ID really doesnât matter for this example. The system (however it works) will need to work for all use cases of placeholder IDs.
I agree that the way placeholders are treated is not optimal, but also have to recognize that the topic has been discussed over many years with no sign at all that it will change.
So this is just to point out to you that the placeholder is not lost. If all actual IDs on an observation were to be deleted, the placeholder would reappear. You can convince yourself that it exists by appending â.jsonâ to the URL of the observation and looking for the field âspecies_guessâ:
This line of reasoning is completely correct. However, the logical corollary is that a âplaceholder IDâ and other IDs should not be segregated either, ie. the very notion of a âplaceholder IDâ is mistaken.
iNat could simply not have any placeholders at all, placeholder canât be not segregated from normal ids as itâs not connected to iNat taxa database, thus isnât really an id, itâd be much better if staff agreed on not removing them after new id is added, but if they said they wonât do that itâs likely wonât ever change, thereâre quite many useful requests that were closed for that reason. It also should be noted using computer would be easier for you as you say you didnât have that problem there, it also saves a lot of time on uploading and checking metadata, so even though itâs not a problem solution, you can try that.
To be a valid ID, the taxon has to be represented in iNaturalistâs taxonomy. Something identified as a âtreeâ doesnât, and neither does an actual taxon with a typo. If you go away from the requirement to match something in the âofficialâ iNat taxonomy then a lot of functionality falls apart.
I donât think we have to abolish the idea of placeholders in order to manage them in a more sensible way, such as simply not hiding them after other IDs have been added.
I agree. Those names which cannot be found on Inat can be simply noted in comments or in description of a broader ID, then possibly also by flagging the boroader taxa to request curators to add the species. It might be harder to do this on mobile thoughâŚ
By âbugâ we mean that something is not working the way it is intended to.
What you reported here is how the software is intended to work, thus itâs not a bug - thatâs what people are trying to tell you. If you think the software should work differently, then the correct course of action is to make a feature request or comment on an existing one that addresses the issue.
Since this isnât a bug, Iâm going to close this bug report.
