Jump to content

Community Wishlist Survey 2021/Multimedia and Commons/Flickr-like uploader

From Meta, a Wikimedia project coordination wiki

Flickr-like uploader

  • Problem: Many people in the community would like to upload images on Commons, but they don't wan't to, because they say how complicated it is. Adding description, captions, categories, licences and all those things is a pain. Especially for new users who just want to choose a folder and upload. Skilled Commons users can use Vicuna, Pattypan or something similar, but we are still missing and easy and well working option. We don't have to re-invent the wheel – Flickr has the wheel! We should just mimic what they have. Choose a folder, add all the data in an environment similar to a folder in a computer, do the upload WHILE the stuff is being described and just confirm it by the Upload button. So simple, so efficient and proven to work.
  • Who would benefit: Especially newbies but all Commons users
  • Proposed solution: Creation of a better description of how the tool should be designed and eventually designing and making the tool working.
  • More comments: Note: I've submitted a similiar proposal before. I still believe the community would benefit from this. Lack of such a tool still represents a major bottleneck in better metrics results in many projects we have. The concept of such an uploader would differ from Upload Wizzard – the interface would have to be completely reshuffled and many things must be done automatically.
  • Phabricator tickets:
  • Proposer: Aktron (talk) 10:43, 17 November 2020 (UTC)[reply]

