While I'm not necessarily disagreeing with you, Todd, there were 14,681
users on English Wikipedia alone who had enabled MediaViewer using the Beta
Features preference before it became the default. That's a huge number of
people who were all using it every time they clicked on an image in the
weeks and months beforehand, and every one of them had to make a conscious
decision to turn it on. The 64 users who want it disabled as default pale
in comparison to the number of people who were actively using it
beforehand.
I've asked for some better statistical information because I don't think
the Limn graphs that have been referred to in the discussion of the RFC are
really accurate; it's my understanding that about 1600 registered accounts
have opted out of MV in total (this should be a linear graph of the
cumulative total, not a "daily number of people who opted out" graph which
is what we seem to see now). As well, somewhere in the neighbourhood of
500 "logged out" users a day are disabling it - this needs to be a daily
number, not a cumulative one, because logged-out disabling is linked to the
individual browser session; those who aren't logged in don't have the
chance to set preferences. There are between 4 and 5 *million* clicks on
image thumbnails every day on enwiki, with only around 500 of those viewing
the images disabling the MediaViewer (excluding logged-in users who have
turned it off in their preferences).
I suspect that at the end of the day, MediaViewer is going to be more like
the switch to Vector skin: there will be plenty of people who choose to
disable for reasons that work for them, but the overwhelming majority of
users will be entirely fine with the default. It's having nowhere near
the impact that VisualEditor had when first enabled as default; in the
first 48 hours there were hundreds of "how do you turn this off" queries
and complaints about functionality, not to mention pretty much automatic
reverting of edits done by IPs because there were so many VE-related
problems associated with them. We're not at that level at all here. I
agree with John Vandenberg's comments that a clear roadmap and prioritized
list of next steps is probably required for MediaViewer.
Risker/Anne
On 11 July 2014 00:56, Todd Allen <toddmallen(a)gmail.com> wrote:
If you don't want to do small opt-in trials,
release software in a fully
production-ready and usable state. What's getting released here is barely
ready for beta. It's buggy, it's full of unexpected UX issues, it's not
ready to go live on one of the top 10 websites in the world. It's got to be
in really good shape to get there.
Until software is actually ready for widescale use, small and very limited
beta tests are exactly the way to go, followed by maybe slightly larger UAT
pools. Yeah, that takes longer and requires actual work to find willing
testers. Quit taking shortcuts through your volunteers.
On Thu, Jul 10, 2014 at 10:40 PM, Sue Gardner <sgardner(a)wikimedia.org>
wrote:
Hey guys,
I use MediaViewer, I like it, and I am happy to trust the WMF product
team
to build stuff. I didn't know about the RFC,
but even if I had I would've
been unlikely to have participated, because I don't think small opt-in
discussions are the best way to do product development -- certainly not
at
the scale of Wikipedia.
I think we should aim on this list to be modest rather than overreaching
in
terms of what we claim to know, and who we imply
we're representing. It's
probably best to be clear --both in the mails we write and in our own
heads
privately-- that what's happening here is a
handful of people talking on
a
mailing list. We can represent our own opinions,
and like David Gerard we
can talk anecdotally about what our friends tell us. But I don't like it
when people here seem to claim to speak on behalf of editors, or users,
or
readers, or the community. It strikes me as
hubristic.
Thanks,
Sue
On 10 Jul 2014 16:13, "MZMcBride" <z(a)mzmcbride.com> wrote:
> Erik Moeller wrote:
> >In this case, we will keep the feature enabled by default (it's easy
> >to turn off, both for readers and editors), but we'll continue to
> >improve it based on community feedback (as has already happened in the
> >last few weeks).
>
> Thanks for the reply. :-)
>
> If your feature development model seemingly requires forcing features
on
users,
it's probably safe to say that it's broken. If you're building
cool
new features, they will ideally be
uncontroversial and users will
actively
> want to enable them and eventually have them enabled by default. Many
new
features
(e.g., the improved search backend) are deployed fairly
regularly
without fanfare or objection. But I see a common
thread among
unsuccessful
> deployments of features such as ArticleFeedbackv5, VisualEditor, and
> MediaViewer. Some of it is the people involved, of course, but the
larger
> pattern is a fault in the process, I think.
I wonder how we address
this.
MZMcBride
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>