Wikipedia talk:File upload wizard/Archive 1

Archive 1

Archive 2

Archive 3

→

Archive 5

So, what's this?

This is a draft of an experimental new file upload wizard that I believe might improve our uploading process, especially for newcomers (who typically don't understand the present system, at all.)

I now need to get some Javascript written that will do the following things:

• On loading the page, substitute actual HTML form code (text boxes, textareas, radiobuttons and checkbuttons) for the various placeholder elements (each now marked <span id="placeholder..."> in the wikicode).
• Add event handlers that will switch visibility of the different alternative question sets in "Step 4" in response to the user's choices among the radio buttons of "Step 3". Each type of file thus gets its own, tailor-made input questionnaire, including specific questions about sourcing, evidence of permissions, and NFCC rationales.
• Add some evaluation code to check that all necessary fields are filled properly. Should also check for overly short or generic file names, filenames that are already taken, and so on.
• Add a submit event handler that will assemble the user input into a string of wikitext for the image description page, sends a http PUT query to the MediaWiki API, notifies the user of success or lack of success, and redirects the user to the finished file page. Apparently this has to be done through Ajax (programming), similar to the way Twinkle does it.

Damn. I'm crap at writing Javascript. Any help welcome. Fut.Perf. ☼ 23:25, 14 January 2012 (UTC)

Update

So, let's say this is now in alpha stage.

• The basic functionality is there. It can actually upload stuff. The dialog mechanism that takes the user through the different options should be working.
• Validating filenames, checking for files that already exist: working for me now.
• Validating article links given for NF files, checking for non-existing targets, non-mainspace targets, redirects and dab pages: working for me.
• Still missing / to be written:
  • response after successful upload
  • option to enter manual edit summary (must be obligatory for uploads overwriting existing files)
  • possibly a mechanism of choosing between different modes for different users. The script could try to figure out if the user is a newcomer or experienced editor, and provide closer or more relaxed guidance accordingly
  • a slightly modified fair-use rationale template with some extra fields to accommodate the input generated by the script

Some of the workflow also needs to be reviewed. I'm not sure about the whole "work type" section being put in front of the free file options. On the one hand, it's important to catch these misunderstandings (e.g. a screenshot from television is "my own work"), but on the other hand the presence of the many dead ends in that part of the wizard may come across as confusing.

Fut.Perf. ☼ 01:51, 3 February 2012 (UTC)

Comment on Section 3

Rather than refer to "Fair Use" wouldn't it be better to refer to Wikipedia's non-free content criteria? So: ...but I believe it meets all of Wikipedia's non-free content criteria.  – ukexpat (talk) 16:38, 3 February 2012 (UTC)

My first test

Tried a text but the licence I chose a cc attribution licence did not come through on the sandbox page. It showed "undefined". Otherwise I like the concept of making the upload more friendly yet more exact, so copyvios cannot be so easily uploaded or information left out. Good work. ww2censor (talk) 16:51, 9 February 2012 (UTC)

Silly bug, thanks for spotting. I think I fixed it. Can you try again? Fut.Perf. ☼ 17:30, 9 February 2012 (UTC)

Nope, still shows "undefined" after choosing a proper licence. ww2censor (talk) 17:38, 9 February 2012 (UTC)

Tried purging your browser cache? I think one also needs to purge it explicitly on the "withJS=" url, not just on the normal page reload. It's working for me now. Fut.Perf. ☼ 17:41, 9 February 2012 (UTC)

It works now. One suggestion might be to let uploaders know they can make wikilinks in their descriptions. Looks good otherwise. ww2censor (talk) 22:35, 9 February 2012 (UTC)

Seems broken

When I click on "Start the Upload Form", it does not start the Upload form; the "Start the Upload Form" link disappears, but it stays on the same page. —teb728 t c 08:19, 10 February 2012 (UTC)

Ouch. It is in fact supposed to stay on the same page, but it should be showing the previously hidden form questionnaire by that point. Maybe a browser compatibility issue I had no idea of. Could you tell me what browser you are using? Fut.Perf. ☼ 08:27, 10 February 2012 (UTC)

I've tried a bugfix. Could you purge your browser cache on [1] and tell me if it is working for you now? Fut.Perf. ☼ 08:41, 10 February 2012 (UTC)

Still the same. I use IE9 on Win7. My firewall is ZoneAlarm Security Suite. I sometimes trip on blocked 3rd party cookies; do you use any of those? —teb728 t c 10:32, 10 February 2012 (UTC)

:-( No, the script uses nothing of the sort. The only explanation I have is that the code I used to switch an element from invisible to visible isn't working for your browser. Because the rest of the script was apparently working for you. Must be a very trivial thing. I was previously using "element.style.display = null", which works on Firefox (has the effect of setting the display attribute back to default, i.e. visible). I now tried changing the code to the jQuery wrapper "$(element).show()". Are you sure both the script page (MediaWiki:UploadScriptDemo.js) and the wizard page itself were properly cache-purged for you when you tried it again? Fut.Perf. ☼ 10:46, 10 February 2012 (UTC)

I don't have this issue with Firefox 9.0.1 for Mac but will try some other browsers to see if I can recreate this problem for you on a Mac. ww2censor (talk) 11:22, 10 February 2012 (UTC)

OK, so I found the same issue with only on browser: OmniWeb 5.11 but the page just stays the same with the link visible. All other browsers, Safari, Opera, SeaMonkey, Camino,Google Chrome and iCab worked fine to bring up the form. I did not test any further. ww2censor (talk) 11:54, 10 February 2012 (UTC)

Thanks for this. The issue in OmniWeb must be a different one. Turns out OmniWeb may be one of the few browsers that still don't support the "getElementById()" function. Maybe I'll have to write a workaround for that? Fut.Perf. ☼ 12:09, 10 February 2012 (UTC)

I've replaced all calls to getElementById with something from jQuery, which I hope should be valid across browsers. Fut.Perf. ☼ 12:35, 10 February 2012 (UTC)

Yeah! It works for me now. —teb728 t c 18:40, 10 February 2012 (UTC)

teb728 tests

Looking at the non-free section:

• "The file will serve an important function in an article": The important function has to be reader understanding.
• At first I tried to skip over the article name, and I was surprised that the buttons in the rationale section were inactive. If you are going to make them inactive, maybe don't display the rationale section until there is an article name.

—teb728 t c 19:11, 10 February 2012 (UTC)

Will change the thing with the disabled controls; good point. That was a leftover from an earlier stage where I had the system make much more use of that, trying to force the user to do things in a specific order, but then I felt it was not very user-friendly that way. – As for the wording of the NFC notice, I was trying to find an "in-a-nutshell" formulation that gets the central idea across in as few and as simple words as possible. The "important function in an article" is actually meant to hint not just at NFCC#8, but also #5, 6 and 9. Fut.Perf. ☼ 11:36, 11 February 2012 (UTC)

Oh, by the way, just in case it wasn't clear: everybody please do feel free to edit the questionnaire if you have a good idea about improving the wording. I protected the page against likely vandalism, but it's still a wiki after all :-) You will find that almost all the text of the questionnaire is actually simple wikitext hidden in Wikipedia:File Upload Wizard. Just be careful not to mess up the nesting tables code, because it's a bit messy. Fut.Perf. ☼ 11:46, 11 February 2012 (UTC)

Some statistics

Just as a background for possible later testing: here's the sad statistics of the dysfunctionality of our current upload system. I took a sample of 1,000 file uploads from 1,000 different uploaders during January 2012. 37% of these files had been deleted by mid-February (plus a few more still being nominated). 26% of all files were deleted for licensing/copyvio issues (per PUF or speedy for bad license, lack of info, lack of evidence or obvious copyvio). 17% of all files had obviously bad description pages at the time they were deleted or first edited by somebody other than the uploader (either completely blank, or with preloaded standard templates but crucial fields or all fields left blank).

For new uploaders, the figures are dramatically worse: almost 70% deletions, 57% licensing/copyvio deletions, 38% bad description pages.

Just so we have a benchmark against which to compare stuff, in case we get to test the new system on real newcomers some time. Fut.Perf. ☼ 23:41, 10 February 2012 (UTC)

	user contribs before upload			total
	<30	<100	>=100
total uploads (January 2012)				14,310
total new files (January 2012)				10,623
total in sample	205	200	595	1,000
survived	48	89	443	580
deleted	143	100	128	371
other outcomes	14	11	24	49
% deleted	69.8	50.0	21.5	37.1
copyvio/licensing deletions	116	81	66	263
% licensing deletions	56.6	40.5	11.1	26.3
NFC speedies	10	4	17	31
other deletions	17	15	45	77
tagged for deletion	80	67	101	248
completely blank description page	53	34	18	105
blank template	24	18	27	69
%incomplete/blank description	37.6	26.0	7.6	17.4

Browser locked up solid

I don't knoiw what you did recently but when I clicked on the upload button I got a message about could not move something and my whole browser locked up solid, so I had to force quit the browser and did not try again. I'm using Firefox Mac v 10.0.2. Cheers ww2censor (talk) 12:20, 20 February 2012 (UTC)

Oops. Sorry about that. I'm doing some testing with a local copy of the script right now and made a few changes to the page to match the changes in the local script. Should be back to normal soon. Fut.Perf. ☼ 12:36, 20 February 2012 (UTC)

Will check again sometime later. ww2censor (talk) 13:58, 20 February 2012 (UTC)

Now I can't choose a file as there is no browse button or field to type a file name, but browser does not lock up on me. Perhaps this last edit caused it as that seems to be the choose a file section code. ww2censor (talk) 16:49, 21 February 2012 (UTC)

Grrrhhrrrhhmph :-(. But I think this time it's just another browser cache issue. Please make sure you purge your browser cache not just on the wikipage itself, but on the wikipage as loaded through the "start the wizard" link, i.e. with the "withJS" parameter. This is happening because the version of the script your browser is using is out of sync with the current page. Sorry for the trouble. Fut.Perf. ☼ 16:56, 21 February 2012 (UTC)

BTW, I made that change in order to have identical "id" and "name" parameters on the file input element, having read that there might be problems otherwise. Though I have to say it didn't solve the compatibility problems with IE I'm having. Fut.Perf. ☼ 16:57, 21 February 2012 (UTC)

I uploaded File:Stamp Irl-USA sept 39 censorHS.jpg but because the template I was using is a redlink on this wiki I used the commons upload button and besides refining a few bits it worked out pretty fine. ww2censor (talk) 17:22, 21 February 2012 (UTC)

Thanks for confirming this! The send-to-commons functionality ought to be pretty safe, technically, except for possible incompatibilities between licensing tags (but all the ones standardly used by this wizard ought to be present on Commons, at least). What I'm still mostly concerned about is the actual local uploading code and how compatible it is across browsers. I somehow couldn't get it to work on IE8 today, and have no idea why. The form.submit() mechanism apparently just didn't send the file data. Fut.Perf. ☼ 17:37, 21 February 2012 (UTC)

I do not like it

As it is now the notice about Commons is very small and you get the notice to late. I think the number of free files uploaded to en-wiki instead of to Commons will be much bigger with the new version.

If the photo is free then uploader should be forwarded to Commons unless they specificly chooses "No I do not want the file on Commons" and if they choose that they should be send to a manual upload page. It should be much easier for users to upload free files on Commons than on en-wiki so we should not make the upload of free files on en-wiki easy. --MGA73 (talk) 17:47, 24 February 2012 (UTC)

Well, if you want A to be easier than B, then I guess the best solution is to make A as easy as possible, but not to make B artificially difficult. And sending people to a manual upload page would go counter to the primary purpose of this whole thing, which is: avoiding copyvios and poorly described files. I really think that is the first and foremost priority about what needs to be fixed about our upload process. The issue of choosing between local and Commons uploads really doesn't come anywhere near it. Fut.Perf. ☼ 17:53, 24 February 2012 (UTC)

Commons was easier untill the upload wizard was copied to en-wiki. How are we going to make A easier than B if all improvements on A is copied to B?

And the old upload form had very big notices about Commons. They are now almost invisible. I think that only unfree files should be uploaded to en-wiki so I do think that it is a relevant issue to discuss. We could for example remove the option to upload free files with the upload wizard. --MGA73 (talk) 17:58, 24 February 2012 (UTC)

Sorry, but I'd be very strongly opposed to that. Under the old system, with its huge notices, were were getting massive numbers both of free files "falsely" uploaded here, and of allegedly free files that were copyvios. First priority is to reduce the copyvios; second priority is to reduce the local files. The old system failed to achieve either; that much is certain. Fut.Perf. ☼ 18:01, 24 February 2012 (UTC)

There are two problems. 1) Users that do not understand the system and 2) users that are trying to cheat. Both systems will fail option 2. What we can do to help users in category 1 is to ask uploader a few questions before they get to the upload wizard. If the file seem to be free then we could send them to Commons. If the file is not free then users should be told not to upload it or to upload it as fair use and then send them to the upload wizard. --MGA73 (talk) 18:22, 24 February 2012 (UTC)

