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

I have previously explained why the current setup of the Wikimedia bug tracker is not ideal. I have also advocated for a more managed & scientific software development strategy. This article aims to discuss an appropriate tool to support this strategy, and at the same time fix what is broken.

Software lifecycle & Project management

Right now, there is little project management of the technical activities at the Foundation. When someone does manage projects, they often use personal desktop applications that don’t allow collaborative work. There isn’t any real development roadmap or product requirements. If we want to be serious about structuring our activities, we need a project management strategy & the appropriate associated tools that allow us to manage things such as project scope, schedule, budget & financial resources, quality assurance, human resources, communications, risks & opportunities, procurement and coordination.

I asked around to see what the needs of the various members of the team were. Naoko Komura, who has been project-managing the Wikipedia Usability Initiative, and is now overseeing all UX programs, is particularly interested in the integration of the Project management platform with calendars & issue tracking. Operations staff members also said they were interested in Project management features such as time and task tracking.

I think it is way past time to have a more organized development process & software lifecycle management. The recent hiring of a new Chief Technical Officer is a step towards a more structured organization of technological activities. Of course, changing our bug tracker alone won’t automatically structure our activities, but it is a step in this direction.

Recommendation: Use tools that allow a better management of, and integration between, the different stages in our product(s) lifecycle.

Requirements

A few months ago, I asked Priyanka Dhanda (our new Code maintenance engineer) to explore open-source collaborative project management platforms that could be easily integrated with bugzilla (or that included a bug tracking system of their own). The Wikimedia tech community was invited to list requirements of such a tool, as well as possible solutions.

From the feedback we received, we can summarize what the required features for an issue tracker are: integration with our Version control system, being FLOSS, multiple projects support and ability to separate between “tasks” and other items such as bugs and feature requests. Additional, “nice to have” features include: ability to import data from existing Bugzilla instance and fined-grained e-mail subscription options

Similarly, the required features for a Project management tool are: being web-based to facilitate collaboration, multiple projects support, calendar/scheduling and roadmap, assignments & resource management and time tracking per task/user/project. Additional, “nice to have” features include: Gantt charts, public/private projects, fine-grained access to projects by user, basic accounting & budget management and requirements management.

Redmine

I haven’t found many Project management softwares that can be easily integrated with Bugzilla. However, I have discovered alternatives to Bugzilla that include project management features like those we’re looking for. Redmine seems to be a good project management software and provides an advanced issue tracking system as well. It supports multiple projects, public/private projects, calendars & Gantt chart, and a lot of other neat stuff. It also offers the ability to distinguish between features/improvements and bugs; this would be particularly useful to prioritize development efforts. We are now considering using Redmine as project management software and taking this opportunity to move our Bugzilla setup to Redmine. Initial research shows that a lot of people seem to praise Redmine compared to Bugzilla; there are migration scripts to import an existing Bugzilla setup into a new Redmine one.

Major projects such as TYPO3 are using Redmine. The software seems to benefit from a dynamic community of developers and it is also possible to sponsor custom development. There are many plug-ins to extend the default core features; popular plug-ins are usually included into the core software at some point.

Priyanka set up a local test instance of Redmine to let us play with it a bit; a public test platform was later made available for wider testing and the Wikimedia Tech community was invited to pitch in. So far, I personally like it and it fits my needs perfectly. Wider testing is now necessary to see if it fits the needs of the tech community.

Because the time I can devote to this change is limited, I haven’t reviewed other alternatives than Redmine, and don’t plan to unless another major alternative is suggested.

Recommendation: Move from Bugzilla to Redmine after careful preparation, especially regarding the organization of the platform.

Read also in this series

• Wikimedia & MediaWiki bugs, issues and requests
• Wikimedia User experience programs: a systematic approach
• Scaling up Software development for Wikimedia websites (Part I: Human resources)

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

I am not going to give specific advice about how many developers the Wikimedia Foundation should hire: there are other people more knowledgeable about how many we need, and what they should work on. However, there are other key positions that I think are need to scale up.

Our human resources are currently focusing on what happens after the code has been written: we review it, we try to ensure quality, we try to automate testing, we file bugs, etc. However, there is little preparation before the development is actually done. This has led to a developer-driven design, resulting in an interface based on the implementation model. We need a more systematic approach to User experience and development management if we want to scale up properly.

Product management & Design

