I recently had to investigate how to customize the “meta” widget provided by WordPress.

I maintain the Wikimedia Blog, and we wanted to include a link to our posting guidelines to the “meta” section of our sidebar.

There is no straightforward way to do this; the widget can’t be edited from within the admin area.

One possibility was to replace the standard meta widget by a custom text widget, with the same content and links, and to add our guidelines to the mix. But this meant losing the nice context-aware links (e.g. “Register” vs. “Site admin”, and “Log in” vs. “Log out”, respectively for logged-out and logged-in users) provided by built-in WordPress functions (wp_register and wp_loginout): widget text can’t embed PHP code.

Another possibility was to install a third-party plugin to customize the meta widget (or allow PHP code in widget text). I’m usually reluctant to using plugins for simple changes like the one we wanted to do. Both our Operations staff and I prefer to keep the amount of third-party plugins installed on the blog to a minimum, for various reasons (security, maintenance, maintainability, etc.)

Because there are no hooks to plug into the widget’s behavior, most of the solutions I’ve seen online consist either of using a third-party plugin, or messing with WordPress core files, which is a no-go for me.

The third possibility, which is the one I went for, was to create our own meta widget. This is what the code below does.

Result: Our blog guidelines inserted into the meta widget.

I used the WordPress widgets API to create a widget, as well as the content of the standard meta widget, located in wp-includes/default-widgets.php. The code is located in our WMBlog plugin, a set of customizations specific to our blog that work independently of the theme.

The custom widget replicates the functionality of the standard meta widget (with the handy context-aware links) and also includes the link to our guidelines. It was a bit more work, but it’s cleaner and more robust that way. Once the widget is available, an admin can replace the standard widget with the custom one.

If you want to add stuff to the meta widget, or remove some of its standard content, this is probably the Right™ Way to do it. You’ll want to look at lines 42 to 51 in the code below.

Note: The code hasn’t been deployed to production yet; it’ll appear on the Wikimedia blog in a few days.

Code

/* =========================================================
   Replicate the default meta widget and extend it to include
   a link to the Wikimedia blog guidelines */

class WMBlog_meta_widget extends WP_Widget {

	function WMBlog_meta_widget() {
		// (constructor) Instantiate the parent object
		parent::WP_Widget( /* Base ID */'WMBlog_meta_widget', /* Name */'WMBlog_meta_widget', array( 'description' => 'The default meta widget plus Wikimedia-specific stuff' ) );
	}

	function form( $instance ) {
		// output the options form on admin
		// i.e. for now only the widget's title
		if ( $instance ) {
			$title = esc_attr( $instance[ 'title' ] );
		}
		else {
			$title = __( 'New title', 'text_domain' );
		}
		?>
		<p>
		<label for="<?php echo $this->get_field_id('title'); ?>"><?php _e('Title:'); ?></label>
		<input class="widefat" id="<?php echo $this->get_field_id('title'); ?>" name="<?php echo $this->get_field_name('title'); ?>" type="text" value="<?php echo $title; ?>" />
		</p>
		<?php
	}

	function update( $new_instance, $old_instance ) {
		// process widget options to be saved
		$instance = $old_instance;
		$instance['title'] = strip_tags($new_instance['title']);
		return $instance;
	}

	function widget( $args, $instance ) {
		// output the content of the widget
		extract( $args );
		$title = apply_filters( 'widget_title', $instance['title'] );
		echo $before_widget;
		if ( !empty( $title ) ) { echo $before_title . $title . $after_title; } ?>
			<ul>
			<?php wp_register(); ?>
			<li><?php wp_loginout(); ?></li>
			// Link to our own posting guidelines
			<li><a href="//meta.wikimedia.org/wiki/Wikimedia_Blog/Guidelines" title="General contribution guidelines for the Wikimedia blog">Blog guidelines</a></li>
			<li><a href="<?php bloginfo('rss2_url'); ?>" title="<?php echo esc_attr(__('Syndicate this site using RSS 2.0')); ?>"><?php _e('Entries <abbr title="Really Simple Syndication">RSS</abbr>'); ?></a></li>
			<li><a href="<?php bloginfo('comments_rss2_url'); ?>" title="<?php echo esc_attr(__('The latest comments to all posts in RSS')); ?>"><?php _e('Comments <abbr title="Really Simple Syndication">RSS</abbr>'); ?></a></li>
			<li><a href="http://wordpress.org/" title="<?php echo esc_attr(__('Powered by WordPress, state-of-the-art semantic personal publishing platform.')); ?>">WordPress.org</a></li>
			<?php wp_meta(); ?>
			</ul>
		<?php echo $after_widget;
	}

}

