I don’t want to diss writing better documents. I believe they are needed. But when talking about large groups of people, a principle to keep in mind is “people don’t read”. That is to say, the more obvious you can make your software without people having to read, the more likely you are to help larger numbers of people use it more effectively than by writing better documentation alone.
When I find features of my Discord bot code that my users are having a hard time using properly, or aren’t even aware exist, I almost never think “this is because my documentation is poor”. Some of those issues are expensive to fix and, as much as I’d love to fix those flaws, they go on a list to deal with “later” while I work on more pressing issues. That’s where having a good community around the software really helps. If someone struggles with using the bot, they can almost always find someone else who is slightly better with it than they are to help them out …
But that’s on a fundamentally social platform, Discord. This platform is all about community. The unique situation iNaturalist finds itself in is that while it is a social platform with a great community around it, not everyone is there for social reasons! Honestly, I feel a lot of those would be better off with Seek. But what can we do? Yes, we’ll get some 1-star reviews from people who don’t “get” us, but I doubt if poor documentation is the cause of that.
Just as a sidebar, I have been able to recover a lost placeholder. When I notice there is a placeholder fractions of seconds before I go ahead and press enter for my ID of something general like dicot but my reflex to to press enter was too fast…I can delete my entry and the placeholder returns so that if the history of it is useful, I can copy it into comments…or I have time to look up a possible mis-spelling or translation or old vs new taxon name on GBIF or WORMS.
I do feel your pain however about the main issue in this thread.
A way to get placeholders back that covers many situations (where the placeholder is gone because someone other than the observer added an ID) is to append .json to the observation URL and look for species_guess in the data. So long as the owner of the observation has not superseded the placeholder with an ID of their own, this should still contain the original placeholder text, even if the web page for the observation does not have the text anywhere on it.
On the other hand, if you are removing a placeholder for your own observation it is, as you say, only something you can prevent by catching yourself and removing the ID before you submit it. Once you’ve given it a new ID, that’s it: in my experiments, I couldn’t find the placeholder text anywhere in the data after that.
Funny that, I was able to recover from other user’s Obs I was IDing for when I deleted my entry from the edit mode if it was before someone else interacted.
I’ve never understood what placeholder does that the description box can’t. I definitely try to copy paste any placeholders I see if I do ID something, I’m sure I do 95%+ of the time but it feel like it’s a bit of a minefield where I might step on something accidentally.
Thanks, I didn’t think of such a case – probably because I only use the web interface for uploading observations. But if there is no connection to the server, the logic of the application should change significantly anyway. Obviously, CV suggestions, automatic geotagging and other functions that require downloading data from the network will not be available. Even the taxonomy is unlikely to be stored and updated locally by the application so that auto-completion would work (I don’t know exactly, but I doubt it’s reasonable). In each of these cases, some sort of feature replacement will probably be required so that the user can continue to work offline.
Well, this just shows that in any large infrastructure, any change can have varied effects, requires design and testing. And, of course, has its cost. Placeholders don’t seem like a significant issue to me. It just seems redundant in my user experience. This may not be the case for someone else. Even changing habits in some sense is also changing personal infrastructure. And not everyone is willing to accept that easily.
Yeah, that’s fine if it was their own placeholder and they didn’t id. What I observed in my tests is that if I made a placeholder on my own observation and subsequently added an ID, deleting the ID does not recover the original placeholder. It’s entirely gone from the record at that point.
would be even more irritated if someone adds a broad ID, before they can get to it. And their careful and meaningful placeholder has.
Disappeared.
Useful for later? Not.
When I talk about flagging for missing species - that is the useful data that I am concerned about iNat automagically disappearing it. It is the disappearing act I object to - not the useful data that I am fighting to keep visible and usable. Your offline till later usage would also apply to my African observers probably.
Especially if while staying at some offgrid cabin, in a country new to you and you carefully find your observation in an antiquated flower guide you found in the stack of assorted magazines from the 80s and scrabble dictionaries. You add that ID to upload later when you return home to only find out @bobmcd just IDed it as dicot…or worse, plant.
Actually. What we need is a dedicated place for an observer to make private notes on each obs. And then for iNat to automagically (so it doesn’t affect current workflow) move what disappears as ‘placeholder’ to Note to Self.
I’ve been bitten by this situation. Changed my workflow. No automatic upload from the app. I check records over at home on my wifi where fields will fill in correctly. And I use the notes field. (Still have a record sitting with a weird ID since the first IDer ignored the placeholder “Leaf miner” and IDed the plant.)
I second moving placeholder info to the Notes field if IDed by someone other than the observer.
Is that a problem with the advice or a problem with expectations? If I was on a platform where I knew that newbies were uploading taxa they didn’t know, where would I get an expectation to be able to filter for family?
Considering that Google can “guess” the meaning of a misspelled word – for example, if you type in “bulet train,” it will ask, “Did you mean bullet train?” – probably half of the placeholders I see wouldn’t be placeholders if iNat had similar functionality.
It’s kinda ironic that the regular search on iNat idnores your mistakes and not even mistakes (e.g. you write a word one way but it still shows you project names with different version of the word) and place search (on taxon page) also allows mistakes in writing places.
Different strategies for matching taxon names are supported by the site, and it seems to me there are good reasons why they just don’t all behave the same way.
Many places on the site that implement taxa name searches use autocomplete so you can see potential matches as you type. The goal for this kind of search is to match a small number of records to whatever the user has typed exactly so far, and sorted so the more likely matches are shown first. These searches need to be less costly for the server to perform as they happen very frequently (i.e. each time a user pauses typing).
By contrast, the “site search” method searches an index that is more forgiving of mistakes via a “fuzzy matching” algorithm but produces a large number of results. These searches can afford to be more costly for the server to perform because they come in at a much slower rate.
So those two basic approaches run contrary to each other in both their purpose and cost to compute. I don’t think it would be easy to merge the two due to different desired server performance characteristics alone.
Additionally, there’s a good reason as a user you might not want a “fuzzy match” to show up in your autocomplete results that has nothing to do with performance: precise matches are better than bad guesses! That is, if you know exactly what you want, and type it correctly, but it is an obscure taxon, the fuzzy match algorithm might conclude that there’s a better match for what you’ve typed because a far more commonly observed thing that differs by one character matches, so will rank it higher than the one you wanted. I don’t know about you, but I’d lose patience with that rather quickly, especially if it means the bad fuzzy matches push what I want right off the short list so I don’t see it!
See, I just don’t know how it would do that without requiring unreasonably more computing power and/or making it a worse user experience in some cases.
I clunk in with - observer decides, they want leaf miner. Then I tag in someone to help. Or, you know, 2 someones to tip the CID if the weird interests me enough. Often get a prompt response (even apologies … but they will remember to check first next time. All good)
I hop over to Google to work out why a placeholder binomial doesn’t show up on iNat. But my bigger concern is that identifiers don’t even realise that they have helpfully disappeared the observer’s field notes.
I have a problem with the advice and its unrealistic expectations.
iNat has 420K (honest) Unknowns.
Greenwashed, out of sight, in a different box with the Plantae label, another 670K equally Unknown wait in limbo. I’m weeding thru my corner. Might look at Western Cape when I have cleared the Peninsula.
That’s about a million obs … altogether.
Filter for family is what the specialist botanists do. Not ever going to be part of my skillset.