Extension talk:MultimediaViewer/About/Archive05

Requests for Comments: Action Pending

So, the links to the RfCs on Wikipedia itself (http://en.wikipedia.org/wiki/Wikipedia:Media_Viewer/June_2014_RfC) and Commons (http://commons.wikimedia.org/wiki/Commons:Requests_for_comment/Media_Viewer_software_feature) seems to have been archived, mistakenly no doubt. So I repost them here.

Please would those representing or employed by the WMF care to state here what action is being taken as a result of those RfCs and what is the expected implementation date? I wish to point out that both RfCs show overwhelming consensus that this "Media Viewer" feature should be disabled by default for both logged-in and non logged-in users.

Update: Ah, I see what they have planned, you won't guess it: another survey. Right. Keep doing surveys until one of them gives you the result the result you want. I despair. Funny thing is I could only find that link via Google (and btw the first Google auto-complete suggestion for "wikipedia media viewer" is... "disable"). As soon as I saw the link title I smelled bullshit. This is a complete piss-take, gents.

Least astonishment

https://en.wikipedia.org/wiki/World_War_II#mediaviewer/File:World_War_II_Casualties2.svg

This breaks that principle very badly. Going from a graph in a click or two to full size images of people digging their own graves, or bodies from a concentration camp is not a good thing.

Rich Farmbrough 19:04, 17 July 2014 (UTC).

If I open en:World_War_II#Impact I can see all of the pics in plain sight anyway. Am I missing something? --Elitre (WMF) (talk) 09:13, 21 July 2014 (UTC) PS: to make myself clear, in that paragraph I can see the graph and then the pictures you mention right below it. I don't really need to see them full-screen to know what they're about, etc. A bug could be filed requesting that some system is implemented to exclude some pictures from slideshow in MV (which ones? how should this be done? anyway, if this was your request, please let me know!). My point here is merely that this is not how it currently works for slideshows on Commons, for example, and that a similar request would not meet some communities' consensus. --Elitre (WMF) (talk) 09:24, 21 July 2014 (UTC)

PPS, I also checked but couldn't find anything related, so we'd file a new bug. Thanks for your feedback, Rich. --Elitre (WMF) (talk) 09:40, 21 July 2014 (UTC)

In my case I was only interested in the graph, not the other images. I do not recall if they were below the fold or not, nor how I came to navigate to them, I rather think I did not intend to move to the subsequent image at all, but possibly I was hoping for more data, or made a category/navigation/mouse error of some kind - I may have navigated away from the second image in a hurry to the third! HCI is, of course, a complex issue. Rich Farmbrough 15:01, 11 August 2014 (UTC).

I would point out that a following iteration was considering adding small preview images, like a gallery mode. Not sure if it is intended only for galleries, but it might be an interesting method to at least partially solve the 'least astonishment' problem you experience. TheDJ (talk) 17:37, 11 August 2014 (UTC)

Make Media Viewer image clickable

Tracked in Phabricator
Task T70203

Normally, I could open the description in new tab with middle-click, and/or open image in new tab with middle-click from the description.

Now, I can open description in new tab, but after opening Media Viewer in the single tab, I can no longer open image in new tab at all. The "open image" icon cannot be middle-clicked and is far too small compared with normal behavior.

--50.136.155.136 23:14, 17 July 2014 (UTC)

The real solution is to restore the clickability of the image, instead of relying on the hard-to-reach icon when trying to view full-size. Extra effort, more of the "modern" "flat" fad.

--50.136.155.136 04:28, 22 July 2014 (UTC)

There is another reason for the MMV behavior, we also have files that are well over multiple megabytes large. Not everyone appreciates downloading those in full either. But I suggest we should find some middle ground there based on the file's properties. TheDJ (talk) 13:10, 31 July 2014 (UTC)

Show categories

Media view is ok, but it would be great if it couls show in the image page the categories link, to surf quickly in case you opened it for mistake. Would be very appreciated by advancer users (like me, uh) --Sailko (talk) 10:54, 18 July 2014 (UTC)

Sailko, it already does that. Open an image, scroll down and look to the right: there's a grey tag icon, and some categories are listed there. See also bug 62277. --Elitre (WMF) (talk) 09:29, 21 July 2014 (UTC)

Grazie elitre --Sailko (talk) 18:57, 25 July 2014 (UTC)

Update: Quick access to enable/disable, opt-in/opt-out metrics

Design mockup for a new "Viewing Options Panel” in Media Viewer.

Design mockup for a new "Viewing Options Panel” on a file page.

Hi everyone. We appreciate the ongoing conversation about Media Viewer, and we’ve been discussing practical ways to address concerns and improve metrics used to establish the default configuration for this tool.

With that in mind, we would like to propose a new feature which we think can address many of the issues you reported here: the Viewing Options Panel would make it much easier to disable (or enable) Media Viewer. This feature would prominently display a ‘cog’ icon at the top right corner of the screen, as shown in the thumbnails to the right — and in this rough prototype. Clicking on that icon would display a settings panel with two viewing options:

• 'View quickly’ — enable Media Viewer (or keep it enabled)
• 'View all the details’ — disable Media Viewer and show the file page instead

The Viewing Options Panel would let users quickly select the mode that works best for them, switching back and forth to compare them. (Note that Media Viewer already includes a “Disable/Enable’ link, but it is located below the fold and can be hard to find; this new feature would bring it above the fold, where everyone can see it.)

This would make it easier for users to decide for themselves if they want Media Viewer enabled or not. It would also enable us to collect better user data on whether or not this tool is useful -- which can inform our discussions about default state for different user groups. To that end, we plan to track the number of enable and disable events by user group on this existing opt-in/out dashboard (this dashboard now tracks clicks on the “Disable/Enable’ links, which would be replaced by the Viewing Options Panel).

What do you think of this new feature? Does it seem worth developing at this time? Any suggestions for improvement?

We are also considering a controlled experiment on the English Wikipedia. We invite you to comment on that separate proposal on its research page.

Thanks again for taking the time to share your thoughts and feedback on Media Viewer. Your comments are really helpful to us, and we look forward to working with you in coming days to find a resolution to your concerns. To be continued, Fabrice Florin (WMF) (talk) 16:31, 18 July 2014 (UTC)

@Fabrice Florin (WMF): Do you suffer from some kind of impediment that prevents you from ever seeing any feedback which does not suit your agenda? Given your behaviour on this whole "Media Viewer" thing (a hint for you: that's called a web browser and we have had them since '93. No need to reinvent the wheel), I can only conclude that you are being wilfully dishonest and lacking in courage and integrity, aside from simple professional competence. Yes, this is meant as an outright insult because you, Fabrice, are only deserving of the same kind of respect that you show to us users and collaborators, that is to say: none at all.

Formally, there is consensus on English Wikipedia that this tool should not be enabled by default. Informally, there appears to be strong consensus on Wikimedia Commons to that effect, and similar sentiments expressed strongly on this discussion page. There is also relevant discussion emerging on the German Wikipedia. Until there is some action on the part of WMF to reduce the intrusion of this inadequate software into the daily experience of many millions of readers, I have no interest in discussing small tweaks to the software. If and when it is changed to "opt-in," I will be happy to discuss improvements. -Pete F (talk) 17:41, 18 July 2014 (UTC)

I agree with Peter F. The consensus for "opt-in" is strong. I used to send links to Wikipedia pages to people who are not very computer literate. Now they are confused by the Media Viewer intrusion and are not able to read the page and look at full size images as they normally did in their browser. You guys at WMF are living in an ivory tower and are not aware of the real Internet world. Users and contributors will thank you when you make this thing opt-in and you will not lose face in doing that.--Michel le tigre (talk) 18:57, 18 July 2014 (UTC)

This would be more intuitive to visitors. Right now they possibly do not know what Media Viewer is. With the layout graphics, it more becomes obvious what MediaViewer is. I can't assess whether it's worth though; if it fits your development strategy, implement it. -- Rillke (talk) 22:05, 18 July 2014 (UTC)

Please do this. In my opinion, it would help a lot with the concerns some community members on enwp have, and switching with the Viewing Options Panel seems to me to be a better and less permanent way to disable Media Viewer itself. However, I have a question: if Media Viewer is disabled via the preferences, will the settings button still show up on the "regular" image view? I hope it will. APerson (talk) 19:28, 11 August 2014 (UTC)

Bug - Out of place quotation box on topleft of page

After loading the Wikipedia main page's featured image in Media Viewer and then closing it by clicking the X button on the top-right, the v-shaped corner of a quotation box appears in the top-left corner of the page, near the Wikipedia logo. LokiClock (talk) 23:34, 19 July 2014 (UTC)

Hi LokiClock, thanks for your feedback! I couldn't reproduce this issue with Chrome or Firefox, though. Can you please share info about your browser/skin/operating system? Thanks, --Elitre (WMF) (talk) 09:38, 21 July 2014 (UTC)

I think LokiClock refers to bug #67894. --Miss-Sophie (talk) 10:35, 21 July 2014 (UTC)

Truly dreadful

Please nuke this feature from orbit, it is utterly dreadful and was not needed in the first place!--137.44.100.1

I totally agree. I like to zoom in on pictures and manipulate it, which I was perfectly capable of doing before this feature. Like I said when you made a mobile version of Wikipedia for iPad, this is completely unnecessary and it's absolutely awful. Please get rid of it because it's pointless. --147.197.251.157 18:23, 26 July 2014 (UTC)

I also agree. This is a feature that is detrimental to the use of Wikipedia. I have no idea why anyone would want the media viewer over the old way of presenting content. When I ended up with the Media Viewer, the first thing I did was desperately look for the way to turn it off, hopefully permanently (although it did turn on for me again today for some reason.) This is apparently the pet project of someone important at Wikipedia given it's still around despite the largely negative response I have seen. Well whoever they are, they need to wake up and stop wasting time and resources on this. --76.10.150.197 5:35, 29 July 2014 (UTC)

"We invite you to test Media Viewer as well." The hell you say—you didn't invite me to test it; you inflicted it on me, and forced me to squander 15 minutes of what might've been productive editing time trying to turn this thing off. I am not interested in "a richer multimedia experience"; I'm trying to add Commons photos to WP articles in an efficient fashion. This "feature" isn't designed for, or useful to, working WP editors; it's for the sort of people who like to look at funny-cat slide shows with Kenny Loggins soundtracks. I trust that I've shut it off, and that it'll stay shut off; and I'll be exceedingly vexed if it's again turned on by default. — Ammodramus (talk) 13:06, 2 August 2014 (UTC)

You can disable media viewer by scrolling down and reading the last line. If you have something specific you dislike, it's useful to mention rather than purely emotional response. Gryllida 00:47, 3 August 2014 (UTC)

It has no redeeming features. It looks like the end result of a board room meeting. 84.45.209.62 21:59, 8 August 2014 (UTC)

The interface it replaces was simple/functional/intuitive. The Media View is none of these. I don't like the way important information is hidden off screen. I have no idea how to get an image of a different size if I want to save a copy. It totally reminds me of the nasty mobile view that showed up on my iPad before I learned how to turn it off. Just because the latest W3C standards allow more interface chrome doesn't mean it's a good idea to add it... especially as default. 130.107.14.108 21:15, 15 August 2014 (UTC)

I agree wholeheartedly with the distaste expressed for this new feature. When I click on an image, I expect to be taken to the file page or the Wikimedia Commons page for that image. There I can easily see all the relevant info without having to click several more times to see the info in a piecemeal fashion. Disabling the media viewer seems to do nothing. It's still there, annoyingly. The media viewer offers no advantages whatsoever to the traditional image file page. Different != better. New != better.32.218.32.196 21:21, 22 August 2014 (UTC)

I've never seen "!=" used to express your meaning, I think you meant "Different ≠ better. New ≠ better." it's called an unequal sign and unfortunately there's no altcode for it (on PC's anyways,I think it's alt +/= on MACs) but you can find it in the character map or simply copy/paste it from google.

en:Equals_sign#Not_equal. :) --Elitre (WMF) (talk) 13:00, 2 September 2014 (UTC)

Doesn't work, tried it several times before--75.142.224.167 15:52, 2 September 2014 (UTC)

Do you mean that Media Viewer doesn't work for you, you can't launch it? --Elitre (WMF) (talk) 15:57, 2 September 2014 (UTC)

I agree wholeheartedly with the OP. It's pointless, gimmicky, annoying and unimaginative! 5.124.129.40 00:15, 5 September 2014 (UTC)

I completely agree with 137.44.100.1, 147.197.251.157, 76.10.150.197 and 5.124.129.40. It is just as Horrible as they say, and I want it out of the Wiki Universe. LaG roiL (talk) 10:17, 7 September 2014 (UTC)

I agree whith OP too, this feature is imposed and not practical, ugly and annoying. Get rid of it or at least make the old one default.--Iagocasabiell (talk) 09:50, 23 September 2014 (UTC)

Upright formated image is shown in landscape format

This upright formated image rotates in Media Viewer and is then shown in wrong landscape format. --Miss-Sophie (talk) 10:43, 21 July 2014 (UTC)

Added here. Also, thanks for the catch above! Best, --Elitre (WMF) (talk) 13:08, 21 July 2014 (UTC)

How to exclude images within a template like infoboxes?

How can I use <span class="metadata">[[File:Foo.jpg]]</span>, to exclude a flag symbol in an infobox template from being displayed in Media Viewer? It doesn't work, since the flag is included via a template itself, not in the form [[File:Foo.jpg]]. Would one have to change the template? Other images in this infobox are included as something like this:

• parameter = image.jpg

--Miss-Sophie (talk) 13:14, 21 July 2014 (UTC)

Hi, this was discussed at length in media-related mailing lists, and I believe it was also implemented as per this Mingle card. If the noviewer parameter shouldn't work (I haven't tested it yet), we can ping my colleague Keegan or someone else from the team to tell us more about this. Thanks! --Elitre (WMF) (talk) 13:26, 21 July 2014 (UTC)

