This discussion has closed on English Wikipedia: https://en.wikipedia.org/wiki/Wikipedia:Media_Viewer/June_2014_RfC
Will WMF deactivate MediaViewer on English Wikipedia per community consensus?
Also, as WMF probably knows, Commons is currently having a similar discussion: https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/Media_Viewer...
Thanks,
Pine
Has a bug request been filed?
On 10 July 2014 15:03, Pine W wiki.pine@gmail.com wrote:
This discussion has closed on English Wikipedia: https://en.wikipedia.org/wiki/Wikipedia:Media_Viewer/June_2014_RfC
Will WMF deactivate MediaViewer on English Wikipedia per community consensus?
Also, as WMF probably knows, Commons is currently having a similar discussion:
https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/Media_Viewer...
Thanks,
Pine _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Perhaps it's time to stop calling self-selected surveys of a tiny subset of our user base "community consensus".
The vast majority of our user base never logs in, never edits, and never even hears about these RfC pages. Those are the people we're making an encyclopedia for.
-- brion
On Wed, Jul 9, 2014 at 10:03 PM, Pine W wiki.pine@gmail.com wrote:
This discussion has closed on English Wikipedia: https://en.wikipedia.org/wiki/Wikipedia:Media_Viewer/June_2014_RfC
Will WMF deactivate MediaViewer on English Wikipedia per community consensus?
Also, as WMF probably knows, Commons is currently having a similar discussion:
https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/Media_Viewer...
Thanks,
Pine _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 10/07/2014, Brion Vibber bvibber@wikimedia.org wrote:
Perhaps it's time to stop calling self-selected surveys of a tiny subset of our user base "community consensus".
The vast majority of our user base never logs in, never edits, and never even hears about these RfC pages. Those are the people we're making an encyclopedia for.
Whole heartedly agree that this is a known and recognized limitation of the RfC process, apart from where we are talking about Wikimedia Commons, not the English Wikipedia. Of course it does not invalidate the RfC as a survey of users that do log in, edit and hear about RfC pages.
Was there a report from a survey that supported having a MediaViewer specified as rolled-out and better represents the majority "user base" rather than the volunteer community of contributors?
Fae
On 10/07/14 15:53, Brion Vibber wrote:
Perhaps it's time to stop calling self-selected surveys of a tiny subset of our user base "community consensus".
The vast majority of our user base never logs in, never edits, and never even hears about these RfC pages. Those are the people we're making an encyclopedia for.
-- brion
And those who do log in, edit, and comment on RfCs generally do so with the understanding, on some level, that everything they do, that the entire encyclopedia, is for the readers, because without an audience there would be nothing. They know their audience, they interact directly with this audience on the talkpages and in email, and indeed they often use the site exactly as this audience would, simply taking things a step further to edit as well.
So when they speak for the users who never log in, never edit, and never comment, do not discount them. No more than you discount yourself when you try to speak for the users who never log in, never edit, and never comment.
-I
On Jul 10, 2014 10:36 AM, "Isarra Yos" zhorishna@gmail.com wrote:
On 10/07/14 15:53, Brion Vibber wrote:
Perhaps it's time to stop calling self-selected surveys of a tiny subset
of
our user base "community consensus".
The vast majority of our user base never logs in, never edits, and never even hears about these RfC pages. Those are the people we're making an encyclopedia for.
-- brion
And those who do log in, edit, and comment on RfCs generally do so with
the understanding, on some level, that everything they do, that the entire encyclopedia, is for the readers, because without an audience there would be nothing. They know their audience, they interact directly with this audience on the talkpages and in email, and indeed they often use the site exactly as this audience would, simply taking things a step further to edit as well.
So when they speak for the users who never log in, never edit, and never
comment, do not discount them. No more than you discount yourself when you try to speak for the users who never log in, never edit, and never comment.
-I
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Yes. Exactly this.
I am beyond tired of hearing that those who have volunteered hundreds or thousands of hours per person toward building the greatest educational work in history do not have at heart the interests of those who would use it. If I didn't care, there are plenty of other ways I could spend my free time.
We should value those volunteers, and quit belittling their concerns. They made this thing and they keep it running day to day. They deal with readers who get upset or confused about something. They do it for no pay and often very little thanks, for no other reason than that they care deeply about the project and its goals.
To say we don't care for the end users of that work is nonsensical and insulting. We differ with you on how to serve those users and our volunteers, who also greatly matter. Stop handwaving that away.
Todd
Well thank you Brion, at least that may explains why things are imposed to the editors community and that also explains the high rejection rate from the editors community of the new big features such as VE. For once take time, think about editors workflow.
For exemple on french wikipedia we used to have a direct link to Wikimedia Commons (we technically removed the description page proxy), now we have totally lost this feature. So yes you may think it's not important, but as an administrator on Wikimedia Commons it screws my workflow when I see an obvious copyvio on the French Wikipedia.
So yes you make software for your users, but I think you're underestimating part of your users that you should not.
2014-07-10 18:36 GMT+02:00 Isarra Yos zhorishna@gmail.com:
On 10/07/14 15:53, Brion Vibber wrote:
Perhaps it's time to stop calling self-selected surveys of a tiny subset of our user base "community consensus".
The vast majority of our user base never logs in, never edits, and never even hears about these RfC pages. Those are the people we're making an encyclopedia for.
-- brion
And those who do log in, edit, and comment on RfCs generally do so with the understanding, on some level, that everything they do, that the entire encyclopedia, is for the readers, because without an audience there would be nothing. They know their audience, they interact directly with this audience on the talkpages and in email, and indeed they often use the site exactly as this audience would, simply taking things a step further to edit as well.
So when they speak for the users who never log in, never edit, and never comment, do not discount them. No more than you discount yourself when you try to speak for the users who never log in, never edit, and never comment.
-I
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
This is exactly why there is an opt-out for the feature.
We don't expect everyone to like everything we make. That's a reality. So take 10 seconds to go to your preferences and disable it, and you'll never see it again.
Dan
On Thursday, 10 July 2014, Pierre-Selim pierre-selim@huard.info wrote:
Well thank you Brion, at least that may explains why things are imposed to the editors community and that also explains the high rejection rate from the editors community of the new big features such as VE. For once take time, think about editors workflow.
For exemple on french wikipedia we used to have a direct link to Wikimedia Commons (we technically removed the description page proxy), now we have totally lost this feature. So yes you may think it's not important, but as an administrator on Wikimedia Commons it screws my workflow when I see an obvious copyvio on the French Wikipedia.
So yes you make software for your users, but I think you're underestimating part of your users that you should not.
2014-07-10 18:36 GMT+02:00 Isarra Yos <zhorishna@gmail.com javascript:;
:
On 10/07/14 15:53, Brion Vibber wrote:
Perhaps it's time to stop calling self-selected surveys of a tiny subset of our user base "community consensus".
The vast majority of our user base never logs in, never edits, and never even hears about these RfC pages. Those are the people we're making an encyclopedia for.
-- brion
And those who do log in, edit, and comment on RfCs generally do so with the understanding, on some level, that everything they do, that the
entire
encyclopedia, is for the readers, because without an audience there would be nothing. They know their audience, they interact directly with this audience on the talkpages and in email, and indeed they often use the
site
exactly as this audience would, simply taking things a step further to
edit
as well.
So when they speak for the users who never log in, never edit, and never comment, do not discount them. No more than you discount yourself when
you
try to speak for the users who never log in, never edit, and never
comment.
-I
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org javascript:; Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org javascript:;
?subject=unsubscribe>
-- Pierre-Selim _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org javascript:; ?subject=unsubscribe>
Keep in mind also that power users like you have access to power tools: preferences, user scripts, gadgets, and API client applications exist EXACTLY so that you guys can completely customize the entire user experience for your specialized workflows.
-- brion
On Thu, Jul 10, 2014 at 9:52 AM, Pierre-Selim pierre-selim@huard.info wrote:
Well thank you Brion, at least that may explains why things are imposed to the editors community and that also explains the high rejection rate from the editors community of the new big features such as VE. For once take time, think about editors workflow.
For exemple on french wikipedia we used to have a direct link to Wikimedia Commons (we technically removed the description page proxy), now we have totally lost this feature. So yes you may think it's not important, but as an administrator on Wikimedia Commons it screws my workflow when I see an obvious copyvio on the French Wikipedia.
So yes you make software for your users, but I think you're underestimating part of your users that you should not.
2014-07-10 18:36 GMT+02:00 Isarra Yos zhorishna@gmail.com:
On 10/07/14 15:53, Brion Vibber wrote:
Perhaps it's time to stop calling self-selected surveys of a tiny subset of our user base "community consensus".
The vast majority of our user base never logs in, never edits, and never even hears about these RfC pages. Those are the people we're making an encyclopedia for.
-- brion
And those who do log in, edit, and comment on RfCs generally do so with the understanding, on some level, that everything they do, that the
entire
encyclopedia, is for the readers, because without an audience there would be nothing. They know their audience, they interact directly with this audience on the talkpages and in email, and indeed they often use the
site
exactly as this audience would, simply taking things a step further to
edit
as well.
So when they speak for the users who never log in, never edit, and never comment, do not discount them. No more than you discount yourself when
you
try to speak for the users who never log in, never edit, and never
comment.
-I
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Pierre-Selim _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
In order to anticipate and meet the needs of readers, you have to have a theory of what those needs are, and what will meet them. The RfC process is one way of getting toward such a theory, and the kind of work done by the WMF's Multimedia Team over the last year or so is another.
The pros and cons of RFC-based consensus have been pretty well covered by others in this thread, and I won't go through them all again -- but I do want to strongly endorse the point Todd Allen made, that many regular volunteers DO care about the experience of readers, and many of us DO have important insights into how readers, new contributors, etc. experience the site, and what would work for them.
The Multimedia Team's approach, on the other hand, seems at this point to be all "con," no "pro." Many people in the discussions on ENWP, Commons, and MediaWiki have elaborated on the many problems in the methodology. English Wikipedian Nyttend's comment, while phrased a bit more harshly than I would choose, summarizes the points fairly well:
"Here at Wikipedia, we have a term for [aspects of the Multimedia Team's gathering of statistics]: votestacking https://en.wikipedia.org/wiki/Wikipedia:Votestacking, which is a form of inappropriate canvassing https://en.wikipedia.org/wiki/Wikipedia:CANVASS. Discussions affected by canvassing are not considered to result in consensus, and those engaged in votestacking are shown the door https://en.wikipedia.org/wiki/Wikipedia:BLOCK: we do not accept their ideas." -Nyttend https://en.wikipedia.org/w/index.php?title=Wikipedia:Media_Viewer/June_2014_...
So -- if we are to eschew the RfC process, what better process is available? How are we going to develop a clear shared understanding of the needs of readers, and the best methods to meet those needs?
-Pete [[User:Peteforsyth]]
On Thu, Jul 10, 2014 at 10:13 AM, Brion Vibber bvibber@wikimedia.org wrote:
Keep in mind also that power users like you have access to power tools: preferences, user scripts, gadgets, and API client applications exist EXACTLY so that you guys can completely customize the entire user experience for your specialized workflows.
-- brion
On Thu, Jul 10, 2014 at 9:52 AM, Pierre-Selim pierre-selim@huard.info wrote:
Well thank you Brion, at least that may explains why things are imposed
to
the editors community and that also explains the high rejection rate from the editors community of the new big features such as VE. For once take time, think about editors workflow.
For exemple on french wikipedia we used to have a direct link to
Wikimedia
Commons (we technically removed the description page proxy), now we have totally lost this feature. So yes you may think it's not important, but
as
an administrator on Wikimedia Commons it screws my workflow when I see an obvious copyvio on the French Wikipedia.
So yes you make software for your users, but I think you're
underestimating
part of your users that you should not.
2014-07-10 18:36 GMT+02:00 Isarra Yos zhorishna@gmail.com:
On 10/07/14 15:53, Brion Vibber wrote:
Perhaps it's time to stop calling self-selected surveys of a tiny
subset
of our user base "community consensus".
The vast majority of our user base never logs in, never edits, and
never
even hears about these RfC pages. Those are the people we're making an encyclopedia for.
-- brion
And those who do log in, edit, and comment on RfCs generally do so with the understanding, on some level, that everything they do, that the
entire
encyclopedia, is for the readers, because without an audience there
would
be nothing. They know their audience, they interact directly with this audience on the talkpages and in email, and indeed they often use the
site
exactly as this audience would, simply taking things a step further to
edit
as well.
So when they speak for the users who never log in, never edit, and
never
comment, do not discount them. No more than you discount yourself when
you
try to speak for the users who never log in, never edit, and never
comment.
-I
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Pierre-Selim _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hoi, Do appreciate that when you "show others the door", you stop conversation. Using such terminology in a confrontation like this can only backfire.
Truly, I love Wikidata to bits however its RfC process is as broken as most. People pontificate, do not listen and, the arguments are intentionally academic both in being often irrelevant and often full of "terminology" that escapes understanding. I have to use this process because there is no alternative... I HATE IT. Thanks, GerardM
On 10 July 2014 19:41, Pete Forsyth peteforsyth@gmail.com wrote:
In order to anticipate and meet the needs of readers, you have to have a theory of what those needs are, and what will meet them. The RfC process is one way of getting toward such a theory, and the kind of work done by the WMF's Multimedia Team over the last year or so is another.
The pros and cons of RFC-based consensus have been pretty well covered by others in this thread, and I won't go through them all again -- but I do want to strongly endorse the point Todd Allen made, that many regular volunteers DO care about the experience of readers, and many of us DO have important insights into how readers, new contributors, etc. experience the site, and what would work for them.
The Multimedia Team's approach, on the other hand, seems at this point to be all "con," no "pro." Many people in the discussions on ENWP, Commons, and MediaWiki have elaborated on the many problems in the methodology. English Wikipedian Nyttend's comment, while phrased a bit more harshly than I would choose, summarizes the points fairly well:
"Here at Wikipedia, we have a term for [aspects of the Multimedia Team's gathering of statistics]: votestacking https://en.wikipedia.org/wiki/Wikipedia:Votestacking, which is a form of inappropriate canvassing https://en.wikipedia.org/wiki/Wikipedia:CANVASS. Discussions affected by canvassing are not considered to result in consensus, and those engaged in votestacking are shown the door https://en.wikipedia.org/wiki/Wikipedia:BLOCK: we do not accept their ideas." -Nyttend
https://en.wikipedia.org/w/index.php?title=Wikipedia:Media_Viewer/June_2014_...
So -- if we are to eschew the RfC process, what better process is available? How are we going to develop a clear shared understanding of the needs of readers, and the best methods to meet those needs?
-Pete [[User:Peteforsyth]]
On Thu, Jul 10, 2014 at 10:13 AM, Brion Vibber bvibber@wikimedia.org wrote:
Keep in mind also that power users like you have access to power tools: preferences, user scripts, gadgets, and API client applications exist EXACTLY so that you guys can completely customize the entire user experience for your specialized workflows.
-- brion
On Thu, Jul 10, 2014 at 9:52 AM, Pierre-Selim pierre-selim@huard.info wrote:
Well thank you Brion, at least that may explains why things are imposed
to
the editors community and that also explains the high rejection rate
from
the editors community of the new big features such as VE. For once take time, think about editors workflow.
For exemple on french wikipedia we used to have a direct link to
Wikimedia
Commons (we technically removed the description page proxy), now we
have
totally lost this feature. So yes you may think it's not important, but
as
an administrator on Wikimedia Commons it screws my workflow when I see
an
obvious copyvio on the French Wikipedia.
So yes you make software for your users, but I think you're
underestimating
part of your users that you should not.
2014-07-10 18:36 GMT+02:00 Isarra Yos zhorishna@gmail.com:
On 10/07/14 15:53, Brion Vibber wrote:
Perhaps it's time to stop calling self-selected surveys of a tiny
subset
of our user base "community consensus".
The vast majority of our user base never logs in, never edits, and
never
even hears about these RfC pages. Those are the people we're making
an
encyclopedia for.
-- brion
And those who do log in, edit, and comment on RfCs generally do so
with
the understanding, on some level, that everything they do, that the
entire
encyclopedia, is for the readers, because without an audience there
would
be nothing. They know their audience, they interact directly with
this
audience on the talkpages and in email, and indeed they often use the
site
exactly as this audience would, simply taking things a step further
to
edit
as well.
So when they speak for the users who never log in, never edit, and
never
comment, do not discount them. No more than you discount yourself
when
you
try to speak for the users who never log in, never edit, and never
comment.
-I
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Pierre-Selim _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Thu, Jul 10, 2014 at 9:52 AM, Pierre-Selim pierre-selim@huard.info wrote:
For exemple on french wikipedia we used to have a direct link to Wikimedia Commons (we technically removed the description page proxy), now we have totally lost this feature. So yes you may think it's not important, but as an administrator on Wikimedia Commons it screws my workflow when I see an obvious copyvio on the French Wikipedia.
Also, try ctrl+click (cmd+click on OS X) or right-click then "open link in new tab". You'll find it opens the Commons description page just as always. (I'd generally expect power users to be using multiple browser tabs already.)
-- brion
On Thu, Jul 10, 2014 at 9:52 AM, Pierre-Selim pierre-selim@huard.info wrote:
For exemple on french wikipedia we used to have a direct link to Wikimedia Commons (we technically removed the description page proxy), now we have totally lost this feature.
Actually, Media Viewer consistently displays a prominent link directly to the file page on Wikimedia Commons for files that are from Commons, and as Brion pointed out, if you skip media viewer (e.g. by ctrl+clicking) the French Wikipedia hack will still kick in as well.
Erik
On 10 July 2014 17:36, Isarra Yos zhorishna@gmail.com wrote:
And those who do log in, edit, and comment on RfCs generally do so with the understanding, on some level, that everything they do, that the entire encyclopedia, is for the readers, because without an audience there would be nothing. They know their audience, they interact directly with this audience on the talkpages and in email, and indeed they often use the site exactly as this audience would, simply taking things a step further to edit as well. So when they speak for the users who never log in, never edit, and never comment, do not discount them. No more than you discount yourself when you try to speak for the users who never log in, never edit, and never comment.
OTOH, typical mind fallacy is rampant everywhere and the results of an actual decent user survey would probably surprise everyone.
- d.
On 10/07/14 18:01, David Gerard wrote:
On 10 July 2014 17:36, Isarra Yos zhorishna@gmail.com wrote:
And those who do log in, edit, and comment on RfCs generally do so with the understanding, on some level, that everything they do, that the entire encyclopedia, is for the readers, because without an audience there would be nothing. They know their audience, they interact directly with this audience on the talkpages and in email, and indeed they often use the site exactly as this audience would, simply taking things a step further to edit as well. So when they speak for the users who never log in, never edit, and never comment, do not discount them. No more than you discount yourself when you try to speak for the users who never log in, never edit, and never comment.
OTOH, typical mind fallacy is rampant everywhere and the results of an actual decent user survey would probably surprise everyone.
- d.
That was kind of my point - as much as editors do tend deal more directly with the readers, we've basically got two (rather biased) sides who both think they know what readers want and thus try to speak for them. This may not even be an issue, by itself, but unfortunately it's becoming a rather common tactic among some WMF staff to simply dismiss community feedback saying things like that the editors simply don't speak for the readers. But if this is really the case, what gives the WMF the right to speak for the readers either?
Personally I'm getting rather tired of this.
-I
On 10 July 2014 19:23, Isarra Yos zhorishna@gmail.com wrote:
On 10/07/14 18:01, David Gerard wrote:
OTOH, typical mind fallacy is rampant everywhere and the results of an actual decent user survey would probably surprise everyone.
That was kind of my point - as much as editors do tend deal more directly with the readers, we've basically got two (rather biased) sides who both think they know what readers want and thus try to speak for them. This may not even be an issue, by itself, but unfortunately it's becoming a rather common tactic among some WMF staff to simply dismiss community feedback saying things like that the editors simply don't speak for the readers. But if this is really the case, what gives the WMF the right to speak for the readers either? Personally I'm getting rather tired of this.
I concur that there's a bit much reasoning from no data, and we could do with some.
Anecdotally, (a) I don't mind the new viewer (b) I know a lot of people who've said they love it (c) I know a few who've said they hate it. So yeah, real user surveys needed!
- d.
On 07/10/2014 02:41 PM, David Gerard wrote:
Anecdotally, (a) I don't mind the new viewer (b) I know a lot of people who've said they love it (c) I know a few who've said they hate it.
That also matches my anecdotal impression, with perhaps the added apparent correlation between (c) and "has been around a long time".
I keep saying - half in jest - that our editor community shows all the symptoms of Stockholm syndrome vis-a-vis Mediawiki. They have suffered so long and so much at its torturous hands that they've now feeling sympathy and affection under its choke.
So yeah, real user surveys needed!
Indeed. That remains a *hard* problem to solve, because any sort of online user survey is necessarily suffering from, at least, self-selection bias. Any brilliant ideas from our metrics people?
-- Marc
On Jul 10, 2014 12:42 PM, "David Gerard" dgerard@gmail.com wrote:
On 10 July 2014 19:23, Isarra Yos zhorishna@gmail.com wrote:
On 10/07/14 18:01, David Gerard wrote:
OTOH, typical mind fallacy is rampant everywhere and the results of an actual decent user survey would probably surprise everyone.
That was kind of my point - as much as editors do tend deal more
directly
with the readers, we've basically got two (rather biased) sides who both think they know what readers want and thus try to speak for them. This
may
not even be an issue, by itself, but unfortunately it's becoming a
rather
common tactic among some WMF staff to simply dismiss community feedback saying things like that the editors simply don't speak for the readers.
But
if this is really the case, what gives the WMF the right to speak for
the
readers either? Personally I'm getting rather tired of this.
I concur that there's a bit much reasoning from no data, and we could do with some.
Anecdotally, (a) I don't mind the new viewer (b) I know a lot of people who've said they love it (c) I know a few who've said they hate it. So yeah, real user surveys needed!
- d.
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
I agree that's sorely needed. We would need a few things to ensure it would work:
--A neutral question. "Do you prefer A or B for...?". Half the takers get the new stuff as A, half get the old. No front loading of the results.
--No self selection of participants. That's not easy but is necessary. People who take the time to self select may be more likely to perceive a problem.
--Getting real feedback and actually analyzing it. Why did people like A or B? Is it for reasons that make sense to default it for logged in editors as well as casual readers? A lot of friction could be reduced if editors' workflows were not unexpectedly disrupted.
--Publishing full (anonymized) results (not a summary only) and methodologies prominently.
If we can do that, I'm all for the survey. Otherwise, it's useless.
On Thu, Jul 10, 2014 at 11:41 AM, David Gerard dgerard@gmail.com wrote:
I concur that there's a bit much reasoning from no data, and we could do with some.
Anecdotally, (a) I don't mind the new viewer (b) I know a lot of people who've said they love it (c) I know a few who've said they hate it. So yeah, real user surveys needed!
We do have user surveys for MediaViewer and did advertise them quite prominently (see design notes https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/261 and analysis of results https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Survey; they ran for about a month on enwiki). They turned out to be not so useful; there was usually a large number of responses right after the launch, which were predominantly negative, and a smaller number of predominantly positive responses after that. That can be interpreted in very different ways - could be change aversion, with most users warming up to the new interface after a week or two; it could the effect of bugfixes and added features (after every rollout we quickly fixed the most reported problems); it could even be possible that most users don't like the tool and those who do wait longer before responding for some reason. Also, editors are still way overrepresented (in the enwiki survey results respondents self-identifying as noneditors / casual editors / active editors are somewhere around 40% / 40% / 20%, while the actual ratio is more like 99% / 0.99% / 0.1%), with the more underrepresented groups having a significantly more positive opinion.
2014-07-10 17:53 GMT+02:00 Brion Vibber bvibber@wikimedia.org:
Perhaps it's time to stop calling self-selected surveys of a tiny subset of our user base "community consensus".
The vast majority of our user base never logs in, never edits, and never even hears about these RfC pages. Those are the people we're making an encyclopedia for.
I don't intend to bother you when you are making an encyclopædia, Brion, but if this is the stance the Wikimedia Foundation takes it's time for me to leave the project. I expect the Wikimedia Foundation to respect a community consensus. If you think you have another community of crowdsourcing workers then go ahead. I won't tolerate this.
Regards, Jürgen.
On 10 July 2014 22:21, Juergen Fenn schneeschmelze@googlemail.com wrote:
I don't intend to bother you when you are making an encyclopædia, Brion, but if this is the stance the Wikimedia Foundation takes it's time for me to leave the project. I expect the Wikimedia Foundation to respect a community consensus. If you think you have another community of crowdsourcing workers then go ahead. I won't tolerate this.
Regards, Jürgen.
The reallit is that an RFC edited by 131 people total is rather borderline in terms of community consensus with regards to new features and significantly lower than [[Wikipedia:VisualEditor/Default State RFC]]. There is also the factor that any new design results in a certain degree of backlash. Sure the design has problems (I've just noticed that links to images will break if the page they are on moves) but so did monobook and vector when they were first released some of the issues have been fixed and most people have got used to using skins other than classic and don't complain that much.
There is also the political side that English wikipedia has resisted several fairly major changes. Pending changes, Visual editor and article rating. The opposition to flow is already starting to dig in. While I'd hope the Visual editor mess isn't held against us there is the issue that a pattern is starting to emerge. The WMF probably can't afford to lose another public facing project to English Wikipedia intransigence.
On Wed, Jul 9, 2014 at 10:03 PM, Pine W wiki.pine@gmail.com wrote:
Will WMF deactivate MediaViewer on English Wikipedia
No. Detailed explanation: https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Media_Viewer/June_...
Erik
Erik Moeller wrote:
On Wed, Jul 9, 2014 at 10:03 PM, Pine W wiki.pine@gmail.com wrote:
Will WMF deactivate MediaViewer on English Wikipedia
No.
Erik has stepped in and employed an office action to re-enable Media Viewer on the English Wikipedia.
Erik, can you please explain what emergency necessitated immediate (and likely unprecedented) action here?
MZMcBride
I don't see any office action at all here. All I see is an administrator acting per what a WMF staffer has said. The code added as explained on the page; disables the feature fully and does not allow any opt ins.
John Lewis
On Thursday, 10 July 2014, MZMcBride z@mzmcbride.com wrote:
Erik Moeller wrote:
On Wed, Jul 9, 2014 at 10:03 PM, Pine W <wiki.pine@gmail.com
javascript:;> wrote:
Will WMF deactivate MediaViewer on English Wikipedia
No.
Erik has stepped in and employed an office action to re-enable Media Viewer on the English Wikipedia.
Erik, can you please explain what emergency necessitated immediate (and likely unprecedented) action here?
MZMcBride
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org javascript:; ?subject=unsubscribe>
This was clarified as an office action under threat of desysop here:
https://en.wikipedia.org/w/index.php?title=User_talk:Peteforsyth&diff=61...
On Thu, Jul 10, 2014 at 4:31 PM, John Lewis johnflewis93@gmail.com wrote:
I don't see any office action at all here. All I see is an administrator acting per what a WMF staffer has said. The code added as explained on the page; disables the feature fully and does not allow any opt ins.
John Lewis
On Thursday, 10 July 2014, MZMcBride z@mzmcbride.com wrote:
Erik Moeller wrote:
On Wed, Jul 9, 2014 at 10:03 PM, Pine W <wiki.pine@gmail.com
javascript:;> wrote:
Will WMF deactivate MediaViewer on English Wikipedia
No.
Erik has stepped in and employed an office action to re-enable Media Viewer on the English Wikipedia.
Erik, can you please explain what emergency necessitated immediate (and likely unprecedented) action here?
MZMcBride
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org javascript:; ?subject=unsubscribe>
-- John Lewis _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 10/07/2014, Todd Allen toddmallen@gmail.com wrote:
This was clarified as an office action under threat of desysop here:
https://en.wikipedia.org/w/index.php?title=User_talk:Peteforsyth&diff=61...
Wow. This has fallen apart quickly.
However the WMF's "no" position has been made extremely clear to all of us unpaid volunteers. That's a good thing I guess, as there is no point in us volunteers wasting more of our time having an opinion, or expressing our opinion.
Fae
On 10 July 2014 23:46, Fæ faewik@gmail.com wrote:
However the WMF's "no" position has been made extremely clear to all of us unpaid volunteers.
You're not on en:wp, so are not part of the "us" in question.
- d.
On 10/07/2014, David Gerard dgerard@gmail.com wrote:
On 10 July 2014 23:46, Fæ faewik@gmail.com wrote:
However the WMF's "no" position has been made extremely clear to all of us unpaid volunteers.
You're not on en:wp, so are not part of the "us" in question.
- d.
Dear David,
Get off my back please.
I suggest you get your facts straight before making false allegations.
Fae
John Lewis wrote:
I don't see any office action at all here. All I see is an administrator acting per what a WMF staffer has said.
Sorry, I have no idea what you're talking about here. I think you may not realize that Erik and Eloquence are the same person?
For reference:
--- Per Fabrice's explanation, please refrain from further edits to the site JavaScript, or I will have to temporarily revoke your admin privileges. This is a WMF action.--Eloquence* 20:07, 10 July 2014 (UTC) ---
Source: https://en.wikipedia.org/w/index.php?diff=616427707&diffonly=1
MZMcBride
I am aware they are the same.
John Lewis
On Thursday, 10 July 2014, MZMcBride z@mzmcbride.com wrote:
John Lewis wrote:
I don't see any office action at all here. All I see is an administrator acting per what a WMF staffer has said.
Sorry, I have no idea what you're talking about here. I think you may not realize that Erik and Eloquence are the same person?
For reference:
Per Fabrice's explanation, please refrain from further edits to the site JavaScript, or I will have to temporarily revoke your admin privileges. This is a WMF action.--Eloquence* 20:07, 10 July 2014 (UTC)
Source: https://en.wikipedia.org/w/index.php?diff=616427707&diffonly=1
MZMcBride
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org javascript:; ?subject=unsubscribe>
On Thu, Jul 10, 2014 at 3:25 PM, MZMcBride z@mzmcbride.com wrote:
Erik, can you please explain what emergency necessitated immediate (and likely unprecedented) action here?
Please see Fabrice Florin's explanation, as linked in my original response: https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Media_Viewer/June_...
It's longstanding WMF policy and practice to apply judgment to community RFCs and requests regarding software and configuration changes on a case-by-case basis, depending on the nature of the requested change, the level of participation, the impact on readers/editors, etc.
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).
Erik
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
On Thu, Jul 10, 2014 at 4:12 PM, MZMcBride z@mzmcbride.com wrote:
Many new features (e.g., the improved search backend) are deployed fairly regularly without fanfare or objection.
Indeed, change-aversion tends to correlate pretty strongly with impact on existing workflows [1] and noticeable changes to user experience and behavior. This is pretty clearly laid out by a Google UX researcher here: https://www.gv.com/lib/change-aversion-why-users-hate-what-you-launched-and-...
Media Viewer is actually a perfect example of this -- most of the functionality people expect (get to the File: page, see a summary, see categories, get the full-size version, get multiple resolutions, see attribution information, etc.) is there; it just takes a little while to get used to it being in a different place, and a negative first reaction is perfectly understandable.
It's normal and expected that the first reaction to noticeable user experience changes will often be negative. This is why we shouldn't base decision-making solely on early-stage RFCs and first reactions. Just look at the responses to major redesigns by Flickr, NYT, and others -- almost universally negative, irrespective of what the data actually says about user and readership growth or decline as a consequence of these changes.
The difference between us and more corporate approaches to product and user experience design is that we work very closely with the community in the product development cycle, and Media Viewer is again a good example of a multi-month development process with lots of community participation and consultation and a dedicated community liaison (Keegan) supporting the process throughout.
But we'll still face the normal patterns of first reactions described in the article above. For this reason, we need to apply judgment on a case-by-case basis when interpreting these types of responses.
Erik
On 11 July 2014 00:40, Erik Moeller erik@wikimedia.org wrote:
On Thu, Jul 10, 2014 at 4:12 PM, MZMcBride z@mzmcbride.com wrote:
Many new features (e.g., the improved search backend) are deployed
fairly regularly
without fanfare or objection.
Indeed, change-aversion tends to correlate pretty strongly with impact on existing workflows [1]
Problem. Existing workflow broken is my being aware of what new users are seeing when they want to know how to do something.
On Fri, Jul 11, 2014 at 9:40 AM, Erik Moeller erik@wikimedia.org wrote:
On Thu, Jul 10, 2014 at 4:12 PM, MZMcBride z@mzmcbride.com wrote:
Many new features (e.g., the improved search backend) are deployed fairly regularly without fanfare or objection.
Indeed, change-aversion tends to correlate pretty strongly with impact on existing workflows [1] and noticeable changes to user experience and behavior. This is pretty clearly laid out by a Google UX researcher here: https://www.gv.com/lib/change-aversion-why-users-hate-what-you-launched-and-...
Media Viewer is actually a perfect example of this -- most of the functionality people expect (get to the File: page, see a summary, see categories, get the full-size version, get multiple resolutions, see attribution information, etc.) is there; ...
Or .. sometimes the licensing and attribution information isnt correct, sometimes you get resolutions which are silly (especially svgs at launch, but also slideshows on a file page include a very large license logo), it takes extra clicks to get to the full-size version, only some of the categories are shown including otherwise 'hidden' categories, and sometimes the summary isnt shown.
These are a combination of design flaws and blatant bugs which were known before launch. Has the WMF done a quick estimate on the amount of time before these basic functions of media viewer are working correctly? Has the WMF allocated developers to ensure these basic functions of media viewer work correct? I would be much happier to support it remaining opt out if WMF could give an estimate on when this will be completed, rather than reading WMF directors say 'most of the functionality people expect ... is there'. It's not, except in the 'proof of concept' mode. Its a long way from being ready to leave beta, much like Visual Editor was.
-- John Vandenberg
On Thu, Jul 10, 2014 at 11:02 PM, John Mark Vandenberg jayvdb@gmail.com wrote:
Or .. sometimes the licensing and attribution information isnt correct
In the common case, Media Viewer provides more prominent and appropriate attribution and license information than the File: page. The author name, license, license URL, and source URL are all immediately accessible below the image, whereas on the File: page there are sometimes screenfuls of metadata between the image and this crucial information.
This is actually a pretty remarkable accomplishment given that this information comes from a huge number of different templates that vary across wikis. Media Viewer makes use of standardized CSS classes to extract metadata, and the team has actively worked with the community to broaden their use:
http://lists.wikimedia.org/pipermail/multimedia/2014-March/000135.html
Ultimately we'll want to use proper structured data for this, but these changes lay the groundwork, and there's already an API (used by Media Viewer but open to anyone) that exposes this information.
Where no license is detected, Media Viewer still falls back to a "View license" link. The more problematic cases are where actual errors occur and important information is not extracted, and there will certainly inevitably be some cases where this happens, but this can only be worked on over time. The expectation that an unbounded problem like this is completely solved prior to deployment of a feature is unreasonable -- it's similar to TemplateData, in that the positive feedback loop into Media Viewer should actually help encourage more and consistent use of machine-readable data.
sometimes you get resolutions which are silly (especially svgs at launch, but also slideshows on a file page include a very large license logo)
Can you give a specific, current example?
it takes extra clicks to get to the full-size version,
It takes exactly one click using the "View original file" button.
Thanks, Erik
Just a note that I am drafting a request to the Board about governance of WMF product launches. Similar problems have happened enough times that I think the Board needs to step in with a more active role. I am also taking a look at the policies around office actions as they relate to product launches, and will likely request that the Board examine that policy as well.
Pine
On Thu, Jul 10, 2014 at 11:53 PM, Erik Moeller erik@wikimedia.org wrote:
On Thu, Jul 10, 2014 at 11:02 PM, John Mark Vandenberg jayvdb@gmail.com wrote:
Or .. sometimes the licensing and attribution information isnt correct
In the common case, Media Viewer provides more prominent and appropriate attribution and license information than the File: page. The author name, license, license URL, and source URL are all immediately accessible below the image, whereas on the File: page there are sometimes screenfuls of metadata between the image and this crucial information.
This is actually a pretty remarkable accomplishment given that this information comes from a huge number of different templates that vary across wikis. Media Viewer makes use of standardized CSS classes to extract metadata, and the team has actively worked with the community to broaden their use:
http://lists.wikimedia.org/pipermail/multimedia/2014-March/000135.html
Ultimately we'll want to use proper structured data for this, but these changes lay the groundwork, and there's already an API (used by Media Viewer but open to anyone) that exposes this information.
Where no license is detected, Media Viewer still falls back to a "View license" link. The more problematic cases are where actual errors occur and important information is not extracted, and there will certainly inevitably be some cases where this happens, but this can only be worked on over time. The expectation that an unbounded problem like this is completely solved prior to deployment of a feature is unreasonable -- it's similar to TemplateData, in that the positive feedback loop into Media Viewer should actually help encourage more and consistent use of machine-readable data.
sometimes you get resolutions which are silly (especially svgs at launch, but also slideshows on a file page include a very large license logo)
Can you give a specific, current example?
it takes extra clicks to get to the full-size version,
It takes exactly one click using the "View original file" button.
Thanks, Erik
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
I agree with Erik here. Media Viewer may have some bugs that need to be fixed. But there are plenty of issues in other places too (like license tags). They also need to improved. See this ongoing discussion. [1]
See my comment on RfC on Commons. [2]
Jee
Links:
1. https://commons.wikimedia.org/wiki/Commons:Village_pump/Copyright#Propose_to...
2. https://commons.wikimedia.org/w/index.php?title=Commons:Requests_for_comment...
On Fri, Jul 11, 2014 at 1:20 PM, Pine W wiki.pine@gmail.com wrote:
Just a note that I am drafting a request to the Board about governance of WMF product launches. Similar problems have happened enough times that I think the Board needs to step in with a more active role. I am also taking a look at the policies around office actions as they relate to product launches, and will likely request that the Board examine that policy as well.
Pine
On Thu, Jul 10, 2014 at 11:53 PM, Erik Moeller erik@wikimedia.org wrote:
On Thu, Jul 10, 2014 at 11:02 PM, John Mark Vandenberg <jayvdb@gmail.com
wrote:
Or .. sometimes the licensing and attribution information isnt correct
In the common case, Media Viewer provides more prominent and appropriate attribution and license information than the File: page. The author name, license, license URL, and source URL are all immediately accessible below the image, whereas on the File: page there are sometimes screenfuls of metadata between the image and this crucial information.
This is actually a pretty remarkable accomplishment given that this information comes from a huge number of different templates that vary across wikis. Media Viewer makes use of standardized CSS classes to extract metadata, and the team has actively worked with the community to broaden their use:
http://lists.wikimedia.org/pipermail/multimedia/2014-March/000135.html
Ultimately we'll want to use proper structured data for this, but these changes lay the groundwork, and there's already an API (used by Media Viewer but open to anyone) that exposes this information.
Where no license is detected, Media Viewer still falls back to a "View license" link. The more problematic cases are where actual errors occur and important information is not extracted, and there will certainly inevitably be some cases where this happens, but this can only be worked on over time. The expectation that an unbounded problem like this is completely solved prior to deployment of a feature is unreasonable -- it's similar to TemplateData, in that the positive feedback loop into Media Viewer should actually help encourage more and consistent use of machine-readable data.
sometimes you get resolutions which are silly (especially svgs at launch, but also slideshows on a file page include a very large license logo)
Can you give a specific, current example?
it takes extra clicks to get to the full-size version,
It takes exactly one click using the "View original file" button.
Thanks, Erik
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
'On Fri, Jul 11, 2014 at 4:53 PM, Erik Moeller erik@wikimedia.org wrote:
On Thu, Jul 10, 2014 at 11:02 PM, John Mark Vandenberg jayvdb@gmail.com wrote:
Or .. sometimes the licensing and attribution information isnt correct
In the common case, Media Viewer provides more prominent and appropriate attribution and license information than the File: page. The author name, license, license URL, and source URL are all immediately accessible below the image, whereas on the File: page there are sometimes screenfuls of metadata between the image and this crucial information.
Im not suggesting that the layout of MV isnt great, but that isnt the issue I raised, and you are unfortunately very wrong and dumbing the licensing and attribution information down is fraught with problems that need to be carefully worked through,
Let's walk through a real example, of a page with over half a milion page views in the last two days.
https://en.wikipedia.org/wiki/Indonesian_presidential_election,_2014 http://stats.grok.se/en/latest/Indonesian_presidential_election,_2014
The photo of Prabowo in MV has a caption of 'Prabowo wapres' instead of 'Prabowo Subianto' which is (now) the caption and alt text on the enwiki article, and the the Jokowi photo in MV has a caption of 'Gubernur DKI Jokowi' despite having an {{information}} block on Commons with an English & Indonesian descriptions, albeit without perfect syntax, but that is par for the course and MV design needs to cater for this type of scenario.
Scrolling down on the Prabowo image in MV shows '== Licensing: ==' .. whoops wasnt wikitext supposed to be hidden? This is another syntax problem with the wikitext, but our goal should be to show broken wikitext to as many eyes as possible so that one person takes the initiative to try to fix it. The licensing shows 'CC-BY-SA 3.0', but the image is 'correctly' tagged as CC & GFDL. The Commons Slideshow gadget manages to correctly detect that this image has metadata that says it is dual licensed. Try https://commons.wikimedia.org/wiki/Help:Slideshow on https://commons.wikimedia.org/wiki/Category:Prabowo_Subianto . Why does the opt-in slideshow gadget have a better understanding of media metadata than the WMF opt-out media viewer?
Scrolling down on the Jokowi image in MV shows Indonesian text instead of English text, it isnt identified as Indonesian language despite very good syntax in the wikitext, and the 'License details' block on my screen shows the first two lines of the licensing template, and the top third of the third line of text which makes it unreadable, and a 'View more' sort-of-button which appears at the bottom right also overlapping with the second line of license text, obscuring that also. I can expand the box to show the rest of the license details, but .. eww .. this is out of beta really??
From an ideology perspective, these image pages have many issues which
needed to be edited, and the MV doesnt promote editing. It shows dubious, incorrect, or syntactically invalid metadata as if it is un-editable, instead of suggesting that the metadata needs editing. It doesnt highlight that one of these images is claimed to be a CC photo , yet it is a professional shot, is uploaded by someone with a red username. Our astute image reusers should be looking for an OTRS permission tag, which is missing.
The slidebar has a sequence which repeats the images: Probowo -> Jokowi -> Prabowo -> Jokowi -> Prabowo -> Jowoki and then whooping huge Indonesia flag colors.
I could easily double or triple what I have written above about just that one page, focusing on finer details of the MV UI that are poor design or inadequate implementation, but .. sigh .. you have people paid to do your designs.
And, there are also sorts of quite important parts of the licensing process which are ignored by MV. e.g. a image which is OTRS pending, now doesnt include a big scary warning one click away. https://en.wikipedia.org/wiki/Nick_Driver#mediaviewer/File:Nick_Driver_in_20...
Erik, do you know what percentage of image pages are not correctly parsed and presented by MV wrt licensing and attribution?
This is actually a pretty remarkable accomplishment given that this information comes from a huge number of different templates that vary across wikis. Media Viewer makes use of standardized CSS classes to extract metadata, and the team has actively worked with the community to broaden their use:
http://lists.wikimedia.org/pipermail/multimedia/2014-March/000135.html
Ultimately we'll want to use proper structured data for this, but these changes lay the groundwork, and there's already an API (used by Media Viewer but open to anyone) that exposes this information.
Where no license is detected, Media Viewer still falls back to a "View license" link. The more problematic cases are where actual errors occur and important information is not extracted, and there will certainly inevitably be some cases where this happens, but this can only be worked on over time. The expectation that an unbounded problem like this is completely solved prior to deployment of a feature is unreasonable -- it's similar to TemplateData, in that the positive feedback loop into Media Viewer should actually help encourage more and consistent use of machine-readable data.
sometimes you get resolutions which are silly (especially svgs at launch, but also slideshows on a file page include a very large license logo)
Can you give a specific, current example?
See above for the 'flag' example, but go to commons, click random file, open in MV, and scroll though all . Seriously Erik, this happens on almost any random use of the MV - you dont need me to tell you this do you?
it takes extra clicks to get to the full-size version,
It takes exactly one click using the "View original file" button.
You mean to say that after the launch, and after much anguish of the community telling the WMF that the extra click was a major pain point, this button was added. It is great that bugs are being fixed, but don't be surprised if you have a hard job advertising the fact you've fixed major failings of the a product at launch, and it would be humble of the WMF to use clear messaging when talking about post launch bug fixes rather than 'It does what you want' type messaging.
On Fri, Jul 11, 2014 at 4:21 AM, John Mark Vandenberg jayvdb@gmail.com wrote:
https://en.wikipedia.org/wiki/Indonesian_presidential_election,_2014 http://stats.grok.se/en/latest/Indonesian_presidential_election,_2014
The photo of Prabowo in MV has a caption of 'Prabowo wapres'
This happens to be the file's name, which is also the first thing users see when they visit the File: page. Media Viewer uses filenames for the titles because there is no consistently short description/label available. It's been suggested to potentially move the caption (when available, which it often won't be, or not in the correct language) below the image instead, but this would lead to a more inconsistent experience and would require making the font size significantly smaller. In any case, it's something we can continue to discuss. Fabrice's preference is to wait for the implementation of structured data support for file description pages, and to then use a multilingual "title" field (similar to the label for Wikidata items).
instead of 'Prabowo Subianto' which is (now) the caption and alt text on the enwiki article, and the the Jokowi photo in MV has a caption of 'Gubernur DKI Jokowi' despite having an {{information}} block on Commons with an English & Indonesian descriptions, albeit without perfect syntax, but that is par for the course and MV design needs to cater for this type of scenario.
In this case it's doing the right thing -- pulling the only description that has a language tag set. Pulling the surrounding text as the default would likely be worse in far more situations. Media Viewer respects the ?uselang= parameter and will show the description in the desired language if available.
Scrolling down on the Prabowo image in MV shows '== Licensing: ==' .. whoops wasnt wikitext supposed to be hidden?
You mean like it is here? https://en.wikipedia.org/wiki/File:Prabowo_wapres.jpeg
This is another syntax problem with the wikitext, but our goal should be to show broken wikitext to as many eyes as possible so that one person takes the initiative to try to fix it.
The Wikimedia Foundation mission statement is not "to show broken wikitext to as many eyes as possible". Wikitext is a tool - and ultimately this file metadata should be managed using a more appropriate tool.
The licensing shows 'CC-BY-SA 3.0', but the image is 'correctly' tagged as CC & GFDL.
Whether or not Media Viewer should show _all_ licenses or just highlight the most usable one is a reasonable discussion to have. Right now, it attempts to do the latter. IMO it should probably recommend a default license above the fold, and show all others below the fold.
GFDL is a license that requires re-users to include a full printed copy of the text of the license with an image. It's nice that we're offering it for some images in addition to CC-licenses, but except for some very obscure cases, it seems unlikely that any user would actually ever _need_ it. So offering this information in a less prominent fashion seems appropriate.
Scrolling down on the Jokowi image in MV shows Indonesian text instead of English text, it isnt identified as Indonesian language despite very good syntax in the wikitext
Media Viewer will pick the most suitable available tagged language and render it. It might be useful to identify a non-English language as such to guide viewers -- I'll file an enhancement request for that. As noted previously, because Indonesian is the only language that was tagged, it will pick that one. I've edited the file description to tag English:
https://commons.wikimedia.org/wiki/File:Gubernur_DKI_Jokowi.jpg#mediaviewer/...
And here it is in Indonesian:
https://commons.wikimedia.org/wiki/File:Gubernur_DKI_Jokowi.jpg?uselang=id#m...
and the 'License details' block on my screen shows the first two lines of the licensing template, and the top third of the third line of text which makes it unreadable, and a 'View more' sort-of-button which appears at the bottom right also overlapping with the second line of license text, obscuring that also. I can expand the box to show the rest of the license details, but ..
The fade-out indicates that the text is abbreviated and can be expanded.
From an ideology perspective, these image pages have many issues which needed to be edited, and the MV doesnt promote editing. It shows dubious, incorrect, or syntactically invalid metadata as if it is un-editable, instead of suggesting that the metadata needs editing.
Yes - we definitely want to offer editing functionality in the viewer down the road. This is directly tied to the work on structured data. When fields like titles are stored as structured metadata, we can potentially make them editable with a simple click action -- even translatable! However, it would be unwise to build such functionality now on top of wikitext. (We should determine whether we really want to expose editing functionality to all readers in the viewer; as we've seen with image annotation on Commons, we'll likely get a lot of nonsense. But we can make that decision when we get there.)
The slidebar has a sequence which repeats the images: Probowo -> Jokowi -> Prabowo -> Jokowi -> Prabowo -> Jowoki and then whooping huge Indonesia flag colors.
It's very unusual to have photographic images repeated in articles in this fashion. MV should probably collapse the sequence, but that's a minor and rare case. The flag only shows up because the template doesn't use the "metadata" or "noviewer" class that exist for the purposes of excluding images from the article sequence. Like other examples, this is a case where clear machine-readable information can only be added incrementally, but when it does get added, it helps us for other purposes as well (e.g. any other process which extracts a sequence of representative images from an article).
See: https://www.mediawiki.org/wiki/Help:Multimedia/Media_Viewer#How_can_I_disabl...
And, there are also sorts of quite important parts of the licensing process which are ignored by MV. e.g. a image which is OTRS pending, now doesnt include a big scary warning one click away. https://en.wikipedia.org/wiki/Nick_Driver#mediaviewer/File:Nick_Driver_in_20...
Media Viewer is not the File: page, intentionally so. It provides a summary view, not all information. We can discuss the inclusion boundaries, but that will always be an ongoing process.
sometimes you get resolutions which are silly (especially svgs at launch, but also slideshows on a file page include a very large license logo)
Can you give a specific, current example?
See above for the 'flag' example,
See above -- images can be excluded from the MV sequence by tagging them with the "noviewer" or "metadata" CSS class as appropriate.
but go to commons, click random file, open in MV, and scroll though all
I still don't understand the issue you're describing.
You mean to say that after the launch, and after much anguish of the community telling the WMF that the extra click was a major pain point, this button was added.
There was always a method to obtain a full resolution copy, it just took two clicks instead of one. The main concern was that the full resolution original file may be in a format the browser doesn't know how to render (correctly), or may be extremely large, so the team wanted to avoid selling that as a "zoom" feature. So they ultimately went with "View original file" which is intentionally a bit technical. Long term we'd like to implement a proper zoomviewer-like zoom feature in MV.
Erik
On 11 July 2014 00:40, Erik Moeller erik@wikimedia.org wrote:
change-aversion tends to correlate pretty strongly with impact on existing workflows and noticeable changes to user experience and behavior.
It's interesting to read that claim in the content of my "aversion" to the unexpected removal of the very useful 'nearby' feature from the Android app [1].
It's normal and expected that the first reaction to noticeable user experience changes will often be negative.
I've yet to hear of any positive aspects of that removal.
[1] Promoted by the WMF at the time of its launch: http://blog.wikimedia.org/2013/05/29/wikipedia-nearby-beta/ and widely reported in the press.
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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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@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@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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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@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@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@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@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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Risker,
I'm actually not going to disagree with you in principle. I ultimately see Media Viewer being used by a good number of users, and said as much from the start. But I also warned that a bulldozer approach was going to cause massive blowback, especially after the previous debacles (VE and ACTRIAL come to mind for me). And well, here we are, with another repeat of the VE situation. That greatly eroded trust in WMF, especially its dev teams and PMs, and that's nowhere even close to rebuilt yet. Now that lack of trust is being confirmed and entrenched.
WMF needs to step very lightly with deployments that will affect editors, and treat the volunteer community as an ally rather than adversary. If that doesn't happen, these showdowns will keep happening.
Part of that is pure arrogance. A significant part of the reason the Vector switch worked is because there was an easy, clearly accessible, one-click option that said "Do not want, disable this!". If that'd been the case here, I would have clicked that and forgotten about it. Instead, I had to dig for an hour to find how to disable the thing, after being surprised by a totally unexpected change. But now we hear things like "We made Vector opt-out too easy!"
Media Viewer probably does have its place, once it is fully functional and free of major bugs. I might even turn it on at that point. But shoving it down people's throats will only serve to further place the WMF's flagship project and the WMF at odds. That is not, I can't imagine, a desirable situation by anyone's estimation. WMF needs a far better deployment strategy than "YOU ARE GETTING IT, LIKE IT OR NOT, AND THAT IS FINAL!!!!!!!!!!!!!" If the WMF's strategy for when the core community and dev team disagree is "We're right, you're wrong, pipe down", these situations will increase in frequency and intensity. I want to stop that before it reaches a real boiling point, and it could've this time if someone had actually gotten desysopped.
On Fri, Jul 11, 2014 at 12:21 AM, Risker risker.wp@gmail.com wrote:
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@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@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@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@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@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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
There's a easy, clearly accessible, one-click option for disabling MediaViewer, Todd. Scroll to the bottom of the screen. Click "disable". Done - it automatically changes your preference.
Risker/Anne
On 11 July 2014 02:44, Todd Allen toddmallen@gmail.com wrote:
Risker,
I'm actually not going to disagree with you in principle. I ultimately see Media Viewer being used by a good number of users, and said as much from the start. But I also warned that a bulldozer approach was going to cause massive blowback, especially after the previous debacles (VE and ACTRIAL come to mind for me). And well, here we are, with another repeat of the VE situation. That greatly eroded trust in WMF, especially its dev teams and PMs, and that's nowhere even close to rebuilt yet. Now that lack of trust is being confirmed and entrenched.
WMF needs to step very lightly with deployments that will affect editors, and treat the volunteer community as an ally rather than adversary. If that doesn't happen, these showdowns will keep happening.
Part of that is pure arrogance. A significant part of the reason the Vector switch worked is because there was an easy, clearly accessible, one-click option that said "Do not want, disable this!". If that'd been the case here, I would have clicked that and forgotten about it. Instead, I had to dig for an hour to find how to disable the thing, after being surprised by a totally unexpected change. But now we hear things like "We made Vector opt-out too easy!"
Media Viewer probably does have its place, once it is fully functional and free of major bugs. I might even turn it on at that point. But shoving it down people's throats will only serve to further place the WMF's flagship project and the WMF at odds. That is not, I can't imagine, a desirable situation by anyone's estimation. WMF needs a far better deployment strategy than "YOU ARE GETTING IT, LIKE IT OR NOT, AND THAT IS FINAL!!!!!!!!!!!!!" If the WMF's strategy for when the core community and dev team disagree is "We're right, you're wrong, pipe down", these situations will increase in frequency and intensity. I want to stop that before it reaches a real boiling point, and it could've this time if someone had actually gotten desysopped.
On Fri, Jul 11, 2014 at 12:21 AM, Risker risker.wp@gmail.com wrote:
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@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@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@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@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@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@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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
There is now. There wasn't originally, or if there was, it didn't show up for me. That was one of the main initial problems, and that's pretty basic stuff. I already figured out how to get rid of it, but it took a good deal of digging at the time to even find out that I could.
So, yes, it's good there's a disable button there. That restores my workflow personally. That doesn't, however, help the concern that millions of users are pulling up the images without immediately seeing the license requirements and author information. The majority of our images require attribution. Some are even nonfree, and which ones may not be clear at first glance. It also doesn't solve the concern that the tool is not yet ready for prime time and shouldn't be the default user experience.
On Fri, Jul 11, 2014 at 12:48 AM, Risker risker.wp@gmail.com wrote:
There's a easy, clearly accessible, one-click option for disabling MediaViewer, Todd. Scroll to the bottom of the screen. Click "disable". Done - it automatically changes your preference.
Risker/Anne
On 11 July 2014 02:44, Todd Allen toddmallen@gmail.com wrote:
Risker,
I'm actually not going to disagree with you in principle. I ultimately
see
Media Viewer being used by a good number of users, and said as much from the start. But I also warned that a bulldozer approach was going to cause massive blowback, especially after the previous debacles (VE and ACTRIAL come to mind for me). And well, here we are, with another repeat of the
VE
situation. That greatly eroded trust in WMF, especially its dev teams and PMs, and that's nowhere even close to rebuilt yet. Now that lack of trust is being confirmed and entrenched.
WMF needs to step very lightly with deployments that will affect editors, and treat the volunteer community as an ally rather than adversary. If
that
doesn't happen, these showdowns will keep happening.
Part of that is pure arrogance. A significant part of the reason the
Vector
switch worked is because there was an easy, clearly accessible, one-click option that said "Do not want, disable this!". If that'd been the case here, I would have clicked that and forgotten about it. Instead, I had to dig for an hour to find how to disable the thing, after being surprised
by
a totally unexpected change. But now we hear things like "We made Vector opt-out too easy!"
Media Viewer probably does have its place, once it is fully functional
and
free of major bugs. I might even turn it on at that point. But shoving it down people's throats will only serve to further place the WMF's flagship project and the WMF at odds. That is not, I can't imagine, a desirable situation by anyone's estimation. WMF needs a far better deployment strategy than "YOU ARE GETTING IT, LIKE IT OR NOT, AND THAT IS FINAL!!!!!!!!!!!!!" If the WMF's strategy for when the core community and dev team disagree is "We're right, you're wrong, pipe down", these situations will increase in frequency and intensity. I want to stop that before it reaches a real boiling point, and it could've this time if someone had actually gotten desysopped.
On Fri, Jul 11, 2014 at 12:21 AM, Risker risker.wp@gmail.com wrote:
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@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@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@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@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@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@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@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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Fri, Jul 11, 2014 at 3:58 AM, Todd Allen toddmallen@gmail.com wrote:
That doesn't, however, help the concern that millions of users are pulling
up the images without immediately seeing the license requirements and
author information.
To the contrary, Media Viewer displays the license, author and source as an always visible part of the image. On a typical file page, you have to scroll down to find any of this information; most users won't do that, if what they are looking for is the image, and that is available without scrolling. (It is well known in web usability http://www.nngroup.com/articles/scrolling-and-attention/ that relatively little attention is given to things above the fold; one of the main benefits of Media Viewer is that it brings the most important things above it.)
Also, many people might not use file pages simply because they are so slow. A famous experiment by Google http://googleresearch.blogspot.com/2009/06/speed-matters.html showed that lowering loading speed by 200 ms resulted in 0.3% less interactions (on the English Wikipedia's scale, that would be about 20,000 thumbnail clicks a day). MediaViewer improves image loading time by a full second for the median user.
On Sat, Jul 12, 2014 at 12:22 AM, Gergo Tisza gtisza@wikimedia.org wrote:
On Fri, Jul 11, 2014 at 3:58 AM, Todd Allen toddmallen@gmail.com wrote:
That doesn't, however, help the concern that millions of users are
pulling
up the images without immediately seeing the license requirements and
author information.
To the contrary, Media Viewer displays the license, author and source as an always visible part of the image. On a typical file page, you have to scroll down to find any of this information; most users won't do that, if what they are looking for is the image, and that is available without scrolling. (It is well known in web usability http://www.nngroup.com/articles/scrolling-and-attention/ that relatively little attention is given to things above the fold; one of the main benefits of Media Viewer is that it brings the most important things above it.)
Agree. The best practices for "marking a work" is to "*make sure that the license information is clearly visible underneath (or otherwise next to) the image." [1] [2]*
*1. **http://wiki.creativecommons.org/Marking_your_work_with_a_CC_license http://wiki.creativecommons.org/Marking_your_work_with_a_CC_license*
*2. http://www.newmediarights.org/guide/how_to/creative_commons/best_practices_c... http://www.newmediarights.org/guide/how_to/creative_commons/best_practices_creative_commons_attributions*
*Unfortunately our "file description page" give more importance for subject description and bury the attribution parameters in a negligible location. As a result most reuses end up with an attribution, "Credit:Wiki[m/p]edia". :(*
*Jee*
On Fri, Jul 11, 2014 at 2:52 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Fri, Jul 11, 2014 at 3:58 AM, Todd Allen toddmallen@gmail.com wrote:
That doesn't, however, help the concern that millions of users are
pulling
up the images without immediately seeing the license requirements and
author information.
To the contrary, Media Viewer displays the license, author and source as an always visible part of the image. On a typical file page, you have to scroll down to find any of this information; most users won't do that, if what they are looking for is the image, and that is available without scrolling. (It is well known in web usability http://www.nngroup.com/articles/scrolling-and-attention/ that relatively little attention is given to things above the fold; one of the main benefits of Media Viewer is that it brings the most important things above it.)
Also, many people might not use file pages simply because they are so slow. A famous experiment by Google http://googleresearch.blogspot.com/2009/06/speed-matters.html showed that lowering loading speed by 200 ms resulted in 0.3% less interactions (on the English Wikipedia's scale, that would be about 20,000 thumbnail clicks a day). MediaViewer improves image loading time by a full second for the median user.
George has made a useful contribution here, in that his points appear to be actually testable.
Could the WMF or someone else look into user-testing how the MediaViewer (and variations on it) affects the average reader's perception and consciousness of the licensing information?
Thanks, Pharos
I have made a suggestion to the WMF Board. See https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_noticeboard#Sugge...
In the near future, I plan to look at the policies surrounding office actions as they apply to product decisions made by local communities, and will likely make a request to the Board that they review those policies as a separate matter.
Cheers, Pine
On Fri, Jul 11, 2014 at 8:32 PM, Pharos pharosofalexandria@gmail.com wrote:
On Fri, Jul 11, 2014 at 2:52 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Fri, Jul 11, 2014 at 3:58 AM, Todd Allen toddmallen@gmail.com
wrote:
That doesn't, however, help the concern that millions of users are
pulling
up the images without immediately seeing the license requirements and
author information.
To the contrary, Media Viewer displays the license, author and source as
an
always visible part of the image. On a typical file page, you have to scroll down to find any of this information; most users won't do that, if what they are looking for is the image, and that is available without scrolling. (It is well known in web usability http://www.nngroup.com/articles/scrolling-and-attention/ that
relatively
little attention is given to things above the fold; one of the main benefits of Media Viewer is that it brings the most important things
above
it.)
Also, many people might not use file pages simply because they are so slow. A famous experiment by Google http://googleresearch.blogspot.com/2009/06/speed-matters.html showed that lowering loading speed by 200 ms resulted in 0.3% less interactions (on
the
English Wikipedia's scale, that would be about 20,000 thumbnail clicks a day). MediaViewer improves image loading time by a full second for the median user.
George has made a useful contribution here, in that his points appear to be actually testable.
Could the WMF or someone else look into user-testing how the MediaViewer (and variations on it) affects the average reader's perception and consciousness of the licensing information?
Thanks, Pharos _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
I have requested that the Board clarify WMF policy about office actions with regard to the software features of wikis.
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_noticeboard#Reque...
Pine
On Sat, Jul 12, 2014 at 1:05 AM, Pine W wiki.pine@gmail.com wrote:
I have made a suggestion to the WMF Board. See https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_noticeboard#Sugge...
In the near future, I plan to look at the policies surrounding office actions as they apply to product decisions made by local communities, and will likely make a request to the Board that they review those policies as a separate matter.
Cheers, Pine
On Fri, Jul 11, 2014 at 8:32 PM, Pharos pharosofalexandria@gmail.com wrote:
On Fri, Jul 11, 2014 at 2:52 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Fri, Jul 11, 2014 at 3:58 AM, Todd Allen toddmallen@gmail.com
wrote:
That doesn't, however, help the concern that millions of users are
pulling
up the images without immediately seeing the license requirements and
author information.
To the contrary, Media Viewer displays the license, author and source
as an
always visible part of the image. On a typical file page, you have to scroll down to find any of this information; most users won't do that,
if
what they are looking for is the image, and that is available without scrolling. (It is well known in web usability http://www.nngroup.com/articles/scrolling-and-attention/ that
relatively
little attention is given to things above the fold; one of the main benefits of Media Viewer is that it brings the most important things
above
it.)
Also, many people might not use file pages simply because they are so slow. A famous experiment by Google http://googleresearch.blogspot.com/2009/06/speed-matters.html showed that lowering loading speed by 200 ms resulted in 0.3% less interactions (on
the
English Wikipedia's scale, that would be about 20,000 thumbnail clicks a day). MediaViewer improves image loading time by a full second for the median user.
George has made a useful contribution here, in that his points appear to be actually testable.
Could the WMF or someone else look into user-testing how the MediaViewer (and variations on it) affects the average reader's perception and consciousness of the licensing information?
Thanks, Pharos _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Sue,
You have gotten your logic exactly backwards here.
Of course David is right -- we should all have some humility about things that we don't, and can't, know.
But the people who express certainty about what readers need -- the people who assert that those needs are paramount, and trump the needs of editors (experienced and occasional), of photographers (with and without Wikimedia accounts), of models (consenting and non-consenting) -- and maybe most significantly, the people who have both the power and the audacity to impose their interpretation of those believes on millions upon millions upon millions of Wikimedia users --
those people all work for the Wikimedia Foundation.
You're addressing the wrong audience here. -Pete [[User:Peteforsyth]]
On Thu, Jul 10, 2014 at 9:40 PM, Sue Gardner sgardner@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@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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 10/07/2014, Erik Moeller erik@wikimedia.org wrote:
On Wed, Jul 9, 2014 at 10:03 PM, Pine W wiki.pine@gmail.com wrote:
Will WMF deactivate MediaViewer on English Wikipedia
No. Detailed explanation: https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Media_Viewer/June_...
Folks following this discussion, and the problematic "tone" we have seen from some parties, may want to chip in with their views for the English Wikipedia Arbcom to consider: https://en.wikipedia.org/wiki/Wikipedia:Arbitration/Requests/Case#MediaViewe...
Fae
Pine and all,
Please read here:
https://en.wikipedia.org/wiki/Wikipedia_talk:Media_Viewer/June_2014_RfC#Prop...
Gryllida.
On Thu, 10 Jul 2014, at 15:03, Pine W wrote:
This discussion has closed on English Wikipedia: https://en.wikipedia.org/wiki/Wikipedia:Media_Viewer/June_2014_RfC
Will WMF deactivate MediaViewer on English Wikipedia per community consensus?
Also, as WMF probably knows, Commons is currently having a similar discussion: https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/Media_Viewer...
Thanks,
Pine _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hi Gryllida,
As I said on the Arbcom case page, RfCs result in changes to Wikipedia on a regular basis despite having a small numbers of participants in each RfC, and current English Wikipedia policy does not require a minimum number of participants beyond what is necessary to establish consensus. Furthermore, any assertion that the MV RfC was invalid because of its advertising or because it had too few participants would open up countless RfCs to being challenged for the same reason. I believe that the form of the MediaViewer RfC and participation in it were sufficient to establish a legitimate consensus.
I am still thinking through the effects that this situation has on the WMF-community relationship. I'm pretty discouraged, and I know others are too.
Pine
On Sun, Jul 13, 2014 at 2:36 AM, Gryllida gryllida@fastmail.fm wrote:
Pine and all,
Please read here:
https://en.wikipedia.org/wiki/Wikipedia_talk:Media_Viewer/June_2014_RfC#Prop...
Gryllida.
On Thu, 10 Jul 2014, at 15:03, Pine W wrote:
This discussion has closed on English Wikipedia: https://en.wikipedia.org/wiki/Wikipedia:Media_Viewer/June_2014_RfC
Will WMF deactivate MediaViewer on English Wikipedia per community consensus?
Also, as WMF probably knows, Commons is currently having a similar discussion:
https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/Media_Viewer...
Thanks,
Pine _______________________________________________ Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
It's time to face reality here: The WMF didn't screw up this RFC, we the English Wikipedia community did.
When we have RFCs that are of interest to a broad portion of the community and will have an impact on the entire community, we do certain things. We advertise it on the watchlist. We arrange for a panel of administrators with experience in assessing consensus to close the discussion - sometimes we line them up before the discussion even happens. We maintain discipline on the RFC page so that there aren't acres of discussion there, and move it to the talk page. We encourage the most fervent supporters and opposers to remain calm and to move on once they've expressed their position. That's what we do when we think something is important - like all the pending changes RFCs and the current conflict of interest discusssions, and the recent discussions about whether certain edit counters should be opt-in or opt-out or automatic.
None of those things happened with this RFC. No watchlist notice. No advance planning for closure. A completely undisciplined RFC. An inexperienced closer who obviously got it wrong, since his initial close didn't match the discussion in the RFC. Instead of people questioning the wrong close, someone writes a script to enact the erroneous close and then encourages an administrator to apply it to the Mediawiki.common.js without explaining exactly what it would do. An administrator who doesn't have the knowledge base to understand the code he was adding adds it - on a page where every other entry for the past several years has been made by experienced and knowledgeable developers. It was entirely correct that his code was reverted - it didn't do what was intended, and it adversely affected every user of English Wikipedia, whether or not they cared about Media Viewer. It was entirely correct that the administrator was warned not to repeat the action - you don't mess around with site-wide impacts - and that he was told the potential consequences if he repeated the action. Warnings are routine and expected if people act outside of our accepted standards or cause harm, whether intended or not. He needed to know that his actions were a big deal with serious consequences.
And now we have the nerve to act as though this is all the WMF's fault. It's not. Every step that led to this breakdown in communication, this disruption in the relationship between the community and the WMF, was taken by members of the English Wikipedia community, with the exception of the reversion of site-breaking code. We did this all by ourselves. I'll even put my hand up and say "geez, maybe I should have pushed harder for a watchlist notice when I saw the RFC" - but the obvious indifference to the issue blinkered me too.
We should be disappointed - but we should be looking at ourselves and fixing the problems we're responsible for. The WMF isn't perfect, and it's made some incredibly bone-headed decisions in the past. It's also made some really good decisions, and none of them were entirely perfect right out of the box and needed tweaking. Instead of rejecting those decisions outright because they failed to be perfect, we all worked together - WMF, developers, and community members from all sorts of projects - to get them right. We need to go back to that perspective. Everyone does. Not just the WMF - our community does too.
Risker/Anne
On 14 July 2014 01:40, Pine W wiki.pine@gmail.com wrote:
Hi Gryllida,
As I said on the Arbcom case page, RfCs result in changes to Wikipedia on a regular basis despite having a small numbers of participants in each RfC, and current English Wikipedia policy does not require a minimum number of participants beyond what is necessary to establish consensus. Furthermore, any assertion that the MV RfC was invalid because of its advertising or because it had too few participants would open up countless RfCs to being challenged for the same reason. I believe that the form of the MediaViewer RfC and participation in it were sufficient to establish a legitimate consensus.
I am still thinking through the effects that this situation has on the WMF-community relationship. I'm pretty discouraged, and I know others are too.
Pine
On Sun, Jul 13, 2014 at 2:36 AM, Gryllida gryllida@fastmail.fm wrote:
Pine and all,
Please read here:
https://en.wikipedia.org/wiki/Wikipedia_talk:Media_Viewer/June_2014_RfC#Prop...
Gryllida.
On Thu, 10 Jul 2014, at 15:03, Pine W wrote:
This discussion has closed on English Wikipedia: https://en.wikipedia.org/wiki/Wikipedia:Media_Viewer/June_2014_RfC
Will WMF deactivate MediaViewer on English Wikipedia per community consensus?
Also, as WMF probably knows, Commons is currently having a similar discussion:
https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/Media_Viewer...
Thanks,
Pine _______________________________________________ Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
I'd agree with Risker more or less wholeheartedly - communication is a multilateral thing not a unilateral thing, and I think we dropped the ball on handling this discussion properly.
This certainly isn't new - holding a large-scale community discussion is *hard* and both the community and WMF tend to have problems instigating and managing it - but this could have been a lot better.
I've been mostly offwiki for the past few weeks (and had my attention sapped by a different RFC), but I'll also put my hand up and say I should have done something - I normally try and make sure discussions like this get advertised at a suitable level and I was vaguely aware this one was going on. Mea culpa.
I've been doing some thinking about this over the past year or so, bubbling away in the back of my mind, after a talk at last Wikimania - would there be any interest/usefulness if I sat down and tried to dump it into a "how to run a large project RFC, and what doesn't work" page somewhere?
Andrew.
On 14 July 2014 09:04, Risker risker.wp@gmail.com wrote:
It's time to face reality here: The WMF didn't screw up this RFC, we the English Wikipedia community did.
When we have RFCs that are of interest to a broad portion of the community and will have an impact on the entire community, we do certain things. We advertise it on the watchlist. We arrange for a panel of administrators with experience in assessing consensus to close the discussion - sometimes we line them up before the discussion even happens. We maintain discipline on the RFC page so that there aren't acres of discussion there, and move it to the talk page. We encourage the most fervent supporters and opposers to remain calm and to move on once they've expressed their position. That's what we do when we think something is important - like all the pending changes RFCs and the current conflict of interest discusssions, and the recent discussions about whether certain edit counters should be opt-in or opt-out or automatic.
None of those things happened with this RFC. No watchlist notice. No advance planning for closure. A completely undisciplined RFC. An inexperienced closer who obviously got it wrong, since his initial close didn't match the discussion in the RFC. Instead of people questioning the wrong close, someone writes a script to enact the erroneous close and then encourages an administrator to apply it to the Mediawiki.common.js without explaining exactly what it would do. An administrator who doesn't have the knowledge base to understand the code he was adding adds it - on a page where every other entry for the past several years has been made by experienced and knowledgeable developers. It was entirely correct that his code was reverted - it didn't do what was intended, and it adversely affected every user of English Wikipedia, whether or not they cared about Media Viewer. It was entirely correct that the administrator was warned not to repeat the action - you don't mess around with site-wide impacts - and that he was told the potential consequences if he repeated the action. Warnings are routine and expected if people act outside of our accepted standards or cause harm, whether intended or not. He needed to know that his actions were a big deal with serious consequences.
And now we have the nerve to act as though this is all the WMF's fault. It's not. Every step that led to this breakdown in communication, this disruption in the relationship between the community and the WMF, was taken by members of the English Wikipedia community, with the exception of the reversion of site-breaking code. We did this all by ourselves. I'll even put my hand up and say "geez, maybe I should have pushed harder for a watchlist notice when I saw the RFC" - but the obvious indifference to the issue blinkered me too.
We should be disappointed - but we should be looking at ourselves and fixing the problems we're responsible for. The WMF isn't perfect, and it's made some incredibly bone-headed decisions in the past. It's also made some really good decisions, and none of them were entirely perfect right out of the box and needed tweaking. Instead of rejecting those decisions outright because they failed to be perfect, we all worked together - WMF, developers, and community members from all sorts of projects - to get them right. We need to go back to that perspective. Everyone does. Not just the WMF - our community does too.
Risker/Anne
On 14 July 2014 01:40, Pine W wiki.pine@gmail.com wrote:
Hi Gryllida,
As I said on the Arbcom case page, RfCs result in changes to Wikipedia on a regular basis despite having a small numbers of participants in each RfC, and current English Wikipedia policy does not require a minimum number of participants beyond what is necessary to establish consensus. Furthermore, any assertion that the MV RfC was invalid because of its advertising or because it had too few participants would open up countless RfCs to being challenged for the same reason. I believe that the form of the MediaViewer RfC and participation in it were sufficient to establish a legitimate consensus.
I am still thinking through the effects that this situation has on the WMF-community relationship. I'm pretty discouraged, and I know others are too.
Pine
On Sun, Jul 13, 2014 at 2:36 AM, Gryllida gryllida@fastmail.fm wrote:
Pine and all,
Please read here:
https://en.wikipedia.org/wiki/Wikipedia_talk:Media_Viewer/June_2014_RfC#Prop...
Gryllida.
On Thu, 10 Jul 2014, at 15:03, Pine W wrote:
This discussion has closed on English Wikipedia: https://en.wikipedia.org/wiki/Wikipedia:Media_Viewer/June_2014_RfC
Will WMF deactivate MediaViewer on English Wikipedia per community consensus?
Also, as WMF probably knows, Commons is currently having a similar discussion:
https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/Media_Viewer...
Thanks,
Pine _______________________________________________ Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@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@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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 7/14/2014 4:43 AM, Andrew Gray wrote:
I've been doing some thinking about this over the past year or so, bubbling away in the back of my mind, after a talk at last Wikimania - would there be any interest/usefulness if I sat down and tried to dump it into a "how to run a large project RFC, and what doesn't work" page somewhere?
There certainly would be usefulness, so I hope there would be equivalent interest. I'd be interested in seeing it, at any rate.
--Michael Snow
On 14 July 2014 09:55, Michael Snow wikipedia@frontier.com wrote:
On 7/14/2014 4:43 AM, Andrew Gray wrote:
I've been doing some thinking about this over the past year or so, bubbling away in the back of my mind, after a talk at last Wikimania - would there be any interest/usefulness if I sat down and tried to dump it into a "how to run a large project RFC, and what doesn't work" page somewhere?
There certainly would be usefulness, so I hope there would be equivalent interest. I'd be interested in seeing it, at any rate.
Me too, Andrew. I think we actually do need some sort of checklist or guidance document on how to deal with these sorts of issues. In this particular case, it had the added element of affecting readers possibly even more so than editors, so some thoughts on how to involve readers in discussions that affect their usage of the site would be good.
Risker/Anne
Hi all, I am willing to support a more detailed RfC policy that describes where and how notices should be distributed for different kinds of RfCs, although for the MV RfC I feel notice was adequate and there was lots of opportunity for anyone who felt that notice was inadequate, including WMF, to say so or boldly distribute notice more widely during the month that the RfC was open. I am not of a mind to reopen this RfC, but again, very willing to support a more detailed RfC policy for future events.
Pine
On Mon, Jul 14, 2014 at 7:00 AM, Risker risker.wp@gmail.com wrote:
On 14 July 2014 09:55, Michael Snow wikipedia@frontier.com wrote:
On 7/14/2014 4:43 AM, Andrew Gray wrote:
I've been doing some thinking about this over the past year or so, bubbling away in the back of my mind, after a talk at last Wikimania - would there be any interest/usefulness if I sat down and tried to dump it into a "how to run a large project RFC, and what doesn't work" page somewhere?
There certainly would be usefulness, so I hope there would be equivalent interest. I'd be interested in seeing it, at any rate.
Me too, Andrew. I think we actually do need some sort of checklist or guidance document on how to deal with these sorts of issues. In this particular case, it had the added element of affecting readers possibly even more so than editors, so some thoughts on how to involve readers in discussions that affect their usage of the site would be good.
Risker/Anne _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Mon, Jul 14, 2014 at 1:40 AM, Pine W wiki.pine@gmail.com wrote:
Hi Gryllida,
As I said on the Arbcom case page, RfCs result in changes to Wikipedia on a regular basis despite having a small numbers of participants in each RfC, and current English Wikipedia policy does not require a minimum number of participants beyond what is necessary to establish consensus. Furthermore, any assertion that the MV RfC was invalid because of its advertising or because it had too few participants would open up countless RfCs to being challenged for the same reason. I believe that the form of the MediaViewer RfC and participation in it were sufficient to establish a legitimate consensus.
I am still thinking through the effects that this situation has on the WMF-community relationship. I'm pretty discouraged, and I know others are too.
Pine
The common practice is that the wider the effect of the change called for in an RfC, the larger and more representative the group of participants must be for the result to be binding. So for something like MediaViewer, the pool of people responding should be quite large. In this case, it wasn't.
wikimedia-l@lists.wikimedia.org