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

Perhaps. Equally, I don’t think it will do any harm though, it would just add further clarity to the UI.

But yes, for me… the main issue to tackle is expressed by a new user on another thread in response to someone asking why she hadn’t used withdraw.

I think this solution would probably help to tackle these instances.
Though maybe it should only appear in case of disagreement, as @pisum suggests.

I think many may still blindly agree afterwards still… even having used a withdraw button. So, I also concur with those who think that the agree button should be invisible to OP - to force them to have to add ID manually (but only on the provision a withdraw button is made visible, to prevent unnecessary disagreements from languishing and thereby adding work to identifiers to overpower).

Confirm and agree are near synonyms to me in the context of IDs. I’d find it pretty confusing.

1 Like

Mention of the use of confirm was with regard to it as a replacement to agree, as discussed on this thread. Not suggesting having both options.
…Or am I misunderstanding your comment?

Ah yeah this made it sound like 2 buttons. Accept, agree, confirm all seem too similar to me.

1 Like

Oh no…I hope this never happens. I would have to stop using iNat if the website became obsolete and I was pushed to app. Not only do I use a throw away phone with little memory, but my images are all made on my Nikon - if I had to rely on my phone’s camera, I may as well use my son’s early 2000s-era Fisher-Price camera…plus, my phone doesn’t have enough memory to download the app.

I surely will not upgrade my phone; I am reclusive and anti-social to a fault. Who needs a phone? :blush:


Ahh ok! Yes, I do ultimately think we need two buttons.
For me, I think Agree should be replaced with Confirm.
And I think Withdraw could also be replaced with something else. E.g. Accept.

I guess, to some extent, I also feel withdraw to have some sort of a “negative” connotation, similar to the comment by @pisum above. I think this is highlighted also by the notion mentioned by @catttailsandcobwebs of wanting “to fix” an ID.

I think [EDIT] people want to feel they have resolved their ID. So the issue is how to provide this sense of resolution without only offering the option of Agree.

If the visible options to resolve were Accept and Confirm, I thought people might discern the difference. But admittedly, maybe too slight. Perhaps tool-tips could aid this as well though?

Or yes,
Button one = Agree/Confirm.
Button two = Something else.
What might be an alternative to Withdraw or Accept for button two?

While I am only an observer and not a power user/IDers, I agree with @bouteloua about the similarities.

I think (and this is an emotional response) new users see the strikethrough associated with either a Withdrawal or an Agree(ment) as wrong.

Psychologically, I can imagine users feeling as if they’ve made an error and it has been corrected. Like red ink scrawled all over their research papers. And now everyone in class sees that error – whereas, if the research paper is handed back to you at your desk and only you see the low grade and red ink, it’s not so embarrassing.

I wonder if something like a Revise button would make users more apt to seriously look at the error and revise their initial ID, especially if the strikethrough then resulted in a message clarifying revision of their thought process (this applies more to those willing to learn about & revise, not so much the people who flippantly upload a spider just to find out if it will bite them while they sleep).

Note: I confess, I am a K-12 educator…so maybe I’m considering the psychology of learning. Feel free to disregard this input if it does not further the conversation.


to be clear, i would imagine that you would only ever have a single withdraw button on a given observation, and such a button would occur only on an active ID that you made. on your own IDs, ideally you would never have an agree button (since it’s redundant to agree with an ID you’ve already made). so if it what you were suggesting were implemented without any other changes, then the withdraw button would occur to the right of the compare button, effectively in the spot where the agree button occurs on other IDs.

because the word “withdraw” is wider than the word “agree”, the combination of compare + withdraw buttons would be physically wider than the current compare + agree combination.

i don’t know that you should necessarily make that kind of distinction. i think the more proper distinction is going to be based on screen size. ultimately, a website on a smaller screen should probably take into consideration the available screen space when deciding what to make available on the screen.

i’m not saying that we should take away the withdraw ability. I’m just saying there’s no need to bring it up to the forefront. there’s already the menu that contains it. if people are confused about the availability of a menu for each ID, then i think the appropriate thing is to redesign that menu button so that it’s more obvious to more people that it exists.

