Multimedia talk:Upload wizard

This discussion page is about an extension which is currently incomplete.

We're currently working on a Questions & Answers page to address the most frequently asked questions. Feedback on the prototype is of course welcome, but you will understand that we may not have the resources to answer every comment individually, especially if many are similar. The Q&A page isn't ready yet, so it'll take some time before we can publish it. So, please consider this a "soft launch": we don't want to make a lot of publicity about our prototype yet. If you happen to know about it and you want to share your opinion, that's fine. But we'll officially invite the community later to try it out, when the Q&A page lets us focus on the most useful comments.

Current todo (issues to fix)

• buttons at end of wizard don't do anything
• fix license names to new templates
• "Use" fields sometimes cut off portions of URLs, wikitext
• Upload page -- choice between upload / next button should be clear (hide or disable next button)
• Error messaging on upload issues (suppressed for development, just re-enable)
• validation details step (including uniqueness of file (suppressed for developement))
• errors page 3
• spinner for file name test
• more options buttons' prototypal state isn't isolated -- may take two clicks to change local state
• locking and progress details step -- do not show progress bar, show loading spinner
• spinner while loading entire page
• progress bar should only appear when we have useful information about progress -- otherwise use a spinner

layout and messaging

• "to use the file" -- add Wiki note.

* arrowSteps & wizard lower-right next button -- make both of them flexible size or both fixed size

• explain licenses better
• it would be nice if page 2 didn't "flash" while laying itself out.

* Alignment of upload status column, total uploads on upload page * [mwe-unknown-code] as language code * use an orange arrow spinner for "uploading..." on upload page

• error textfields need rounded corners, or otherwise match platform textfields

Commons.prototype server

• copy licensing templates
• copy filedesc/infobox templates
• remove account new messages
• check that we are receiving optimized JS
• Verify if apache / php settings allow for long uploads -- mac firefox upload of large files failing? (received by php /tmp just fine, but no response given to browser). Update verified settings, still unsure what the issue is with mac firefox.
• Monthnames in Infoboxes are missing

Fallbacks

• noscript fallback (this is designed in, just need to dump old form in there)p

Licensing

In step 1, Alice can upload files under various licensing information. Based on our conversation yesterday, the choice of 1) my own work, 2) someone else's work or 3) from a web site, will apply to all uploaded media files. If that's the case, why not display most widely used scenario and allow users to change the selection by each media at the preview stage? Confirmation page is likely to be complex to support this scenario though. --Shuhari 17:17, 20 January 2010 (UTC)

I see what you mean. It would certainly add complexity, we'd have to think whether it's worth it. guillom 18:09, 20 January 2010 (UTC)

The license should require an action from the user. We can't even be sure they understand the language or what the text say, they would just continue with the default regardless that it applies or not. We already have people choosing a random license until "getting the right one" (one for which we don't sepeedily delete it :). Platonides 23:14, 21 January 2010 (UTC)

Incomplete status

The images with an "incomplete status" should be available in the image space. Not necessarily for step 2, but if the file will be there with wrong license, OTRS volunteers will be changing it, etc. It's appealing to create a new system, but admins should be able to view what people semi-uploaded, OTRS agents will have to edit it, and more cases will arise. Hiding the image goes against the wiki way, and creates many problems. What method is better for the permission request than include a list of the images, (which should thus be visible as anon) so the recipient can verify which ones are them? How to handle a OTRS agent approving Usability Meeting.png when a different user uploaded its self work Usability Meeting.png in the meantime? Et cetera, et cetera.

What we could do is to have a "bad-status" tag, where images can only be linked, not embedded, and not get shared via instantantcommons. Adding a no source could place it back in that state, or another, similar one. I'm pretty sure there are some bugs on that line in bugzilla.

Platonides 23:14, 21 January 2010 (UTC)

Are you referring to the step 3b? The main point of the staging area is to provide a space where uploads can be refined / amended before publication. These files would not be available publicly, but a certain category of users (who could be admins, OTRS volunteers or simple "helpers") would of course be able to see and edit them. Until we have this way to handle incomplete uploads, all files (complete or incomplete) would be publicly viewable, and for incomplete uploads we would use the existing tagging system with templates. Does that address your concerns? guillom 23:22, 21 January 2010 (UTC)

Yes. My point was on not having it hidden, just not embeddable. Platonides 15:13, 22 January 2010 (UTC)

Batch file selection

