On Wed, Aug 13, 2014 at 10:12 PM, Pete Forsyth peteforsyth@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