Media Viewer - A new hope

[Vigilant]

And it's funny you mentioned LibreOffice. When Oracle bought Sun and forced out the developers of Open Office, they went off and did a major revision for LO, which included the removal of megabytes of "deprecated code".

That's refactoring.
Always try to remove as much code as possible.


That's the opposite of what the WMF is doing...putting someone else's known broken code into their first major release to a hostile crowd of unwilling customers.

[dogbiscuit]

That's the opposite of what the WMF is doing...putting someone else's known broken code into their first major release to a hostile crowd of unwilling customers.

To be fair what they probably did was:

1) Think - need tool tip.
2) JuniorWMF programmer does a quick Google (or more likely used some weird open source search engine because them's the rules and got a 15 year old search result.
3) Found some code which looked like it worked.
4) Didn't know that stuff is on SourceForge which is out of date and abandoned so just assumed it was OK.
5) Stuck code in without supervision.
6) Quick test by lead programmer - runs mouse over buttons, sees tips, ticks tested box.
7) All is well.
8) Complaints from end users - bastards are at it again!
9) Come up with some glib CYA statement that makes it sound to themselves that they know what they are doing.

It does make you think: they now know that they have broken code in their project that doesn't work, and rather than saying "Oh, we need to fix that, we better find another tooltip library because the dolt goofed prototype code we used doesn't work in all scenarios" they simply say "Oh, someone else's code is broken so we are not going to fix it - live with it, it is not important to us that the product we make is broken."

Unbelievable.

Nobody forced them to select broken code to start with.

[Zoloft]

That's the opposite of what the WMF is doing...putting someone else's known broken code into their first major release to a hostile crowd of unwilling customers.

To be fair what they probably did was:

1) Think - need tool tip.
2) JuniorWMF programmer does a quick Google (or more likely used some weird open source search engine because them's the rules and got a 15 year old search result.
3) Found some code which looked like it worked.
4) Didn't know that stuff is on SourceForge which is out of date and abandoned so just assumed it was OK.
5) Stuck code in without supervision.
6) Quick test by lead programmer - runs mouse over buttons, sees tips, ticks tested box.
7) All is well.
8) Complaints from end users - bastards are at it again!
9) Come up with some glib CYA statement that makes it sound to themselves that they know what they are doing.

It does make you think: they now know that they have broken code in their project that doesn't work, and rather than saying "Oh, we need to fix that, we better find another tooltip library because the dolt goofed prototype code we used doesn't work in all scenarios" they simply say "Oh, someone else's code is broken so we are not going to fix it - live with it, it is not important to us that the product we make is broken."

Unbelievable.

Nobody forced them to select broken code to start with.

Indeed they could have developed their own tooltip libraries.
They could be simple but difficult-to-break, using only CSS and HTML.
Or Java, or javascript, or python, or perl...

There are tutorials all over the place.

Build your own libraries, maintain them.

You work for an enterprise, with a staff, and a multi-million dollar budget!

[Hex]

I nudged them about this. Apparently "Tipsy is a module of the core software and used in several more places." Perhaps it got there before it became unmaintained. Either way, if was known to be unmaintained it should have been culled, pronto, but instead is now just another piece of technical debt - as evidenced by the bug report.

[Vigilant]

That's the opposite of what the WMF is doing...putting someone else's known broken code into their first major release to a hostile crowd of unwilling customers.

To be fair what they probably did was:

1) Think - need tool tip.
2) JuniorWMF programmer does a quick Google (or more likely used some weird open source search engine because them's the rules and got a 15 year old search result.
3) Found some code which looked like it worked.
4) Didn't know that stuff is on SourceForge which is out of date and abandoned so just assumed it was OK.
5) Stuck code in without supervision.
6) Quick test by lead programmer - runs mouse over buttons, sees tips, ticks tested box.
7) All is well.
8) Complaints from end users - bastards are at it again!
9) Come up with some glib CYA statement that makes it sound to themselves that they know what they are doing.

It does make you think: they now know that they have broken code in their project that doesn't work, and rather than saying "Oh, we need to fix that, we better find another tooltip library because the dolt goofed prototype code we used doesn't work in all scenarios" they simply say "Oh, someone else's code is broken so we are not going to fix it - live with it, it is not important to us that the product we make is broken."

