Grants talk:IEG/Easy Media Uploader

Please add your comments to the Easy Media Uploader proposal for an individual grant from the Wikimedia Foundation.

Related Projects

• Comment See mw:Extension:Add Media Wizard for a similar project. Jean-Fred (talk) 12:54, 25 January 2013 (UTC)

Thanks for sharing! The differences in my proposal from this, is that I'm aiming to create a wizard that supports direct uploading into the page versus searching across different media hosts to insert existing images. Another difference is that it has to be installed / enabled by the user, whereas what I am aiming for is improving the functionality of the image icon from the edit tools when you click Edit on an article page without having to do any configuration.

You’re welcome. Actually, I mentionned AddMediaWizard because it supported / was meant to support direct upload ; and it was also used directly from the image icon of the edit toolbar − before being discontinued. See commons:Help:Multimedia_beta#Add_Media_Wizard. Jean-Fred (talk) 00:45, 27 January 2013 (UTC)

Got it. The intent was actually very close to mine. Its unfortunate it was discontinued. Have any idea who started this project? Ashstar01 (talk) Ash 04:51, 29 January 2013 (UTC)

Hi, I originally developed Add Media Wizard. I don't think you could easily leverage code from Add Media Wizard. Your best path would probably be to start a new. Mdale (talk) 20:40, 30 January 2013 (UTC)

Thanks for weighing in Michael! Thats really helpful in defining the approach to build this uploader. My instinct was that leveraging the Commons Uploader would be the best approach since a lotof the UI is defined already and its more connecting the article upload tool to that wizard. Ashstar01 (talk) 17:53, 2 February 2013 (UTC)

Destination of uploads

It sounds like the goal is to build some sort of upload wizard-type device working across WMF projects. Don't forget that different projects have different rules about image hosting, and there are many images that can't be hosted on Commons, but can be hosted on, for example, English Wikipedia. This includes fair use images (en-wp has its Non-Free Content Criteria, while Commons does not accept any fair-use files) and non-US images that are still copyrighted in the source country but free in the US. An ideal upload wizard would guide users through this and help route each upload to the most suitable site. cmadler (talk) 14:15, 25 January 2013 (UTC)

Great point. This tool should definitely guide the user through the process in a way that helps them understand the requirements of each host for their photo. I think if approved, it would be important to align with the Wikimedia Foundation's goal going forward of where they want to encourage media hosting - continue with both Commons and Wikipedia or slowly limit support for uploading to Wikipedia itself. Ashstar01 (talk)

A reduced-scope of that uploader could be one handling just projects without local uploads. Even then, note that «guide the user through the process in a way that helps them understand the requirements of each host for their photo» won't be simple at all. Expect dull reasonings like "This photo is my own work and I release it under the CC-BY-SA license, since I found it on Google". Platonides (talk) 23:54, 30 January 2013 (UTC)

I think that the goal is to encourage the hosting of all images on Commons and not locally given their is a more guided process to explain copyright licensing options. I would almost instead say this tool only supports Commons uploading similar to the mobile web beta thats being tested now which assumes a default CC-BY-SA license and Commons hosting of any images uploaded. Ashstar01 (talk) 17:56, 2 February 2013 (UTC)

2 distinct things

This proposal seems to want to do 2 very separate things - cross wiki upload, and transcode to free formats. These are two very separate things. I would suggest picking just one to do. This proposal should also probably talk about current efforts in this direction. AFAIK transcode-to-free-format is part of the plan for TMH which is actively being worked on (I think, not sure). Bawolff (talk) 17:55, 25 January 2013 (UTC)

• I agree, it would be best to deal with these two issues separately. cmadler (talk) 18:05, 25 January 2013 (UTC)
• Agree as well, I deliberated a long time to decide if the media format encoding should be split out as a follow on project. Given others feel it is too broad with both, I will update the proposal to focus on the media uploading flow from the article page and submit a separate proposal for the transcoding piece. Ashstar01 (talk) 18:31, 25 January 2013 (UTC)

Mobile web

How serendipitous – uploading images directly to articles in one easy step is something the WMF mobile team is currently working on :) See Mobile design/Uploads for some documentation on our experimental image upload workflow up on the mobile Beta site. We're hoping to polish it and move it to the full Wikimedia mobile web by March. I don't know if anyone has given much thought to it for desktop yet, but having the mobile example will hopefully inspire more interest in the idea :)

