Should some fields be required when creating an observation?

General
1

Hello. I’m fairly new to iNat, so it’s possible this has been discussed before and/or it’s controversial. In looking for ways to help out on the site, I’ve had a lot of people tell me it is helpful to go through “unknown” observations and put them into broad categories (“plants,” “birds,” etc) so that search filters can pick them up. I’ve also been instructed to flag things as “not wild” if necessary. After a while of doing this, it occurred to me: 90% of people who create an observation of the rose bush in their yard do know it’s A) a plant and B) not wild, but they left these fields blank because…well, because iNaturalist let them!

I’m proposing the form to create an observation have some “required fields” which must be filled out, so that it isn’t possible to create totally unlabeled observations. Personally I would like the observer to have to choose one of the same category icons the search filters use: birds, amphibians, reptiles, and so on. “Unknown” would still be a category, but the user would have to consciously choose to apply it, in situations where they genuinely don’t know what they are looking at. I would also like a “multi” category which the the person could click if their observation contains more than one life form; but this button, rather than actually going through, would simply kick back an error message explaining how there can only be one life form per observation, and the user needs to make multiple observations if they desire to upload more than one life form. And finally, I would like every observation to require the user to click either “this organism is wild,” “this organism is not wild,” or “I don’t know,” before publication.

Would this result in more mislabeled organisms? Sure. But I don’t feel it is more work for other users to change something from “plant” to “fungi” than it is to change the item from “unknown” to “fungi.” Yes, it would force the plant people (for example) to look at a few more non-plants than they might otherwise see, but assuming the observer is correct in their labeling at least some of the time, this would decrease the overall workload on the site.

Will people lie about whether an organism is wild, because they do not want the observation hidden from general view/they want the higher likelihood of community ID? They probably will, but some people do that already, it seems.

Thank you for your thoughts.

5 Likes
Thoughts on unknown ID level?
2

Just a heads up that although you submitted this as a feature request, I moved it to General until there’s an actionable feature you’d like to move forward with requesting as a result of the discussion.

If I recall correctly, I believe an initial ID is mandatory on iSpot, a website similar to iNat.

I’m one of those people who submits a lot of unknowns, not because they’re necessarily unknowns but for a host of reasons. One of those is that adding observations via mobile could really do with some streamlining, and making some fields mandatory would further slow the process down in the field for sure. Though, were a draft mode created I probably wouldn’t mind so much if some ID were required before going live.

3 Likes
3

I would not support making the Is Wild / Captive field be mandatory. The default assumption on the site for records is that they are wild. The same way the default assumption is that the date is accurate, the location is accurate, that the evidence actually supports the presence of the organism etc, yet none of those are proposed as mandatory.

3 Likes
4

A second impact of making the is wild mandatory is if people were to ‘cheat’ and mark yes when they know it is not, it would then require 2 votes to the contrary to get it moved back to casual, as the 1st dissenting vote would only offset the submitters and return it to a base status which is that it is wild.

2 Likes
5

Why not just have all observations in “Needs ID” with sticky filters for Wild and Casual, to remove the incentive to cheat?

6

Doing this would more or less break my ability to use Inaturalist the way I do now, would basically ruin the app. And it’s been tried before. It also broke the app any time you didn’t have cell service. So it was reversed. It might reduce some errors but would greatly impact the experience that established users have. And from what I remember project Noah had similar requirements and they were why I didn’t use it.

1 Like
7

Here’s something I couldn’t have known. What specifically was tried? When? How long was the trial? Did the app crash or was it just less enjoyable to use? Isn’t a lack of cell phone service normal when searching for wild creatures?

8

It was in the beta/test version of the app so it wasn’t released widely I don’t think. You just literally couldn’t observe anything without cell service (to tag the species) and so it didn’t work in most of Vermont and where it did work it was extremely slow.

The only way I could see it working would be on the website to publish after draft mode. But it would probably just confuse new users.

9

Fair point. Although the “default assumption” of wildness is something I had to learn on the forum. It was not clear to me from the wording of the site and app, which seem intentionally open ended.

1 Like
10

Thank you for linking those topics. They were quite relevant and informative.
Update: I do now agree with your decision to move to General. I’m not clear on how feature requests work and I thought the board for them also included discussion of possible requests.

11

I wasn’t imagining it as needing to load the database drop down suggestions. I was thinking more that the icons used for the search filtering would be displayed in a row, and you would poke the relevant one to select it. Maybe that is a misunderstanding of how programming works.

12

