Description of need:
There are often multiple species in an observation. This is common with plants and parasites like galls/leafminers/fungi. People frequently seem confused when you request they duplicate an observation, they will often not don’t do it, or do it poorly (for example duplicating 5 plant pics for an insect in pic 4).
Feature request details:
I would like to have a simple button Request Duplicate button which allows me to make a ‘draft’ duplicate of someone’s observation which will appear as a request for them. All it need to do it is open a version of the duplication UI and allow me to check which images.
Then the user simply gets a notification like “A user has requested you duplicate X” and a preview they can approve or deny
I was hoping that question would take me to one of your kind and helpful tutorials - how to duplicate this flower obs for the bug.
PS still needing to go via the ‘old’ Help to get to the preferred ‘new’ Help.
I routinely encounter multiple species per observation. I always downgrade the ID, leave a boilerplate comment, and move on. The comment is brief and general:
Multiple photos, multiple species. Can you split this observation? Thanks!
If there were a help page for this, I would include it in the boilerplate.
I don’t know an easy way to “split an observation”. In any case, splitting an observation is different than duplicating an observation. I wouldn’t use the word “duplicate” in a help page or user interface involving a split.
I do a lot of sound IDs, and I’d support the “Request Duplicate” button just for the many sound recordings in which multiple species are singing. I have a text replacement to suggest that the OP duplicate the observation, but only a few follow through.
I would find that confusing, as an observer. On at least one occasion I inadvertently added an unrelated photo to an OBS, and it was pointed out to me in a comment by an IDer - something along the lines of “the organism in photo 3 is different from the organism in photos 1 and 2. You should make a separate observation,” which made my error clear to me. As a newbie, I wouldn’t have understood if informed that I needed to “split” or “duplicate” the OBS.
I think you should be careful about making things more confusing to newbies, who I suspect are most likely to make the kind of OBS that needs splitting. There can be a steep learning curve for using iNat, both as an observer and as an IDer.
Let’s hope that a “multiple-species observation” (with different organisms in different photos) won’t get duplicated (all photos duplicated, making 2 “multiple-species observations”). Such a confusion would be even worse.
You can duplicate an observation and just delete the extra photos. I’ve done it. It’s not hard at all.
I prefer that than a button that will select only one picture . What if the subject is in 3 pictures?
I’ve had observations where there were three different bombus, so I duplicated it twice and the other two observations just cropped the photo to capture the species that needed ID’ed.
While this seems like a decent solution and not one I’d feel confused by, I admit that new users often have struggles that are hard for experienced users to fathom. But I do think some kind of UI flow should be implemented to address or mitigate the number of observations logged that have several photos of distinct subjects. The DQA lets us turn those into casual observations, but it would be nice if we had better chances of getting those actually fixed and turned into RG observations.
Part of the issue is also that a lot of new users either don’t respond or don’t notice at all when people request observation splits in the comments. I wonder how much of this would be fixed if the platform, especially the apps, communicated notifications in a way that was more salient and insistent. If a “Request Duplication” button that drafts a suggested duplication is considered too complicated for new users, perhaps a “Request Duplication” button that creates a special type of notification that is displayed with an urgent error/warning symbol and only clears when the request is viewed and then either denied or agreed to would be helpful?
Alternatively, I think this is another area where it feels like a problem that there are two Casual grades, “Casual = Captive/Wild” and “Casual = Data Quality Problem”. If we had a distinct Error grade that applied to observations with data quality problems and a flow around that grade which helped bring it to the original observer’s attention quickly, I think the DQA moving these observations into that “error grade” would probably go a long way to addressing the community’s desire to fix these obs. I suspect a lot of folks would want to fix data quality issues in their observations if they were aware of them.
My idea has mutated a few times on this. In the past I really wanted a “Request Observation Split” that behaved the same way. Maybe there is a clever way combine that idea in here.
@tiwane fwiw here’s another https://inaturalist.ala.org.au/observations/66242032
it’s just one of a set of requests I got from a researcher interested in the clams that were otherwise just “part of the background” in obs at that location.
I’m likewise a little wary of having random people just go open slather duplicating my obs for every little thing that might be visible in each photo - but it would be nice to be able to help genuine researchers like this in a way that has a bit less Busywork than, them posting a request on each of my obs of, me spending time going through all of those to dup them for them, then them going back again to add confirming ID’s …
So some way of flagging them simply, and me being able to “one click ack or deny” the extra work done by the person who wanted it seems like it could be a Nice Thing.
I’m going to decline this request. I think a better solution would be for iNat to build a duplication tool in iNaturalist Next (the one on the web works fine), rather than engineering a special tool for making a request. I can make a non-video help doc for using the web and Android ones that are available at the moment as well.