Description of need:
Photo Browser shows all photos of a species rather than just the first photo. Many observations include interesting photos but you’d never know it unless you open up every observation and look at each photo. That’s enormously time consuming. Hence Photo Browser is very useful. Howver, endless scrolling is tedious and you can’t come back to where you left off after closing browser.
Feature request details:
Make the Photo Browser view paginated like the Observations and Identify view.
Clicking that icon could show the pictures arranged horizontally in a filmstrip widget on a modal layer. Or the UI could do something similar to what Lightroom and Darktable do:
Also, the current system eats up RAM much more the further you scroll, than a paginated view would. It’s not an issue for me except on principle, but I know many people who have older computers or phones with less memory.
I wouldn’t mind pagination (not sure how difficult it would be to implement) but I’m wondering if you’ve used the filters on the page as well, to narrow down the number of photos being returned?
I admit I don’t use the photo browser on iNat very often, but I still remember the backlash when endless scrolling was introduced on Flickr. Oh boy, users were not happy with it. The site eventually went back to paginated photostreams. So from an online photo browsing standpoint, it seems pagination is preferred over endless scrolling.
If I understand what you’re proposing, I would really like the photo browser to default to showing only the first photo from each observation. I often use the browser to get just a general idea of what the members of a taxon look like. In that situation, multiple nearly identical photos are of little interest. Collapsing the multiples in a display such as this,
Now, as it happens, the last of the observations shown in the reimagined display contains two quite different views, one lateral and one frontal, so hiding the latter by default would not be so advantageous. In Lightroom, one can choose how coarse or fine the aggregation is, and maybe something similar could be done here.
Incidentally, I find the Photo Browse feature generally more useful for this than the list of observations, where the number of photos in each is stated, because it’s easier to filter on, say, nymphs.
Agreed, I think it would be very helpful to have a paginated view. I like to use the photo browser to look for misidentifications, when species A is frequently misidentified as species B. I’ve also suggested it to others to look for observations to include in projects (e.g. a project to aggregate instances of predation).
Filtering observations down is useful sometimes, but not always. For the project I mentioned above, the user wanted to include all reptiles in Australia. You can filter it down by browsing each individual species and narrowing by location, but that’s extremely tedious and only gets you so far, especially for species with lots of observations (one reptile species has 20K+ research grade observations in Australia- that’s a lot to scroll through!). Having some way to come back to where you left off would be extremely helpful.
I also wasn’t aware of how RAM-intensive endless scrolling is, but as I sit here using a 10+ year old computer, I definitely prefer options that use less RAM.
The Photo Browser is fine as is, just need pagination to scale up to the ever growing data set.
Some taxa need multiple photos for reliable ID and these are prone to have photos of other taxa mixed in accidentally. (I’ve done this a couple of times)
Showing every photo help weeding out the misplaced photos.
I’ve likewise used the photo browser to search for wrongly identified observations (as well as to check for photos of other taxa mixed in), and would agree with the benefits of both reduced RAM and not losing your place if there are lots to look through.
I would love to see grouping too because when looking at species, the first photo of the observation is typically a good quality photo. But to clarify, the reason why I mentioned the Observation’s page is because that one is already paginated.
The other uses mentioned here could definitely benefit from pagination, but as users, we need to lower our expectations a bit. By looking at their API, there is no way to obtain a standalone list of photos based on some criteria. The object that ties it all is the Observation. In my opinion, that’s why the infinity scroll was chosen for this. But if I were to implement a paginated photo browser, I’d give you pages of observations expanded into photos.
For example, for page 1, if observations 1-10 have 10 photos collectively, I’d show you 10 photos. Then if 11-20 were to have 50 photos collectively, you’d see 50 photos in page 2. Every page would have a variable number of photos (unless you collapse the photos by observation). While possible, I would not do the work to discard photos and read a partial set of photos just to show a fixed number of photos per page.
So I got a bit interested in Paropsina, especially one called Paropsis Atomaria which is everywhere in Southern California. I annotated all… haha… all of the observations of Paropsina (three species) in the U.S. with their Life Stage, resulting in this beautiful chart:
I feel your pain. The fastest way I found was in the Identify page. Setting per_page=100, and then picking page 10 and working my way back. To speed up annotating Adult vs Larva vs Egg, I mapped F9 to “la” and F10 to “ll”. I did that enough times that I started thinking about new features to speed it up but I’ve not sat down to think them through. I did think that the Identify page needs an “Annotate” mode. Or perhaps a separate page “Annotate”.
It’d work like this:
Show the observations just like Identify does. N results per page.
Allow multiple selection
When a selection is active, give the option to…
Annotate
Add to project (for you)
The rationale for this is that the Identify page already has a button to “Agree” on each observation, so why not formalize that workflow into something that enables faster quality control of recent and old observations.
The filter could have a “Not In Project” = “” to help you filter out what you’ve not added to that project.
But I know it’s more complicated than that because the annotations are dependent on the taxa that’s selected.
Anyway, it’s a bit off-topic but I like it. It’s a good brainstorming session with the goal of making the site more efficient to QC mass quantities of data.
I sure am! I wish I could share tips for how to breeze through annotating faster but the truth is that I’m actually pretty slow about it! I just use the identify mode at 30 per page and then I use the keyboard shortcuts, I haven’t even mapped keys the way you have. I’m a bit of a technophobe so I don’t mind the slowness if it means I can avoid the scariness of having to figure out how to map keys or install a browser extension :)
Editing to add: I just looked into Paropsina and I salute you, friend. Leaf beetles are an absolute delight and annotating 6K+ observations is no small feat, even for a species as wonderful as a leaf beetle. If you ever want a hand with more leaf beetles I’d be happy to help out (might I suggest the cottonwood leaf beetle? Or perhaps one of the tortoise beetles?).
Agreed. Scrolling the photo browser is by far the fastest way to catch misidentifications and observations that need the DQA vote “Evidence related to a single subject? No.” However there’s often too many photos to look through in one sitting and without pages there’s no way to find where you left off.
I looked for a solution like this because Adult is the most common life stage and it’s hard to type ‘l’ then ‘a’ with one hand and then press the back arrow key with the other.
What I do in each page is to look first take care of rare ones (pupa, larva, eggs). Then I sweep the adult ones with F9 → arrow key, F9 → arrow key, …, until done.
I don’t use DQA. Leaving a message proved to be is just as effective.
On the flip side, I received similar messages when I mixed them up and never been DQAd.
Your choice. But the DQA is intended to push it to Casual and take it out of Needs ID - as a courtesy to future identifiers. And to avoid a tug of war - do NOT ID the first photo, there is more.
I tend to leave a comment if the observer seems still active but then come back later and DQA if it’s not fixed (though ‘later’ can mean anything from 10 days to a month or two, or indefinite if I lose the tab…). It seems unfair to just DQA if the observer is happy to fix it, as plenty are.
I find it’s best to do both- mark DQA and leave a comment, even if the user seems to be inactive. Often active users are unresponsive and very rarely inactive users actually come back and respond. I check all my notifications so after a response, I can remove my DQA votes.