I'd love to talk more with you about this – maybe at the next Engineering meetup? Maryana (WMF) (talk) 19:15, 25 January 2013 (UTC)

Yeah! I've been using the Alpha mobile site upload button with my Android phone, and it's delightful at least when my camera phone works well enough and an Alpha dragon flitting by doesn't startle me. More! I mean, context sensitive! That is, when I'm reading en:Landmarks of Hoboken, New Jersey, the upload button wizard should ask: Is this entirely my own picture not showing someone else's work of art? If no, then to a complex menu but if yes, then do I want it in:

1. en
2. Commons (Wikipedia's picture department and usually better)
   1. commons:category:Hoboken, New Jersey
   2. Other or additional categories

Or if I'm in a commons category like commons:Category:Parks in Hoboken, New Jersey, that choice ought to appear automatically in the cat list. Or if I'm looking at a picture like commons:File:Sybils Cave Hoboken jeh.jpg, is this another picture of the same thing? If yes, then offer its description and categories for approval, rejection or editing.

Though, I am somewhat surprised such a button is not showing up in the Mobile App, which for me is generally faster, and established Wikipedians should be expected to be both the people who run the app and the most frequent uploaders. But anyway, Yay, team! Jim.henderson (talk) 23:50, 25 January 2013 (UTC)

That would be great if it auto-categorized, or at least offered that from both mobile and web contexts. Ash 17:44, 26 January 2013 (UTC)

And yesterday the en mobile site wasn't doing it at all. The only upload is by the menu button which starts a generic upload to Commons. The process has no idea of the purpose of the picture, provides no categories, and doesn't offer to insert it in the article. This is not good. The default assumption, especially for the mobile user, should be that the picture is to illustrate the article that's on the screen when I hit the button. That allows easy relevance for the inexperienced who see the subject of the article and want to snap a Wikipicture. The mobile upload should not be oriented to efficient batch processing or sending up an old picture, tasks which call for more precision of license among other complications. Such jobs are better suited to the desk version which, however, should also be context sensitive and ready to guess categories and automatically insert a picture in an unillustrated article, and to link from the picture description to an already illustrated article to ease manual editing. Jim.henderson (talk) 11:14, 28 January 2013 (UTC)

Or at least it should ask if this is for article X. cmadler (talk) 13:11, 28 January 2013 (UTC)

Evaluating risks, and building on past efforts

In general, this is a good idea. There are two things that I think are essential, though, for a proposal like this:

• Identify, evaluate, and discuss the potential downsides or risks to this. The main one that comes to mind is what Derrick Coetzee said on Commons (permanent link) -- if a tool like this were to result in far more copyright violations or otherwise unacceptable images getting uploaded, how could that be handled? How could that be avoided through its design?
• Identify, evaluate, mine ideas from, and reengage past efforts to do similar things.

The main past effort resulted in the Upload Wizard on Commons. The Multimedia Usability Initiative from a couple years ago, funded by a grant from the Ford Foundation, launched with an intensive meeting of Wikimedians in Paris to deliberate improvements, and the Upload Wizard was the part that was implemented. We published a report here on Meta: Multimedia usability project report And there is a page with lots of useful detailed info here: usability:Multimedia:Hub. If you haven't already, I'd strongly urge you to dig through those outputs and think about how they apply to your model, and comment on how your project aligns with the goals identified there (or, if that doesn't seem right to you, comment on why you don't think it should).

Finally, I think you will need to put together a more detailed budget before this goes forward, to help others understand how you arrived at those numbers and why they are the right amounts.

None of this is meant to discourage you from what seems like an excellent, and much needed project! I would love to see something like this developed and implemented, as long as the kind of things I've mentioned here are addressed. -Pete F (talk) 02:55, 27 January 2013 (UTC)

Thanks for pointing these things out Pete! I'll definitely go back and clarify the budget. I added a related projects section to illustrate past and current efforts and can certainly add how they overlap or are different from what I am proposing. I would appreciate your endorsement once updated if you feel this is a worthwhile idea to pursue. - -Ash Dewey (talk) 04:08, 29 January 2013 (UTC)

I should be clear, I'm really no authority on the budget -- it's really just a guess that more detail will be requested. So don't put a lot of work into that before somebody more qualified to comment weighs in :)

I will try to keep an eye on this page and add an endorsement as it starts to feel more complete. Feel free to ping me if there is a significant update and you don't see me responding.

Also, in case it has not been said: I do notice that you have volunteered to contribute your product management services pro bono. Regardless of where this goes, I think you should be commended for your generous offer to the Wikimedia mission. It seems like a huge task, and I am very impressed that you would dedicate such a big chunk of your time to something like this. -Pete F (talk) 23:31, 29 January 2013 (UTC)

Easy Media Uploader vs. Add Media Wizard

As discussed above, this proposal is extremely similar to the Add Media Wizard. Could you explain why it would be desirable to spin up an entirely new project rather than updating/completing the Add Media Wizard? Currently the proposal explains this by saying "I am aiming for an editing tool versus a Wikimedia plug-in implementation to ensure wide access and accessibility". The Easy Media Uploader will need to be implemented as a MediaWiki extension, just like the Add Media Wizard, and most of the features of Easy Media Uploader seem to already be covered in the Add Media Wizard. As a co-developer of the UploadWizard, I'm very skeptical that an entirely new project like Easy Media Uploader could be completed in a month (or even 2 months). I'm afraid that the project would end up 90% complete, but never polished enough to be deployed (just like Add Media Wizard). Wouldn't it be better to complete the project that already exists (possibly as a fork)? Kaldari (talk) 20:07, 29 January 2013 (UTC)

Ryan, thanks for taking a look at my proposal. I definitely want to build off of any existing work that has been done to create a framework for uploading from the article page. From what I understood of the Add Media Wizard from the documentation I found off of this [[1]] described the main utility of this wizard around searching and selecting existing media and I couldn't find any documentation of flows that illustrated the upload flow of new content. Forking what exists is certainly an option that we can decide on if this this project is selected and we have engineers and the community onboard with the proposal. I would love to chat with you more about your thoughts on the scope of this project given my plan was to leverage the existing infrastructure developed by the Wikimedia Commons upload wizard and focus around integration of it on the article page. I adjusted the timeline to span 3 months and adjusted the budget accordingly based on your feedback. The goal is to get this project completed using whatever existing work that has been done. Would you be interested in being an advisor on the project given your background and knowledge of previous efforts? 50.152.140.27 19:10, 30 January 2013 (UTC) Ash Dewey (talk)

My understanding is that the upload functionality in Add Media Wizard was basically just pulling in the UploadWizard. I don't think it had a unique uploading interface of it's own. Unfortunately, I was never involved in Add Media Wizard and don't have any experience using it. I'm not sure how mature it was or how much it has bit-rotted in the last two years (the last update to it was 12 March 2011). Probably the best thing to do is to see if you can get Add Media Wizard running on a local mediawiki installation and evaluate it there. I don't think I would be comfortable endorsing this project without seeing an evaluation of Add Media Wizard, as this could potentially have a big effect on the direction of your project. It may be that Add Media Wizard is too old to be useful or doesn't provide a good interface for uploading. But it might also be a good starting point for your project and possibly reduce your development time substantially. If the project is funded, I would be willing to be an adviser. You might also want to try getting in touch with Michael Dale, the developer of the Add Media Wizard. Kaldari (talk) 19:48, 30 January 2013 (UTC)

BTW, the maximum IEG grant amount is US$30,000. Have you considered reducing the scope of this project to just doing the interface design and no actual coding? I think having a professionally designed interface spec would be very useful on its own. It could then be picked up by WMF developers whenever such a feature is actually developed. Kaldari (talk) 19:57, 30 January 2013 (UTC)

I will try to get in contact with Michael Dale to better understand current state of the Add Media Wizard. I think the most important part of this proposal is the engineering work as there is a lot of UI I would be borrowing from the mobile upload wizard work and the Commons upload wizard (if not re-using most of that wizard) so I fear this project will never happen unless someone drives the initiative to implement versus just design a UI. Thanks for the budget tip, re-adjusted the budget again by removing the media campaign costs and will hope to get a better sense of scope after talking with Maryana about the mobile work and Michael around his project. Ash 20:15, 30 January 2013 (UTC)

I think reusing the Upload Wizard (preferably adapting it where needed) should be the way to go. And obviously, working from Add Media Wizard (which is likely to be suitable). Platonides (talk) 23:50, 30 January 2013 (UTC)

The Commons Upload wizard correct? Agree. I think they've done a lot of the rights management work in the flow that would carry over to the article context. Ash 03:47, 31 January 2013 (UTC)Ash Dewey (talk)

Concerns

Make sure to figure out all the possible issues, like it should not allow Google found images, duplicate files by scanning metadata info. And to have different options for free-media, non-free media, where to upload etc. And to have another tool in edit box, man not everybody around the world using fast internet! Looks tough to me! -- ɑηsuмaη ^{ʈ ᶏ ɭ Ϟ} 21:26, 31 January 2013 (UTC)

Some of these things are implemented: for instance, I've found that the Upload Wizard on Commons detects duplicate files. I'm not sure how that is implemented or whether special steps would need to be taken to hook into it. -Pete F (talk) 23:11, 31 January 2013 (UTC)

Comments

• Appears someone has done something similar here [2]. So it looks like it is done already.

• Should this become standard? Maybe. Would be good to try see if their is consensus for this sort of idea on Wikipedia.

• One concern is the proposing users number of edits is less than 300 across projects and they started contributing ~ 4 months ago. [3] Doc James (talk · contribs · email) 07:14, 8 February 2013 (UTC)

Hi Doc James. Thanks for your feedback. I admit, I am a newer user to Wikipedia having not edited until a few months ago mainly due to dissatisfaction with the editing UI as I'm a designer of product interaction during the day. Fair point, however I feel a fresh perspective in terms of getting this goal achieved may be just what is needed. I definitely have plans throughout my project plan to get consensus on in context article media uploading, through meetups and potentially a Wikimania demo. The Add media wizard, I mentioned in my proposal and was a plug-in that was unfortunately discontinued and its code in unusable. I contacted its main developer to confirm (Michael Dale). I would love the support of an endorsement if you feel this idea has potential. Thanks again! Ashstar01 (talk) 05:36, 9 February 2013 (UTC)

Ineligible for IEGrant

Hi Aislinn, Thanks for submitting this proposal - it does seem like it would be a useful feature. In conversations with WMF Engineering and Product this week, however, it has become clear that any grant which requires coordination with WMF staff outside of the WMF grantmaking team are just not going to be feasible this year. That dept has their own core priorities to meet and unfortunately are not able to make additional time in their schedules to consult on new projects, review code for integration, etc. What this means is, anything that a grantee wants to build which requires integration with the core software is considered ineligible for an IEGrant. If your project idea could be completed as a gadget, it might still be eligible, but my guess is this is an important enough feature that it should really be built the right way, and be fully integrated into MediaWiki as an extension or some-such so that everyone can use it by default. As such, I'm marking your proposal ineligible at present. If you make any updates to your project that you believe helps it meet our updated eligibility criteria in the future, feel free to let us know. Meanwhile, thanks again for your time and participation, and please accept my apologies that these criteria were not as clear from day 1 as they might have been...we're all learning as we go in this first pilot round. Cheers! Siko (WMF) (talk) 17:55, 15 February 2013 (UTC)

@Aislinn,

I'd just like to say, I've been keeping an eye on your efforts to address the concerns I and other people have brought up, and I've been really impressed. You have made some great progress in exploring the fit between your vision and past and current efforts and tools. This is a kind of open planning and transparent thinking that the Wikimedia movement deeply values, but that is difficult, and often does not get done so effectively; major technology rollouts have been derailed, in my view, as a pretty direct result of planning and thinking that doesn't offer clear opportunities for deliberation and engagement from an early stage. Here, I think you have sown the seeds for a project that could be a big success, and I hope to see it brought to completion at some point.

So above all, thank you for modeling excellent communication around planning. Also, if you find that you do see a path forward for this project, now or in the future, please let me know -- I would be very happy to help you move a project like this forward. -Pete F (talk) 23:32, 15 February 2013 (UTC)