Not sure I get what you're saying. "Ask the uploader a few questions"? But that's exactly what the wizard does. Sending them through one wizard first just in order to let them enter the real wizard afterwards? That doesn't sound very useful. Fut.Perf. ☼ 18:31, 24 February 2012 (UTC)

(ec) Maybe to put your mind to rest a bit: this thing has now been online for about two hours. During this time, only two images marked as free have been uploaded through it (one a copyvio, one apparently legit). That's a pretty low rate. Of course we don't know how many uploaders came here and decided not to upload, and why (realized it wasn't legit? went to Commons instead? Didn't understand the form and gave up?) But if this first impression is representative, then perhaps the system is actually more successful at avoiding unwanted uploads than you'd have thought. – One thing we might do to get better data, but I'm not sure if there'd be consensus for that, is this: when the user presses the "go to Commons" link, it could cause their account to first automatically make a log edit somewhere, registering the intended filename, so we could track how many people actually went to Commons from here. I'm just not sure if that would be okay, "ethically", because it would mean making an automated edit that the user didn't explicitly authorize, through their account. Fut.Perf. ☼ 18:29, 24 February 2012 (UTC)

(ec) Oki. Maybe it is not that bad after all. It turns out that if you click long enough a "Upload to Commons" button appears. That is good.

But I still think that there should be a bigger notice on top with a notice "If you upload free files go to Commons." and "If you want to upload many free files Commons has an upload wizard that makes it easier for you" or something like that.