The "prototype" does not seem to contain "batch" selection of files... I know this is probably not possible to do with HTML+JavaScrips (?), but it would help a lot!!! There are people who want to upload 10+ files but Commonist is a problem for them. Facebook has a Java applet that shows thumbnails too for example.--Kozuch 13:33, 29 January 2010 (UTC)

Like this? (click "Bilder auswählen") --Subfader 13:59, 6 May 2010 (UTC)

In principle we can have batch file selection, but only for very modern browsers like Chrome, Opera, Firefox 3.6+. Unfortunately we'd basically need to overhaul how uploading even worked. It's on the nice-to-have list, and we may even get there, but it's not a priority. NeilK 22:06, 8 June 2010 (UTC)

Just to clarify -- anything you see on the internet today that allows multiple file upload with proper progress bars and such probably uses Flash. (If not, it only works in ultra-modern browsers). The WMF is very leery about including Flash components. 216.38.133.254 22:31, 19 July 2010 (UTC)

Upload by email attachment please

Please include a way for users to upload by email attachment. This is likely to require either pre-registration of the uploader's email address, which is bad because it prevents spur-of-the-moment uploads, or post-registration where the uploader is sent a URL in return email to a link to the form at "Step 2" of the ordinary upload workflow which involves possibly renaming the file, adding optional metadata, and selecting or confirming the license. Such a link would expire within a period of time (a day?) if it isn't completed, and the uploaded attachment files deleted at that point.

Please survey popular mobile phones with cameras capable of sending pictures, audio recordings, and video, and make sure that we accept their formats. Thank you. 99.27.203.165 17:42, 6 February 2010 (UTC)

Please find enough money to pay 5 more developers, and I'll give you that feature. Thank you. guillom 23:36, 19 May 2010 (UTC)

Actually, I know all about the whole upload-by-email-from-mobile phones -- while 5 more developers might be a bit of hyperbole, it almost does require another developer. The messages are wildly inconsistent and it requires heuristics when you receive an attachment. The images are usually not high resolution (for instance, the iphone sends 800x600 over email, but has much higher res images if uploaded by other means.) Doable but I also question why we would want to support this use case. Unlike Flickr or Facebook, we are not about streaming all the data of your life, but selecting high quality images likely to be useful for an educational purpose. NeilK 21:22, 8 June 2010 (UTC)

Commons doesn't let people upload unless they type in a password first. If you allow preregistered email addresses to upload, it means that someone could write a virus/worm/trojan to send your private image collection to Commons. If this happens to a thousand editors... Wnt 13:36, 15 August 2010 (UTC)

Some thoughts

I left some thoughts about a perfect Multi-uploader here and here. --Subfader

Simultaneous upload/details

Why not merge the feedback part with licensing? For example, Alice can start the upload, and provide licensing, etc for the files while the upload is in progress.
On the page with the progress bar, give each file its own progress bar. Then, add a show/hide link to edit info (universal info, which is required/used on all types of files, such as licensing, description, author, etc.) for each file. When the upload of a file (not the entire set of files) is complete, the result of the upload of the file will be shown ("previously uploaded", "Converted to Ogg", "corrupt file", etc). That way, users can multitask and save their time. Manishearth 12:12, 16 March 2010 (UTC)

We considered this option, but we need the files to be uploaded before we move to the next steps, because we want to extract as much metadata as possible from the files. And we can't extract the metadata unless the upload of the files is complete. guillom 23:38, 19 May 2010 (UTC)

Er, actually this IS possible and the programmers have thought about this idea. It's definitely possible because, by design, each upload process has no knowledge of the other uploads. However, it would also make it less easy to batch-select a license for all, which we think is a major benefit.NeilK 21:25, 8 June 2010 (UTC)

When will it go live?

Is there an estimation when this will go live? --Subfader 14:02, 6 May 2010 (UTC)

Not really; the way it works now wouldn't be acceptable for production use; we need to couple it to the Incomplete uploads, so it will be a couple more months before it can be offered as a gadget or lab feature. Then, it will be offered as default, if it works well. guillom 23:36, 19 May 2010 (UTC)

Alright, let's say by the end of 2010 :) --Subfader 19:24, 8 June 2010 (UTC)

Paintings upload

Hello I suggested on the village pump to add an option "upload a faithtful reproduction of a PD 2 dimensional work of art, or something like that. The reasons were that the default information template is really inadequate for artworks and that photographs of paintings don't seem to correspond to any of the options in the "where is the work from ?" of the upload form. So I post an adapted version of the end of the discussion. If there is still anything that you can do...

