March 4, 2010, 4:06 pm
During the past few weeks, I have been thinking about a more structured way to manage software and product development within the Wikimedia community. The result is a list of ideas and recommendations I have compiled and submitted to the relevant staff members at the Wikimedia Foundation. I am also publishing them here in order to allow for a wider feedback. This article is the second of a series dedicated to this topic.
Disclaimer: The content of this article reflects only my personal opinion and is not an official plan or communication of the Wikimedia Foundation.
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
December 1, 2009, 6:01 pm
As part of the Wikimedia Multimedia Usability project, we are currently doing what is called Domain research. Basically, it means that we look at how similar websites work and how they deal with the same issues we encounter. Since our goal is to make Wikimedia Commons more usable, we want to look at other media sharing platforms, such as Flickr, Youtube, Fotopedia, Picasa web, Panoramio, etc.
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.
November 25, 2009, 9:26 am
For a few months now, I have been maintaining a newsletter on my weblog in French called “Actualités Wikimedia“; it consists typically of very short stories and links about news of the Wikimedia universe that I find noteworthy. Part of these news come from RSS feeds in English that I follow; I summarize them in French in order to bring them to a larger audience.
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.
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.
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.
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.
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.
June 30, 2009, 12:22 pm
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
- 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.
- 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.
- 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.
- 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.
- 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
- 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
- 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.
- 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”.
- 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.
- 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.