Loss of observation species identification for new species

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) :

URLs (aka web addresses) of any relevant observations or pages: https://www.inaturalist.org/observations/105899874/

Also occurred for https://www.inaturalist.org/observations/105899831

Screenshots of what you are seeing (instructions for taking a screenshot on computers and mobile devices: https://www.take-a-screenshot.org/):

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.

2 Likes

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:

  1. Change DB/app/site to preserve and display original 'placeholder ID’
  2. 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

You can check already existing feature request about placeholders and vote there, but it’s not a bug.

3 Likes

You can check already existing feature request about placeholders and vote there

I searched and received many results.

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.

5 Likes

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.

2 Likes

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.

3 Likes

That’s probably because the EOL search for external names was removed, and now it only searches COL.

3 Likes

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”:

That’s not exactly helpful, I realize – but again may people have barked up that particular tree for a long time.

2 Likes

Yes, very surprising. I noted that above.

2 Likes

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.

1 Like

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.

3 Likes

If there is the leaf icon as you showed above, the name is not in the database, and if selected it will display as a placeholder.

2 Likes

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…

3 Likes

The About the Bug Reports category - please read before posting! topic defines a bug as:

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.

6 Likes