I tried to follow these instructions and according to them I should use <span class="metadata"> in this case. --Miss-Sophie (talk) 13:43, 21 July 2014 (UTC)

Yeah, but the case is probably not covered there? I think infoboxes do not accept the syntax including square brackets. User:Tgr (WMF) surely knows :) --Elitre (WMF) (talk) 13:59, 21 July 2014 (UTC)

That was my point. The syntax is different, so I don't know, what to do. I suppose, one would have to change the template, would have to add the <span class="metadata"> there? But I'm quite unexperienced with editing templates. --Miss-Sophie (talk) 14:22, 21 July 2014 (UTC)

Hard to tell without seeing the template. --Tgr (WMF) (talk) 20:20, 21 July 2014 (UTC)

I'm guessing something like en:Template:Infobox_country#Examples, Tgr (WMF). I believe many of them work this way. Clearly this is not the correct syntax in this case :) --Elitre (WMF) (talk) 12:56, 22 July 2014 (UTC)

@Elitre (WMF): I don't understand. What does the "class=metadata" piece accomplish? Is the code the "correct syntax" with or without it? Does the correctness have to do with how MV behaves, or something else? -Pete F (talk) 14:56, 22 July 2014 (UTC)

I don't understand why those would have to be hidden in the first place, they seem part of the content to me... But if you do hide them, they would need to be hidden with the noviewer strategy and NOT the metadata strategy, and it would have to be done by changing the implementation of Template:Infobox country. TheDJ (talk) 15:01, 22 July 2014 (UTC)