As for the files found on the Internet there should be a notice about Flickr, Panoramio etc. that they must be uploaded to Commons to get a license review to make sure that they will not be deleted if the Flickr user (etc.) should change the license to one that is unfree.

Anyway I hope that it will work and I do appriciate that someone try to do something to get less copyvios uploaded. So thank you for that. :-) --MGA73 (talk) 18:35, 24 February 2012 (UTC)

Another idea. Once a file is uploaded perhaps 1, 2, 5 or 100 (?) users that check the same file to see if it is ok. But we can't see if a file has been checked unless it has a no source, no permission etc. Perhaps we should implement a review system. That way there is a chance that all files are checked and only checked one time. But that should probably be discussed somewhere else. --MGA73 (talk) 18:52, 24 February 2012 (UTC)

True, that will be useful but it's something that goes for all image uploads, independent of how they're uploaded. By the way, sorry I wasn't aware you hadn't yet noticed the existence of that "Upload-to-Commons" button. It's true it's currently a bit hidden. I should tweak the script so that it makes it visible at an earlier stage, as soon as the "free file" option is chosen. Another idea is that the files that are sent to Commons through that button might get a special tag added to their Commons description, as another tracking method. About the information you suggest to be added, true, all of those things are very useful for an uploader to know. I'm only a bit wary of the danger of information overload. I think that's been one of the big problems of the old system; people tried to cram too much instruction into those pages. I think the issue is to find a good balance and prioritize the information. Fut.Perf. ☼ 19:01, 24 February 2012 (UTC)

What if we were to switch steps 1 and 3 around, so that you don't have to go through steps 1 and 2 to find out, for example, that if your doesn't fit any of the categories above, it doesn't belong. Or that if it is a free file you can upload it to commons. Perhaps the the subsequent parts of step 3 don't belong before choosing the file, but that way at least they don't go through steps 1 and 2 unnecessarily if they decide to upload it to commons, or if it isn't fair use. - SudoGhost 07:18, 25 February 2012 (UTC)

Hmm. I guess switching the order between steps 3 and 1 would be fairly easy. But then, that too might lead a n00b user into blind alleys. For instance, what if they spent a long time sweating over the copyright stuff of Step 3, only to come to Step 1 later to discover that they can't technically upload a file that's not yet on their own computer but only somewhere out on the web? – Splitting Step 3 up into an initial pre-questionnaire to decide between free and non-free status and then the main questionnaire to enter the actual sourcing stuff might be possible but would require quite a bit more rewriting, both of the wikipage and the javascript logic. Also keep in mind that there are several places where a user might discover only while working on the details of the free sourcing/licensing that the piece isn't free after all. About the workflow of when the user should be sent to Commons, there are currently three points: (a) right in the beginning, when they see the entry in the "alternative upload methods" in the navbox (admittedly small); (b) in the middle of the process, after completing steps 1 and 2 and on beginning step 3, when they click the "free work" option; this link will lead them to the Commons Wizard, which means they have to start over but get the most comfortable uploading method available on Commons; (c) at the end, when they have completed the whole questionnaire; this link goes to the plain old upload form on Commons, but preserves the work they have already done about the sourcing. Fut.Perf. ☼ 10:04, 25 February 2012 (UTC)

Regarding the comment above "First priority is to reduce the copyvios; second priority is to reduce the local files. The old system failed to achieve either; that much is certain."

People are going to upload copyvios no matter what wizard we use, and no matter where we shoot people to. This is because a good number of people are stupid don't read or follow basic instructions. Under this system, most of the uploads, both truly free and copyvio, will wind up here. This creates the dual problem of having to deal with copyright violations and having to transfer over the free files (we get between 50 and 100 a day). Instead, we should try to direct all of the images people are claiming to be free over to Commons. Yes, that means that commons will have to deal with the copyvios, however this is actually the ideal solution. This is because Commons has 250 reviewers and 300 admins, all of whom are willing and able to deal with files that aren't as free as they claim to be. Wikipedia has about a dozen users in total, a third of whom are admins, that do file work of any type at all. In short, there are going to be copyvios no matter what we do, we might as well send them to the place where they will actually be found and dealt with. That's Commons, not Wikipedia. Sven Manguard Wha? 18:00, 25 February 2012 (UTC)