function WMBlog_register_widgets() {
	// register the plugin's available widgets
	register_widget( 'WMBlog_meta_widget' );
}

// plug in the widgets registration
add_action( 'widgets_init', 'WMBlog_register_widgets' );

Because I’m currently working on a new version, I was reluctant to spend a lot of time to fix this one. The downside is that I couldn’t really post new content in the meantime.

Because I still want to have a space to post articles, I’ve done a bunch of upgrades and cleanup, and reverted this site to a working state. There are still quirks, but for the time being it’ll be good enough.

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?

Boats on the Motława river seen from Most Stągiewny

It’s been a few months since Wikimania 2010 in Gdańsk. I had a few notes I wanted to share, but I was waiting for the Wikimania videos, which were never delivered. I’ll just go ahead and publish my notes now.

I went to Wikimania with my staff hat on, mainly to present and discuss the Multimedia usability project. I briefly presented the results of our research, then went on to demo the Upload wizard and play videos from our UX study.

The supporting slides are available on Wikimedia Commons; you can also download the PDF directly (2.36 MB).

I also submitted and coordinated a UX panel to provide a venue for users to ask their questions to the UX team. During this session, both the panel and the audience took notes collaboratively, which we found was a pretty effective means to maintain audience engagement!

The venue for the event was lovely; after WikiSym, hosted at the Music Academy in Gdańsk, having Wikimania in the Polish Baltic Philharmonic was awesome. Then again, I’m biased towards concert halls.

Program & Sessions

I wasn’t necessarily a big fan of the “Wikimania madness” concept at first: I personally hate to be rushed through something. But if you prepare your 30-second intro, the idea actually works quite well — provided everybody plays by the rules and speaks for only 30 seconds.

The overall program was awesome; with all due respect to the previous Wikimania conferences I attended, whose program was great too, I feel this year’s Wikimania was the best in terms of quality of talks. Huge props to the Program team!

The downside of it, obviously, was that it was extremely difficult to choose between concurrent sessions. For example, I missed the sessions about Talk pages and LiquidThreads, Semantic MediaWiki and Semantic Result Formats. I have some thoughts on how to solve this dilemma that I’ll publish later.

On Friday evening, we had the opportunity of attending a gala concert performed by the Gdańsk Baltic Philarmonic, directed by Felix Reolon. I’m hoping the recording will be made available, but in the meantime there’s an extract of the concert on YouTube. The concert was lovely, even though the audience didn’t necessarily measure up.

Many Wikimania sessions were better than the ones I attended at WikiSym. Harel’s talk about Conflicts between chapters and communities was both painfully accurate and delightfully funny. I feel a large part of the audience recognized themselves in both groups.

Another highlight was the presentation of the German mentoring program, by Tim Moritz Hector and his friends from the German-language Wikipedia. Their system seems to be fairly effective, and this talk was particularly relevant in a context where many criticize the unfriendliness of established editors towards inexperienced participants, but few act on it.

I was eager to watch the world premiere of Truth in Numbers, the documentary about Wikipedia, whose early cuts I had had the opportunity to see at Wikimania 2007 in Taipei. I ended up being quite disappointed, and the audience had mixed feelings about it overall.

Staff are people, too

The thing I like most about Wikimania is obviously the Wikimedians. Many of them interact a lot online, and sometimes become friends. Yet, most of them never get to see each other in person except once a year at Wikimania. This gives the event a rare intensity that I was looking forward to.

Unfortunately, I didn’t have too many opportunities to catch up with Wikimedians I know, or to meet new ones. When I talked to some of my Wikimedian friends online afterwards, they told me they had been reluctant to “using my time” for “just socializing” because it had become “more precious”  since I was an employee, and not “just” a volunteer.

While it was very nice of them to have that concern, I was still a tad disappointed. Wikimania is about meeting people, socializing and catching up with friends, more than attending presentations. Employees are not different than volunteers in that regard, especially when they’ve been long-time Wikimedians.

In a nutshell: Don’t hesitate to hang out with me (and other employees) at Wikimania next year!