Hi Pete. According to this page, it might be used in edge cases when you need to disable MV on some pics. However, this Mingle card says something slightly different. It seems to me that the user guide doesn't cover the case where the image is located in an infobox, but I might be wrong (I'm not in the MV team), so one of them will ASAP explain all of this :) TheDJ, it might be that Miss-Sophie is actually trying to hide non-SVG, low-quality icons which might look bad in MV? It's just a guess, she can tell us better. Best, --Elitre (WMF) (talk) 15:05, 22 July 2014 (UTC)

The syntax that works is probably Flag of Cameroon.svg{{!}}class="noviewer" but dealing with this inside the parameter value is a really bad idea; the infobox should be changed. (Although personally I agree with TheDJ that these should not be hidden, esp. the coat of arms which is completely unreadable in the size used in the infobox.) Like this, for example (test). --Tgr (WMF) (talk) 18:45, 22 July 2014 (UTC)

I would guess Miss Sophie might be talking about small icons/insignias, eg, at en:Winston Churchill, the image en:File:UK-Army-OF4.gif (in his infobox) shows up in the slideshow (it's part of en:Template:Infobox officeholder).

All of the separate flag icon templates should also be updated with the correct fix (which I believe is the |class=noviewer option). Eg. At enwiki, that'd be all the templates covered by Wikipedia:WikiProject_Flag_Template. (but I'm not sure) –Quiddity (talk) 19:13, 22 July 2014 (UTC)

Okay, to stop all the guessing ;-)
Quiddity's thoughts about what I might be thinking of go into the right direction. I don't think - and personally was very confused, when I stumbled over this image in the slideshow - the little England flag from the band infobox in this article should be displayed in MV. The help page doesn't give a hint about what to do in this case, where the synax is different (template), and suggested earlier explicitely for flags and small icons to use the metadata class to exclude those images from MV. --Miss-Sophie (talk) 20:06, 22 July 2014 (UTC)

schaltet den Mist bloß ab

Man wird von de.wikipedia.org hier hergeleitet zum Diskutieren, hier ist aber mal wieder alles Englisch. Wer hat sich denn diesen Schwachsinn einfallen lassen? Recourcenfressend, bevormundende Technik, nicht mehr barrierefrei. Und es ist offenbar der erste große Schritt Richtung Gemeinfreiheit der Inhalte. Lizenzinformationen werden schön klein und im Hintergrund gehalten. Mal sehen, wann man ganz darauf verzichtet. Und dann die Ignoranz von Erik Möller! Was interessieren schon die Leute, die dafür sorgen, daß jährlich Millionen fließen, daß Eloquence & Co. ihren bezahlten Job haben? Denkt mal daran, daß wir Autoren für euer Gehalt sorgen. Aber als Dank scheißt man uns vor den Koffer und macht, was man will. Visual Editor war je wenigstens nur ein Rohrkrepierer, das hier ist aber friendly fire. Es scheint, daß alle Bildautoren vergrault werden sollen. --79.201.211.5 10:54, 25 July 2014 (UTC)

Scheint mir eher, dass man evtl. plant, zukünftig enger mit Yahoo und seinem Bilderdienst Flickr zusammenarbeiten zu wollen. Der Bildbetrachter von Flickr ähnelt auffallend dem von Wikimedia. Aus ähnlichen Gründen dürfte es dann auch nicht erwünscht sein, dass unnötige und nervige JavaScript-Gimmicks von Wikipedia kritisiert werden, denn JavaScript ist schließlich eines der Backbones von Big Data. Sowas generiert sicherlich am Ende stattliche Werbeeinnahmen und würde dafür sorgen, dass sich Wikimedia zukünftig ohne Spendenaufrufe finanzieren kann, außerdem müsste die WMF dann zukünftig keine eigenen Bilder mehr hosten und könnte hier ebenfalls Kosten sparen. Darüber hinaus hätte Yahoo dann auch direkt wieder deutlich mehr Daten über Nutzergewohnheiten (welches Bild betrachtet welcher Typ von Nutzer unter welchen Bedingungen gern?) usw. Ist doch alles sehr praktisch. Einziges "Problem": Vektorgrafiken wären damit völlig aus dem Rennen. Aber das ist sicherlich auch gewollt so, schließlich kann man Vektorgrafiken als Endkunde ja weiterverwenden..

Meinungsbild zum Medienbetrachter in der deutschen Wikipedia

Zur Info: In der deutschen Wikipedia läuft zurzeit ein Meinungsbild darüber, ob der Media Viewer / Medienbetrachter eine Standardeinstellung zum Betrachten von Bildern bleiben soll. --Miss-Sophie (talk) 14:49, 25 July 2014 (UTC)

It's finished, it's clear, but the WMF doesn't bother to listen to it's authors. They made a very arrogant answer in the discussion of the MB, that said, in too many words: Nice that you said something, but we rule, we don't give a f*** about the community. The statement sounds like the usual useless stuff marketing people use to utter once someone found moldy stuff in one of it's packages: meaningless blah-blah, no real intention to do anything, that was said, just calming the waves to go on with business as usual. --Sänger S.G (talk) 15:36, 10 August 2014 (UTC)

Solution for truncated source/author information

Will the new feature for showing the truncated source/author information stay like it is now or is it still in development? I'm asking, because it doesn't work that well, but I don't know, if we are already supposed to criticise... --Miss-Sophie (talk) 21:56, 25 July 2014 (UTC)

It will stay as it is now for the time being. Keegan (WMF) (talk) 15:51, 29 July 2014 (UTC)

Problems when researching

Wikipedia has became an important resource for researching information, and the images inluded are useful for projects, academic essays, and other academic uses which require images from the internet.

With the old version, using images and crediting them was a breeze. You could see if the image is under a copyleft license, whom to credit, and etcetera. Let's see this in action: Media viewer: http://en.wikipedia.org/wiki/Global_warming#mediaviewer/File:2000_Year_Temperature_Comparison.png Normal: http://commons.wikimedia.org/wiki/File:2000_Year_Temperature_Comparison.png