There is a template:painting, but uploaders are not necessarily aware of that and use the default template provided for files uploads. This template is truly inadequate for artworks (see template painting and see the differences). The consequence is that a good half of the paintings on commons have paltry file descriptions, that are definitely not up to any quality standards.

Adding an option for reproductions of paintings/drawings wouldn't make things more complex, far from it. If the upload form isn't clear, it is rather because it is not comprehensive than because it is too long. In the current system, if you want to upload your photo of a public domain painting, you have to choose "it is entirely my own work", but it sounds strange because it is not you who made the painting. Then, if you know the existence of the template:painting, you have to look for it and copy-paste it. If you're an occasional user, chances are that you provide only the information that you are asked, even if they are grossly insufficient for a painting. Adding an option "it is a faithful reproduction of a 2 dimension public domain image" would not make things more difficult, and it may prompt people to provide information that are necessary but too often lack on commons file. Given the large number of artworks on commons (many tens of thousands I suppose), I think it is something that is really worth doing.--Zolo (talk) 21:11, 18 May 2010 (UTC)

You might want to bring this up on Commons:Usability issues and ideas. The usabilityuser experience team might already have something in the pipeline. -- User:Docu at 03:11, 19 May 2010 (UTC)

I agree it would be a good idea if it can be done. --Jarekt (talk) 12:58, 19 May 2010 (UTC)

Yes, paintings are one of the options that we'll add later; it won't be among the default 3, but it should be available under "more options". guillom 23:33, 19 May 2010 (UTC)

Practical problems with choosing an approriate license in WM Commons

As suggested by user Justass at http://commons.wikimedia.org/wiki/Commons:Help_desk#Practical_problems_with_choosing_an_approriate_license, I copied the following discussion here. HHahn 20:02, 20 May 2010 (UTC)

Please look at http://commons.wikimedia.org/wiki/User_talk:HHahn#File:Diagram_Reflector_GregoryMaksutov.svg, where I complained about the poor presentation of license type choices. Please see it as a suggestion for a new functionality: a clear selection form for choosing a lincense type.

HHahn (talk) 15:20, 20 May 2010 (UTC)

There are ongoing discussions about this at Wikimedia Usability Initiative, please post your suggestion or comments there --Justass (talk) 15:35, 20 May 2010 (UTC)

Even with the current upload form, there is—unless JavaScript is disabled—a MediaWiki:UploadFormHelpOpenButton button next to the license selector. When clicked, it opens a pop-up with some help text. On the "own work" upload form, it displays the text from MediaWiki:UploadFormLicenseHelp/ownwork. It's still not a "decision tree" like HHahn suggested on his talk page, but at least it does try to explain things in (relatively) simple English. Lupo 15:55, 20 May 2010 (UTC)

By the way, the "own work" situation is the most simple one. For my own work I can choose any license that is not too restrictive. But when I am uploading an image from another source, I have to comply with the license requirements set by that source. And that requires that I more or less understand that #$^%$@* lawyerese. As a Dutchman, I already have problems with Dutch lawyerese, but here it is even an a foreign language (English)...

HHahn (talk) 19:47, 20 May 2010 (UTC)

End of copy – please put further discussion below this line

Thank you; these are typically the issues we're trying to fix; Our prototype tries to present licenses more explicitly, in plain English. I'd be glad to hear your feedback. guillom 23:20, 20 May 2010 (UTC)

Sorry, yhe link you mention only gives a nearly-empty page, with no license info, selections, or whatever. HHahn 15:02, 21 May 2010 (UTC)

It is a separate prototype wiki. You need to create an account, and upload a file (both links are given on the main page). For now, it only works with modern versions of Firefox & Chrome, and you need JavaScript to be enabled. guillom 16:33, 21 May 2010 (UTC)

OK. I now tried it, uploading two files. It looks very much better than the old upload form. However, some questions remain.

• There are now fewer license types shown for selection (making it simpler), but their meaning is not yet explained. A short text -- possibly only shown on request (e.g. folded out after clicking a button or a link) -- briefly explaining each one of the license types show, would be helpful. Don't ask me what the difference is between "Public Domain", "Creative Commons Zero waiver", "Creative Commons Attribution 3.0", "Creative Commons Attribution ShareAlike 3.0", "GFDL (GNU Free Documentation License)" etc.! These terms sound just meaningless to people not familiar with these things. And if I look them up somewhere (where?), I am sure I have forgotten it within a few minutes.
• In the end, when for some reason I want (or have to) to change the license, I can only "edit" the license template name shown. Not even the "names" of the license types are shown now.