Extract from the licensing tutorial. All graphics CC-by-sa, Wikimedia Foundation.

A few days ago, I announced the publication of the English version of an illustrated licensing tutorial for Wikimedia Commons. The tutorial was developed as part of the Multimedia usability project I’ve been working on for the past year. This article invites you on a behind-the-scenes tour of the licensing tutorial project.

Context

Because all Wikimedia projects are based on free licenses, Wikimedians have developed a particular expertise in this field, and in copyright in general. One of my favorite quotes about Wikimedians is from Sue Gardner’s keynote session at Wikimania 2009 in Buenos Aires:

You all know more about copyright law than any sane, sensible human being.

We do. And it’s hard to remember how little we knew about copyright a few years ago, when we had just started to edit. Back then, most of us had never heard about the GFDL, or about Creative Commons. Back then, we had never heard of Bridgeman Art Library v. Corel Corp. or the Place des Terreaux case¹.

Copyright is an incredibly complicated topic, especially in an international context. We’ve grown accustomed to it, but the learning curve is very steep for new users.

Copyright and free licenses are a complicated topic, and confuse many new participants.

Wikimedians generally like to be thorough, but we can’t expect new participants to read dozens of documentation pages before uploading a picture². We needed to create a high-level introduction that presented the basics without misrepresenting the complexity of copyright. No jargon, no legal precedents, no country-specific idiosyncrasies. There would be no “freedom of panorama” or “threshold of originality” here.

During the early stages of the licensing tutorial project, we even decided to ban the words “copyright” and “free licenses” altogether: they’re misunderstood and misinterpreted so often that we chose to explain these concepts in plain English, using practical examples. It was also consistent with our wish to provide plain-English descriptions of licenses in the upload wizard.

I started with a purposely short list of main points that we wanted to cover in the tutorial, and asked experienced participants to review them. The list was effectively a summary based on my own experience and a review of the existing instructions and documentation available on Commons. Then, we met with our illustrator to discuss the general approach and to agree on the rough content.

A collaborative effort

Finding an illustrator wasn’t an easy task. We had several non-negotiable requirements, listed in our Call for proposals. For example, we needed to find an artist willing to release their final artwork under a free license. We also had time and budget constraints.

With the help of Jay Walsh (our Head of Communications), we were able to find a talented illustrator who aligned with our values and met our requirements: Michael Bartalos, an illustrator from San Francisco, who had notably done some pretty awesome work for the California Academy of Sciences.

Puzzly is a character developed by Michael Bartalos in collaboration with experienced Wikimedians.

Michael was extremely accommodating with our hands-on, iterative and open process. Wikimedians are used to completely open, very inclusive processes, but it isn’t as natural in other fields, particularly in art-related disciplines. In the world of illustration, in particular, you usually try to keep all your preliminary and in-progress artwork secret to prevent other people from stealing your still-rough ideas.

Luckily, Michael and I were able to find a middle ground. We agreed not to publish the in-progress designs, and he agreed to let us share them privately with members of our community interested in providing feedback.

I explained the context and reasons honestly on the Commons mailing list and Village pump, and the participants were very sympathetic to these constraints. I invited people to sign up if they were interested in providing feedback, so they could receive a link to the artwork. Most of the people who signed up did write useful comments, and all of them respected our request not to republish it. The feedback they provided was very constructive and of high quality.

We went through this process a few times, first to comment on the general approach and content, then to focus on specific details of wording and graphics.

I found that it helped immensely to ask specific questions to commenters. I structured the page into specific sections and most commenters naturally added their feedback in the appropriate place. I initiated the sections with my own comments, in order to save other people’s time.

Some comments were similar, while others were in disagreement. The preparation made it easier to provide the illustrator with a consolidated summary to help him work on the next version without having to deal with long discussions and contradictory statements.

Translation and localization

The tutorial has been translated and localized into many languages, such as Arabic.

Once the English version was ready, the translation process started. Casey Brown and I prepared the translation framework and provided detailed pieces of advice, in order to inform translators and help them with this particular translation request.

I used to be a Wikimedia translator myself, and I knew how effective they were. Still, I was amazed to discover that, after only three days, about 20 translations of the text had been completed. Furthermore, they had already integrated the translations in about a dozen localized versions of the artwork.

As it turns out, the coordination page containing advice and instructions proved to be very helpful to translators, and well worth the time I had invested in it. About eighteen localized versions are available now, and more are underway.

