We're currently working on a grant proposal that is related to the usability for uploading and embedding media files to Wikimedia Commons. (This is an area that we will likely not be able to address in detail as part of the Stanton project, so we're trying to parcel it into a separate project.) As part of this proposal, I would like to make a compelling case that pictures and other media uploaded to Commons benefit from strongly from the increased visibility, especially through Wikipedia articles. I'd also like to demonstrate that images get used in multiple languages and multiple projects.
The simplest research approach that any volunteer could take is to take a sample (say 50 featured media and 50 random ones) and to catalog in a spreadsheet usage across Wikimedia projects, using the CheckUsage tool. But I'm sure there are other approaches - both quantitative and qualitative - that might work as well, e.g. based on Wikipedia article traffic statistics.
I'd love to see some volunteer input into this question, which essentially boils down: Why is Wikimedia Commons awesome, and why is it worth investing in to make it even better? I've started a page on Meta here if you want to contribute ideas on-wiki:
http://commons.wikimedia.org/wiki/Commons:Case_for_Commons
But feel free to e-mail me off-list as well. :-)
Thanks for any and all help, Erik
We're currently working on a grant proposal that is related to the usability for uploading and embedding media files to Wikimedia Commons.
I think this is a good idea. Embedding images and other files into a wiki page is something that most wiki engines don't support in a highly usable way. I observed something like 100 kids working with wikis for 10 hours each, on a task that involved a lot of image uploading. Uploading images was one of the most frequent snags that I observed.
A typical snag looked like this.
* User finds an image he likes on the web, using his browser. * User saves that image to his file system, using the default location selected by the browser. * User goes to the wiki page, and clicks on the upload image button. * The browser starts a file selection dialog, but it starts from a different part of the file system than the part where the user saved the image. * User doesn't have a clue where he saved the image previously and can't find the image anymore.
Based on what I have seen, most folks naturally want to do one of the following:
* Find an image on the web using their browser, then copy that image from the browser, and paste it into the wiki page. * Find an image on their file system, then drag it and drop it into the wiki page.
I know these are hard to do with an HTML text box, but the closer you get to that, the better. For example, could it be that with a bit of JavaScript, the HTML text box is able to know the path of the file that was dragged onto it from the file system? If so, maybe it could then upload that file to the wiki, and insert wiki markup to embed it at the current cursor location?
This is not far from what is done in TikiWiki. There, when editing a page, there is a button you can use to browse for an image on the file system. When you select the image file and click on upload, this both uploads the image to the wiki, and inserts wiki markup to embed that image in the wiki page, at the current cursor location.
But again, I know that these sorts of things are hard to do.
---- Alain Désilets, MASc Agent de recherches/Research Officer Institut de technologie de l'information du CNRC / NRC Institute for Information Technology
alain.desilets@nrc-cnrc.gc.ca Tél/Tel (613) 990-2813 Facsimile/télécopieur: (613) 952-7151
Conseil national de recherches Canada, M50, 1200 chemin Montréal, Ottawa (Ontario) K1A 0R6 National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON K1A 0R6
Gouvernement du Canada | Government of Canada
Desilets, Alain wrote:
We're currently working on a grant proposal that is related to the usability for uploading and embedding media files to Wikimedia Commons.
I think this is a good idea. Embedding images and other files into a wiki page is something that most wiki engines don't support in a highly usable way. I observed something like 100 kids working with wikis for 10 hours each, on a task that involved a lot of image uploading. Uploading images was one of the most frequent snags that I observed.
A typical snag looked like this.
- User finds an image he likes on the web, using his browser.
- User saves that image to his file system, using the default location selected by the browser.
- User goes to the wiki page, and clicks on the upload image button.
- The browser starts a file selection dialog, but it starts from a different part of the file system than the part where the user saved the image.
- User doesn't have a clue where he saved the image previously and can't find the image anymore.
MediaWiki supports a upload from URL feature, thus skipping the need to local save. But it's disabled on WMF projects.
MediaWiki supports a upload from URL feature, thus skipping the need
to
local save. But it's disabled on WMF projects.
I suspect that will not be easy enough for many folks. For example, I suspect many people will do something like this:
* Go to google and search for a picture of a tree ** http://images.google.com/images?hl=fr&q=tree&btnG=Recherche+d%27imag... bv=2
* Click on a tree that looks interesting, which would lead them somewhere like here: ** http://images.google.com/imgres?imgurl=http://www.freefoto.com/images/15 /19/15_19_1---Tree--Sunrise--Northumberland_web.jpg&imgrefurl=http://www .freefoto.com/preview/15-19-1%3Fffid%3D15-19-1&usg=__OFzLWf5V_u5Jq7HX_6o TYEBMQYA=&h=400&w=600&sz=129&hl=fr&start=2&sig2=Sgr35XjTpKJsBElvgz8QOQ&t bnid=rL2dCnuYhy7MAM:&tbnh=90&tbnw=135&ei=FCNmSb-0EaX6NNS0jZYE&prev=/imag es%3Fq%3Dtree%26gbv%3D2%26hl%3Dfr
* Copy and paste that google URL into the wiki image upload box
* Of course, we tech-oriented folks know that the above URL is not the URL of the actual image (it's the URL of a page that CONTAINS the image). To get the URL of the actual image, you of course, have to first click on the google link that says: "Display full size image", which gets you to: ** http://www.freefoto.com/images/15/19/15_19_1---Tree--Sunrise--Northumber land_web.jpg
* But given that the previous google URL is largely dominated by the image of interest, I suspect (based on my observations) that most "normal" folks would use that as the URL for the image.
Now, if the user could drag the image from the google URL onto the wiki page, and the wiki was able to figure out from that the URL of the image and upload it, now that would be REALLY COOL!
Alain
On Thu, Jan 8, 2009 at 8:08 AM, Desilets, Alain Alain.Desilets@nrc-cnrc.gc.ca wrote:
MediaWiki supports a upload from URL feature, thus skipping the need
to
local save. But it's disabled on WMF projects.
I suspect that will not be easy enough for many folks. For example, I suspect many people will do something like this:
- Go to google and search for a picture of a tree
** http://images.google.com/images?hl=fr&q=tree&btnG=Recherche+d%27imag... bv=2
- Click on a tree that looks interesting, which would lead them
somewhere like here: ** http://images.google.com/imgres?imgurl=http://www.freefoto.com/images/15 /19/15_19_1---Tree--Sunrise--Northumberland_web.jpg&imgrefurl=http://www .freefoto.com/preview/15-19-1%3Fffid%3D15-19-1&usg=__OFzLWf5V_u5Jq7HX_6o TYEBMQYA=&h=400&w=600&sz=129&hl=fr&start=2&sig2=Sgr35XjTpKJsBElvgz8QOQ&t bnid=rL2dCnuYhy7MAM:&tbnh=90&tbnw=135&ei=FCNmSb-0EaX6NNS0jZYE&prev=/imag es%3Fq%3Dtree%26gbv%3D2%26hl%3Dfr
Copy and paste that google URL into the wiki image upload box
Of course, we tech-oriented folks know that the above URL is not the
URL of the actual image (it's the URL of a page that CONTAINS the image). To get the URL of the actual image, you of course, have to first click on the google link that says: "Display full size image", which gets you to: ** http://www.freefoto.com/images/15/19/15_19_1---Tree--Sunrise--Northumber land_web.jpg
- But given that the previous google URL is largely dominated by the
image of interest, I suspect (based on my observations) that most "normal" folks would use that as the URL for the image.
Now, if the user could drag the image from the google URL onto the wiki page, and the wiki was able to figure out from that the URL of the image and upload it, now that would be REALLY COOL!
Alain
... cool, but probably not that great a feature for WMF projects, because copyright violations are widespread as it is. There's a fine line between making images easily uploadable and, well, discouraging people from uploading stuff.
But improving the interface for working with images once you've got them, for embedding them in existing pages, etc. would be great. And it would be nice to not make the upload/licensing wizard just that, and not a crazy templated hack.
I can't think of good ways to "prove" that commons is useful, however, beyond the standard arguments about making free materials accessible to a global community, reducing duplication and improving quality among all editions of our projects, providing a resource for (more than just the encyclopedia) to tap, etc.
-- phoebe
... cool, but probably not that great a feature for WMF projects, because copyright violations are widespread as it is. There's a fine line between making images easily uploadable and, well, discouraging people from uploading stuff.
Yes, I understand that concern for WMF projects.
Still... making it harder to upload images does not guarantee that people who manage to do it will be aware of copyright issues. A better solution would be for example, for any upload dialog (whether it be the current clunky upload dialog or a better, drag-and-drop improved one) displays a very prominent message about making sure that the image has no copyright attached to it (and that, btw, just because you got it on the web doesn't mean that it doesn't have a copyright).
But improving the interface for working with images once you've got them, for embedding them in existing pages, etc. would be great. And
it
would be nice to not make the upload/licensing wizard just that, and not a crazy templated hack.
Right.
Alain
Hoi, The other day I blogged about a Wikimedian in Iran who is sitting on 5Gb of images and it is too much of a pain for him to upload it. Commons is disfunctional for several reasons and the complicated and clunky user interface is one.
When people use Google to search for a دِرَخت they do not find the same quantity and quality of images. When they search for વૃક્ષ they find only 18 images most not about a tree. Gujarati is spoken by some 50 million people. The notion that Google is functional for most languages is a myth.
When we want to have people use Commons, be it for uploads or for later usage, we need to make sure that Commons actually works for our editors who do not speak English. As it is, people look for pictures by going through interwikilinks and using the material that they find in this way. Consequently we have an overabundance of images used everywhere that originate in the "first" world. This does contribute to a systemic bias and it is not conducive to our much desired "neutral point of view".
If Google is to become usable, it needs to support languages like Persian, Gujarati, Amharic to make the images we have available to all of our community. It has been demonstrated that we can show the category trees and the categories in many languages. If we are to go for funding, this means that we can actually deliver the goods.
Given that Commons has only 3.7 million files is hardly a sign of its success, compare it to Flickr and you see what the "competition" is doing. Thanks, GerardM
PS It is still a great achievement, but it is could and should be so much more.
2009/1/9 phoebe ayers brassratgirl@gmail.com
On Thu, Jan 8, 2009 at 8:08 AM, Desilets, Alain Alain.Desilets@nrc-cnrc.gc.ca wrote:
MediaWiki supports a upload from URL feature, thus skipping the need
to
local save. But it's disabled on WMF projects.
I suspect that will not be easy enough for many folks. For example, I suspect many people will do something like this:
- Go to google and search for a picture of a tree
** http://images.google.com/images?hl=fr&q=tree&btnG=Recherche+d%27imag... bv=2
- Click on a tree that looks interesting, which would lead them
somewhere like here: ** http://images.google.com/imgres?imgurl=http://www.freefoto.com/images/15 /19/15_19_1---Tree--Sunrise--Northumberland_web.jpg&imgrefurl=http://www .freefoto.com/preview/15-19-1%3Fffid%3D15-19-1&usg=__OFzLWf5V_u5Jq7HX_6o TYEBMQYA=&h=400&w=600&sz=129&hl=fr&start=2&sig2=Sgr35XjTpKJsBElvgz8QOQ&t bnid=rL2dCnuYhy7MAM:&tbnh=90&tbnw=135&ei=FCNmSb-0EaX6NNS0jZYE&prev=/imag es%3Fq%3Dtree%26gbv%3D2%26hl%3Dfr
Copy and paste that google URL into the wiki image upload box
Of course, we tech-oriented folks know that the above URL is not the
URL of the actual image (it's the URL of a page that CONTAINS the image). To get the URL of the actual image, you of course, have to first click on the google link that says: "Display full size image", which gets you to: ** http://www.freefoto.com/images/15/19/15_19_1---Tree--Sunrise--Northumber land_web.jpg
- But given that the previous google URL is largely dominated by the
image of interest, I suspect (based on my observations) that most "normal" folks would use that as the URL for the image.
Now, if the user could drag the image from the google URL onto the wiki page, and the wiki was able to figure out from that the URL of the image and upload it, now that would be REALLY COOL!
Alain
... cool, but probably not that great a feature for WMF projects, because copyright violations are widespread as it is. There's a fine line between making images easily uploadable and, well, discouraging people from uploading stuff.
But improving the interface for working with images once you've got them, for embedding them in existing pages, etc. would be great. And it would be nice to not make the upload/licensing wizard just that, and not a crazy templated hack.
I can't think of good ways to "prove" that commons is useful, however, beyond the standard arguments about making free materials accessible to a global community, reducing duplication and improving quality among all editions of our projects, providing a resource for (more than just the encyclopedia) to tap, etc.
-- phoebe
Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Gerard Meijssen wrote:
Hoi, The other day I blogged about a Wikimedian in Iran who is sitting on 5Gb of images and it is too much of a pain for him to upload it. Commons is disfunctional for several reasons and the complicated and clunky user interface is one.
I am not sure if we can improve the interface significantly to deal with that. I have 2000-3000 photos in my growing backlog, and what's really is time consuming is not the interface per se (I use commonist anyway) but the need to properly name, categorize and describe the images. Yes, a better interface could help somewhat, but in the end, properly describing an image will always be time consuming.
Hoi, Well you just proved that you write in English ... Thanks, GerardM
2009/1/9 Piotr Konieczny piokon@post.pl
Gerard Meijssen wrote:
Hoi, The other day I blogged about a Wikimedian in Iran who is sitting on 5Gb of images and it is too much of a pain for him to upload it. Commons is disfunctional for several reasons and the complicated and clunky user interface is one.
I am not sure if we can improve the interface significantly to deal with that. I have 2000-3000 photos in my growing backlog, and what's really is time consuming is not the interface per se (I use commonist anyway) but the need to properly name, categorize and describe the images. Yes, a better interface could help somewhat, but in the end, properly describing an image will always be time consuming.
-- Piotr Konieczny
"The problem about Wikipedia is, that it just works in reality, not in theory."
Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
'properly describing an image will always be time consuming.'
I totally agree. Still, can we have some games for Wikipedians to play so that we can 'tag' photos with different terms in different languages and enjoy some relaxing moment?
I stumble on the idea from the clip: from 10:20 on http://video.google.com/videoplay?docid=-8246463980976635143
hanteng
Piotr Konieczny wrote:
Gerard Meijssen wrote:
Hoi, The other day I blogged about a Wikimedian in Iran who is sitting on 5Gb of images and it is too much of a pain for him to upload it. Commons is disfunctional for several reasons and the complicated and clunky user interface is one.
I am not sure if we can improve the interface significantly to deal with that. I have 2000-3000 photos in my growing backlog, and what's really is time consuming is not the interface per se (I use commonist anyway) but the need to properly name, categorize and describe the images. Yes, a better interface could help somewhat, but in the end, properly describing an image will always be time consuming.
Gerard Meijssen wrote:
Hoi, The other day I blogged about a Wikimedian in Iran who is sitting on 5Gb of images
I am curious as to the nature of that 5 GB
and it is too much of a pain for him to upload it.
Can you clarify? Uploading ~1000 images is bound to be /tedious/, but it's not /difficult/ with something like Commonist (http://www.djini.de/software/commonist/)
If Google is to become usable, it needs to support languages like Persian, Gujarati, Amharic to make the images we have available to all of our community.
I think you're in the wrong place to suggest changes to Google.
Given that Commons has only 3.7 million files is hardly a sign of its success, compare it to Flickr and you see what the "competition" is doing.
This comparison makes no sense. The vast majority of the images on Flickr are illegal, non-free, non-educational, or all three. Commons does not want those images. There are a small subset that are appropriate for Commons, and editors (including me) work on bringing them over.
Matt Flaschen
Hoi, Is Commonist localised ? Is it usable in a Persian context ?
When you look for images on Google in other languages, you will not be well served. This is something where Commons can make a difference. I have shown that we can do this.. It takes a lot of commitment and more money then I have to make this happen. Even when you PROVE that we can do this, it does not mean that it has any priority.
I know that we can have many more material on Commons. One BIG reason why Commons underperforms is because it is in effect not a multilingual project. Thanks, GerardM
2009/1/14 Matthew Flaschen matthew.flaschen@gatech.edu
Gerard Meijssen wrote:
Hoi, The other day I blogged about a Wikimedian in Iran who is sitting on 5Gb of images
I am curious as to the nature of that 5 GB
and it is too much of a pain for him to upload it.
Can you clarify? Uploading ~1000 images is bound to be /tedious/, but it's not /difficult/ with something like Commonist (http://www.djini.de/software/commonist/)
If Google is to become usable, it needs to support languages like Persian, Gujarati, Amharic to make the images we have available to all of our community.
I think you're in the wrong place to suggest changes to Google.
Given that Commons has only 3.7 million files is hardly a sign of its success, compare it to Flickr and you see what the "competition" is
doing.
This comparison makes no sense. The vast majority of the images on Flickr are illegal, non-free, non-educational, or all three. Commons does not want those images. There are a small subset that are appropriate for Commons, and editors (including me) work on bringing them over.
Matt Flaschen
Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Gerard Meijssen schrieb:
Hoi, Is Commonist localised ? Is it usable in a Persian context ?
Commonist is GPL. It's Java-based, and Java as pretty good unicode support. As to localization, I'm not sure, but I think it uses the standard java mechanisnm, that is "resource bundels" in the form of "property files". The syntax is pretty simple, it would be nice for betawiki to support it.
I havn't checked what languages it supports so far. At least german and english I expect.
-- daniel
Hoi, As long as there is no Internationalisation and Localisation for the essential Commons tools like Commonist, Commons is not usable for people from other languages. When these tools are to be part of Betawiki, get into contact with the people at Betawiki and make this a priority.
Be clear that you will have people NOT use English as a consequence. Thanks, GerardM
2009/1/14 Daniel Kinzler daniel@brightbyte.de
Gerard Meijssen schrieb:
Hoi, Is Commonist localised ? Is it usable in a Persian context ?
Commonist is GPL. It's Java-based, and Java as pretty good unicode support. As to localization, I'm not sure, but I think it uses the standard java mechanisnm, that is "resource bundels" in the form of "property files". The syntax is pretty simple, it would be nice for betawiki to support it.
I havn't checked what languages it supports so far. At least german and english I expect.
-- daniel
Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Gerard Meijssen wrote:
Hoi, As long as there is no Internationalisation and Localisation for the essential Commons tools like Commonist, Commons is not usable for people from other languages.
It seems clear you're not paying attention, and you haven't looked at the Commonist source code. As Daniel said, Commonist is localized, and besides the two languages he named, it also supports French and Slovak.
Matt Flaschen
Hoi, I do not look at source code. I was talking about Commonist in a Persian setting. For your information, because of all this talk about Commonist, the 50 messages of Commonist can now be localised in Betawiki. In seven hours 380 messages were localised, among others there is now a full localisation in Tagalog. I am sure that Persian will also be supported in the very near future.
This is what is needed to help people contribute to Commons. Thanks, GerardM
2009/1/14 Matthew Flaschen matthew.flaschen@gatech.edu
Gerard Meijssen wrote:
Hoi, As long as there is no Internationalisation and Localisation for the essential Commons tools like Commonist, Commons is not usable for people from other languages.
It seems clear you're not paying attention, and you haven't looked at the Commonist source code. As Daniel said, Commonist is localized, and besides the two languages he named, it also supports French and Slovak.
Matt Flaschen
Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Gerard Meijssen schrieb:
Hoi, Is Commonist localised ? Is it usable in a Persian context ?
Ok, I just checked: it does indeed use the standard property file format, and currently supports en, de, fr and sk. I don't know how well it will handle a RTL language -- Java/Swing does have support built in, but you have to take care to consider it when building the UI.
But ask the author about it, he's quite competent, and a nice guy.
-- daniel
I'm happy to tell you: COmmonist is now on Betawiki, translation is in progress.
See http://translatewiki.net/wiki/Translating:Commonist
-- daniel
2009/1/8 Erik Moeller erik@wikimedia.org: As part of this proposal, I would like to
make a compelling case that pictures and other media uploaded to Commons benefit from strongly from the increased visibility, especially through Wikipedia articles. I'd also like to demonstrate that images get used in multiple languages and multiple projects.
This is similar to a discussion I started in July, called "Institutional stats reports" http://lists.wikimedia.org/pipermail/commons-l/2008-July/003924.html.
Domas' wikistats doesn't include image view logs. To be useful, such logs would aggregate stats of all different size thumbnails. I opened a bug report to request this data in late July. https://bugzilla.wikimedia.org/show_bug.cgi?id=14890
WMF has the data directly, why not provide it? Instead of suggesting volunteers go the long way around which is ultimately less accurate.
Beyond view stats I can think of a few other arguments which I will write up on the wiki page.
cheers Brianna
wiki-research-l@lists.wikimedia.org