Unbelievable.

Nobody forced them to select broken code to start with.

The tech lead, the project and/or program manager and especially the build master should all have caught this and said, "No man. No. Fuck no. I do believe you could get your ass kicked for trying something like that."

Such amateur hour garbage.

[Poetlister]

I suppose it's out of the question for them to fix Tipsy themselves.

[dogbiscuit]

I suppose it's out of the question for them to fix Tipsy themselves.

Quite. Surely one of the points of using open source code is that it is there for you to use as you wish.

Their choices are:

1) SOFIXIT
2) Pay someone else to fix it.
3) Select another product and use that instead.

Personally I think too tips are usually an indication that something is up with the interface to patch up something that is not intuitive. So with the WMF we can see that tooltips will always be essential, and also they are a solution for ensuring that inexperienced users, who may not be familiar with the concepts within the interface, do gain useful extra information.

[Kelly Martin]

It does make you think: they now know that they have broken code in their project that doesn't work, and rather than saying "Oh, we need to fix that, we better find another tooltip library because the dolt goofed prototype code we used doesn't work in all scenarios" they simply say "Oh, someone else's code is broken so we are not going to fix it - live with it, it is not important to us that the product we make is broken."

It's amazing the degree to which the buck-passing ideology is sunk in there. When you adopt someone else's code into your project you make any flaws in their code your problem. If there's a bug, it's up to you to get it fixed. The customer doesn't care who wrote the bad code, all the customer cares about is that it doesn't work.

It seems nobody in WMF engineering is committed to success. They're all just committed to getting their paychecks.

[Freddy]

It's sad to see a project with such potential wasted by the lazy developers at WMF.

What WMF engineers see:


What everybody else sees:

[Vigilant]

Can anyone figure out why these two statements should come out of the same developer's mouth?

Tipsy is unmaintained and generally low quality

Tipsy is a module of the core software and used in several more places.

Is there anyone here, developer or not, who thinks this is an acceptable state of affairs? Ever?

[Vigilant]

The RFC has now run for 30 days.
Media Viewer is going down 10-1 for disabling by default for logged in users and 4-1 for disabling by default for logged out users.

Closing it now in favor of disabling it, opt-in in both cases, is a no-brainer.
Pine looks like the perfect no-brainer for the job.

It makes me wonder, "at what point will the WMF stop building and deploying software that nobody wants?"

The three biggest pushes, VisualEditor, Flow and MediViewer, can only be described as abject failures.
At what point does the Director of Engineering get called on the carpet?
Or is it the fact that this is only donated money mean that that never, ever happens?

[Vigilant]