What I am suggesting, is that at least an explanatory text (in plain English, avoiding lawyerese) of each license type be given. But better would be what I called a "selection tree" consisting of questions guiding the user clearly through the "maze" of license types. Compare it with a "clever" opinion survey that only shows those questions (the tree branch) that are relevant in view of the answers given so far. If at certain points multiple answers must be allowed, a clear indication should be given that the user will now first be guided through the remaining questions for, say, answer 3.5.3. When that is done, answer 3.5.7 must be worked out, etc.

HHahn 10:50, 22 May 2010 (UTC)

Anotjer point is that in the localised (Dutch) version I cannot select "Creative Commons... unported", but only "Creative Commons...Netherlands. There are two problems with this. First of all, Dutch is spoken in more countries than only the Netherlands: more than half of Belgium (known as "Flanders") speaks Dutch, and in Surinam, too, Dutch is an official language. Wikipedia is organised bij languages (and rightly so), but legal regulation are udually "organised" by country, which more often than not is NOT the same.

Secondly, A user may have several reasons to specify an "unported" license. So at any rate, "unported" must be selectable as well.

HHahn 11:43, 9 June 2010 (UTC)

Why would a user want to specify an unported license? It seems to me that the right thing to do is to use the correct ported licenses whenever available. The license template itself may not be in a language which matches the media, but that's irrelevant. For instance, I could record a person speaking Navajo in the USA and the license template, say, CC-BY-SA-3.0-US would still be in English, since that's the default language in the USA. NeilK 18:29, 25 June 2010 (UTC)

Inconsistent behaviour of external links?

The link Gillom gave in the above item is shown as an external link (with the little image where a pointer points out of the screen). As far as I understand, the normal behaviour is that Wiki software executes such external links in a new tab (at least in Firefox). But sometimes it does not -- it overwirites the current tab. That is also what happened here.

Is there some clear description in what cases a link is executed on a new tab and when it is not?

HHahn 15:02, 21 May 2010 (UTC)

External links are always opened in the same tab or window. By default, MediaWiki doesn't open links in another tab/window. guillom 16:34, 21 May 2010 (UTC)

Feedback

I haven't closely read the rest of this page, but these are the problems that stuck out for me with the new Upload wizard:

• It's very frustrating to have to upload the entire file before entering any details. Over my high-speed connection uploading a high-resolution photograph requires a few minutes, and people on modems or data plans would require even longer, up to 30 minutes. If you spend a long time uploading something you end up going to do something else and lose the context of what you were doing.
• I disfavor the idea of having a default or "recommended" license for image uploads. Text on the wiki has to be released under a single license to maintain sanity because it's collaboratively edited - images are quite rarely edited, and authors should be encouraged to (briefly) consider which license best suits their needs, without imposing any restrictions that they don't actually care about. I'd much prefer something like Creative Commons' license chooser.
• I dislike how the license chooser seems to emphasize making it easy to multilicense - multilicensing is not often useful, and frequently entirely pointless (as with say, CC-BY-SA and CC-BY, public domain and anything), and shouldn't be the focus of the UI. I would make it a "choose one of the below" list with multilicensing as an option in that list.
• It would be nice if the license screen would remember what they entered for their name the previous upload, instead of having to re-enter it every upload. Or if this was a setting in their preferences.
• In the current upload wizard for "not my own work", we include many "trap" choices for license: licenses that are actually unacceptable on Commons. The reason for this is that users who are not permitted to choose the actual license of a work will often randomly choose something from the list, leading to copyright violations. It's important that the new "This file is not my own work" area also include trap choices. Alternatively, the trap choices could redirect users to the non-free content policy at their home wiki, if there is one.
• Ideally, the "not my own work" section would have options for common sources like Flickr, Picasa Web Albums, etc. that allow you to just enter a URL and they'll automatically extract the metadata from there.
• Ideally, we should have a "public domain" guide to help people determine if a work is actually public domain in its country of origin. This is an incredibly complex determination that is hard for many people to do. This page could be a starting point for US works.
• It'd be nice to have a larger, multiline box for Source, as some people like to put detailed citations and we shouldn't discourage this.
• The description box auto-expands, which is nice, but it wasn't intuitive for me at first that it would do this, which made the field feel too constrained.
• It would be great if geolocation tags were automatically added based on EXIF data.

