Make the Withdraw function visible as a button on the observation block (with a connected tool-tip)

[sbushes]

Turn the withdraw function into a visible button on the observation
(with a connected tooltip to explain its purpose).

As has been vocalised by many (especially on recent threads)… there is a well-known issue with OPs “blind agreeing” to IDs that are suggested. The major downside of this occurs when both OP and identifier have no, or limited, knowledge of taxa. Its impact is probably more pronounced in locations and taxa with limited identifiers.

POTENTIAL DAMAGE might include :-

• the accuracy of the iNaturalist dataset on GBIF
• the perception of the quality of the iNaturalist dataset by external entities
• corruption of the test data used by the CV model
• the amount of work identifiers have to do to fix incorrect RG obs
• as well as feedback loops resulting from this, which exaggerate all of the above

The exact reasons for this “blind agreement”, doubtless vary.
Some might have multiple reasons.

POSSIBLE REASONS may include:
A - as a form of thanks or acknowledgement
B - simply because there is only one button visible, and it offers the option to agree
C - ceding power, because the original ID is conflicting, and the withdraw button is not understood by newer users
D - to make an observation RG so it goes to GBIF
E - to take an observation out of the “Needs ID” pool and see it as somehow more resolved
F - to second and cement an ID if the identifier is a known specialist/ has a high ID count

For me, the core reasons I imagine, for any newer user, with limited knowledge of iNaturalist or perhaps even of recording nature at all, will be A, B and C. The other reasons seem more connected to users who are more experienced, and who actually choose this regardless of the downsides… arguably, not a completely “Blind” agreement.

POSSIBLE SOLUTIONS mentioned so far include:
1 - better on-boarding for newer users
2 - renaming the Agree button
3 - making the Withdraw button more visible
4 - giving more weight to IDs by users with experience / less weight to IDs by new users
5 - stripping the “Agree” button entirely
6 - limiting the ability of the OP to use an agree button

Of the possible solutions, I think 1, 2 and 3 are the least contentious and disruptive to the community with clearest benefit and lowest cost. They could all be enacted without any serious downside. In addition, 2 and 3 would be relatively quick to implement, I would imagine.

Number 1 is already being acted on.
Number 2 already has a connected feature request and debate.
This feature request is for number 3.

Of course, this alone will not solve all of the above cases, but it’s a simple change, with no real downside and some significant potential to help, I think.

NOTE!
Much of the above has involved lengthy discussions and been touched on in multiple other threads. For practical reasons, better to read the connected threads and respond in place, not here, I think, for risk of reiterating other arguments or muddying the water.
This is only about whether or not it might be helpful to have the withdraw button more visible.

[pisum]

with touch screens and fat fingers, my thought is that fewer buttons is better. so if this is implemented, i wonder if a button could be added only if there’s a disagreement?

[sbushes]

I’m confused - I am proposing a one click larger button, instead of the existing, triangle menu access to the Withdraw function, which requires smaller fingers and two clicks.

[pisum]

fewer buttons is better to prevent accidental clicks. mostly it would be accidentally clicking on something when swiping to scroll, but it could also just be holding the device the wrong way, or accidentally brushing the screen when doing something else. fewer buttons also occupy less screen space, especially when the buttons ideally should be large enough to accommodate touch.

[sbushes]

I see.
Is this already an issue with the Compare button for you then?

@pisum

fewer buttons is better to prevent accidental clicks

How about shifting the Compare function elsewhere then and having the Withdraw function in its place?

[sbushes]

( I think even if implemented only in case of a disagreement though…as you suggest…would also be really helpful )

[pisum]

i think it’s probably more beneficial to have the compare tool – something to help people make good identifications on the front end – easily visible and available, rather than a button to allow people to retract their IDs on the back end. i think it sends the wrong message to suggest that people should want to retract their IDs often enough to highlight that button more than something like compare. also, accidentally opening up the compare tool isn’t going to trigger any immediate actions.

(if you wanted to bury the agree button in the additional function menu, i’d be okay with that, though maybe i would roll something like that out in conjunction with a “like” type of button for comments and identifications.)

[teellbee]

FWIW, many users are using a limited-feature mobile app, with no option to withdraw an ID. Some one kindly commented I should consider doing such-and-such. I could see no way to do that on my phone app and wrote my puzzled query to iNatHelp. I know I was shocked - well, very surprised - when the (very prompt) reply said that functionality only existed on the website.