From the commons RFC (https://commons.wikimedia.org/wiki/Comm ... re_feature)

I literally can't think of a single time where I ever found the media viewer to be anything other than an annoyance. Typical scenario: I want to view certain information about an image, such as its file size, history, assesments tags, usage, etc. I click on the picture expecting to be taken to the file page where I know exactly where everything is like the back of my hand. Instead the screen goes black and an ugly light gray bar with rudimentary information blinks into appearance taking up the lower third of the screen. wtf. Then an extremely blurry version of the image shows up and the site freezes for a few more seconds until the actual image loads.

The visual design is horrendous and reeks of Windows 8 (and not in a good way). Gray squares angles and lines are cut or placed off awkwardly on the gray background, and delineate gray text. It seems that every line of text is a different size which makes me unconfortable. The image name is present, but is missing the file extension, which makes it difficult to copy the name and paste it into brackets for use in a wiki page. In what appear to be a row of parking spaces (or awkwardly clipped squares) there lies a gray megaphone, a gray iOS 6 style export icon, and, incomprehensibly, a gray commons logo. I hover over the icons and wait a few seconds for each one to tell me what they do. Evidently the gray megaphone is for me to leave feedback, and when I click on it, a popup explodes in my face that takes me to surveymonkey. Not an elegant text box under the icon, a new tab, or god forbid, a link to this RFC. A popup.
Then I click on the the gray export icon. An oversized flyout appears (though at least it isn't a popup). There is a green "Download" button that seems to have been lifted from an ancient version of vine. And at least vine made the two lobes of its buttons the same size, unlike media viewer. Below the green button is some gray "view in browser" text that is accompanied by a sharp gray Windows 8 style picture icon that clashes with the rounded foamy vine button.
Then I go to the gray commons logo and click it... and... literally nothing happens. Evidently the first click just makes the other flyout dissapear. When I click it again, it takes me to the file page. Apparently whoever designed the thing wasn't creative enough to think of a way to represent the file page (or maybe just, idk, replace the vague icons with text??) so they just stuck a commons logo there.
Below the parking spaces are three lines of information, the uploader, the date, and the categories accompanied by three blurry gray icons (pixel alignment??). Beneath that is the file usage, with three pages listed for commons and three listed for other wikipedias. Of course the three that are listed for the other wikis are almost always going to be from the Arabic wikipedia because they decided to alphabetize it. Not the English wikipedia, even though I specified my user language as English in my preferences. To find the english usage you have to click on the "view all uses" link.
On the left is the image description. Everything seems to be in order, except I notice a small typo in the description. I look for the edit button, but alas, the WMF, so intent on increasing reader–editor conversion and sticking "edit" links, pencil icons, and "did you know you can edit this??" footnotes wherever there is room, has somehow neglected to include an edit button in the one place it might have been useful.
Because whoever designed the thing decided to overlay the gray bar on the image I scroll on the image to see the rest, only to find that apparently it just makes the gray bar grow and shrink (coupled with extremely irritating lag & jumpiness). There is also a gray chevron at the bottom that when I click it does the same thing. Incomprehensibly the gray chevron that points down makes the gray panel go up, and the chevron that points up makes the panel go down. And the up pointing chevron that makes the panel retract doesn't actually make the panel go away or turn transparent or anything. It just makes it smaller. Please please just do what Apple does & make the chevrons more intuitive instead of the morass of contradictions you've made here.
I have also yet to figure out how to zoom in this thing.
By this point I'm actually sick of the media viewer and I just want to go to the actual image page (maybe so I can fix that typo in the image description). I am not likely to understand that Commons logo semitrans white bg.svg equals "File page", & so I click on the image to try and get there, but apparently the whole image is a dead zone, so I instead have to search for a relatively small button that is colored a slightly lighter shade of gray then the jumpy panel that says "More details about this file". Not "File page". Because whoever designed the thing thinks that we all know that Commons logo semitrans white bg.svg equals "File page", they stuck a Commons logo semitrans white bg.svg there, except this time in color. Perhaps for completeness, they saw it fit to tack on a light gray "The free media repository" beneath it for good measure because wherever there is a Commons logo semitrans white bg.svg the tagline has to accompany it.
I click on the button (or the Commons logo semitrans white bg.svg) but literally nothing happens. Evidently you have to click the blue link inside the button to go to the file page, where I can at last do actual work like fix that description typo or something. On the file page I also discover that the image is a featured picture, and that there is a personality rights warning on it. Somehow this was not considered important enough for the media viewer's gray panel (while I am so glad that they thought I might want preformatted HTML code to embed the image on the website I apparently run, or that they thought it might be important for me to know that the image is being used on ويكيبيديا:ترشيحات الصور المختارة/صور مرفوضة/أرشيف).
Now whoever made this contraption might say that the media viewer's only use is to provide basic information about the file, and if you really needed the other information (like idk, the copyright tags??) you should just go to the file page. I wonder then—why do we even need the media viewer???. Most of what we Commons editors do is not oogling pictures, but uploading media, categorizing it, editing descriptions, and inspecting images at various zooms (like at FPC). The media viewer just slows us down.
Even though I am a designer I don't know if I could create anything better than the current media viewer, but I expect more from the WMF design team. As a designer I can clearly see that there are many things wrong with it which means that either they have no clue what they are doing, or, they are good enough designers to see all the flaws in the media viewer, and consciously deployed what they knew was a flawed product anyway.
I can't even.
—Love, Kelvinsong talk 19:30, 5 July 2014 (UTC)

BRUTAL.

[Vigilant]

More from the commons RFC

Disabled by default. Back in February, I pointed out some criteria that, to me, seem central in designing the software, and now I think they are also good criteria for evaluating whether or not the software is suitable for being enabled by default. I'll refer to them by number here:

Copyrights and personality rights are not adequately protected. Others have rightly delved into the issues around copyright; but I think the issues around personality rights are far more troubling. We have, in COM:IDENT, a guideline that makes it important that the uploader of a photo of people in private locations clearly assert their belief in the subject's consent. That guideline does not require them to use a template, and the template that currently exists for that purpose is a very incomplete tool. So just pulling in the template, when the important information is often communicated in other ways, is inadequate. But copyright and personality rights need to be dealt with in a way that honors the rights-holders -- not merely one that complies with the letter of the law.
We have not shown reusers a clear path forward. There are many kinds of reuse; one that we care highly about is being able to place an image into a wiki page. With the standard software, with a small amount of experience, a user learns that copying the file name from the top of the image page lets them get what they need; then they can paste it into a wiki page and do any number of things (link to the file, add it to a navigation template or a gallery, create a thumbnail with a caption, etc.) by adding a little more code. Many somewhat-experienced users (like the students in my Writing Wikipedia Articles course) are used to that workflow, and have worked hard to become regular Wikipedia contributors. But with the Media Viewer, the information they need is two clicks further away: first they have to click the "share" icon (and I have no idea what would lead them to guess to click that), and then they have to click "Embed" (again, a word they don't associate with placing a photo on a page). Once they get there, they don't have the simple file name -- they have a string like this: [[File:File_Name.jpg|thumb|Pre-loaded caption, who knows how suitable]]. Unneeded underscores in the file name, and an unjustified assumption that they are looking for the "thumbnail" function, as opposed to any number of other possible uses.
The Media Viewer does not sufficiently expose the strengths and edit-ability of Wikimedia Commons to the end user. Most importantly, the existence of the "Media Viewer" means that a huge proportion of the pages on our projects have been changed from having an "EDIT" button in a familiar location, to having no suggestion whatsoever that readers are encouraged to improve what they find. This is appalling to me, I can't even begin to imagine how this got so far. It is at odds with our top-level strategic priority of increasing participation, full stop.

There are other problems at the strategic level -- it's hard to see how this improves quality from a reader's perspective when it is such a departure from existing design, and it's hard to see how innovation is encouraged in an environment where massive changes like this are implemented without adequate vetting.
This feature needs to be disabled, lest our readers forget that we invite them to join our cause, or that we consider it important to facilitate productive communication among a wide variety of stakeholders around the sharing of content. -Pete F (talk) 23:29, 5 July 2014 (UTC)

I would die of shame if I were the project manager for this turd.
The feedback is cogent, honest and brutal.

[Vigilant]

RFC for en.wp closed.

There is a clear consensus that the Media Viewer should be disabled for both logged-in (section link) and non-logged-in users (section link). Armbrust The Homunculus 10:23, 9 July 2014 (UTC)

There is a clear consensus that the Media Viewer should disabled by default for logged-in users. There was, however, no discussion about the the conditions, under which it should be re-enabled. Armbrust The Homunculus 06:46, 9 July 2014 (UTC)

I'm going to guess "never" was the predominate opinion.

Should be a good show...
I mean, those developers worked so HAAAAAARD on it...
Can't figure out why the proles didn't eat their gruel...

[Vigilant]

Going down 10-1 on commons as well.

It makes you wonder if the visible people in engineering at the WMF are taking bad orders from above them or if they are really as blind as pile of hedgehogs ... in a bag.

[HRIP7]

The German RfC on the Media Viewer is still in the drafting stage, but has now reached the requisite number of supporters to run.

[Vigilant]

The German RfC on the Media Viewer is still in the drafting stage, but has now reached the requisite number of supporters to run.

If en.wp, de.wp and commons all disable MediaViewer, what percentage of the total number of editors will have this disabled?

[thekohser]

The German RfC on the Media Viewer is still in the drafting stage, but has now reached the requisite number of supporters to run.

If en.wp, de.wp and commons all disable MediaViewer, what percentage of the total number of editors will have this disabled?

Without bothering to check the actual data, I'd guess roughly 60%?

[Vigilant]

The German RfC on the Media Viewer is still in the drafting stage, but has now reached the requisite number of supporters to run.

If en.wp, de.wp and commons all disable MediaViewer, what percentage of the total number of editors will have this disabled?

Without bothering to check the actual data, I'd guess roughly 60%?

That leaves them in high mix/low volume territory.
Lots and lots of tiny wikis with different languages but not many users.
High support overhead with difficult communications and lowered chance of closing an issue.


Perfect.

[Randy from Boise]

The German RfC on the Media Viewer is still in the drafting stage, but has now reached the requisite number of supporters to run.

If en.wp, de.wp and commons all disable MediaViewer, what percentage of the total number of editors will have this disabled?

Without bothering to check the actual data, I'd guess roughly 60%?

Here's Pete F. on Mediawiki:

Active users of Wikipedia within the EN (English) or DE (German) projects outnumber all other Wikipedians combined. Within the eight languages surveyed, EN and DE combined represent 76% of the active user base for Wikipedia and 80% of users across all MediaWiki projects. MediaViewer is an image tool and (of projects in those eight languages) EN and DE account for 89% of the Wikipedia images (88% across MediaWIki).

link

This doesn't include the smaller language WPs.

tim

[Vigilant]

The German RfC on the Media Viewer is still in the drafting stage, but has now reached the requisite number of supporters to run.

If en.wp, de.wp and commons all disable MediaViewer, what percentage of the total number of editors will have this disabled?

Without bothering to check the actual data, I'd guess roughly 60%?

Here's Pete F. on Mediawiki:

Active users of Wikipedia within the EN (English) or DE (German) projects outnumber all other Wikipedians combined. Within the eight languages surveyed, EN and DE combined represent 76% of the active user base for Wikipedia and 80% of users across all MediaWiki projects. MediaViewer is an image tool and (of projects in those eight languages) EN and DE account for 89% of the Wikipedia images (88% across MediaWIki).

link

This doesn't include the smaller language WPs.

tim

That can't be right...commons??

[thekohser]

Within the eight languages surveyed, EN and DE combined represent 76% of the active user base for Wikipedia and 80% of users across all MediaWiki projects.

Somehow in Pete's world, a number of active users divided by a small number (active users of Wikipedia) results in a lower percentage than if you divide by a larger number (users of all MediaWiki projects). I'm not sure how that's mathematically possible.

[Vigilant]

Within the eight languages surveyed, EN and DE combined represent 76% of the active user base for Wikipedia and 80% of users across all MediaWiki projects.

Somehow in Pete's world, a number of active users divided by a small number (active users of Wikipedia) results in a lower percentage than if you divide by a larger number (users of all MediaWiki projects). I'm not sure how that's mathematically possible.

It IS Pete Forsyth we're talking about here.
I'm sure his clients get their money's worth.

[Kelly Martin]

Within the eight languages surveyed, EN and DE combined represent 76% of the active user base for Wikipedia and 80% of users across all MediaWiki projects.

Somehow in Pete's world, a number of active users divided by a small number (active users of Wikipedia) results in a lower percentage than if you divide by a larger number (users of all MediaWiki projects). I'm not sure how that's mathematically possible.

The 76% may be (EN + DE Wikipedias)/(all Wikipedias) and the 80% (EN + DE projects of all sorts)/(all projects). The EN and DE Wiktionaries, Wikisources, and so forth are far and away the most active within their respective project categories, probably even more so than with the Wikipedia category, so that would explain his numbers.

[Vigilant]

What doesn't make sense is

Active users of Wikipedia within the EN (English) or DE (German) projects outnumber all other Wikipedians combined. Within the eight languages surveyed, EN and DE combined represent 76% of the active user base for Wikipedia and 80% of users across all MediaWiki projects. MediaViewer is an image tool and (of projects in those eight languages) EN and DE account for 89% of the Wikipedia images (88% across MediaWIki).

Commons has a ton of pictures.

If commons, en.wp and de.wp opt out, and en.wp and de.wp already have 80% of the pictures on wikis, does the MediaViewer end up serving < 1% pictures viewed on WMF servers?

Is it the new VisualEditor(7 out of the last 5000 edits on en.wp)?

How much have each of these projects cost the WMF to implement?
How much to complete and support these projects over their lifetimes?
To what end?

[Randy from Boise]

How much have each of these projects cost the WMF to implement?
How much to complete and support these projects over their lifetimes?
To what end?

To the end that WMF can say, "We did A and B and C this year.... Now give us more money!!!"

RfB

[Vigilant]

Here we go!
http://lists.wikimedia.org/pipermail/wi ... 73206.html

This discussion has closed on English Wikipedia:
https://en.wikipedia.org/wiki/Wikipedia ... e_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/Comm ... re_feature

Thanks,

Pine

Poor Media Viewer!

[Vigilant]

Ruh Roh!!
http://lists.wikimedia.org/pipermail/wi ... 73211.html

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

Always fine to do a self-selected survey on a tiny subset if the numbers come out how you want them though.
Does this mean that ANI is going to be cemented over?

Also, all you "editors" can go rightly fuck yourselves!
We're not making this encyclopedia for you, you drones!
We're making an encyclopedia for people who never contribute!

This is why WMF engineering should have all of their public access revoked immediately.
Completely unprofessional behavior.

[Vigilant]

And more!!
http://lists.wikimedia.org/pipermail/wi ... 73216.html

This is exactly why there is an opt-out for the feature.

We don't expect everyone to like everything we make. That's a reality. So
take 10 seconds to go to your preferences and disable it, and you'll never
see it again.

Dan

WMF Engineering, the grift that keeps on giving!!

That's not what they want you smug, little shit.
They want the interface that worked. You know, the one before you guys decided you needed the "Deskana and Other Shitbirds Full Employment Act"?
Here's the "community's" collective response to your "feature"...



What makes me chuckle is that you guys think that your MediaViewer project is somehow MORE SPESHUL than VisualEditor.
VE got punted. They cried a bit but soldiered on.
You guys are in full on denial.

I've included a picture to help you understand exactly how sympathetic everyone is to your plight.




In summary, your shit stinks and nobody wants it.

[Vigilant]

Balls!
http://lists.wikimedia.org/pipermail/wi ... 73217.html

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

Keep in mind that nobody asked for this "improvement".
Keep in mind that your "survey" has been shown to be fraudulent.
Keep in mind that WMF engineering has a long history of boondoggle projects.

[Vigilant]

Double down.
http://lists.wikimedia.org/pipermail/wi ... 73219.html

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

Someone needs to muzzle that dog.
He's now trying to say that the RfC is invalid because "power users" can just do things the way he thinks they should...

And Mo:eller drops by to fan the flames!
http://lists.wikimedia.org/pipermail/wi ... 73220.html

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

You've missed the point Herr Erik.
Nobody wants this ... abomination.

Good thing David Gerard is here to help!
http://lists.wikimedia.org/pipermail/wi ... 73221.html

OTOH, typical mind fallacy is rampant everywhere and the results of an
actual decent user survey would probably surprise everyone.

- d.

Allow me to summarize everyone's feelings here, David.

[Hex]

In a development that will surprise nobody:

"The Wikimedia Foundation appreciates feedback about features we develop, and we respectfully acknowledge this group’s proposal to disable Media Viewer on the English Wikipedia. After carefully reviewing this proposal, we recommend that Media Viewer remain enabled on the English Wikipedia"

[Vigilant]

In a development that will surprise nobody:

"The Wikimedia Foundation appreciates feedback about features we develop, and we respectfully acknowledge this group’s proposal to disable Media Viewer on the English Wikipedia. After carefully reviewing this proposal, we recommend that Media Viewer remain enabled on the English Wikipedia"

I was just going to post that.

Response to the Media Viewer RfC

Thanks for sharing your comments about Media Viewer.

Can't you guys just shut up while we get paid?

The Wikimedia Foundation appreciates feedback about features we develop, and we respectfully acknowledge this group’s proposal to disable Media Viewer on the English Wikipedia.

But we don't care what you plebes have to say.
Suck it.

After carefully reviewing this proposal, we recommend that Media Viewer remain enabled on the English Wikipedia, for a number of reasons:

Are you kidding me?!
You have no power here!

We believe that an RfC of this type is not representative of our much wider user base.

Why we believe this is a complete mystery shrouded in a fraudulent, biased "survey". So there!

Readers in particular are not represented at all in this kind of discussion, and they are a key user group for this feature.

You "editors" can just go jump in the lake.

Media Viewer was developed with extensive community guidance from a more diverse user base for over a year, through beta testing, online discussions, usability studies and other feedback channels.

But we're not gonna show you the data.
It's secret, from the lord and written on golden plates that only we can see...in a bag.

Media Viewer provides important benefits to users:

And not a few dollars to otherwise unemployably incompetent software engineers!!

Larger images: this tool shows images more prominently, with a single click.

But not full screen!

Faster image load: files are shown twice as fast as the previous solution, since you don’t have to go to a separate page.

But only after loading the hugely oversized Media Viewer!!
Slower for the one picture you gave a shit about!

Easier browsing: more users click on the next and previous buttons than on thumbnails, increasing overall image views.

But not for people who already know how to use a mouse!

Better use of space: less scrolling is required to find information, due to a more compact layout.

But we take away access to all of your native browser's functionality!
And you can't go "back history"...it's apparently just too damn hard!

Other factors were considered in reaching this decision:

We do what we want!
You don't know us!

Media Viewer is a central part of our strategy and vision to modernize our multimedia software and user experience.

I've got a mortgage!

As recognized by the Wikipedia:Consensus policy, software development is not subject to the same policies which bind English Wikipedia editors.

Never mind that VisualEditor kerfluffle!

Users who do not want this feature can easily turn it off, and only a small percentage of English Wikipedia users have chosen to opt out so far. We encourage users who don't like Media Viewer to disable it.

Just not on an entire wiki!

Overall, we believe that Media Viewer’s benefits far outweigh its downsides.

Which implies that we really don't give a shit about what the people who took the time to sign the RfC think.
But, we knew that. Just nice to have it in writing.

And while the feature still has some limitations,

You misspelled, buggy, slow, awkward, annoying. Happy to help.

we have collectively identified practical ways to improve it over time.

We all have mortgages too!

We deeply appreciate your help in making this tool better

Go away, silly English Knnnniguts!

and we hope that more users will come to value this feature as a result.

Or we shall taunt you a second time!

Thank you so much for your feedback. Fabrice Florin (WMF) (talk) 17:45, 10 July 2014 (UTC)

Fetchez La Vache!!

My take on how this is playing out.

[Vigilant]

Mutiny, I say! Mutiny!

Decision for local administrators

As far as I can tell, putting the following code into MediaWiki:Common.js should do the trick:

mw.config.set("wgMediaViewerOnClick", false);

This makes the decision to enable or disable Media Viewer within the purview of local site administrators. There are a variety of ways to make this code conditional, such as only applying it to users who use a particular skin (Vector, Monobook, etc.), users who are in a particular user group (autoconfirmed, sysop, etc.), users with a specified edit count or account registration date, and much more! Hope that helps. --MZMcBride (talk) 19:15, 10 July 2014 (UTC)

[Vigilant]

Thanks @MZMcBride: - I've now done that. Testing to make sure it worked right. Please let me know if I got anything wrong. -Pete (talk) 20:04, 10 July 2014 (UTC)

And I've reverted it. Please see Fabrice's explanation above.--Eloquence* 20:10, 10 July 2014 (UTC)

You've reverted an administrator's action which was required to implement the lawful closing of an RfC...

Time for you to lose your sysop bit, Erik.

Ruh ROH!!
https://en.wikipedia.org/wiki/User_talk ... dia_viewer

Media viewer

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)

WMF doesn't have authority over individual wikis.
That's been decided.

You have a constitutional crisis on your hands now.

Where is Lila in all this?
Is she really going to let this wannabe jackboot run the show?

[Vigilant]

I cannot WAIT to see what happens when commons decides to get rid of it!

[Poetlister]

Decision for local administrators

As far as I can tell, putting the following code into MediaWiki:Common.js should do the trick:

mw.config.set("wgMediaViewerOnClick", false);

This makes the decision to enable or disable Media Viewer within the purview of local site administrators. There are a variety of ways to make this code conditional, such as only applying it to users who use a particular skin (Vector, Monobook, etc.), users who are in a particular user group (autoconfirmed, sysop, etc.), users with a specified edit count or account registration date, and much more! Hope that helps. --MZMcBride (talk) 19:15, 10 July 2014 (UTC)

He's dangerous, that MZMcBride. He knows too much about how things work.

[Anroth]

Tempted to post it at AN, but no doubt someone will put it up there shortly. Not sure what part of office action allows the WMF to do this though.

[Vigilant]

Tempted to post it at AN, but no doubt someone will put it up there shortly. Not sure what part of office action allows the WMF to do this though.

Please note: Erik did not call it an WP:OFFICE action. He called it a WMF action.
I don't know what that actually means. Never heard of it.

Perhaps someone could ask him to clarify where his authority to threaten an admin with emergency desysop stems from?

[Hex]

Ruh ROH!!
https://en.wikipedia.org/wiki/User_talk ... dia_viewer

Media viewer

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)

What the actual fuckadoo.

[Hex]

Perhaps someone could ask him to clarify where his authority to threaten an admin with emergency desysop stems from?

Done.

Edit: Link.

[Anroth]

Tempted to post it at AN, but no doubt someone will put it up there shortly. Not sure what part of office action allows the WMF to do this though.

Please note: Erik did not call it an WP:OFFICE action. He called it a WMF action.
I don't know what that actually means. Never heard of it.

Perhaps someone could ask him to clarify where his authority to threaten an admin with emergency desysop stems from?

Good point. If its not OFFICE he has no authority to do it.

[Kelly Martin]

Erik is basically asking people to go crying to Lila over this. The problem with that, for him, at least, is that they just might, and she just might listen.

As to his authority, it's because he's Erik. What more do you need to know?

[Anroth]

Ah fuck it, the arrogant prick. To the battlements!

[Kelly Martin]

The Wikimedia operations team reports to Erik. If he orders them to desysop someone, they have to do it. That gives him all the authority he needs. The fact that the community doesn't acknowledge such authority is irrelevant, because the community has no ability to resist anything that happens by WMF edict.

[Anroth]

The Wikimedia operations team reports to Erik. If he orders them to desysop someone, they have to do it. That gives him all the authority he needs. The fact that the community doesn't acknowledge such authority is irrelevant, because the community has no ability to resist anything that happens by WMF edict.

Well yes, thats rather the point. He has the authority to do so. But he has to act like a dictator to do it. Which isnt how Wikipedia is supposed to work. Digging his own grave in the long run with that one.

But depressingly the admin corps (and by extension the community) do actually have the ability to stand up to the WMF en-masse if they want to. One of two things happen: All the admins get de-sysopped. You can imagine the chaos that would cause (and how the 'Hasten the Day' crowd here would cheer), my god, think of the bots.... Or Erik eats humble pie and does what he is told.

Granted getting a large enough group of admins to understand collective action would be like herding cats...

Still, how on earth is Erik still employed? Serious question - any of my peers in development would have been quietly let go or shuffled off into technical support (read-cleaning keyboards) by this time.

[Kelly Martin]

But depressingly the admin corps (and by extension the community) do actually have the ability to stand up to the WMF en-masse if they want to.

Do they, really? Just how do they "stand up" to the WMF? It's not as if they can take their business elsewhere.

[Anroth]

But depressingly the admin corps (and by extension the community) do actually have the ability to stand up to the WMF en-masse if they want to.

Do they, really? Just how do they "stand up" to the WMF? It's not as if they can take their business elsewhere.

They have the ability to, if they want it bad enough. Not sure its yet, but at some point they will. Its just a matter of time. As the admin pool drops, the core left are going to be more of one mind.

[Vigilant]

But depressingly the admin corps (and by extension the community) do actually have the ability to stand up to the WMF en-masse if they want to.

Do they, really? Just how do they "stand up" to the WMF? It's not as if they can take their business elsewhere.

"Why was VisualEditor different" is the question I want answered?

[Vigilant]

From WP:AN

I'm sorry if my message to Pete came across as heavy-handed. I wanted to be clear that we're not going to disable this feature, as per Fabrice's response to the RFC, and that applies to changes implemented in site JavaScript/CSS as well. But you're right that an explanation without a warning would have sufficed.--Eloquence* 00:10, 11 July 2014 (UTC)

Screw you guys!
We don't care what you want, no matter how many people want it.
Eat our collective shit, "community".