User gallery example

I just found out by chance that a long-awaited feature for Wikimedia Commons had been enabled a few weeks ago. I’m talking about user galleries, i.e. the ability to list recent uploads by a user to a MediaWiki-powered wiki.

As if often happens, such a tool has been available on the toolserver for years (see an example), and a link to this tool was added to the default Commons interface for user pages.

Nonetheless, a “user gallery” feature built in MediaWiki, similar to the list of one’s edits, was still missing. We touched the subject during the Multimedia usability project, but we had to focus on the uploader.

A feature request was opened in our bug tracker back in 2005. This morning, while reading my bugmail, I saw a notification about this bug, saying the feature had been added in 2010 and deployed recently.

It turns out it was added by Bryan Tong Minh, a MediaWiki developer particularly active in multimedia features; he’s also the one who wrote the GlobalUsage extension a few years ago, which provides a list of all the pages around Wikimedia sites where a file is included.

It was already possible, in MediaWiki, to list files (in reverse-chronological order) through the Special:ListFiles special page. Bryan added the ability to filter this list by user, effectively creating a user gallery (r65013). He then added thumbnails to the page (r75582). The feature was enabled on Wikimedia sites (including Commons) as part of the deployment of MediaWiki 1.17.

So, it is now possible to see the gallery of uploads by a certain user (see an example). Want to see your gallery? Go to Special:MyUploads. Neat, heh?

The gallery is also accessible through the small “uploads” link at the top of your contributions list.

This feature is a huge step forward in terms of usability. During our interviews & testing, most people were wondering where their uploads had gone once the upload was completed. I’d like to thank Bryan, and all our awesome volunteers, for their work in making MediaWiki better.

The next step will probably be to add a shortcut to the gallery in the user’s top-right menu, as well as in the “Toolbox” menu in the sidebar. Maybe not on all wikis, but it would definitely be useful on Commons.

Further improvement could include the prettification of the page, perhaps à la Flickr, and the possibility to get the code to insert the image in a wiki page, as we do at the last step of the Upload wizard.

Actually, once that is done, we could pretty much replace the last step of the upload wizard by the gallery page, only with a thank-you message at the top. What do you think?

Gate of Great Centrality and Perfect Uprightness and Democrary Memorial Hall in Taipei, Taiwan

Our volunteers are awesome. More specifically, Magnus Manske is awesome. He just made reusing pictures from Wikimedia Commons a hundred times easier.

The story begins in October 2009.

About a year ago, I created some mock-ups of what the ideal file description page should look like on Commons. One of my suggestions was to add a series of buttons for one-click reuse cases, to make it easier for people to reuse the more than 7 million files available on Wikimedia Commons.

One-click reuse cases from the October 2009 draft mock-ups

These prominent buttons would help users embed the media files in wiki pages, HTML code or simply download the file. If you wanted to include the file in a Wikipedia article, it would provide you with the wikicode for it, so you would only have to copy/paste the code snippet, without having to be a wiki expert. Same thing if you wanted to include the file in an external web page. The “Download” button was an attempt to make the current (and quite frankly, hidden) download link more obvious.

Code snippets from the October 2009 mock-ups

Magnus Manke’s “Stock photo” tool

Last week, Magnus Manske created a small JavaScript piece of code to add a “Stock photo” feature and mentioned it on the Commons mailing list. Magnus is one of the original developers of MediaWiki, but nowadays he mostly works on Toolserver and JavaScript tools, especially for Commons.

The tool he wrote was pretty neat, and User:TheDJ and I briefly talked about it on IRC. I also pointed TheDJ to my earlier mock-ups from last year, explaining how the idea was similar.

Today, as I was visiting Commons, I was stunned to see a new version of Magnus’ tool, available on all file description pages, that was clearly inspired by my design. You can see for yourself by visiting any file description page on Commons.

Screenshot of the buttons as now implemented on Wikimedia Commons

Apparently, TheDJ pointed to my design in the discussion on the Village pump, Magnus implemented it and the feature was globally enabled on Commons for all users.

I think this is fantastic.

Magnus not only reused my design, but he even made it better by adding the possibility to select the size of the file you want to download or embed.

As we held the user experience study for the prototype upload wizard, our users were really pleased to see similar code snippets at the last stage of the wizard, but they were wondering how to obtain this information again. Until now, they couldn’t. Now, anyone can.