well, you could make someone select the high level taxa, but then they’d have to do that even if they knew the species, then drag through the whole thing again to update the species. All while in the field - right now it takes me about 3 seconds to make an observation so anything that takes 30 seconds is going to make a big difference. It’s the difference between me doing iNat while hiking with a 3 year old or not doing so, and also the difference between being able to use iNat for work related things or not (because it’s a time saver for many things but if it became a time sink instead i’d need to stop).

I suppose it could be something you could turn off, but that might drive away users before they got that far.

I just don’t really see the need. The unknown observations usually get identified anyhow, they are annoying but… this alternative sounds much worse to me.

13

So would you say there is no problem at all with the current system, or that my solution is the wrong solution?

I suppose the higher quality ones do, although it seems to take quite some time. Here’s a perfectly good one which took 11 months to get out of the “unknown” bin, but took a mere half day to reach research grade after I pulled it up: https://www.inaturalist.org/observations/13718558 (That particular user is unlikely to care, given their inactivity.)

14

https://forum.inaturalist.org/t/automatic-computer-vision-ids/2074 would be an interesting alternative

15

i would say the current system is imperfect but if i am understanding what you are proposing, it would be much worse than what we have now because it would make the app really hard to use in the way a lot of people use it now. People have often proposed more confined or ‘hand-holding’ changes to the app, some already exist, and already cause problems, but are considered worth the trade off… making the app more clunky and slow to observe things would ruin it for a lot of established users which i don’t think is a good or fair solution.

well, if we are talking about ‘poor quality’ observations by fled users, that makes it even more apparent that it’s not worth ham-stringing the app over. The problems to me seem to be fled users (often duress users) and problems with the ID system. people have proposed (or even made versions of ) app functionality for quick ID of unknown observations, the proposed draft mode would help for cases when established users make unknown observations, and there are other ideas out there, even allowing the ID algorithm to assign coarse level IDs for old unknowns. In terms of things being flagged captive versus wild, i think requiring that field would cause a bunch of people to put things in as wild when they aren’t, either because they don’t understand the question or because they want to get an ID faster. And as mentioned above, those would be harder to mark as captive than if just left alone since it would take 2 votes. Better onboarding, allowing cultivated plants and such to get the equivalent to research grade, and solving duress user issues are probably the only real answers to the captive-as-wild thing.

I get why you are proposing this and the thought behind it is reasonable, but the site really has taken a life of its own and the app is used for a ton of different things and allows a lot o people to use the site in ways they couldn’t without a fast and easy app. And it’s been tried before and at least in my observation, it wasn’t a success. So, I don’t think this is the way to go unless paired with a draft mode.

16

Okay. Thank you for the more detailed explanation, @charlie . I do agree draft mode is a big need (at least for me and how I’m currently making observations) and would help with the “unknowns” situation.

2 Likes
17

sorry if my previous posts were brief and not as good, this one comes after the 3 year old fell asleep so i had more time to write it :) I think you are correct that there are app interface ways that could be used to help with this but i am also really not a fan of required fields. Like… you can make a project with required fields, and i literally won’t participate in that project, even though i use fields quite a bit on my own. It’s way too annoying to have to deal with the pop ups and often the required field doesn’t even apply… so maybe it’s a bit of a pet peeve.
Anyway, the forum is literally telling me i am posting too much in this thread so i will leave it at that so others can comment :)

1 Like
18

Wait, what? There are over 450000 verifiable observations in the unknown pool. To me that says the system isn’t working. It doesn’t seem like a big ask to me to have people select one of the iconic taxa on upload – it’s maybe half a second to check a box, and unknown would still be an option, but one that would have to be consciously chosen. If that’s going to make the app completely unusable, it could be something to opt out of in a semi-hidden account setting. At least then new users would realize the importance of adding even coarse IDs, and power users could opt out.

I might be misunderstanding, but I think the idea is that you only have to select from the iconic taxa if you decline to enter a species ID. Once you’ve entered a real ID, the requirement to select from the iconic taxa disappears.

19

It’s not an initial ID that is mandatory on iSpot, but you have to select which group the obs falls under: Birds, Amphibians&Reptiles, Mammals, Fish, Plants, Invertebrates, Fungi&Lichens, Other Organisms. So even if an obs had no initial ID it could be filtered into groups for IDing. An obs there rarely get a high level ID (such as Plantae) unless it is impossible to ID further. This has some advantages over the proposal that all obs on iNat must belong to one of the iconic taxa. If we forced all plant obs, when added to iNat, to be ID’d to some level, you’d get thousands of IDs of Plantae, making life difficult for the IDers as they’d get mixed up with all the obs that are ‘Plantae’ for a good reason: they are bad or ambiguous obs that cannot easily be ID’d further.

20

Yes, that’s the idea. If you do input an ID, the system already does assort the observation accordingly.

Should an iconic taxa selection be required as a part of uploading?