In the media viewer, all it says that it's under CC-BY-SA 3.0 and that it's uploaded by User:Saperaud. This begs several questions:

Is it the user's own work, or is it a copyleft work by someone else?

What is CC-BY-SA anyways? Do I have to click to go to ANOTHER website? Does it mean Cereal Cooker-Bot Yarp-San Arppy?

Who made this picture? Is it someone other than the user?

A speech bubble says "Click to show full author and source", but the speech bubble is aligned with the title, which when clicked does not do anything. Where do I click? Why is the speech bubble not aligned with the button I should click? Why does it sometimes fail to show? Why does it pop up only after I hovered over the correct place, and then show hundreds of pixels away from the correct button?

Where is the file history? What is that icon? Why do I have to hover over everything to see the "See original file" button?

All of these questions were answered with the normal viewer. (e.g. it was by Robert A. Rohde)Jh1234l (talk) 04:51, 31 July 2014 (UTC)

This image in particular is not using any standard templates that are annotated to enable Machine-readable data. That is the problem. It has little to do with MultimediaViewer. (PDF print, mobile, book print etc etc etc would not attribute the image properly either right now). There is more in the world than just webpages, but unfortunately our image file description pages are 10 years out of date in that regard, and it will be a cleanup operation of another 10 years in that regard. TheDJ (talk) 13:16, 31 July 2014 (UTC)

You say: "[...] image in particular is not using any standard templates that are annotated to enable Machine-readable data. That is the problem." Why is that a problem? Rather it shows the strength, robustness, and sound design of the existing system, as it allows the user to be as expressive as he feels necessary, instead of constraining him to whichever set of properties the developer thought (almost always wrongly) would ever be needed. The design of the file description pages is far from ten years out of date: it has matured for ten years and was doing the job all right until some busybody trying to justify getting a salary out of this supplanted it with a piss-poor designed, untested, and not fit for purpose contraption. If this shows anything, it is that wikimedia developers should a) go back to the Bazaar approach and b) probably should not be paid for their contributions, other than in terms of developer cred. This should certainly be the case with those not doing any actual coding (project leaders and the like).

Suggestions for improvement

Despite the problems that others have pointed out, I like the Media Viewer as a reader because it displays a larger photo on one click than does the original system. However, there are two things that need fixing:

1. The View Original File icon in the bottom right corner of the image should move up when you scroll down rather than disappearing (it gets covered up by the information panel).

2. The Use This File icon needs a tooltip when the user has scrolled down. Or better yet, don't make the "Use this file" text disappear when the user scrolls down.

Many thanks for your attention to these. --Albany NY (talk) 16:41, 1 August 2014 (UTC)

For me these icons do not disappear (the 'use this file' label does). --Gryllida 00:45, 3 August 2014 (UTC)

To clarify: I have noticed problem #1 in both Firefox 31 and Chrome 36. --Albany NY (talk) 02:57, 3 August 2014 (UTC)

Install

Hi I'm Representing a wiki community (i would like to keep the community a secret) ,my firend and i just browsing through Wikipedia bahasa indonesia and discover this feature and like to use it in our wiki ,please send the answer to my email ezraelvio@yahoo.co.id on how to install this kind of feature in small wiki 139.193.181.94 18:15, 1 August 2014 (UTC)

Please see Extension:MultimediaViewer for install instructions. (I have also e-mailed as you requested.) Gryllida 00:43, 3 August 2014 (UTC)

MediaViewer should be able to show image description

When I use the left-right navigation to see other images in an article, it'd be nice to see image description (the long one, not the file name). --Gryllida 00:39, 3 August 2014 (UTC)

You mean it would be nice to see it without scrolling? --Tgr (WMF) (talk) 10:34, 3 August 2014 (UTC)

Featured Pictures

Shouldn't there be something that lets you know if the picture you are viewing is a Featured Photo and/or has appeared on Wikipedia's Main Page? It would be kind of nice to have.Ug5151 (talk) 17:25, 3 August 2014 (UTC)

buggy and annoying

I find the new image viewer to be a drag. While it is nice to have an album-like method to view all images in an article, just too much information is being lost. One notable example besides the already-mentioned image descriptions, is the fact that articles often contain layered images, eg. an SVG with additional markings or an additional legend. When I try to zoom in, these are all lost, and I can only see the basically meaningless base image (the lowest layer). I don't know whether the old image viewer did it any better, but this is a major nuisance. I consider the loss of information to be a serious bug. 80.135.158.107 11:01, 4 August 2014 (UTC)

Disableing doesn't work

If I click on disable Media Viewer, as described above, nothing changes. Well, almost nothing changes, the text I just click changes to enable Media Viewer. Wikipedia becomes more and more useless every day. — Preceding unsigned comment added by 193.254.155.48 (talk • contribs) 14:13 4 August 2014

At first I observed the same result, but try purging the cache; that did it for me. In Chrome, that means Ctrl+Shift+R. You'll have to figure it out on your own for any other browser. http://<blacklistedURL>/?q=purge+browser+cache -- D. F. Schmidt (talk) 14:43, 7 August 2014 (UTC)

Please remove! No zoom

Why there is no possibility to zoom? — Preceding unsigned comment added by 79.240.239.187 (talk • contribs) 20:11 5 August 2014

For now you can access the file in its original size by clicking on the icon to the bottom right of the image. A full-fledged zoom feature will be integrated in the next version of Media Viewer. Keegan (WMF) (talk) 17:41, 14 August 2014 (UTC)

Congratulations!!!

Job very well done, lads. Here is a testimonial of a user's reaction to this great tool: http://www.overclockers.com/forums/showthread.php?t=747755 I can see how thorough your user testing was. Awesome, truly awesome.— Preceding unsigned comment added by 109.81.211.129 (talk • contribs) 02:00 6 August 2014

In case anyone missed the sarcasm above, the thread interprets the MV as malware. Rich Farmbrough 03:57, 14 August 2014 (UTC).

I love it

It would be great if you also could make the star become yellow if there are new changes on your watchlist. That way I would not have to bother with e-mail notifications or RSS-feeds. --Spannerjam (talk) 08:51, 6 August 2014 (UTC)

How was this image created?

The technology for producing representative images has improved in two divergent ways: new machines for capturing images from nature are used in many fields of study without being understood by laymen. These technologies include telescopic (e.g. Hubble Telescope), microscopic enhancements, using alternative electromagnet wavelengths (e.g. infrared) or other inputs such as sound. At the same time sophisticated computer-generated artwork can easily be created so that conceptual drawings appear to be simple photographs. Given these factors, explanations should regularly be provided with images. For example in the article on Solar Wind the image showing the heliospheric current sheet looks like a pink flower or ballerina's skirt. There's no explanation of how it was created, so it raises the question: If I could place myself in the right spot (outside the helioshere in space)would I see this pretty pink flower? The reader is left to guess from the context and outside knowledge that this is computer generated art. I would like to see an explanation any time an image does not show what the naked eye could see, including substantial edits to photographs. — Preceding unsigned comment added by Eemstewart (talk • contribs)