What next?

The real test, of course, will be when new participants are presented with the tutorial. Will they like it? Will they read it, or jump directly to the next step? Will the tutorial be successful in helping them learn what we want to teach?

So far, we haven’t formally tested it. We were hoping to conduct a study on the tutorial and the latest version of our upload wizard prototype, but we had to postpone it. I do hope we’ll be able to measure the impact of the tutorial at a later point. Still, the enthusiasm with which the tutorial has been welcomed is, it seems, a good sign.

I hope this summary will be helpful to people conducting similar projects. I feel the interaction with the rest of the community has been quite smooth during the whole project. It would be presumptuous to think it was only because I’ve been a long-time community member myself, but it sure helped to speak the same language as the users’.

More generally, the Multimedia usability project was the first engineering project of the Wikimedia Foundation with a Product Manager on its team. I feel this role has played a critical bridging role between the users and the rest of the team, to everyone’s benefit. I’d love to see this happening more regularly in WMF-driven projects.

My own lessons learned, in a nutshell:

• Trust the Power of The Crowd.
• Collaboration is worth the effort.

Notes

Meeting room. CC-by by Luis Argerich.

More often than not, meetings are abused. Let me tell you a short story to help you understand why you should prepare your next meeting if you expect me to attend.

The story

I was invited to a meeting through a Google Calendar invitation. The subject of the invitation was vague, and it contained no description or agenda. A similarly vague email was sent an hour before the meeting, but still, no specific agenda was provided. Unsurprisingly, absolutely nothing was accomplished during that meeting. Time wasted: 1 hour × 5 people. Casualties: 5, dead by meeting.

Another meeting was initiated much the same way, with an unspecific Google Calendar invitation. I requested a specific agenda, and said I would enforce my new rule: No agenda, no meeting. A few “topics of discussion” were added, which was better than nothing.

When the meeting came, random stuff was discussed for an hour, random ideas discussed and thrown in all directions, without any regard for the supposed agenda. All but one participant¹ felt the meeting was productive (see why below). Some vague “next steps” were written down, but all were left unassigned.

Yet another meeting was initiated with an introductory email (a real email, not a Google Calendar invitation) that already included a clear agenda. The agenda contained a list of specific issues to solve during the meeting, and a list of actions that required everybody’s presence. The email included a link to a doodle planner.

Five out of the six guests provided their availability through the planner; the sixth (who was traveling overseas) did so by IM after a personal reminder from the meeting caller². The latter prepared a detailed wiki page and sent the link to the attendees in advance.

The meeting was run in a respectful but firm manner. All items on the agenda were addressed, all issues solved. All the participants felt the meeting was productive. Specific action items were explicitly identified, scheduled and assigned; the meeting caller sent a follow-up email to the attendees, thanking them for their participation, and including a link to the notes and the list of action items.

Why is the latter example the rarest?

De Conventibus

There seems to be a widespread plague of meetingitis, caused by a mix of laziness, and belief that More Brains is better.

First, laziness. More often than not, a meeting is just a way for people to avoid doing their homework. Most useless meetings I have been drawn into have had no preparation whatsoever. It’s simply much easier to throw a bunch of people into a room and have them discuss to death, than to take some of your own time, organize your thoughts and prepare it to save everybody else’s time.

Recently, a volunteer (rightfully) argued on the Wikimedia developers mailing list³ that concentrating Wikimedia tech staff in San Francisco was the best way to exclude remote staff (whether or not they’re calling in) and worldwide volunteers. Similarly, concentrating staff in one location makes meetings way too easy, which means meetings get abused.

Most people who call a meeting have only a vague idea of what they want it to accomplish. They simply believe meeting will solve the issue, because then the work and responsibility are shared with other people. But, as has been amply demonstrated, throwing people into a room to “discuss” something, with no agenda and no guidance, rarely leads to any tangible outcome.

In this context, more is rarely better. For example, it’s been long proven that group brainstorming sessions only appear to be productive⁴. In fact, not only does group brainstorming not foster creativity, but it can even hinder it⁵.

Until now, I’ve assumed good faith, because most meeting callers probably aren’t even conscious of what they should (or shouldn’t) do.

They shall learn.

Notes and references

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.

The Tower of Babel, by Pieter Bruegel the Elder

This article is a follow-up to my previous article about the state of the language selection in MediaWiki and Wikipedia.