?!? There’s a website? With more features than the app?

Shoot, I was used to places like Yelp reducing access via the website in favor of to push users to their app! It never would have occurred to me to find more functionality on a web interface.

[sbushes]

On the web page version, as a user who has an incorrect autosuggest ID, I am confronted with the following … 3 x compare buttons, 1 x about button, and 2 x agree buttons.
But for you, not one of those 6 could be a withdraw button?
There is no way to make a visible withdraw option on the menu that would satisfy you?

Surely, if we are struggling with OPs over-agreeing…this is partly happening, because there are no other measures visible?

@pisum

i think it sends the wrong message to suggest that people should want to retract their IDs often enough to highlight that button more than something like compare.

I’m not completely sure what you mean by “the wrong message”.
Realistically, as older users, we all know, we have four options in the above instance.
Agree, Withdraw, Delete, or add a New ID.

Its like…

Lets play a game!
I’m not going to tell you how to go backwards or sideways.
So, I will hide that. Its top secret!
BUT, I will tell you how to go forwards.
I will give you lots of options on how to go forwards.

Meanwhile…in a galaxy far away… a crowd of experienced players watch you play the game on an intergalactic television station…but they are aghast!…
Why are these new players just going forwards?!!!
So weird!
What could have possibly caused it???

Making these options clearly visible just helps explain their choices.
Withdrawing is fundamental to using iNaturalist, in its current form. No?

Having said that! And intergalactic space adventures aside…
Even better, in my opinion, would be to rename it perhaps…

@pisum

i think it’s probably more beneficial to have the compare tool – something to help people make good identifications on the front end

This is maybe specific to my current taxa of interest… but Compare must be very unhelpful I think, to users inexperienced in Diptera… I certainly wouldn’t want anyone to use it to make “good” identifications. The opposite, in fact - I’d rather it wasn’t implied that you can make an ID just through visual similarity. This could even be another root cause of the problem. So for me, this just reinforces the reason to not have 3 big juicy buttons encouraging it…

@pisum

(if you wanted to bury the agree button in the additional function menu, i’d be okay with that, though maybe i would roll something like that out in conjunction with a “like” type of button for comments and identifications.)

I am also all for burying the agree button for the OP only. I really like this option now, on reflection.
But this would most likely lead to a painful increase in obs stuck with a maverick ID…without a withdraw button!

@pisum

i would roll something like that out in conjunction with a “like” type of button for comments and identifications.

Regardless of Agree and Withdraw, I also agree that a Thanks button, would be another reallllly helpful and much needed intervention

[sbushes]

that explains why my mum can’t find it!
haha… I thought she was just having an elderly moment

wow.
well, thats certainly gonna add to the blind agreements even more then…

[pisum]

@teellbee

that functionality only existed on the website

it actually exists on the Android app. not sure about iOS.

[teellbee]

Hmmm… on iOS, not one that seems obvious . Here is the Main screen and Edit screen :

[sbushes]

Interesting.
This is really different in design to the web interface.
With the weighting much heavier on the “Suggest an ID”

I wonder if the blind agreements are happening more with phone users or web users.
For me, if you removed the agree option there, I wouldn’t suggest a further ID.
I’m not sure I would even click agree as it is…there’s less incentive somehow.

I think these cases should be spoken about separately then, as this is really different, I didn’t realise.

For phones, I think perhaps I agree more with @pisum then, I see what you mean - better to only add withdraw if the ID is maverick perhaps. Unnecessary clutter. …and remove the Agree option for OP.

Website…a different matter though…

[sgene]

@pisum

i think it sends the wrong message to suggest that people should want to retract their IDs often enough to highlight that button more than something like compare

This is the opposite of how I’ve been viewing it. If I felt certain when I made an ID and then someone makes a subsequent ID that makes me uncertain of mine, I am not suddenly certain of the subsequent ID so that I want to agree with it. Instead, I want to get my ID out of the way so that the second ID can be found easily and considered. I certainly don’t want to compound my uncertainties at that point by choosing a third possibility from Compare that I know nothing about. It seems to me that iNat should be encouraging newcomers especially to become aware of the limits of their current knowledge and be able to choose accordingly. I’m just surprised, and curious, because I never saw any downside to withdrawal expressed before.

[jdmore]

