This feature seems like it requires a large amount of behind-the-scenes work for the value it delivers to the user: the global "feed" of images may be constantly changing, which means a user's place within the stack of images is not going to remain constant and may need to be re-calculated every time they change tabs (or even in the background as they work, since other users will presumably be using this tool simultaneously). I'd argue that this feature is not essential at all (or if it is included, is something that should be limited to the "personal" feed).

In the interest of sticking to our target release date, I think we should put this task on the back burner and return to it post-launch.

Per discussion today:

• We'll only do x of y for the user's personal uploads

• we'll move that UI element to the Uploads tab itself, not the top level area.

I played with a few different options, and after talking with @AnneT, we believe the best option is the 1st one because it's the most clear and will work the best on a variety of screen widths.

[I will update this ticket tomorrow morning since my uploads keep failing!]

My image uploads keep failing. In leu of uploading, here are some dropbox links:

Including the image count with the filename heading (our chosen treatment): https://www.dropbox.com/s/e69g9mgpkobxusi/image%20count%20in%20filename.png?dl=0

Other treatments we considered:

• Centered between the tab and the image card (Visibility was nice, but it pushed the image card down): https://www.dropbox.com/s/8vflx1wmx3ktexe/centered%20image%20count.png?dl=0
• Below the image card (Not visible enough): https://www.dropbox.com/s/ob8x4f2zdzrbvy7/image%20count%20below%20card.png?dl=0

Unfortunately, I've run into some more issues while building this out.

Originally, we planned to keep the total number of images constant (so if 32 personal upload images exist, the Y value in "Image X of Y" would always be 32, then we would increase the X value each time an image is skipped or tagged. With this model, if you get to image 10 of 32, on the next skip or publish, a new batch of 10 would load and the first one you see would be image 11 of 32.

However, this only really works if a user is publishing tags for every image, in order. If they skip any images it breaks down pretty quickly.

Take the example of a user with 4 personal uploads. Say they skip images 1 and 2, publish tags for 3, and skip 4. After skipping 4, the query would run again and would return the 3 skipped images. With the current way things are set up, these images would be numbered:

Image 5 of 4
Image 6 of 4
Image 7 of 4

Now, we could reset the index when we get to the final batch of images to get 1 of 4, 2 of 4, and 3 of 4, but this is still confusing because there is no 4 of 4.

Basically, I don't see any way of really achieving something that makes sense unless we, on each fetch, update the number of images and the index numbers. So, in the case of 4 images:

First fetch:

• Image 1 of 4 - skipped
• Image 2 of 4 - skipped
• Image 3 of 4 - tags published
• Image 4 of 4 - skipped

Second fetch:

• Image 1 of 3
• Image 2 of 3
• Image 3 of 3

The question is: do these numbers make sense to or help the user? The index resetting with each fetch seems confusing to me.

One solution: only show the total number of images remaining. I've got this working locally:

Any time the user publishes tags for a personal upload, the number would change. We could, of course, adjust the design.

Pam, let me know what you think, or we can discuss at the CAT meeting tomorrow!

@AnneT -- I like it. This is the simplest solution! I may want to fiddle with the typography (not sure yet what size/weight is needed here) but let's go with this approach!

Change 545641 had a related patch set uploaded (by Anne Tomasevich; owner: Anne Tomasevich):
[mediawiki/extensions/MachineVision@master] Show number of user uploads to be reviewed

https://gerrit.wikimedia.org/r/545641

Change 545641 merged by jenkins-bot:
[mediawiki/extensions/MachineVision@master] Show number of user uploads to be reviewed

https://gerrit.wikimedia.org/r/545641