Things I like:

• A short list of licenses. The five that are included are just the ones that I would include.
• Setting the "date" field from the EXIF data.
• Not requiring an extension for the title.
• Showing how to use it with the thumb syntax at the end.
• The link on the final page opening a new tab/window. If it didn't do this it'd be easy to lose the info on the last page.

Neutral:

• The upload form does nothing to address complex copyright issues like derivative works, PD-Art, freedom of panorama, de minimis and so on. I think this is okay as I have no idea what the best way to deal with these is.

Thanks for working on this, I do think it's a great effort and will hopefully facilitate easier uploads in the future. :-) Dcoetzee 21:00, 17 June 2010 (UTC)

Thanks for all this. I think you've zeroed in on a lot of important issues here. I'm not going to respond point by point because a lot of the questions are still up in the air. Some are no-brainers, but some are a bit more in a grey area. A lot of the participants in our study really like that you can upload before adding titles and so on, which is your number one complaint.

One thing which is not at all obvious is that this frontend supposes a rewritten backend which allows you to upload files without "publishing" them. That is, you can upload files without metadata, and then you can add that metadata at your leisure (for instance, determining the license may be really complex). So one choice for license might be "I need help with this" or "Figure it out later". In which case the file will stay in your private area, until maybe an admin can help you out. We're calling this concept "incomplete uploads" for now. NeilK 22:48, 17 June 2010 (UTC)

Okay, after saying I wasn't going to respond point by point, I think I'd like to anyway, as we are now setting post-study priorities.

• Frustrating to upload file... without adding details we just disagree on this. Study participants have not yet complained about that.
• disfavor recommended license we disagree on this, I think Erik summed it up well below. That said we can do better explaining what's happening with the licenses.
• too easy to multilicense a lot of people think we've got it wrong here. Personally I think we need to review this. That said if we open it up it's a rathole we may never escape from. Assuming we even want to give people the ability to multilicense, in an ideal world we'd be able to sort out what licenses were compatible with each other. It definitely is possible to dual-license GFDL and CC-BY-SA-3.0, but is Public Domain (Argentina) incompatible with a CC0 license everywhere else? I don't know. Maybe this is impossible to really get right. But right now we're just not even trying to help them make a choice which makes sense.
• remember license settings from previous upload -- planned feature
• trap choices -- I would like to learn more about this. Please write more. My gut instinct says that if we need to do this it must be a symptom of a failure elsewhere in the entire upload experience. Perhaps the licensing tutorial will reduce the need for this. It seems wrong to me if we are giving them choices that don't make sense just to trip them up -- it is definitely not in the spirit of 'Assume good faith'. That said it may be a sort of human-nature hack that works better in practice.
• not my own work should have common sources like Flickr etc -- a planned feature, but currently deferred as a nice to have.
• public domain guide. Well, you said everything that needs to be said. That's hella hard. The licensing tutorial is not expected to solve that problem. I think we have to defer this for another day. However, we may be able to explain to them that the common notion of "I found it on the internet, therefore it's public domain" is WRONG.
• multiline box for source -- it IS multiline, just like the description field is autoexpands.
• surprised that description box autoexpands -- not sure what I can do about this. I think you're right that we need a little more room in the description field to start with. Is there an interface convention to show that such boxes autoexpand? In any cases, Facebook uses such boxes everywhere, so they are pretty mainstream now. I would argue that it's more likely that the more computer savvy users are surprised that it expands, where the less savvy users would be surprised/irritated if it doesn't expand.

NeilK 18:53, 25 June 2010 (UTC)

I would strongly argue against forcing a licensing selector on new users. Wikimedia's core philosophy on licensing is expressed by the Creative Commons Attribution/Share-Alike license on text, so it seems entirely sensible to default to CC-BY-SA licensing for media files as well. To the extent that users have expectations, this will be consistent with them, and it will reduce the need for new users to familiarize themselves with the relatively minor differences among free cultural works licenses, which are incredibly difficult to understand for someone who has no mental framework of licensing at all. Nobody is arguing for taking away licensing choices - just for picking a reasonable default. (I'm of course in favor of doing the best possible job we can do without cluttering the UI of explaining the meaning of the default, just like the Wikipedia edit page makes it very clear what the default text licensing means.) --Eloquence 02:07, 18 June 2010 (UTC)