This is interesting feedback. I think it indicates that people are not finding the details page and due to the low amount of details that ARE present in the media viewer panel, are expecting to find all the details here. This would support the ideas of removing details from the media viewer, as was presented during WikiMania. TheDJ (talk) 11:24, 9 August 2014 (UTC)

I think having the Expand View button is more than sufficient to provide users access to this tool. It should not be the default viewing option, since it is a hindrance to readers of the Wikipedia, making it less likely they will view and edit the File page. We should do everything possible to encourage readers to edit the Wikipedia, not hinder them from editing it. --Robert.Allen (talk) 18:40, 9 August 2014 (UTC)

Is anything ever going to be done about MediaViewer, or has the diktat of the MWF been accepted?

Some pictures still being stretched

Win 7 / IE 11

The problem with pictures sometimes being stretched to about twice their proper width still is not fixed. 217.44.214.95 19:39, 10 August 2014 (UTC)

@217.44.214.95: , can you please give links to any and all images that have this problem ? They are a very minor subset, so it is difficult to reproduce this problem otherwise. TheDJ (talk) 10:20, 14 August 2014 (UTC)

Unfortunately it does not happen consistently with any particular image. Instead, it happens seemingly at random. If you use MV long enough with Win 7 and IE 11 you will see it (unless there is something locally odd with my installation). Previously I suggested some steps to try to make it happen but I cannot now locate that thread. Try this:

1. Goto http://en.wikipedia.org/wiki/Wikipedia:Featured_picture_candidates/File:Navya_Nair.jpg

2. Click on the picture of the dancing girl

3. In MV, click the "View original file" button

4. Click the Broswer "Back" button

5. Repeat steps 3 and 4, or sometimes 1 through 4, until it breaks or you get tired of trying.

Are you using desktop mode or tile mode? --Tgr (WMF) (talk) 22:22, 15 August 2014 (UTC)

I have never heard of "tile mode" in connection with Win 7. Are you sure you are not thinking of Win 8? 109.147.186.225 01:52, 16 August 2014 (UTC)

Yeah, my bad, I wasn't paying attention. --Tgr (WMF) (talk) 03:01, 16 August 2014 (UTC)

Goals Conflict With User Requirements

On the main page one of the goals given is: « Reduce confusion when users click on thumbnails (bypass duplicate file info page on Wikipedias) ».

Then, the user stories (no doubt collected from actual users, right?), say:

• « find basic information »
• « find more information »
• « view all the file details »
• « add or correct information »

Aside from noting that the existing implementation already did that, to the complete satisfaction of every user, I also note that those requirements conflict with the goal to "bypass duplicate file info".

A terrible, badly thought out and poorly implemented idea

I fear I must write to express my complete disgust with the way this unwanted feature is being imposed on the users of this website. Clearly, as stated elsewhere, it should be opt-in, for those determined to make their experience with the site needlessly complicated and easily ignored by 99.9% of the population. Hopefully you don't just take feedback then ignore it as too often seems to happen with this sort of change.

Accessibility problem

Summary: The Media Viewer creates signficant issues for the accessibility of highly-detailed images. This is a serious issue for people with limited visual acuity.

Explanation: Modern desktop browsers have standardized on a small set of keyboard controls for zoom-in/zoom-out on browsers. On the particular platform I am writing this from, that would be command-plus, command-minus, and command-zero. If you are unfamiliar with these or similar controls, you should investigate more, but those tools are ubiquitous and necessary for looking at details in highly detailed images. This is particularly at issue when small text is contained within the graphic, as sometimes happens in maps.

Example: https://en.wikipedia.org/wiki/Sykes%E2%80%93Picot_Agreement#mediaviewer/File:MPK1-426_Sykes_Picot_Agreement_Map_signed_8_May_1916.jpg is an example taken from en:Sykes-Picot Agreement.

I suggest spending a few moments to experiment with the zoom-in/zoom-out feature on, on our encyclopedia article, on the image with Media Viewer enabled, and the Media Viewer disabled before continuing.

You will note that with the Media Viewer disabled, the only way of using standard browser zoom to examine the detailed text of the diagram is to click through to the image file, and then use command-plus and command-minus.

You will note that with the Media Viewer enabled, there is no direct manner of performing that function whatsoever, the design of MV actually actually shrinks the image in response to a user's request to a zoom-in.

In this example, the problem is not limited to users with visual impairment, and that is bad enough, but the problem will be far more common, blocking the reading of more and more graphical content, so long as Media Viewer's design continues to circumvent browser accessibility features. --Joe Decker (talk) 00:28, 13 August 2014 (UTC)

i'd love as well that browser zoom works, just like in facebook. also not working: esc to leave fullscreen leaves mediaviewer instead of fullscreen --194.230.155.164 05:35, 13 August 2014 (UTC)

All this is on the roadmap. TheDJ (talk) 09:50, 14 August 2014 (UTC)

for the fullscreen issue, I filed bugzilla:69527. TheDJ (talk) 10:05, 14 August 2014 (UTC)

Thanks! Most appreciated. --Joe Decker (talk) 17:01, 14 August 2014 (UTC)

no donation from me

I see that Wikipedia has launched another fundraising drive. Unfortunately the MediaViewer debacle, particularly the MWF's response (or rather, lack of response) to criticism to user complaints, marks the end of my financial support for Wikipedia. I will not be donating this time around, nor will I be donating again in the future.

No donation from me either. Not that they would do any good anyway: see http://www.theregister.co.uk/2012/12/20/cash_rich_wikipedia_chugging/ and http://www.glassdoor.com/Reviews/Wikimedia-Foundation-Reviews-E38331.htm

Buggy

This tool is tremendously buggy on Firefox. It keeps telling me it's trying to run Chrome specific code, which then crashes FF. I know everyone but me (and 2/3s of the rest of the population) loves Chrome. I know that anyone that doesn't use Chrome clearly shouldn't be allowed to use Wikimedia sites. But please, please stop releasing stuff that you've only tested (thoroughly) in Chrome. Please. It's embarrassing for you and hard on us.

I've disabled this extension for myself and won't be re-enabling it. I'm also going to try and get it kicked off my home wiki. It's overly complex, confusing to casual users, and poorly coded. Gopher65 (talk) 00:00, 14 August 2014 (UTC)

@Gopher65: , "It keeps telling me it's trying to run Chrome specific code". Eh, that is unusual, I have not heard a complaint like that before. Would you be able to provide a bit more specific information on exactly what step this problem is occurring, and what the exact message the browser is giving you ? TheDJ (talk) 10:11, 14 August 2014 (UTC)

https://de.wikipedia.org/wiki/Slough#mediaviewer/Datei:Slough_bus_station_berkshire.jpg

Da steht, es sei keine Beschreibung verfügbar, dabei hat die Dateibeschreibungsseite auf Commons soger einen Abschnitt, der "Beschreibung" heißt. Und wenn es tatsächlich keine Beschreibung gäbe, so würde ich in einem Wiki doch erwarten, dass dort ein Link wäre "Beschreibung einfügen" oder so. --84.61.173.122 07:41, 14 August 2014 (UTC)

