Last modified: 2012-05-22 23:40:53 UTC
When the user adds a category to their uploads, they have to explicitly click the "Add" button to save the category, otherwise the category is not added when they move to the next step. Some users don't realize they have to explicitly add the category they entered in the field. One way to handle this would be to automatically add any category that is in the "category" field, but hasn't been manually "added", when the user moves to the next step in the wizard/
I agree, I fell into this trap myself. Just uploaded as set of images, copying the category to each. Not a single category was stored in the end. In my opinion, the normal logic of html forms is that the field, if filled, is actually submitted, and the button ADD adds another other line/field.
At the very least, it should note an error on submitting if it seems the user hasn't added a category.
Perhaps, but friendly. Many potential contributors will not understand the category system. But still: this would not resolve the user-interface bug that in most other web sites the "add" button would refer to "add another empty field", not to "mark the text already entered to be actually added to the submission".
Gregor: I am not convinced that users are more familiar with forms that mutate themselves and add new fields. That's pretty rare. However, the widget could work better. Or at least it should notice that a category has been left un-added. The main problem is that we have to be ready for categories that have spaces in them. Other 'tagging' interfaces use the convention that when the user presses space, the tag is complete. So they either convert a textarea of space-delimited tags afterwards, or they transform the text as you type it. However, our Categories have spaces within them, and we want people to mostly use pre-existing Categories, so we want a single field that autocompletes. And we need some signal that the Category name is complete, that isn't shown by typing whitespace. Hitting return would be worse since that's the convention for submitting a form. So that's why there is a button. I tried to avoid this button but I couldn't see how. If anyone has a better idea please make it known.
Perhaps the "add" button should light up if there is non-whitespace in the field? That would give the user a visual clue.
There are two issues here: a) a button exists to modify a form, adding a new field. That is in fact very common and a standard feature of semantic mediawikis using semantic forms (i.e. almost all). b) if adding a single category: several text fields in the form are filled, the form submitted, but the content of one field (the category) is silently ignored. The second is the problem. It seems the key is the requirement "we want a single field that autocompletes"? I would use jquery.blur() for this - but I have not made the analysis in any depth, so there may of course be reasons why this does not work. Or it can be added to the submit button - before submitting, any non-existing categories are checked a must be verified in a dialog.
(In reply to comment #1) > In my opinion, the normal logic of html forms is that the field, if filled, is > actually submitted, and the button ADD adds another other line/field. (In reply to comment #3) > in most other web > sites the "add" button would refer to "add another empty field", not to "mark > the text already entered to be actually added to the submission". I agree on this. The first time I encountered this "click {add} to save form value and reset input field" system was on Commons with the HotCat gadget, I didn't like it there but it's something you can get used to. However during uploads I dont think there should be any component that requires "getting used to".
I agree as well, also with (comment #4) > Or at least it should notice that a > category has been left un-added. This is especially annoying when uploading multiple files: because of bug 26065 you'll surely copy and paste to insert metadata and then all categories will get lost. This happens also if you copy and paste the category from the category description or another file or whatever, though.
I made the mistake too and I'm pretty sure I'm not the only one. If the field is non-empty we could just add a tracker category to do some statistics. Just have this modification running for say a week <tracker category> / Category:Uploaded with UploadWizard * 100 = <some percentage> % That will give us some metrics on how often this happens.
(In reply to comment #9) > If the field is non-empty we could just add a tracker category to do some > statistics. Just have this modification running for say a week <tracker > category> / Category:Uploaded with UploadWizard * 100 = <some percentage> % > > That will give us some metrics on how often this happens. Good idea, especially to get metrics! I interpret the above: If category has not yet been verified, add both the category and a hidden category like "Unchecked category from Upload Wizard" - right?
I disagree that the right answer here is to get metrics. It's a nice idea but I just don't have time to make a research project of this. We should just solve the problem. One possible solution was to auto-add categories if they haven't added them. I don't agree with this because: 1 - We also want to check for newly created categories and warn them this is a bad idea 2 - I have noticed that some users also type multiple categories into the field, space separated or comma separated, and this isn't correct either. Another is to have a multiple input box field. Personally I think these have rather poor usability. The widget I made (mwCoolCats) is designed to emulate similar interfaces around the web, particularly Flickr's, so there is some precedent that this can be useful. I think this is the solution: There is already field validation on the page. On submit, we can simply look for category widgets where the field is filled out but the button hasn't been pressed, and highlight those in red, saying they should press the "add" button. If there are other problems with their Category, they can fix them as they are entered. That should solve almost all the problems we currently have.
(In reply to comment #11) > I disagree that the right answer here is to get metrics. It's a nice idea but I > just don't have time to make a research project of this. We should just solve > the problem. Not sure the effort is big: blindly adding the category submitted rather than ignoring it plus a monitoring category should be the work of how many minutes? People are adding categories by entering them, not by clicking an add-another-field-button. The clicking-a-button is rather the secret knowledge of the programmer. But as long as we can have no hard data to test, we are just speculating. Not a good method. > The widget I made (mwCoolCats) is designed to emulate similar interfaces around > the web, particularly Flickr's, so there is some precedent that this can be > useful. I strongly disagree. The Flickr interface your refer to is completely different in that it is NOT embedded in a form with a SAVE/Upload button, but it appears after the upload so that the submission button IS the Add-button. Note that the equivalent to the mediawiki upload form itself has in flickr a field "Add tags to the whole batch?" This is a normal text field which does not require an extra button click. I maintain that the Commons upload form violates all user interface expectations. If you follow your planned solution, please report the errors after checking the submitted categories first. Having to fix the categories which don't exist would make sense. Getting an error message that all categories are correct, but you have to click on a button for each file anyways (which is what you describe) seems Kafkaesk.
http://commons.wikimedia.org/wiki/Commons:Village_pump#Media_needing_categories/Commons:Village_pump#Media needing categories, here u see some statistics. The upload wizard should tell the uploader that he is saving without a category, we get too many media Category:Media needing a category this way.
(In reply to comment #13) Sorry messed up the links. This bug floods the CategorizationBot, we need an emergency patch. > http://commons.wikimedia.org/wiki/Commons:Village_pump#Media_needing_categories > Commons:Village pump#Media needing categories > User talk:CategorizationBot#Images categorized when I uploaded them > Category:Media needing categories
The key should be bigger, with "Please confirm the category" on it, instead of just "OK".
RE metrics: In June, I estimated that 25% of the files uploaded through the Wizard were uncategorized. Details at [[Commons:Commons:Village_pump/Archive/2011/06#Upload_Wizard_keeping_files_from_being_marked_as_uncategorised]]
Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734
There are a lot of people complaining about this including myself. I think this is really bad because I'm a very experienced user and even I thought the "Add" button is there to add a second category. What I ask is very simple: If I enter something in an input field and press a button ("Next" in this case) the script should not ignore what I entered. From what I see the solution is very, very simple: Add a handler to the "Next" button. If "Next" is clicked but there is something in the category input field, cancel the "Next" click and do a click on the "Add" button instead. That's all. The "Add" button will do the rest. This and other problems (many are minor, some are major) are described here: http://commons.wikimedia.org/wiki/Commons:Prototype_upload_wizard_feedback#Not_usable_at_all_due_to_security_errors_and_other_exceptions
Just add the category when the input-(of type text) field is left. - The onblur-event. http://api.jquery.com/blur/ No big deal.
Hello? Somebody reading this? From all bugs I reported (new one: comment in the file history is always empty, see feedback page) this is the most serious. You tell us Upload Wizard is about being accessible and easy to use. Currently it simply drops and ignores what the users enters in the category field. The "Add" button is confusing. As said multiple times now, a lot of users don't press the Add button because they do not want to add a second category. They want a single category only, enter some text in the category field, choose something from the selection that shows up and press "Next".
As a temporary workaround for this bug, I've edited [[:commons:MediaWiki:Mwe-upwiz-categories-add]] on Commons to show "Save category" instead of "Add". This doesn't solve the underlying issue, but hopefully more users will think of saving the category.
We're getting tons of complaints at Commons. Would be nice if this could be solved.
Created attachment 9150 [details] Automatical add categories if the user forgot to hit the button. Don't add them when autocomplete/ suggestion-list is open.
Patch reference path: http://svn.mediawiki.org/viewvc/mediawiki/trunk/extensions/UploadWizard/resources/jquery/jquery.mwCoolCats.js?revision=96918&view=markup
(In reply to comment #21) > As a temporary workaround for this bug, I've edited > [[:commons:MediaWiki:Mwe-upwiz-categories-add]] on Commons to show "Save > category" instead of "Add". I did the same for the German translation at translatewiki.net. From my point of view "Add" is misleading because it does not add a second category input field. What it does is submitting whats in the input field. So "Save" is a lot better, I think. As you said, this does not solve the problem. Whats wrong is the interaction design. "Add" should add a second input field for a second category and all input fields should be submitted with the "Next" button. The problem is that the categories need to be confirmed THREE times: 1. Enter some letters. 2. Confirm by choosing the category from the drop down list. 3. Confirm by pressing "Add". 4. Confirm by pressing "Next". All other input fields are only confirmed once by pressing "Next".
My Summary: Many people and Wikipedia communities agree that the bug should be fixed. A patch exists, but it is not applied because the original developer has a different view of good user interfaces. I would wish we could bring this to some conflict resolution mechanim - perhaps WMF could apply to an external web user interface design expert? Should we encourage everyone we know to vote on this bug -- perhaps if MANY people to vote it gets attention?
Don't you think there are enough votes on the feedback page just from the (possibly few) people who took notice of this bug and reported it? http://commons.wikimedia.org/wiki/Commons:Prototype_upload_wizard_feedback
I am not sure mediawiki developers transfer this. Presently only 3 people have voted for this bug on bugzilla. But then I am not sure whether voting will catch attention.
Adding Neil since I *think* he is the one who should take care of this
Working on it. The patch won't be useful as we need to block on this error, since yet another thing could block when the category is added. (It could block on confirming if you want to add a new category. With the patch as written, the wizard just proceeds blithely on and ALSO shows the dialog asking for confirmation.) Starting with a new approach centered around blocking validation.
Marking patch as reviewed. Neil has stopped working on this so it's available for anyone else to take over.
Slightly improved the patch, then started code review: https://gerrit.wikimedia.org/r/7138
Various improvements made in CR; the warning about new categories is now passive and the 'add' bit looks/feels much more like the description adding. Merged in 0f4f74c32fbf0235a1cb60f53cc40d302cac1674