Hey all, sorry for late response.

• My main concern with multilicense is just that the interface makes it really easy to multilicense, when most files are not multilicensed. There will, in all likelihood, be more users who accidentally multilicense incorrectly or get confused by the concept than users who actually need to perform multilicensing. A single-selection UI would be more intuitive.
• My opposition to the CC-BY-SA is philosophical, and I recognize that the use of this default license for "self created images" is unlikely to change, as much as I'd like it to.
• You can see trap choices in the current upload form on Commons. "I found the image on Google or on a random website." "Fair use image." And so on. These are important because it's extremely expensive to detect images where the uploader lied about the license later on. The target audience here is the uninformed Commons user who goes "I need an image for my article," goes to Google Image search, downloads one and then tries to upload it to Commons without even reading any of the warnings we provide. This type of user may have done this routinely in the past on other, less strict websites. I realise this may sound like not assuming good faith, but because the cost of detecting this type of upload is high it's important to take some limited measures to help prevent it.
• I really like the idea of "incomplete uploads" for images where the user is not sure about the copyright status. Commons users routinely answer questions about copyright and do public domain review and I think they'd be happy to help with this type of image. I'm assuming the technical measures that will support this will also prevent the inclusion of incomplete uploads in articles, which is important to avoid collateral damage if they need to be removed.
• I forgot about Facebook's boxes. Yeah the autoexpand thing is fine, just unfamiliar to me. :-)

Hope this helps. Dcoetzee 19:56, 7 July 2010 (UTC)

As for incomplete uploads, we had some discussions about this and we're starting to realize that we don't have concrete enough plans for how this "mentorship" is going to work. We can lay the groundwork for that sort of thing (stay tuned) but that isn't going to be a major part of our first release. Be aware this is a time-limited grant and we have to wrap it all up by November.

Re: trap choices -- thanks, I understand what you mean now. However, it's not clear to me if this is actually doing what you say it is doing. Is it known for certain that adding these trap choices really reduces problems, and reduces them for the right reasons? My gut feeling is that we're just making life difficult for our users, as opposed to educating good faith users about what they should be doing.

We're going to have a licensing tutorial, however, we can't expect people to read anything, so maybe something like a "fair use" trap choice in the license widget will end up being useful. There are some very common and silly notions about "fair use" and "public domain" and we have to be realistic about the vocabulary we use and what it means to our potential users.

That said, we're making uploading so easy that a user determined to falsify a license will not have a lot of problems.

Perhaps we should focus our efforts somewhere else. At places like Flickr, a new user is monitored more closely during their first uploads. Could something like that be helpful? That's out of scope for this project, but we can think about it for later.

NeilK 23:25, 19 July 2010 (UTC)

Feedback (2)

Copied from IRC chat:

• Upload doesn't complete

[00:29] <siebrand> first impressions: nice n00b interface, indeed.
[00:29] <siebrand> uploading two files, 1 preexisting.
[00:30] <siebrand> in the preview I get distorted image ratio (my image was square). Might make me wonder if something was wrong with my source image.
[00:30] <siebrand> the upload is stuck in phase 3
[00:30] <siebrand> using Dutch interface - it's incomplete, I know, but I can read through that ;)
[00:31] <siebrand> have two spinning balls on screen for over a minute now for 2 3k files.
[00:32] <siebrand> rc now shows as uploaded, but the page doesn't end.

• Eh? The file names do not look like the ones on my hard drive. I uploaded 01.jpg and 02.jpg, and RC shows me File:Siebrand 1277245629035 02.jpg and File:Siebrand 1277245622313 01.jpg‎

Siebrand 22:35, 22 June 2010 (UTC)

The interface isn't handling posting errors gracefully yet. The priority was to get a sense of the interface should be, and error handling was left out for the time being. So, something happened (not sure what) and it failed.

The reason why you see autogenerated filenames is a temporary behind-the-scenes hack. As you notice we are uploading files and only afterwards adding titles. The easiest way to do this (for the interface prototype) was to upload them under a guaranteed-unique name and change them later. In the final version we will probably hack up something based on stashed files instead, so the files will not become actual File: entries until they are ready. NeilK 18:32, 25 June 2010 (UTC)

Categories!