We couldn’t implement the improved file description pages as part of the Multimedia Usability grant, because we had to focus on the new upload system. I’m really thrilled to see volunteers taking on such tasks, and I’d like to express my deepest gratitude and thanks to Magnus, TheDJ, and more generally all the awesome volunteers who help make our software platform better.

The tool’s code is available at MediaWiki:Stockphoto.js; comments and bug reports can be left on the talk page.

In a nutshell, reusing media files from Wikimedia Commons just got a lot easier; this is really nifty. I imagine it would be great if this feature, along with a few similar others, could be integrated directly into MediaWiki, or into an extension for media repositories to be enabled on Wikimedia Commons.

In June last year, I summarized my view with the following comment:

The main issue of Commons is that it is growing way too fast. This issue is quite unique in Wikimedia projects: when a wiki is growing, it is usually growing because its community is growing. The issue with Commons is that it is a central repository used by almost all the other wikis; many users on Commons are not regular participants there, they only use it to upload pictures for their wiki and they don’t involve themselves in the local Commons community, which remains limited. As a consequence, this Commons community doesn’t have the human resources to face the workload induced by the growth of the wiki.

In a nutshell, Commons’ issue is that the wiki is growing faster than its community.

And apparently, I wasn’t the only one to think so. Yet, this statement was only an opinion, and was not based on actual research. My opinion hasn’t changed much since then, but now I actually have some data to support this conclusion.

Content and community growth

There has been much interest in the academic world about “Who writes Wikipedia?” and whether most of the content is contributed by an elite group of participants or by occasional visitors^{1 2}. Roth et al. studied the factors influencing wiki viability and noted a “dynamical intertwinement of population and content growth”³; they had earlier suggested that a wiki’s success was linked to “a virtuous demographic path with content and contributors co-evolving”⁴.

In a media repository like Wikimedia Commons, however, the focus of activity is on contributing new media files, rather than improving the existing ones. Once a file has been uploaded, improvements are mostly limited to metadata and peripheral information (description of the media file, copyright information, general topics, location, etc.); the files themselves are rarely edited. As a consequence, it is particularly interesting to study the dynamics of population & content in this special case. For this purpose, I studied the temporal evolution of the Files-to-active Participants ratio (F:P) and compared it to the Articles-to-active Participants (A:P) ratio on the English Wikipedia (Fig. 1). All the data come from stats.wikimedia.org.

Fig. 1: Temporal evolution of the ratio of media files on Wikimedia Commons per active participant (orange squares) and evolution of the ratio of articles on the English-language Wikipedia per active participant (blue triangles).

While the articles-to-participants ratio has remained stable on Wikipedia after the first few years of existence, the files-to-participants ratio has been steadily increasing since the creation of Wikimedia Commons. F:P has exceeded A:P since then and is now ten times higher than A:P. This demonstrates that Wikimedia Commons, despite being successful in terms of content, does not follow the usual model of “viable” or “successful” wikis, and requires new metrics and new models.

Content inflow management

Because of the fundamental difference between a text-based encyclopedia and a media repository, a more interesting approach is to compare the capacity of the community of participants to “absorb” the inflow of new content contributed to the platform. Thus, I studied the temporal evolution of the ratio of persistent new media files uploaded each month, per very active participants on Wikimedia Commons (Fig. 2). I compared it to the ratio of persistent new articles per very active participants on the English-language Wikipedia. “Persistent” means that I only counted media files and articles that were not deleted during the patrolling process; the actual number of files uploaded and articles created is higher. I chose to consider only very active participants (more than 100 edits per month) since they are the more likely participants to engage into patrolling activities, such as checking newly uploaded files or newly created pages.

Fig. 2: Temporal evolution of the ratio of persistent new media files on Wikimedia Commons per very active participant (orange squares) and evolution of the ratio of persistent new articles on the English-language Wikipedia per very active participant (blue triangles).

The ratio of persistent new media files per very active participants has doubled since the creation of Wikimedia Commons and still continues to increase. This ratio is now more than ten times higher than the one for articles on the English-language Wikipedia. Because of this imbalance between the growth of the content and the growth of the community, Wikimedia Commons faces a peculiar challenge.

Using appropriate tools

Some may argue that comparing uploads and the creation of new pages is like comparing apples and oranges; I agree to some extent. For this reason, I have also studied the evolution of the number of edits on the English Wikipedia, which may be a better indicator of the inflow the community has to absorb. This will be the subject of an upcoming article.

