Apologies if this question has already been asked (as I’m a French speaker, I’m not searching in the most effective way).
On several topics, I find that the ‘observation fields’ are truly an essential feature of iNaturalist.
Unfortunately, unless I’m mistaken, this information isn’t accessible via the mobile app (I’m on Android), either for viewing or, even less so, for editing.
Have I missed a feature?
If not, is there already an issue (on GitHub) or a forum thread requesting this feature for mobile?
I have an external app that can display them for you if you have a specific need. I think they were going to add some functionality to the iNat app. not sure the status of it.
It requires a .json configuration file for a variety of reasons, which I don’t mind setting up for you so that you could try it. This also means that it’s “project based”. In the above example, I’m pretending that an ecologist at a nature preserve has asked a team of observers to document bees found visiting specific plants within the preserve.
The first component, “Notworthy Natives” displays a list of plants. When a plant is clicked, you can see the bee activity observed on that plant. You can then choose the specific bee visiting the specific plants to see images collected by the team and a map of where that plant / insect activity was observed.
There is also some support for tertiary observation fields (what was the bee doing when visiting the plant). This applies more to butterflies and other insects which might have been feeding, nectaring, pollinating, etc.
The “matrix” component is also sort of interesting because it’s a running log of the teams observations and also allows sorting / filtering when a plant or bee is clicked within the matrix.
It’s very simple in terms of coding. I’d be excited if someone else took the concept and ran with it.
Part of the intent is to hide the complexity of iNat from the team of observers who is slowly on-boarded onto iNat by the ecologist… who becomes self-interested in their on-boarding in order to receive better data.
Thank you for this tool, @stockslager : I’ll try to get to grips with how it works.
However, I’m not sure it meets my needs.
What I actually wanted was to view, or better still, edit, the observation fields directly within the iNaturalist app (without having to leave the app and go to a website).
Your reply confirms that this isn’t currently possible.
I’d also like to support any efforts that may already have been made to request this feature (I’d be surprised if I were the only one to have raised this).
It sounds like you’d be more interested in a different component (or components) of the same prototype app. This component is designed to fit better on a mobile handset. The updating of observation fields is very clunky… you need to select the plant you’re interested in, followed by the insect observed perching on that plant, and then you can click an image where you want to update the tertiary observation field (clicking the image will just bring up iNat and allow you to set the observation field there… and it sometimes launches the app which doesn’t allow editing of obs fields). https://stockslager.github.io/iNat/nn/garden/garden_list.html?params=france2&component=plants&hide_dash=yes
I know this is only closer to what you want… and still not exactly what you want. I’d only ever experiment with updating data via the api’s if I were doing it as part of an organization. For some reason, the relevant organizations are really reluctant to hire a software developer to extend and enhance iNat. This would be preferable to iNat trying to address all the scenarios related to complex related observation fields. This may sound like i’m lobbying for a job but I am not. However, also not likely to update their data without the oversight of an organization.
They are available if you are adding an observation to a traditional project and that traditional project has observation fields attached to it. For example, if I try to add an observation to the Bird Fishing project, I get this option:
I can’t remember whether I’ve mentioned this before on the Forum or not, but I’ve noticed that when you go through the app to add an observation to a Traditional Project that has drop-down Observation Fields, it will automatically add the first choice in those Observation Fields to the observation, even if those fields are optional and you did not individually press Add for the field.
do you know if iNat generally prefers something like this to happen from external apps? @tiwane
an external app that allowed annotations of only bees could make a lot of assumptions about the types of annotations appropriate for bees and the life-stages specific to bees. it would greatly simplify the app. it would have a simplistic searching/filtration mechanism and when the user arrived at the end of the filtering with the list of observations to annotate, the logic wouldn’t be as complex since it’d be specific to bees.
what this might trigger is additional discovery…
once they had their custom app, the bee experts might realize they have additional annotations and observation fields they’d like to collect that aren’t supported within iNat. they might create an external database with external api’s and allow their front end access to both. this would mean they’d be creating iNat observations through their new front end. the annotations/obs fields would be created first in the external database, then a create transaction would be executed in iNat. it’s possible that some of the annotations in the external database could become orphaned without integration on iNat’s side (and subsequently left out of the filtered display)… but is this part of the future that iNat sees? the orphaned annotations db entries could be periodically cleaned up in a batch process.
i feel like whenever I ask a question like this I get an answer like… you can do whatever we allow you to do… rather than… yes, that seems to us like a valuable use of an external organization’s time and money. iNat probably has the worlds largest active network of observers, why wouldn’t they want to integrate with us. we don’t have time to spend helping each of them, but we’d love it if they built custom front-ends based on their specific areas of expertise.
*** this might should be its own thread. it definitely relates to “observation fields on mobile app”. but it’s really a question of overall direction. does inat prefer centralized data collection and display with consistency of data-structure and approach. or does inat prefer decentralized data collection and display with diversity of data-structure and approach. the latter would provide the possibility of more complex observation field data structures (more complex than name / value pairs and potentially specific to taxa / location).
@tiwane I get the impression that a lot of us would like that.
At the very least, to be able to view them in read-only mode without having to leave the app, and then display search results based on those fields.