In the Software development world, Product managers and Designers are the most common bridges between users and engineers. Product managers identify the needs of users and prioritize features & improvements; their goal is to translate the users’ experience and feedback into explicit requirements to meet the users’ expectations. It is then the role of the designers to create innovative, well-thought solutions to address these issues and meet the requirements. Finally, developers provide feedback about the technical feasibility of these solutions, and implement them the best way possible. This is of course a simplistic summary, but it helps get the point across.

“Designer” can have a lot of different meanings. A lot of people think that “design” is just making things pretty. When I talk about designers, I think mainly of Interaction Designers, i.e. people who design solutions to improve the user experience and the way the product interacts with the user.

The community of MediaWiki users is amazingly large, partly because they include participants from all Wikimedia Websites. Similarly, MediaWiki also benefits from a large base of volunteer developers. Product managers and designers have been the missing piece in this picture; their bridging role is critical, simply because there aren’t any volunteers to take up this task. Admittedly, some users are also developers, and some developers keep themselves informed of the users’ wishes. But without product managers, clear requirements & prioritization are missing. And without designers, the technical solutions created by the developers don’t meet the users’ expectations and mental model.

In my experience, developers prefer to focus on the actual development and rarely enjoy meta-activities related to it. They usually dislike project management and writing product specifications, and rightly so: it is not their job. However, a successful software product strategy cannot rely only on development. We benefit from a large community of volunteer developers, but we lack management & design resources; it is the role of the Foundation to supplement this lack. It doesn’t mean we shouldn’t expand our development team: our number of paid core developers is ridiculously small. It only means we should also invest where the weakness lies.

Recommendation: Recruit Product managers and Designers to strengthen the development cycle of our technological platform

Research team

The Multimedia usability project has relied heavily on initial research in order to gather as much information as possible about users and their goals. A lot of useful information was already available, but a lot of specific metrics were also missing; collecting and analyzing them took a lot of time and it will still take months to get all the metrics we need. Research is critical in order to make the right decisions, especially about design. Research is the only way know our users in order to make the best design & management decisions. Good research is the best basis on which product managers, designers and developers can then respectively specify, design and build awesome solutions.

Right now the only researcher we have is Erik Zachte as Data analyst, but his job seems to essentially focus on providing operational metrics. While this work is much needed, we also need some more specific data on a case by case basis. I see at least three other positions needed:

• A UX research specialist, who would conduct regular in-house low-cost usability testing, and generally manage UX studies
• A Metrics engineer, who would develop integrated metrics in the software and be able to extract specific information from the database on a case by case basis.
• A Community specialist, with a good knowledge of social psychology and online interaction, who would especially focus on improving the interaction between participants by identifying the community issues and proposing ways to fix them.

Recommendation: Build a Research team to guide design & strategic decisions about our technological platform

Volunteer developers

We benefit from a fantastic community of volunteer developers, but we underestimate their potential; I think we are not doing enough to support their work and engage them into our activities. In 2007, the Foundation hired Cary Bass to try and coordinate the large pool of volunteers willing to help us with meta activities. Similarly, we need a Dev community manager to care for our volunteer developers. We need someone who knows the developer community very well, and knows their strengths and weaknesses in order to find the right person for each job. We need someone who can help orient new volunteers, organize real-life meet-ups and manage projects such as the Google Summer of Code.

Recommendation: Recruit a Community manager to coordinate the efforts of volunteer developers.

Read also in this series

• Wikimedia & MediaWiki bugs, issues and requests
• Wikimedia User experience programs: a systematic approach
• Scaling up Software development for Wikimedia websites (Part II: Tools)

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

• 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)

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

Bugs & Bugzilla

Right now, the bug tracker we use is based on Bugzilla and located at bugzilla.wikimedia.org. Many major free projects use a generic “bugs” or “issues” prefix or suffix in their URL: bugs.kde.org, bugs.gentoo.org, issues.apache.org, www.debian.org/Bugs. Some projects use the “bugzilla” prefix like we currently do, like bugzilla.gnome.org. The latter is an example of a choice based on the implementation model: the name reflects the technical implementation of the bug tracker, not its actual purpose. A better name would be closer to the user model and describe the actual goal of the platform: to report and manage bugs and issues related to a specific project. If we do change our tracker, the current name will have to change too, because it is specific to a given tool.

Recommendation: Use a generic descriptive prefix rather than one based on the tool we use.

Wikimedia & MediaWiki

Another current issue is the confusion caused by the similar names used for the organization (Wikimedia) and the software (MediaWiki). A good example of this confusion is the number of MediaWiki users who join the #wikimedia IRC channel instead of #mediawiki to ask for software support. The confusion is even worsened by the fact that we have a unique bug tracker located at bugzilla.wikimedia.org, dealing with issues related to both Wikimedia websites and the MediaWiki software.

