Last modified: 2014-05-01 08:07:25 UTC
The present workflow for users on http://commons.wikimedia.org/w/index.php?title=Special:Upload&uselang=ownwork is : Learn > Describe > Release rights > Upload > Use I don't see the reason why this should be changed. I don't see why we should invite a user to upload a file, if he finaly realizes that he is missing some key information (for example he can't remember whether he took the picture with his own camera or he borrowed it from a friend) and can't go to the final step. The detailed steps on http://commons.wikimedia.org/w/index.php?title=Special:Upload&uselang=ownwork are: Step 1. Is this your work? Step 2. Help people find this file. Step 3. Select a Free Content license for your work. Step 4. Has your work been published before? (if so, help us verify that this is a rightful copy) Then (we might call this step 5) the user fills the form Then (we might call this step 6) he clicks on the "upload" button. This should not be changed unless a community consensus is reached on Commons to change it. I have never heard any request to change this, so I am suprised with this sudden change.
http://usability.wikimedia.org/wiki/Multimedia:Upload_wizard/Questions_%26_Answers#Why_do_you_allow_the_user_to_upload_without_first_asking_for_a_license_.2F_author_.2F_description.3F
Folengo: in addition to the FAQ item: It's not obvious that there ever was a "decision" to arrange things as they were before. There was really a one step process, and as people thought up new things for the user to do they simply got added to the form or the maze of links you had to navigate before the form. Our user research is *very* clear that people find it easier and more satisfying to upload first. That said, I am not convinced we have the ideal flow now either (we educate the user about licenses in general on step 1, but then ask them to make a detailed decision on step 3) but that's a different issue. Changing status to INVALID as this is not actually a bug. WONTFIX is for stuff that's actually a bug but that (for instance) won't be fixed until a subsequent version.
To Guillom : When you say "This wouldn't be possible in all browsers if we didn't upload the file first"(1), you confess that you prefer to create a tool with a defective workflow (allow the user to upload without first asking for a license / author / description) because of some technical limitations. So you are caught doing the very thing you denounce a few lines lower saying "Much of the complexity of the original form was in explaining how to work around various defects of the form itself". Instead of creating a series of browser-specific tools that could work well, you prefer to create a single defective tool that can work with more than one browser. Where is the benefit in replacing an allegedly defective (3) form by a defective tool ? First create something that works perfectly for Internet Explorer whose market share is the largest (2). Then, if it is OK, let's create another similar one for Firefox, Chrome and the other browsers. (1) http://usability.wikimedia.org/wiki/Multimedia:Upload_wizard/Questions_%26_Answers (2) http://en.wikipedia.org/wiki/Usage_share_of_web_browsers (3) I am not at all sure it is as defective as you say
To Neil : "Our user research" What is the value of a secret unpublished non-peer-reviewed research ? Nothing. This mere rethorics. Part of the purpose of the upload interface is educative : teaching users what is an acceptable upload, and what is not. You don't decide a classroom's education program by conducting a poll among pupills about what they want to do. Pupills are naturally lazy and many would say that they want to play instead of studying mathematics or science. Education implies a part of authority. (Folengo is an old e-mail name, a consequence of "We recommend using a secondary account or free web email service" from https://bugzilla.wikimedia.org/createaccount.cgi ; My user name on Commons is Teofilo. See also my other comments at http://commons.wikimedia.org/wiki/Commons:Usability_issues_and_ideas#Upload_Wizard_test )
I have nothing against a tool dedicated to advanced users that would have any bizarre workflow, if that tool can give advanced users new powerful functions (such as fetching some metadata from the EXIF, or IPTC from a JPG). But if you intend the tool for beginners, the logical order should be respected. When you open a new savings account at a bank, do you give your money first, and only then discuss with the bank the terms and conditions by which the bank can use your money, such as the interest rate ? When you go shopping, do you give your money first, and choose which item you buy only after ? What happens if you find out that all the food in the shop is stale ? You have lost your money. And that shop keeper is a crook. When you install a new software on your computer, does the install wizzard install the software first, and finally requests you to agree with the terms and conditions after it is already installed ?
Hi, I was asked, as one of the authors of the prior commons procedures, to comment here. It's alleged upthread by Neil Kandalgaonkar that the prior process arose without consideration. This is a mistaken impression which could have been dispelled with only a moments research into the origin of the existing uselang wizard workflow. A key and explicit criteria behind the design developed by our community was _always_ to place high prominence on the mandatory criteria such as licensing and metadata. The reason behind this is simple: A large part of the value of the commons repository is its purity. There are a great many other image repositories out there, some much larger than commons, but most are stuff full of fraudulent licensing claims and incorrectly described media. The commons community would rather forgo some useful contributors in the short term— trusting that our repository will continue to grow regardless and will eventually replace these lost works— in exchange for keeping the repository clean as it's very difficult or often impossible to obtain licensing status or meta-information after the uploader has completed their part of the process. It appears the that the planning here has neglected to understand how the commons community— the creators and maintainers of this shared repository— understand its value, and that disappoints me greatly. Usability is important, but it is meaningless if it must remove our unique value in the process. The discussion above and on the FAQ makes it sound like the process is being guided by people who regard usability as an end in and of itself. '"Traps" currently in use on Commons aim to identify unfree content; we would like to empower users to make that choice consciously'. There isn't much of a "choice" here. Certain things are permitted, other things are not. Some of the restrictions stem from the laws and regulations of the various places we serve and operate from and we have no control over them (other than our decision to abide by the law and decision to include improved lawfulness of our collection as one of the values we offer our users). I'm skeptical of your ability to actually study the effectiveness of tutorials except in-situ, as in a study environment people will be more likely to read the instructions than someone who is simply acting with a simple goal ("get this image posted") in mind, especially when the instructions ultimately tell the person "sorry, you can't post that image". We know from experience that instructions have value but that value is bounded. The traps exist not to reduce choice, as there was no choice to begin with. They exist to gauge understanding. If the tutorial is very effective then the traps should have no effect. Concern about the traps is easily viewed as a lack of confidence in the processes ability to educate new contributors. However, I don't really share all of the concerns opposing the new ordering specifically. We know from experience on commons and the larger Wikipedias that the workflow which allows people to submit material only to later find it deleted when they failed to meet some obscure criteria creates a lot of ill feelings. I expect the revised ordering to cause this on commons, but we _already_ had a significant problem with that due to people simply clicking until the upload completed (and thus the trap options). The fact that we warned them a lot might ease our on conscious but I doubt it makes anyone less angry. So, I think that the reodering will likely be a null effect. People will continue to upload material which doesn't meet the requirements, we'll continue to delete things once they've been uploaded and continue to piss people off who didn't read the instructions carefully. I could even argue that getting the upload out of the way first will encourage fewer people to push through the forms blindly, the results will be interesting.
I understand there are strong differences of opinion here, but I think that you may be under a misapprehension of what UploadWizard does. 1) Are you aware that for UploadWizard, we first upload the file to a special "quarantine"? It is not actually published on Commons unless and until they assign a proper license. So the question of whether we do license first or upload first has no practical importance, and we can consider it only on the basis of usability. This was a key insight that we made early on -- the upload process was in thrall to a model that required all the information at once, or bad consequences would ensue. So we made it so bad consequences would NOT ensue we changed the order of things. Incidentally, we also made that choice because we envisioned an interface where other Wikipedians could work with the uploader to improve the "quarantined" data and licensing until it was finally ready to publish. That proved to a be a little too ambitious for 1.0, but I'm trying hard to create a system that can support such a use in the future. 2) As for the value of our research, all of it is online. Guillaume posted some highlight videos on his blog. http://www.gpaumier.org/blog/691_wikimedia-multimedia-ux-testing-videos/ (I believe there are full videos available somewhere if you want to watch the whole thing.) Usability testing is not an exact science, but once you see five or more people crash and burn on the same interface, one gets an idea where the problems are. We specifically tested if the current upload interface was helping anybody understand what the restrictions on Commons were. If my memory serves we got precisely zero correct responses. Even the one person who was 'geeky' enough to get through the current Commons interface with little difficulty did not fully understand what Commons was about by the end of the process. (Incidentally, the independent testing company we hired suggested that we should not even bother with further usability testing as our prototype was vastly superior. However, conscious of the community's skepticism, we insisted on full user testing.) So, while it is true we have only incomplete research on our approach, it is equally true that all of the research at our disposal contradicts your assertions that the current Commons form is working well. a) the current Commons interface is VERY difficult to use, even by experienced computer users. b) the difficulty is not justified by any greater understanding imparted to users about Commons' licensing needs or other benefits. I do not want to diminish the practical experience that Commons admins have. It definitely is a common perception that complex upload form = better submissions. However, I am skeptical that this really is the case. While it probably repels Tumblr-style "I found it on the internet" reposters, it also eliminates 99% of the population. This is a bit too high of a price. And in my estimation, the remaining 1% are not necessarily more likely to be acting in good faith either. You've just trained the people acting in bad faith to provide metadata that undetectably simulates good faith contributions. But anyway, this is just my speculation for now. When UploadWizard is enabled it will be interesting to see what changes there are in the character of uploads. We will be monitoring the situation and will make changes if the balance seems to be tipping in a bad direction. Also, one remaining area for research is whether our new tutorial works well enough. We had planned to a subsequent research round but for various reasons (time, money, project scheduling) have not done this yet. This may still happen.
Finally, I'd just like to restate that we don't really know if UploadWizard (in its current form) is the total answer to our problems. But there is a definite usability issue with Commons uploading, and this is our attempt at a partial solution. If and when it is finally introduced as the default interface, or in some A/B test, we will be monitoring the situation closely, and we hope those in the community will work with us to iron out any issues.
(In reply to comment #8) > Finally, I'd just like to restate that we don't really know if UploadWizard (in > its current form) is the total answer to our problems. But there is a definite > usability issue with Commons uploading, and this is our attempt at a partial > solution. > > If and when it is finally introduced as the default interface, or in some A/B > test, we will be monitoring the situation closely, and we hope those in the > community will work with us to iron out any issues. I don't see anything "invalid" about this bug, so I'm re-opening it for now. When there's actual evidence that the new UploadWizard's interface and processes work better than the current Commons' model, it _might_ make sense to mark this bug as "resolved." Right now, there's a lot of talk, but there appears to be very little actual evidence to support the claims being made. ("Evidence" is being used here to mean that there is hard data available to be reviewed by the Commons community and others.) Personally, I think allowing a user to upload a file and then asking them to release the rights seems like a workflow (and possibly legal) issue: if the user doesn't first understand the upload agreement, how can they possibly enter into it or modify the terms later? It also does seem completely counter-intuitive and backward. In addition to these issues, there's the issue alluded to in the opening post about whether or not this change was even desired by the Commons community. There's been no evidence to suggest that the process that Commons designed and implemented is ready to be replaced by the Commons community. While usability is great, so is wiki sovereignty. If the Commons community wants to keep their upload form the way it is (even if it's awful), it really isn't the place of Wikimedia (backed by a grant or not) to overrule them.
Speaking only as an occasional uploader of media to Commons, I expect upload forms to let me upload files right away, and then to get information from me before publishing what I've uploaded. I love the fact that the wizard supports this, it feels quite natural; a definite improvement for me. This is entirely separate from how (and how explicitly) we ask people to confirm the license under which the media is available. The introduction of a quarantine for images with uncertain licensing status is a great step, and helps reduce unnecessary deletion-churn; this is something that has come up as a requested feature at the two multimedia / GLAM events I have been to in which organizations have asked how they can more effectively upload media to commons (they have inevitably tried and failed in the past, and had their media deleted, despite clearly wanting to release media under a free license).
Marking this as an enhancement. I don't think the complaints are entirely invalid, but we can't change our fundamental approach now.
Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734