because of touchscreens, i’m not a big fan of tooltips these days. sure, add one if you like, but i would not assume that most or even many people would pay attention to it, and certainly i would not expect a tooltip to drive or modify any behavior by itself.

i don’t think that’s quite right.

on our own IDs, we can:

  1. withdraw
  2. edit (and from within the edit, we can further delete / withdraw)
  3. plus other things

on others’ IDs, we can:

  1. agree
  2. flag
  3. plus other things

on the community taxon, we can agree.

on the observation in general, we can always add a new ID or comment, and, of course, we can compare at the ID level and at the community taxon level, as well as do other things.

for what it’s worth, i would have no objection to adding an edit button, as opposed to adding a withdraw button. that would take you to the edit screen, from which you could edit, withdraw, or delete. i don’t think it would have negative connotations as a withdraw button might, and “edit” is no longer than “agree” in the layout.


One really gets the impression that you want people to resolve their observations, preferably in a sense that you agree with. After all the workshopping of button language wouldn’t the best options be “resign,” and “submit?”

I maintain that it is perfectly OK, acceptable, and to the point not a loss if observations remain at higher taxonomic levels than ideally achievable. You’re trying to optimize data quality where without the users’ participation the data would not exist in the first place. At the risk of overly generalizing, people use this platform for a variety of reasons. Please allow them to leave observations hanging, walk away, or otherwise leave their observations “unresolved.” Allow them to be contrarian and “wrong” so they can experience aha moments even if it takes them a over year - or if it never happens. Leave some space for agency. If they feel coerced to do “the right action” before they are ready, they just may simply image.


I have to admit I never even thought of this. Thank you for bringing it up.

I really like this idea.


I believe everyone should make their very best effort to identify an organism upon adding it to the site - that is simply courteous. I always provide a best guess when I upload butterflies and moths to my account at BAMONA - I believe it shows the individuals volunteering their time that I am as invested in the process as they are and that I am not simply relying on them to do my research for me.

I think that is why I like the idea of a Revise button after an initial identification…so, if I suggest my butterfly is a monarch and IDer #1 stops by to disagree and suggest it’s a viceroy, I can research why they disagree and choose to leave it unresolved or Revise my identification with the confidence I did my homework. For me, clicking Agree has an air of defeat to it - like giving in or giving up.

So…I guess I’m thinking…is it possible to post an image and identify it (using Computer Vision or one’s own knowledge). The first IDer has an option to Agree or make a new suggestion. The observer may either Revise to agree with the second ID, leave it alone or disagree by choosing yet another ID?

I envision the Revise button being visible only to the initial observer - to thoughtfully move the ID forward. Could the action be programmed to require comment - to dissuade blind-agreement? Most obs require only two in agreement, so an observer clicking Agree and submitting to the 2nd person’s ID makes the observation Research Grade. [Note: if a third individual agrees with IDer #2, the observation would be RG anyway and it will not matter if the observer revises, disagrees, or walks away, right?].

I am happy to take time to learn more, as in this Cladonia observation thread…but, I imagine others prefer tapping Agree and moving on.


Yikes. No, totally not my intention here.
If my passion and enthusiasm for change and debate sounds heavy-handed then apologies! I’m certainly not a natural when it comes to navigating social media. I get that the comment you mention sounds a bit presumptive. If there’s something else that I’ve said or done to lead you to this larger comment, then please flag it up for me to be more self-aware.

The issue of “blind agreement by OP” that this stems partly from was raised by many on the blog post following the recent agree button change. So, certainly not alone I think in believing this to be a bigger issue. I tried to list in original post all the reasons I could think of that people might blindly agree and why this was problematic. If you think I am missing something, let me know and I will add it in.

My personal perception that part of this might involve people desiring to resolve an observation is based on a few recent experiences, including:

  • As an identifier - having queried a user recently on their agreement…and they told me it was to “keep it tidy”.

  • A thread I came across debating the term Research Grade I think, where someone else posited that people wanted it to reach RG in order to have a sense of resolution.

  • comments I’m reading from users such as @cattailsandcobwebs who said they felt they had to “either a.) fix it or b.) leave it as a disagreement.”