It's certainly not my impression that Commons has been more efficient at filtering out copyvios than en-wp, rather the contrary. And after observing the first 24 hours worth of uploads with the new system, it's also certainly not my impression that it is less efficient at persuading people to go to Commons than the old system. Rather the contrary. Fut.Perf. ☼ 18:14, 25 February 2012 (UTC)

Not sure we can judge by what happend the first 24 hours. I bet that we were many users that checked the uploads made in the first hours and tagged with "no whatever" minutes after the file was uploaded if there were a problem. I also think that the Commons drive get many users to check new uploads. Anyway we will know more in a few days when we have seen more uploads. --MGA73 (talk) 21:30, 25 February 2012 (UTC)

I'm reading the logs, obviously, so I'm also including files that have already been deleted in the meantime. On Commons, this can now be used for tracking. Fut.Perf. ☼ 21:35, 25 February 2012 (UTC)

It was suggested above that we do not select the file to upload before we are sure the file is ok. I think that in most of the cases where uploader aborts it is because (s)he finds out that the file is not ok for Wikipedia/Commons and not because it is not stored on her/his pc so swapping sounds ok to me.

As for the notice to get users to upload to Commons we could change the notices to

• Click here if you know the file is free (upload to Commons) [Link to Commons upload form]
• Click here if file is unfree or you are not sure etc. (upload to Wikipedia) [Link to WP upload form]

Then the Commons option is more visible. --MGA73 (talk) 09:24, 26 February 2012 (UTC)

Well, not quite: if the file is non-free, it makes no sense to show them the Commons button at all. This is the one thing where we really cannot give them any choice. Whether it is free or not follows from the initial option button choices while doing Step 3; it's no longer open to choice by the time they are ready to submit. And if they are "not sure" about whether it's free, then they must be told to not upload anything at all but ask at Wikipedia:Media copyright questions first. – About the order of steps, I'll have to think about what changes in the script that would necessitate. Another issue to consider in that respect is those editors who come here not to upload a new file but to overwrite an old one, or indeed who really don't want to upload anything at all but merely to change a description page and haven't yet understood they can simply click "edit" on the file page. These are very frequent cases among newcomers, and for them the early file name selection is important.

Back to the "how to get people to Commons" issue in general, I see the argument as articulated most clearly by Sven Manguard above, but at the same time, I think the same argument can be turned upside down and still make just as much sense. Sven is saying: "people will continue to upload copyvios no matter what we do, so if we can't stop them from doing that, let's at least make sure to send as many of them to Commons as possible". What I'm saying is: "people will continue to upload locally no matter what we do, so if we can't stop them from doing that, let's at least make sure to prevent as many copyvios as possible." Fut.Perf. ☼ 12:02, 26 February 2012 (UTC)

What I meant with the 2 links was that if they are sure it is free they could be send to the upload wizard on Commons at once. If they are not sure they could use the upload wizard on en-wiki and hopefully find out if it is free or not free before they upload (there is a few "stop signs" or warnings in the upload wizard). --MGA73 (talk) 16:43, 27 February 2012 (UTC)

Here's one possible model of how the form could be restructured that might satisfy us both:

1. remove the whole structuring of "Step 1 – Step 2 – Step 3"
2. instead, start out just with the three option buttons that are currently Step 3, with the next logical level below them already visible – i.e. let the user peruse those twelve or so main option types to get a first orientation of what is or isn't possible, and what "free" and "non-free" means.
3. move everything else, including the file selection box and description textfield, into the details form area that opens up when you click on one of those main options.
4. Show the "Why Not Go To Commons?" nag screen, possibly as a popup window, when the user clicks on any of the five free file type options – i.e. at a time when they have already read through the most crucial copyright-related criteria, but haven't yet spent time typing anything in.
5. Keep the "Submit to Commons" button as an alternative way of getting to Commons at the end of the process, as it is now.

How about that? Fut.Perf. ☼ 17:33, 27 February 2012 (UTC)

Not working

Clicked to start and it returned to same page. Used the old form instead.REVUpminster (talk) 21:05, 25 February 2012 (UTC)

Thanks for reporting this. Could you tell me what browser you are using please? Also, was this the first time you visited this page, or had you perhaps loaded it at some earlier date (in the latter case, there might be an issue with an outdated version of the script still being in your server cache.) Sorry about the problem. Fut.Perf. ☼ 21:26, 25 February 2012 (UTC)

• I use windows 7 and Internet explorer 9 or 10 I think and it was the first time this new upload page appeared. I tried again a few minutes ago and it is now working so I had a look at it. I specialise in screenshots of titlecards for infoboxes and cast lists per the manual of style so i am mainly on english wikipedia (I have uploaded a few items to the commons and foreign wikis) and the old form with the non-free rational form provided to fill in was easy to use. This new process looks more complicated but I will give it a go when I come across a new titlecard to upload if this new process survives but I think there will be a lot of complaints.REVUpminster (talk) 07:35, 26 February 2012 (UTC)

Choose your file - finicky?

Using FF 10.0.2 - Needed to "Choose your file" 3x before it "took" - rest of the materials were correct, wasn't picking up that field. Also, at the completion of the upload, the preview image was about 30px X 30px, too small to determine success or not! Skier Dude (talk) 02:49, 26 February 2012 (UTC)

About the sluggish behaviour on picking the file, the only explanation I have is that at that point the script may be making an API request to determine if a file already exists under the chosen name. If you do that step at the end rather than at the beginning, and the API happens to be slow for some reason, then the script will fail to set the submit button enabled immediately. About the thumbnail size, the script uses a fixed width of 120px, which means that a wide-format image might end up with a rather small height. If you're talking about File:Hawthorne girl school logo.png, are you sure the whole image was only 30x30? Because in that case I'd have no idea how that could happen. Or was it just the embedded logo at the right edge of the image, as in [2]? Fut.Perf. ☼ 06:54, 26 February 2012 (UTC)

Confused about how to label a photo

I have a photo to upload that was given to me by its owner. My impression is that he is only granting permission for me to use this on the specific Wiki page that I'm currently putting together rather than offering it for everyone to use. I'm not sure if any of the 3 categories currently listed on the file upload wizard pertain and would love it if someone could let me know how best to proceed on this. Thanks. — Preceding unsigned comment added by Canamets (talk • contribs) 22:00, 26 February 2012 (UTC)