Have you ever had a hard time finding your language in a web interface? The interface of MediaWiki is available in literally hundreds of languages, where many other major websites only care about English, and maybe a handful of other “major” languages.

The problem is that, with the number of available languages growing, it has become difficult to find the one you’re looking for. Especially if you don’t know in what language it’s displayed, or how the languages are ordered.

The Universal language picker aims to solve this problem by accepting any valid input from the user and associating it with the language value stored in the software.

Context

The main focus of the Multimedia usability project right now is on developing a new upload wizard, to replace the insanely complicated current upload form on Wikimedia Commons. It’s not going as fast as I expected, but we’ve made some great progress recently.

A few months ago, we did some “hallway testing”: we asked some of our co-workers (who aren’t necessarily wiki-experts) to try out the upload wizard. As they were using it, we watched them and tried to identify what was confusing, in order to improve the interface & interaction with the user.

It was really interesting, as they were all using the upload wizard differently. One was an “explorer”, who would expand each and every sub-menu in order to better understand the options offered to her. Another would just try to proceed as fast as possible, get the job done and get it over with. It was a sort of rehearsal for our then-upcoming User experience (UX) study, and we learned a lot.

Where’s my Hindi?

Drop-down language selector currently used in the JavaScript-enhanced upload form on Wikimedia Commons

During the testing, one of our victims was Aradhana Datta Ravindra, the Project Manager for the Bookshelf project. Aradhana was born and raised in India, and Hindi is her mother tongue.

Our prototype makes it possible to add descriptions in multiple languages. After uploading her picture, Aradhana added a description in English, then naturally tried to add one in Hindi. The problem is, she couldn’t find Hindi in the list.

The interface we use to select the language of each description is a basic drop-down menu, similar to the one already available on the current upload form.

On Commons, the list is ordered by ISO 639-1 code (sort of) but displays the name of the language in this language. For instance, Chinese is displayed as 中文 but listed at the end of the list, because its language code is ‘zh’. You have no way of knowing how languages are sorted.

In our case, the list was ordered slightly differently. It would show the same thing, but ordered as the characters appear in the UTF-8 tables. However, the problem was similar in both cases: the user couldn’t know how to find their language in the list.

We’re not talking about a 10-item-long list. We’re talking hundreds of languages (356 at the time of writing). So, if you don’t know where to look, it can take a while to browse the whole list.

When Aradhana started to look for Hindi, she realized the list was very long. She tried to type ‘h’ to jump to “Hindi” directly. Except Hindi wasn’t there. It was at the bottom of the list, with other non-latin scripts.

Non-latin languages at the bottom of the list in the language picker on Commons Prototype

Later, we had a very interesting discussion about how we should show languages in the drop-down language selector.

Language displayed in the same language

One viewpoint is that, if you’re looking for a language in the list, you should know the name of this language in this language. For example, if you’re English, but you’re looking for German, you should know that the German name for “German” is “Deutsch”.

This is currently how MediaWiki handles language selection in most cases, because this system is considered to be the most language-neutral (see my previous article on this topic). The language picker in your Wikipedia (or other MediaWik-based wiki) user preferences is an example if this:

Drop-down menu from MediaWiki's user preferences to select the language of the interface

Also, although languages are usually displayed in their own language, they’re sorted by ISO code (as in the example above). On the one hand, it makes it easier to jump to your language (if you happen to know the ISO code for it, and your keyboard can input latin characters). On the other hand, the displayed names and the sorting order are inconsistent.

Language displayed in the user’s language: The n × n issue

Another viewpoint is that all languages should be presented in the user’s language. If we consider the same example (you’re English and looking for German), the software should present you with a full list of languages with their English name, and you would be able to select “German”.

That would basically require us to know the name of all languages in all languages. For n languages, you would need a total of n × n translations. That’s a lot.

Illustration of the language table for 3 languages and its extension to an arbitrary number of languages

Even then, the table is obviously incomplete, and may stay incomplete forever. Do you know how to say “French” in Cherokee? I don’t. Wikipedia doesn’t, either (yet).

#include <mindreading>

An n × n language table will be missing many translations.

Actually, even if we somehow managed to get a complete table, we’d still have a problem. Let’s assume for a second we’re able to know the name of every language on the planet in every other language. Some estimate the number of current languages up to ca. 7,000. That means we would have a complete table of 7,000 × 7,000 languages, i.e. ca. 49 million entries.

