There is much discussion (linked below) about the pros and cons of the Agree buttons in various parts of the iNaturalist interface. Please don’t rehash any of that here – visit the related linked topics instead.
Instead I want to suggest a set of related solutions to the issues, which to me boil down to
People often misunderstand the expected usage of the Agree button, and
Agree buttons are highly available (good up to a point), but sometimes with too little context to promote and support the expected usage, and with too much potential for redundant IDs coming from different parts of the interface.
Prompt a user who tries to add rapid serial IDs to the same observation. What is rapid? I suggest within 60 seconds of their previous ID, but that’s up for debate. Prompt? Something like: You just identified this observation as [Taxon name 1]. Are you sure you want to change your identification to [Taxon name 2]? (Yes / No)
Delete instead of Withdraw very recent ID by same user on same observation when they add a new ID. How recent? I suggest a little longer than the time above for rapid serial IDs, maybe 2 or 5 minutes. The assumption would be that serial IDs happening this fast are most likely inadvertent mistakes that the user would want to delete anyway, not based on new research by the user, and would needlessly clutter up the ID history. EDIT: still Withdraw instead of Delete if there is an ID comment associated with the previous ID.
Rename Agree to something that better promotes the expected usage (already recommended in responses to some other posts). This is the hard part – finding an alternative that still fits readably on a small button. And also something not subject to unintended nuances of meaning when translated into other languages (which I suspect might be affecting current usage of the Agree button to some extent). Some initial thoughts: "Make my ID" "Add this ID" "I Confirm" "Confirm ID?"
There are gaps in some of the above solutions taken in isolation, but together as a package, I think they would eliminate a lot of existing issues with Agree buttons (and ID workflow in general).
One point though, there have been times when I have ID’d as genus, and then put species… the intention being to suggest it needs close scrutiny. I mention it in the comments usually, but I think seeing the genus level IDs regularly enough for that taxon “subliminally reinforces” the need to consider the genus level ID as a choice.
This is an excellent summary and synthesis of previously disconnected ideas. I was able to remove several votes on other feature requests to free up enough to add one to this feature request.
@jdmore - Jim, minor quibble / note. Point 2 says ‘prevent duplicate observations’. Based on what you link to, I assume you mean ‘prevent duplicate identifications’ ?
Preventing duplicate observations seems outside the scope of this discussion.
Oops, yes, thank you, I fixed it in the initial post.
This reminds me of something I meant to include in #4, and now will: still Withdraw instead of Delete if there is an ID comment associated with the previous ID. Otherwise I’ll stay neutral on your usage – it is certainly supported by existing functionality.
Yeah, that one really wouldn’t be relevant, since as @cmcheatle corrected me, it has to do with preventing duplicate observations, not duplicate IDs.
Addendum: names I considered but rejected for the Agree button (#5):
“Confirmed”
“Accurate”
To me these would still be too vague, and still invite usage on any/all matching IDs that come in at different ranks, like genus or family IDs matching (but not necessarily agreeing with) a species suggestion.
I wonder if access to the agree buttons could be an account setting, off by default. When turning on access to the agree button, a thorough description of what it is and how it should be used would be presented to the account holder, perhaps even with multi choice questions at the end of it to ensure they read and didn’t just “OK” past them… Would count as on-boarding and also not limit use to those that know how to use it appropriately. Implementation could even have us ALL having to go in and turn it back on, which might educate a few of those that have been mis-using it. Perhaps a direct message out to all users explaining why it is missing and how to get it back.
If off-topic to the feature request, feel free to move to appropriate place…
I agree with the Thanks button… and wanted to vote for it on other feature requests, but they’ve all been closed. So adding in support for it here!
I think adding a Thanks button would help limit comment traffic to identifiers from people who just want to say thanks ( they wouldnt need to open the notification to view comment)…
It might also help limit people just agreeing to ID as a way of saying thanks without realising the impact of their action ( as mentioned on another thread ).
I realised in helping my mum use iNaturalist for the first time that one of the main issues for her was not seeing or understanding the use of “withdraw” when she made an initial ID in a different taxonomic group to that which the community suggested. She couldn’t see a way to do this …and didn’t appear to understand the need… or indeed how to navigate to the menu to resolve. I ended up suggesting she just blind agree to resolve, which isn’t ideal.
So, my vote is simply for CONFIRM
But I think there should be a second button to prevent users using confirm as a workaround when they need to withdraw but don’t know how or understand why. This could be
ACCEPT
for example.
In use cases without taxonomic disagreement, it could also act as a sort of placebo for those who just want to click something to acknowledge the identifiers suggestion or give thanks - preventing another one of the ways the Agree button is currently being misused. This could potentially be a source of confusion however, without a connected visual impact, so maybe it should also exchange their existing ID for the community suggestion, but without impacting the “Needs ID” / RG. This “soft ID” could be in a different colour, or higher transparency to visually indicate the lack of weight it carries. Alternatively it could simply be noted somehow, more minimally, that the ID was “accepted by OP with thanks!”
Note - this is similar to @tallastro’s suggestion for MY ID … but I think, important to delineate clearly between acceptance and confirmation.
I vote for renaming Agree to Confirm ID because it suggests more strongly an independent and thoughtful opinion.
But I’m skeptical that any interface changes will help (too) much. Most users seem to not be aware of the great biodiversity out there and they will agree with any ID that somewhat resembles their observation. The problem boils down to allowing unknowledgeable and uninvolved users to make decisions that require knowledge or involvement (like checking literature, keys, distribution).
Then I am … unknowledgeable. No literature or keys available. Many, most? of us are not professional scientists.
But I would prefer an obs to need 3 IDs before going to research grade.
“Then I am … unknowledgeable”? I haven’t defined “unknowledgeable” so that you can make such an inference from what I’ve said. The " checking literature, keys…" part was about involvement.
If you both don’t have any knowledge about a taxon (you are unknowledgeable) AND you don’t consult written knowledge like literature, keys, etc. about that taxon (i.e. you are uninvolved), then your ID about that taxon can’t possibly have any value. Many users are just like that.
Obviously there’re degrees to knowledgeability and involvement but discussing this in detail would get too off topic.
What do we gain, other than saving a few seconds of typing, by having an ‘Agree’ button at all?
What do we sacrifice, in terms of data quality, by having an ‘Agree’ button that many users seem to misunderstand or can’t help clicking on, even when they have no idea what the ID of the observation should be?
When iNat experimented with removing the button there were a lot of complaints. In summary, a few seconds times several hundred or thousands of IDs is a big deal.
Personally I think it should be a hidden opt-in feature. Keep the code, but you have to go into user settings to turn it on. That way major identifiers can still use it but new users won’t be tempted by that bright green button.
Just to clarify… good reason to do this on a single observation? (Like, multiple IDs within a few seconds of each other, by the same identifier, on the same observation?) I’d be interested in knowing more about those reasons. I agree that an identifier needs to be able to move rapidly through a series of separate observations during the ID process, but I can’t think of why I would ever want to rapidly add multiple IDs to a single observation, unless a previous ID was a typo I’m trying to correct. I don’t think typos need to be preserved in the ID history.
Definitely agree here. Again, though, I’m talking about IDs within a few seconds of each other on the same observation by the same identifier, when the most likely explanation is that they are either trying to correct a typo / selection mistake, or are just hitting all of the available Agree buttons on that observation for the different IDs present (which I’ve seen happen a lot). In the latter case they are probably misunderstanding the Agree button as a “thank you” button, but if there is a good reason to allow that, I can be persuaded…
Fair enough. I guess I’m just not convinced that this rapid-fire momentary thought process is worth permanently documenting in the ID history. If I’m changing my mind a day later, or even a few minutes later, then I definitely leave the previous ID in the history, and explain what changed my mind. But for changes within a few seconds I tend to just delete my old ID, as I am still in the same thought process, and don’t feel the need to document my “thinking out loud” as a series of IDs. But maybe others do…