Problem is - the observer hasn’t done that. The identifier needs to
- See the placeholder.
- Copypasta in a comment - where it becomes the identifier’s responsibility to delete if necessary.
2 Likes
I have 2 issues around this with iNat.
Making the observer aware upfront (preferably by not having any placeholder) so they are forced to use Notes / Comments.
Making the subsequent indentifier aware, so they don’t unintentionally / accidentally delete the observer’s information.
It is broken at both ends. As an Unknown identifier addict I stumble over this frequently every day.
5 Likes
I agree with those 2 issues. I just don’t think changing the terminology to “temporary placeholder” actually addresses either issue.
2 Likes
If I don’t get anyone motivating for Placeholder.
I will ask iNat to, please make these glitches more user friendly for us.
It has been years since I used the app, but if I recall correctly, when you have no network connection (as when you’re deliberately offline to conserve battery and/or data, or are simply out of cell data network range) and have the app set to auto-upload when the network returns, then if you know the taxon and enter it at the time, it is uploaded as a Placeholder. I suspect some portion of them are for this reason and I would argue this constitutes a valid use case.
You might counter-argue: in that case, they ought to disable auto-upload and fix the IDs before uploading later. However, those are extra steps a person might prefer not to do on their phone. They might rather leave the placeholder and make a proper ID efficiently on their computer when they next review their uploads.
6 Likes
Thanks - for that valid workflow - the needed temporary placeholder - could be a Note. Or a new, dedicated and visible field - which identifiers can see regardless, and the observer can subsequently edit or delete. It’s the there but not there that makes for quiet chaos.
Maybe if the interface just doesn’t offer “Use … as placeholder” (only “Unknown” by default, and auto-complete from the taxonomy), the observer would have no choice but to use the “Notes” field?
4 Likes
That is a nice tidy option
Right now, sporadically offline users have a workflow where they don’t have to think about whether their phone is online or offline. They simply enter a name in a single field and if it offers to look it up for them, great, but if they are offline, they can still enter something useful for later. I can’t see people who rely on that being happy with being forced to do an extra step to put the name somewhere else. Nor do I think automatically entering it in the notes instead would be good UI, as it blurs the purpose of each input, possibly leading to errors in understanding and development of bad habits.
2 Likes
How many users are doing that? Can it be made different for offline use of the app?
1 Like
I honestly don’t know how many. I don’t have access to such statistics. I think the whole thread so far has been from the perspective that placeholders are a misfeature that needs to be eliminated vs. a good idea for users that unfortunately has a negative impact on the data and causes issues for the identifiers (and particularly the subset of identifiers who are concerned with cleaning up the data).
Anecdotally, there are a number of fairly competent “high output” observers in my local area that I see from time to time in my feed have a Placeholder with a perfectly valid taxon name that would’ve matched, had they had network connectivity at the time. It has been my assumption that those users were offline at the time and are taking advantage of this feature for good reasons.
4 Likes
Addressing your second question, I cited offline as one case I commonly see, but it’s not the only possible use case. A second would be online, entering whatever name you know a taxon by but it not matching, but still the placeholder provides a better starting point than no information at all. When you’re in the field and quickly entering observations, you may not catch typos, or have much time to think about correcting your mis-remembering a name, or consulting a taxonomic authority to find if the name you know a taxon by is valid. Just being able in those cases to enter a name is value provided by the placeholder that would be removed if the placeholder were eliminated. Therefore implementing some different behaviour but only for offline users is probably not desirable.
1 Like
If you’re a “data warrior” doing lots of cleanup work on the iNaturalist data (and by the way, if you fit this description, I applaud you!) you might encounter it frequently enough for it to seem like “most” placeholders are not intentional. But if you put more modest amounts of effort into making identifications, focusing instead mostly on observations, and are picky about what you put in your home page feed to review, it might flip the other way where most placeholders that you encounter are serving a useful purpose. I imagine it’s rather hard to assess what the actual numbers are and how much pain it actually causes vs. the benefit accrued by the users with legitimate use cases.
I think it’s more of a point to upload later than right in the field, I know some users are into the field online work, but then they maybe they can quickly google the correct latin/common name (but I also her that most of them turn off auto-upload, so for them it wouldn’t be hard to change the name when checking their “waiting for upload” later?) I never though before how many of placeholdres come from the app vs the website.
I honestly don’t remember meeting those, maybe you’re right and I’m just looking at wrong place, but statistically mistakes of new users are very common in all aspects of iNat, most users are new users, so those mistakes will be predominant unless a huge observer uploads 10k of placeholders, at least that’s how I see it.
1 Like
By the way, I don’t disagree with you here - the lack of searchability of placeholders certainly makes them less useful. Also the lack of understanding about the need to go back and clean up your data after you upload it is a problem (i.e. that it costs the rest of the community something to leave your own bad data unaddressed). So that’s partly a technical issue and partly social. I honestly don’t think adding the word “temporary” will change the social part of the problem. Making placeholder texts searchable, though, sounds like a good idea!
2 Likes
The problem is that the purpose of the placeholder input is already obscured (and used inappropriately in my opinion more often than it is used appropriately).
Consider this situation I’ve seen recently: A user added a placeholder “Buteo jamaicensis abieticola”. This subspecies is not recognized by iNaturalist. What I would suggeste, is that the observer ID the observation as Buteo jamaicensis with the desired subspecies designation in the ID comments. Because I can accurately ID that subspecies, that is exactly what I did. However, say I was confident in my ability to ID a Red-tailed Hawk, but I couldn’t confirm or deny it was the abieticola subspecies. If I just ID it as Red-tailed Hawk, the observer’s desire to indicate it was that specific subspecies is lost. This would not happen if we:
3 Likes
I agree with you here in general. When I was using the app while partially offline, deferring uploads is one of the first things I learned to do. My workflow with the app was: observe offline but with auto-uploads turned off, sometimes go online to check an id, but go offline again immediately to conserve data & battery. But that’s me. Others (e.g. certain of my family members) prefer to stay online constantly while they are out and really thrive on the immediate feedback that is given. It’s worth it to them to upload immediately. They may even be in communication with others about their observations as they go (e.g. on iNaturalist Discord). So just turning off auto-upload doesn’t fix this problem for everyone.
1 Like
I agree there are multiple problems with the placeholder implementation. I have seen this particular problem where the placeholder is “lost” too. (Well, not entirely lost, as it is retained in the record - but there’s no UI to see it again.) So I am with everyone on this thread who wants to see placeholders improved. My disagreement so far has only been with suggested specific approaches, and not that there are no problems to fix.
5 Likes
I wince with you at large, systematic breakage of data by new users with high output! We could all do with a lot less of that sort of thing. And placeholders can play into that problem. I don’t know … I’d love to see more attention given to limiting the damage caused by that kind of usage pattern. I would hope that such things could be addressed primarily by educating the user and having them change their behaviour. Failing that (though this is a desperate last measure to preserve an individual reviewer’s sanity), filtering out the data from specific users when it just causes too much anguish.
We hear that there will be more materials for new users for years, now I think iNat could ask someone from big users to write such documents for free if team doesn’t have enough time and funds to do that part. I accidentally say 1-star reviews of iNat app and it’s like every one of people there didn’t get a single thing about iNat and added comments like “I id it as what I saw and they disagreed!!!”.