Now, how do we sort them?

The fact is, you can never really know what the user is going to input. How do you know if they’re entering the ISO code, the name in English, the name in German, etc.? What if the user happens to know and regularly use the ISO 639 code, but doesn’t know the name of the language¹? For extremely long lists, we can’t expect the user to go through the whole list if they don’t even know how it’s ordered.

It all boils down to the implementation model vs. the user model. But in this case, there are multiple users models.

Comes the Universal language picker

The main problem with the previously presented approaches is that they all assume a bijection between the displayed name and the value in the software, i.e. a one-to-one correspondence. Whether it’s displayed with the ISO code, the name in English, or whatever, there’s always only one representation possible for each language.

In the end, what we need is a way to assign multiple representations to a single language value in the software. We need a surjection that recognizes every possible input from the user and associates it with the language value stored in the software.

Surjection between all the possible inputs from the user, and the language value stored in the software

Now, what kind of interface can we use to implement this model?

A simple input field with autocomplete.

Simple as that. Forget endless drop-down menus with weird sorting orders. All we need is a simple input field with autocomplete containing all existing items in the n × n languages table. It doesn’t matter if it’s incomplete: as we get more translations, we’ll add them to the table.

Of course, we’ll need to use an arbitrary sorting order for autocomplete suggestions anyway. But by using an input field with autocomplete instead of a drop-down, the user can refine their search and dramatically decrease the size of the subset of items they’re searching in.

Ideally, the user wouldn’t even have to search: in many cases, it’s possible to guess a sensible default language, based for example on the browser language. We could pre-populate the input field with a grayed out default text that disappears if the user clicks to edit the field.

Further implications

This design has broader applications: the upload wizard is not the only place where the user might want to select a language. User preferences are an obvious example.

Given the multilingual nature of Commons, it would even make sense to add a language selector for the interface on the sign-up page. Right now, the user has to go change the language in their preferences after they’ve signed up.

I’d be delighted to hear opinions and comments about this proposed design. Do you think it would work? How technically feasible would it be?

Notes

The WikiSym 2010 banner, designed by yours truly (except for the logo, by David Bailey).

WikiSym & Wikimania in Gdańsk

I couldn’t attend WikiSym the previous years for various reasons, the main one being money: they were too far away and the registration fee was too expensive. This year, WikiSym was collocated with Wikimania in Gdańsk, Poland, so it was a perfect opportunity for researchers & Wikimedians (or “practitioners”, as researchers call them) to get together and meet. We have to thank my friend Phoebe Ayers for that, who was this year’s Chair/Organizer of WikiSym.

I was pretty excited because WikiSym seemed to be at the crossroads of two of my circles: academia & open collaboration. I was also really looking forward to meeting researchers: the Wikimedia Foundation is currently engaged in an effort to include research into their decision-making process in order to make it more data-driven. Thus, it was the perfect time to try and build awareness, understanding and relationships between the two communities.

Open space schedule boards at WikiSym 2010

Program & Sessions

The symposium was a mix of regular conference talks and an unconference-style Open space track. I wasn’t necessarily a big fan of the unconference style, but one of the most productive discussions I had (about quality assessment tools) actually happened in a group I walked in a bit randomly. I was a bit disappointed by the quality of some talks, but overall the event was great.

One major issue, though, was the number of conflicting talks: there were up to eight concurrent open space sessions, conflicting with each other, as well as with the main sessions and workshops. It was just impossible to take part in everything one was interested in. While this is a usual problem with large events, I didn’t expect to have this issue in a relatively small conference like WikiSym.

I gave a presentation entitled Understanding the users of Wikimedia Commons, a summary of the user research I did for the Multimedia usability project, and it was pretty well received. The audience particularly liked the video I showed from our UX study. The supporting slides are available on Commons  (download the PDF – 504 KB). Unfortunately, the presentation wasn’t recorded, but it was similar to the one I gave at Wikimania, whose recording will be available soonish.

Me trying not to burst into song, being on stage in such a nice Concert hall (CC-by-sa by Blue Oxen Associates)

Not as open as you might think

The second day ended with a discussion in the “Open circle” about copyright. Specifically, the participants asked if they could publish their work (that they presented at WikiSym) under a free license. I was particularly interested, since I had had the very same discussion a few months before.

« Open circle » at WikiSym 2010