Hello, thanks for asking. I'm afraid from what you're saying, it sounds like there's probably no way we can use that image, unless you can persuade the owner to grant a more far-reaching license. The only alternative would be if you could make a case for "fair use". Is it an historical photograph? If it is old and unreplaceable, you might be able to make a case under our WP:NFCC rules. However, this presupposes that the photo was previously published somewhere. If it was merely a private photograph somebody had in their personal collection, fair use is out. Fut.Perf. ☼ 22:10, 26 February 2012 (UTC)

Hi, and thanks for the quick reply. The photo in question is a shot of the cover of a piece of music published perhaps 100 years ago that this person I'm assuming took on his own. He owns the music outright and, to the best of my knowledge, the publisher is long since defunct. It may well be that the owner will allow it to be used as you say in a more far-reaching way. If this turns out to be the case, what would you suggest would be the best way for me to so indicate this when I try and upload it? Would I need a document from the owner, an email, or something else perhaps? — Preceding unsigned comment added by Canamets (talk • contribs) 01:39, 27 February 2012 (UTC)

Thanks for this. If it's a photograph of a printed piece of sheet music from the early 20th century, then we can treat it as "public domain" – the photographer doesn't actually own any copyrights on it, because the photograph itself is a mere reproduction, and the original print is out of copyright if it was published before 1923. You could upload it using the option "This work is so old its copyright has expired", under "free works". Fut.Perf. ☼ 07:14, 27 February 2012 (UTC)

Terrific. Thanks again! — Preceding unsigned comment added by Canamets (talk • contribs) 15:24, 28 February 2012 (UTC)

Syntax of the desc page for files uploaded to COM

Apparently everywhere {{en}} is added. That is not good. Dates should be entered simply in ISO (yyyy-mm-dd) notation. The author field does not really need the "english" tag. That is just what I noticed just now. I would only add the "en" to the description. Cheers --Saibo (Δ) 23:58, 26 February 2012 (UTC)

Point taken. Will change that. Fut.Perf. ☼ 06:48, 27 February 2012 (UTC)

uploaded without a license?

Here - I had guessed that this is not possible with this wizard. Even the source does not show up (apparently syntax errors). --Saibo (Δ) 00:14, 27 February 2012 (UTC)

There was a problem with some license tags that didn't match exactly between this script and the dropdown box in the Commons form; this has been improved in the meantime and should not be happening again. Thanks for reporting. The other thing must be about the overuse of the "{{en}}" tag you mentioned above. Also now fixed. Fut.Perf. ☼ 07:07, 27 February 2012 (UTC)

Categories?

For COM-Uploads. Are there no ones added usually? Does the user has no chance to? If possible then {{subst:unc}} should be added. A sidenote: please have a look in the COM:VP section. --Saibo (Δ) 12:51, 27 February 2012 (UTC)

I know, the thing with the categories is a bit of a problem. Our local uploads typically aren't categorized, so the wizard doesn't contain functionality for that, and of course it doesn't have access to the categories at Commons. It does include a request to the uploader to add categories manually, in the message screen shown before they are forwarded to Commons, but that is fairly easy to overlook, or users may easily fail to understand what's meant by it. Not sure how to overcome this:

• Create a better message screen, using not a simple browser alert() box but a jQuery .dialog(), which can have formatted wikitext and could contain a richer set of instructions. (I'll be working on that.)
• Add some instructions in html comments in the preloaded description text sent to Commons
• Add {{subst:unc}}, as you say.

Fut.Perf. ☼ 13:31, 27 February 2012 (UTC)

Well, you could try to borrow the category adding code (with auto-suggestions) from the COM:UW. But probably that is far from easy. That said, the COM:UW hides it's category selector that good that most uploads are also without categories (subst:unc is added then). ;-) --Saibo (Δ) 13:40, 27 February 2012 (UTC)

I think categorizing files is just objectively a very difficult thing to do for a newcomer. If you have no prior experience with how the category system works, little to no understanding of what its purpose is, no way of quickly looking up how the whole category hierarchy is structured, and nothing telling you what possible categories might exist and how they might be named, it's basically a hit-and-miss, even with the help of that autocomplete feature. By the way, the reason why the Commons UW often produces files without categories might be not so much because the selector is "hidden", but because it's so stupidly designed that you have to not just input a category name, but separately hit a "save" button for it to make it stick, unlike with all other stuff you put into the form. That's very easy to miss (has happened to me too). [<rant>And since we're at it, why is it that the popup helps that are supposedly meant to be shown when you hover or click on all those little question marks in the wizard's labels aren't working for me on FF10? And why is it showing me that big distracting "Learn > Upload > Release rights" bar at the top, always making me expect I can click on it for navigating between the steps, but then I can't? Something makes me think the wizard isn't quite as well designed as the public-relations-speak of the people who so proudly put all their resources and nifty testing methods into it [3] wants us to believe :-P </rant>] Fut.Perf. ☼ 16:31, 27 February 2012 (UTC)

Please do not rant about COM:UW here... :-D And yes, we^TM (or I) know that COM:UW is quite fucked up (since it was released). See commons:Commons talk:Upload Wizard. The error that you cannot click on the labels and generally have no way to navigate back and forth is known since probably a year... That the category picker has a confusing UI even if someone finds it is known, too. The servers are currently being not really available, cannot the the ?-bubble boxes... By the way: if you get those open, it is confusing to get them closed again: bugzilla:34337.. Cheers --Saibo (Δ) 17:27, 27 February 2012 (UTC)

author field with "own"

{{own|[[User:Nixenzo|Nixenzo]]}} e.g. at commons:File:CCP Tanghalang Nicanor Abelardo.jpg. That is probably not intended. ;) --Saibo (Δ) 12:57, 27 February 2012 (UTC)

Dang. The Commons "own" template doesn't take the author name as an optional parameter? Ours on en-wp does. :-( Better like this? [4]. Fut.Perf. ☼ 13:14, 27 February 2012 (UTC)

Looks better, yes. Thanks. Commons has a very useful template by the way: {{self-photographed}}. I personally think it is more clear than "own work" since it makes it clear that it does not refer to any depicted work. --Saibo (Δ) 13:28, 27 February 2012 (UTC)

Confusing licensing info at uploads at COM