There are obviously strong ties between Wikimedia projects and MediaWiki: all Wikimedia projects use the MediaWiki software, and the MediaWiki software is primarily developed with Wikimedia projects in mind. However, there is also a growing community of MediaWiki users who are not Wikimedia users and we should provide them with tools relevant to them. This might be for instance a support forum dedicated to MediaWiki users.

Wikimedia projects and MediaWiki are separate products and they should be acknowledged as such: as a consequence, the separation between bugs in the MediaWiki software, and Wikimedia-specific operations & configuration requests should be made more explicit. Obviously, we would prefer to have a unique back-end to support both sites, particularly to be able to move bugs and requests from one platform to another, but this is easily configurable. Possible names could be dev.mediawiki.org and tech.wikimedia.org; both are currently unused. They are pretty wide prefixes, because we may host a real project management platform there, rather than just bug trackers.

Recommendation: Offer two different public-facing platforms for MediaWiki- and Wikimedia-related issue tracking.

Read also in this series

• Wikimedia User experience programs: a systematic approach
• Scaling up Software development for Wikimedia websites (Part I: Human resources)
• Scaling up Software development for Wikimedia websites (Part II: Tools)

A couple of topics were discussed during the meet-up, notably the next Maker Faire, the next meet-ups and the possibility of organizing a regional Wikimedia conference later this year, probably around November. I am also going to try and promote Commons as much as possible while I’m here.

As people were talking about the need for various kind of documents and goodies to hand out at the Maker Faire, I realized that we could actually organize some sort of Marketing Marathon during the next meet-up. The goal would be to write together the content of documents, based on pre-arranged templates so that it fits with the design.

I have to admit my other responsibilities within the Wikimedia movement have distracted me quite a bit from the Wikimedia documents initiative I launched in May last year. It would probably have helped a lot if some people had responded to my call for volunteers. Not only would it have saved time, but it also helps immensely when other people are interested in your work: it puts some friendly pressure on you.

The Marketing Marathon proposal was well received and we agreed to organize it as part of the preparation for the Maker Faire during the next meet-up. I now have volunteers willing to help, and a draft timeline with the next meet-up and the Maker Faire. Besides, I hope to benefit from the research made by the Bookshelf project, which already answered one of my questions: what standard format to use for documents intended for an international use.

If you would like to help, or if you think you have good ideas, feel free to contact me.

As a consequence, I will be available on IRC to answer questions related to the Multimedia usability project this Thursday, February 4, 2010 @ 1700 UTC. You can use the fixed time world clock to check the time in your timezone. Please join us in #wikimedia-office on Freenode using your favorite IRC client; you may also use web-based clients (check out the IRC office hours page on meta-wiki for more information on how to do that).

Looking forward to your questions.

Golden Gate Bridge, Rodefeld, CC-by

The last couple of weeks have been quite busy for me. I moved from Toulouse, France, to San Francisco, California as a consequence of my hiring by the Wikimedia Foundation (the non-profit that runs Wikipedia) where I work as Product Manager for Multimedia Usability.

I just got my Internet connection at home set up, so you should see more regular blog articles now. I have a few drafts in the works and a lot of updates to post related to my work at the Foundation. In the meantime, I invite you to read the summary published today on the Wikimedia blog.

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.

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.

I assume that you write your weblog in order to be read. The more people read your work, the further your ideas travel and the more impact you have. At least, it’s how it works for me.

Like many other readers of yours, I use RSS feeds to stay informed of new articles you publish. I collect RSS feeds from many websites into a desktop application that sorts them by topic.

I happen to travel a lot these days, which means I have scarce Internet connection. As a consequence, I update my RSS feeds when I can and read them offline later, for example in the train I am right now.

The problem is that your RSS feed only contains the first three lines of your article. Sometimes, it even cuts  a sentence in the middle. In order to read the full article, I have to visit your website, because somewhere in your blog’s configuration, you disabled a setting allowing the full article to be included in your RSS feed.

Please don’t do that.

Don’t force me to read your work online on your blog. It’s annoying. It’s rude. It frustrates me.

I want to be able to read your work wherever I am, whenever I want, even if I don’t have an Internet connection. I am really interested in what you have to say; I value your ideas, your insights, your sense of humor; I enjoy reading your prose.

Dear blogger, if you care about your readers as much as they care about what you have to say, please make it easier for them to read your work. Not more difficult.

Thank you.