In March 2010, I submitted a scientific paper to WikiSym about my work. I had written papers for scientific journals & conferences before, but it was the first time I submitted one in this specific field of research. As a consequence, I was quite happy when my paper was accepted.

Then came the copyright transfer issue. WikiSym partnered with the ACM to publish the proceedings of the conference, and the ACM asked me to transfer my copyright to them. While this is fairly standard in the scientific publishing industry¹, I was surprised by this requirement considering the field of research involved (open collaboration and free knowledge).

I shared my concerns with Phoebe and with Felipe Ortega (Chair of the Program Committee), who reached out to the ACM. The ACM wouldn’t let me release my work under a free license such as Creative Commons Attribution Share Alike (CC-by-sa). I felt my research belonged to the Wikimedia community, and I didn’t want to enclose my work within the ACM’s intellectual property prison.

Hence, I refused to sign the copyright transfer form, even though it meant not being able to present my work at WikiSym. In the end, thanks to Phoebe & Felipe’s efforts and discussions with the WikiSym committee, I was allowed to present my work, but only as a lightning talk, and it wasn’t included into the conference proceedings.

I do hope, though, that at some point we’ll be able to move towards a more open access & reuse model², in accord with the philosophy of open collaboration and free works.

Notes

The observation room at the testing facility; the testing is happening in the background, behind the semi-transparent glass (CC-by-nc by Neil Kandalgaonkar).

Getting there

We reached out to some UX firms and published a Call for proposals in February. Several firms submitted proposals; after serious consideration, we chose to work with gotomedia, a San Francisco-based firm that seemed to align best with our goals & values.

The study was planned to take place in March, but was postponed because the prototype was not ready. In the meantime, we asked some of our co-workers to test it in order to uncover the most obvious flaws & bugs.

Goals & testing conditions

A few weeks ago, the actual testing eventually took place. We tested ten users: five locally in San Francisco, and five remotely within the US. We considered conducting similar testing abroad, in order to identify language-specific issues; but in the end, it turned out that we wouldn’t learn a lot by simply replicating the same test script.

Multilingualism on Commons (and Wikimedia websites generally) is a huge piece of work that deserves dedicated efforts, and dedicated UX studies. The main reason for which we decided to hold the testing halfway through the project, and not at its very beginning, was that we could test both the current upload interface, and our prototype.

On the one hand, during our preliminary research phase, we identified a large number of issues with the current interface; but we still needed to formally record the user experience and validate our preliminary conclusions. On the other hand, we wanted to do a reality-check with our prototype, to see if the direction we had chosen was appropriate, and to identify areas of improvement.

Highlight videos

The testing sessions went pretty smoothly. The gotomedia folks did a fantastic job at preparing the “highlight videos” in time for our conferences in Gdańsk (WikiSym & Wikimania). The audiences really liked them, although we didn’t have time to show all of them.

Highlight videos are edited summaries of the main findings of the study. In our case, we have three highlight videos: one about the testing of the current interface on Commons, one about the testing of the prototype, and the last one about how we could improve the prototype.

Long story short: the current interface is a nightmare, and the prototype is way better, even if there are some minor things to improve. The good news is, all the items to improve were already planned features at the time of testing, and they have either already been added, or will be before the upload wizard is released.

Namely, one of the main remaining issues is the fact that users don’t really understand copyright and free licenses. That’s why we’ve been working on a licensing tutorial at the same time, to be released jointly with the new upload wizard.

See for yourself

The highlight videos are now available on Wikimedia Commons; per our agreement with gotomedia, all the videos were released under the Creative Commons Attribution – Share alike 3.0 license.

In the tradition of Wikipedia’s Neutral point of view policy, we’ll try to upload the unedited videos to Commons as well, in order to let the community draw their own conclusions.

If you would like to draw our attention to things we’ve missed, or even edit your own highlight videos yourself, you are warmly invited to do so. You can watch the highlight videos below (if it works) or on Commons. The links to Commons are available below if you want to download the video files on your computer.

Your feedback and comments are much welcome.

Current interface highlight video

Prototype highlight video

Room for improvement highlight video

Files

• Current interface testing: File page on Commons – Download OGV file (4m11s, 29.89 MB)
• Prototype testing: File page on Commons – Download OGV file (5m32s, 35.43 MB)
• Room for improvement: File page on Commons – Download OGV file (3m51s, 23.02 MB)