Quite often confusing licensing info like in commons:File:Asiel Snow Founder of Snowville,VA.jpg - but at least it is not simply labeled "own work" without any other information... that makes it obvious and easy to detect problematic files. However, from today's uploads in commons:Category:Uploaded_with_en.wp_upload_wizard it gets obvious that this uploadwizard does not really lead to a good upload. ;-) My first impression. --Saibo (Δ) 13:10, 27 February 2012 (UTC)

About cases like commons:File:Asiel Snow Founder of Snowville,VA.jpg: I'd say that's "a feature, not a bug". We can't really stop people from misunderstanding the "own work" option, but with this wizard, they are at least tricked into revealing enough other information to make it easy to detect. (I'm not quite sure what you were saying in your second sentence; somehow the grammar has gone astray there :-) Fut.Perf. ☼ 13:18, 27 February 2012 (UTC)

Before I saw your comment I made my mind up: the thing is: probably all users who use this wizard are newbies - so the uploads are kind of "newbie only". So this cannot be compared that easily to other means of uploading. As soon as the users know about licensing they will maybe stop using this wizard. So it could be that only "shit" is uploaded with it... but that is much better than the plain "own work" claims of so many newbie copyvio uploads with the COM:UW.

Second sentence: hmpf ;-) Added some words... this sentence was not really complete. --Saibo (Δ) 13:24, 27 February 2012 (UTC)

Found one good upload! ... but: the uploader's stats: "195 edits since: 2006-10-09". So that wasn't a newbie. ;-) --Saibo (Δ) 13:38, 27 February 2012 (UTC)

(ec) Yes, I think you hit the nail on the head here. What you're seeing in the new Commons category is representative of the kind of stuff we used to get uploaded here – the people who fail to get the recommendation of going to Commons from the start are typically newbies, and the percentage of problematic or plainly low-quality images has always been very high (see the "statistics" section above). Fut.Perf. ☼ 13:40, 27 February 2012 (UTC)

No, some (fairly) experienced users have tried (and much like) the new wizard. I use Commons, of course, for images I know are free, but for fair-use images this is certainly a good thing if not the obviously-right route. The questions seemed to me considerably less of a nuisance than the previous wizard, and the checking it seemed to do appeared considerably more intelligent, so well done all round. Will report any problems if they arise! Chiswick Chap (talk) 17:12, 29 February 2012 (UTC)

File upload seems to be broken at the moment

File upload seems to be broken at the moment. When I click the "Click here to Start the Upload Form", nothing happens. Banaticus (talk) 21:19, 27 February 2012 (UTC)

Sorry about that; should be fixed now. Please purge your browser cache after clicking start the next time, to make sure you get the most recent, corrected version of the script. Fut.Perf. ☼ 21:46, 27 February 2012 (UTC)

COM uploads: subst:OP instead of OTRS pending

Please use subst:OP instead of OTRS pending Cheers --Saibo (Δ) 00:44, 28 February 2012 (UTC)

Okay. [5]. Fut.Perf. ☼ 09:10, 28 February 2012 (UTC)

I do not see the "subst:OP". Instead there is "Harry Potter and the Order of the Phoenix"?! --Saibo (Δ) 14:34, 28 February 2012 (UTC)

Oh sh.... Why on earth does it treat the {{subst:OP}} string as a substitutable template here on en-wiki when I insert it into a javascript page?! :-(.... Fut.Perf. ☼ 14:45, 28 February 2012 (UTC)

LOL - I understand (no harm done). JS pages are no different from other wiki pages except in display. You have to break such templates with e.g. \. That is a reason why it can be useful to wrap the JS in nowiki tags. ;-) You can also add speedy tags or categories to JS pages to sort it into a category example: commons:User:Saibo/catgraphtabs.js. One question: you even give me a diff link without looking at the diff? ;-) Cheers --Saibo (Δ) 23:30, 28 February 2012 (UTC)

Revert test version please?

Please return me to the normal page, please? I want to upload a file, thanks.--♫GoP♫_T^C_N 13:15, 28 February 2012 (UTC)

Please revert to this good, old version. Thanks.--♫GoP♫_T^C_N 13:16, 28 February 2012 (UTC)

You can still use that form, of course. You can also still use the plain old Special:Upload. However, experience shows that these methods lead to a huge lot of problems because new uploaders don't understand them. Can I ask what exactly you didn't like about the new one? Fut.Perf. ☼ 13:19, 28 February 2012 (UTC)

Complicated, premature and unprofessional. Really confusing, especially for newbies.--♫GoP♫_T^C_N 13:24, 28 February 2012 (UTC)

Well, I regret you don't like it, but this criticism doesn't really do much to improve things. Initial observation shows that newcomers can work with it much better than with the old form (which undoubtedly is a lot more complicated and unprofessional), so I doubt reverting to that will be much of an option. Fut.Perf. ☼ 13:26, 28 February 2012 (UTC)

I'm sure that many people spent many long hours to create this, for which I sincerely thank you. My reaction is: I hope I never have to actually use it again. (and this comes from am "early adopter" type of person). Something simple has been turned into something complex. I can tell it is designed for the newbie user, but even so it has too many "fill in the blanks" that aren't explained until after clicking the button. The previous "complete the pre-filled template" method seems superior to me. Hope you find the comments helpful. Senator2029 (talk) 21:34, 9 March 2012 (UTC)

Heh, actually, no, so far it's basically just one person who spent many long hours creating this :-) – I'm not quite sure what you mean when you say "fill in the blanks that aren't explained until after clicking the button"; could you give an example?

About "something simple turned into something complex": I'm afraid the whole problem is that this is the minimum level of complexity dictated by the subject matter. The decisions an uploader has to make during the upload process simply are this complex (or actually, even more complex than this.) The old form did nothing for guiding people through this necessary level of complexity. Finally, about the "pre-filled template" method: no, that one never worked. From months of frequent patrolling of the image logs, I know that most people never figured it out. Many newcomers, at that stage, haven't even grasped the basics of what a template is, technically; they never realized they were supposed to enter stuff after those equals signs. 15% of all image uploads with the old system came with completely blank description pages. Also, there was nothing explaining what those template parameters meant and what output they would produce. What does "|Purpose=" mean in a FUR template? A very large number of uploaders either left it completely blank, or they thought it referred to the original purpose of an image for its author (so they would enter stuff like "promotion" if it was a promotional image.) What does "|Date=" or "|Source=" mean, when you're dealing with an old public domain item? People had no way of knowing. Fut.Perf. ☼ 21:58, 9 March 2012 (UTC)