I just tried this and it's kick-ass. That's my official opinion. :) The only thing I find missing is the option to add categories (or free-form wiki-text). It would be annoying if you have to edit the page after uploading to add categories. There is a nice JavaScripty category-chooser which would work well with this set-up, I think. --Pfctdayelise 14:05, 9 July 2010 (UTC)

Originally, we wanted to have a widget that suggested categories for each file based on the description. Such a feature would be too complicated to implement, however we'll add a hotcats-like category adder that would work à la SimpleSearch, i.e. not only autocompletion but displaying categories that match the letters entered, wherever they appear in the category's name.

For the free-form text, there's an "additional information" field for free wikitext in the "more options" box. guillom 21:06, 9 July 2010 (UTC)

There are already extensions that do that sort of thing for categories, why not work together?

File page name - using the existing filename

A minor point, but maybe an important one - the fact that the image is uploaded using the original filename, and then moved, is obviously not very neat, and also perhaps a kind of privacy risk? I certainly don't expect files to be uploaded with my original title, and it could be that they have fullnames or some other private details in them. It might be enough to just move the "Title:" box to the first page, and use it directly. I think that would be OK. --Pfctdayelise 14:08, 9 July 2010 (UTC)

The current situation is an artifact of the prototype; the final implementation will be cleaner. guillom 21:06, 9 July 2010 (UTC)

Some observations

Using the wizard for the first time (using Firefox on Mac OS X 10.6)

• Is the layout and text final or will there be a newer version? It seems pretty bare-bones right now. I guess the first sentence "Welcome to Wikimedia Commons" is not really relevant: i know that already by entering from the home page. I like the second sentence, maybe it could be highlighted more.
• I like the four steps layed out on top. Gives a good indicator of what you need to do.
• 'Click here to upload a file' is not a button, but a hyperlink without any visual indicator (e.g. the mouse cursor changing into the 'hand' when doing a hover) that you can do something with it. The same is true for the 'Add another file' button (which isn't a button, but a hyperlink)
• What does the grey background mean on some of the files in the 'to-upload' list?
• When i upload two photos at about 50% of the process i get an alert box with the message 'Failure!', which is a) not very descriptive and b) doesn't indicate if i can do anything about it
• Apparently my second file didn't upload, but there is no way to go back to the previous step and try again.
• On the 'Release rights' page i think you might want some way to get help on terms. What's a 'license'? How can i find out what source and author(s) are for a specific file? What are all these 'Creative Commons' licenses? The current upload page has far too much information, but it would be good if you could get more specific information.
• The 'description' page isn't aligned and layed-out properly. I like the fact that a date is selected for you and you can easily select something else.
• On the 'description' page i see an empty image, where i suppose my second image in the upload process (with the 'failure' alert box) should be.
• I like the small green information boxes i get when i click on certain input fields. Nice! Although i would like some indication that i can actually get more information (this is also true for the 'Release rights' page). Maybe a small question mark or something.
• I also really like how the state of required fields is automatically updated when you enter more information, such as the warning about a 5-character minimum for descriptions goes away when you are typing.
• I like the textareas on the 'Use' page. Maybe a quick 'copy' button would be nice that you sometimes see on websites. A *really* nice addition would be some suggestions (maybe on the basis of the description) of articles that the image could use.
• Where did the categories go? That was actually one of the few things on the current upload page that's mostly decent.

Keep up the good work. Very interested to see this progress in the following weeks. Husky 14:09, 23 July 2010 (UTC)

I agree with most of your criticisms, and we're working on it. Here's just some additional info:

• Nothing's final but this is close to what we want.
• The "click here to upload a file" is a rather complicated beast. In other HTML-based multi-file uploaders there has to be two clicks; one to add a file input field and the second to add the file. This one only requires one. The tradeoff is that in some browsers, it was impossible to make the cursor do the right thing. Very few people notice this. We can make it look like a button but so far we have had nobody misunderstand what they are supposed to do.
• The background for files alternates between white and grey. It'll be more obvious why when I finish this.
• The error messages are placeholders for now.
• To my knowledge, in current browser technology, it is impossible to make a "Copy to clipboard" button without using Flash.
• What's wrong with the layout, exactly?
• The categories are right there, in the Describe phase. I agree that the current Commons category interface, HotCats is very good, but its usability could be improved. Lupo recently added even more experimental bells and whistles to HotCats but at the cost of having a somewhat bewildering interface. I'm working on a new categorizer called CoolCats which will attempt to do most of what HotCats does with a less surprising interface.

Thanks very much for taking the time to check this out and offer feedback, it really matters.

