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?

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)

and it was fun.

Shared values & challenges

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, if it works.

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 LUG. 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, FAOTD, POTD), 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?

Disclaimer: The content of this article reflects only my personal opinion and is not an official plan or communication of the Wikimedia Foundation.

A Japanese teapot. Friends of Donald Norman will understand. CC-by by Denis Savard

Investing in UX is a Good Idea™

Over the years, the design of MediaWiki has been solely driven by software developers. This has caused an unfortunate technology-based approach of the front-end and the features (implemented or missing), relying mostly on the implementation model. The consequence is that the interface & features are too far from the users’ mental model. The Wikipedia and Multimedia Usability projects have tried to address the most pressing concerns resulting from this hiatus between the software and the users’ expectations.

For all these reasons, I am really happy to see the Wikimedia Foundation investing further in User Experience (UX). However, I see little added value in having an UX department separate from the main development cycle. There are at least two reasons to keep them as one.

UX should be a systematic approach

A more systematic approach is necessary in order to improve the usability of Wikimedia projects perennially; good, usable design needs to happen before the actual implementation of any feature, in the early stages of the product (or component) development. Otherwise, we will always be running after the train, and never catch it. A separate entity made sense when these UX programs had a specific scope and time frame, but it was because they were tied to specific grants. In a more permanent setup, I see no reason to separate UX programs from the “regular” development processes; targeted actions can be carried out by specific projects inside the development team, rather than by a separate team altogether.

Everything is UX

More generally, all the activities of our Technology department are about User experience; everything we do is UX. Software development aims to fix bugs, develop new features, improve others, and remove hindrances. The sole goal of all of these activities is to improve the user experience by making the software better and closer to users’ needs. Even Operations are about UX: the goal of the Operations team is to make sure the information can be accessed reliably and reasonably fast by an audience as large as possible; in short, the point of Operations is to ensure we actually provide a user experience.

As a consequence, I recommend to make UX a systematic part of the product or component development cycle, not a separate parallel entity.

Read also in this series

• Wikimedia & MediaWiki bugs, issues and requests.
• Scaling up Software development for Wikimedia websites (Part I: Human resources)
• Scaling up Software development for Wikimedia websites (Part II: Tools)

I would like to ask for your help to accomplish this research. It can take a lot of time if only one person is doing it. On the contrary, if ten or twenty people step in and all do a small part, we can collect helpful data very quickly. Besides, it is always better to have several people with different perspectives look at the data we collect, in order to better see the “big picture”.

Your help is crucial in order to move quickly towards the requirements definition phase. I have already prepared a list of websites and a few questions we are asking ourselves; they should facilitate the collection of data that can then be used directly by the team.

Please join us and make your contribution to the Domain research page on the Usability wiki.

I also follow another set of RSS feeds related to User experience (UX), Interaction design (IxD) and Usability in general. Until now, I have been reading them for my own benefit; but with my new job, it makes sense to pick a few interesting pieces of information for Wikimedians who want to better understand the work of the Wikimedia usability team(s). As a consequence, I will try to maintain a “UX & IxD newsletter” on this weblog, starting with this one.

Japanese Cast Iron Tea Kettle. Friends of Donald Norman will understand. (CC-by by Steven Depolo)

User research

What is the point of user experience research? It may seem obvious to any designer, but it is harder to explain to clients or, in my case, to the Wikimedia community. People who are not familiar with interaction design and product development in general often have a hard time understanding why it is critical to “lose” time in research (it is really “invest”) at the early stages, even when the course of action looks so obvious. David Sherwin provides a “cheat sheet” to explain the value of user experience research in plain English.

• Can You Say That in English? Explaining User Experience Research to Clients, David Sherwin, A List Apart, 3 Nov. 2009.

What are the benefits of using personas in product design? Personas are fictional model users based on behavioral patterns and goals of real users that we have studied. More than just stereotypes with a stock photograph stuck on a board, they are very much like other scientific models based on experimental data. As a trained scientist and a follower of the Cooper methodology, I make an intensive use of personas for my work on the Wikimedia Multimedia Usability project. Despite their broad use in design teams, few studies have tried to assess the actual effectiveness of personas; Frank Long has now published such a study.

• Real or Imaginary: The effectiveness of using personas in product design, Frank Long, Irish Ergonomics Review, Proceedings of the IES Conference 2009, Dublin, 20 Nov. 2009.

Design principles

Let users explore and discover your website. There is a trap MediaWiki developers easily fall into: the interface of MediaWiki (and, as a consequence, the one you see on Wikipedia and Wikimedia Commons) is cluttered by dozens of unnecessary links and verbose descriptions. On the other hand, the software is so complex that a lot of features remain hidden even to established participants. What we need is a simpler interface that provides the relevant links and hints when appropriate, and at the same time empowers and encourages users to be bold and explore the interface. Amber Simmons provides a few pieces of advice on how to improve discoverability in order to make websites more explorable.

• You Can Get There From Here: Websites for Learners, Amber Simmons, A List Apart, 3 Nov. 2009.

Product implementation

A babelfish for designers and developers. In the world of software and website development, it is not uncommon to find designers and developers working together. This is for instance the case with the Multimedia Usability project, where the core team is comprised of two people: me and a software developer. However, communication between designers and developers is not always easy, because of their different backgrounds and perspectives; it could be compared to chatting in a foreign language. This is something I have also experienced during my previous work as an interdisciplinary researcher: I was a physicist and microtechnologist working closely with chemists and biologists. In her latest article, Theresa Neil provides some good advice in order to facilitate the communication and collaboration between designers and developers.

• Designers vs Developers: Coming together to build the best RIAs, Theresa Neil, Designing Web interfaces, 10 Nov. 2009.

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.