This should be fixed now, the File description page was not using the {{Information }} template yet, and I cleaned that up. You can easily do this yourself for any images that you run into with similar problems, by enabling the 'Add {{Information}}'-Gadget in your preferences. TheDJ (talk) 10:18, 14 August 2014 (UTC)

IPs don't have "Preferences".

This problem is was nothing more than an example. Did you go through the 22.5 billion files on commons: to be sure that they all use the "Information" template? Why doesn't the Media Viewer encourage visitors to add obviously missing information. Isn't this a wiki anymore? --212.62.66.5 09:48, 22 August 2014 (UTC)

opininion

As a "casual" Wikipedia user I have to say that I'm very disappointed by what has happened here. Also with respect to the discussion/events on the german Wiki. Beside all the obvious technical deficiencies and the miserable introduction, showing great disrespect to the user, IMHO the media viewer is conceptually wrong. It breakes gravely and harmful with the regular Wikipedia layout/experience in an unexpected, inacceptable and severe manner. Therefor we don't want you to improve this. Instead we urge you to stop this project, in order to prevent further damage. Currently, I am not prepared to donate to Wikipedia anymore.--46.127.67.173 23:49, 15 August 2014 (UTC)

... and neither am I! This complete waste of MY money - money, I had to work for before being able to donate it - is such an impertinence... Reading all these more or less direct staff-statements, seeing all these officials comments - never again will I donate money to the WMF! And concerning my editing-acitivities: These 2000 edits I made - let's say 1000 of them for clearing misspelling or substantial errors - they cost MY time - why should I invest the time for another 1000 or 2000 edits? Get back to wikipedias fundamental principles NOW! I don't think that earning ~190.000$ per year for mismanaging this project is one of them! I don't think that unnecessary, expensive script-gadgets are covered by them! Frustrated, S3r0 (talk) 17:20, 20 August 2014 (UTC)

Performance on mobile devices absolutely unacceptable

Viewing images on mobiles devices is a pain in the ass! Wanna have a try? Try this on the iPhone: http://en.wikipedia.org/wiki/Islamic_State_of_Iraq_and_the_Levant#mediaviewer/File:Syria_and_Iraq_2014-onward_War_map.png

Try to zoom in. Try to move the picture while in zoom. Try to find the old versions. Sorry the performance of the feature is absolutely downright unacceptable! And if it's supposed to be opened as an overlay, why does it feed the browser history?

Modern but not KISS

I liked Wikipedias general presentation as it is quite strongly aligned at broad web standards. Except the Media Viewer. So I see no sense in bloating the usability with this stuff unless it gives great benefits, which I cannot see for this one. This could be optional by small icon buttons, that would be cool. But breaking the link-url-page scheme for this one is totally inacceptable, rendering the back button useless etc.

COAInformation Template doesn't work

As mentioned here Media Viewer doesn't show the description when using the COAInformation template.--Marcel Rogge (talk) 11:18, 19 August 2014 (UTC)

Media Viewer strips complex HTML from the description. You can modify the template to display some of the information in plain text, and that information should show up in the viewer. --Tgr (WMF) (talk) 15:50, 19 August 2014 (UTC)

How? I'm not a programmer, can somebody do that modification, please?--Marcel Rogge (talk) 14:40, 20 August 2014 (UTC)

Blow up vector graphics even if their actual size is smaller

Tracked in Phabricator
Task T71237

Example

Hi. I'm not sure if this has been reported already, but Media Viewer should probably increase the size of SVG files so they show ~full-screen. An example is the file opposite: Even though the SVG is only 978 pixel wide, it can safely be blown up to match the viewport's width in Media Viewer (ant therefore become more readable), since it's vector graphics. HTH, guillom 13:23, 19 August 2014 (UTC)

Hate it and feel helpless

I hate this feature. I want a simple web page with simple text and images, not some hip animations and script-heavy "webapps". Yet I feel helpless, and believe soon it will be forced upon everyone, just like when you removed the "nostalgia" theme.

This, a thousand times this. I don't need a viewer in my browser. My web-browser already displays images perfectly well. You are trying to solve a nonexistent problem in a cack-handed way. We don't hate media viewer because it is new and different, we hate it because it is less usable than the commons page that it now obscures.

I totally agree, if something works don't break it. This media viewer is pointless and also ugly.--Iagocasabiell (talk) 09:44, 23 September 2014 (UTC)

just useless and quite unusable with a smartphone