Forward slash

I tried to upload an image called "Office of HIV/AIDS Network Coordination". Things seemed to work but then it gave me a bogus link to my file and I could not find it. Eventually I found it as File:AIDS Network Coordination.gif, so it seems to have ignored what came before the slash. I sorted this issue for myself, but maybe others will have this problem too. Blue Rasberry (talk) 19:33, 28 February 2012 (UTC)

Thanks for reporting this. I've added the slash character to the list of characters the script will disallow, and made another change to the response script that reports on the completion of the upload so that it retrieves the actual filename properly, in case there might be other unforeseen situations where the server might have changed it. Fut.Perf. ☼ 20:02, 28 February 2012 (UTC)

I've also taken the freedom of moving your file to File:Office of HIV-AIDS Network Coordination.gif, as being closer to the originally intended name, supposing that's okay with you? Fut.Perf. ☼ 20:08, 28 February 2012 (UTC)

Thanks for appreciating the feedback. I am always thrilled when my contributions matter. I appreciate your moving the file, also. Blue Rasberry (talk) 20:18, 28 February 2012 (UTC)

Upload Button Not Working

Trying to upload an image, I've filled in everything I need to, and the upload button is still unclickable. It shows the Upload button but it doesn't let me actually press it. Benjamin7887

That's strange. Can you tell me which of the main file type options you were working with? Fut.Perf. ☼ 07:13, 29 February 2012 (UTC)

Ah, wait, I see now. In your case, it's because your account is not yet old enough to be technically able to upload files (see WP:autoconfirmed). But the wizard ought to have shown you a message about that at the beginning, did it not do so? I'll check. Fut.Perf. ☼ 07:36, 29 February 2012 (UTC)

I'm also unable to upload an image, and I have had an account for quite some time. Richiekim (talk) 19:13, 29 February 2012 (UTC)

Can I ask which browser you were using, and which of the main file type options you had chosen? Fut.Perf. ☼ 19:15, 29 February 2012 (UTC)

No default filename

I really do not like this. I also do not like that everything is cluttered up on a single page, making the upload process seem more difficult than it is. I really see no reason this isn't modeled on the new Commons uploader, with just the addition of a page for Fair Use and an option to insert your own templates under both the summary and licensing. (This is essential to being able to replace an image with another filetype: it's annoying to have to retype the entire fair-use rationale.) Distinct sections make the process look easier. — trlkly 04:12, 29 February 2012 (UTC)

The lack of an automatically filled in filename is by design. The old mechanism that just copies over the local filename from the user's harddisk leads to too many poorly named files (often much too generic, or random strings of the "DSC0012345.jpg" type). We actually want to force the user to give some thought about how to best name the file, and there's no reason to expect that what was a handy filename for local storage will also be a good filename for Wikipedia in most cases.

About whether to divide it into several pages, well, I guess that's a matter of taste then – I for one find the structure of the Commons wizard with its rigid separation of stages annoying (you can't even navigate back and forth between them). There are also a number of other factors, both technical and design matters, that would have made a direct adaptation of the Commons wizard not an optimal solution, in my view.

I'm not quite certain what you mean by "option to insert your own templates" – there is in fact such an option; you can put whatever tags you like in the "description" box at the top and in the "any other info" box at the bottom, and you can also enter alternative license tags in several of the file categories. However, in the scenario you seem to be thinking of, where you are uploading a new version of a pre-existing file with an identical description page but a different extension, you are certainly better off using the old, plain form (think of it as a kind of "expert mode" that allows all sorts of rare extra things.)

Fut.Perf. ☼ 07:33, 29 February 2012 (UTC)

Test?

hello,

when will the "beta version" period end? Regards.--♫GoP♫_T^C_N 10:15, 29 February 2012 (UTC)

Personally, I'd propose letting it run until at least 4 March as a start, by which time we should have some first, reasonably reliable statistical data based on a full week's worth of uploads. Once we have that, we can decide whether to keep it running, make the old system the default again, or start a new test with an improved version later. Fut.Perf. ☼ 10:47, 29 February 2012 (UTC)

I was going to upload a photograph but

I was going to upload a photograph, but having spent some time looking through all this palaver I shan't bother. I don't upload to the Commons, much too complicated for an old dear like me. I learned to upload to enwikipedia but refuse to learn how to do something more complicated. Wikipedia's loss, not mine.J3Mrs (talk) 15:07, 29 February 2012 (UTC)

That's regrettable. Did you see that you can still access the old form if you prefer that one? The thing is, the files you have been uploading are real, good, honest, self-made photographs; just the kind of work that we really ought to welcome most; and for this kind of work, uploading indeed ought to be easy. The trouble is that so many other people are trying to upload other stuff where the copyright situation is far more complicated (fair-use stuff, photos they didn't take themselves etc.), and unfortunately the upload forms have to be so complicated in order to catch all these other cases. Fut.Perf. ☼ 16:48, 29 February 2012 (UTC)

I can no longer be bothered. Why should I have to jump through hoops to provide free images to Wikipedia? I didn't see the old form or I would have used it, but .....well it's supposed to be my hobby not something to wind me up. Odd isn't it, anybody can edit wikipedia, even vandalise someone's perfectly good work, but good-faith editors who are useless with computers and find these things so complicated are driven away. J3Mrs (talk) 17:24, 29 February 2012 (UTC)

At the bottom of the upload page there are links to all the other upload pages. I presume one of these is the one you are familiar with. Try again. ww2censor (talk) 18:15, 29 February 2012 (UTC)

Thank you, yes now I see it, but it wasn't obvious to me when I was feeling miffed at the change. I won't be uploading anything as I've lost interest and run out of patience. J3Mrs (talk) 19:50, 29 February 2012 (UTC)

Simplification made

After observing the incoming files, I deactivated the first subsection under "free files" with its questions about various types of derived works. This section appears to have added too much complexity for too little benefit and rarely produced good output.

I apologize for likely browser cache problems that will be experienced by people who have visited the form before and reload it now; they will initially see a few error messages. Please make sure to purge your browser cache after clicking on the start button. Fut.Perf. ☼ 19:39, 29 February 2012 (UTC)

Statistics after first week of test run

