Extension talk:Media Viewer/About/Archive04

Good example image to perhaps test features like this before rolling out ...
http://en.wikipedia.org/wiki/Linux_distributions#mediaviewer/File:Linux_Distribution_Timeline.svg

For some reason the "view original image" link isn't working for me and I found no way on Win7 with Firefox 29 to actually get at that image at a usable size via the new viewer. Finally "Copy Link" on the actual thumbnail on the main wiki page and using that link directly got me the old approach where I can use my browser to zoom to my heart's content.

I agree with others this isn't necessarily a bad feature ... when you want it. But when you don't? Aiieeee.


 * Can you explain in more detail how "view original image" does not work for you? --Tgr (WMF) (talk) 03:55, 16 June 2014 (UTC)
 * Tested with FF 30/Ubuntu : opening MMV on this image makes  throw   in   and clicking on the “view original image” does nothing — Ltrlg (talk), 11:27, 22 June 2014 (UTC)
 * That's ; there is a patch pending. --Tgr (WMF) (talk) 22:56, 26 June 2014 (UTC)

New features are live!
Hi everyone: To follow up on our earlier update on Media Viewer, I’m happy to report that we just deployed a range of new features today, based on community feedback.

1. New features These features are now live on English Wikipedia, German Wikipedia and other Media Viewer sites:
 * View original file: A prominent button to open the original image in your browser (#630)
 * Show Commons link to logged out users: now all users can quickly access the file description page (#429)
 * Scroll down for more info: Use either up or down arrows to open the metadata panel below the image (#697)

Try them out with and let us know what you think using the built-in feedback tool in Media Viewer — or in this discussion page. You can find these new buttons at the lower right corner of the Media Viewer tool. All three features address frequent community requests — especially the ‘View original file’ button, which lets you use your browser to zoom in, or download images for re-use.

2. Next features We're now working on these next features, to address other community requests:
 * Instant Opt-out (#703) (*)
 * Opt-out for anons (#704) (*)
 * View different image sizes (#664)
 * Add tooltips to Media Viewer (#546)
 * Make it easier to find image information (#706)
 * Disable MediaViewer for certain images (#511)
 * Show attribution credits in download tool (#598)

The first two opt-out features asterisked above (*) can now be tested here on MediaWiki.org, on this demo page — open the metadata panel and scroll down to the bottom, then click ‘Disable Media Viewer’. To learn more about these features, click on the relevant cards on the current sprint wall of our planning site.

We aim to deploy these next features on MediaWiki.org by next Thursday, then to all other sites the following week. To accelerate deployment, we may back-port the most important improvements to all Media Viewer sites next week, if they test well on production.

3. Next releases We are preparing to deploy Media Viewer on all wikis next Thursday, June 19, if all goes well with the testing of these new features. We’ll keep you posted as the release date approaches.

4. Metrics We are now logging about 24 million global image views per day for Media Viewer, doubling overall traffic since last week. The most active sites are the English Wikipedia (10M views/day), the German Wikipedia (3M views/day) and the Spanish Wikipedia (2M views/day), as shown on this global image view dashboard. Global network performance has remained stable, at about 2.5 seconds per image served for 90% of our users (~4 seconds for the 95th percentile).

5. Surveys We continue to see favorable global feedback across all surveys:
 * about 60% of 13,891 global respondents find the tool useful, on average.
 * approval breakdown by language: French 71%, Spanish 78%, Dutch 60%, Portuguese 81%, Hungarian 63%, English 29%, German 26%.
 * approval rates have stabilized for all languages that have used the tool for over a month (excluding English and German).
 * English and German approval rates are lower than other languages, partly because Media Viewer was only launched one week ago on their sites.
 * English daily approval rates have increased from 23% a day after launch — up to 35% a week after launch.

We expect approval rates on Enwiki and Dewiki to keep increasing over time, as new features get rolled out based on community feedback. For comparison purposes, approvals on the Hungarian Wikipedia started at 42% and grew to 63% in just a few weeks, once we addressed the most important community issues. To learn more, visit the survey results page.

Please let us know if you have any questions. We’ll keep you posted on the next major developments.

Thanks to everyone who gave us constructive feedback in recent days: we really appreciate your guidance and look further to improving Media Viewer further in coming days, with your help. :) Fabrice Florin (WMF) (talk) 22:12, 12 June 2014 (UTC)
 * I still believe that clicking the image should do something -- either show the original file or go to the traditional image page. 86.160.87.249 13:18, 13 June 2014 (UTC)
 * Fabrice, this improves the tool and improves the experience. The anon issues are high priority and that is appreciated. Is there a mechanism to note this in a retrospective other teams can access? The dismissal of the anon user community's needs was (guessing from the flames erupting on this page and others) a major blow to the project and likely to the WikiWorld as a whole. I'd love to see this avoided for future projects. There are still a lot of critical objections (especially around copyright as discussed on this page and the archives), but this set of features certainly made great strides. One other note: the images selected on your demo page brilliantly showcase the power of this tool. Good job on that! 159.53.174.144 15:55, 13 June 2014 (UTC) (same Kevin)
 * Yes, there will be a launch retrospective which is shared with other teams (well, all retrospectives are shared, but launch retrospectives tend to be read, too :), and doing beta testing with anonymous users + being prepared for implementing an anon optout are certainly some of the main take-home messages in my opinion. --Tgr (WMF) (talk) 07:28, 25 June 2014 (UTC)

Let go of coding the opt-out, this is very powerful fertilizer (a.k.a. a steaming bowl of crap) and should be opt-in only! It adds no useful functionality and makes Wikipedia harder to use. If I wanted useless and pretty, I'd look on Instagram, not Wikipedia.

This new viewer is obtrusive and poorly designed.
I use Wikipedia for personal and professional reasons more or less every day and I had no idea this feature was even in development until it suddenly popped up one day. The fact that this huge of a change appeared without any notice was already suspicious. After spending just a short time researching actual written feedback here and on other discussion sites, it's very clear that pretty much no one wants or enjoys this feature, and that its implementation is mostly annoying and disruptive. However, it is defended staunchly by a few dedicated people who are apparently involved with the project. I have seen incidental discussion about money and funding being wasted. It seems pretty obvious that someone needed a place to spend money, ended up with this terrible feature, and now needs to justify it with a couple poorly worded public surveys and by just pushing it into full implementation without any discussion about the possibility of scrapping the project. Hope I'm wrong and this disappears soon.

How do I disable Media Viewer on Commons?
There is no option to disable Media Viewer in the preferences on Wikimedia Commons. How can I do it? --Jonund (talk) 16:39, 13 June 2014 (UTC)
 * You should be able to find it here, untick the box in the "Files" section that says "Enable Media Viewer." Hope that helps. Keegan (WMF) (talk) 17:35, 13 June 2014 (UTC)

Unticking does not disable this stupid, no damn good, value-subtracted feature. USNorseman (talk) 00:50, 19 June 2014 (UTC)

New version: still horrible
"Try out these new features and let us know what you think." Still hate it. Completely. There is not a single good thing about the new media viewer. You're replacing a good, useful, basic thing, with an annoying, stupid, useless, over-designed, web-2.0-bullshit thing. OH YAY, ANOTHER SITE WHERE I NEED TO MOUSE OVER EVERYTHING AND CLICK RANDOMLY TO SEE WHAT HAPPENS FOR SOMETHING THAT SHOULD BE TOTALLY BASIC. This is a mountain of shit. Kill it with fire. BrianAshe (talk) 05:56, 24 June 2014 (UTC)


 * This is pretty well what I feel about it. I have not seen a convincing argument for doing it in the first place and when someone described it as "very professional", I thought, "Looks pretty amateurish to me!" LynwoodF (talk) 08:25, 24 June 2014 (UTC)

Description
I have some issues concerning the description. Normally, the description in Media Viewer consists of two lines whereas the first line is the caption from the article in wikipedia and the second line is the description from the description page on wikimedia commons. is an example of an image used in the article de:Zervreilahorn, where everything works fine. But in the following cases, Media Viewer behaves different: --Capricorn4049 (talk) 18:04, 13 June 2014 (UTC)
 * if the image is used in the infobox, the caption from wikipedia is not shown (example)
 * if the image is not from wikimedia commons, even the caption from the description site is not shown (example)
 * if the image is used in a template, the caption from wikipedia is not shown (example)

This is being fixed, see (multimedia/#513) Caption not shown for images which do not have |thumb| in their wikitext. For the issue in your second bullet point, see commons:Commons:MRD about how to mark up description templates so that they are understood by Media Viewer. --Tgr (WMF) (talk) 03:41, 16 June 2014 (UTC)

Problem with Lage Images
Well, the only purpose why we have files like is because people would want to view parts of it by zooming in. Either I'm stupid, or it doenst work. Klicking on "View original file" ("Originaldatei anzeigen" in german) changes nothing. So good I understand URLs and can edit it to but that certainly can do only 1% of wikipedia readers. --Dan-yell (talk) 18:08, 13 June 2014 (UTC)

For me, "View original file" links to the same URL you have given. If that works differently for you, can you describe in more detail? --Tgr (WMF) (talk) 02:17, 16 June 2014 (UTC)
 * Actually, this file is running into a bug, that is causing this behavior. I have filed it in bugzilla and it is linked to the top right of this topic. TheDJ (talk) 09:25, 16 June 2014 (UTC)

"Derivative versions not eligible"
Elsewhere on this talk page, someone linked to. There it says "Derivative versions, GFDL, License migration not eligible". This sounds as if the image is ineligible for three things: licence migration, GFDL and derivative versions. In other words, it sounds as if I can't make derivative works and that I can't use the image under the GNU Free Document Licence, implying (because of the derivative works issue) that the image is unfree. Please improve the wording.

Also, users who are not logged in are usually not shown hidden categories, but for some reason, the media viewer shows all hidden categories. How does the category choice work? The file appears in five categories: four hidden and one visible. The media viewer shows three of the four hidden categories but not the last hidden category and not the visible category. --Stefan2 (talk) 18:17, 13 June 2014 (UTC)

These are categories, taken from the image page. Not sure what wording we could improve.

Categories are currently chosen in a rather dumb way, we just pick the first three returned by MediaWiki (I think these correspond to their order in the wikitext source, but I am not sure). Hidden/non-hidden is not taken into account since that information is not easy to access at the place where Media Viewer processes categories. --Tgr (WMF) (talk) 04:15, 16 June 2014 (UTC)

Tsunami of criticism
I can see tsunami of criticism of the whole idea of Media Viewer, but I can't see any reaction of authors of this idea. --Matrek (talk) 01:51, 14 June 2014 (UTC)

I think it's horrible
This new way of forcing users to view images in a media player seriously detracts from the usabilitu of Wikipedia. I click on an image for more information ABOUT THAT IMAGE, is a larger view and some meta info, NOT so that I can be taken away from my current page into an all-consuming app.

Please, please, please, can we have a GLOBAL opt-out of this new imposition FORNON REGISTERED USERS. Despite being a subject matter expert I stopped logging in and editing Wikipedia some time ago when various policies changed and made Wikipedia a less useful place to support. I know I'm not just a voice in the wilderness - a LOT of people seem to find this new 'feature' a disaster.

Please, let us have the simple old image viewer system back. Doing whizzy stuff 'because you can' is NOT a justification.

Unfortunately there is no easy way to have global settings, not even for registered users, much less for anonymous visitors. --Tgr (WMF) (talk) 03:48, 16 June 2014 (UTC)


 * What do you mean by "no easy way"? With the Unified login, once users logs in one of the wikis, all other wikis also automatically recognize him/her. Is the addition of one more bit to that shared information exceptionally difficult? — 128.32.220.21 20:34, 16 June 2014 (UTC)


 * Yes. You can track the progress of global preferences at if you are interested. --Tgr (WMF) (talk) 21:29, 16 June 2014 (UTC)

I hate it
This "feature" adds nothing, but it does make Wikipedia harder to use, and MUCH more annoying.

Who asked for this garbage anyway? Certainly not I.


 * I hate it too, and was shocked to find that it's universally-enabled. No one asked ME if I wanted such a useless feature, something which farts-out a blob of a picture when I click on an embedded image - devoid of useful context, something I'd expect would appeal more to social media misfits high on Adderall, and wholly inappropriate for serious, registered (or even anonymous) contributors to a supposedly respectable online knowledge project. Harrrumppff!! Azx2 (talk) 01:48, 25 June 2014 (UTC)

Useless when looking at magnified webpages
I always view webpages with a degree of magnification to avoid eyestrain (i.e. I use "Ctrl+"). With the old system, I would click on a picture and go to a page which showed a larger picture, plus other available resolutions, plus associated info. The new viewer takes me to a picture which is the SAME size or even SMALLER (because the page I left was already enlarged), and with associated info obscured. Because of the magnification, if I scroll down to try and find metadata, it is all in unreadably giant letters. Pic in the new new viewer cannot be enlarged by Ctrl+. The whole experience is a HORRIBLE step backwards for Wikipedia, which I had assumed was run too intelligently to fall for the modern fad of making websites less usable for reasons of being "trendy". Please disable the disaster as soon as possible and return to the old system, which was far more informative, professional, and befitting an encyclopaedia!
 * I would argue that by using additional tools that change the presentation of the page (your magnification tool), the weight is on you to disable the feature instead of require that it be disabled for everyone (surely if you're using magnification all the time, you've found that a great deal of sites don't handle it well). Bear in mind that you can always disable the feature for the old one if the tools you use don't play nicely with MV.


 * The image in the MV should also definitely not be smaller. I believe that you're confusing physical size and resolution. The higher resolution image that MV displays should show a great deal of quality that is not in the thumbnails (even with magnification).


 * Regarding the metadata being large, I'm not sure exactly what you're expecting. I attempted to zoom in several times and while the text got bigger (as expected), it was always readable. With that said, you have a good point that the image cannot be zoomed in on (in fact, zooming makes the image smaller). In my opinion, a one-click "show real size" feature needs to be implemented, and this full-sized image should play nicely with magnification tools.


 * As a workaround, you can click the "view original file" icon in the bottom (the thing that looks like an icon for a Windows photo viewer), and that plain image should be supported by browser zooming features. Hofmic (talk) 18:22, 17 June 2014 (UTC)

In answer - no, I'm talking about physical size on the screen, not resolution. As for the metadata text, it is magnified much more than the text on the wikipedia page I navigated from.

Media Viewer Sucks
How do I turn it off? Wee Curry Monster (talk) 21:34, 14 June 2014 (UTC)
 * You can disable it in your preferences. Unfortunately MediaWiki does not currently support global preferences, so it depends on which wiki you would like to turn it off. Click on the "Preferences" link you see at the top of the site, go to Appearance, and untick "Enable Media Viewer"  in the "Files" section. This is a quick link for the English Wikipedia, for example. Keegan (WMF) (talk) 21:57, 14 June 2014 (UTC)
 * Why we have to disable feature on our side? Just because group of few MV authors want to force that idea to be default feature? You guys should disable whole idea of MV --Matrek (talk) 04:39, 17 June 2014 (UTC)
 * For the same reasons that you'd have to disable any feature if you don't like it. Software change happens. At least MW provided the ability to disable the feature natively (more than can be said about, say, how Microsoft handled the changes to the start menu, which still require third party software to revert). And to be fair, I wouldn't say that MV is all bad (although I do think it was rushed without enough acceptance testing). Hofmic (talk) 18:05, 17 June 2014 (UTC)
 * Microsoft is a privately owned commercial company, handling its own business risk. Wikimedia Commons is not a private enterprise, at least as long, as long Wikimedia Foundation asks for our donations, and for our contributions. --Matrek (talk) 04:05, 22 June 2014 (UTC)
 * Thanks for explanation :)--Shanghainese.ua (talk) 09:10, 19 June 2014 (UTC)
 * No, I can't disable it. Those directions don't work for me; not without creating an account, logging in, and staying logged in (not an option).  When I click/tap on an image (or preferably right-click but that's not an option on a touchscreen), I expect to see info about the image and any other resolutions.  I'm not interested in a slideshow of all the images in the article.  72.145.224.180 19:34, 20 June 2014 (UTC)
 * You can disable it by bringing up the information panel (just scroll down or tap at the little down arrow at the bottom) and selecting the option at the very bottom. --Tgr (WMF) (talk) 19:43, 20 June 2014 (UTC)

Pointless Change and a Distraction
This is a case of a change of feature for the sake of changing a feature. The supposed benefits of this "media viewer" are "it looks different."

I specified in the survey the points why I feel the media viewer fails in doing anything useful, and I won't go into all of them here, but I feel so strongly about this that I actually made an account so I could add my objection to this discussion. I apologize in advance if I am not doing this right since I haven't done this before.

Just like so many websites have in the past 4 years, some person in charge of web design says "Hey nobody has changed anything with how this part of the website is done in ages... people will get bored!" So they come up with a completely superficial idea to change things around, make it look "new" and "exciting." The only problem is that it almost always reduces functionality and adds no real benefit, because it's all about how it 'looks' not what it does. This is exactly the same problem, now afflicting Wikipedia.

To the web designer whose smartypants idea this is: I don't want an "immersive" experience with the images, I am looking at an image in context with the article it's attached to. All I want is perhaps a slightly larger image, or to view the details such as copyright. An "Immersive" image is a distraction and a complication in my trying to absorb the information in the article. I'm not viewing a gallery of images like on Flickr, I am looking at an image that's connected to an article.

So no, I want nothing to do with this. I want to disable this "Media Viewer" nonsense permanently and return to the simple but efficient layout that I enjoyed before.

I would welcome any new layout that adds means of accessing more information about something. I welcome change that adds more to the content without removing features, or needlessly complicating the experience. This adds nothing except superficial scripting, removes features, and makes it more complicated to use.

Since it's clear that there is a bias towards accepting this new "Media Viewer" by the administration of Wikipedia, and as such this entire thread of objections is likely to be ignored, and this foolish idea adopted anyway... I will now proceed to find a way to disable this feature on my end of things. Ikaruseijin 23:12, 14 June 2014 (UTC)

It's a big shit
Sorry, but it's a big shit ! Rgds user:Tonton Bernardo

Author not clear
I like to use images from wikimedia resorces. But in this new viewer I often do not find the author of an image. Therefore this new viewer it's a step back. I do not like it. Please take it away and let it as it was before. Thank you.

Bogus survey
The people who are pushing this unusable new "feature" onto wikipedia users are hiding behind the results of a worthless survey. The survey results would only be meaningful if they could be compared to a survey conducted before rollout of the new viewer, asking people if they were satisfied with the results of clicking on a picture. I strongly suspect that most users were satisfied with the old system, or more tellingly, likely very few users were dissatisfied. After all, clicking on a picture under the old system did everything any user would require, whether a casual user or advanced. I very much doubt that there was any dissatisfaction amongst the user base, and so there was no problem which needed to be addressed. Reducing functionality for the sake of being "cool" is pretty lame for a encyclopaedia, and hiding behind the survey is reprehensible. Listen to the frequent and advanced users and permanently remove the new picture viewer.
 * I still dont know who was asked to participate in that survey. Maybe mobile users, whos preferences and taste were formed by Instagram or something, feel more comfortable with that new lack of usefulness. Alexpl (talk) 12:11, 16 June 2014 (UTC)

One more person who hates Media Viewer
I only found out about Media Viewer when I clicked on an image and was surprised by this obtrusive and annoying full-screen popup that appeared. I use wikipedia all the time, and I only do edits on rare occasions. This "improved" feature is just a piece of garbage. The regular File: page was perfect and simple, and it provided everything that any user, casual or what ever, would need. Blacking out the rest of the screen and article is just dumb. If the Media Viewer is just going to cover up the entire page and take over everything, I'd rather just go to the File: page. And I'd rather go to the File: page even if the Media Viewer gets a change to its black background and full screen popup, because it's not necessary and just ruins the flow of the wiki. It also just looks horrible, so if you were trying to make something that looks cool and new, you failed. And besides, why are you trying to do that? This is a wiki encyclopedia, plain and simple functionality should be it's main goal. Get rid of this horrible downgrade and fire the moron(s) who implemented it.

-- Someone Who Hates Media Viewer
 * +1,000,000 .... ⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖THIS!!!! Azx2 (talk) 02:08, 25 June 2014 (UTC)

I speak only a few English, so I'll make it as short as possible: BULLSHIT!
Country roads, take me home!

And another...
Yes, I've turned it off - for myself anyway. I don't have the power to turn it off generally. As I commented at en-wiki, utter crap. A solution without a problem to justify it. Presumably a similarity to something found in social media, where I find the image viewing to be usually appalling anyway.Interesting that the 'survey' was so much in favour, but the proportion of happy little bunnies on this page seems vastly different. When I click on an image, I want to see the image and possibly magnify it, and sometimes to read the data. With this, magnifying becomes complicated and not obvious, and the data on its silly little sliding thing has become almost unreadable - except perhaps for those who sit nine inches from the screen and are short-sighted anyway. You asked for feedback. You're getting feedback. Will notice be taken of it? Doubtful. Peridon (talk) 13:50, 16 June 2014 (UTC)

Major flaws still exist
After all that's been said and done about improvements to media viewer, it still has its major flaws:
 * MV doesn't allow the user to readily see an image in its max resolution by simply clicking a second time. Instead, users have to click on an icon in the lower right, and you have to hover over it to see what its for, where the little pop-up message says "More details on a Wikimedia Commons", which doesn't even hint that there is access to an image's max resolution. This will be ignored by most viewers, so I think it's safe to assume that the quality of all the hi-res images (e.g.'Today's featured picture', 'Picture of the Day', etc) will be denied to the casual users we were told are the first priority by the few individuals who have pushed MV into its default existence.
 * There is no readily available way to disable the viewer, still, and in fact there is not even a hint of how to do so for the average reader and users with limited experience. -- Gwillhickers (talk) 16:12, 16 June 2014 (UTC)

Contrary to the approval rating we were told about MV, that it's "a useful tool" (a "tool"?), it's rather clear that it is not wanted here at English Wikipedia. Had there been a list of features (and lack thereof) presented in the original approval survey compared to those of the standard viewing system, I think we can assume most rational adults would have said, 'don't bother'. Instead they were presented a gallery of images and told to view them with MV where the naive user was mesmerized by the slide show feature as they skipped along from one image to the next. No doubt the "approval" is based on this feature alone, simply because it was (and still is) its only feature. Disappointed. -- Gwillhickers (talk) 16:12, 16 June 2014 (UTC)
 * You can one-click the mountain icon in the bottom left right sips morning coffee corner to go straight to the full resolution of the image; you don't need to go to Commons. I'm not sure it's 100% how you would have it implemented but I hope it'll work for you. As for one-click disable, that is now live right here on MediaWiki and is going out to Wikimedia Commons tomorrow, then it will be backported to all the other wikis.  This fix took an extra bit of testing to make sure it worked properly. Hope that helps :/ Keegan (WMF) (talk) 16:51, 16 June 2014 (UTC)
 * . Ahhgg!! ... yes, you're right. Please accept my apologies on that note. However, it might be helpful to give the viewers something more than an ambiguous icon (whatever happened to labels? e.g.'Max-Res') After all, I missed it, no doubt others will, esp if they don't know about max resolutions in the first place. I would recommend 'something' that indicates that there's a provision for viewing an image's max resolution besides the cryptic icon in the lower right. Also, an indication of the image's resolution would be nice. (e.g. 1024 x 2036) -- One last bit of feed back: When I first encountered media viewer it was almost like running into a wall. A very abrupt visual change. It looked as if I had left Wikipedia altogether. Can you make the viewer look like we're still in the world of Wikipedia? I would recommend a Wiki' view first before going to 'the dark zone' with the black background and the completely different look. Hopefully the instant disable feature you say is coming along will not be equally as fuzzy to discern. -- 107.215.12.158 19:48, 16 June 2014 (UTC)
 * @ Keegan - why you guys are forcing this commonly unwanted format? Can't you really see, that no-one wants it? That the only people wanting MV are it's authors? --Matrek (talk) 04:34, 17 June 2014 (UTC)

Please show the image annotations
Hi!

I have to say that, contrary to most commenters, I actually like this media viewer. Browsing through an article's images is now really fast and enjoyable.

However, for annotated images, it would be really nice if the viewer displayed the annotations. Right now, the annotations are two clicks away from the page (open the viewer, then click on "More details on Wikimedia Commons"). Not really worse than before on English Wikipedia, however, in the French Wikipedia it is worse, as the commons page used to be at only one click distance from the Wikipedia page.

Example: in an "encyclopedic" context, the image https://en.wikipedia.org/wiki/Nikon_FE#mediaviewer/File:Nikon_FE_top_view.jpg would really be more useful with the annotations seen in

Regards,

Edit: a bonus suggestion: If an annotation is available in several languages, and the current Wikipedia language is among them, then only display the annotation in that language. E.g., when I click on the example image above from en.wikipedia.org, I would like to see the annotations in English. When I click on the same image from fr.wikipedia.org, I would like to see them in French.

— Edgar.bonet (talk) 16:31, 16 June 2014 (UTC)
 * Thanks for the feedback, Edgar.bonet. Annotations have been pointed out by others as well, and Media Viewer should be able to support them in the future. There's interface interaction complexities in making annotations work across platforms. I too look forward to the support. Keegan (WMF) (talk) 20:40, 16 June 2014 (UTC)

Please, please don't force this "feature" on us!
All the other criticisms people have mentioned on this page are valid. Additionally, the media viewer is highly buggy and literally unusable on mobile devices running the desktop version of Wikipedia. Please restore the older, highly functional image pages as the default way to view images because not everybody has a Wikipedia account and access to a preferences menu! 2601:8:9100:7B1:4CF8:961F:C99C:5099 17:59, 16 June 2014 (UTC)

Candid question: who is in charge on this?
I have a candid (albeit not malicious) question: who is in charge on this? Who decides if, yes, or no, the new Media Viewer becomes the new standard? I'm used at Commons and English Wikipedia to reaching decisions by consensus. Doesn't seem to be the case on this matter, as this particular decison is being taken against a strong opposition of the users! -- Alvesgaspar (talk) 19:34, 16 June 2014 (UTC)
 * Nobody knows or cares? Hard to believe! -- Alvesgaspar (talk) 19:57, 17 June 2014 (UTC)
 * Mr. Florin from Wikimedia is in charge as can be noted from his profile. It's part of the 'Multimedia Vision 2016'. Note: The opposition comes mainly from intermediate users like you and not from the 'silent majority' of potential Wikipedia beginners. Therefore, the decision in favor of the Viewer is 'consensus'. More precise: A consensus between prospective customers of the Wikimedia Foundation and its fleet of technical staff to create tons of annoying, but immersive scripts (like the keyboard that keeps popping up in the editor window at every keystroke) rather than keeping the technical side of Wikipedia understandable as it used to be. That's not profitable. But that's the way it goes, Alvesgaspar. Seems like you and your knowledge become obsolete here. Make room for beginners and professionals.
 * This kind of arrogance is not acceptable, especially when addressed to a volunteer editor, and makes me re-evaluate my long collaboration in the project. Alvesgaspar (talk) 11:49, 18 June 2014 (UTC)
 * Alvesgaspar: For the sake of clarity, the above message was posted by the anon . Whatever the merits of their (obviously negative) opinion of MediaViewer, this is not a message from the WMF team. As much as one can disagree with them, to my knowledge neither Fabrice nor anyone on his team has ever displayed such arrogance towards community members (in which case I would also be outraged of course :). Hope this clarifies the situation. Jean-Fred (talk) 13:26, 18 June 2014 (UTC)
 * It does, thank you. I was fooled by the scarcastic tone of the anonymous user and wrongly assumed that he was part of the WMF team. My fault, sorry. However, my initial doubts about the legitimacy of the process still hold. Alvesgaspar (talk) 13:32, 18 June 2014 (UTC)
 * Hello Alvesgaspar, and thanks for your question. The ultimate decision-maker on whether or not to keep Media Viewer enabled by default is Lila Tretikov, Wikimedia Foundation's Executive Director. On a day-to-day basis, I am in charge of this project as its product manager, in consultation with the multimedia team, and taking into account quantitative measures and feedback from our users. Note that we strive to take all viewpoints in consideration when making these types of feature decisions: the editor community, the readers we all serve and the developers who are most familiar with these features. All those perspectives are considered regularly, through a variety of channels, such as this one. Fabrice Florin (WMF) (talk) 15:30, 18 June 2014 (UTC)

Why does this still exist?!
Last time I was polite. This time I won't be. You're still attacking all wiki users with this crap's continued existence, and now I'm sick of being polite with this garbage shoved in my face on a daily basis.

I'm doing something SIMPLE. I'm reading an article, and want to look at the pictures, sometimes accessing information on them. Somehow you've managed to make this a problem! How the hell do you make something simple into a problem?! Why the bloody hell is this garbage still live? Doing basic tasks now takes twenty-thirty times as long - twice-thrice as many steps, and each takes ten times as long to load!

This garbage DOES NOT OFFER EVEN A SINGLE ADVANTAGE OVER THE OLD INTERFACE IN ANY WAY. None, at all, whatsoever. There is absolutely NO REASON FOR IT TO EXIST.

Old interface:
 * Pros:
 * Quick to load.
 * Easy selection of image size.
 * Lets me choose the tradeoff between detail and download time.
 * Easy access to image information, such as uploader and pages containing, loaded instantly with the rest of the page.
 * Image loading status, pan, zoom, etc provided by the browser, working quickly and correctly.
 * Properly separates content and presentation.
 * Integrates perfectly with browser's navigation, because the browser WORKS.
 * Lets me see both a small-size image and the description at once.
 * Had clear text links, works well for everyone.
 * Cons:

New interface:
 * Pros:
 * Cons:
 * Slow as fuck. Seriously.  Garbage like this makes me want to turn off javascript permanently.
 * No access to select image size. Accessing the original image takes a half dozen clicks, every one of which is slow as fuck.  And none of the clicks even work until after the rest of the slow-as-fuck crap finishes loading.
 * No ability to pick whether I want to see lots of detail, or want to see it soon.
 * Slow access to image information. First you have to wait for it to load (which is slow as fuck), then you have to click to access it...  which is slow as fuck.  How the fuck do you make simply displaying more info slow?  Does your javascript run loops counting to a billion for the hell of it?
 * (EDIT: Gah!  It actually fucking DOES! (in effect, at least)  The god damn slow as fuck appearance of the info is INTENTIONAL!  Someone actually WROTE CODE TO MAKE IT FUCKING TAKE LONGER!  This goes beyond smoking crack and well into PCP territory!)
 * Ugly, huge, wasteful, slow as fuck image loading status bar, no pan or zoom. And, of course, no progressive loading - you have to sit there doing nothing until the entire image loads, rather than being able to see parts of it as it loads.
 * Combines content and presentation, doing a piss-poor job of it, duplicating built-in browser features, worse.
 * Viewing an image causes THREE (count them, THREE!) useless URLs to end up in the browser's history, for every single image you view. This means you might need to click "back" dozens of times to return to the last page you were reading - and the ability to quickly navigate pages is one of the things that makes wikis nice.
 * Can't see both the whole image, in any size, and the text at once
 * Uses ugly, large, cryptic icons for navigation, giving people no idea what they do, probably breaking it for people with poor vision - obviously they don't need access to images, right? (And it breaks if you use any zoom feature, too!)
 * Uses ugly, large, cryptic icons for navigation, giving people no idea what they do, probably breaking it for people with poor vision - obviously they don't need access to images, right? (And it breaks if you use any zoom feature, too!)

And, last but most definitely not least, even if all of the above were somehow magically fixed, this simply isn't how I (or, judging from the comments, just about anyone else) want to interact with images. Functionality issues aside, it's just not what anyone wants. There is no fixing this. People want to interact with images in a way they find pleasant, and this is not, never can be, and never will be it.

This "feature" NEEDS TO DIE. I'm sure someone spent a lot of effort on it (after all, duplicating existing browser functionality can't be easy!), but it is entirely ill-conceived and ill-executed, and should not exist. It provides no benefits, gets in the way, goes against every concept of good web design, and generally should be stuck firmly in the bit bucket where it belongs. 74.207.250.159 04:38, 17 June 2014 (UTC)

Sucks
I just discovered this horrible feature. What a bad idea, and badly implemented. Seriously, just roll back the code-base. It sucks.

Could be a useful feature, but needs some work
Personally, I have mixed opinions. I can see how it would be useful (quick, appropriate sized preview of an image without having to go to the image page), but the UI is very weak. There's tons of ambiguous buttons that don't even have tooltips. I don't feel icons are always the best idea. Perhaps including labels on the icons (or using just labels) would be clearer. When an image is still loading, the navigation arrows are sometimes not shown.

It was difficult to find out how to get different sizes of the image. Not to mention they're hidden behind multiple clicks, now. When licensing details is large, it's partially hidden and you have to click to show it, and even then nest scrollbars.

A way to view large images easily is sorely needed. Some images need to be viewed in their full resolution and panned to be readable. Perhaps for sufficiently large images, we could click on the image to switch to a fullsized, pan-able version?

I'd also like to see a one-click button accessible on the media viewer and file pages for toggling the viewer on and off (presumably saving to the account if the user is logged in or local storage for anon users).

With that said, performance for loading an image of an optimal size for browsing is something I like. But at the moment (and more so when first released), it seems like a feature that is imperfect. Hofmic (talk) 17:54, 17 June 2014 (UTC)
 * Hello Hofmic: Most of your issues are being addressed in a release of Media Viewer that is now live here on MediaWiki and also on WIkimedia Commons. There is now a one-click disable/enable for registered users as well as anons found by pulling up the fold. You can access the large file size by clicking on the mountain icon in the bottom right corner. Tooltips will be available as well. You'll find most of these changes being released to the English Wikipedia tomorrow (Thursday). I hope that help you find Media Viewer a more complete product. Keegan (WMF) (talk) 16:55, 18 June 2014 (UTC)
 * As of the time signature shown, a disable feature for anons is not live on Commons. 159.53.174.143 22:58, 18 June 2014 (UTC)(Kevin)
 * We are storing the opt-out flag in localStorage. The option will only appear if your browser and your privacy settings allow for that. The feature was enabled on Commons a day ago. --Tgr (WMF) (talk) 00:09, 19 June 2014 (UTC)

Improvement
Thanks. Better now with "enlarge-button", but it could be more obvious.--Milseburg (talk) 17:56, 17 June 2014 (UTC)
 * I agree, it could be more obvious. "Prominent" (like it is promoted) is something different. I also have very mixed feelings about this Media Viewer. --Miss-Sophie (talk) 14:36, 18 June 2014 (UTC)

Clicking image
Why does clicking the image still not take you to the full resolution version? 86.179.5.128 02:17, 18 June 2014 (UTC)
 * Hi there. The action that happens when you click on the image itself is being "reserved," so-to-speak, for future development. The next version of Media Viewer will have full zoom-and-pan options so there is an option there; Media Viewer should also eventually support annotations in files, and clicking on the image might be needed for that. Those are just two of several possible use cases. Sorry that clicking on the image is not as intuitive as it was based on the old way of getting to full resolution :/ Keegan (WMF) (talk) 16:09, 19 June 2014 (UTC)

GREAT improvement! Almost a fifth as good as if this malware never existed.
Pictures like this need to be handled by the browser, with no layer hiding the page source in between.

Ceterum censeo: Media Viewer esse delendam. Tatzelbrumm (talk) 06:42, 18 June 2014 (UTC)


 * This is the best section on this entire page. ツ ツ I hereby award the best comment ribbon. Fylbecatulous (talk) 14:43, 26 June 2014 (UTC)

Where's quickie for the old image page?
I would have stuck it out if the help page had explained how to easily click through to what I had before, the plain old image upload page. I couldn't find that explained in under a minute or two, so I switched it off in my user preferences. As a general rule, I hardly ever like improvements that pretend that the ugly under-the-hood predecessor doesn't exist (or confine it's mention to an obscure footnote). Nor am I willing to wade through the documentation carefully until it's proven the feature and I can successfully co-exist. This Catch 22 scenario often makes me a late adopter. 154.20.45.238 07:09, 18 June 2014 (UTC)

What is the green hammer thing for?
What is the green hammer thing for that you get to by clicking on "use this image"? Also why doesn't the "preview in browser" link underneath it work. This pimple on Wikipedia just seems to get worse. Please cut your losses and just get rid of it!
 * Can you give a link to the case for which it is not working ? Because this option always works for me. Also please detail you browser and it's version, perhaps it is a browser specific problem. TheDJ (talk) 14:15, 18 June 2014 (UTC)

Cut your losses, guys
It must be pretty obvious to you all that this project has been a miserable failure. I have disabled it wherever I find it popping up. It does nothing for me, but it irritates me greatly. Why not just abandon it? If there is some problem you think it solves, design a solution from scratch. LynwoodF (talk) 16:25, 18 June 2014 (UTC)

Rename link "expanded view" as "show in Media Viewer" and add logo or title
I write the following under the pre-condition, that the reader (imagine an IP-user) is on the Wikimedia Commons page of a file, looking around for the various options, links etc.:

The link description on the button, which says "expanded view", is misleading. It gives the impression of either getting more information about the image than already are on the Commons page or - more likely - of immediately getting a larger version/the original resolution of this picture. Both isn't true (you only get the original file after a seond click within the Viewer, something that can much more easily be achieved by simply once clicking on the image on the Commons page, where the user is at this moment anyway).

I would prefer to call it by its name and write on the button "Show in/with Media Viewer". In additon I would like a little logo/title (if you partly copy Flickr, why not this element, too?) reading "Media Viewer" in the left upper corner, that tells the reader which tool he is using and enables him to draw a connection to the suggested button inscription and every Wiki (help) text that mentions Media Viewer. The small impressum at the end of the page ("About Media Viewer") escapes notice too easily. --Miss-Sophie (talk) 09:49, 19 June 2014 (UTC)

Lessons Unlearned
The latest version released to MediaWiki addresses many of the most critical concerns about the tool itself. I think the tool is nearing the point that it is a viable, shippable product. My question remains: How and when did you reach consensus to make the late-May version the universal default for all Wikis?

Did you, as Sven Manguard strongly recommended on 23 Nov 2013, consult any substantial portion of the Commons community? Why were the warnings of Vive la Rosière (22 Nov 2013) dismissed or deferred? When Pete F warned on 16 Feb that "enabling the Media Viewer by default will [likely] be rejected by the Wikimedia community," his narrow and immediate concerns were addressed but why was the larger point, that different workflow and usage patterns made MV a dangerous change that might be (and proved to be) incredibly disruptive and unpopular?

I don't hate the tool. I think the team did phenomenal work with the best interest of the WikiWorld at heart. I don't oppose change on first principle (far from it; I am an agile transformation specialist and change is both my life and my career). I just think that this implementation event is a massive red flag (a) that our consensus process is seriously broken, (b) that repeated, often-strident warnings from highly-respected editors were ignored and (c) that we have forgotten the lessons of history (Wikipedia Main Page Transformation, for instance) which taught us never, ever, ever to make fundamental changes to the user experience without exhaustive testing with the widest possible range of users.

I applaud the team and their work. It is an impressive tool for a certain type of user, showcasing first-rate code quality and a clean and highly-professional interface. I am terrified, however, that this is a sign of a sea change in our attitudes toward the user community. Editorship, collaboration and trust have eroded steadily since over the past six years. Is it inappropriate for us to request expect demand that project teams "first do not harm"? 159.53.110.143 01:04, 19 June 2014 (UTC) (Kevin)


 * Kevin, I'm glad my comments didn't go unnoticed. I continue to believe that there were major problems with both the process and the final product, and that the end result is a step backward, not a step forward. The two things that concern me the most are (1) the Media Viewer does a worse job of reporting information about personality rights, not better; and (2) end users will be less likely to see a path toward becoming contributors, when we should try to make them more likely to do so. Anyway, here is a link to the comment you reference: /Archive01 -Pete F (talk) 04:04, 25 June 2014 (UTC)

end users will be less likely to see a path toward becoming contributors - this sounds like it could be turned into a testable hypothesis. Basically you are predicting that there is a significant number of a) useful image edits or b) first edits after registration in the File: namespaces, and enabling MediaViewer causes these to drop. Does that sound correct? --Tgr (WMF) (talk) 07:35, 25 June 2014 (UTC)


 * Yes, it's a (theoretically) testable hypothesis.
 * Constructing an effective test would be difficult and time consuming, mainly because the percentage of people starting to edit after viewing a file is tiny to begin with.
 * Good grief -- now is when we start talking about testing stuff like this??!! -Pete F (talk) 14:28, 25 June 2014 (UTC)
 * Good grief -- now is when we start talking about testing stuff like this??!! -Pete F (talk) 14:28, 25 June 2014 (UTC)

Well if the number of people starting their career as Wikimedians on a file page is tiny (that would be my expectation as well), then the negative effect MediaViewer can have on them, if it exists, would be also tiny. So maybe your concerns are overstated? --Tgr (WMF) (talk) 04:46, 26 June 2014 (UTC)

Bug: when full screen mode is shut down, my browser window goes out of full screen mode, too
I use my Firefox browser on a Mac and usually in full screen mode. Now I find, that when I end the full screen mode for an image in Media Viewer, my browser window goes from full screen mode to a smaller window. The browser window should stay full screen sized, only Media Viewer should return to normal size. --Miss-Sophie (talk) 10:28, 19 June 2014 (UTC)
 * Reproduced and confirmed. I'll file the bug. Good catch, Miss-Sophie. Keegan (WMF) (talk) 17:08, 19 June 2014 (UTC)

Add a link in Wikipedia articles that leads directly to the file description page (avoiding Media Viewer)
There are many users (probably many with an account but also IPs without), that want to go directly to the file description page (on Commons or a local Wikipedia) for an image they see within a Wikipedia article. They don't want to go to Media Viewer first to then click on the Wikimedia Commons link there. So please give them the opportunity to do so, without the need to have an account and to be looged in, which is the only way at the moment to avoid Media Viwer by deactivating it in one's user settings.

My suggestion: There is this little button in the right lower corner of images within a Wikipedia article (an exception are images in infoboxes, maybe other forms I'm not aware of right now, too), the one that says "enlarge" when you go over it with a mouse. This button does the same like clicking on the image itself and is, I assume, hardly used, because clicking on the image is a much more direct way. Clicking on the image and clicking on the button both lead you to Media Viewer now. Why not give this button a new function and let it take the user to the description page (Commons page)? Give the button a new layout/symbol for clarification and invent something to also add this button to images within info boxes. --Miss-Sophie (talk) 11:18, 19 June 2014 (UTC)


 * I now have read, that one can also disable Media Viewer as an IP, by clicking a link in Media Viewer at the bottom, which leads to a file being saved on the IP's computer. I suppose this is a cookie? In the user settings of my browser I made Firefox always delete all cookies, once I have ended the application, because of security reasons. Since deleting cookies from time to time makes the Media Viewer cookie useless, so you would have to repeatedly disable Media Viewer (annoying), I still suggest the direct link to the description page. --Miss-Sophie (talk) 00:24, 20 June 2014 (UTC)
 * Actually the "file" that gets saved is an entry in the browser's localStorage object, which is not necessarily supported on all browsers. We don't track this at all, in fact, the value doesn't get sent to the server at all. You can turn off the viewer, as an IP, without any record on the server. Deleting your local tracking information may or may not delete the localStorage - check your settings for that :) --MarkTraceur (talk) 04:10, 20 June 2014 (UTC)
 * One reason more to think about my suggestion, if this file storage is not supported by every browser and might or might not work after deleting of local tracking information. Give people, depending on the role they are using Wikipedia in at a certain time (learner, photo viewer, editor, ...), the possibility to chose, if they need Media Viewer right now or the original file description page. From case to case, picture to picture, right there at the roots of chosing an image within a Wikipedia article for closer examination, not in general by deactivating and undeactivating the application. Some interesting thoughts also by others below, like the sidebar thing, though I would prefer to have the option for every single image. --Miss-Sophie (talk) 09:01, 20 June 2014 (UTC)
 * We have discussed that and similar approaches (display a small icon with a direct link on hover, add an option to the right-click menu). The main concern is the lack of discoverability: browsing help pages would be pretty much the only way of learning of such a feature. --Tgr (WMF) (talk) 22:12, 20 June 2014 (UTC)
 * Thats your own fault. You guys wanted this smartphone-style design, which doesnt ask people to participate or contribute but only to consume. So everything besides the compressed image is hard to discover - exept for those useless navigation arrows and the even more useless fullscreen mode of course. Alexpl (talk) 12:24, 21 June 2014 (UTC)
 * I imagine it must be easy to redirect the link from the little icon in thumbnails, which already exists, to the file description page (like it was before) and to give it a new label instead of "enlarge" plus a new design. Seemingly there weren't any worries about a lack of discoverability for the existing icon, as it is there, and also I had no problem with noticeing it on my own. You would then have to create the possibility to apply the same icon to images in infoboxes and galleries. I can't judge, how difficult the realization of the latter is. But you could start with the first change at least, which already would affect the largest part of images within articles. --Miss-Sophie (talk) 23:17, 22 June 2014 (UTC)
 * I would like the button/toggle functionality to view the file description with a one-click, so that I can enjoy Media Viewer as a general reader, then with one click convert the page disabling Media Viewer to check sourcing as an editor. In this way it would be a default feature, as I check through subsidiary/related articles for additional information as a reader and consistency as an editor. Then each time I returned to a page, I could easily go to any image and disable Media View to source check or better view charts or maps, especially those with great detail.


 * That's my "druthers", I don't think it should be either-or, I'd like it to be both available at a click on an image at each image, my choice. Otherwise, maybe a disabling opt out for the entire article in the "Tools" list on the sidebar. TheVirginiaHistorian (talk) 07:27, 20 June 2014 (UTC)

Toggle for every single image in an article to activate/deactivate Media Viewer for the click on the image
Another, I think better, idea based on what TheVirginiaHistorian wrote: I like the idea of a toggle. But it should be a toggle for every separate image in an article, not just for the whole page (since I understand, that is what he/she suggested). A toggle, that is in thumbnails placed instead of the icon "enlarge" and looks like the icon on Wikimedia Commons for the "expanded view" link (the picture with a landscape). This toggle provokes, that Media Viewer is either active for this certain image or not, with "active" meaning a one click on the image opens the file in Media Viewer and "not active" meaning a one click on the image opens the file description (Commons) page. The colour of the icon/toggle indicates, whether the Viewer is on or off (for example it is light blue, when it is active and grey, when it is not). Make it possible to apply the toggle/icon to images in infoboxes and galleries. One has to determine though, what should be the default setting when loading a page. I think, considering it is an encoclypedia and you can find more information on the description page, the default setting should be the not active icon. But every user should be able to change this in his user settings. So if somebody wants Media Viewer to be active / the toogle to be on as a standard, he can change this. Maybe make this setting also possible for IPs, like now with the stored file for Media Viewer. Plus place a toggler with the same icon at the beginning of the article page or in the sidebar tools, which allows to deactivate/activate Media Viewer for all images at once. What do you think, is this possible? --Miss-Sophie (talk) 13:16, 23 June 2014 (UTC)

Media Viewer is now live on all wikis
Hi folks, we're happy to announce that Media Viewer is now live on all wikis hosted by the Wikimedia Foundation!

Media Viewer is testing well on all remaining Wikipedias (e.g.: Chinese, Arabic, Hindu, Indonesian, etc.) and sister sites (e.g.: MetaWiki, Wikibooks, Wikiquotes, Wikiversity, Wiktionary). And the multimedia team worked hard in the last few weeks to develop a range of new improvements, in response to frequent community requests on this page and elsewhere. We hope you will try them out and let us know what you think.

1. Features on All Wikis These features are now available on all wikis as of today:
 * View original file (#630)
 * Scroll down to see more info (#697)
 * Show Commons link to logged out users (#429)
 * Easy opt-out for registered users (#703)
 * Opt-out for anons (#704)
 * Add more tooltips to Media Viewer (#546)

You can test these features on this on the English Wikipedia.

2. Features on MediaWiki.org only These features are now available on MediaWiki.org and will be deployed to all wikis by next Thursday:
 * Make it easier to find image information (#706)
 * Prominent links to different image sizes (#664)
 * Disable MediaViewer for certain images (#511)
 * Track 'View original file’ and ‘Commons link' clicks (#715, #726)
 * Track Media Viewer Opt-outs (/#558, #675)

You can test these features on this demo page on MediaWiki.org, as well as on this metrics dashboard — and learn more on this updated help page.

3. Features in development Other tasks in development or analysis include:
 * Show attribution credits in download tool (#598)
 * Make 'Commons link' and 'Use this file' more discoverable (#732)
 * Click on image in Media Viewer to help view original file (#712)
 * Improve Media Viewer UI on tablets (zoom/scroll) (#716)
 * Remember the last selection for ‘Use this file' (#660)

You can view more details about these features on this planning site.

4. Feedback Overall, we keep getting generally positive feedback worldwide, with these latest results:
 * A majority of global respondents find the tool useful (~60% average across surveys)
 * Cumulative approval by language: English 29%, French 70%, Spanish 78%, Dutch 59%, Portuguese 81%, German 28%, Hungarian 62%, Catalan 71% as of yesterday
 * Daily approval rates have increased on English Wikipedia from about 23% a day after launch to 39% two weeks after launch (and German approval has also increased from 23% to 56% in the same period).
 * We anticipate further approval increases on these sites, as more new features get rolled out in coming days, based on community feedback.

We are also starting to track opt-out rates to see how many people turn off Media Viewer in their preferences. As of June 16, about 875 users had disabled this feature on the English Wikipedia, two weeks after launch: this represents about 0.34% of all registered users who touched the site since launch. We are sorry that this small minority of users doesn’t like the tool, but we are glad that so many other users are finding it useful. :)


 * For example, I leave it active, because I'm waiting for the day that it no longer appears by default. This statistic says nothing. Hockei (talk) 12:22, 22 June 2014 (UTC)
 * Most users aren't critical thinkers who can distinguish good from bad. The ability to turn this off is hidden, so the fact that most people haven't turned it off merely proves they don't know how.  Also, that's not a good measure anyway, the proper analysis would look at who uses the wiki most, not the general occasionally browsing public.  Torch this awful media ruiner.
 * I also keep it on, just to see when this Beast will die. Concerning the survey, of course a simple statistical analysis shows that negative feedback is overwhelming and is even greater on langueages where the feedback button was left longer. As said just above, "Torch this awful media ruiner". --Michel le tigre (talk) 14:56, 9 July 2014 (UTC)
 * The opt-out stat is being misused. I haven't bothered to change prefs because I assume problems will be worked out, but they need fixed.  These features need incremental roll out, to 1-5-20-50%. Readers need a baseline for comparison, may not have.  Tonicmatic (talk) 04:57, 10 July 2014 (UTC)

Please let us know what you think of these new features. Which do you like most? least? Are there other must-have features that need to be developed right away, before we move on to other projects?

Thanks to all the community and team members for all you’ve done to make Media Viewer possible. :) Onward! Fabrice Florin (WMF) (talk) 18:14, 20 June 2014 (UTC)

Comments

 * On Feedback: 1. What kind of statistics are those, where you consider all wikis to have the same weight? I want to assume good faith but that approach is either manipulative or incredibly incompetent; 2. I never received any kind of survey in the three wikis where I work: Commons, en Wikipedia and pt Wikipedia. Neither was that survey announced. Caesar's wife must be above suspiction. -- Alvesgaspar (talk) 19:58, 20 June 2014 (UTC)
 * On your comment that we are glad that so many other users are finding it useful. :). What kind of decision process in this that changes the default viewing system of all wikis just because 60% of them considered it to be useful for viewing images and learning about them? I want to assume good faith but this approach is either manipulative or incredibly incompetent. Caesar's wife must be above suspiction. Alvesgaspar (talk) 20:43, 20 June 2014 (UTC)
 * I calculated the correct percentage of users (based on the published numbers) who considered the tool useful: it is 55.7%, not 60%. Not very promising, is it? -- Alvesgaspar (talk) 21:45, 20 June 2014 (UTC)
 * On your comment that this represents about 0.34% of all registered users who touched the site since launch. We are sorry that this small minority of users doesn’t like the tool. You forgot, of course, to say what is the percentage of all registered users still active. Or to make the distinction between the casual users and the frequent ones. Sorry, but this time it is difficult to me to assume good faith. Alvesgaspar (talk) 21:41, 20 June 2014 (UTC)


 * As a frequent Wikipedia user who dowloads many images, I hate the new viewer so much that I ALWAYS either Ctrl-click or middle-click on images so I can view them properly (i.e. on the Wikimedia Commons page). It is annoying to have to open a new tab, but not as annoying as having my screen obscured by a javascript-driven monstrosity. What I want to know is, are users who access the Wikimedia Commons pages like me being counted among those who are not using the new media viewer? I suspect not! Also, regardless of the "approval" figures for the new viewer, what were the disapproval ratings for the old viewing system? I am not aware that there was any widespread dissatisfaction which warranted the introduction of the picture viewer. The Wikimedia commons pages were befitting an encyclopedia, whereas the new picture viewer is reminiscent of a dumbed-down social media site. Very sad. D, 21st June 2014


 * That's interesting with pressing ctrl in an article! I didn't know, you could directly open the file in Wikimedia Commons this way. Good to know, but that shouldn't be the only way to do so, since many more people apart from me don't know this probably. I partly like Media Viewer (the slide show option), but it's not always what I want to do, so I would like to chose from case to case (see my comments in the section above). And Media Viewer should not hide important information of how to use a file, especially for uninformed readers! That's realy bad right now and I don't understand, why Media Viewer is nevertheless already standard for all readers. I want to remark, that just because I didn't deactivate the application, this doesn't mean I agree with everything the tool involves. What does this mean, people, who opened Media Viewer and didn't deactivate the tool afterwards, find it useful? If you want to imply with this, that they prefer it to the Commons page, this would be putting words into their mouths. Maybe they don't care about it, see it's new and that's all. Even if some think it's better, because the image is presented centered and looks nice and that's most important for them, they might just not mind or see the lacks of Media Viewer, because they focus on how the image looks and is described in a certain article and are not that interested in which and how image information is presented outside of it. That doesn't mean, there are no lacks. -Miss-Sophie (talk) 20:08, 21 June 2014 (UTC)


 * Thank you all for your comments about Media Viewer. I have responded below to some of the key concerns you raised above. Fabrice Florin (WMF) (talk) 00:53, 25 June 2014 (UTC)


 * Alvesgaspar, in response to your first point above, keep in mind that the primary intent of this short-term Media Viewer survey was to get qualitative feedback from all users, not to provide a long-term quantitative metric of acceptance for this tool. So while the feedback we collected was invaluable and helped us improve a number of issues, we should all interpret the quantitative results with caution. To answer your second question, the survey is now available to all Media Viewer users on enwiki, commons and pt sites: simply open Media Viewer and click on the bullhorn icon to post your feedback in a pop-up window. To answer your third question, over dozens of separate announcements were made in the past two months on all our sites; in the English Wikipedia alone, we invited feedback on the Village Pump and other community hubs (announcement 1, 2, 3, 4, 5, 6, 7, 8, 9 and 10). In response to your fifth point, you are correct that the average across all users is 55.7% (that number had not been verified when I filed this update, which is why I used the number across surveys instead). Note that this average hovered between 60% and 70% approval for months, until the recent launch on the English and German Wikipedias, where post-launch negative feedback brought it back down for a few weeks. However, we observed that the rate of users who find the tool useful is usually lower for the first few weeks after launch, and typically increases after users become familiar with the tool and its new features: for example, Hungarian approvals started at 42% and grew to over 60% in about a month. Similarly, daily approvals from English users started at 23% right after launch and have grown to 48% two weeks later, as shown in this survey dashboard (2nd graph). That said, this survey was never intended to be a long-term metric for this project -- and we plan to end it next month, now that we have enough feedback for development purposes. Going forward, we will focus on image views and disable rates as our main metrics, because they provide a more accurate indication of the tool's actual usage. In response to your sixth point about the 0.34% disable rate, I would like to clarify that it is based on the cumulative number of registered users who disabled Media Viewer in their preferences (875), divided by the total users who made an edit or changed their preferences since Media Viewer was launched on the English Wikipedia (260,450); it is not based on total registered users, which would yield a much lower percentage. We think that metric gives us a better representation of the community's overall acceptance of this feature, particularly now that we've made it much easier for both registered and unregistered users to disable the tool with a single click, right inside Media Viewer. Lastly, your insinuation that we are not working in good faith doesn't seem fair or accurate: over the past year, we have fully disclosed all of our findings, in good faith and gone out of our way to be as transparent as we could. We have also engaged community members extensively at each step of the way, starting with over ten separate discussions since June 2013. The tool was then widely tested by over 25,000 beta users on all our sites since November 2013, as part of our Beta Features program. And in the past two months, we have collected over 15,000 survey responses from a wide range of user groups, as well as on talk pages like this one, and responded to their requests with many new improvements. All this provides ample evidence to support our position that we have consistently acted in good faith and actively engaged community members throughout this project. Fabrice Florin (WMF) (talk) 00:53, 25 June 2014 (UTC)


 * Miss-Sophie: I am glad that you found out how to bypass Media Viewer, as further described in this Help FAQ page. Your point is well taken that there are a number of users who have chosen not to disable Media Viewers but still think it has issues. We are working in good faith with these users to improve the tool, as you can tell from the long list of features we just enabled based on their feedback. But we believe that most users who strongly object to the tool will eventually disable it, which should provide us with an objective metric for tracking this disapproval. We welcome other practical ideas for tracking community acceptance consistently across all user groups. But this approach seems reasonable and feasible right away, without requiring more development resources than we currently have. We hope that over time, this and other metrics will help us all make more informed decisions together about next steps for this project. Thanks for your other thoughtful observations on this page, which are much appreciated. Fabrice Florin (WMF) (talk) 00:53, 25 June 2014 (UTC)


 * I have logged in to Wikipedia since the launch, but didn't realize that it was live on my account until recently, and then I went into my preferences to try and turn it off and couldn't figure out how. I finally had to click on a random image and click to disable it. I hate this "feature", and I don't think it's any measure of its reception that such a small percentage of people went through the effort to turn it off (chances are most people assumed it was a permanent change that was being foisted on them anyway). It should be off by default. It's going to be annoying to have to log in or turn it off every single time I clear my cookies, or any time I use wikipedia on a new browser. This adds nothing to the old way of doing things, as is abundantly clear from the huge volume of negative comments on this page. 0x0077BE [talk/contrib] 01:36, 27 June 2014 (UTC)


 * Two style suggestions: (1) Don't utilize icons that can be 'symmetrically interpreted', in this case the arrows.  Some think a down-arrow means 'there is more below'; others think it means 'push this thing down'.  In this case, I would suggest words: 'more' and 'less'. (2) Don't obscure significant amounts of screen space with a partially hidden object.  In this case, roughly 5% (vertically) of the screen, at the bottom, is covered by the mostly-hidden additional info (which the above arrows reveal / hide.)  This is one of the things that I think killed the new Google Maps.  That said, this seems to me (not a style expert) a harder problem... perhaps a floating, semi-transparent 'switch' somewhere near a corner of the screen (upper right would be my preference, but preferences vary)?  My first impression of the new feature was not especially positive, primarily because of the above two issues.   DrTLesterThomas (talk) 13:18, 9 July 2014 (UTC)
 * Words can't be used, as this thing was to be imposed on all languages of WP. Better just kill it.--Michel le tigre (talk) 14:26, 9 July 2014 (UTC)

SurveyMonkey Feedback
Why does Fabrice, who as far as I can tell is one of the main perpetrators of this attack on Wikipedia users, keep waving some randomly chosen figures from a "survey" which clearly has never been anywhere near a statistician. A few things:


 * WTF is being meant by the thing "being useful"? Do you realise that usefulness (unless very strictly defined in a particular context) is not a measurable quantity and therefore no good as a metric?


 * Why are you asking two questions at once, to which only a single answer can be provided?


 * I tried opening the so-called "survey" page multiple times, and as far as I can see, the order of the response choices is not randomised: "Yes" always comes first. I hope you are not aware of first choice bias, otherwise you are being deliberately manipulative.


 * Where is the "Elephant in the Room" question? Namely: whether the user would rather use this contraption or the traditional, and mostly well-designed system.


 * Why is all the qualitative feedback here being utterly ignored, unless it can be manipulated to further prolong the existence of this crap?

Fabrice, I am well aware of the saying that tells us not to ascribe to malice what can be explained as stupidity. However, I do note they're not mutually exclusive. Making mistakes, sometimes pretty big ones, is part and parcel of any job. Plowing forward after mistakes have been pointed out, especially by attempting to ignore criticism, is irresponsible and a sign of cowardice and immaturity--hardly desirable characteristics in a competent project manager. Take this criticism from a another project manager, having made pretty big and stupid mistakes myself I know what it's like, but as one of my mentors said, one must always come forward, acknowledge one's failures and learn from them. Everyone comes off better in the long run.

And to sign off, let me give you a free pro-tip: when you've got a big and complex product that is used by millions of users, radical and disruptive changes are not welcome. Always proceed in small incremental steps, and be prepared to back off at the first sign of trouble.


 * Well said! This "Media Viewer" is a disaster, and its implementation and fanatical defense in the face of broad, detailed, sustained criticism is a poor reflection upon the person responsible for leading the debacle. Jdanek007 (talk) 00:12, 3 July 2014 (UTC)


 * Exactly, and according to the dubious survey only 36.07% of people actually found it useful. I despise this media viewer, and find it hilarious the way it has been forced on everyone, and with this bizarre proclamation that black is white and it's actually wonderful and loved by all. It is utterly utterly dreadful and should be destroyed. --Gjackson123 (talk) 17:09, 7 July 2014 (UTC)

Bug: "Close this tool. Or press Esc to exit" pop up doesn't go away
The "Close this tool. Or press Esc to exit" pop up, that appears when moving the mouse on the X in the right upper corner of Media Viwer, doesn't go away under the following conditions: I opened an image from a Wikipedia article with Media Viewer and went with the mouse to the X until the description popped up, then I clicked the X to exit. When I then click on another or the same image from the article, Media Viewer oppens with still showing this pop up, that stays while sliding through the images and only vanishes, when I once again move the mouse onto the X.

Also, comming from a German Wikipedia article, this pop up text is in English instad of a German translation like the rest of the user interface. --Miss-Sophie (talk) 21:17, 20 June 2014 (UTC)


 * The latter is probably a lack of translation. At the moment everything is translated, so you will see the correct text as soon as the software is updated (within a day, usually). --Tgr (WMF) (talk) 22:10, 20 June 2014 (UTC)

Addition: The pop up not just stays within Media Viewer, it even stays visible in the Wikipedia article after closing Media Viewer! It covers the search field in the right upper corner of the page, when doing what I described. --Miss-Sophie (talk) 00:18, 21 June 2014 (UTC)

Keep Optional
I hope we have the option to keep it disabled. I don't like it because I don't like change or new stuff... Smarkflea (talk) 21:58, 20 June 2014 (UTC)
 * The option to disable Media Viewer is not going away, no worries :) Keegan (WMF) (talk) 18:11, 21 June 2014 (UTC)

Make it stop
Please. Your tool is unwanted by the vast majority. Its slow, cumbersome, annoying, unintuitive, painful.

Please disable this tool until you have an RfC on each deployed to wiki. DaveJohnson (talk) 03:38, 21 June 2014 (UTC)

Distorted picture + "View original file" not working + content disappearing
Win 7 / IE 11

Shut down and reopen browser. Go to http://en.wikipedia.org/wiki/Main_Page. Click on today's featured picture, which is http://commons.wikimedia.org/wiki/File:A_couple_of_Tadorna_ferruginea.jpg. The picture in Media Viewer is stretched horizontally to about twice its correct width, and the "View original file" link does not work either.

Now click left arrow, then right arrow, and all the content (text + buttons) in the lower pane has disappeared.

Retrurning to the picture after viewing other pages, the picture sometimes displays correctly, sometimes not. I do not know the exact circumstances which determine this. However, when I follow the above sequence, it always breaks. 86.179.0.254 02:13, 22 June 2014 (UTC)
 * I was able to reproduce at least the image being stretched in IE 11 on Windows 7. I cannot reproduce the right/left shifting issues with the specified image since it's no longer in the context of the Main Page and I didn't encounter similar issues with today's Main Page Featured Picture. Thanks for the information so it can get fixed :) Keegan (WMF) (talk) 21:21, 23 June 2014 (UTC)

This seems to be the combination of (for which the fix will be deployed on Thursday) and some different, IE11-specific issue. Couldn't reproduce any issues with "view original file" though.

For next/prev issues, can you share the URL your browser shows when you are viewing ther image? (Preferably with something that's not on the main page, since those links don't work for long.) --Tgr (WMF) (talk) 21:36, 23 June 2014 (UTC)

Very low approval rating
According to their own survey, media viewer has received a very low approval rating on English Wikipedia, where the greater majority of editors and viewers abide, with only a 29% approval rating, which means of course that 71% disapprove. Even with the new features, (an attempt to make media viewer do some of the things that we were able to do in the first place) approval has only increased to 39% recently, which means that 61% disapprove. Then we are told that 875 registered users have disabled it (in only 2+ weeks!) since media viewer was forced on everyone, with the claim that this represents 0.34% of all registered users. Is this globally, or for English Wikipedia?? Since many registered users haven't logged on in weeks, months and even years, this 'statistic' is very deceptive and misleading. Esp since the disable feature was not available at first and continues to be obscure, tucked away at the bottom of the popup screen where it will get unnoticed by the majority of viewers who peek at images in full view occasionally. Media viewer should only be a default viewer where there is overwhelming approval for it, and it's perfectly clear, there is overwhelming disapproval for it on English Wikipedia. Their own statistics back this up. People who use Wikipedia as an encyclopedia don't need a default slideshow. It should be an option when one clicks on an image -- not the other way around. Why they came up with this viewer in the first place still remains a mystery. To be fair to the debate, they need to take a separate survey of experienced editors and see how it fares. Meanwhile registered and unregistered users continue to leave overwhelmingly negative feed back at the English Wikipedia RfC and here on the media viewer talk page. We can only hope that the individuals who are promoting media viewer share the same spirit of Wikipeida and abide by the same ethics as do most of their fellow editors, and will respect consensus and the decision of the RfC which is presently examining this issue. -- Gwillhickers (talk) 18:01, 22 June 2014 (UTC)

Redundant
My browser has an image viewer, and I don't like this javascript one. 76.185.182.224 20:08, 22 June 2014 (UTC) This. A thousand times this. You are engaging in one of the classic blunders by this shitty re-implementation of already-existing functionality. Make it opt-in until you have something that is worth using.


 * Totally what the fellow above says.

Aspect ratio screwed up, confusion about "More details" link to Wikipedia's or Common's file info page
When I click on one of the pics on today's main page, Media Viewer displays it with the aspect ratio all wrong; the face about twice as wide as it should be. I'm using IE11 on Win 7.

I'm also noticing that the "More details" button in the lower right for this image goes to the Wikipedia info page, while for another image on today's main page, the "More details" link goes to Commons. Which one is it supposed to be?

Further, I still see that Media Viewer interacts unexpectedly with the browser's most important feature: the back navigation button.

These bugs aside, the best solution would be to dump the new annoying Media Viewer altogether. It's not half as well implemented as the similar javascript toys it apes from social media sites etc, and even if it were, it doesn't belong on an encyclopedia.
 * Hi there.
 * More details: Why does one say Wikipedia and one say Commons? This isn't a Media Viewer issue, this is an issue of how and where files are stored on Wikimedia projects, and why. The File: pages do not make this much more clear, either. Sometimes there's a box that says that a File is hosted on Commons and everything you see on the English Wikipedia is automagically appearing; other times files are locally hosted and need to be copied to Commons, sometimes local files can't be copied for technical reasons (For example, the Felipe image is temporarily hosted on the English Wikipedia so that it can be protected from vandalism locally while on the main page).
 * As for the back button, there's a pretty intense debate over this very issue on bugzilla. FWIW, I agree about the back button not behaving as I expect it to, but Gilles makes excellent points about why the browser history behaves as it does and what I expect isn't necessarily the best use case. It's good reading.
 * I'm sorry that you didn't enjoy Media Viewer and I hope you found the way to disable it for now. Media Viewer will be developed further in the future, I hope you take some time then to see if you like it any better. Thanks for your time. Keegan (WMF) (talk) 19:11, 23 June 2014 (UTC)

Media Viewer can't include certain image descriptions from Commons page
I notice, that for the above linked painting Media Viewer isn't able to include the description of the painting from Commons, which involves information about the painting technique, the size of this artwork and the museum. Media Viewer doesn't show any description. --Miss-Sophie (talk) 10:16, 23 June 2014 (UTC)
 * Looks like Media Viewer is having trouble scraping that Artwork template. Thanks, will look into this. Keegan (WMF) (talk) 19:16, 23 June 2014 (UTC)

Not sure what should be done differently here. We scrape the author, source and date correctly. (Well, for some value of correct - see .) There is no description field in the template, nor anything else that should be shown in the metadata panel, as far as I can see. --Tgr (WMF) (talk) 23:07, 26 June 2014 (UTC)

Yay! Shift-click to avoid this rubbish
I was pleased to learn that shift-click opens the proper way mage page. Media Mangler simply does not work in my office environment (probably due to the security settings that I cannot change).

Now, if only there was a way to get rid of this from my mobile device...


 * I haven't tried it myself, but I suspect that if you do a long click (or press or whatever it's called) then choose the option to open in a new tab (if your mobile browser has this feature, like Firefox), then you might be safe from this sorry piece of unwanted shit that nobody asked for in the first place. Hope this helps.

+1 to the comment regarding 0.34% of user IDs complaining, and how this is a figure completely skewed and manipulated to serve an agenda. I rarely log in to Wikipedia, but use it quite a lot. Remember, any online survey is likely to prove that 100% of the world has internet access... all you're actually proving is that everyone who has internet access has internet access, ignoring the billions who do not.

Scrap Media Mangler now!
 * Sorry that you didn't care for the Media Viewer experience, do note that even as an IP you can disable Media Viewer by pulling up the fold of information and clicking "Disable Media Viewer." That should work for your mobile device as well. Hope that helps.
 * 0.34% of active users on the English Wikipedia have disabled Media Viewer. This is true. The English Wikipedia has, as of this writing, 126,977 accounts that made at least one edit in the past month. Of those, ~30,000 accounts made at least five edits in the past month- the "active editors." 875 into 30,000 gives a result of 0.34%. Some may not like these numbers, but they are true.

Keegan (WMF) (talk) 18:55, 23 June 2014 (UTC)
 * Not so: 875 divided by 30,000 is 2.9%, not 0.34% ! Some may not like Math but is useful at times... -- Alvesgaspar (talk) 21:06, 23 June 2014 (UTC)
 * :) You are correct; it seems like the conflict comes from where Fabrice said "all registered users who have touched the site" versus what I'm using as a metric, that is "active users." I confused myself here, sorry about that. To say: 2.9% of active editors have disabled Media Viewer. Keegan (WMF) (talk) 21:32, 23 June 2014 (UTC)
 * 1.5% of the active editors, actually. Only about half of those who have disabled were active. --Tgr (WMF) (talk) 00:30, 24 June 2014 (UTC)
 * You know that it is a very, very big lie. It is only statistics. But... most of users don't know possibility to disable that crap and most users don't work with images. Ahsoous (talk) 20:03, 23 June 2014 (UTC)
 * The biggest problem with these statistics is of course awareness of how to disable Media Viewer and the very reasonable bias towards not changing settings in general. All designers know that the choice of defaults is incredibly important for user experience. What you need to do is to return to the original file information page by default, offer Media Viewer as an opt-in on the user settings page and see how many chose it. I doubt it would be many even if there was an awareness campaign a la the fundraising banners.
 * A very big lie. You might as well say, "Only 875 people out of the 7 billion on the planet have disabled the Media Viewer." How stupid do you think we are? DaveJohnson (talk) 03:02, 24 June 2014 (UTC)
 * Yeah I thought that. Visitors have to disable the thing right now to get key information, like placenames, from larger svg maps for example. And they dont do it? Alexpl (talk) 09:49, 25 June 2014 (UTC)
 * "... even as an IP you can disable Media Viewer by pulling up the fold of information and clicking "Disable Media Viewer."" Thank you for pointing me to how to disable the media viewer, might I suggest this disable link is placed far more prominently right at the top? Just beforehand I had left a feedback requesting a clear way to disable it, together with my disappointment in the sad trend of ignoring the community by some elements of the foundation. Anyway, the first few times I clicked on an image, expecting to see the usual file description page, I thought I had some gadget or beta feature enabled in my preferences and simply could not find a way to disable it. Please do not require users to hunt for basic stuff such as this. To my mind any globally made changes such as this requires a very clear "return to old behaviour" button. I also was not aware of any survey or questionnaire asking wikipedians about this (I hardly edit now, but still read the articles). -84user (talk) 06:47, 1 July 2014 (UTC)

Bug: While flipping through images in the slide show Media Viewer confuses the author information for certain images (the ones on Wikipedias?)
I skipped through the images from the and noticed, that Media Viewer doesn't show the correct author information for this one particular file of the band logo, when clicking the forward or return button. The application takes the author information from the previous or the following file, depending on which button you used. It's the only file of the lot with a Wikipedia location, so maybe it has something to do with this? --Miss-Sophie (talk) 10:25, 23 June 2014 (UTC)

Addition: This seems only to happen under certain conditions. If I start using Media Viewer with the logo file, the problem only occurs when clicking return for at least two images (and then going forward again to the logo file) or forward for at least four images (and then going back again to the logo file). It doesn't happen, when you click back or forward just once to the directly previous or next file. Once it's wrong though, it stays wrong, which means, that when I close Media Viewer and then click again on the logo image, it's still the wrong author information from before. When I start with another image from the refreshed article it is accordingly: The problem starts with an image two steps before the logo (the band montage) and with an image four steps after (the one from Chicago 1975). --Miss-Sophie (talk) 10:40, 23 June 2014 (UTC)
 * Oh how bizarre this is. I think the problem might lie in the English Wikipedia File page where the logo image is hosted, Thoughts, when you get time? Keegan (WMF) (talk) 19:02, 23 June 2014 (UTC)

It is a bug with emptying the panel. (The conditions to reproduce are very weird, no idea how that came about.) Thanks for catching! --Tgr (WMF) (talk) 01:44, 24 June 2014 (UTC)

Bug? MV confuses file name with article name
I've noticed that, when you open an image on a wikipedia page, the name displayed is the WP page name, instead of the file name. For example: open https://en.wikipedia.org/wiki/Realgar and click on any image. The page name also shows up in the browser history page, which makes it harder to get back to the image later, as both image and article are labelled "Realgar".

My setup: Firefox 30.0/Mac OS-X

No biggie, but an annoyance. --Tillman (talk) 19:19, 23 June 2014 (UTC)

good idea, thanks! --Tgr (WMF) (talk) 22:45, 23 June 2014 (UTC)

I Call FOUL!
To repeat (ad nauseam), I don't hate this tool. I think the dev team did a great job. I object to the implementation, and especially to the misleading info in and similar posts. I make no assumption that anyone is trying to mislead or deliberately cherry-picking data, but the end result is factually misleading.

"Cumulative approval by language: English 29%, French 70%, Spanish 78%, Dutch 59%, Portuguese 81%, German 28%, Hungarian 62%, Catalan 71% as of yesterday." That sounds great until you do the math. I will always AGF, but Disraeli and Twain must be having quite the chuckle over this.

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).

If we take the actual, raw numbers provided, we have to accept one of the following conclusions:
 * 39.13% of active Wikipedia users approve of the tool
 * 37.84% of MediaWiki users approve of the tool
 * 33.29% of users on Wikipedia sites weighted by number of images approve of the tool
 * 33.67% of users on MediaWiki projects weighted by number of images approve of the tool
 * 73.02% of users approve of this tool because the two languages with largest active Wikipedia user-communities, English and German, just don't matter that much and they'll come to their senses soon enough.
 * Insert : Where are you getting "73.02%" if an average of only 35% approve?
 * Insert: I think this was included to illustrate the absurdity of the "logic" that could lead to the conclusion that a majority of users approve of the tool -- i.e., that you would have to ignore English and German projects in order to arrive at a number like this. I could be wrong, but that's how I read it. -Pete F (talk) 18:18, 25 June 2014 (UTC)

Again, I don't hate the tool and I don't hate the team and I don't ascribe conspiratorial or malicious motives onto Media Viewer's supporters. I just want Keegan's request from 24 May honoured: "Personally, I'd like to make sure that the discussion is not based on 'I don't like it and I don't think anyone else does either' but actually had solid numbers and facts on how communities feel about Media Viewer…" Can we please give each other at least that much respect? 159.53.174.145 19:54, 23 June 2014 (UTC) (Kevin)

Hi Kevin,

our rollout strategy was to deploy Media Viewer (after an extensive beta period) to some small wikis, then increasingly larger ones, using the survey results as predictors for the next batch. Obviously that didn't work well for EN/DE, but that only became obvious after we rolled out on those sites; so I am not sure what you find surprising or shady in the choice of surveys.

The huge difference in results per site certainly questions the usefulness of these surveys - given that there is no reason why the viewer would be more useful or less annoying for French readers than for English ones, there should be some external factors causing that difference; and a survey with external factors causing a +-50% bias is not very valuable. That would have been nice to know beforehand, but we didn't; the results before en/de seemed fairly consistent. We should have done small-scale tests on enwiki instead of assuming that the results from other sites can be interpolated, but, well, hindsight is 20/20... --Tgr (WMF) (talk) 07:20, 25 June 2014 (UTC)


 * @Tgr: A fair and reasonable answer, and I truly appreciate it. I also appreciate the predicament of any product team whose only chance to spot a landmine comes after detonation. It's neither nice nor fun, and I've been down that road more often that I'd like to admit. It chafes that some other members of the team are still trying to hide behind the fig-leaves of dubious statistics and dodgy self-justification, but that's not the point. My concern for future projects outweighs my ire over this one -- We MUST learn from this. We have to rebuild our consensus process to give more weight to naysayers and less to proponents of change. We also have to admit that our decision-making has an intrinsic bias toward "Hard Core Wiki-Wonks" -- we need to compensate to get valid input from a true cross-section, especially non-account-holders whose usage patterns vary wildly from True Believers and whose input is rarely solicited and (when offered) usually ignored. While I am an anon here due to my corporate system setup, I've been an active editor on EN projects since 2003. This really is the first project I've seen that (a) fundamentally changed the user experience and (b) provided no reasonable method to restore the previous experience. Combined with the lack of input from massive, critical sectors of our community (like anons and most Commons people), that should have been recognised as an invitation to disaster. It terrifies me that all of those warning signs were missed and I pray that changes are in the works to prevent the same failure mode for other projects. 159.53.110.140 16:10, 25 June 2014 (UTC)(Kevin)
 * At this point it's safe to assume that the warning signs weren't missed, they were ignored, just as they are ignoring their own statistics which reveal majority disapproval on English Wikipedia and the overwhelming negative feedback here and at the RfC where this issue is presently being examined. -- Gwillhickers (talk) 16:57, 25 June 2014 (UTC)
 * Kevin, we made a lot of effort to get input from various stakeholder groups at Commons. Media Viewer has a discussion page there, we posted to commons-l several times, organized round tables, held office hours on IRC, plus probably did a bunch of things that I don't know about. I am sure we still didn't collect input from most Commons users (there are, what, ten thousand of them?) but we got a pretty good cross-section of the concerns of the Commons community, and enough feature requests to keep us busy for three years. Too bad we only had a half.
 * That is usually underappreciated in these kinds of discussions: that we are talking about projects with finite resources (very finite, given the limitations of being a nonprofit), so fulfilling every person's every expectation is just not an option. The people who work on personality rights feel it will be a huge step backwards if Media Viewer does not warn about them, the people who work with GLAMs think those collaborations are threatened if it does not display institutional templates, the people who work with licenses say it must display all custom attribution and permission details down to the last dot, those who work on categorization feel their work is made meaningless if MediaViewer does not display categories, and so on and so forth. Everyone has their pet topic to push, with a fair amount of overestimation of their importance, as it usually happens with pet topics; the only thing no one seems to care about is the actual user experience of looking at an image. Which sucked horribly. And only, oh, 99% or so of the readers care about that, as opposed to multi-licenses and warnings about panorama freedom and displaying the file history. Someone has to advocate for the needs of the average reader, and that job historically falls to the WMF because no one else seems to be interested. And that means sometimes the WMF has to make decisions which make everyone else unhappy. Considering all that, I think we have gone to great lengths to accommodate the most important requests of the Commons community and have generally done a decent job of prioritizing those requests (although in hindsight we should probably have opted for less kinds of metadata, but better displayed).
 * The anon issue, on the other hand, was a complete blind spot. There was just no way to support all the non-basic usage patterns of the file page, so we relied on Media Viewer having a disable switch, and it never occurred for us that that won't work for anons. Yes, that was stupid. As you say, fundamental changes to the reader's user experience are rare (though not unheard of; the switch to the Vector skin being one example), so there is less organizational memory for handling that sort of stuff. A weak excuse but it's all I have. At least we will now remember for a while to plan for anonymous users, I guess. --Tgr (WMF) (talk) 06:02, 26 June 2014 (UTC)
 * The anon issue, on the other hand, was a complete blind spot. There was just no way to support all the non-basic usage patterns of the file page, so we relied on Media Viewer having a disable switch, and it never occurred for us that that won't work for anons. Yes, that was stupid. As you say, fundamental changes to the reader's user experience are rare (though not unheard of; the switch to the Vector skin being one example), so there is less organizational memory for handling that sort of stuff. A weak excuse but it's all I have. At least we will now remember for a while to plan for anonymous users, I guess. --Tgr (WMF) (talk) 06:02, 26 June 2014 (UTC)
 * The anon issue, on the other hand, was a complete blind spot. There was just no way to support all the non-basic usage patterns of the file page, so we relied on Media Viewer having a disable switch, and it never occurred for us that that won't work for anons. Yes, that was stupid. As you say, fundamental changes to the reader's user experience are rare (though not unheard of; the switch to the Vector skin being one example), so there is less organizational memory for handling that sort of stuff. A weak excuse but it's all I have. At least we will now remember for a while to plan for anonymous users, I guess. --Tgr (WMF) (talk) 06:02, 26 June 2014 (UTC)


 * Tgr (WMF) Quote: "...the only thing no one seems to care about is the actual user experience of looking at an image. Which sucked horribly. And only, oh, 99% or so of the readers care about that..." - Dude, whatever. My experience of "looking at an image" didn't "suck horribly" before the implementation of Media Viewer. But it certainly has now, since MV was forced on me, and deployed universally. Oh, and I assume we're both thinking of the same "suck" metric...sheesh. Jdanek007 (talk) 21:51, 4 July 2014 (UTC)
 * That is NOT a weak answer; it's directly on point and completely honest (and very much appreciated). A few notes:
 * My apologies for an incorrect assumption on engagement level for Commons, but there just isn't anything I could find on the project site to suggest that that base had been covered.
 * Anyone who expects a product (especially a new one) to fulfil every expectation from every user need serious attention from a mental health professional.
 * I am painfully familiar with "200% demand on 50% resource" teams; it's what I do for a living. ;) I have tried to make sure in every post to respect and recognise the effort of the team who built this product.
 * The voice of the consumer (in this case the WMF) is lightning rod of any blame-storm. It's a miserable position to hold when the ship sinks, especially if you had weren't allowed to touch the rudder before the team hit the reef.
 * Processes improve through failure, not success. I am (pardon the contradiction) shocked but not surprised that anons were missed. It's easy to miss those who are systemically, structurally excluded from most conversations.
 * A lot of the rage, imho, came from a small but incredibly critical set of missteps. Honestly, very little outrage was driven directly from the feature set; instead, the features became the whipping boys for procedural failures. I feel they can be summarized (details later if wanted), (1) the sense of surprise; the appearance of (2) denial, (3) condescension and (4) diversion on the part of some defenders; and (5) opacity of project history, process and direction.
 * I am not backing away from my belief that Media Viewer should not be a default feature and stand by my concerns that the original consensus was flawed. But that ship has sailed (and, imho, sank like a rock). We need to make sure that future projects don't founder on the same rocks and, where possible, equip them with tools to avoid similar situations.159.53.110.143 14:11, 26 June 2014 (UTC)(Kevin)

Strange. Only in the English and German Wikipedia can I find the feedback button. No way to express one's opinion in other languages? is something wrong with my IP or what?--Michel le tigre (talk) 08:43, 5 July 2014 (UTC)

No authorship for no Wiki Commons files
Why the new interface view, not seen authorship images that are not uploaded to the Wiki Commons. In Ukraine there is no freedom of panorama, this many photos loaded on servers is Wikipedia. Thanks in advance for the answer and solution.--AlexusUkr (talk) 10:10, 24 June 2014 (UTC)

Hi please see Multimedia/Media Viewer/Template compatibility. --Tgr (WMF) (talk) 01:08, 25 June 2014 (UTC)

Mistake in German translation
The plural of "Website" is "Websites", also in German. At the moment it says "Webseiten" (eng.: Web pages) instead in the column on the right, where the usages of an image are partly listed. That's a common mistake, because "site" and "seite" sound similar in German. I don't think I'm able to correct this myself (plus to add a translation for the escape button X in the right upper corner)? --Miss-Sophie (talk) 11:09, 24 June 2014 (UTC)

You can translate the messages on Translatewiki. --Tgr (WMF) (talk) 01:06, 25 June 2014 (UTC)


 * No, I can't. Seemingly I didn't pass their quality test, but they sadly don't tell me precisely, why, in the e-mail. I opened an account and they gave me some things to translate from English into German as a trial, so maybe I didn't get the context right for some of them, or my English is insufficient, even though I seriously did my best. If they hadn't asked me for a translation of those of all things, I wouldn't even have tried to translate them. I just guessed the context and skipped the strangest ones, when I couldn't imagine the meaning/context. That's annoying, since I just would like to see this one wrong plural corrected and a translation for the escape tooltip added. Maybe I should have read their FAQs and all help pages before, but I don't feel like going into all of this. So I have to wait till somebody else maybe translates and corrects the mistake ... --Miss-Sophie (talk) 20:32, 25 June 2014 (UTC)
 * Uh... I have no idea how that works, to be honest. For smaller languages, you just need to say "Hey, I am willing to translate!" and they shove the bit at you; the German translator community might have their own rules. In that case, just tell them to fix this :-) At any rate, there is no special method for developers to translate things, it has to be done at Translatewiki. --Tgr (WMF) (talk) 21:31, 25 June 2014 (UTC)
 * Translatewiki deleted my new account twice, after they had told me in the e-mail, I didn't pass. So I think, I would have to ask on one of the talk pages as an IP. I'm feeling a bit put off right now. --Miss-Sophie (talk) 21:53, 25 June 2014 (UTC)
 * Translatewiki.net changed their process a while ago, after encountering some problems. People need to take a "test", which is then reviewed and accounts approved manually.  I don't know what quality standard they use; for a major language like German, it might be quite high.  User:Miss-Sophie, I hope that you will consider translating here at MediaWiki instead.  We certainly need your help with some high-priority translations and reviews.   Whatamidoing (WMF) (talk) 19:36, 30 June 2014 (UTC)
 * Miss-Sophie, I corrected the translation for you. It will take a day or two for the translation to catch up to MediaWiki. Keegan (WMF) (talk) 02:14, 26 June 2014 (UTC)
 * I reverted myself for the moment. It looks like "Websites" was used once and Steinsplitter changed it to "Webseiten" as a "typo." I've asked Steinsplitter for clarification over on Commons. Keegan (WMF) (talk) 02:37, 26 June 2014 (UTC)
 * No, it wasn't a 'typo'/typing error/spelling mistake! It might be a bit complicated for Non-German speakers, but I'll try to explain. First "Webseite" (plural "Webseiten") and "Website" (plural "Websites") are both existing loanwords in German ("web" and "site" being English words, "Seite/-seite" being a German word with the meaning "page"), so none of them is a spelling mistake per se. Secondly the two words mean (or at least can mean) two different things, which have two different German Wikipedia articles, see Webseite and Website. Both articles clarify a difference. The article Website even gives Wikipedia as an example, explaining that German Wikipedia as a Website contains more than four million Webseiten. Also Wiktionary makes this difference: See Webseite, which is defined as a single page of a website. So does duden.de (online version of THE German dictionary), see and, that additionally traces back "Webseite" to a loan translation of "web page".


 * On the other hand: On the talk pages for these German articles there are discussions about this topic, where some users argue, that many Germans use "Website" and "Webseite" as synonyms, so that "Webseite" should be treated as a common synonym for a "Website" in the articles, no matter the literally meanings. Others are against it, explaining that "Seite" (= page) is not a translation of "site" and that its synonymous use is wrong and originated as a false friend. I don't know if this false friend theory is true in general and the reason for the development of an often synonymous use of "Website" and "Webseite", but I can say, that in my case it was. For I somehow thought "site" was the English word for "Seite" in this context, until I one day stumbled across the definition of the difference. And I made this mistake, although I knew the word "page" of course. But I didn't know the vocable "site" or its meaning regarding the Internet.


 * Now I will try to relate all this to Media Viewer: Media Viewer in German right now uses the singular "Website", saying "Auf dieser Website" (for "On this site"), but the plural "Webseiten", saying "Auf anderen Webseiten" (for "On other sites"). Since "On this site" and "On other sites" are meant as opposites (here versus there) regarding the same thing (a "site"), in my opinion the German translation should accordingly also use the singular and plural form of the same word, not a mixture of two different words. So it would either have to be a) "Auf dieser Webseite" (singular) and "Auf anderen Webseiten" (plural) or b) "Auf dieser Website" (singular) and "Auf anderen Websites" (plural). Based on what I wrote in the first passage of this post, the choice should be b) Website/s. Although a synonymous use of "Website" and "Webseite" may exist (see my second passage), I wouldn't choose "Webseite/n". It's much clearer to use "Website/s", because "Webseite/n" has mainly this other meaning of "wep page/s". The more so as there is also "Auf x Seiten verwendet" (for "Used in x pages"), which again contains the word "Seite", and in fact now with the meaning of a single page (Wikipedia article page)! So the use of "Webseite/n" instad of "Website/s" along with "Seiten" for single Wikipedia article "pages" would be confusing things, that are originally very explicitly separated in the English Media Viewer. I hope I could explain this in an understandable way.
 * --Miss-Sophie (talk) 11:40, 26 June 2014 (UTC)
 * Fine by me. Changed it back to Websites. Steinsplitter hasn't commented yet, but other confirm this as well :) Thanks! Keegan (WMF) (talk) 16:52, 26 June 2014 (UTC)
 * Thank you! I'm glad I could convey my points to you. --Miss-Sophie (talk) 18:22, 26 June 2014 (UTC)

Another issue, this time regarding the tooltip for the full screen mode. At the moment it is "In Vollbild anzeigen", but it should be "Als Vollbild anzeigen". A "Vollbild" is a picture filling the whole page/screen, so right now it says "Show in picture filling the whole screen", which doesn't make sense. "Als Vollbild anzeigen" means "Show as picture filling the whole screen". Alternatively "Im Vollbildmodus anzeigen" - "Show in full screen mode". --Miss-Sophie (talk) 21:01, 29 June 2014 (UTC)
 * Prepositions don't translate quite so precisely. I understand that both of these are probably okay, but als Vollbild anzeigen sounds better to me.  What would you think of just plain "Vollbild anzeigen", with no preposition at all?  Whatamidoing (WMF) (talk) 19:30, 30 June 2014 (UTC)
 * I know, that prepositions don't translate precisely and are one of the most difficult things to learn in a foreign language. I only tried an English translation in a way, that non-German speakers could maybe understand the matter a bit. After you said, both versions are probably okay, I googled them and I noticed, "In Vollbild" is actually also in use (60.700 hits versus 125.000 hits for "als Vollbild"), which sounds totally strange to me. I guess, it's a colloquial, 'lazy' way of saying "in full screen mode" with omiting the word "mode" ("Modus" in German). Though grammatically it then would have to be rather "im Vollbild", because it's "im Vollbildmodus", and you actually find this too on Google. Another likely explanation would be, that people, who say "in Vollbild", simply treat "Vollbild" the same way like when they say for example "in Groß", "in Klein" or "in Blau", "in Rot" (I haven't translated this, for I read in your profile, that you speak some German), which is a different case and not transferable, in my opinion. So what to do? Your suggestion without any preposition would work fine for me anyway and I prefer it much to "In Vollbild anzeigen". --Miss-Sophie (talk) 10:35, 1 July 2014 (UTC)
 * Does anyone object to dropping the preposition? I believe that Translatewiki.net was having some problems yesterday, and I'm not sure if it's up again, but when it is, I or someone else could make that small change.  Whatamidoing (WMF) (talk) 00:13, 11 July 2014 (UTC)

Annoying and Unuseful
I find this very annoying and hard to use. I don't want to see this annoying popup. My antivirus thinks wikipedia is sending me popups. Please remove this feature.

Two minor things
Win 7 / IE 11

1. Sometimes when I am moving quickly left or right through the slideshow, a small blue rectangle appears, adjacent to the left/right arrows. This has no obvious purpose.

2. When I click the "full screen" double-headed arrow icon, I get a message from IE saying "Do you want to view wikipedia.org in full screen?" but the display has already switched to full screen, so the message is pointless. I guess this may be a browser glitch that you have no control over.

86.169.36.18 00:39, 25 June 2014 (UTC)

The first is probably text selection - the browser interprets two close clicks as a double-click and tries to select the arrow element. We prevent this for other browsers but somehow not for IE - will see if that can be improved.

The other thing is standard browser behavior; all browsers switch first and ask later. Probably improves the usability that you can immediately see what is meant by fullscreen; at any rate, we have no control over it. --Tgr (WMF) (talk) 01:02, 25 June 2014 (UTC)

File name
My main issue with Media Viewer is that it takes multiple clicks to find the full file name (e.g. File:Example.png): MediaViewer only shows "Example", making it a bit harder to copy and paste the file name into an article (and URLs are longer, making it difficult to just copy the end of it). Is it possible to expose the full file name somehow, perhaps by a user option, or maybe addding it under the "Uploaded by" metadata list? — Microchip08 (talk · contribs) 06:20, 25 June 2014 (UTC)
 * I saw there is a link to embed the file, which you get after clicking on the icon in the middle on the right, which says "use this file" or something (I read it in German right now, don't want to log out to see the English tooltip). It already has Wiki syntax. --Miss-Sophie (talk) 17:53, 25 June 2014 (UTC)
 * Yes indeed, there is a new embed dialogue out now that offers file links in either wikimarkup or HTML for the original size of the file as well as small, medium and large. Keegan (WMF) (talk) 21:52, 25 June 2014 (UTC)

This is. --Tgr (WMF) (talk) 18:53, 26 June 2014 (UTC)

I feel like loosing context/contact to the article when using the slide show (especially for many images)
Some more thoughts that come to my mind, while testing Media Viewer. While I like the idea of a slide show option for images in an article and think it looks nice and gives you a better experience of many of the pictures (not of the file information though), I think it should be improved. I don't feel like still being in the article, when looking through the images in Media Viewer. Especially when there is a long row of pictures, I feel that I loose contact to the article and its context.

Reasons for this are:
 * Media Viewer looks completely different from the Wikipedia article page, nothing reminds me of the article anymore. You should at least place the title of the article somewhere above! At the moment the only hint is the url, which I'm sure many people don't look at.
 * Furthermore the image caption, which (sometimes more, sometimes less) explains the image in context of the article, is hidden below, while the file name is unnecessarily flashy prominent. Unnecessarily, because it is of minor interest in the context of reading an article. Since Media Viewer should serve the reader of an article and the captions are an integral part of this article, those should not just be treated as "further details" behind an arrow. As far as I know, the naming of the file name is also not part of any license conditions, which would justify a flashy prominent presentation. Sometimes file names also sound very strange for a reader, the more so as Media Viewer doesn't add the word "file" or the file format, like the Wikimedia Commons page does. File names are often just catchwords you can't read as a proper phrase, sometimes not telling at all. It's not like they are always the well thought out titles of artworks; they have mostly a practical function (the thing needs a name, so it can be uploaded). I would like the file names to be smaller and not that much a central element of the presentation. Maybe put the file name to the right, next to the "original file" button, which would be intuitively understandable. I think I would also prefer the addition of the file format (.jpg etc.), which makes it clearer to the reader, that this is a file name. Instead the caption of the image in the article should be immediately visible without having to scroll down or click (which I'm sure many people don't do when flipping through the images). I would like this caption to be more separated from the also included file description (from Commons), which is often partly identical and because of that confusing. I doubt "normal" readers understand, why the description in Media Viewer tells them things about the image content etc. in this repetitive way within two passages. Add soemthing like "from the file description page" (together with a link to this page) after this description and put the caption from the article somewhere else, directly visible, as I said, without scrolling.

--Miss-Sophie (talk) 18:28, 25 June 2014 (UTC)
 * The placement of the image caption was and still is a significant debate, and I encourage everyone else with opinions to speak up about it. I agree with you about placing the caption above the fold for Wikipedias, because the context is everything, but there is limited space on a screen and decisions had to be made about how to use that space. Licensing and Attribution naturally took first place, but I still think there's a way in future design to get the caption in for relevance. Good to hear this coming from you as well :) As for the rest of the design and placement, there's a nice dashboard tracking which actions are the most frequent and/or popular which will help with future design, I think. Keegan (WMF) (talk) 22:08, 25 June 2014 (UTC)
 * Currently too much prominence is given to the filename. If filenames were always well-written descriptions of the image then this wouldn't be so much of a problem, but they are very variable in quality, sometimes not in proper grammatical English, sometimes not in English at all, sometimes containing obscure and unnecessary codes and numbers, sometimes just not explaining the picture at all. 86.169.185.14 03:31, 26 June 2014 (UTC)
 * I think you have a point here, indeed. Jean-Fred (talk) 08:05, 26 June 2014 (UTC)
 * Yes, that's exactly what I mean. Too prominent (I guess "flashy" wasn't the right word) plus sometimes not telling. Regarding "not in English at all" and "If filenames were always well-written descriptions": From a non-English speaking reader's point of view even a file name in proper English has no meaning. There is always a reader whom the most well-written descriptive file name in the world doesn't say anything, simply because it's written in a language he/she doesn't understand. It's all relative, depending of the language abilities of the particular reader. One reason more to give these readers the image caption in their language in this prominent way instead.--Miss-Sophie (talk) 19:13, 26 June 2014 (UTC)


 * Hi Miss-Sophie, 86.169.185.14 and Jean-Fred, thanks for bringing up the file name vs. caption question. We considered moving the caption above the fold, as proposed in this card #589. But this would require quite a bit of development, as we would need to move everything around, which could introduce new complications; as Keegan points out, space is at a premium above the fold, and we would have to truncate many captions, which would be frustrating. So for now, we recommend waiting until we can support more descriptive 'file titles', as part of the upcoming Structured Data project with Wikidata (it would be the same as the 'Wikidata label' for each file, a short but descriptive title). For now, we have an opportunity to feature 'styled captions' more prominently below the fold, if you think that would help, as shown in this card #159, which is a much simpler task. Let us know if you think that this styling would make enough of a difference to warrant taking it on as one of our last features, before we move on to other projects this summer. Thanks again for your constructive suggestions! Fabrice Florin (WMF) (talk) 19:30, 26 June 2014 (UTC)
 * Hm, I thought about it for quite a while, but I'm not convinced by the styled captions at all. I think it even looks more confusing and most notably it doesn't solve the problem of the missing caption above the fold versus the too prominent file name. The styled caption looks confusing, because the bold text makes you think, this is a headline with then a second, subordinated headline (actually the title of the article) below, both belonging to the following short running text (the description from Commons). The line on the left will probably not be understandable as the marking of a quote for most readers and just enhances the look of two associated headlines. This impression may vary depending on the content of the text, but the example on your card #159 surely looks like this, since the wording of the caption resembles a typical headline text (think of an announcement of the exhibition). --Miss-Sophie (talk) 16:56, 27 June 2014 (UTC)

Truncated author information
Since Fabrice Florin (WMF) mentioned the truncateing of text above the fold: You already truncate the authors section, if the text is too long. Without the possibility to click on a link to see the whole text (apart from the link to the file description page). I think this is unacceptable, given license conditions that demand the naming of the author. I have thought about how to improve this, though I can't really judge, if my idea works. --Miss-Sophie (talk) 21:15, 27 June 2014 (UTC)
 * Assuming that I'm a new reader, who doesn't know MV or Wiki in general yet and is confronted with an image with truncated author information like this one. My logical assumption would be, that clicking on the arrow, which directly below this truncated text promises me to provide more details, will cause the rest of the author information to appear. I don't know what else there will be, but surely the dots, which show a part of the text is missing, have to be replaced with the missing text!? I will soon enough realize, it's not like expected.
 * But what if clicking on the upwards arrow would not just unfold the information part below, but would at the same time cause the upper text field above the fold, which presently has a fixed size, to widen upwards, so the complete author information can be displayed in the additional space. I assume, the text field above the fold doesn't need to have a fixed size anymore, the moment the arrow has been clicked, since the unfolding information covers the image anyway.
 * Alternative option: Include a "more" link that causes a momentary upwards widening of only the text field above the fold (while leaving the fold itself where it is at the under edge of the screen). This upwards widening would give space to display the complete author information.
 * Furthermore: I don't know, if it makes sense to include the image caption above the fold with one these two options to show it completely, in case it had to be truncated? It might be less comfortable to see a truncated image caption than a truncated author information, when using the slide show function. I think you're right, saying this would be frustrating, even, if there was one of the two options to show the cropped caption completely. But somehow there has to be an option to flip through the images and to read the caption at the same time, without having to click on "further details". Maybe somewhere to the left of the image?


 * Hello Miss-Sophie, and thanks for your good suggestion regarding truncated author information. Great minds think alike! :) We agree with you that it's not acceptable to truncate critical author information without an easy way to expand it -- and plan to address this issue next week, as outlined in this ticket #396 (Expand truncated text fields on click)]. The goal is to let you click on truncated text so you can see all of the author and source information about an image without having to go to the file page. For practical purposes, we would expand the metadata panel to present this full information, then contract it back if you click again. Would that approach work for you? Or do you recommend any simple tweaks? Once we have solved this critical issue, it will be easier to think through some of the other related issues like the caption.Thanks again for your constructive feedback, which is much appreciated :) Fabrice Florin (WMF) (talk) 21:53, 27 June 2014 (UTC)
 * Good to know, you intend to change that. Regarding your question - I'm not quite sure, if I fully understand your plan from the ticket, but I'll try to comment. If I'm not mistaken, you don't want to create an option to on click read the full text above the fold. Instead the truncated text would after clicking still be displayed as truncated with the dots and you want to duplicate and complete this text somewhere in the section below the fold. With a link from the truncated text, which you can click to unfold this section. I'm not sure how I would like that. My first thought was, that a duplication instead of a replacement with the full text might not look very 'elegant'. That the amputated text and dots are only provisional, should disappear after clicking and not be part of the final result. Plus not truncated file names and author/source information would then unnecessarily always be displayed in two places in MV (above the fold and below). From other sites I'm used to seeing the text continue, where it broke, after clicking on some kind of "more details" link. But I'll wait and see, how I find it. --Miss-Sophie (talk) 16:39, 28 June 2014 (UTC)
 * I now see on the card, that the mockup design there is exactly what I thought it should look like. Somehow I hadn't seen the image of the design there before, when I wrote the above. I thought the metadata panel was just the part below the fold, not also the part above. So when you wrote, you plan to expand the metadata panel to show the completed information, I didn't relate this to the part above the fold, which in the mockup of the card is actually the expanded part (and corresponds with my suggestion). So I was a bit confused and thought, you wanted to not continue the text above the folt but duplicate the information below. --Miss-Sophie (talk) 17:03, 6 July 2014 (UTC)

Is scrapping MV on the table?
An honest question for Keegan, Fabrice Florin, and any others involved in bringing us Media Viewer: You claim to have your ear to the community wanting to know our opinions and thoughts on how your product can be improved. Do you consider scrapping it and returning to the file pages as an option if opinions on Media Viewer continue to be negative, particularly from the large and most-active EN and DE wikipedian communities, or are you steadfast in your course that going forward the only changes will be to further "improve" Media Viewer? - S201676 (talk) 02:49, 26 June 2014 (UTC)
 * From what I understand, turning Media Viewer off for unhappy projects is not off the table. I do not know what the criteria for measuring that is. Keegan (WMF) (talk) 16:25, 26 June 2014 (UTC)
 * @Keegan (WMF): Please would you find out what the criteria are. Thank you. RomanSpa (talk) 13:27, 29 June 2014 (UTC)
 * In general whatever counts as a community recognized consensus (usually trough some sort of RFC) on the wiki in question. TheDJ (talk) 14:34, 1 July 2014 (UTC)
 * @TheDJ: Can you thus confirm that attention is being paid to the discussion and comments in this RFC, Wikipedia:Media Viewer/June 2014 RfC, where it appears that the sizable majority on EN:wiki is not happy with the feature? Perhaps a consensus has not been achieved there, but specific guidelines for determining when a consensus is achieved and assurances that it would trigger the desired disabling of Media Viewer are sought. - S201676 (talk) 18:16, 1 July 2014 (UTC)
 * 'can you thus confirm attention is being paid to the discussion and comments in this RFC' Can you ? I'm not much different the you as far as I know. Communities form consensus in whatever way they do. A consensus should be used when filing a request in bugzilla for a 'site specific' change to substantiate the communities request to deviate from the defaults. TheDJ (talk) 10:26, 4 July 2014 (UTC)

Missing caption + "View original file" button broken
Win 7 / IE 11

(Reported above, but on a page that subsequently changed and so apparently you could not reproduce it.)

Restart browser. Go to http://en.wikipedia.org/wiki/Henri_Moissan. Click on the infobox portrait to go to MV http://en.wikipedia.org/wiki/Henri_Moissan#mediaviewer/File:Henri_Moissan_HiRes.jpg. "View original file" not functioning. Click browser "back" button to return to article. Click again on the same image in article. This time the filename and other content is lost from the lower pane. 86.169.185.14 03:21, 26 June 2014 (UTC)

Thanks for reproducing! This is caused by mishandling file usage lists with strange namespaces. It will be fixed once ticket gets merged. --Tgr (WMF) (talk) 06:37, 26 June 2014 (UTC)
 * (For the record, this is . --Tgr (WMF) (talk) 22:57, 26 June 2014 (UTC))

Can't get 'Back' to the article
I was reading an article with a lot of images and clicked on an image and the viewer took over. I panned to the next image, and then the next and several more. When I wanted to return to the article I hit the back arrow on my browser but it took me to the previous image, again, and again. To get back to the article I had to revisit all the images I had just viewed, in this case I had to back-track through some ten images to get back to the article. (!) Is there a way to go 'straight' back to the article once a viewer has panned through a number of images? -- Gwillhickers (talk) 15:20, 26 June 2014 (UTC)
 * Unfortunately not. It irritates me still as well, but GIlles has a point if you read through this conversation about browsing behavior and history interaction. There's still ways around this being discussed. Keegan (WMF) (talk) 16:27, 26 June 2014 (UTC)

To clarify, you can use Esc / the X button to go back to the article; but there is no way to go back in the browser history (to the place from which you visited the article) without going through the MediaViewer entries. (Well, apart from the history jumping functions which the browser provides. would make those easier to use.) --Tgr (WMF) (talk) 17:08, 26 June 2014 (UTC)
 * Yes, the 'X' icon takes you back, but when you hit the browser 'Back arrow' again, you're right back to media viewer at the last image you viewed, where you have to pan through all the images to get back to the same spot. So if you're reading an article (A) and click on a link that takes you to another article (B) where you begin viewing images, you can't get back to article A. In other words, media viewer blocks your recent history functions and to get back to where you started you have to resort to other measures. Any fixes in sight? -- Gwillhickers (talk) 18:29, 26 June 2014 (UTC)
 * Tgr linked you to 67008, which is a possible fix in sight. Keegan (WMF) (talk) 18:31, 26 June 2014 (UTC)
 * Well, not really a fix, it would just make it slightly less annoying. You can read for background - we are relying on native browser behavior here, in an area where browsers don't give you a great deal of control. There are alternatives, but they are either risky or even more surprising for the user. --Tgr (WMF) (talk) 18:51, 26 June 2014 (UTC)

Small display problem
Win 7 / IE 11

Go to http://en.wikipedia.org/wiki/Cyclone_Joy. Click the main image in the infobox to go to MV http://en.wikipedia.org/wiki/Cyclone_Joy#mediaviewer/File:Joy_dec_22_1990_0440Z.jpg. Click the "X" button to go back to the article. In the article, click the same image again. A small white box, which appears to be a drawing error, appears in the top left of MV. The outline of this box persists even after MV is closed. 86.169.185.14 00:28, 27 June 2014 (UTC)

I have also seen the text "Show next image", almost certainly left behind by MV, displayed at the right-hand edge of a Wikipedia article, but I cannot at the moment find the steps to reproduce this. 86.169.185.14 03:20, 27 June 2014 (UTC)

I can't reproduce either of these, but the second sounds like, just with the next button. (We will soon remove the tooltip from that button anyway, but we might want to consider a more generic solution for the tooltips.)

A screenshot would help in figuring out what the first issue is. --Tgr (WMF) (talk) 06:27, 27 June 2014 (UTC)


 * I noticed this blank white spot in the upper left corner, too. It seems to be related to the bug with the tooltip for the Exit button, I reported, and can be reproduced as follows by me: Click on an image in an article and close Media Viewer with the Exit "X" button, before the tooltip for the button appears. Now the spot is already there on the article page as a little object with light blue border. Open the same or another image from the article and the white object becomes that spot on the black background of Media Viewer. The spot vanishes the moment you move to the "X" button and let the tooltip for it appear! But if you click "X" then, you get the already described stuck tooltip in the article over the search field instead. By the way, the problem with the left over "X" tooltip occurs all the time and is pretty annoying. You can't use the search field anymore without having to reload the page before. --Miss-Sophie (talk) 08:37, 27 June 2014 (UTC)


 * It's exactly the same for me. It seems to be very consistent with all images. Tgr, perhaps the reason you could not reproduce my scenario is to do with the timing of the clicks (e.g. waiting too long or something). 86.179.7.208 11:56, 27 June 2014 (UTC)


 * Hi Miss-Sophie and 86.179.7.208: Thanks for reporting these issues! As Tgr points out, it would be great if you could give us a more detailed report with a screenshot about the first issue, including info about your operating system and browser version. You can either file the report here on Bugzilla, or email it to us, after joining the multimedia mailing list. Regarding the second issue about the Exit button tooltip still showing up after you close Media Viewer, we're addressing this issue, as shown in this ticket #740 (Tooltips can get stuck when MediaViewer is closed). Thanks again for all your help in improving Media Viewer :) Fabrice Florin (WMF) (talk) 22:15, 27 June 2014 (UTC)
 * Thanks, but I am going nowhere near Bugzilla as I believe it makes email addresses publically viewable on the Internet, which is totally and utterly unacceptable behaviour. In case still wanted, a screenshot of the first problem is at http://oi60.tinypic.com/1z3xnqs.jpg 86.179.7.208 01:31, 28 June 2014 (UTC)
 * We figured it out in the meanwhile (well, Miss-Sophie figured it out, really). It's the same issue with tooltips, patch is incoming. --Tgr (WMF) (talk) 22:39, 27 June 2014 (UTC)

Thanks for easy disable
Thanks for easy disable. Some dogs just don't want to learn new tricks. 67.161.254.8 01:10, 28 June 2014 (UTC)


 * No, not thank you. Not as long as this horrible feature is still the default option. I know many people who are not familiar enough with a computer and will not find the way to disable it. As for myself I do not disable it, just to know when the people in charge, if any, will be sensible enough to understand that it is not wanted and that what they claim to be result of a survey is just a big lie. --125.255.112.142 15:34, 29 June 2014 (UTC)


 * +1 IP users can not make full use of our mediafiles, as long as this thing is default. That could mean loss of contributions to WP, which is inacceptable. Alexpl (talk) 07:47, 1 July 2014 (UTC)


 * I am happy to learn new tricks. I am disinclined to be fed shit and be told that it's filet mignon. Further, because of the way that disablements work for IP users, they are not counted. Similarly, people who vote with their right-click or control-click to avoid mediaviewer are not seen by the perpetrators of this piece of software as having opted-out.