about the political handling... no comment :(

Doesn't work at all...

On my office computer, it simply doesn't work at all. If I click on any image in any article, the following happens:

• First the low resolution image, stretched to fill up almost all the screen height, is displayed on a black background
• Then instead of the low res image, an error is displayed like "Erreur : Impossible de charger les données de la vignette. could not load image from https://upload.wikimedia.org/wikipedia/commons/thumb/c/c4/Robert_Rodriguez.jpg/640px-Robert_Rodriguez.jpg" (image which is correctly displayed if I enter the same URL that is said as not working...)
• If I click on the link to commons, the page on commons is correctly displayed (on this example)
• If I click again on the image, the image is displayed alone (on this example).

Platform: Win XP, FF ESR 17.0.2.

Is this the useless feature that has been forced on dewiki by adding the superprotect right ? I understand why dewiki wouldn't want it in the current status. --NicoV (talk) 12:14, 21 August 2014 (UTC)

Unable to reproduce with FF ESR 17.0.2 on Mac OS X. NicoV can you reproduce the problem on other wikimedia sites ? (other than what I presume to be french Wikipedia ?). I already checked, you don't seem to run any custom JS, any enabled gadget perhaps ? Or a non-default skin ? TheDJ (talk) 12:46, 21 August 2014 (UTC)

TheDJ. Same on all wikimedia sites: enwiki, mediawiki (this one), brwiki (I tried one wiki I've neither visited before, so nothing customized), ... --NicoV (talk) 12:52, 21 August 2014 (UTC)

Firefox console displays the following for a test on brwiki when I click on an image :

[14:54:15,613] GET https://bits.wikimedia.org/event.gif?%7B%22event%22%3A%7B%22action%22%3A%22thumbnail%22%2C%22samplingFactor%22%3A1%7D%2C%22clientValidated%22%3Atrue%2C%22revision%22%3A8935662%2C%22schema%22%3A%22MediaViewer%22%2C%22webHost%22%3A%22br.wikipedia.org%22%2C%22wiki%22%3A%22brwiki%22%7D; [HTTP/1.1 204 No Content 63ms]
[14:54:15,614] GET https://br.wikipedia.org/w/api.php?action=query&format=json&prop=imageinfo&titles=Restr%3ALlanberis-P4121156%2EJPG&iiprop=timestamp%7Cuser%7Curl%7Csize%7Cmime%7Cmediatype%7Cextmetadata&iiextmetadatafilter=DateTime%7CDateTimeOriginal%7CImageDescription%7CLicense%7CLicenseShortName%7CUsageTerms%7CLicenseUrl%7CCredit%7CArtist%7CGPSLatitude%7CGPSLongitude%7CCategories%7CPermission&iiextmetadatalanguage=br [HTTP/1.1 200 OK 1547ms]
[14:54:15,614] GET https://br.wikipedia.org/w/api.php?action=query&format=json&list=imageusage&iutitle=Restr%3ALlanberis-P4121156%2EJPG&iulimit=100&smaxage=86400&maxage=86400 [HTTP/1.1 200 OK 829ms]
[14:54:15,615] GET https://br.wikipedia.org/w/api.php?action=query&format=json&prop=globalusage&titles=Restr%3ALlanberis-P4121156%2EJPG&guprop=url%7Cnamespace&gufilterlocal=1&gulimit=100&smaxage=86400&maxage=86400 [HTTP/1.1 200 OK 829ms]
[14:54:15,615] GET https://upload.wikimedia.org/wikipedia/commons/thumb/8/81/Llanberis-P4121156.JPG/800px-Llanberis-P4121156.JPG [HTTP/1.1 302 Found 516ms]
[14:54:16,246] GET https://upload.wikimedia.org/wikipedia/commons/thumb/8/81/Llanberis-P4121156.JPG/800px-Llanberis-P4121156.JPG [HTTP/1.1 302 Found 641ms]
[14:54:17,133] GET https://br.wikipedia.org/w/api.php?action=query&format=json&prop=imageinfo&titles=Restr%3ALlanberis-P4121156%2EJPG&iiprop=url&iiurlwidth=800&smaxage=86400&maxage=86400 [HTTP/1.1 200 OK 485ms]
[14:54:17,108] Deprecation warning: moment construction falls back to js Date. This is discouraged and will be removed in upcoming major release. Please refer to https://github.com/moment/moment/issues/1407 for more info.

with the following message displayed instead of the image "Error: Could not load thumbnail data. could not load image from https://upload.wikimedia.org/wikipedia/commons/thumb/8/81/Llanberis-P4121156.JPG/800px-Llanberis-P4121156.JPG"

--NicoV (talk) 12:56, 21 August 2014 (UTC)

One possible reason is if you are behind a proxy which strips CORS headers (that's bug 62469). Can you test again in Chrome? Firefox has a tendency of not reporting CORS errors properly. --Tgr (WMF) (talk) 13:03, 21 August 2014 (UTC)

Unfortunately, I can't test with Chrome (rules prevent from running it) or any other browser. --NicoV (talk) 14:54, 21 August 2014 (UTC)

Could you check the network tab of the web toolbar, filter for XHR and images and see what sort of headers the request for the image has? --Tgr (WMF) (talk) 00:53, 22 August 2014 (UTC)

Tgr (WMF), I hope this is what you wanted... I tried opening an image from brwiki. The results are available here.--NicoV (talk) 07:56, 22 August 2014 (UTC)

Thanks! This is indeed an office proxy stripping CORS headers. You could try raising this with office IT - I don't think there is any valid reason for a proxy to do that. Alternatively, you can disable Media Viewer by opening it, scrolling down and clicking on the "Disable..." link. --Tgr (WMF) (talk) 11:58, 22 August 2014 (UTC)

Well, not a single chance the IT service will do anything about this. Reading bug 62469 comments, that doesn't seem to be something so rare. You don't plan to make it work ? Personnally, I have disabled Media Viewer because I'm not interested in it at all (I didn't find any advantage of using it compared to the classic way, but several obvious disadvantages). But for someone that would have the same problem as me (not working in the office, working at home), he would have to either disable it for both or have something not working at the office ? Not very nice. --NicoV (talk) 12:09, 22 August 2014 (UTC)

You are the second person reporting it so far (the first half of the bug is about server configuration for third-party MediaWiki installations), so it is fairly rare; and I don't see an easy fix, so this is towards the bottom of the priority list, I am afraid. --Tgr (WMF) (talk) 13:17, 22 August 2014 (UTC)

Doesn't work at all 2

but nobody cares. WMF has decided that we have to use this bug and there is no way around it. Disabeling the pile of brown stuff doesn't work either: http://bits.wikimedia.org/event.gif?%7B%22event%22%3A%7B%22action%22%3A%22optout-anon%22%2C%22samplingFactor%22%3A1%7D%2C%22clientValidated%22%3Atrue%2C%22revision%22%3A8935662%2C%22schema%22%3A%22MediaViewer%22%2C%22webHost%22%3A%22de.wikipedia.org%22%2C%22wiki%22%3A%22dewiki%22%7D;

{"event":{"action":"optout-anon","samplingFactor":1},"clientValidated":true,"revision":8935662,"schema":"MediaViewer","webHost":"de.wikipedia.org","wiki":"dewiki"};=

Results in a big nothing. The programmers behin this nonsens should be made volunteers.--193.254.155.48 13:20, 21 August 2014 (UTC)

This is an event logging link; it results in the event counter being incremented by one. Disabling Media Viewer on dewiki as an anon works fine for me. You have to enable cookies (localStorage to be precise), of course. --Tgr (WMF) (talk) 16:51, 21 August 2014 (UTC)

Doesn't work with cookies enabeled. Changing the User Agent to something silly like "Mozilla/4.0 (compatible; MSIE 3.5; Windows NT 5.1; ..." works fine though. Which site does the media Viewer originate from Wikipedia.org or Wikimedia.org to make the UA site specific?--91.10.8.206 19:05, 21 August 2014 (UTC)

I have no idea how the user agent could influence that; as far as I know we use feature detection for everything that's relevant. What is your normal user agent? --Tgr (WMF) (talk) 23:28, 21 August 2014 (UTC)

Media Attribution - Development priorities

Tracked in Phabricator
Task T67445

I highlighted Media Viewer's lack of support for licensetpl_attr elements in June. It's tracked in Bugzilla and in Mingle. However, it is not scheduled until the 2014/15 Q3 cycle, this is 6 months away.

I believe it should be a higher priority, the credit line is legally mandated by the license. Photographers are at loathe to contribute images because of a lack of on page attribution on Wikipedia, they're going to dislike it even further if there is no off page attribution either. Can we see if this feature can be moved up the development chain? - Hahnchen (talk) 12:57, 22 August 2014 (UTC)

Media Viewer Update

Media Viewer's new 'minimal design'.

Hi folks, here is another update about the Media Viewer project, for those of you who haven't been following it lately.

Here are some highlights of what we’ve been working on this month:

1. Media Viewer Improvements

We are now working to improve Media Viewer in coming weeks, to address editor concerns while making it even more useful for readers — our main target users for this product. Here are some of the improvements we are planning to test and develop for the next version:

• a much more visible link to the File: page;
• an even easier way to disable the tool;
• a caption or description right below the image
• remove additional metadata below the image, directing users to the File: page instead.

As described in our improvements plan, these features are now being prototyped and will be carefully tested with target users in coming days, so we can validate their effectiveness before developing and deploying them in September. You can see some of our thinking in this presentation, which we discussed with community members at Wikimania in London -- with positive responses from many experienced users. We’ll keep you posted on what we learn from this research in coming days, based on our latest prototype . Please contact us if you are interested in testing the prototype, with the understanding that we are now optimizing it for casual users, not power users.

2. Community Discussions

While Media Viewer has generally been well received on most wikis, you’ve probably heard by now that it was the subject of three separate Requests for Comments on the English and German Wikipedias, as well as on Wikimedia Commons.

The Wikimedia Foundation has now responded to all three RfCs, as briefly summarized below. We understand that a majority of editors participating in these RfCs would prefer that Media Viewer be disabled by default for all users. Yet many of those editors have also correctly pointed out that Media Viewer is primarily aimed at readers — and the feedback we have collected so far shows that many readers find this tool useful, across our projects. We also note that if Media Viewer were to be disabled by default, it would be very difficult for those readers to re-discover it and re-enable it. So it seems important to keep it enabled for logged-out users, instead of preventing them from using it, if they find valuable. And while we recognize that enabling Media Viewer by default can be inconvenient for logged-in editors, it’s also easy to disable -- either within the tool itself, or in their preferences -- and we plan to make it even easier to opt out in the next version. For software tools like these, our view is that we should let individual users decide for themselves if they want to keep new features enabled.

For these reasons, the foundation respectfully declined to disable Media Viewer by default for either logged-in or logged-out users on the English and German Wikipedias at this time. On Wikimedia Commons, however, the tool has just been disabled for logged in users by default, as a special exception due to that project's primary focus on media curation. Each community has responded in different ways to the foundation’s statements. In one case, our decision to leave Media Viewer enabled by default led to a conflict escalation between the foundation and some German community members, which we deeply regret. In coming weeks, we will exert our best efforts to resolve these issues in a variety of ways, from improving Media Viewer itself (see above), to improving the process by which new features are developed, tested and released (see below).

3. Working Together

As our executive director Lila Tretikov stated on her talk page, the foundation is committed to working with the community towards a constructive resolution of this and any future disputes. We are now reviewing our current development processes and exploring new approaches to allow for feedback at more critical and relevant junctures. With that in mind, we invite you to help brainstorm ideas that might improve community engagement for future product rollouts, on this special page. I will also be going to Germany in about a month to discuss some of these issues in person with community members, whom I really look forward to meeting face-to-face.

4. Wikimania Update

Most of our multimedia team was present at Wikimania in London, where we hosted 7 different roundtable discussions and sessions, which we found extremely productive. Topics ranged the gamut from the Structured Data to Upload Wizard, Media Viewer, Video, Community Engagement — and yes, even Kindness. We really enjoyed our many constructive conversations with hundreds of community members, who worked with us as partners to improve our plans and products in a variety of useful ways. We’re very grateful for these special collaborations, which keep getting stronger year after year. In coming days, we will share what we learned together in some of these sessions. For now, you can check each session's slides and notes, which are linked on this overview page. You might also enjoy some of my favorite photos from this exceptional gathering, as well as the latest installment in my ongoing series of community ideas on how to improve Wikipedia. Finally, those of you who read German might appreciate User:Ziko’s excellent article for the Kurier on our in-depth conversation in London.

Overall, the wonderful collaborations we’ve enjoyed with many of you at Wikimania are a great example of what is possible when we all work together in good faith and with mutual respect for each other. Thanks to everyone who made this inspiring event possible! We all look forward to discussing the new version of Media Viewer with you very soon. :) Be well, Fabrice Florin (WMF) (talk) 18:57, 22 August 2014 (UTC) - for the Multimedia Team.

• Don't fix it. Just kill it. Do you understand that most readers are not able to disable it? Let them use by default the efficient normal use of pictures allowing multiple sizes and a not confusing way to navigate between text and pictures.--31.44.121.34 20:49, 22 August 2014 (UTC)
• "a much more visible link to the File: page;": While I really appreciate the change, I'm a little sad that the Wikimedia Commons icon (or the icon of the respective Wiki) was dropped in favor of a totally vacuous paper scroll. I'd recommend using the (colored) version of the Commons icon. This has multiple advantages: a) people now what to await (-> being taken to Commons); b) it's memorable – a key feature of every icon which the current one lacks; c) it's by far the best that we can do regarding recognizability while expressing our "corporate" identity with the project's logo. --Patrick87 (talk) 21:03, 22 August 2014 (UTC)
• And still you want to paper over the cracks with verbage and platitudes, can't you tell that the furore is less now about the Media Viewer but the cack-handed way the devs, and one in particular acted when we rejected your baby. Apologise, repudiate and censure that dev's actions and then maybe then we can believe that you (you plural) have truly learnt from this episode and will not in future just repeat the same mistakes.--KTo288 (talk) 09:24, 23 August 2014 (UTC)

