Re: [Wikimedia-l] Community RfCs about MediaViewer
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...@gmail.com wrote: On 14 July 2014 09:55, Michael Snow wikipe...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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...@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.p...@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
Re: [Wikimedia-l] Community RfCs about MediaViewer
On Mon, Jul 14, 2014 at 1:40 AM, Pine W wiki.p...@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 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
Pine, please read what risker said in this thread. It is not about proper paperwork, it is about choosing who to reach and what to communicate to them. Communicate with multimedia team about getting an objective picture and doing the statistics right. This is a broad interesting topic that, as you may see at the rfc talk page, would make use of a structured and free approach with better software (and rather interestingly, potentionally input from users of various sister projects and languages). Gryllida. On Mon, 14 Jul 2014, at 15:40, Pine W 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 gryll...@fastmail.fm wrote: Pine and all, Please read here: https://en.wikipedia.org/wiki/Wikipedia_talk:Media_Viewer/June_2014_RfC#Proposal_to_reach_consistency.2Fagreement_first.2C_before_actioning_this_RfC 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_software_feature 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-requ...@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-requ...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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 ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On 14 July 2014 09:55, Michael Snow wikipe...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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#Request:_clarify_policy_for_on-wiki_Office_actions Pine On Sat, Jul 12, 2014 at 1:05 AM, Pine W wiki.p...@gmail.com wrote: I have made a suggestion to the WMF Board. See https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_noticeboard#Suggestion_for_the_Board:_Technology_Committee 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 pharosofalexand...@gmail.com wrote: On Fri, Jul 11, 2014 at 2:52 PM, Gergo Tisza gti...@wikimedia.org wrote: On Fri, Jul 11, 2014 at 3:58 AM, Todd Allen toddmal...@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/guidelineswikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
Pine and all, Please read here: https://en.wikipedia.org/wiki/Wikipedia_talk:Media_Viewer/June_2014_RfC#Proposal_to_reach_consistency.2Fagreement_first.2C_before_actioning_this_RfC 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_software_feature 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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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 gryll...@fastmail.fm wrote: Pine and all, Please read here: https://en.wikipedia.org/wiki/Wikipedia_talk:Media_Viewer/June_2014_RfC#Proposal_to_reach_consistency.2Fagreement_first.2C_before_actioning_this_RfC 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_software_feature 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-requ...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
I have made a suggestion to the WMF Board. See https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_noticeboard#Suggestion_for_the_Board:_Technology_Committee 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 pharosofalexand...@gmail.com wrote: On Fri, Jul 11, 2014 at 2:52 PM, Gergo Tisza gti...@wikimedia.org wrote: On Fri, Jul 11, 2014 at 3:58 AM, Todd Allen toddmal...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On Fri, Jul 11, 2014 at 9:40 AM, Erik Moeller e...@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-what-to-do-about-it 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 ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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 toddmal...@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 sgard...@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
Re: [Wikimedia-l] Community RfCs about MediaViewer
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...@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 toddmal...@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
Re: [Wikimedia-l] Community RfCs about MediaViewer
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 toddmal...@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...@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 toddmal...@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
Re: [Wikimedia-l] Community RfCs about MediaViewer
On Thu, Jul 10, 2014 at 11:02 PM, John Mark Vandenberg jay...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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 e...@wikimedia.org wrote: On Thu, Jul 10, 2014 at 11:02 PM, John Mark Vandenberg jay...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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_update_CC_license_tags_to_comply_with_the_new_wordings_in_CC_deeds 2. https://commons.wikimedia.org/w/index.php?title=Commons:Requests_for_comment/Media_Viewer_software_featurediff=128434830oldid=128433051 On Fri, Jul 11, 2014 at 1:20 PM, Pine W wiki.p...@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 e...@wikimedia.org wrote: On Thu, Jul 10, 2014 at 11:02 PM, John Mark Vandenberg jay...@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-requ...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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 sgard...@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-requ...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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...@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 toddmal...@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...@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
Re: [Wikimedia-l] Community RfCs about MediaViewer
'On Fri, Jul 11, 2014 at 4:53 PM, Erik Moeller e...@wikimedia.org wrote:
On Thu, Jul 10, 2014 at 11:02 PM, John Mark Vandenberg jay...@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_2013.png
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
Re: [Wikimedia-l] Community RfCs about MediaViewer
On 10/07/2014, Erik Moeller e...@wikimedia.org wrote: On Wed, Jul 9, 2014 at 10:03 PM, Pine W wiki.p...@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_2014_RfCdiff=616407785oldid=616294249 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#MediaViewer_RfC Fae -- fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae https://en.wikipedia.org/wiki/User:Fae ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On Fri, Jul 11, 2014 at 4:21 AM, John Mark Vandenberg jay...@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/File:Gubernur_DKI_Jokowi.jpg
And here it is in Indonesian:
https://commons.wikimedia.org/wiki/File:Gubernur_DKI_Jokowi.jpg?uselang=id#mediaviewer/File:Gubernur_DKI_Jokowi.jpg
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
Re: [Wikimedia-l] Community RfCs about MediaViewer
On 11 July 2014 00:40, Erik Moeller e...@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. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On Fri, Jul 11, 2014 at 3:58 AM, Todd Allen toddmal...@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. ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On Sat, Jul 12, 2014 at 12:22 AM, Gergo Tisza gti...@wikimedia.org wrote: On Fri, Jul 11, 2014 at 3:58 AM, Todd Allen toddmal...@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_creative_commons_attributions 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* ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On Fri, Jul 11, 2014 at 2:52 PM, Gergo Tisza gti...@wikimedia.org wrote: On Fri, Jul 11, 2014 at 3:58 AM, Todd Allen toddmal...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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.p...@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_software_feature 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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On 10/07/2014, Brion Vibber bvib...@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 -- fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On Jul 10, 2014 10:36 AM, Isarra Yos zhoris...@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-requ...@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 ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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_RfCdiff=614906589oldid=614904248 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 bvib...@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-se...@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 zhoris...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at:
Re: [Wikimedia-l] Community RfCs about MediaViewer
On Thu, Jul 10, 2014 at 9:52 AM, Pierre-Selim pierre-se...@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 ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On Thu, Jul 10, 2014 at 9:52 AM, Pierre-Selim pierre-se...@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 -- 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On 10 July 2014 17:36, Isarra Yos zhoris...@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. ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On 10 July 2014 19:23, Isarra Yos zhoris...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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 ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On Jul 10, 2014 12:42 PM, David Gerard dger...@gmail.com wrote: On 10 July 2014 19:23, Isarra Yos zhoris...@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-requ...@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. ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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 petefors...@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_RfCdiff=614906589oldid=614904248 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 bvib...@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-se...@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 zhoris...@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/
Re: [Wikimedia-l] Community RfCs about MediaViewer
On Thu, Jul 10, 2014 at 11:41 AM, David Gerard dger...@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. ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On Wed, Jul 9, 2014 at 10:03 PM, Pine W wiki.p...@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_2014_RfCdiff=616407785oldid=616294249 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
2014-07-10 17:53 GMT+02:00 Brion Vibber bvib...@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. ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
Erik Moeller wrote: On Wed, Jul 9, 2014 at 10:03 PM, Pine W wiki.p...@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 ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
This was clarified as an office action under threat of desysop here: https://en.wikipedia.org/w/index.php?title=User_talk:Peteforsythdiff=616427707oldid=615757838 On Thu, Jul 10, 2014 at 4:31 PM, John Lewis johnflewi...@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.p...@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-requ...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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=616427707diffonly=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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On 10/07/2014, Todd Allen toddmal...@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:Peteforsythdiff=616427707oldid=615757838 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 -- fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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=616427707diffonly=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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On 10 July 2014 23:46, Fæ fae...@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. ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On 10/07/2014, David Gerard dger...@gmail.com wrote: On 10 July 2014 23:46, Fæ fae...@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 -- fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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_2014_RfCdiff=616407785oldid=616294249 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 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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-what-to-do-about-it 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 [1] http://xkcd.com/1172/ -- 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
On 10 July 2014 22:21, Juergen Fenn schneeschme...@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. -- geni ___ 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
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 sgard...@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-requ...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] Community RfCs about MediaViewer
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_software_feature 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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Community RfCs about MediaViewer
Has a bug request been filed? On 10 July 2014 15:03, Pine W wiki.p...@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_software_feature 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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
