Group selection quirks in upload interface

[sbushes]

Platform : Mac OS 10.14

Browser : Chrome

Screenshots :

Selection of a single image:

Attempt to group select three images using shift-click:

Description of problem :

Step 1: Select the second photo, Empis livida.

Step 2: Shift-click a few photos along to group select connected images, ready to combine

Step 3: Wonder why it’s being weird.

I consistently find quirks with this aspect of the upload interface.
In this particular instance, I clicked the first, shift clicked the third to create a group, but it selected all four on the line. Then trying to reproduce it a moment later for this bug report, it wouldn’t group select any at all.

I’ve noted similar quirks like this in trying to group select images for a while.

[sbushes]

Coming back to it again, I was able to reproduce initial bug :
So this is created using the same action as above. Shift clicking on image at end of row having first clicked on 2nd image along.

[pisum]

i see a problem only if you’ve re-ordered the observation “cards”, as is now possible since https://forum.inaturalist.org/t/web-uploader-update-duplicate-and-reorder-observations/11467.

for example, suppose you have four observations:
:A: :B: :C: :D:

if you select :A: (the first item) and then shift+click :C: (the 3rd item), then you should see [A], [B], and [C] selected:
[A] [B] [C] :D:

however, suppose you reorder the observations by moving :C: after :D::
:A: :B: :D: :C:

then if you select :A: (the first item) and then shift+click :D: (the 3rd item visually but the 4th item created), you’ll see everything selected:
[A] [B] [D] [C]

alternatively, suppose you reorder the observations by moving :D: before :A::
:D: :A: :B: :C:

then if you select :D: (the first item visually but the 4th item created) and then shift+click :B: (the third item visually but the second item created), you’ll see [B], [C], and [D] selected:
[D] :A: [B] [C]

… in other words, the shift+click operates based on the order of the observations as they were created, not based on the order of the observations as they are represented on the screen.

[sbushes]

Nice. Yep, that seems to be the cause. Good to know how to avoid.

[sbushes]

Ok…still noticing more of this.
Seems a bit more to it.

This time, no reordering happened …but the quirks are there. The photos have been uploaded and grouped in order taken…except the grasshopper photos which were dragged in afterwards to the front of the queue.

Here I am selecting obs 5 then trying to shift click obs 1 to select all, but it only selects the two observations.

Moments before, as with the original post, it flicked from accidentally selecting everything to not group selecting at all.

Will keep playing it with it when I upload stuff tomorrow to see if I can figure out a theme… maybe there are other triggers in addition to reordering.

[kiwifergus]

@sbushes

This time, no reordering happened …but the quirks are there. The photos have been uploaded and grouped in order taken…except the grasshopper photos which were dragged in afterwards to the front of the queue.

so the order they were added to the uploader was 2-3-4-5-1 (as they display in your screenshot), you then group highlight 5 and 1 and so only 5 and 1 are highlighted! That fits what Pisum described as happening, the “order” as far as grouping is concerned is not the displayed order, but rather the order they were added to the uploader…

[sbushes]

Ok, just trying uploading again now.
Same quirks, no reordering, no later additions, just adding photos as is, in order, and trying to group them.

[kiwifergus]

If you pick up from folder starting with number one, then number 10, it drops number 10 first into the uploader, followed by numbers 1-9. However, I don’t think this is anything to do with that, or it would be happening a lot more frequently!

Other possibilities are maybe that the initial logical order (ie not necessarily the appearance or physical order) could be influenced by esoteric matters, such as the order the “objects” (cards) are created in the browser, which could in theory differ to the order in which they are placed and displayed! Maybe even the filesystem creation date/time is coming into play, or file modified date…

[pisum]

like i said before, i don’t see any problems unless the order of the “cards” as they are represented on the screen does not match the order in which they were added to the screen. so if you see a problem that’s unrelated to that kind of mismatch, then i would just suggest trying to document a specific set of steps that you can use to reliably reproduce the problem you’re seeing. without a way to reproduce the problem, i suspect it will be really difficult to fix the problem.

[sbushes]

@pisum

i don’t see any problems

Even if there is no issue here beyond this :

@pisum

the shift+click operates based on the order of the observations as they were created, not based on the order of the observations as they are represented on the screen.

This still needs fixing…it’s unintuitive, not in keeping with similar interfaces and will likely increase errors on upload needlessly. I highly doubt it’s an aspect of the interface which was intentionally designed to act like that … more just a simple error / oversight when coding.

But if this is not seen as a bug, then I can put in a feature request for it to be altered instead.

[pisum]

@sbushes

But if this is not seen as a bug, then I can put in a feature request for it to be altered instead.

to clarify, i don’t think anyone is claiming it’s not a bug, nor that it shouldn’t be fixed. as noted previously, the problem seems to be:

@pisum

shift+click operates based on the order of the observations as they were created, not based on the order of the observations as they are represented on the screen

there are at least 3 variations of this sort of case:

• user explicitly reorders the observation cards
• user adds an observation card before another existing observation card
• user duplicates an observation card that is not the last observation card. this will add an observation card that appears visually after the duplicated observation card (and before another existing observation card).

in the posts from July 2020, you seemed to be saying that there might be cases that didn’t fit this sort of pattern. so if you know of other ways to tirgger the problem, make sure you detail how you are able to trigger those other cases.

[sbushes]

@pisum

to clarify, i don’t think anyone is claiming it’s not a bug, nor that it shouldn’t be fixed.

ok, a misunderstanding

@pisum

• user explicitly reorders the observation cards
• user adds an observation card before another existing observation card
• user duplicates an observation card that is not the last observation card. this will add an observation card that appears visually after the duplicated observation card (and before another existing observation card).

yes, these variations may well cover it

[nickybay]

Please fill out the following sections to the best of your ability, it will help us investigate bugs if we have this information at the outset. Screenshots are especially helpful, so please provide those if you can.

Platform (Android, iOS, Website): Website

App version number, if a mobile app issue (shown under Settings or About):

Browser, if a website issue (Firefox, Chrome, etc) : Chrome

URLs (aka web addresses) of any relevant observations or pages: https://www.inaturalist.org/observations/upload

Screenshots of what you are seeing (instructions for taking a screenshot on computers and mobile devices: https://www.take-a-screenshot.org/):

Description of problem (please provide a set of steps we can use to replicate the issue, and make as many as you need.):

Step 1: Click Upload

Step 2: Drag a few photos in to create a few observations (5 will suffice)

Step 3: Drag to re-order the observations in random

Step 4: Click any observation (A)

Step 5: Hold-SHIFT and click another observation (B)

Example (not same as screenshot)
1 2 3 4 5
after re-ordering
3 1 2 5 4
Click on 3 then shift-click 5. You will see 3 4 5 selected instead of 3 1 2 5.

Normally it should select the range of observations from A to B based on the new re-ordered list. However, it currently selects the range based on the old sequence prior to re-ordering. This sometimes leads to the accidental overwriting of species identifications in the batch when not paying attention to the observations selected.

[pisum]

this is the same as https://forum.inaturalist.org/t/group-selection-quirks-in-upload-interface/14700

[tiwane]

Added the above two posts to this existing bug report.

I can replicate @nickybay’s bug and have made a github issue here. For what it’s worth, drawing a selection rectangle doesn’t seem to be affected by this.

[pisum]

i think this is fixed. seems like this and a few other recent code changes were done by non-staff folks. it’s nice that other folks are helping out in this way.

[tiwane]

@nickybay @sbushes how’s it working for you now?

[tiwane]

I’m setting this to close tomorrow. Please ask us to reopen if you’re still experiencing the issue.