commons-app
UX Flow is inverted, we should consider matching to wikidata and wikicommons before titling and tagging images.
What is the user problem or growth opportunity you want to see solved?
This is a high level issue. But I hope it gives pause and starts conversations.
Currently the flow is,
- Select pictures.
- Add title.
- Add description.
- Search for thing on Wikidata (which treats the upload as a batch)
- Search for category on Wiki Commons. (which treats the upload as a batch)
As both a user, and developer it occurs to me this is entirely backwards. I propose we invert this.
- Describe batch:
- Search on Wikidata.
- Resolve errors on linkage to commons galleries if needed.
- Add pictures.
- QA titles and descriptions on each pictures.
Downsides to current flow.
More complex to program.
- The resolution attempts happen per-picture, ignoring the fact that the user may have batched them meaningfully.
- Errors in wikidata-wikicommons linking result in problems which may not be discovered until much later. For example, there are two links for Wikidata to Wikicommons the
{{Wikidata Infobox}}uses the multi-site links at the bottom of Wikidata. While this mobile app uses theWikicommons Categorylink in Wikidata. Putting off the linking until the end means we delay catching errors and make less use of associated data. Handling these later creates all kinds of problems.
But it's also more complex on the user.
- If you add only the multisite link and not statement, this app will fail to link to the commons category. And if you fix that problem on your desktop you can't go back and hit a refresh button on the app or the like. You cought the error too late. You have to scrap the batch, and start all over or manually add the pictures to categories after they're uploaded -- which causes bots to pounce and flag for delete the pictures because they lack a category.
- Sometimes I type in title, but the title and location doesn't resolve (perhaps because I'm not waiting long enough). I can't catch whether or not I've encountered this problem until after I've titled and described my pictures.
- One such annoyance for users is "Copy to subsequent pictures" does not copy to the pictures before. This is awkward, because uploading a batch is order-specific on batch selection. If I batch the outside pictures before the inside pictures of a place, there is a chance geolocating works and the item is properly identified. Otherwise, I may hit "Next" until I get a location with the proper coordinates which can match and then my only option is to copy the description for subsequent pictures.
This flow also means we miss out on lots of features and capabilities.
For example, if the batch was tied to a Wikidata item and Commons gallery before hand then we could expand the batch with the options.
- Replace
image(et al) link on Wikidata. Remember there is not just image links on Wikidata. There are also links toplaques(P1801)views(P8517) and alsointerior views(P5775). - Because we already have a primary category. We can see what the parent-categories of that one are and resolve whether or not the Wikidata entries for that are filed out to the same degree and if not, offer the ability to use the image there too.
- We can offer the ability to replace a prior image, or mark it as a duplicate if you're uploading a higher resolution or better quality image. Perhaps restricting this functionality to images you've uploaded.
- Speaking only for myself, 99% of what I populate are Categories that I've created. It would be tremendously helpful if in the resolution step I could do an unachored search amongst categories I've created, or that I've edited. "Even if just preset to the last 1,000 distinct categories edited or created." This would save me from having to disambiguate.
- Because we have the primary catagory, we can give users the ability to secondary categories on a per-image basis. This is better because we can use these secondary categories to generate titles and descriptions. For example, category is Trees in Houston, secondary category is Park benches in Houston. We could easily implement logic to generate a default title of "Pictures represents a Tree and Park Bench in Houston." Giving us a better default description and accurate linking with less work on the user.
How do you know that this problem exists today? Why is this important?
I believe this app is TREMENDOUSLY useful, but suffers from one minor bad design decision. I just wanted to raise this to see if others felt the same way.
Who will benefit from it?
Everyone.
Anything else you would like to add?
Perhaps this is something we can set for a new major release?
Thanks for the great ideas! I am digesting all of this and will come back to you once my thoughts are in order. :-)
If any of this you would like screen caps of please tell me. I'm happy to supplement any of the claims made above. I really hate the one where it doesn't find the pictures, and then I search for the entry as I just typed it -- it finds that. And it finds the associated category. But the problem is the pictures still get uploaded with the old title and description. Here is an example. The sheer quantity of pictures I upload mean I can't typically provide descriptions (I know that sounds bad, but I probably create 5-10 categories a week).
https://commons.wikimedia.org/wiki/Category:Dean_Neubek_Critter_Classroom
I really hate the one where it doesn't find the pictures, and then I search for the entry as I just typed it -- it finds that. And it finds the associated category. But the problem is the pictures still get uploaded with the old title and description
Would you mind posting a screencast of that? Thanks!
Sure I'll provide a view videos.
In this one I show the matching after the fact doesn't update the descriptions. Here are the ones uploaded (the newer ones in this category anyway). https://commons.wikimedia.org/wiki/Category:Heron_Lake_lookout
It doesn't find it by typing in the name, it only finds it when you search at the end.
https://github.com/user-attachments/assets/d93aa87a-016e-4383-95ee-a259aaec0837
And here is the video you requested, where it automagically suggests based on the geoinformation when uploading a batch a suggestion based on data in wikidata, but only for that picture and subsequent picutres. If you accept the suggestion even after copying to subsequent images the prior image do not get updated. This makes a "batch" upload order specific. You need to put the ones that are most central to the geolocated point of the attribute first.
https://github.com/user-attachments/assets/820fecaa-1f1b-4368-96ff-5a94ad335f0f
I just want to be clear, I think you could fix these bugs without front-loading the association to wikidata and wikicommons the point here is to show that,
- we can make these bugs impossible.
- we can get more functionality.
- we can provide a better UX.
By inverting the UX.
@nicolas-raoul here is another one of the subsequent bug not working on prior pictures.
https://github.com/user-attachments/assets/6f515777-e69b-4ad6-8bed-c2173d42cb27
Thanks a lot for the videos, very clear! And sorry for the long delay, I kept thinking about this and what would be the best implementation.
How about this workflow:
- Let the user select the pictures, as currently
- Extract the location of all of the pictures, and based on that, show the depictions selection activity with geographically close items suggested.
- Similarly show the categories depictions activity.
- After that, let the user modify the captions/descriptions (prefilled with the first selected depiction's label, or first selected category if no depiction was selected).
- Finally, if some of the selected items do not have a P18/P1801/etc but should have one, or some parent items do not have a P18, ask for each such property whether any of the pictures to upload would be a good choice.
Also, allow the user to initiate an upload from a Wikidata item or category (reached from either Explore or Media Details or Bookmarks). For instance, when exploring the category "Dogs in Guana", tapping the proposed "Upload in this category" button would pre-select "Dogs in Ghana" as a category for the pictures that I select.
Pre-filling works great using depictions, I hope it is also useful when using categories. In the example above, I might have to remove the "s" from "Dogs" if there was only one. Including secondary items/categories could be even trickier, for instance did I upload "Dog in doghouse" or "Dog besides doghouse"? If anyone can find other edge cases please comment, thanks! In a first phase I would recommend prefilling without secondary items/categories.
We have to be cautious about replacing P18s, and also at least reserve it to veteran users. The philosophy of the app is to encourage users to upload pictures of non-represented items. Uploading a better version of an existing picture is good, but secondary. I would suggest keeping that for a subsequent iteration.
In any case, let's keep in mind that this would be a very significant undertaking, so finding a volunteer willing to implement it might take years. But the better we specify how it should work, the better.
About the way we find a category for a Wikidata item: Interesting, I think we should suggest all and let the user choose. Would you mind creating a new enhancement request about this?
About searching "categories I created": Can you create a separate issue about it? I think it can be implemented without waiting for the UX redesign. It could be a checkbox in the 3-dots menu of the category selection activity.
Also, allow the user to initiate an upload from a Wikidata item or category (reached from either Explore or Media Details or Bookmarks). For instance, when exploring the category "Dogs in Guana", tapping the proposed "Upload in this category" button would pre-select "Dogs in Ghana" as a category for the pictures that I select.
That would work, that's the only flow I would use and that would solve all my issues.
@EvanCarroll You should follow https://github.com/commons-app/apps-android-commons/issues/1691 :-)