That won't happen. This guy is just a loser, a spineless and incompetent loser, complete with attempts at pointy-haired boss speak. Then again, the WMF seem to breed them. Truly sad state of affairs.

I think you guys above are being very unfair. IMO the Multimedia team deserve a lot of credit for listening, and taking a new approach to the MV, which IMO should substantially resolve the antipathy people who dislike the existing MV have felt for it.

In particular, the new MV will have a much clearer role, as an alternative way to skim through the pictures on Wikipedia, complete with the captions from the WP articles, and no longer attempting to be any kind of susbtitute for Commons file pages.

It's a really clear view of what the use-case for the MV is, and I applaud the Multimedia team for having thought the issue through, found this solution, and embraced it. Jheald (talk) 21:45, 25 August 2014 (UTC)

Those who read German might just as much laugh their heads off reading this you-called-it excellent article. Man77 (talk) 08:12, 29 August 2014 (UTC)

Link for reuse

Hi team. Please can you shorten the link syntax when a user chooses "Use This File"? For example for file File:User_99of9_reflected_in_Australian_Magpie_eye.jpg it gives the link as https://commons.wikimedia.org/wiki/File:User_99of9_reflected_in_Australian_Magpie_eye.jpg#mediaviewer/File:User_99of9_reflected_in_Australian_Magpie_eye.jpg which is way longer than necessary for reusers. IMO reusers should just be told to link to https://commons.wikimedia.org/wiki/File:User_99of9_reflected_in_Australian_Magpie_eye.jpg. What is your rationale for including all the extra stuff? --99of9 (talk) 13:00, 25 August 2014 (UTC)

Completely agreed, and I came here to ask the same thing. Furthermore, not only is it impossible to access the real URL from within MediaViewer it is also not possible to access the filename. For both of these things a user is required to go to Commons. Of course, that's only "one click away" but I would have thought that providing the URL and/or Filename are very low level requirements for attribution or sharing. I have listed this as a bug in Bugzilla - number 66997. Wittylama (talk) 14:44, 25 August 2014 (UTC)

Media viewer is way too hard to use and not very clear on how to go to original page.

I used to like wikimedia for all it's open source images, however this new Media viewer is nothing more than a pain in the backside. When I'm trying to download the file and use it somewhere else it isn't very clear where to find the TASL information to include. All I see is one big image and have to try and scroll around the screen to find the rest of the information. Also I noticed that the disable media viewer option doesn't always work, and when you next go back on the website again instead of using a cookie to remember your preferences it shows the media viewer again.

Double click => go to commons

Just an idea.

• one click on image => open MV
• double click => go to commons/wherever the file is located

What do you think? Lazowik (talk) 14:16, 27 August 2014 (UTC)

@Lazowik: Try the mouse wheel. 217.92.223.239 13:39, 28 August 2014 (UTC)

Have you accidentally seen mine? Man77 (talk) 08:08, 29 August 2014 (UTC)