I think it would be a helpful convenience and reminder to have the Withdraw option more visible as a button on one’s own ID, so I added my vote.

@sbushes

with a connected tooltip

Do you have any suggestions for what this tooltip should say? Maybe something like, “Cancel this identification”?

@sbushes

there is a well-known issue with OPs “blind agreeing” to IDs that are suggested

Though I realize your request is only for the Withdraw button, it seems to be motivated by the blind-agree issue, so I have to wonder, would a tooltip for the Agree button help as much or even more? I think it would solve a lot of misunderstanding about the intent of the Agree button if a tooltip immediately popped up that said, “Identify this observation as [Taxon name]” (with the Taxon name being whatever they would be agreeing with). That would leave no ambiguity that the button would be adding an ID, and not just thanking or acknowledging the previous identifier.

[sbushes]

@jdmore

Do you have any suggestions for what this tooltip should say? Maybe something like, “Cancel this identification”?

Yes, sounds good!

Not sure if its too much for a tool-tip, but it could also say something like this as well
" use this if your existing ID is conflicting with the community ID "
" let community ID take precedence if yours is conflicting"
" submit to community ID"
" accept community ID"

I think it could be worth explaining this bigger need for it more clearly…to cede power…( when trying to explain it to my mum, I’m not sure she got it ). But maybe that can be fixed more through on-boarding …or there’s another way to show this…a click for more info kind of thing. I think many newer users simply don’t even realise how taxonomy works which is one of the problems at stake here.

@jdmore

I have to wonder, would a tooltip for the Agree button help as much or even more?

Couldn’t hurt in my book! Anything that gives the user more information about this decision is a plus I reckon. I liked the word “Confirm” used in your other thread. Maybe
“Confirm this observation as [Taxon name]” ?
I think ideally Agree would just be renamed though in any case.
Would be good to hear an update on this aspect of that feature request from staff.

Realised there’s also a solution 7 to add to the above…
Another option which newer users don’t realise… which is connected to all this …is the option to place at a higher taxonomic rank… to agree to the shared rank. So also wondering how that could be added as a function? Perhaps if instead of removing the Agree button entirely, as @pisum mentioned, it could be that the Agree button is simply set to go to shared rank by default for OP.

[jdmore]

@sbushes

Not sure if its too much for a tool-tip, but it could also say something like this as well
" use this if your existing ID is conflicting with the community ID "
" let community ID take precedence if yours is conflicting"
" submit to community ID"
" accept community ID"

Yeah, I think a tool-tip should help clarify what the action will do, but not get into possible reasons or motivations for taking that action, especially when there can be so many. And I would want to avoid implying that withdrawal “should” or “must” happen in particular circumstances - it’s always optional.

Another complication is when withdrawal would change the current community ID. So I would want something like “accept community ID” to also say what specific taxon would be accepted if the withdrawal proceeds.

[sgene]

@jdmore

And I would want to avoid implying that withdrawal “should” or “must” happen in particular circumstances - it’s always optional.

There is another topic https://forum.inaturalist.org/t/general-consesus-on-being-asked-to-fix-ones-id/14609/73 where the issue of one person asking another to withdraw their ID has been raised, so if it is always optional maybe that should be explicit on the tool-tip?

[sbushes]

Isn’t the fact its optional implied just by the nature of having a button to choose to press or not?
I’m not sure. Another option though, would be that once withdrawn, the Restore option would take its place, to visibly show that you can return to original ID.

In any case, I agree simplicity is important. Perhaps less is more here.
These more complex aspects could just be better explained elsewhere within the interface…and/or with better onboarding.

Sometimes I withdraw (or agree, or add ID) to understand impact to observation ID.
As its not always clear. I think most users might play around with these things and figure them out…
( if more visible in the first place )

[jdmore]

@sbushes

Isn’t the fact its optional implied just by the nature of having a button to choose to press or not?

Without any tool-tip, yes. But a tool-tip saying something like

@sbushes

" use this if your existing ID is conflicting with the community ID "

might suggest otherwise, especially to less experienced users. Also, on another random thought,

@sbushes

I liked the word “Confirm” used in your other thread.

I’m actually not a big fan of that option. People who do a lot of identifying generally understand what “confirm” means. But those who don’t (and who are the ones we are most trying to target for clarifying what “agree” means) may just interpret that as another way to acknowledge/thank an identifier, without more explanation. FWIW.