Wikimedia Bugzilla is closed!

How is this a bug?

We've talked about batch editing before, but not as a feature of this project.

It's not a bug, it's a feature request. With our current bugzilla setup, they're mixed.

This feature was in the original specs of the upload wizard. The same way the user is able to batch-edit the copyright information & license for files uploaded together, they should be able to do the same for descriptions, categories, etc.

I'm not saying we must do this before next week's launch (we realistically can't), but we do need to document this missing feature.

Neil, Note that bugzilla feature requests should be marked with "enhancement"

This is not an anticipated feature for UploadWizard 1.0. Removing blocker status. 

We will review this bug at some later time. 

My own feeling is that "batch" features may be handled in a manner completely outside UploadWizard at some point.

I think this feature should be added as well, otherwise there's not much point in multiple upload: if you're uploading multiple files in a batch it means that they probably have something in common. With the standard interface you can copy and paste everything and modify the relevant part, with UploadWizard you have to manually re-add everything except the license and this is very time consuming.
A simpler solution would be to add a button to copy the specified field (the title, the description, the category, or all of them) to all other files, or to copy it from the previous file, and then allow to modify them (but if you copy and don't modify the title you run into bug 28921).

Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734

Agree. This is probably one of the highest feature requests for a future release. I was actually kinda hoping it was in there because you *can* batch edit multiple files when selecting a license. 

Maybe the same might be good enough for the uploadwizard: only support either editing all files at the same time (per license chooser) or edit them all individually (like it is right now).

With multi-file selection implemented, this is definitely becoming a hotter feature request. Here's how I'd suggest implementing this:

For the first file in a batch of >1, show an expandable "copy this information to all the files below". When expanded, it shows four default-checked checkboxes:

[X] copy title (will use auto-numbering)
[X] copy descriptions and categories
[X] copy location data
[X] copy other information

[Copy]

The logic here is that we should allow the user to selectively copy content which can legitimately vary (locations in a batch could easily vary, but if descriptions are identical then categories probably are, too). 

The [Copy] action would be pretty straightforward, except for the auto-numbering bit. Here I'd suggest checking for the rightmost digit in the title and incrementing that if it exists, or adding a 001 format digit to the title if there isn't one, and incrementing from there.

Thoughts?

Erik, I like this UI concept.  I think categories and description should be separated, though.  While the categories will probably match for matching descriptions, the reverse may not be true.  That is, the files may be categorized the same, but have different descriptions.

The other question is, should this overwrite anything already entered in the form?  I'm thinking it should.  At least, that's what I'd expect in this case.  We could have a control for overwrite vs preserve, but I think that would add needless interface complexity.

Yeah, descriptions may be different. But there's no risk that we're either overwriting an existing description (they're never pre-populated), or that the editor wants to leave the description empty (it's required). So they'll have to touch the descriptions as part of the editing process regardless. That's why I thought it would be OK to bundle them in the copy operation.

In contrast, I might want to set the "other info" or "location" only for one image but not all.

But, it's just one checkbox difference, so it may be most straightforward to have five instead of four.

I agree that it should overwrite whatever's there; if the user doesn't want that, they'll uncheck the respective boxes.

While this would be relatively easy to implement, I think it would be a bit hard to use in practice. I have wanted to do it this way, which is a bit harder and there are some unsolved UI problems.

Replace the license and the details step with a single step.


1) Have a set of thumbnails at the top, as currently appears at the license stage. Below them is UploadWizardDetails block, including license picker.

2) Allow those thumbnails to be selectable. They start off being all selected. http://jqueryui.com/demos/selectable/#display-grid

3) The harder part:
- Change UploadWizardDetails so that it copies its information to the appropriate selected uploads on any change.
- When a new thumbnail or group of thumbnails is selected, survey the data in all the selected uploads. When there is data common to all, make the UploadWizardDetails form show that. Otherwise show blank.

4) Unsolved problem: figure out some way to recover from title uniqueness or blacklist errors. Ideally, never ever bother the user about this. Perhaps this means appending "by $username, uploaded $date $time".

Created attachment 9625 [details]
screenshot of flickr uploadr

(In reply to comment #11)

See attachment 9625 [details] for an example of this kind of interface

Yeah, a more sophisticated batch group editing interface would definitely be cool, but pretty hard to get right (revisiting some of the fundamental workflow assumptions in UW). In the spirit of iterative improvement, I think a simple metadata copy operation would already cover lots of use cases.

Patch submitted:

https://gerrit.wikimedia.org/r/#change,5958

*** Bug 35280 has been marked as a duplicate of this bug. ***

You can test this feature now on: https://test2.wikipedia.org/wiki/Main_Page

It will be deployed into production on Wednesday 5/16.

Deployed.