January sample (1–31 January; 1,000 out of 10,623 files)
		Newcomers		Other editors		Total
		N	%	N	%	N	%	approx. per day
Free	bad	194	48.0	83	22.0	277	27.7	94.9
	ok	85	21.0	131	22.0	216	21.6	74.0
Non-free	bad	58	14.4	55	9.2	113	11.3	38.7
	ok	52	12.9	312	52.3	364	36.4	124.7
Other		15		15		30
Total		404		596		1000		342.7
Sample from Wizard test run (26 February – 4 March, 1,016 out of 2,050 files)
Editors using the File Upload Wizard
Free	bad	42	16.3	8	2.9	50	9.3	16.4
	ok	85	33.1	55	19.8	140	26.2	45.9
Non-free	bad	34	13.2	15	5.4	49	9.2	16.1
	ok	94	36.6	184	66.2	278	52.0	91.2
Other		2		16		18
Total		257		278		535		175.6
Editors using the wizard's "upload to Commons" button
bad						112	22.0	16.0
ok						396	78.0	56.6
Total						508		72.6
Editors using the old upload methods
Free	bad	75	36.6	26	8.9	101	20.3	33.1
	ok	71	34.6	72	24.6	143	28.7	46.9
Non-free	bad	19	9.3	16	5.5	35	7.0	11.5
	ok	40	19.5	176	60.1	216	43.4	70.9
Other		0		3		3
Total		205		293		498		163.4

Discussion

So, here's my evaluation of the statistics above.

long discussion of figures

For comparison, I had taken a sample of 1,000 files uploaded by 1,000 distinct editors during the month of January, before the introduction of WP:FUW, representing approximately 10% of all new uploads (10,623) of that month (see section above). During the first week of operation of FUW, after the first bugs were ironed out (26 February – 4 March, 16:00 UTC), a total of 2,950 files were uploaded on en-wp, by 1,016 distinct editors. To keep the samples comparable, I again used a sample with only one file per editor, i.e. 1,016 files. During the same week, 508 files were uploaded to Commons using FUW's "upload to Commons" button (recognizable by the "{{subst:Upload marker added by en.wp UW}}" string in the upload summary). These were all included in the sample above. Obviously, the number of uploaders who went to Commons directly or on being asked to do so at the beginning of the upload process is unknown, both for the old and for the new system. In all the tables, "bad" files are those that had been deleted or were tagged for deletion at the time of the survey, for any reason other than "move to Commons"; all others were counted as "ok". Files were counted as (claimed to be) "free" if they were not explicitly tagged as non-free. "Other" refers to files having partial problems, such as non-free files having their initial file versions deleted for size reduction. "Newbie" editors are those with edit counts lower than 100 at the time of upload. The bar diagrams represent proportions of "bad" and "ok", "free" and "non-free" files drawn to a common scale representing estimated total figures per day. During the test run, slightly over one half of all uploaders opted for using the new wizard; the others opted for the traditional upload forms or some other means of upload (bots etc.) Taking into account those that used the "upload to Commons" button, the number of FUW users is approx. 60%. The figure is somewhat higher for new users than for old users. Approximately 54% of those who were uploading free files through the FUW opted for the "Commons" upload button. Comparing proportions of bad to good files across the three samples, it appears that the FUW has been reasonably successful at reducing the number of copyvios and other problem files, compared to the dysmal picture of the January sample. In January, 39% of all uploads were bad. Among free files uploaded by newbies, the rate of bad ones was as high as 70%. For non-free files by newbies, it was 53%. Bad files from newbies together accounted for 25% of the total of all files uploaded. In comparison, among the files uploaded with FUW, the rate of bad files has been cut to half. The total rate of bad files is down from 39% to 18.5%; that among free files from newbies is down from 70% to 33%; that among non-free files from newbies is down from 53% to 27%. The rate of bad files among those sent to Commons is comparable to that among the local uploads. Even for those editors who did not use FUW, performance is somewhat better than before: total rate of bad files 27%, bad files among free files from newbies 51%. In terms of absolute numbers of uploads per day, the figures show a virtually unchanged total number of new files (342.2 files/day in January vs. 339 files/day during the test period, combining all methods of upload.) Breaking this down to estimated absolute upload rates of different types of files, it appears that the number of good files from experienced uploaders, both free and non-free, has been virtually unchanged. In contrast, the number of good files from newbie uploaders, both free and non-free, has increased. The number of bad files, in all categories, has decreased by between one third and half. While the reduction of bad files can certainly be ascribed to a success of the FUW, there are different potential explanations for the changes in the number of good free files. An increase in such files might partly be due to better instruction through the FUW, leading to a larger number of potentially good files surviving that would have been lost through poor tagging in the earlier system. Alternatively, it might also be due to a poorer performance of the FUW in inviting uploaders to Commons. Yet another theoretical possibility is that it might be an artifact of more copyvios being concealed more efficiently and slipping through. Based on my observations from patrolling files (see below), I believe this latter explanation can be ruled out. Given the fact that the number of good free files with experienced uploaders has remained stable, and that the increase with newbie uploaders has affected both free and non-free files alike, I would argue that the first explanation – better instruction – is the most likely factor, and that the new system's efficiency in directing people to Commons is likely equal if not better than that of the old one (although this cannot be tested with certainty.) Looking at the quality of file descriptions produced with the FUW, I believe we can see another advantage: even the bad uploads produced with the FUW are easier to deal with than the bad uploads produced in other ways. This is because even editors who upload bad files are now typically led to include more information than before and thus make the problem much more obvious and easier to understand. For instance, an editor who in good faith has failed to understand what a "free license" is, and therefore misuses the "from a free website" upload option for a "found it somewhere on the web" file, will still try to follow the instructions and add a link to the source website. In such a case, one look at the claimed source is sufficient to determine that the uploader was mistaken, and thus the file can be immediately speedied as an obvious copyvio, rather than having to waste time with the "no permission" tagging procedure, which would only confuse the uploader further. In this way, bad uploads produced through good-faith errors can be far better distinguished from copyvios produced through intentional cheating.

tl;dr summary: In conclusion, I believe the first week's results show that the new WP:File Upload Wizard has an overall beneficial effect increasing the quality of our uploads and decreasing the number of problematic uploads. I therefore propose leaving it in place as the default upload entry point for the time being. Fut.Perf. ☼ 09:37, 6 March 2012 (UTC)