For me psychologically, this rang true that some newer users might feel they have to resolve an ID. But, maybe I’m wrong on that.

100%. I think we’re on the same page here, no?
I am suggesting change to help prevent observations going to RG without sufficient input from the community. I have no issue with things remaining at a higher taxa.

That’s distinct I would say from, for example…my mum leaving a conflicting observation ID because she literally can’t find or does not understand where the withdraw button is. (Another trigger for me to post this). This just takes unnecessary community energy, as it means more people have to pile on to overpower an autosuggested ID to correct it. This is just disempowering her, without benefit.

I absolutely agree that iNaturalist should be a safe space for making mistakes!
One of the many many reasons I am a big fan of the platform.
But design issues on a bike that cause children to fall off more won’t teach them how to cycle better.
Whether the current design does induce the mistakes we are seeing or not, is absolutely up for debate.
I am just positing, that some aspects in place right now might be part of the problem.
And I guess asking, if so, what might they be?

I would argue, we could also say at present they are “coerced” into taking “the wrong action”.

My central thought, is simply to make it clear how and why to withdraw. Good UI design all hangs around recognition of affordance. Designing affordance involves exploring how best to visually explain to people how an interface functions. These are choices to make, like it or not.
All design, arguably, could be seen as coercive to some extent(?)

Do you feel the current interface explains perfectly all the functions available?
Is there nothing you would consider changing that might help with existing issues?
Is considering what that change might be, for you, coercive?

1 Like

Yes. Similar to the handy mock-up made by @schoenitz.

Sure. I just meant that the design issues seem to be pretty different.
The existing design/affordances seem pretty different on Android and iPhone and website. I don’t use the app, so have no idea how that feels. I can only really speak from my experience of the website, and second hand experience of my mum using the app.

This along with also burying the Agree button within it as you previously suggested also seem like a better option to me than the existing option at least. My primary concern is that there is a visual imbalance and these functions should be visually equal.

Similar to @cattailsandcobwebs suggestion of “Revise”… I think these are both also interesting options on how to deal with the issue. I think I lean marginally more towards Revise perhaps. But, maybe that’s also too specific. Edit feels more neutral which might be good in this instance.


edit is existing terminology for an existing function on an existing screen. a bigger change might need to be contemplated as part of a revamp of the whole page.

1 Like

It’s probably not feasible at all, but sometimes (even before this topic) I have thought it would be so much simpler to organize the IDs on an observation by showing them as a poll, with the list of taxa choices increasing as new IDs are added. Then there would be no need to have any strikethroughs. As in an open poll, a change of mind would just be a matter of checking a different taxa from the one first chosen (with the earlier “vote” disappearing), so no need to characterize the action, either.


I guess the other thing to consider is effort.
At present, on the website:
Agree = 1 click
Withdraw = 2 clicks
Delete = 3 clicks, as well as waiting for a new window to load.

For me, ideally, I feel like these three functions should be not only visually equal but also equal in effort to achieve. Both of these imbalances likely play into the existing dynamic, one would imagine. Ideally, I agree with @schoenitz in a sense, that no-one should be incentivised (or coerced ) into one action over another.

You mentioned “Flag” also - I actually have no idea what this does in this context - what does it do?


i believe at some point a few years back, delete used to be equivalent to withdraw in number of clicks. now, it’s buried, which i don’t think is a bad thing. i sort of like to see the full history of revisions, which is impossible if things are deleted.

this just allows you to Flag a particular id as problematic for a curator or staff to look at. you might Flag joke IDs or IDs with inappropriate notes, for example.


I see. I guess for me, I find it annoying when I add an ID, and then 10 seconds later realise my error…and find it annoying to have to click through to a new window just to undo something basic. But, under other circumstances I get what you mean. Not so relevant to the withdraw issue, anyhow at least.

@catttailsandcobwebs -

See here for another debate about strikethrough btw :

And here for a connected feature request you can vote for: :slightly_smiling_face:

Oh, I do not expect iNat would have any interest in promoting app use over the website. They seem pretty committed to the website portal; the app seems mainly for introductions to new people and for field updates.