A long-awaited feature has just been added to Wikimedia Commons by volunteer developer Bryan Tong Minh.
I just found out 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.
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.
The new user galleries list recent uploads for any user, including thumbnails and basic information.
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 similarly to 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?
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 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 portion of the concert on YouTube. The concert was lovely, even though the audience didn’t necessarily measure up.
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!
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.[1]
Copyright law 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.
Wikimedians generally like to be thorough, but we can’t expect new participants to read dozens of documentation pages before uploading a picture.[2] 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.
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 fewtimes, 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
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’s 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.
Free knowledge is the foundation of all Wikimedia projects: anyone is free to use, modify and redistribute the content for any purpose. But copyright and free licenses are very confusing for new users, especially when they want to contribute pictures and other media files. A new illustrated licensing tutorial will now guide new users through the basics of copyright and free licenses to make their first steps easier.
You may remember that the Wikimedia Foundation :doc:`unveiled a prototype of upload wizard <prototype-upload-wizard-unveiled-for-wikimedia-commons/>` for Wikimedia Commons (the repository of freely reusable media files used in all of our projects) a few months ago. The prototype was developed as part of the Multimedia usability project, a grant-funded, one-year project aiming to increase multimedia participation on Wikimedia websites.
One of the main issues identified early on is that the current workflow of the upload process attempts to provide an advanced course in worldwide copyright when the user uploads a file. In reality, our research showed (unsurprisingly) that most users either gave up in front of the overwhelming instructions, or simply ignored them.
Our approach was to separate the “educational” part of the upload page from the actual upload form. Copyright has proven to be one of the most unappealing topics to new users, who simply want to share their knowledge and artwork. For that reason, we created an illustrated licensing tutorial in a comic-strip format.
This licensing tutorial was developed with experienced Wikimedians, who had both the expertise on copyright and licenses, and the experience of guiding new users. They collaboratively improved the wording and suggested many changes to the illustrator. You will see that the tutorial features a new character, who was developed specifically for this project. We experimented with several others, but the puzzle-piece character was the one that worked the best.
Although developed primarily for Wikimedia Commons, both the tutorial and the character are under a free license; we hope experienced participants will reuse them for similar tutorials and across help pages.
The tutorial was created by Michael Bartalos, a freelance illustrator from San Francisco. Michael did an awesome job at illustrating complex topics without sacrificing readability or accuracy. I would like to thank him for putting up with our hands-on approach; it surely wasn’t easy to accommodate our requests and all the little details in wording, typography and graphics that Wikimedians are expert at.
The tutorial is now available on Wikimedia Commons as an editable vector graphics file (SVG) to facilitate localization. It will be included in the Upload wizard’s interface when it is released at the end of November.
In the meantime, Wikimedia translators are warmly invited to help translate and localize the tutorial. If you don’t feel comfortable creating the localized tutorials yourself, you can focus on the text. We’ll seek help from the Graphic Lab on Commons to create the localized artwork.
Our volunteers are awesome. More specifically, Magnus Manske is awesome. He just made reusing pictures from Wikimedia Commons a hundred times easier.
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 (Source)
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 (Source)
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.
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.
Have you ever had a hard time finding your language in a web interface? 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.
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.
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?
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.
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 of this.
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
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>
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 type in. 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? [1] 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?
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?
If you’ve ever tried to upload a file to Wikimedia Commons, you may have grown frustrated. Our new upload wizard aims to make it easier to contribute multimedia works to Wikimedia projects, and the first test results look promising.
Wikimedia Commons is the media library associated with Wikipedia; it is a central repository for all Wikimedia projects, and any media file shared there can be used in any Wikipedia page in any language. Wikimedia Commons is curated by a multilingual community and recently reached 7 million files.
Wikimedia Commons relies on MediaWiki, the same software that powers Wikipedia. Because MediaWiki was primarily developed for text-based content like Wikipedia articles, contributing multimedia works has always been a challenge.
In July 2009, the Ford Foundation awarded a $300,000 grant to the Wikimedia Foundation to improve the tools and workflows related to multimedia participation. The following Multimedia usability project started in October with a phase of preliminary research, and we worked with the Wikimedia community to identify the key issues and design solutions.
Over the past few months, Neil Kandalgaonkar (NeilK) has been implementing the interface we designed. The result is a prototype upload wizard that we’re happy to share now with the community.
We recently conducted a User experience study, both to evaluate the current upload interface and to make a first check on our prototype. Our first results look promising and show a clear improvement over the current interface (watch the videos); we’re hoping to share the full videos in the coming weeks. We’ve also taken into account the informal feedback already provided by the first community testers.
The prototype isn’t finished yet, but we feel it’s important to continue to include the Wikimedia community in the ongoing development of our tool. We would like to invite you to test the prototype, read the Questions & Answers page, and share your comments and questions on the feedback page.
We thank in advance every user who will help us provide better tools and interfaces for the Wikimedia contributors. The prototype is located at http://commons.prototype.wikimedia.org.
Update:
2015-12-27: Removed the links to the prototype, since disabled. Removed the link to the list of existing bugs, now inaccessible.
Three weeks ago, I attended the WikiSym 2010 conference. WikiSym is the “International Symposium on Wikis and Open Collaboration;” it’s sort of the “Academic Wikimania,” where people researching wikis, Wikipedia and generally open collaboration get together and share their findings.
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.
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.
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.
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,[1] 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,[2] in accord with the philosophy of open collaboration and free works.
Over the past few months, I’ve been coordinating the preparation of a formal User experience (UX) study for the Multimedia usability project. Basically, it means observing how “real” users interact with the Wikimedia Commons in order to improve it. Videos of the testing have now been published in order to share them with the community.
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.
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 (streamed from Commons) or directly 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.
Three weeks ago, I attended the KDE Akademy 2010 conference in Tampere, Finland. Besides the talk Parul Vora and I gave to share experience about User experience, I also took this opportunity to meet with the KDE community and discuss collaboration opportunities.
The talk we gave at KDE Akademy was entitled Wikimedia User Experience programs: lowering the barriers of entry. Basically, we presented the work done as part of the Wikipedia usability initiative, and the Multimedia usability project.
It might seem odd for Wikimedia to be presenting at KDE Akademy: Wikimedia is mostly about online content, while KDE is mostly about desktop software. Yet, they share common goals & values.
On the one hand, a common criticism made against KDE is its feature creep: the tendency to allow for maximum customizability in KDE often comes at the price of simplicity and ease of use.
On the other hand, MediaWiki, the software on which rely Wikipedia and the other Wikimedia websites, suffers from the same flaws: it has always been “designed” by developers. As a consequence, the interface reflects the implementation model, and often doesn’t match, or even conflicts with, the user’s mental model. The Wikimedia Foundation recently started to include user research and design as part of their development cycle, where user experience is taking a increasingly critical role.
Our presentation at Akademy was an opportunity to share experience. Both KDE and Wikimedia communities struggle to improve complex interfaces, and both communities have a lot to learn from each other.
Wikimedia and KDE also have more practical ties: Wikimedia Deutschland e.V. and KDE e.V. used to share an office a few years ago. I’ll take this opportunity to thank Claudia Rauch for inviting us to submit a proposal for Akademy this year.
Presentation slides & video
Thanks to KDE e.V. and their awesome volunteers, the full video of our talk (and the follow-up discussion) is available, along with all the other videos, from the Akademy schedule page. A slightly edited version is also available from Wikimedia Commons; you can also download the file to your computer (Download - OGV, 162 MB). Or, you can watch it below (streamed from Wikimedia Commons), if it works in your browser.
The presentation slides aren’t very useful alone, but they’re also available on Commons if you want to take a look or watch them alongside the video (Download - PDF, 2.2 MB).
Meeting the KDE community
I’ve had some interaction with the KDE community before. I used to live in the same city as one of the lead KDE developers, and we belonged to the same Linux User Group. I’m also familiar with the digiKam community, with whom I’ve been working on and off.
Besides our presentation, Akademy was also an opportunity to get together with the “gearheads,” to discuss collaboration opportunities, and of course to get my debugging duck.
“Take the duck from your desk, look at your code and explain to the duck—line by line—what it does.”“
Working hand in hand
We had planned to hold a more hands-on workshop to discuss practical common projects between the two KDE& Wikimedia communities. Unfortunately, I had to leave Tampere early to fly to Gdańsk for WikiSym & Wikimania. I didn’t have much time to explore the city either, which is a pity; Tampere is a quaint little city, and the surroundings looked really charming.
I would still like to work on common projects, as I think there’s a huge potential for a better integration of Wikimedia websites with the desktop. Since I’ve been thinking about this for a while, I have a few ideas of my own: mass upload tool, offline wiki editor, desktop widgets (e.g. for Wiktionary, Featured article of the day, Picture of the day), application plugins (e.g. to find media files from Commons from within an application), instant messaging with other Wikimedia editors, etc. That said, I would also like to collect ideas & feedback.
So, what Wikimedia content would you like to access from your desktop? For what use? What desktop tool would facilitate your editing or reading of Wikimedia projects?