Discussion

  • How would you add categories to those files? Are they coming with the folder? JopkeB (talk) 16:33, 17 November 2020 (UTC)[reply]
    • Simple: A filename will be above the icon of the image, description/caption below and category will be below the description. I believe this would work fine with many user cases. Aktron (talk) 15:13, 21 November 2020 (UTC)[reply]
  • When I upload all pictures of my "DCIM" folder, what do you think should be the caption of each file? What depictions/categories should they have? Surely a generic caption and zero depiction is not a great idea, right? Syced (talk) 13:53, 18 November 2020 (UTC)[reply]
    • The user should have an option to write a custom caption/description for each file. This is ok if we do maximum accessibility – just like in Flickr you click below an image and directly input the data. No need to load pages, scroll or anything similar. This is what we should do. Aktron (talk) 15:13, 21 November 2020 (UTC)[reply]
  • What would be the use of thousands of images with no categories and no description? How would one ever find them (without browsing through the uploader's contribs)? However, I agree that adding those new captions is a pain. PiotrekDTALK 15:45, 19 November 2020 (UTC)[reply]
    • The reason why we have thousands of images with no categories or description is that our tools fail to be easy to use so people can use them to add the data. Adding a description by editing each PAGE of the images is utterly slow. This tool was intened to help this, but it was still limited. So we first need a tool that will allow everyone to easily add caption/description/category to an image or a batch of images. The Flickr uploader is tested and works well, the concept I believe can be easily applied here. Disallowing empty values for caption/description/categories will simply guarantee that we wouldn't have files with no descrition. And we should work with coordinates in a much better way in the future too! Wikishootme is a good start, but let's go further! Aktron (talk) 15:13, 21 November 2020 (UTC)[reply]
  • I agree. I decided not to provide images any longer to commons because meanwihle it takes me up to 30 minutes to upload a picture (searching for the right categories, addings structured data, creating WD object and linking it...), although I still have thousands of usable images. But this is complex process with many single solutions and does need more than just one request. Many single solutions could help in the future. E.g. a feature that scans the EXIF keywords and suggests categories or a feature that processes the location and time EXIF data and puts it in these time categories "photographs of Germany taken on..." or these lens and camera and aperture categories (including structured data). And finally thinking of introducing tags as well what makes searching easier. -- DerFussi 09:18, 20 November 2020 (UTC)[reply]
    • I believe the future is when we the Commons will pre-load GPS coordinates from the images and ask you: "This image is within the shapefile: Arc de Triomphe, Paris. Does the image depict it?" And you will click yes and all the data will be added from Wikidata or somewhere else :-) Aktron (talk) 15:13, 21 November 2020 (UTC)[reply]
      • @Aktron: Its just a bit of help. To be honest - frankly spoken, a wiki is the very last kind of software that should be used as a media repository. The whole commons wiki should be thrown into a garbage can and replaced by a new suitable media repository software. Actually I am curious how many hours and live times the users spent for creating categories by hand (and reorganising them later) and how many hours uploaders spent to find the all suitable categories for a picture (and nobody will find them all), although a handful of keywords/tags in the EXIF data have all the necessary information. I am aware, that we all have to live with that short-sighted decision to use a wiki for commons. But some AI may help in the future to suggest suitable categories after sanning EXIF data (location, coordinates and keywords). -- DerFussi 22:10, 21 November 2020 (UTC)[reply]
        • Yeah, but Wiki for image repository is kinda like a QWERTY keyboard. The idea is utterly impractical and outdated and yet so many people use it that despite the utter impracticality everyone does it. Aktron (talk) 22:46, 21 November 2020 (UTC)[reply]
    • “[…] addings structured data, creating WD object and linking it […]” – I find these WD-related parts annoying as well. Actually, what is the point of them? IMO the uploader was better in '17 when there were no fancy “features” like that (if memory serves). Regards, PiotrekDTALK 11:15, 24 November 2020 (UTC)[reply]
      • They do have a sense but adding them manually just doesn't work. We have made a perfect brick but now we need a perfect machine for laying bricks. Nobody builds a huge structure by laying brick by brick by hand. Aktron (talk) 18:11, 24 November 2020 (UTC)[reply]
        • Enter the Captain: laying bricks by hand is the only reliable way to lay bricks. Humans tackled the issue of mechanized bricklaying for the past two hundred years, at least, and each time they failed. To eliminate bricklayers, one has to replace bricks with something else. Back to our "bricks", the problem is that only the uploader can describe the contents of the upload. AI systems can sometimes help, but not in the case of original, never-published material (think of the only existing photo of someone's great-great-grandmother...). So, even in foreseeable future, the uploader has to provide meaningful descriptions, typing with their fingers. If it doesn't work now (I know it doesn't, I'm fixing the backlogs at a snail's pace...), it has nothing to do with the "complexity" of the upload form, and it won't work with any alternative upload protocol. Retired electrician (talk) 19:20, 15 December 2020 (UTC)[reply]
  • I agree. The upload-form is kindof dumb in an annoying way.It does not, but it should support drag and drop and /or point to files in the local image browser. The current method keeps loosing the spot in the local browser if the folder has hundreds of images to pick in a manually selected order of appearance by batches of a few in time. Found out i can drop them on the button. The upload form should remember my only few used languages and have their formfields open and prepared to fill in right away. Now it asks the uploader over and over again which out of hundreds of languages we want to use. At least create a shorlist for this in user prefrences, so language can be picked by typing 1 single letter. (Parts of) carefully crafted titles could be re-used and preproposed as captions, as descriptions and as Data, even as proposed categories. Let users pick and save their preferred upload templates (single file, batch, series, homogenous, misc.) Add buttons troughout the form to copy info from one to the next the file in sequence, not just info from file 1 to all others. Make an opt-out button for reloading page for last step (DATA) or possibly integrate a smarter version (using parts of the already provided info) in the upload form as an optional formfield. Upload form could remember a shortlist of last used categories. Upload form could remember and display till the end of the process, in grey or italics, the old (local) filename for further reference when moving local 'done' files to local 'done' folders, or tagging them alike. Pelikana (talk) 13:07, 20 November 2020 (UTC) Yes, agree ... time could be saved by being able to edit descriptions etc. while the uploads are being done in the background. Pelikana (talk) 16:04, 22 November 2020 (UTC)[reply]
    @Pelikana Drag and drop upload will soon be improved by T47656. ESanders (WMF) (talk) 18:37, 2 December 2020 (UTC)[reply]
    I feel neglected because the upload form has never asked me "which out of hundreds of languages we want to use". It's always in plain English. Why such difference in treatment? Retired electrician (talk) 19:26, 15 December 2020 (UTC)[reply]
    I meant picking the extra especially the 3rd languages for the captions and descriptions is a pain. Say: I want to upload a batch of 10 heterogeneous images and I want to add 2 extra languages for each file description, than I will have to click and pick or type at least 60 times for these 2 extra languages within this short session (unlike the captions that remember my choises). Picking the 3rd language is a 3-click process. So let us select the Constants Caption Languages and Description Languages centrally, in preferences, or at least at the top of the form and apply that choice to all files. Don't treat this choice as a variable, because it's actually a lifelong constant. Don't confront us a n-thousand times in this UploadWizzard with language options that we will never ever pick. Peli (talk) 04:07, 16 December 2020 (UTC)[reply]
What about the bug: the form tells me that I'm already uploading the file? This erroneous error message pops up every time when I stay on the site an click 'Upload More Images' to do next batch - unless I do a reload of the empty form page first by pressing F5. Can this be investigated please? Peli (talk) 14:44, 16 December 2020 (UTC)[reply]
It appears that you're using the unfortunate "upload wizard" in place of the regular, wikitext-based upload form. No triple-clicks required there, which probably explains its longevity. Just type in double-character language codes as you would in a wikipedia article or talk page. Retired electrician (talk) 20:44, 16 December 2020 (UTC)[reply]
  • Seems like a reasonable proposal that would entice me more to start uploading images as well. --Ivario (talk) 22:23, 24 November 2020 (UTC)[reply]
  • Problems to address: let's please focus on specific problems that make uploading so slow and painful. Copying the fields entered helps, but maybe there should be an option to copy down to any below the current image. Uploading from Flickr should allow you to see more files, and upload from a photostream over just an album. Copyright statuses should be able to be copied; right now they cannot. Errors uploading need to be clearly stated, either easily found or searchable, perhaps by saying "Error: XYZ". Right now, finding the error preventing your upload of 200+ files is painstaking. There's other problems beyond just these... (talk) 04:22, 7 December 2020 (UTC)[reply]

Voting
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/Multimedia_and_Commons/Flickr-like_uploader
meta.wikimedia.org
CC-MAIN-2024-33
187939
application/http; msgtype=response
sha1:TUHHVEMZERSJ4Z4PJVY3YK6NSZUAWFLV
<urn:uuid:1e509107-1fda-4e42-8c11-90f1b5dc97f8>
2024-08-16T04:54:25Z
208.80.154.224
text/html
sha1:7WVEKOP5TWRS6MKGBNK7X7QMHN7AQJKO
<urn:uuid:1497c88e-88b4-409d-b2b1-280ce8968a21>
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/Multimedia_and_Commons/Flickr-like_uploader
response
<urn:uuid:d52a345a-e99a-4119-95cf-874f4ce7717d>
isPartOf: CC-MAIN-2024-33
publisher: Common Crawl
description: Wide crawl of the web for August 2024
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-44
software: Apache Nutch 1.20 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.5-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/