2010/6/28 Tim Starling tstarling@wikimedia.org:
In this case, I would recommend a process of negotiation. Detail your concerns in Bugzilla, and give the developers time to respond to them.
This is good advice. I want to add that there's something very unusual about the work that's been done over the last year, relative to many other software changes we've made over the years. Its primary audience is not in fact the community of individuals who may participate in polls or file bugs in BugZilla -- its primary audience are the readers of Wikimedia Foundation projects who have knowledge to share, but who may find our user interface and user experience too daunting to do so.
The changes we've made have therefore not been directed at experienced editors at all, and insofar as we've considered their needs and interests, our primary intent has been not to cause significant impediments or inconveniences except where such inconveniences were deemed necessary trade-offs to accomplish a better experience for new users.
Our motivations for engaging in such a project are rooted in the well-established trend of stagnation and, in some cases, decline of key participation metrics in the largest Wikimedia projects. Those trends can be seen clearly in the numbers of active contributors, and the numbers of new editors joining the projects:
http://stats.wikimedia.org/EN/TablesWikipediansNew.htm http://stats.wikimedia.org/EN/TablesWikipediansEditsGt5.htm
German Wikipedia, by the way, is no exception from this trend, and indeed, shows a significant decline in the number of new editors joining, and a less dramatic but still pronounced decline in the number of active editors from its peak levels.
User experience, by its very nature, is habitual. Don Norman, in "The Design of Everyday Things", describes many examples of idiotic design decisions for everyday objects like doors, projectors, or stove top controls. After initial irritation, we accept those design decisions, get used to them, and will suffer another brief irritation when someone tries to fix them.
The same is true for user interfaces in software. A degree of temporary inconvenience when changing user interfaces is unavoidable, and thus, any such change tends to be accompanied by voices of frustration and irritation by established users who have learned the habits the software forced them to learn. In no way is such frustration or irritation alone evidence that the change was wrong: it is entirely to be expected.
Agile user testing in small groups is a well-established methodology for engineering a better user experience and surfacing key impediments for new users of a given interface. The improvements we've made have been grounded in real impediments people with no prior editing experience have encountered when navigating Monobok's cluttered and tiny tabs, utilizing the mystery toolbar (a trumpet? really?) [*], finding the tiny search box in the sidebar, etc.
Thus, we are in favor of continued conversations about the best user experience for Wikipedia, but we're not going to roll back the user interface only because a self-selected majority of active editors vote to decide to make it so. Let's have focused conversations about whether the changes we've made serve the established need (creating a better participation experience for new users) without unintended side effects and unacceptable trade-offs. Surfacing normal change resistance is not particularly helpful; surfacing facts and thoughtful arguments certainly is, and we've tried to respond to those.
As many of you have seen, we've continued to make changes and apply fixes to the new UX at a fast pace (see http://www.mediawiki.org/w/index.php?path=/trunk/extensions/UsabilityInitiat... ) ; that pace will slow down in July due to Wikimania, but will resume at full swing thereafter. We are also incrementally improving our analytics (using open source tools) so we can better measure the actual impact of everything we do.
All best, Erik
[*] I'm personally responsible for the initial design of the edit toolbar, and deeply appreciate the work that's been done by the team to identify what people actually click on, come up with sensible icons, and remove clutter. The toolbar was always conceptualized with new editors in mind, and the new design serves that audience much better.