[Foundation-l] Self-determination of language versions in questions of skin?

Erik Moeller erik at wikimedia.org
Fri Jul 2 21:21:06 UTC 2010


2010/6/28 Tim Starling <tstarling at 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/UsabilityInitiative&title=Special:Code/MediaWiki/path
) ; 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.
-- 
Erik Möller
Deputy Director, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate



More information about the foundation-l mailing list