NeilK 20:31, 23 July 2010 (UTC)

Some critical observations

Having uploaded two photos just now, I remarked that the license options are very limited. For instance : OTRS authorization is lacking or it is not possible to use the license PD-author.

Another remark. I have uploaded thousands of photos to the Commons. In many cases several photos uploaded in a row contain about the same text with some small differences. After uploading the first of such a series, I used to go back, import the next photo from my hard drive and change the text in the upload form if needed. This saves me a lot of time, preventing the use of a new upload form and entering a new text. This seems no longer possible.

Otherwise, this new upload wizard seems OK to me. JoJan 18:35, 23 July 2010 (UTC)

Loading icon

I tried to use the Upload wizard, but I cannot get it started at all. I use Internet explorer 7 on Windows XP.

• it shows a blank screen with an indefinite timer ()
• at the bottom a script error is shown (line: 7 Chr:1317 Error: Expected identifier, string number Code: 0 URL: http://commons.prototype.wikimedia.org/wiki/Special:UploadWizard)

HenkvD 09:48, 24 July 2010 (UTC)

(Moved from http://commons.prototype.wikimedia.org/wiki/Talk:Main_Page )

I don't know if it's just my "fault", anyway the upload wizard is currently not loading for me (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100621 Ubuntu/9.10 (karmic) Firefox/3.6.4): it shows the loading icon (for an hour or such) but nothing happens. --Nemo bis 09:01, 22 July 2010 (UTC)

Any news on this major bug? HenkvD 12:12, 5 August 2010 (UTC)

The current placeholder for it is bugzilla:24709, I suppose. --Nemo 09:50, 7 August 2010 (UTC)

translations

what about translations? --Olli 14:02, 26 July 2010 (UTC)

As a MediaWiki extension, the Upload wizard is already available for translation at http://translatewiki.net. We just prefer not to advertise it for now, because we're still changing the reference messages. guillom 16:48, 26 July 2010 (UTC)

Confusing messaging

A couple minor issues:

1. The initial link "Click here to upload a file" doesn't actually upload a file. This makes it somewhat confusing when you have to click on the "Upload files and continue" link to continue. My initial thought is "But I already uploaded the files". Either the initial link should say "Select files to upload" or the files should start uploading immediately after being chosen.
2. When you first load the Release rights page it says "Set a license for the above file:" and then asks you to pick whether you own the file or not. This is confusing since choosing whether or not you own the file is not setting a license. It only makes sense after you've chosen one of the options and then it displays the licensing info. I would suggest either deleting the "Set a license for the above file:" text or replacing it with "Choose one of the following:".

Kaldari 00:47, 5 August 2010 (UTC)

Right, thanks for catching that. We're currently working on refining the UI and the messaging, but I definitely need to add that in the Q&A page so people know. guillom 00:52, 5 August 2010 (UTC)

Derivatives of Wikimedia Commons works

I tested the new Upload Wizard: apart from several issues the FAQ says will be fixed, my main concern is that I want DerivativeFX to be improvedreplaced with something better, especially for works already in Wikimedia Commons. I want to be able to click "this is a derivative of a work from Wikimedia Commons", specify the name of the file it is based on, and upload - without being harassed with all kinds of check marks that have to be checked or unchecked to allow the upload and avoid putting bot-messages in other files that I haven't thought about (how many notes about "retouched photos" does a blank map need?). And without having to mess with a description that starts by default as a description of the other file. The description I type in should be simply my statement of how I altered the other file, period.

A more general derivative interface probably should also exist for non-Wikimedia files, though I think the point might fairly be made that if a file is worth your making a derivative of it, and has a license suitable for upload, then you should upload it first, then relate your derivative to it afterward. Wnt 13:25, 15 August 2010 (UTC)

Metadata

In the interests of privacy, I think the upload wizard should announce all metadata (such as EXIF) and any watermarks detected before any permanent record is made of the upload.

I also think it would be quite desirable if option can be provided to (a) automatically remove all metadata, (b) preserve all metadata, or (c) automatically strip out unrecognized metadata, which may contain serial numbers and the like - preserving only the bare basic information that can be recognized by the template that displays the metadata on Commons, such as the exposure and aperture settings. This option should be available at the time of upload but its default might make a good user setting. Wnt 13:32, 15 August 2010 (UTC)

Installing

Why isn't there any instructions on how to install this?? I uploaded it and it doesn't appear.

Help???