Yep, it’s really great! Basically everything I’m ID’ing now is getting annotated at the same time, because it’s just so much easier! Sorry, I already praised this extension in a post above just yesterday, but can’t stop gushing about it. 
I know it’s a different set of coding and everything, but I swear basically this exact interface should be rolled into iNaturalist’s web platform.
I think this perfectly illustrates the need for selection based bulk updates. Personally, I’d trust dianastuder to do a massive bulk update. I wouldn’t trust myself, but maybe that’s my problem. I’m not sure actually. :)
If the new Tool will capture Placeholder text
before iNat can destroy it
then I will tackle the plants
if I can USE the info the observer carefully entered - and then fell for iNat’s - shall we make that a placeholder for you? 
No other data that an observer adds is silently deleted.
Not even - Placeholder was here - survives.
I’m not sure what you mean by API support here. I have already written and run (last year) a script to generate thousands of OF actions to annotate cynipini observations from species only known from one generation (IE no need to check the observation specifically as long as it’s RG confirmed to be that species). The script just sequentially sends the API requests one after another; if you put a time delay in it, the API limit is never hit. But there isn’t a specific functionality where the API accepts a list of observations at once, if that’s what you mean. It’s all done one at a time, just automatically.
the work you’ve already done is amazing. excited by the prospects of a new bulk update mechanism. keep going. :)
time delay built into updates in a for loop should work as long as there isn’t a proliferation of client side scripts (or a proliferation of their use).
I just added alphabetical sorting.
When you get the new version, let me know if you still have the issue with new buttons not appearing. I had this issue at one point and fixed it but it’s possible the fix didn’t work for all conditions.
This should work perfectly with the existing setup. All you’d need to do is define a combination of inputs in the extension (eg ctrl+shift+alt+x) and then map one of the controller inputs to that combination of buttons in Xpadder.
Thanks a lot. I see the alphabetical sorting but I still have the issue with some buttons not displayed (same result as my previous screenshot).
Are you not able to add any buttons at all after importing or what? I can’t duplicate the bug in my browser so any additional info you can provide would be good. I will add more console logs later to help debug.
If I add one more configuration “P. pterocarpum”, I get:
The new button is there, but “Delonix regia” and “Senna occidentalis +” are missing:
Sorry, just finally getting to this. This does seem like it could be what iNat defines as Machine Generated Content.
Taking a look at the policy, it seems like the use of such a tool is explicitly permitted, as long as users do in fact check the observations before applying the metadata:
“It’s ok for humans to use machines as tools for arriving at their choice or to facilitate posting this content, as long as there is human involvement/oversight creating the content/decisions about each individual observation, identification, or comment.”
My intention is for users of the tool to apply that oversight–the whole point is to scale up the ability of knowledgeable users to apply their expertise.
What if it worked something like the “mark all as reviewed” button? You could click once to select every observation on the page, then manually click to remove some of them, and only apply the bulk action to those? That would remove the ability to do the really big batches, and it wouldn’t completely guarantee adherence to the policy (users could still apply actions 30 at a time without paying attention) but it seems like a reasonable compromise between attention and power. The observations would at least all be on screen immediately before the action is committed.
I also have some additional safeguards in mind (confirmation dialog box, undo button, prevent users from overwriting existing OF values during a bulk action). Also toying with the idea of making the user select a filter URL that excludes observations based on whichever action they intend to take. That would clear them from the ID page after the action and avoid undesired repetition.
I will need to think more and talk to potential users and experiment with how I want to implement things, but I won’t do that if you don’t want me to move forward at all.
I am not sure to visualize correctly, sorry if I went out of the road… What about the paging done by iNat (when I am in view “List” (subview=table), when I scroll down to the bottom, more observations are loaded)? Would the batch action apply only to observations currently displayed or to all observations matching the search query URL (even those not yet displayed)?
Screenshots of the “big batch” procedure steps would help understand.
In my original vision, it would make no difference if you used the Identify or Explore page to curate your batch. The batch action would apply based on the filter criteria in your URL. You can use the same filter criteria to fetch a list of all corresponding observations from the API.
In the version I just described above, it would only work on observations currently displayed on the Identify page, which has a max of 30 observations at a time and doesn’t scroll.
Thanks. I’m also having difficulty imagining this without a concrete example. So let’s say i’m annotating lepidoptera, adding life stage annotations, using https://www.inaturalist.org/observations/identify?quality_grade=needs_id%2Cresearch&order_by=random&without_term_id=1&taxon_id=47157
I get a page of 30 obs, nearly all are of adults (although I’m only looking at thumbnails, so I may miss obs that have photos of, say, adults and larvae). I see one of a larva, the rest appear to be adults:
What I’d do then is:
Are you still intending to put this in the extension stores eventually?
Yes, once I’m done with it. But I’m currently in the feature creep phase of development :) I just added a whole page that generates URLs and now I guess I’m going to figure out if I can/should add a bulk action option as well.
Here’s a quick mockup:
Your example is perfect; in that scenario you’d have three options: You could mark the larva as reviewed and refresh, as long as you had reviewed=false selected.
You could use a search URL to exclude observations that have lifestage annotations, then manually apply the annotations to the one larva observation and refresh to make it disappear. Then you could select all and apply the Adult annotation to all 30 (assuming that refreshing didn’t add a new larva observation).
Or you could select all, then click the larva observation to exclude it from the list, then click to add adult to all the selected ones. This would leave the larva observation unannotated.
Either way, you would need to deal with the larva annotation before you add the action, because you don’t want to add an incorrect value (especially true for annotations, which can’t be overwritten).
Then you could go on to the next page, yeah. Again, it will definitely be helpful here to employ URL filters that clear the observations once you’re done with them.
I just added a second input page to the extension that allows you to generate Identify page URLs using the full power of the URL filter parameters listed in the forum wiki post.
The most recent version also has a minor bug fix for Firefox users and some other minor fixes on the options page. Please remember to export your configurations before you remove and reinstall!
Since there are yellow squares highlighting selected observations, it could be simplified (less clicks): manually apply the annotations to the one larva observation, then click on “Select All [Others]” (this would select all observations that you have not yet annotated during this work session) and apply the Adult annotation to all these other observations.
(Just a suggestion, I don’t need it as I never add annotations).