The MediaWiki software provides various maintenance and patrolling tools that allow participants to check newly contributed content; one of these tools is the “watchlist”, a personal page listing the recent changes made to pages of interest selected by each participant. Watchlists are appropriate for text-based wikis like Wikipedia where participants want to check new edits to existing pages, rather than new pages. However, maintenance activities on Wikimedia Commons mainly consist of checking new files (especially their copyright status) and classifying them appropriately. For this purpose, the usefulness of the watchlist is limited. Some ad-hoc tools have been developed by power participants, but MediaWiki does not provide dedicated features to help the limited community of participants absorb the inflow of new media files. This is where the Multimedia Usability project can step in.

Notes & References

From your computer to Commons using digiKam

For several years now, I have been a photographer for Wikimedia Commons. Commons is actually the reason why I became interested in photography, and why I bought a DSLR camera and various lenses. And I have ended up taking a lot of pictures.

The problem when you take a lot of pictures is that the time you need then to process and upload them grows exponentially. Besides, if you want to upload your pictures to several platforms (say, Commons, flickr and your blog), you have to deal with the specifics of each website. It would be much simpler and faster to describe, tag, classify, geotag the pictures only once (using an appropriate batch-editing tool) and then to have each website extract the metadata, or to use an upload tool that extracts them automatically.

Wikimedia Commons

So, on the one hand, you have Wikimedia Commons, a repository of freely-licensed multimedia files (photos, maps, diagrams, sounds, videos, etc.). It is a project of the Wikimedia Foundation, from which uploaded files can be used across all Wikimedia projects in all languages, including the famous encyclopedia Wikipedia.

Wikimedia Commons contains over 5 million files, the overwhelming majority of which have been contributed by volunteers. Such a large amount of files makes it mandatory to properly:

• describe what each work is about
• identify the author and the copyright status of each work
• classify each work in order to be able to find it later and to manage such a large collection.

Besides these requirements, it is also considered a good practice to geotag your pictures (if applicable), i.e. to indicate the geographical location of where the picture was taken.

digiKam

On the other hand, there is digiKam, a FLOSS “digital asset management” application whose special features allows to annotate, classify and catalogue a large media library, although it provides some very handy editing and post-processing tools as well. digiKam uses the KIPI plugins, which provide handy features such as batch editing or export modules to a variety of websites, including Flickr, Picasa and Facebook. The 4th beta release of digiKam 1.0 was recently released and the official 1.0 release is planned for late October this year.

I won’t go through digiKam’s impressive list of features; instead, I will focus on those that make digiKam a very powerful tool for Wikimedia photographers.

The perfect combination?

So let’s take a quick look at the features digiKam offers that would be handy for people who want to contribute their pictures to Wikimedia Commons:

So, what’s missing? Well, you can do a lot of stuff with digiKam to prepare your pictures before they’re uploaded to Commons. Yet, you still have to upload them manually, or using an external tool such as Commonist. And even if you have been spending days to annotate your pictures, describe them in several languages, geotag them, etc., well, all this information remains in the image metadata. Neither Commonist nor MediaWiki knows how to extract these metadata meaningfully (yet); as a consequence, you have to redo all the work when uploading each file to Wikimedia Commons. The Ford Foundation recently awarded a $300,000 grant to the Wikimedia Foundation in order to improve the usability of the upload process. I expect some work will be done regarding the extraction of metadata from files. Yet, when uploading a large number of files, it would be more convenient to provide a standalone desktop upload tool like Commonist. Or…

What would really be neat is an integrated export module to Wikimedia Commons in digiKam; not only would it serve as a batch upload tool, but it would also read all the metadata and create the file description pages accordingly. A few weeks ago, I contacted the main developer of digiKam in order to discuss the possibility of implementing such an export module. He showed interest in this project even if he didn’t have the time to code it himself. As a consequence, I have initiated a roadmap and brainstorming page for the plugin.

Feel free to contact me if you’re interested in helping implement such a plugin.

Notes

Logo of Wikimedia Commons

About two years ago, I said “Commons may be the next coolest project, as soon as developers find the time to improve its usability to make it more user-friendly”. Sadly, Wikimedia Commons hasn’t evolved much in terms of usability since then. MIT’s Technology Review recently published an article about improvements to come regarding the management of video content on Wikipedia and Wikimedia websites. I heard a lot of people say: “Good, but what about pictures?” Some technical improvements described by the Technology Review will be useful for both images and videos, such as the media and upload wizard currently developed by Michael Dale. However, Wikimedia Commons still needs many little (or big) features that would dramatically improve its user-friendliness.

