On Wed, Aug 13, 2014 at 10:12 PM, Pete Forsyth <peteforsyth(a)gmail.com> wrote:
In favor of the Media Viewer software is a bunch of
inquiry and analysis
Restoring the default state of the software to the state that worked for
the last decade is a clear precondition for healthier discussion of a
positive path forward.
Dear Pete,
You speak as if there is no cost to disabling and re-enabling an
interface. That is not the case.
As you say, millions of readers use the site. And just like editors,
introducing a new, very different viewing experience - like MV - takes
some time to adjust to. We saw this in survey responses improving over
time where they were initially negative, and we also saw it in some
comments of the type "I am getting used to it now and I like it". (We
also got plenty of "I love this, this is great" type comments.) To the
extent that there are discoverability issues in the current UI, they
are just that: discoverability issues. That doesn't mean if the same
user keeps using the same inteface, they will never click a button -
it means it's harder to figure out than it needs to be.
Some of this was already fixed in production. For example, adding a
label to the "Use this file" button more than doubled its usage. This
is how this stuff works: You instrument, you change, you learn. Other
changes are underway. Turning off the UI completely means readers who
have gotten used to it or who have always enjoyed it will have to
re-learn the old UI, then re-learn the new UI when some (undetermined)
set of conditions are met. That's jarring, confusing, and avoidable.
This is why on all major sites, you see a gradual ramp-up of a new
feature, and continued improvement once it's widely used. Often
there's an opt-in and then an opt-out to ease users into the change.
But once a change is launched, it very rarely gets rolled back unless
it's just clearly not doing what it's supposed to. Yes, we can all
agree that we need to continually raise the bar for how we build
software (without getting into analysis paralysis) -- but that doesn't
mean that reverting (here or in other cases) once there's an ad hoc
vote (or two, or three) is the right thing to do.
No other significantly sized organization follows the development
methodology you're proposing WMF should follow. Certainly, WMF is an
unusual organization, and we have every desire to take concerns
seriously, engage with people, scrutinize data honestly, and work
iteratively to make things better for everyone. What we can't and
won't accept is the idea that admin-reverts of features are an OK way
to try to enforce the outcome of an ad hoc poll or vote.
We can - and should, and do - talk to figure things out. We can - and
should, and do - work out compromises. (And we did indeed agree to
implement a compromise solution for Commons.) But the idea that WMF
always must slavishly execute the result of a poll or vote is neither
rational nor sustainable, nor has it ever been practice --- much less
controversially so in situations where WMF's decisions cannot be
overriden by admins employing JavaScript hacks.
If we're being honest, at the end of the day, a lot of this is about
establishing clear governing principles for the MediaWiki: namespace.
The fact that WMF doesn't implement every vote and indeed has in the
past even been somewhat capricious at times when it did not
(especially when such decisions were made just by a single dev
applying their own best judgment) is not in question. From a
communications perspective, we handled WP:ACTRIAL much more poorly
than we did this (we responded way too late), for example. But you
can't implement WP:ACTRIAL in JavaScript.
But there is no governing principle - documented clearly - that says
you can't disable a feature using the MW: namespace. WMF is saying it
now, and people perceive that (understandably) as a power grab. Fair
enough - it is the explicit extension of existing authority into a
novel domain. Such a change is always contentious and controversial,
but I don't think it was avoidable. If we are to work together
effectively, we need to define areas of competency and responsibility
clearly.
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation