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.
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.
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.
There are two main use cases for language selection across Wikimedia projects: the language of the content, and the language of the interface. In this article, I am reviewing a few examples of tools related to language selection on MediaWiki websites, and particularly on Wikimedia wikis.
… and I’m neither saying you should, nor you shouldn’t.
As part of the Multimedia Usability project, I have been doing a lot of research to better understand how Wikimedia Commons is functioning, and particularly to understand its users & participants. One side I am particularly interested in is the demographics and the content dynamics of Commons.
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.
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.
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.
During the past few weeks, I have been thinking about how to improve (or rather, kick off) 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 first of a series dedicated to this topic.