Browsing & reusing

1. Automatic localization: Websites such as Wikimedia Commons and meta-wiki host content in various languages and have a multilingual audience. These multilingual wikis should automagically detect the locale of the user’s browser and use it as language of the interface, especially for unregistered users. As for users with an account, their browser’s locale should be set as the default language in their preferences.
2. Usage-centric page layout: It’s all very nice to know that such image is a “retouched picture” or that such diagram was “made using Inkscape”. But I think what most of the users want to know is: how to use the picture (in Wikimedia projects or elsewhere) and how to download it (using the best resolution available). Many people use the right-click-save-as method to save pictures from the Internet. If they do that on Commons, they will only save the low-resolution preview. There should be a big button « Download high-res », as well as snippets of code to embed a file with proper attribution.

Metadata

Full metadata support is the cornerstone of many other features. EXIF is probably the most known type of metadata, but there are also others such as IPTC or XMP.

3. Pull metadata from files on upload: this idea is not a new one, yet it hasn’t been implemented. A fair amount of photographers add a lot of metadata to their files: author, description, copyright information, geotags, keywords, etc. and it is extremely cumbersome to have to redo all the work by hand during the upload.
4. Store metadata in a database to make search and attribution easier, especially: description, license, media type (photo, diagram, map, etc.). It should be connected to the MediaWiki API to allow for easy extraction of these data.
5. Push metadata to files on download: In the field of publishing, storing credit information directly into the file’s metadata is strongly recommended and is a standard practice to avoid losing track of it.

Related open bugs

• bugzilla:6672: EXIF orientation not used (rotation from digital cameras)
• bugzilla:3361: Image author, description, and copyright data saved in EXIF fields
• bugzilla:16956: Show IPTC metadata on image description page
• bugzilla:657: Pull copyright metadata from files on upload
• bugzilla:11484: Include ISO rating in abbreviated exif metadata.

Editing

6. Built-in basic editing features (lossless rotate, crop) and ability to save under another name (i.e. for crops). Similarly, a built-in geocoding feature using OpenStreetMap. Geocoding images means attaching geographic information about the place where the work was made. This may be made easier by the current initiative to integrate OpenStreetMap with Wikimedia projects. And of course it should save the coordinates as metadata.

Rating

7. Some sort of community-managed rating feature; as someone said elsewhere, “Commons is a depository, and depositories are expected to host lots of junk”. A rating feature would allow the best of Commons to be presented first during the search, and junk to be presented last.

Searching

With currently more than 4.6 million files (and counting), it is becoming increasingly important to improve the search features of Wikimedia Commons.

8. An “advanced search” feature similar to flickr’s. It should be possible to search by media type, by license, and to add toggles such as “safe mode” (explicit content) or “personality rights”.
9. Multilingual search: Files on Commons are ordered in hierarchical categories, using English as lingua franca. If you want to find a file, you have to search in English. I imagine it is possible to use some dictionary (coupled to the language detection) to give good results for a search in any language.
10. Google-Images-friendliness. A lot of people use Google Images to find pictures, but images from Wikimedia Commons rarely appear in these results (unless they are used on a Wikipedia page).

Note: All these ideas are given from a user point of view; their technical feasibility has to be assessed by a MediaWiki-literate developer.

Panning photo of Nicolas Sarkozy at a political rallye in Toulouse

Some months ago, I was asked permission to reuse one of my photos of Nicolas Sarkozy, the new French President, that I had taken during his rallye in Toulouse. The photo was printed on the cover of a newsletter issued by think tank in London called the Stockholm Network. They contacted me via flickr but I told them to credit me via Wikimedia Commons instead, where the photos also were.

I am now being contacted by someone working for Community Connection News Magazine, “a minority print media publication company based out of Milwaukee, WI and serving the tri-state area” who’s interested in a picture of school bus from Québec.

School bus in Québec

The lady emailed me through flickr and asked permission to use photos from my gallery there. She was quite astonished when I told her about Wikimedia Commons offering more than 1.8 million free media files.

Eventually, flickr may help Commons to get some attention. Teachers and librarians, who are always very doubtful about Wikipedia, usually love the idea of a free media repository where they can pick media for their courses or to where they can send their students without risking that they copy/paste articles full of errors. Commons may be the next coolest project, as soon as developers find the time to improve its usability to make it more user-friendly and more “2.0“.