Extension talk:Media Viewer/About

Being fair to everyone
On that note, making this viewer the default viewer is sort of like a kick in the teeth in terms of our wants and interests. I would suggest that when this viewer comes into view that a banner asking Disable? [y/n] be presented (with a check box for 'Never ask this question again?') If after a trial period it is found that most users have disabled this viewer, it should no longer be the default viewer, but rather a choice. I'm not understanding why it wasn't presented as a choice to begin with. This would be fair to everyone. As it is, the media viewer still needs a lot of work and I'm still wondering how the viewer was "tested extensively around the world" and still got 70% approval. This finding is not at all consistent with all its faults and the overwhelming disapproval its received on English Wikipedia/Commons. Are you locked in with some sort of contract and have given a large down payment to a software developer and there's no turning back now? In the face of all this disapproval and the fact that you're going ahead with this viewer, anyway, would seem to support that premise. If you can render this new viewer where we can readily view an image in its fullest resolution, with all the categories, other versions, description information, viewable and able to be edited, then you at least will not get my disapproval, and I'm sure that of most other editors. All the best. -- Gwillhickers (talk) 16:32, 5 June 2014 (UTC)
 * Could you please link to a supporting discussion page for your statement that "the overwhelming response among English Wikipedia editors and others is that this thing is frivolous, frustrating and not needed, or wanted"? We haven't seen that much of an issue on English Wikipedia, and I'm sure it would be helpful to see some of the responses those people are giving. --MarkTraceur (talk) 18:37, 5 June 2014 (UTC)
 * I was referring to this discussion page, which I believe at this stage, given the many responses, supports my estimation of the Media Viewer's acceptance. Esp since its faults and shortcomings have been articulated with one example after another. I suspect any "approval" for this viewer was made without the knowledge of its many faults and shortcomings. i.e. How could any adult approve of it knowing all it's faults and shortcomings? Simply because it shows pretty pictures in a slide show fashion? -- Gwillhickers (talk) 21:14, 5 June 2014 (UTC)
 * There are a lot of responses here without any real content, and I'm taking into account that this is on MediaWiki.org instead of enwiki, and that there's some response bias for this talk page. I have seen exactly two threads on enwiki itself, and nothing else. This page is the feedback area for enwiki, English Commons users, developers, and Wikisourcerors as well. You can't necessarily attribute the response here to an "overwhelming response among English Wikipedia editors". If you could be a little more specific that would be helpful. --MarkTraceur (talk) 21:31, 5 June 2014 (UTC)
 * Indeed; the English Wikipedia alone has 30,000 active editors per month. This page is serving 900+ projects. Some context,, would be nice to have. Keegan (talk) 22:56, 5 June 2014 (UTC) Keegan (WMF) (talk) 22:58, 5 June 2014 (UTC)
 * Stupid accounts :) Keegan (WMF) (talk) 22:58, 5 June 2014 (UTC)
 * The "responses without any real content"? I wouldn't be so eager to write them off simply because they didn't reiterate the many real problems other editors have pointed out. And the problems are indeed real, regardless of any "bias" you may think exists. I hardly think editors are objecting to the viewer just because the forum exists here at MediaWiki. That almost seems like a biased claim itself. The discussion for the viewer exists here, which is why we don't see it much elsewhere, and the complaints continue to roll in, below. Easy math guys. In any event, the viewer should be offered as a choice, and as I said, if enough people disable it as the default viewer, then we should follow suit and offer it as an option when people click on an image. That would be fair to everyone. As it is, the media viewer was made the default viewer with all its faults and shortcomings. Not fair. -- Gwillhickers (talk) 01:19, 6 June 2014 (UTC)
 * I see 74 discussion threads . Of those, FIVE threads were initiated by happy customers with praise for the product. The other 93.4% start with either a polite complaint, a problem or (frequently) a howl of outrage. I don't really like unspecified terms, but I think @Gwillhickers' "overwhelming" is appropriate here. @Keegan was right when he said this should be discussed based on solid numbers and facts on how communities feel about Media Viewer. Saying that everyone else is "broadly supportive" or "generally pleased" is no more valid than statements you dismiss out of hand as biased that claim "most people" hate it. I join with @Keegan and request that we stop relying on assumptions, innuendo and the pre-release survey in favour of the comments being made now that it is in the wild. Defenders, please provide a summary of wiki-talk comments as follows: Number of threads where originators (not respondents) praise versus criticise the tool. Include every thread on the talk page (not just those you deem significant or substantive) dated after wide release. Exclude only threads originated by participants in the project (whose bias, as @Keegan notes, is undeniable). To balance negativity-bias common to feedback sources, let's set the bar low: If you can show that just 50% of respondents praise the feature, I will consider it a smashing success. If you can show just 33% of responses do not contain a complaint, I would concede that the tool is a good addition to the WikiWorld. If the results show that the supermajority of users have objections, I respectfully submit that the time you spend defending this tool might be better used finding solutions to the problems raised. On the other hand, if you do not feel that such a review of talk pages is worth your time, please immediately cease telling us how everybody else loves this thing and that Wiki Commons & MediaWiki users are being unreasonable... or, as 130.34.157.13 so eloquently put it, STOP IT!. 159.53.78.142 16:14, 6 June 2014 (UTC) (also responsible for above comment posted 159.53.110.143 18:36, 2 June 2014)
 * Is it possible to collect the statistics on the number of users who disable the viewer? That could provide some hard data on how people actually feel about it. DB (talk) 00:10, 7 June 2014 (UTC)
 * It is in the plans. --Tgr (WMF) (talk) 00:52, 7 June 2014 (UTC)
 * Looked at some large wikis, on enwiki ~500 users disabled it which is less the half percent of the editors who have been active since it was enabled. Other large wikis (de, fr, es) have similar stats - some slightly larger, but all below 1%. --Tgr (WMF) (talk) 20:46, 7 June 2014 (UTC)
 * I do not have stats but I understand most wiki users do not have or want accounts. They don't edit; they consume. NO ONE who uses a wiki that way can turn this feature off. Those who turn it off are a subset of those who can, and therefore your statistic ignores the massive group who are denied that option. Next up, measuring how many people actively disable the feature is simply not a valid measure of approval, even amongst account-holders. It is simply a measure of how many account-holders as so horrified that they spend time to get rid of it. Those who do not use pesticides do not necessarily love cockroaches. Next, many supporters have asked that we delay discussion until the "natural course of change" takes place and the "I hate it because it's new" reaction fades. Explain, please, why the negative responses are increasing steadily over time. As people really "get used to the new feature", more of them are talking the time to register their frustration and annoyance.


 * Is it maybe time to at least CONSIDER that this feature should be opt-in? Is it POSSIBLE that Commons users have legitimate concerns about copyright, ease of use and lack of critical features? One last note: Yes, objections to this feature will fade over time. There is no doubt. Objections to anything, no matter how onerous or offensive, fade. Pick your historical analogy from any era where negative but non-lethal changes were foisted on a group -- there is a point where folks realise that they're shouting to the wind or that they're troubles pale in comparison to those under the rule of worse regimes. My question is, do we really want our motto to be "at least we're not as vile as Flickr"? 159.53.46.141 21:02, 9 June 2014 (UTC) (same as originator of this thread)
 * Sure sure. Continued usability of Media Viewer on Commons is an active discussion and nothing should ever be counted out. However, there are very likely development solutions that could help make Media Viewer a more powerful tool on Commons and much more accepted there. I'd like to see what we can do to help the community with the tool before we just give up and there has been extensive feedback given from Commons contributors about what we can do to make Media Viewer much more useful for them there. More to come in the following days as opportunities to make Media Viewer a better thing are distilled and worked out :) Keegan (WMF) (talk) 22:51, 9 June 2014 (UTC)

Link to old style page
The link to the old-style image page, which seems to be essential to access certain features such as viewing upload history, commenting on talk pages, viewing particular resolutions, seems to be available only by clicking on non-obvious and inconsistently labelled links like "View licence" or "Public Domain", or in some cases appears not to be available at all. I find this quite confusing. If the old-style page is supposed to be still available for certain purposes then there should be a clear and consistently titled link to take you there. 86.151.118.43 17:34, 5 June 2014 (UTC)
 * Hi! We have already heard this complaint a few times recently, and we're going to solve it by adding the link to the file page that logged-in users get for non-logged-in users. This decision was made Once Upon a Time with the rationale that logged-in users would be the primary users of the feature, since they would want to get to the file page to edit the file metadata, or add categories. Now we realize that logged-out folks want to see the file page too, so we're removing the check for logged-in-ed-ness. --MarkTraceur (talk) 18:32, 5 June 2014 (UTC)
 * Cool, thanks. 86.151.118.43 19:45, 5 June 2014 (UTC)
 * That's a good decision, thanks from me, too. - By the way, I think that survey results may be misleading: It's plausible that 70% or more of users just want to have a quick look / browse through images and aren't potential re-users, so those may be happy with a simple viewer that hides additional information and download options. But the remaining 30% (or so), those who really want to use pictures, are very important users, too - and those don't necessarily have a Wikimedia account. Gestumblindi (talk) 19:57, 5 June 2014 (UTC)

Seriously. This needs to be a top priority. Having a permanent, consistent, highly-visible, explicit link to the file description page is not an optional feature, it is critical. The first time this thing was foisted on me, I was trying to find the file that an image was derived from, and I clicked about half a dozen different things and never found the right one. I ended up disabling the feature because I literally was unable to figure out how to get to the standard file page with the information I needed - a page that I'd gotten the last several thousand times I'd clicked on a Wikipedia image. I tried hovering, I tried right clicking, I tried clicking on every undecipherable icon on this monolithic black screen of death, and my only option was to find the preference that enabled me to just shut the thing down, placing my Wikipedia experience one more step removed from the default user. Vanisaac (talk) 19:59, 6 June 2014 (UTC)

Resource hungry on older computers
Whilst my computer is over 10 years old, I still expect to be able to browse images quickly whereas this interface is bordering on unusably slow compared to the previous image pages. Keep it simple, there are a lot of people worldwide using older technology. — Preceding unsigned comment added by 80.189.68.163 (talk) 18:16, 5 June 2014‎
 * I think it would be a bad idea to design everything we do around the lowest denominator platform there is. That is a sure way to end up being no longer relevant. TheDJ (talk) 08:29, 6 June 2014 (UTC)
 * Yes, I agree completely. Access to information should be restricted to the middle-class of first-world countries.  74.207.250.159 20:45, 6 June 2014 (UTC)


 * I would conclude exactly the opposite; ignoring everyone who does not adhere to the latest fashions is a sure-fire way to alienate and exclude people and fade into irrelevance. Has everyone become so brainwashed by marketing that adherence to technological fashion is the only way to remain "relevant"? Whatever happened to graceful degradation? Just because a website has pictures doesn't mean it shouldn't work in an ancient text-only web browser. Just because a website has resource-hungry JavaScript doesn't mean it shouldn't work on a relatively under-resourced, older computer. --79.74.105.228 00:51, 9 June 2014 (UTC)

Any details on how MediaViewer is slow on old computers would be helpful. Does the image take long to load? Is switching between images slow? Does the browser become unresponsive? Also, how old is the computer exactly (what kind of CPU/memory does it have)? What OS/browser are you using? --Tgr (WMF) (talk) 08:21, 9 June 2014 (UTC)
 * Why should is have to be explained to developers? They should have 10 year old computers in their lab.  If they still don't get it, they should be forced to develop on 10 yaar old computers, especially since Wikimedia is supposedly a nonprofit.    Any moron can develop for the latest workstation, that's just trial and error.  Making it work for everyone is what makes it a profession.

The media viewer discourages users
Get rid of the media viewer because it is cumbersome to use and discourages users. I like to be able to choose the file resolution before I download a file and the media viewer does not allow users a choice. It seems that whoever thought of adding the media viewer might have a financial interest in the software or wants to limit access to free media. This person or people need to be fired ASAP because of the interest they have displayed in discouraging the use of free media. ThelmaLou (talk)
 * You can download a specific resolution by clicking the 'use this file'-icon (bottom right of the view) and then selection a specific size from the "Download" drop down. TheDJ (talk) 08:25, 6 June 2014 (UTC)

Please return it to original style
In the old style of viewing image, I could select the image size and resolution. Since my vision is impaired, this allowed me to see detail in a higher resolution or a larger size image that is missing in the thumbnail. In this new viewing system, I try to increase the size of the image but a) there is no zoom feature and b) when I hit Ctrl+, the image momentarily gets larger and then snaps back to the small size it originally is. Only the footer is made larger, not the image. This prevents me from being able to read text that is included (like in diagrams or flow charts) as well as details in more intricate images.

How can I return to viewing images in the old fashion? I'm not against change all of the time but this new viewing style actually prevents me for seeing images, outside of a thumbsized or small version. You should consider the needs of those without 20/20 vision who might need the images to be larger. Liz (talk) 21:19, 5 June 2014 (UTC)
 * Liz, you can disable Media Viewer in your preferences. If you're referring to the English Wikipedia, this is the page. Untick the "Enable Media Viewer" box in the -Files- section.
 * When Media Viewer is being developed again for the next version, there are plans to fully integrate a zoom feature as well as access to various resolutions/file sizes for viewing. I hope once this is nicely built in, you can turn Media Viewer back on :) Keegan (WMF) (talk) 21:41, 5 June 2014 (UTC)
 * Sorry, but I am with the opposers to the new Media Viewer. Please don't make it the default, otherwise unexperienced users won't even know that the file information is available! -- Alvesgaspar (talk) 23:26, 5 June 2014 (UTC)


 * Thanks, Keegan (WMF). I also discovered that there is a circle in the bottom far right hand corner of the screen which will take me to the Commons page where I can view different sizes of the image which is what I was searching for. Maybe it could be better identified because, otherwise, I couldn't get out of the new media viewing page. Liz (talk) 07:49, 7 June 2014 (UTC)

Reformatting file descriptions to be more Media Viewer friendly
Due to the unstructured or semi-structured nature of information on file description pages, the Media Viewer sometimes does a poor job of conveying the information from the description page. For example,, the Media Viewer says "No description available." underneath what appears to be the description of the image, and also doesn't inform the user that the image is under a fair use licence.

My question is, is there documentation somewhere that lets users know how to reformat the information that's on the file description page so that it's readable by Media Viewer? There'd be many such editors willing to do that (myself included), and it'd greatly improve the user experience of the Media Viewer if it could provide more meaningful information for more images.

Thanks!

--Dan Garry, Wikimedia Foundation (talk) 22:59, 5 June 2014 (UTC)

Much appreciated! Basically MediaViewer looks at Information-like templates, license templates an coordinate templates, as long as they conform with commons:COM:MRD. There is some info on Multimedia/Media Viewer/Template compatibility (mostly aimed at template maintainers and not very user-friendly, though). Fair use is not handled by Media Viewer right now (unless you add mock license metadata to the fair use templates); detecting it using the category would be easy enough. What appears to be the description of the Tank Man image is actually the image caption from the article; there are some plans here on how to make that less confusing. (I guess we should not show the "no description" text if there is a caption.) --Tgr (WMF) (talk) 00:30, 6 June 2014 (UTC)
 * Yup yup. There's a lot of work that needs to done by hand not just for Media Viewer but for getting metadata structured in general. Thanks for the links, tgr :) Keegan (WMF) (talk) 00:43, 6 June 2014 (UTC)
 * I've given a first shot at this. That template is one of the most used and most consistent parts of the non-free media templates, so it seemed like a quick win to add some info there, as long as these templates do not have the correct info yet. But cleaning up all english wikipedia templates is going to be a GIGANTIC undertaking, since en.wp have taken a very visual and non-central approach to templating, instead of the meta-templating approach of Commons. TheDJ (talk) 09:56, 6 June 2014 (UTC)
 * Great, thank you for starting that. Yeah, en.wp is going to be something...else :) Keegan (WMF) (talk) 17:31, 6 June 2014 (UTC)
 * There is a sort-of meta template, Non-free media; one thing you could do is to use licensetpl_* markup with hidden fields there to set "license name" (similar to the way it is done in the PD meta-template on Commons), and use fileinfotpl_* on the fair use rationale template to get description and source. --Tgr (WMF) (talk) 19:26, 6 June 2014 (UTC)

Not obvious how to find the file page
The link "Learn more on Wikimedia Commons The free media repository" is unclear and unintuitive, because it implies it takes you to the front page of Wikipedia Commons rather than the file page. A link stating something like "View this image's page on Wikipedia Commons" would be far clearer. -86.135.189.79 23:35, 5 June 2014 (UTC)
 * I agree with this. Could we have the link text made more explicit, please. —  Scott  •  talk  08:34, 6 June 2014 (UTC)
 * Seems the image viewer would generate far fewer objections if bypassing it wasn't browser-specific, so have a second small icon next to the gray Enlarge logo (RHS below image) with a gray Commons logo that clicks straight through to the Commons page. Also, have clicking on the image in the viewer do the same. Problem solved? Munrogue (talk) 07:35, 7 June 2014 (UTC)

Display errors in IE 10
Images in the mediaviewer appear in the wrong aspect ratio (they’re stretched lengthwise), and the lower part of the image is completely blocked by the information bar. Scrolling, which one might expect to reveal the hidden part of the image, instead simply expands the information bar to hide more of the image. If there is a way to close the information bar, it is not evident.

Example: http://en.wikipedia.org/wiki/F/A-18C#mediaviewer/File:FA-18F-USN-RedRippers-20070406.jpg. The rocket/flare at the bottom of the image is completely obscured by the information bar in mediaviewer.

Viewed in IE 10.

Note: I would not have learned about the shift-click workaround without reading this discussion page. It might be worthwhile to note this solution more prominently until the bugs are fixed. (I do not have an account to permit me to disable mediaviewer, nor do I plan to create one. Similarly, I’d report this on the bugzilla page, but I lack an account there. I am not an editor (obviously), just a reader for whom this problem got in my way enough to take the time to report it here.)


 * I reported this problem in bugzilla, linked to the top right of this post. TheDJ (talk) 07:58, 6 June 2014 (UTC)


 * Thank you, anonymous reader, for reporting this bug. And thank you, TheDJ, for filing and  . We have added corresponding Mingle tickets #699 and #700 on our next development cycle board -- and plan to start working on them this week. Again, many thanks for your contributions to this project, which are much, much appreciated! Fabrice Florin (WMF) (talk) 10:00, 7 June 2014 (UTC)

to small
Big pictures to see?? How does it works? Is it a new mini player? It was better before to see details ! Greetings,--Benutzername eingeben (talk) 06:14, 6 June 2014 (UTC)

URL? Not user friendly nor crawlable
What kind of URLs does the Media Viewer create? https://en.wikipedia.org/wiki/Zebra_Technologies#mediaviewer/File:Zebra_Technologies_Logo.png A "#" in the middle of the URL, really?
 * "# is used in a URL of a webpage or other resource to introduce a "fragment identifier" – an id which defines a position within that resource." (see [])

Furthermore the URL ist long and strange and no user will be able to type it from hand.

And last but not least the filetype is wrong. It says ".png" at the end of the URL, but the data delieverd is a HTML Page. That is just plain wrong (just as it was before with https://commons.wikimedia.org/wiki/File:Kanadische_Truppen_landen_in_der_Normandie.jpg, but why didn't you correct the mistake?)

This will also create the same problems with crawlers (Google and others) as the previous version. Google with build a workaround for wikipedia, as they did before, but they will not for all the small MediaWiki installations, just as they did not before. And why should the fix your erroneous software? Please keep to the webstandards!

When i copy the URL and send it to a friend, it doesn't just load an image.

https://en.wikipedia.org/wiki/USA#mediaviewer/File:Flag_of_the_United_States.svg

loads the whole article about the US in the background for showing the image. 2.1MB are transferred for an image that is just 52KB. That is a real WTF.--62.153.251.26 12:03, 6 June 2014 (UTC)

That said: I like the mediaviewer, the idea is good, the execution not so much. IF you fix the problems, i will love using it. — Preceding unsigned comment added by 62.153.251.26 (talk) 06:33, 6 June 2014‎
 * A fragment identifier ending in ".png" doesn't imply that a PNG will be delivered. This is explained in section 3.5 of RFC 3986, which defines fragment identifiers in URI syntax. Likewise, nor is it implied by a URL - you should never blindly assume that the content-type of a resource is implied by a textual identifier. Media files are uniquely identified in MediaWiki by their name, which is why it needs to be present in URLs for interacting with them in some fashion. The alternative is URLs with numeric identifiers of some sort, which is far less palatable.
 * However, I have to agree about the "loaded in the background" issue. It's inevitable that Media Viewer URLs will be shared around, and this needs to be given some thought. If Media Viewer URLs are to be formed via fragment identifiers, MediaWiki should check on page load whether the requested URL contains a Media Viewer call. If it does, load Media Viewer and set up an AJAX call to load the page's content when Media Viewer is closed... or something like that. Tricky. Of course, if the URLs are redesigned to not involve fragment identifiers ( perhaps?) then it'll be a non-issue. That would presumably involve, when being invoked from wiki pages as opposed to standalone, loading Media Viewer as a separate resource and displaying it in a floating frame, or some such. —  Scott  •  talk  09:04, 6 June 2014 (UTC)


 * Thanks for the feedback, Scott. You say "you should never blindly assume that the content-type of a resource is implied by a textual identifier". That is true. But the reality is: When Googlebot sees a URL ending in .jpg it does not crawl it. Instead it sends the Google-Image-Bot. The Google-Image-Bot tries to crawl the url but gets a html document, which it cannot understand. You can look at any mediawiki installation, that is not wikipedia, and see that google does not crawl any pages like /wiki/File:*.jpg (and other images).


 * My first thought would be a URL like: https://en.wikipedia.org/wiki/mediaviewer:Flag_of_the_United_States/svg?page=USA. This way you could open the image in fullscreen view and the page would know to wich article to return after the close. It would also work the same way for just one image without "?page=USA". But thats just one early idea without looking into it further.--62.153.251.26 12:03, 6 June 2014 (UTC)

What you say about Googlebot does not seem to be true even for URLs where the path part ends in an extension (and it would be fairly stupid behavior from Google - you are supposed to use the mime type to tell the resource type an URL represents, not the URL), much less when the extension is in the fragment part (which is largely ignored by search bots - although Google is more clever about that - since the same page can be referenced with different fragment ids).

As for using fragment IDs, that was a design decision to support older browsers. You have basically three options:
 * 1) reload the page every time the URL changes (clearly not wanted)
 * 2) use hashes to store the state
 * 3) use the History API to change URLs without reloading - only supported by about 75% of browsers. (There are some other problems with it, too, like splitting caches.)

Choosing option 2 means that we need to serve the whole page, not just the image (as the fragment id does not get sent to the server). That is unfortunate, but I still think it is the least bad option. --Tgr (WMF) (talk) 19:18, 6 June 2014 (UTC)

Should be Opt-in for Everyone...
... that is, for anonymous users and random browsers of Wikipedia, who are otherwise unable to enlarge images and look at image credits. Personally, I really don't like this "enhancement" - it's unhelpful in every way. There appear to be idle hands somewhere, and the devil has obviously found work for them... Sigh... RomanSpa (talk) 10:42, 6 June 2014 (UTC)

Today I was confronted without warning with a new and unhelpful viewing experience. I am an occasional editor - mostly I just fix typos and bad links - so I had at least a first idea of where to go to find out what was happening. That brought me to this discussion, and I strongly agree with those who are against this change. What we had before was a very usable system that had what I might call academic rigour - something that I expect from such an important information resource as Wikipedia.

It seems to be really difficult for enthusiasts to understand that foisting an unheralded change on people who use this excellent resource is counter-productive. I am not so involved with Wikipedia that I wish to spend time researching better ways to fix something that was delivered to us unannounced, and clearly is unwanted by many in this community. The changes to privacy policy that have been announced for some months clearly show that it is possible to give a decent amount of prior notice. The same should have been done with this non-trivial change.

But that said, sometimes horrible "features" only show up once a software change is implemented. It is important to know when you have driven up the wrong road and need to turn around and go back. This seems to me to be one of those times.

I have anyway logged in and disabled Media Viewer. What is not clear from the FAQ is whether I am now going to have to log in every time I come to Wikipedia, or if the setting will be remembered via a cookie or something. I fear it will be a requirement to log in each and every time, which is going to drive me to distraction.

I very much agree with RomanSpa that Media Viewer should be an opt-in.

[Don't know what I've done wrong, but my user name doesn't seem to display ... RikardT]


 * Hi RikardT, I'm not sure what happened there, either. There have been problems with people coming to MediaWiki.org and and discovering that they're somehow logged out (mostly in Firefox?  It doesn't seem to be clear).  However, you seem to be logged in, so that's not the problem you were having.
 * Disabling most tools is only available to editors who are logged in. However, most of the time, people stay logged in for 30 days at a time.  Whatamidoing (WMF) (talk) 22:28, 6 June 2014 (UTC)

Description not visible without scrolling down
Hi, for me (Win 7 laptop, IE 11), the description of pictures is not visible unless I scroll down. The filename is visible, and sometimes this suffices, but sometimes filenames are not very meaningful or lack essential information. 86.179.112.1 12:44, 6 June 2014 (UTC)
 * Hi, thank you for your feedback. The position of the caption is not 100% set in stone, so it's always good to hear something about it. Thanks! Keegan (WMF) (talk) 17:25, 6 June 2014 (UTC)

-- If this feature is adopted I will use Wikipedia less for images and instead use Google images more.

Don't like this approach
Pros: Makes copyright status more noticeable Defects: Doesn't show previous versions and how to upload a modification of the file; suppresses left-hand column of links; no access to categories Brews ohare (talk) 16:11, 6 June 2014 (UTC)

My objections would be largely met if the "Learn more" link to commons were identified clearly as the same-old-same-old commons page for the file where everything I'm interested in is listed. Brews ohare (talk) 02:27, 8 June 2014 (UTC)


 * "This is the same page that you've always gone to" isn't exactly going to be a useful label for most people, especially people who haven't made thousands of edits like you.   However, improvements to the labels and buttons is something that I'm sure the team would be happy to hear about, so if you've got a suggestion for what to say instead of "Learn more", please post it.
 * In the meantime, if you don't want to disable Media Viewer entirely, and you want to skip straight to the description page on a given image, then opening the image in another tab (Command-click on a Mac, probably Control-click on a Windows box) will take you straight there. Whatamidoing (WMF) (talk) 22:45, 8 June 2014 (UTC)

Please make Media Viewer a choice!!
Judging from the response here, which at this point isn't something one can simply ignore anymore, it's becoming more and more clear that most editors and others here at English Wikipedia don't like the new media viewer. We were told that this thing had "overwhelming user response...tested extensively around the world...had feedback from/useful to over ten thousand users, 70% of them" -- but we have yet been told 'how' Media Viewer is useful to them in ways the original arrangement was not. Would someone please tell us now? So far all we've heard is a claim about "confusing" file data, etc, all the while we've read about one fault and shortcoming after another from many editors. So we have to ask -- what's really going on here? Why hasn't most if not all users in this conference heard about the Media Viewer until just recently when it was forced as the default viewer on everyone? The average reader simply clicks on and views an image once in a while as they read an article, so obviously they're not going to be making the informed analysis that's coming from editors who edit and build Wikipedia. Therefore it's unfair to base any decisions on the general and passing comments of casual readers. It was disappointing to read that the individuals who are pushing the media viewer on everyone else are more concerned with the general reader than they are with us "power users". There would be no Wikipedia content without us "power users", and in that event, there would be no readers. The back bone and life blood of Wikipedia are its editors. English Wikipedia editors need to tell other editors and users to come here and weigh in, and to also let them know about The survey, it was simply wrong to "move forward" with this viewer as the default viewer when it is not wanted by so many people. Again, the casual reader only views an image in passing, so naturally most of them are going to say 'Gee...what a neat viewer', when asked. This sort of feed back is not what you should be basing your decisions on. Please be fair to everyone and make the viewer an option when someone clicks on an image. -- Gwillhickers (talk) 16:41, 6 June 2014 (UTC)
 * Dear Gwillhickers: Thanks for your prolific feedback (I notice that you have posted over a dozen times on this page in the past couple days, more so than other users). We appreciate your concerns, which we heard the first time you posted them, and have responded to in great detail already; there is no need to repeat these concerns over and over again. I can assure you that we care as much about editors as readers, and always aim to develop solutions that can support the needs of both user groups. As shown in the full survey report, about half of survey respondents are editors, who are well represented in this study. To determine the need for this tool over the past year, we hosted a dozen IRC and roundtable discussions with community members, who confirmed that the previous user interface was confusing and needed improvement: they generally supported Media Viewer as a practical solution to those issues. The tool has also been tested for over six months by 15,000 English Wikipedia editors on an opt-in basis, as part of our Beta Features program. After improving the tool based on their helpful feedback, we confirmed that it was useful to over 70% of survey respondents around the world; on that basis, we concluded that the feature was ready for wider release. This decision process is logical, methodical and we consider it to be fair. While I understand that you personally don't like this tool, we see no evidence of wrongdoing on our part, nor do we see evidence that "most editors and others here at English Wikipedia" don't like the tool. At this time, about 450 users have disabled Media Viewer on English Wikipedia, which is a relatively small number -- about 0.37% of the users who have been active since the rollout. So it appears that a lot of folks are giving Media Viewer a try -- and we encourage you to follow their lead. While we may not be able to answer every comment you post in the future, rest assured that we have heard your position, that we respect your views and that we will be taking them into consideration as we plan our next steps for this product. Thanks for your trust and understanding. Fabrice Florin (WMF) (talk) 08:32, 7 June 2014 (UTC)
 * , Yes, I have posted here a fair number of times because, one, I deal with, uploaded and edit many images, and have done so for years, and two, because I feel strongly about a few individuals taking it upon themselves to make this viewer a default, rather than a choice, knowing full well of the many problems that exist, and then try to justify it by referring to the approval of people who obviously are not aware of the many problems that media viewer brings with it. Three, I have tried this viewer, and your inference, "follow their lead", suggests I haven't and that my objections are unfounded, which is sort of an insult. In any event, if there was an option to disable the viewer, up front, with no hassels, I am confident you would see many more users disabling this viewer. -- I will try to keep my tone civil and maintain good faith, but I must say, you are certainly making this difficult with your insistence to push media viewer as the default, rather than an option, which would be fair to everyone. You should be basing your decisions on the feedback of experienced users, not those who drop in once in a while and say "gee what a neat viewer" when asked, which is in essence the basis of your approval rating. -- Gwillhickers (talk) 17:19, 7 June 2014 (UTC)
 * It's already "a choice", Gwillhickers. "A choice" is not synonymous with "turned off by default".  If you don't like it, then please go to Special:Preferences, under the "Files" section, and remove the checkmark.  Unfortunately, because of a lack of a global preferences system, you will have to do this for each wiki that you use, which in your case means once for Commons and once for the English Wikipedia.  Whatamidoing (WMF) (talk) 22:49, 8 June 2014 (UTC)
 * , no, actually I don't think you HAVE "responded to [Gwhillhicker's points] in great detail already". (1) I see nothing in Gwhillhicker's posts to justify a defensive posture. "[W]e see no evidence of wrongdoing on our part" does not seem warranted since I don't see an accusation of wrongdoing. Also, you have consistently cited the survey in many, many responses, so I see no reason to chastise Gwhillhickers for repeating the same arguments when I don't see anything new from the proponents of the tool. As for being prolific, most of Gwhillhickers' edits are quick rewrites of his owns posts. By contrast, I see massive numbers of posts by Quiddity, Keegan and, to be blunt, you. AGF goes both ways, don't you think? (2) You note that the survey was opt-in before people saw this tool. Are you saying the survey sample could not have been weighted to those who did know -- folks likely to be friends or family of project champions? (3) I am unclear why stale data takes precedence over current feedback. Your survey was done before roll-out. After roll-out, there seems (at least to a casual observer) to be a torrent of objections. Is it at least POSSIBLE that people have changed their minds or that the original consensus was flawed? (4) A small number, 0.37% of the people with accounts, have found the feature so intrusive that they've taken pains to disable it. Can you help me understand how that translates into approval? Everyone who got food poisoning at the restaurant liked it because only 0.37% called to complain? An extreme analogy, I know, but an effective one. (5) Can you also explain why that would apply to those who use wikis without accounts? Since half the people at the restaurant who got food poisoning didn't have phones, they MUST have liked it cuz they didn't call to complain?(6) I am intrigued by the fact that you do not "see evidence" that folks don't like the tool. By casual count, I see around 75 clear objections to either the tool or the roll-out plan. Are you saying that this thread and others like it are not valid? Does everyone who objects have to create an account and disable the feature in order for you to acknowledge that people can object in good faith? Is there some other forum where folks can ask that intrusive features should be opt in for the good of the WikiWorld? (7, and coming full circle) I don't hate this tool but object to forced-adoption roll-out. Is this not the forum for asking WHY? and then rephrasing the question if someone thinks it's been ignored or dismissed out of hand? We all want the wikis to improve and we (obviously) disagree on how. Do you have a constructive recommendation for reaching consensus that does not involves challenges on talk pages and (occasionally) a bit of friction when people (perhaps like Gwhillhickers) feel they have an important issue that they truly believe has been brushed off without a hearing by others (perhaps like some of the posts above)? 159.53.46.141 22:20, 9 June 2014 (UTC) (Kevin, same as other posts above)

Kill it with fire. Preferably something that you can't put out with any kind of extinguisher.
Horrible.

Horrifying.

Offensive.

When I click on an image, I expect to be taken to the file's info page. This is how it's always been done, and this is what makes sense.

1. You fucking click on something.

2. You fucking get its info.

It's not difficult. It's how a wiki, which is based on content and information, not pretty presentation, is supposed to work.

But some fucknut decided his pet project was more important than (1) convention, (2) consensus, and (3) common sense.

Instead, now the process is something more like this:

1. You click on an image.

2. You click on a really faint arrow at the bottom of the screen, or scroll upwards, or swipe upwards with your shitty touch-screen (which is what this POS seems designed for: tablets, rather than REAL computers).

3. You ask yourself, "What the fuck do I click on now?" You look around for eight minutes trying to find something that looks like "more on this image" or "image metadata" or "image page".

4. You click the link to the image source. This takes you to the image source's web page, rather than the file's wiki metadata page.

5. You go back, you try the uploader's page. No dice.

6. You find out that it can't be disabled without creating an account.

7. You find out that nobody who's in charge is planning on fixing (read: getting rid of) this pile of shit soon---as in yesterday. So you decide to try toughing it out.

8. You go back, on a whim, and then click "Learn more on Wikimedia Commons", :expecting to get an info page "on" (interpretation: about or concerning or on the subject of) Wikimedia itself,' or hopefully about whoever made this dumb media viewer application.

9. Sure enough, you "learn more". You learn more about the dumbass who made this and didn't think to put the words "about this image" in the middle of that link, so you can fucking know what it is you're going to be fucking "learning more" about, rather than misinterpret the ambiguously-worded link title.

10. You get pissed off, go write an angry review of this new "feature", and fully expect it to be removed by some butthurt overly-sensitive editor who doesn't understand what this whole wiki ecosystem is about:

Organizing information, making it free, and making it accessible, not about making it fancy, and not about making it family safe.

11. And then you wonder if maybe the bastard will lock the page to prevent "vandalism", just to rub it in:

'''Wikimedia isn't run by common people. It's run by corporate tools masquerading as common people.'''

You've fucked up, whoever designed this crap, and especially whoever decided to greenlight its use on a production website instead of testing it via opt-in. Go work on Uncyclopedia or the Encyclopedia Dramatica or somewhere else that might appreciate your incompetence.

(Oh yeah, want to hear something painful? If you'd done this right, maybe I would have supported it down the road. But now that it's been done wrongly, so magnificently wrongly, I'd rather spite every new mini-project that comes out later, than see mediawiki ever try to improve itself in the future, which more than likely will result in something like this happening again.)

Shame on you, and a pox upon your careers as software developers and decision makers.

— Preceding unsigned comment added by 198.228.216.29 (talk • contribs)  17:53, 6 June 2014 (UTC)

Agreed, this is horrendous.

Thank you for taking your time to leave this feedback. I'm certainly sorry that Media Viewer has caused you so much animosity- I hope that I can address some of your concerns. Your feelings are clear and I do not expect to change those. It seems like, ultimately, Media Viewer is not intuitive for you navigate around. There are things that the Multimedia team is doing right now to work on usability, based on feedback like yours. The link to Wikimedia Commons needs to be bigger, other points of navigation need more clarity, and it's important to get this right. Media Viewer has been opt-in for the past six months on the English Wikipedia through the Beta Features program, but you have to have an account to participate in Beta testing. The way IPs work there is simply no way to allow customization of Wikipedia or Wikimedia projects without an account. We will, however, be making it clearer and easier for IPs to find and access the original file page as well; IPs are humans too :)

Developing Media Viewer has not been a pet project, as you describe, but has been highly collaborative throughout its process, from conception to where we are now, getting feedback from you to make Media Viewer better. Keegan (WMF) (talk) 19:20, 6 June 2014 (UTC)
 * You could make things "better" for a lot of people by making this thing an option when we click on an image. Why isn't this being considered? -- Gwillhickers (talk) 19:58, 6 June 2014 (UTC)
 * I doubt that people would want to choose between new and old styles every single time they clicked on a picture.  It makes more sense to have a preference setting that lets you choose the default display method for you, which is what the Media Viewer team implemented.
 * Personally, I think a one-click system to change preferences would be desirable. Then you could have a one-time question on the first time you viewed a picture, or you could leave a message that said "click here to opt-in", instead of click here, scroll there, find the item, check the box, and save the page.  However, I've asked around, and the ability doesn't exist in MediaWiki.  (Also, if you've never seen Media Viewer before, how could you make an informed choice about whether you'd like to use it?  So perhaps it would have to be the second time you clicked on an image rather than the first.)  Whatamidoing (WMF) (talk) 22:58, 8 June 2014 (UTC)

Worse. Much worse.
Seriously. I don't like being rude after someone obviously spent a lot of effort on something, but this shouldn't exist, or should require some specific action to use. It's slow. It's ugly. It takes more clicks to do the same things. It uses icons in place of text. It duplicates functionality already provided by virtually all modern browsers. The old interface was substantially better. Click, pick which size I wanted to see, it loads. My browser provides loading status, pan and zoom functionality, etc. Two clicks to perfection. Picking the size lets me select the proper tradeoff between quality and load time. Quick, easy, functional. This crap? Not so. Separate content and presentation. Make it go away, preferably forever. If you want to actually improve the image viewing experience, spend your time tracking down and clubbing the people who upload tiny images. 74.207.250.159 20:41, 6 June 2014 (UTC)

Transparent pixels
Transparent areas of images display as the checkerboard pattern, which doesn't seem right. That pattern is to identify transparent areas when working on editing graphics, not when displaying them. Those areas should probably be displayed as white instead. 86.179.112.1 20:46, 6 June 2014 (UTC)
 * The transparent areas are also shown in that way, at standard File: pages, eg c:Category:Transparent has a few, specifically, File:Blue DualShock.png. I'm not sure what the benefits or drawbacks would be, of doing it differently in Media Viewer... Hmm, I'll ask around. :) Quiddity (WMF) (talk) 00:46, 7 June 2014 (UTC)
 * Only when the cursor is over the image. At least, that's the way it works for me. I don't know whether it's a browser-dependent thing. 86.179.112.1 02:58, 7 June 2014 (UTC)
 * Oh! My mistake and apologies. I've filed 66306. Quiddity (WMF) (talk) 04:58, 7 June 2014 (UTC)
 * Depends on the wiki. On Commons, it is always visible: commons:File:Disqus_d_icon_official_-_white_on_transparent_background.png --Tgr (WMF) (talk) 05:25, 7 June 2014 (UTC)
 * The checkerboard pattern is used to make sure the background color does not match the image color. Imagine File:Disqus_d_icon_official_-_white_on_transparent_background.png on a white background... --Tgr (WMF) (talk) 01:02, 7 June 2014 (UTC)
 * The checkerboard pattern is information for people editing the image. It is NOT intended to be displayed with the image in normal viewing mode. It is up to image users to ensure that white is not displayed on white, etc. 86.179.112.1 02:58, 7 June 2014 (UTC)
 * That's not true. Consider, for example, Google Image Search: when you look at the image in detail (click on it), you will see the checkerboard background. This is fairly normal behavior for transparent images. --Tgr (WMF) (talk) 05:22, 7 June 2014 (UTC)
 * You are wrong. Transparent should not shown as checkerboard in normal viewing mode. It should be shown as transparent. That is the whole point of transparent pixels. Google probably show it that way because they don't automatically/easily know the background against which the picture should be displayed. 86.160.85.177 11:23, 7 June 2014 (UTC)
 * It sounds like "what the designers originally intended" and "how transparent pixels are actually used in the real world in 2014" might have diverged some.
 * I don't really see any perfect solution here. If the image is a black dot on transparent, and you display it on a black background, then the image is invisible.  If the image is a white dot on transparent, and you display it on a white background, then the image is invisible.  Unless we're prepared to ban people from using images containing whatever color is chosen for the background, then the choice is between having some images that aren't visible to the reader, or some images that show the reader that some pixels are set to transparent.  Whatamidoing (WMF) (talk) 23:04, 8 June 2014 (UTC)

Deceptive language
On the Multimedia/Media Viewer/Survey/Results - 05-05-2014 page, the language used to describe "approval" is very deceptive. It says for example "73% of readers find the tool useful". Useful in what way? They don't say. Surely when readers click on an image the media viewer presents the image, so yes, it is "useful" in that regard. -- It's like they're asking a group of swimmers if they found the water "useful". In my opinion the "approval" survey is a sham.

Questions that need answering:


 * How else was media viewer "useful" for readers where the prior arrangement for file viewing was not?
 * What does the media viewer offer readers and editors that the prior file viewing arrangement did not?

-- Gwillhickers (talk) 20:48, 6 June 2014 (UTC)


 * One thing it offers readers, that I like, is a customized image-size to fit my viewport. Previously, we'd always get a 800px wide or 600px tall maximum (unless we'd logged-in and changed our preferences at that wiki). Now, I get large almost-full-screen images, on both my cheap small laptop and my decently sized desktop-monitor. I agree the Media Viewer could be further improved in many ways, or possibly certain decisions could be re-examined, but overall it seems to be a step (or 2) in a positive direction. Quiddity (WMF) (talk) 00:54, 7 June 2014 (UTC)


 * Before, if I wanted to see an image bigger, I clicked on it. If it was still too small, then I clicked on it again. Ironically, the images displayed in media viewer are smaller than the old system where you could easily get an image to appear in the browser's native image viewer. --94.195.183.212 03:30, 7 June 2014 (UTC)
 * I believe that the question being asked is, "Is this media viewer useful for viewing images and learning about them?", which allows survey respondents to make up their own minds about what they consider to be useful. Since the question is actually "Is it useful", then reporting the responses as "X% of readers find the tool useful" does not seem deceptive to me.  Whatamidoing (WMF) (talk) 23:08, 8 June 2014 (UTC)

How to get rid of the Media Viewer?
On Wikipedia I can't get rid of it. I've followed directions and unchecked etc. everything under "Preferences". On the Commons I've managed to get rid of it. What should I do? (It's extremely annoying and requires several extra clicks to do what I want.) Thanks,  Parabolooidal (talk) 21:44, 6 June 2014 (UTC)
 * Hmmm...did you make sure to save your preferences after you unticked the box? Did you "hard" refresh your browser after doing so (usually accomplished by shift+Refresh or shift+ctrl+R)? If none of this works for you, what browser are you using? Keegan (WMF) (talk) 22:18, 6 June 2014 (UTC)
 * To find out what the setting on the English Wikipedia is, be sure that you check w:en:Special:Preferences and look in the "Files" subsection. (Oh, how I wish that we had global preferences, instead of having to do things separately for each and every language edition of each project.)  Whatamidoing (WMF) (talk) 22:21, 6 June 2014 (UTC)
 * Could you please post the exact steps needed to disable this "feature"? Nwbeeson (talk) 23:13, 6 June 2014 (UTC)
 * To disable at English Wikipedia, click here, scroll down to the "Files" section, un-check the "Enable Media Viewer" box, and click "Save" at the bottom. Quiddity (WMF) (talk) 00:13, 7 June 2014 (UTC)

Destroy Media Viewer
It is one of the worst ideas I have ever run into from Wikipedia. I frequently look at pictures. When I click a picture I do so to see the largest version that will fit my screen, and to be given the option of enlarging it to the maximum size uploaded. This used to be trivial, now it is arduous. Horrible change.

I edit every day. I have been editing for eight years. Today I have found an image that is in error. Before Media Viewer I could click the image, in one step I would have access to the original file, could download it, make the changes, and reupload it. Now I do not have any idea how to do that. The original needed no explanation. This new improved media viewer does need a tutorial. How is that an improvement?Nwbeeson (talk) 23:13, 6 June 2014 (UTC)
 * To access the standard image-page directly, you can either middle-click (if your mouse has a middle/scrollwheel button), or ctrl-click, on the image. I'm going to suggest an alternative, with my volunteer hat on, below.. Quiddity (WMF) (talk) 00:18, 7 June 2014 (UTC)

Cool!
Hi! I just wanted to say, this is a very nice way to look at images! I am glad to be able to have the clearer visual distinction between the content and the metadata. Thank you! I have a couple of minor criticisms, but overall it is great. My thoughts on how it could be improved:


 * I'd like to be able to tap on the image to get the original file; right now it doesn't do anything.
 * It is a bit visually jarring having the down-pointing arrow, the right/left pointing arrows, and the close/full screen buttons all have different line thicknesses. They could all be the same I think.

Those are very minor issues I have with it though. Thanks again for the great work developing this tool! Goldenshimmer (talk) 00:23, 7 June 2014 (UTC)


 * Dear Goldenshimmer: Thanks so much for your kind words, which are particularly welcome at this time :) We will take your recommendations under consideration. You make a good point that the thickness lines could be a bit more consistent and we will pass on your suggestions to our design team. Thanks again for taking the time to share your appreciation for this tool. Be well. Fabrice Florin (WMF) (talk) 02:24, 7 June 2014 (UTC)

Direct access, via the magnify icon?
Occasionally, I'd like to be able to directly access the file-page, particularly as an editor. I know I can do so via middle-click or ctrl-click, but not everyone has those options.

I was wondering if we could change the icon to link directly to the file-page? Or create a replacement for that "Magnify-clip" icon that would do the same thing?

Thanks for considering it.

(Overall, I really like getting fullscreen images now, instead of the 800px wide or 600px tall maximums we were previously getting. I hope we can get some sort of easy access to "2x fullscreen, and also original size", or a google-maps like zoom function, at some point in the near future, for better access to the Large Images. But as noted above, the multi-megabyte originals are rarely what I want.) –Quiddity (talk) 00:31, 7 June 2014 (UTC)
 * The new viewer will not fill your screen with an image if it's not large enough to begin with. Previously when an image was large enough to fill your screen, and larger, all we had to do is click on the image a second time to get the full view. This could and can be done in an instant. While you may have no interest in large image files with high resolution, most people want to be able to view them in full, esp where it involves images of maps, flowers, insects, birds -- nature. Hello? Yes, even a stopped clock is "correct" twice a day, but I don't see how this justifies a few individuals who apparently have taken it upon themselves to make this new viewer the default viewer, esp since it has created so much dissatisfaction, (which has been articulated time and again, unlike it being "useful") for so many editors. Again, most readers were happy and would find any viewing system "useful" no matter what they use to view images with. There was no outcry for a different viewing system, so I can only wonder if this thing is being forced on everyone for other reasons, esp since they have yet to even acknowledge the idea of making this thing an option when an image is clicked. It seems they are dead set on making this the default viewer regardless of the fact that it's a buggy system with serious shortcomings and that virtually no one asked for it. -- Gwillhickers (talk) 02:11, 7 June 2014 (UTC)


 * Dear Quiddity: Thanks for this constructive suggestion! I have added this ticket for consideration by our team: #702 Provide direct access to the file page via a small icon near the thumbnail. We'll discuss this idea on Monday and keep you posted. Thanks again for proposing practical improvements to this project :) Fabrice Florin (WMF) (talk) 02:41, 7 June 2014 (UTC)

Default enabling for logged in editors
I wish there were a stronger way I could get this across. Let's try.

'''Please do not, ever, for any reason, automatically set a new feature to "enabled" for logged-in editors. Let them know it exists, and give them the option to try, but don't just screw with their interface.'''

I'm awfully tired of having new "features" that entirely break my workflow turned on and slap me across the face, and make me go to Meta or here to figure out how to get rid of them. I actually rather like this feature for the casual reader, it's more modern looking and I imagine it will be well received among the general readership. But it's very poor for an editor, especially one working with images. All new features should be opt-in for logged-in users. Seraphimblade (talk) 02:27, 7 June 2014 (UTC)
 * I have several times asked that the viewer be presented as an option, not "burned" or "destroyed", when someone clicks on an image, but evidently this is not considered a "constructive suggestion" and has not even been acknowledged by the few individuals who are promoting, pushing this viewer and who of course want to be fair to everyone, esp the editors who have given much time and effort, years, into building Wikipedia from the ground up. I have submitted a couple fair questions to this effect but they continue to be ignored by our friends with smily faces. For example, how has the viewer been "useful" in ways that the prior viewing system has not? As for the "70% approval rating", the 70% figure comes from average readers who were impressed with a couple of images and obviously had no idea of all the shortcomings and faults this new viewer has presented to very many editors and users. -- -- Gwillhickers (talk) 03:15, 7 June 2014 (UTC)


 * Dear Seraphimblade: Thanks for your proposal. I'm sorry that this new feature took you by surprise. It has been tested for over six months by 15,000 English Wikipedia editors on an opt-in basis, as part of our Beta Features program. After improving the tool based on their helpful feedback, we confirmed that it was useful to over 70% of survey respondents around the world; on that basis, we concluded that the feature was ready for wider release. We appreciate your suggestion to have new features be released on an opt-in basis for editors and on an opt-out basis for readers: as much as we'd like to provide special treatment for valued editors like you, this approach would provide an inconsistent user experience that would confuse users. For example, editors who temporarily log out might not understand why images suddenly open in the Media Viewer and would start complaining, rightly so. Instead, we recommend that you give the tool a fair try, become familiar with its features, and see if it grows on you over time. Note that you can press shift-click or control-click to bypass Media Viewer when you want direct access to the file page, as documented in the Help FAQ. Over time, we hope that you find enough value in the tool to use it for your own purposes, but fully respect your desire to disable it if it doesn't work for you: to turn it off, simply click on the 'Preference' link provided at the bottom of the Media Viewer panel, and uncheck 'Enable Media Viewer'. Thanks again for taking the time to share your perspective, which we very much appreciate. Fabrice Florin (WMF) (talk) 03:01, 7 June 2014 (UTC)
 * Actually, what confused me was to have the thing turned on, whereas providing an "inconsistent user experience" would have left me, well, not even knowing or caring it was "inconsistent". Editors and readers don't use the same features because they aren't doing the same thing, so there's nothing wrong with differentiating the interface between the two. But it's pretty clear that this is VE round 2, and that you'll make the same attempt to blow off and discount editors with the same nonanswers and superior tone as you did with that project, while referring to a nebulous group of "readers" who, interestingly, invariably agree with what you wanted to do anyway. I'd hate to see the same result, as this actually could be a useful feature, but this smug and nonresponsive attitude will cause blowback. At the very least, on first invocation, provide a "Don't use this feature again" checkbox, prominently, instead of requiring digging to figure out how to disable the thing. Seraphimblade (talk) 03:41, 7 June 2014 (UTC)
 * Hi Seraphimblade: Thanks for suggesting that first-time users be given the option to disable Media Viewer. We considered the idea of a first-time guider showing how to use or disable the tool -- but it didn't seem needed at the time, given that Media Viewer was so favorably received in our first pilots (e.g. French, Portuguese, Spanish Wikipedias -- where a majority of survey respondents give the tool high marks). But I agree with you that this type of guider could have been useful for the English Wikipedia release -- and we will keep it in mind for future roll-outs. I'm sorry if we come across as 'smug' and 'nonresponsive': we care deeply about our users and have engaged community members as partners on this project since its inception, through a series of discussions, beta programs and surveys. And our team has responded to most comments on this page, in good faith, with as much information as we could provide. Just like you, we aim to make Wikipedia better for our users: our goal is to modernize our aging software infrastructure, and make it more inviting to the many new users we need to grow our community. We would be grateful for your support to help reach that goal in coming years: there is much work to be done to catch up with user expectations. We may not always get it right the first time, but we're committed to improving the tools incrementally, based on community feedback. Thanks for your understanding. Fabrice Florin (WMF) (talk) 07:03, 7 June 2014 (UTC)
 * Seraphimblade You have it so right. Mr. Florin and company are starting to sound like politicians with such ambiguous and generic rhetoric as they continue to refer to the "approval" they received from occasional and naive readers, apparently knowing full well they were not aware of all the many problems this viewer is saddled with, which is obviously why they approved. I hardly think anyone would have approved of this viewer knowing all the many faults and shortcomings it has. Media viewer is supposed to be a solution for a problem that doesn't exist. Media viewer is the problem. The idea that a few individuals have pushed this on everyone as the default viewer while toting their deceptive "approval" ratings is a shame. Consequently it's been very difficult to maintain good faith for these individuals, esp since they continue to ignore fair questions.


 * In what ways did people find media viewer "useful" where the previous viewing system was not?


 * Why have they not presented media viewer as a choice, getting feed back from experienced users, before they took it upon themselves to force it on everyone as the default viewer?


 * Is there a software developer making a lot of money on this deal?  -- Gwillhickers (talk) 16:57, 7 June 2014 (UTC)


 * For Seraphimblade and anyone else who doesn't like being "surprised" by changes to the software: Please consider subscribing to m:Tech/News, so that you will get a concise summary of nearly all upcoming changes, almost always with a link to a page that contains opt-out instructions.  Whatamidoing (WMF) (talk) 00:59, 9 June 2014 (UTC)

Dumbed-down is not the way to go
Please drop this new dumbed-down information-less image viewer. People actually go to WP for information, that's what an encyclopedia is for. When I click on an image, I do so because I want information about the image, and I want to see it larger. I used to get just that: information about the image, and several sizes to choose from including the full native size. Now I barely get any information and no metadata, not even basics like the picture's size, and I get just one size which is not the full size, and no zoom. What are you guys at Wikimedia thinking? First the editor disaster, then the font disaster, now this... Jim Wales: I think it's time for some heads to roll... WinTakeAll (talk)

Request for Comment about Media Viewer
A Request for Comment is at en:Wikipedia:Media Viewer/June 2014 RfC. I am not voting but I see that a number of editors have expressed opinions and I think it would be beneficial for the community to reach consensus about whether Media Viewer should be enabled or disabled at this time. This RfC affects English Wikipedia only but the feedback it produces may be useful for development of Media Viewer for all wikis, and I want to stress my neutrality on the issue. --Pine ✉ 07:59, 7 June 2014 (UTC)
 * Hi Pine, I think your proposal for an RFC on this is a very good idea, but perhaps not yet? I think the viewer is immature and rollout has been crassly handled - witness some of the abuse here - but there's a good piece of work trying to get out. Several people (myself included) have made suggestions that surely will improve acceptance: providing a direct click-thru icon to Commons, providing a way of tagging (say) small images to exclude them from the carousel, and fixing a number of bugs. So I maybe the developers should be given a chance to get version 2.0 together before everybody decides? Munrogue (talk) 21:11, 7 June 2014 (UTC)
 * PS: I had an idea about rollout, too. Maybe in future major features could be rolled out to users in descending order of edit totals. That would be progressive, and experienced editors would give vital early feedback. Munrogue (talk) 21:11, 7 June 2014 (UTC)
 * Pine, thank you for the RfC. I strongly oppose the new default and have added 10 reasons why. -- 79.253.58.136 21:19, 7 June 2014 (UTC)
 * I'm assuming that this RfC would only be binding to the English Wikipedia. Would people suggest that each individual Wikipedia project start their own RfC, or should there be a centralised RfC for all projects? --  李博杰  | —Talk contribs 06:30, 8 June 2014 (UTC)
 * 李博杰, as a general rule, each community makes its own separate decisions. The mid-size and smaller projects don't want a couple of big ones deciding everything for them.
 * Munrogue, it is (finally) possible to deploy at least some tools to smaller groups of editors. I'm not sure that choosing high-volume editors first is always going to be appropriate.  This particular project is aimed primarily at readers, not high-volume editors, so the views of people with tens of thousands of edits is probably not as relevant as the views of people with new accounts.  Also, high-volume editors tend to be vandal fighters and wikignomes, which are probably the two groups of editors least likely to care about this particular feature (or even notice it:  how often does a vandal fighter need to click on any image?  Personally, I click on only a handful of images in a month).  I fully agree with you about doing progressive rollouts on the larger wikis, but I don't agree that high-volume editors are always the ones that should be first on the list.  Whatamidoing (WMF) (talk) 01:24, 9 June 2014 (UTC)

Media Viewer attribution problem
If I contacted a third party flickr owner to get an image freely licensed...and that third party cannot even see himself attributed in the picture due to Media Viewer, he/she will slam the door on licensing any future images freely, I would think. People take attribution very seriously and Media Viewer just takes away all attribution. Most people won't bother to click a button or link. They will just feel lied to--all because of this new feature. If Full attribution information is not given on Media Viewer, this application won't help Wikipedia users trying to get images freely licensed at all sadly. Didn't anyone think about including all attribution information with a larger picture that Media Viewer shows? I am a reviewer on Wikicommons and I think this new feature will hurt the Wikicommons project to get images licensed freely. There is no description data displayed for the images either...and this is supposed to be an improvement? That's just my personal view. Best Regards, --Leoboudv (talk) 09:11, 7 June 2014 (UTC)

Hi, maybe we mean different things by attribution? When I open an image imported from flickr, say, I see correctly the name of the author (linked to their Flickr profile) and the name of the image (linked to the original Flickr image page). If I scroll down, I can see the description and other details. --Tgr (WMF) (talk) 18:16, 7 June 2014 (UTC)
 * Comment: The image title text should be a bit bigger so that the flickr account owner who is being attributed could see his name more clearly rather than in a small size text like the one you described. I did have to scroll down to see the rest of the description but most people who want attribution won't think of doing this either--and the text is rather small. Thank You, --Leoboudv (talk) 20:43, 7 June 2014 (UTC)
 * Compare with the Flickr page - our attribution seems way more prominent to me. (Not to mention the comparison with the file description page, where you have to scroll down to even see any attribution.) Some metadata did become harder to find with MediaViewer enabled, but I think for the attribution the opposite is true. --Tgr (WMF) (talk) 21:40, 7 June 2014 (UTC)

click-through link
Hi! Why am I not able to get to the file description page by clicking on this button but am taken to the media viewer almost as if I clicked the image itself? Changing this would be very helpful. Cheers, DerHexer (talk) 09:52, 7 June 2014 (UTC)


 * Hello, DerHexer,
 * Do you think that the suggestion described in the section above would do what you want?  Whatamidoing (WMF) (talk) 01:27, 9 June 2014 (UTC)

Bugreport: Up/down arrow keys
Hello. Please report this bug to the appropriate bugtracker so that the developers can fix it as soon as possible. Here’s the bug report:


 * Steps to reproduce: With MediaViewer active, press Alt-Up.
 * Expected behaviour: Nothing.
 * Actual behaviour: The same as Up.

More comments: This suggests to me that the keydown handler simply forgets to check for the modifier keys. Please fix this so that it will only respond to Up/Down, but not Alt/Ctrl/Shift/etc.-Up/Down. The reason this is important is because some browser add-ons use Alt-Up and Alt-Down as shortcuts for their features, and MediaViewer swallows that.

Thanks! Timwi (talk) 10:15, 7 June 2014 (UTC)

Thanks! Tracked. --Tgr (WMF) (talk) 18:23, 7 June 2014 (UTC)

Bug report: Scrollbar non-functional
Steps to reproduce:
 * Using Firefox 29, open the Media Viewer for a large image (e.g. the first one on Eiffel Tower did it for me).
 * Click on “Use this image”.
 * Click on “Embed”.
 * Open the drop-down in the bottom of the popup area. You should see something similar to this screenshot.
 * Attempt to use the scrollbar to scroll the list in any way.

Expected behaviour: The scrollbar should work as normal.

Actual behaviour: The drop-down list is closed. The scrollbar cannot be used at all.

Please forward this bugreport to the appropriate bugtracker. Thank you! Timwi (talk) 11:09, 7 June 2014 (UTC)

Hi, can you add details about your OS and screen size? I tried to reproduce this on FF 29 / Ubuntu but could not - the drop-down has no scrollbar. (Which is expected behavior: we positioned it so that it should always fit the screen.) --Tgr (WMF) (talk) 18:27, 7 June 2014 (UTC)

Can we please let the browser and OS handle the way we look at images?
If I use my Moto X or iPhone to view an image, pinch-zoom only works to a very small degree until I go to a high-res image. This is irksome, but I can deal with it. As I move up in screen size to an iPad or a laptop, I wind up boxing with the user interface.

If I try to zoom in and pan on an image, the metadata pane slides up over it, blocking my view. In some cases, a last modified pane shows up over the top portion of the image. It's unclear how or why this shows up.

Different window elements move at different rates relative to scrolling. While this is visually interesting and amusing for the first second and a half, it ends up being obtrusive for every moment after. I'm viewing an image. Scroll, pan, and zoom actions should scroll, pan, and zoom  THE IMAGE, right? Not the random UI elements around it. I had to go on a hunting expedition, and was totally surprised to find the "use this image" button was really a popup menu that would lead me to a link ("Preview in browser"). After all, it looks almost exactly like the OS X / iOS Share Button, which has absolutely nothing to do with viewing images.

What's your use case here? Do you really have millions of users more interested in downloading the image (GIANT GREEN BUTTON) than, oh, I dunno, viewing the image in a browser (tiny blue link)? Are users really more interested in using their scroll feature to view metadata, rather than, say, scrolling the image?

Please, in the name of all this is good and holy, remove this terrible ZOMG WEB TWO POINT OH EVERYTHING HAS TO BE SHINY AND MOVE AROUND crap. — Preceding unsigned comment added by Tntc.tig (talk • contribs) 11:50, 7 June 2014‎

Nice feature, lots of room for improvement
a) Please fix progressive image loading. Browsers support this properly; here's a 5 minute hack demoing progressive update of a thumbnail: http://jsfiddle.net/Czwpu/1/ - click "Load" and watch the perfectly progressive update. (watch closely, because once the full-sized image is cached by the browser, you won't see the progressive update again).

b) It's too difficult to navigate to the full-sized image. Please add a direct link to the full-size image in the info panel.

c) BUG: The image loaded is not large enough: my screen is 2560x1440, and my zoom is 150%. The viewer chooses the wrong sized image, making it blurry. I imagine this is a blurry problem for anyone with high-DPI laptop screens too. This is made extra bad by the fact that the larger variants are now much more difficult to access (no obvious link anywhere in the info panel). Easy to reproduce, too: just zoom to 500%. The image should NOT go blurry as a result of this, but it does, because you replace a perfectly fine high-res image with a blurry tiny one, then zoom that.

d) Those mystery-meat buttons in the top right... Cannot be selected by typing, cannot be understood without mouse hover, cannot find the right one until I've hovered each and every one... Worst UI trend in years. Please add clickable text labels.

e) The weird-scrolling panel. It's... it's just weird how it scrolls. It's an unusual departure from conventional UI with minimal benefits. It is disorienting when you scroll but the image stays, and probably responsible for many people's negative reactions.

My initial reaction was negative, and I think that was down to reasons a) and e) more than anything else.

--Romanski (talk) 11:57, 7 June 2014 (UTC)


 * It's the greatest shit i ever had seen. Sorry --217.246.198.83 15:28, 7 June 2014 (UTC)


 * This is useless as it sits, the "view original image" option also gives a gargantuan result, what we want/need it the link to go to the description page on wikipedia where one can edit, access information, and so on. the "learn more on commons" link gets you there, but it is not intuitive or easy to find. This setup is a HUGE pain in the butt for anyone trying to verify copyright information also.  In general, why did WMF, once again, have to fix something that wasn't broken, and why do it the same klunky way that Flickr did it??  Montanabw (talk) 17:06, 7 June 2014 (UTC)

Hi, thanks for the feedback! --Tgr (WMF) (talk) 04:59, 9 June 2014 (UTC)
 * the demo doesn't work for me (or maybe I am just not getting what is it trying to demo). Can you describe your intent with it?
 * can you give your browser/OS details, and which image you are experiencing the blurryness with? If you are comfortable with your browser's debug toolbar, can you check the URL of the thumbnail that's being served when you see blurryness? We take devicePixelRatio into account, and modern browsers manipulate that on zoom, so in theory, using above-100% zoom or high-DPI screens should not cause a problem. (We did test on various high-DPI devices, as well, and the images looked crisp. I re-tested now on current Chrome: in 500% zoom, the image box is 100 pixels wide, and the thumbnail is 640px, so it has more than 5x more pixels, as expected for a devicePixelRatio of 5.)
 * the navigation buttons can overlap the image, depending on aspect ratio, so we are trying to keep them as simple as possible, with no labels. And the icons are pretty self-explanatory, I think. Also the keyboard equivalents are quite obvious, with the exception of zoom (which also has an obvious keyboard control but it is not handled correctly). That said, putting those buttons on top of the tab order would make sense. I filed and.
 * IIRC we have UX tests planned to compare scrolling modes.
 * The demo works for me (latest Chrome on Windows). In it, when the button is clicked, the thumbnail image displayed at large size on the right is progressively replaced with the full-size image as it loads. —  Scott  •  talk  12:18, 9 June 2014 (UTC)

Not a nice Surprise!
I was using the German wikipedia and this new mediaviewer caught me by surprise. My first thought was WTF, another site goes web 2.0, what has happened to KISS (keep it simple, stupid)? The invaison of the touchscreen...

And to change it back to the old version, I'd need to create an account and log in each time? I have no intention to become an editor neither in the German nor English wikipedia.

I'm working with senior citizens, some of them love wikipedia, they get informations about their hobbies, or the towns/counties their grand/children are living in etc. They often click the photographs and teaching them how to zoom in has been easy. Now with the new mediaviewer, they'll be very much confused.

And what about people with older computers and/or a slow connection to the internet? Please make it opt-in, I don't mind wikipedia to set a cookie with the options.

This is the first time ever I wrote on a talkpage, so yes I feel strongly about it.

Monika from Germany

--46.114.28.147 17:44, 7 June 2014 (UTC)


 * Thank you, Monkia, for taking the time to find the right page and post your comments where the Media Viewer team will be able to see them. I'm sure that they will consider your suggestion.  However, the policy of the Wikimedia Foundation is that all cookies must expire every 30 days (or sooner).  If you don't have an account, you would have to re-state your preference every 30 days, and that might be annoying, too.
 * By the way, I would be very interested in hearing what your group of senior citizens thinks of it, after they've had a fair chance to try it out. Whatamidoing (WMF) (talk) 01:40, 9 June 2014 (UTC)

Please restrict all such "improvements" and "features" to special subdomain (eg, en.fresh.wikipedia.org, jp.fresh.wikipedia.org)
In this way, the well meaning and helpful people dedicated to making the Wikipedia interface as "fresh" as possible while insisting that those who dislike it are "afraid of change," "never objected when the change was proposed", "don't have valid objections" or "don't have specific objections" can still make the changes they want and do the things they want - and they won't have to put up with overwhelming dissent and sadly predictable controversy.

Additionally, it would then be a simple matter to allow those of us who financially support the foundation to specify our preferences regarding whether our largesse should support fresh.wiki. This is an important advantage! I would feel confident that my donations were supporting improving the quality of the wikipedia articles and images. At the moment, I am reluctant to donate, as some of my funds may instead be spent enhancing wikipedia article javascripts and image viewer widgets. To my mind, this is a clear cut waste of resources, but there is a clique of people who certainly believe that wikipedia will perish if it doesn't immediately default to a Flickr Image Viewing Experience, and I think they should have the opportunity to see precisely how much their work is valued without requiring the rest of the project to suffer. — Preceding unsigned comment added by Thebrainsalad (talk • contribs) 21:55, 7 June 2014‎


 * Thank you for taking the time to share your opinion.
 * There is already a method of getting "fresh" updates, early in their development. Go to Special:Preferences and choose "Automatically enable all new beta features".
 * I don't know whether the Wikimedia Foundation accepts restricted donations, outside of the occasional large grant. Since the typical donation from a reader or editor is about US $20 or $30, it probably would not make sense to accept restricted donations of that size.  (It would cost more than $30 of staff time to do the legally required accounting paperwork for the money.)  If you'd like, I could try to find out the answer; just leave a note on my talk page.  Whatamidoing (WMF) (talk) 01:47, 9 June 2014 (UTC)

What a piece of crap
Why should I waste time to produce a 4177 x 2026 drawing - when no normal reader is able to look at the details because this idiotic feature allows them a 50% version at best. End that now or at least limit it to jpegs or something! Alexpl (talk) 22:36, 7 June 2014 (UTC)


 * Hi Alexpl,
 * That's an awesome image. I wish it were larger in the article.
 * If viewers click through to the original description page on Commons (there are at least two links to it in Media Viewer), then they can see exactly the same thing that they've always been able to see. For most users, what they'll see first in Media Viewer is larger than what shows as the default on the file description pages.
 * Keegan, this image has annotations on it, and they're not available in either the old-style description page at en.wp or in MediaViewer (for me, at least, but my connection's been a bit flaky today, so maybe it's just me). Is this something on the list for the future?  Whatamidoing (WMF) (talk) 01:57, 9 June 2014 (UTC)
 * I am seeing the annotations on the en.wp file page; I'm not aware of this having been brought up. I'll find out and probably file a bug for it if one's not there already. Keegan (WMF) (talk) 17:52, 9 June 2014 (UTC)

Why is media viewer not activated by a button at each article that offers the option of viewing the images as a slideshow since that is what it is?
And if a reason for media viewer is to enhance the  multimedia experience of Wikipedia articles, it makes no sense whatsoever that instead of the image caption from the article being directly below the image  in the media viewer, instead the title  of the image which was selected by the image uploader is below the image and one has to scroll down to read the image caption from the article. The article might have little to do with the name for the image selected by the image uploader, while the image caption relates to the images reason for being in the article. How does a slideshow with image captions that are often not or only marginally related to the use of the image in the article add to a multimedia experience? Will this be changed or are we to go back and reload images to Wikimedia multiple times with titles that are the caption of each use in an article so the slide show will be a multimedia experience?

I have read most of this discussion and it has already been mentioned that having the link to the Wikimedia Commons Image titled "Learn More on Wikimedia Commons" instead of "Image on Wikimedia Commons" or "Learn more about the image on Wikimedia Commons"  just about makes zero sense unless the purpose is to obfuscate the link to the full resolution image on Wikimedia Commons to limit bandwidth usage; this is also a source of major frustration when first subjected to the media viewer along with the fact that media viewer  totally distorts many images when using IE10. Also, when using IE 10, the bottom of the image is blocked by the caption and there is no media viewer full screen  option available that would allow the full image to be seen in the viewer. So, basically, having a slideshow option is a plus but should not be a default. The slide show can be a worthwhile multimedia experience if the caption from the Wikipedia article shows in the media viewer directly below the image. The link to the Wikimedia Commons image page and full resolution image should be very apparent when viewing the images as a slideshow.

Thanks! — Preceding unsigned comment added by 75.61.67.18 (talk • contribs)  23:33, 7 June 2014‎

Thanks for suggesting Learn more about this image on Wikimedia Commons - submitted a patch. --Tgr (WMF) (talk) 07:58, 9 June 2014 (UTC)

The "working on now" and "in progress" Mingle views indicate that we have a severe problem on our hands
Everyone, please follow the "working on now" and "in progress" links at the top of this page. Note that, without exception, none of the tickets reflect any key aspects of the things people here have requested:

NARRATIVE: I CLICK DRAG ON IMAGE. IMAGE PANS.

NARRATIVE: I ROTATE SCROLL WHEEL. IMAGE ZOOMS.

METHOD OF DISABLING MEDIA VIEWER WITHOUT REQUIRING LOGIN

METHOD OF PERMITTING ARTICLE AUTHOR TO EXCLUDE IMAGE FROM DISPLAY USING NEW IMAGE VIEWER

(To be clear, these are examples of tickets that don't exist and will never exist.)

Instead, we have things such as:
 * Make a column wider in the new viewer!!!!! Woohoo!
 * Improve WMV support!!!!! Woohoo!
 * Generate a single high resolution thumbnail and derive other image thumbnails from it!!!!! Woohoo!
 * Links initialized empty should have a default noop click handler!!!! Woohoo!

You are being politely assured that, in spite of: Dedicated and long suffering professionals are taking your input into account. Even at this late hour, even so late in the game, and even though random facebook users drop by to absolutely gush about their profound love for this new thing, changes are being made for you.
 * limited resources
 * the fact that you didn't bother to participate in a beta
 * the fact that the beta was announced in a $10 million advertising buy including a 4 page spread in the Wall Street Journal SIX FULL YEARS AGO
 * that you are very rude...

However, you can see what changes are being made. You can see what changes are planned.

None of your changes are being made, nor are they planned, nor are they even acknowledged as "could have." They are "can't haves" until this fracas gets so totally out of hand that A Person Who Owns This Damn Place catches wind, sends a terse three line email, and makes the new image viewer opt-in. Then it's like this never happened except that even mentioning it causes the record needle to scratch and lift, conversation to stop, heads to turn, sweating and blushing in shame and running into the forest screaming with the seat of your pants aflame... .. ..

— Preceding unsigned comment added by Thebrainsalad (talk • contribs) 08:00, 8 June 2014‎

As a matter of fact, tickets for the things you mention do exist (and have existed for a while): zoom + basic zoom, offering a way for authors to disable MediaViewer (note that they already have multiple ways of doing so, they are just not ideal), quick button for disabling MediaViewer

Also, unlike the false impression you are trying to create by cherry-picking relatively unimportant tickets from our backlog of several hundreds, the tickets scheduled for next week are ones that have been requested: fixing the download of the original file, making which button does what more obvious, making it easier for non-logged-in users to get to the file page, making it easier to view the file in larger resolutions, fixing an IE10 bug that has just been reported. --Tgr (WMF) (talk) 06:21, 9 June 2014 (UTC)

"a $10 million advertising buy including a 4 page spread in the Wall Street Journal" - what? —  Scott  •  talk  12:27, 9 June 2014 (UTC)

Recruitment tool -- "If you register, you can turn it off!"
Since, in your infinite wisdom, you have decided to switch this so called feature to on by default for everyone's preferences; I wonder if you're keeping track of how many active users immediately turn it off? I'm betting that people are voting with their feet and stampeding away from this thing.

However, there might be a silver lining -- improving recruitment! If we tell anons that if they register, they can turn it off, I'll bet we'll have a surge in registrations! Elipongo (talk) 11:59, 8 June 2014 (UTC)
 * Well, what we don't want is a flood of new registered users who did so just to disable this thing. What we need is an upfront, quick and easy way for anyone to disable it, whether they are logged in or not. Users not logged in ought to have a way to disable it that will keep it disabled, at least for the session they are here for. -- Gwillhickers (talk) 16:26, 8 June 2014 (UTC)
 * Well, I do not think of myself as an editor, as I only did minor changes to a few pages in the fr Wikipedia. Instead I am a big user in several languages and never bother to log in (no need to, and also I'm often using a computer that is not mine). I hate this Media Viewer and right now I hate clicking on a picture. Anyway, comments on this page show that negative feedback is overwhelming.--Michel le tigre (talk) 21:57, 8 June 2014 (UTC)
 * Hello, Michel le tigre. The last I heard, feedback from the French Wikipedia was running around 70% support.  Support varies a bit between projects, but generally seems to be growing over time.  It's important to remember that if you like it and it worked for you, there's not usually much "useful" for you to say, so supporters tend not to post on a problem-oriented page like this one.  But people who had problems of any sort are motivated to report those problems.  The dev team needs their problem reports, so this ultimately works in everyone's favor, but it does make it difficult to accurately gauge acceptance.
 * Elipongo, I believe that they are tracking opt-outs among existing editors, although I'm not sure that they do it specifically for brand-new accounts. (I'm not sure that would be a good measure, because most readers wouldn't know that this could be turned off by creating an account.)
 * I don't have the numbers in front of me (Media Viewer isn't officially my project), but I believe that even at the wikis where it is the least popular, only about 1% of editors have chosen to opt-out. Overall, if you compare it to other new MediaWiki tools, that's a relatively low level of opposition.  Whatamidoing (WMF) (talk) 03:29, 9 June 2014 (UTC)
 * The "approval" for this thing seems to be a sham, i.e.claims made by the same individuals trying to force this on everyone and seems to be based on generic questions asked occasional and inexperienced viewers who only looked at a few images, not knowing the many faults and short comings of this viewer. I think this is a fair estimation because how could an adult with average intelligence "approve" of this thing once they are made aware of all its faults and short comings? See my similar comments on the talk page for en:Wikipedia:Media Viewer. -- Gwillhickers (talk) 05:17, 9 June 2014 (UTC)

Captions
In cases where picture captions can be easily extracted (e.g. from tag), would it be possible to put these next to the images, preferably readable without scrolling, so that you can read them as you flick through the slideshow? Typically on today's wider screens there is more space to the left and right of the image, so perhaps they could be placed there. 86.128.4.123 13:44, 8 June 2014 (UTC)
 * We are thinking about alternative ways to place captions. It would certainly be great to seem together with the full image; on the other hand both the caption length and the image aspect ratio varies wildly so it is hard to find an arrangement which would not look very broken in certain cases. --Tgr (WMF) (talk) 05:54, 9 June 2014 (UTC)
 * I think it should be possible to come up with a solution that nearly always works. Very long captions may have to be truncated (or require scrolling). At the moment, when moving through the slideshow, one is entirely reliant, in terms of what is easily visible, on the file names, which are of variable quality and usefulness. With the slideshow format, where images are thrown up with no surrounding article context, it becomes pretty essential to have full information about what you are looking at, which presently is not always the case. 86.130.66.213 13:43, 9 June 2014 (UTC)

Casual Wikipedia Reader: "I don't like it"
I'm not a Wiki contributor. I don't add or edit things, I just use the site as an information source.

When I clicked on an image, with the old way it took me to a page where I could see the file name, a preview, and the other image sizes that were available, all right there in front of me. This is pretty much all I needed. Nice, simple, and convenient.

If I wanted to, I could scroll down and see the licensing information, source data, pages where the file was used, and so on. This information is somewhat less useful for my general needs, but it wasn't an inconvenience to have it on that page as I could simply not scroll down if I didn't want to see it.

I don't like this new Media Viewer. I don't need a slideshow to scroll through all the pictures on a page. I shouldn't have to click on a tiny button to see the available image sizes when they used to be available right in front of me. On the occasions that I did read the source information, the information was clearly available, all I had to do was scroll down.

Please make this feature an option for ALL users. As I've said, I don't edit pages, so I have no need to register. I shouldn't have to register just to tell this site that I don't want the Media Viewer to open every single damn time I want to view an image.

— Preceding unsigned comment added by ‎ 74.103.11.138 (talk • contribs) 18:55, 8 June 2014


 * Thanks for posting this. This dev team is very interested in hearing from casual readers like yourself.
 * By the way, at least as a temporary workround, you can bypass Media Viewer by opening the image in another tab, e.g., by command-clicking or control-clicking on the image.  Whatamidoing (WMF) (talk) 03:34, 9 June 2014 (UTC)

Copyvio because of this new, non requested, feature. And other things
Look this photo, the source description follows the WCommons default and is normally required by Commons volunteers, and in the Media Viewer you don't even have all the authors, the only thing that licence demand, furthorme links to the images used... this results in no Attribution, so, copyvio.

More,

Look this:, this is a silly i.e., but this gonna work. If you read by the Media Viewer, you can't actually see who did the art, we describe what we did in the history, that's not accessible by this thing, so you could violate the authors' rights, not giving the credit, and the moral rights...

And more:

, if we read that trough the Media Viewer, we can't see the double license and the real therms, and we can download that without know.

There is are thinks that are bother me:

, ..., all of then have important information in their body, t, "Personality rights warning", about who produces, if this a part of a bigger project, if this a featured pictures... and this are not appearing! I know that all WMF is focus in Wikipedia, but this is important for Wikimedia Commons, and for other communities too, even for Wikipedia... and some notice are very important, with this new system people can download the image without reading any notice about the photo.

This file:, don't have half of the information as the old one...

Another think that are making me crazy:, this is a SVG image, but I only have a PNG option to download, and in the old system I can download this in at least 4 different sizes of png, and none of then, is tinny as you are offering me with the new system.

About the size, some images we need to see every single detail, as maps, diagrams... now we have to work three times more to reach the full-size, and I'm old as hell here, if you did that for a WP reader, they not even gonna scroll the image, imagine click to go to the normal page, and then go to full-size... they will miss the whole thing...

This is a free community, we need to grantee some informations to reproduce the results, and this Media Viewer not even show me the Metadata! Even the Google Plus brings the Metadata...

The last thing for the first impressions, yes I disable that to work better at Wikimedia Commons, but I used just for a day... we are in the social media era, why this share button is so hide and not easily clickable (share via FB/G+/...)????????? Or at least the "♥" button, the thanks for the uploader????? We need to spread the knowledge and we need to encourage our volunteers.

Speaking about Google Plus, why don't you do like than, and put the info in the right side? All images that I opened had tons of black, and just after 3 images I scroll and fond the link to Commons. Flickr also uses the right side to give info...

Did you talk with the Commons community, actually did you talk with any community before start?? Because I beg that you made that for WP-en, but I think that will not use that at all, by the discussions. I know some people asking for a better way to talk, like everyone that I know in Wikimedia Movement, why don't you sit and scale the priorities with the Movement before the development of a thing that they will not gonna use?

You need urgent fix the first things, for me, you need to remove that from the air, because this is a copyvio. I don't know why EUA people insist in release things that is not done, this affects tons of people, this needs to be flawless before goes on public. Peace. Rodrigo Tetsuo Argenton (talk) 22:09, 8 June 2014 (UTC)

Hi ! --Tgr (WMF) (talk) 05:49, 9 June 2014 (UTC)
 * Any license that is permissive enough to be useful for Wikimedia will permit displaying images the way MediaViewer does it. After all, in articles those images are displayed without any kind of visible attribution, while MediaViewer displays at least part of the attribution (and all of it for the huge majority of cases). We asked the WMF legal team for review before deploying MediaViewer, obviously. (That said, we do plan to fix the cutting off of long fields.)
 * I am not sure what you find unclear about File:Wikipedia-logo-en.png - when I open it in MediaViewer, it says Nohat (concept by Paullusmagnus), and that's all I learn from the file page as well. More generally, the author information should be there in the author field of Information - if it's not, the file page should be fixed.
 * you are right about the extra information - we have plans for displaying all three types you mentioned (personality warnings, providing institutions, quality assessments). I don't think they are critical features that should block releasing MediaViewer though - especially compared to the current inability to easily and quickly get an enlarged view of the images in an article, which *is* a critical defect from a reader's point of view.
 * not offering the original file format for download is a bug, we are working on fixing that.
 * as for the social media buttons, ask about them once more a bit louder, then observe the crowd with torches and pitchforks coming at you. (See e.g. the discussion here about how the passing mention of Twitter in a design mockup is proof that MediaViewer is the foot in the door for selling out Wikipedia to Big Business.)
 * we would like to add a thanks functionality in the future, but at the moment you can only thank edits, not uploads.


 * Thanks for the feedback Tgr
 * But some points,
 * First, enter again at the WP image, scroll, and you will see the history of uploads, none of them are the "Nohat (concept by Paullusmagnus)", because they described the original authors, not the guys who modifier that, and this is very normal at Wikimedia Commons.
 * Second, Wikipedia is not the whole Wikimedia Movement, commons:Main Page, we have a tweet button, and in pt version commons:Página Principal we have three social media to share that media. At the WN we have tons of social media buttons to share, in all published articles, i.e..
 * "Imagine a world in which every single human being on the planet has equal access to the sum of all knowledge." this includes spread the knowledge, and facilitate that.
 * Third, as this pop-up, readers will not go to the full page anymore, (could pleas track that, and share the reports?) so, if you do not put a direct link to the media page in WP article, as requested, this is a infringement, so at least put the whole information in that, upload history is important, the describe is also under a free license, the crazy double licenses... WMF do a lot of copyvio, small i.e., Grants:IEG see that little cat? IdeaLab_kitten_logo.png, is under cc-by-sa, so this requires a attribution... so, some times, I can be sceptical about WMF handle with copyright issues, and this increases when a remember that you use proprietary logos...
 * The last thing, images coming from Wikimedia Commons, that should be our main community to hear, I bet that half of this fellows of WP that are commenting about Media Viewer didn't notice the lack of the Metada, and it was one of the first things that I saw.
 * I really hope that this is not became a "unselectable" thing, as the global account, because for me, this will take years to be useful, if those.
 * Think about right side box, people are lazy, facilitate things, and be more close to things that they are accustomed. Rodrigo Tetsuo Argenton (talk) 09:22, 9 June 2014 (UTC)
 * The cat logo was created by a WMF employee as part of her job, and she added it to the page. There is no copyright violation there.  The fact that the designer made the image available as CC-BY-SA does not prevent her from using it herself under other terms, or from releasing it to other people under any other terms whenever she wants.
 * As for the general complaint that Media Viewer isn't complying with the license, I believe that the WMF's legal team has already reviewed this design for compliance with the license requirements. Whatamidoing (WMF) (talk) 18:20, 9 June 2014 (UTC)


 * You mention "the current inability to easily and quickly get an enlarged view of the images in an article", which is something I don't quite understand. What happens without Media Viewer if you click on an image in an article? You get: The Commons image page, which includes "an enlarged view of the image" at the very top - easily and quickly, in my opinion. And furthermore, it doesn't break the "look and feel" and navigation conventions of Wikipedia, you just navigate back with your browser's back button, all very intuitive. Also, the Commons image page doesn't just contain the enlarged view, but also very easily accessible links to other resolutions below the picture, and all available information further below; which, however, you don't need to scroll down to and read if you're not interested in that information. But if you're interested, it isn't hidden by some overlay. - The Media Viewer may still be nice for people who just want to look quickly at an image, but I don't think it has huge advantages even for "just viewing", and the disadvantages are too obvious to have this tool enabled by default. Gestumblindi (talk) 20:07, 9 June 2014 (UTC) (Admin @ German-language Wikipedia and Wikimedia Commons, for what it's worth ;) )

Next time you ask for money
Say what exactly it is going to be spent on. Saying "paying some dudes and the electricity bill" is not quite good enough. How much has this cost? Who decided to fund this? For what purpose and under whose authority?

I'm pretty pissed off that my money (and more importantly, that of less well-off donors) has been wasted on shit like this. And it is not the first time this happens either (e.g., that fancy editor thing from a year or so back).


 * — Preceding unsigned comment added by 2a00:1028:83a0:291e:762f:68ff:fe2d:429e (talk • contribs) 02:05, 9 June 2014‎


 * According to foundation:2013-2014 Annual Plan Questions and Answers, the multimedia team's work on Media Viewer was approved by and funded under the authorization of the Board of Trustees as part of the previous annual plan.
 * I don't know the funding source for Media Viewer. However, the funding source for VisualEditor was grants, so (as far as I can tell) no donor money has been spent on that.  Whatamidoing (WMF) (talk) 03:50, 9 June 2014 (UTC)

Editing images just got harder
I occasionally help out at the graphics lab map workshop. The procedure used to start But today, it started Maproom (talk) 14:36, 9 June 2014 (UTC)
 * Click on the image to get to a larger version
 * Follow a link to the version on Commons
 * Download it, and start editing.
 * Click on the image to get to a larger version
 * Wonder why there was no accompanying text
 * Follow some chevrons to other, irrelevant, images
 * Wonder what has broken and how to fix it
 * After a lot of searching, find the answer at the Wikipedia Help Desk


 * P.S. I have just seen the questionnaire near the top of this page.
 * Q1. How important to you is it that we implement “View original file” or a similar feature at this time?
 * a) very important. But it was already there and easy to use. It's now impossible, until you have figured out that Media Viewer is what makes it impossible, and then learned how to disable it.
 * Q2. Which of the following options do you think we should develop at this time?
 * d) Do Nothing
 * Maproom (talk) 14:48, 9 June 2014 (UTC)


 * Maproom; if you press ctrl and click on the image - the browser will open a new tab which contains the real description page. (btw. enwiki has a gadget which takes you directly to commons - its under "preferences" (top of the screen), then the tab "gadget" and click "Redirect image links to Commons for files that are hosted there", and save in the bottom) Christian75 (talk) 21:49, 9 June 2014 (UTC)


 * So it does! Thank you. Maybe this useful tip could be written in some of the black space that surrounds most images displayed in Media Viewer? Maproom (talk) 23:18, 9 June 2014 (UTC)

Thought my iPad was broken
The feature does not work on Safari or Chrome on iOS 4. Browser does not respond to tapping on the picture. Jimgawn (talk) 14:55, 9 June 2014 (UTC)
 * Doesn't work properly on iOS 7 Safari either. Cannot see the bottom of images.  Zooming makes things much, much worse. The infobox is a floating layer, and it zooms too, but stays glued to the bottom so it eclipses the entire picture.  There is absolutely no God given reason on the face of this earth for Wiki*edia to use layers in any way whatsoever, for display.  Maybe for sophisticated functions like editing.  They need to keep the code simple and let the browser do its job.  Every browser on every platform is capable of rendering a simple page correctly.  76.226.151.122 16:48, 9 June 2014 (UTC)

unclear new Media Viewer informations ...
Take a look here, a first public reuser ask me for the right attribution, because he only see the unclear new media viewer information. This is absolutely unacceptable. Please switch the new media viewer off, otherwise it is possible for reuser a copyright trap. --Alchemist-hp (talk) 17:13, 9 June 2014 (UTC)

Casual user dislikes whole idea of web-based UI
As another casual user, I would also like to indicate my dislike of the new Media Viewer and agree with 74.103.11.138's comments. 99.9% of the time, I am just visiting to find information. I have edited articles before on English Wikipedia, but only a handful of times when I found a glaring spelling error or similar. I don't have an account and I would consider myself to be more of a leech than a contributor.

In addition, I find it extremely irritating and unhelpful in general when websites forget that they are serving information and instead try to act like pieces of software and build user interfaces, which are inevitably jarring, non-standard and require extra thought from the user in order to figure out what the designer was trying to achieve. The number of times I abandon articles on news blogs and other websites because they are festooned with overcomplicated widgetry seems to be growing. HTML is a document markup language, not a user interface toolkit! No matter how many clever people write complicated javascript libraries and implement clever CSS hacks, building user interfaces using Web technology is still, in my opinion, a dirty hack and an attempt to fit a square peg in a round hole. I think Web developers who insist on making it fit need to regain some perspective on what's actually important and stop trying to circumvent standard Web behaviour. I always thought Wikimedia was immune from this tendency, being free from commercial pressures and fashions, but clearly I was complacent.

I used to help absolute beginners to use computers. People, generally elderly, who'd never even switched on a computer were shown how to operate a mouse and keyboard and progressed to web browsing and email. The sort of messing about with the way things work that's embodied in the Media Viewer is exactly the kind of thing that I used to find tripping people up. Tech people have a habit of assuming that the things they create are intuitive, without realising that, for someone who hasn't lived through what came before, it isn't intuitive, and is often unintentionally misleading. Often subtle misdirection is actually a goal, to serve some vested interest (e.g. conflate address bars and search boxes so that people fail to pick up on the way URIs (and therefore the Web as a whole) work and feel lost without your search engine).

In software and web design, the response to people being confused by things is all too often for designers to sweep away and hide the immediate objects of the confusion, further and further diverging from uniform, standardized sets of behaviours and expectations. In the wake of this, without clearly defined and predictable behaviour, it becomes ever harder to explain the underlying principles upon which things operate. It is not sufficient to explain to someone the basic concepts, because there are too many exceptions, amassed over the years. (Rather like the spelling of words in English, I suppose; you could spend a whole academic career studying the origins of it all.)

Something I worry about with the Media Viewer is that it hides away the way Wikimedia Commons works. How is a complete newcomer (say, a young child) supposed to pick up over time that the images they are seeing have been contributed by a community of volunteers, or generously donated by other organizations. How are they supposed to discover that they can make contributions like touching up an image, or even uploading their own? How are they supposed to know that the image has even been presented by Commons and not some third party image website? The majority of people will look at the enlarged image and leave it at that. At least with the old image pages, if you figured out that Wikipedia was community-edited, it was then quite easy to make the connection (because they looked the same) that the pictures were part of the same project and subject to the same basic principles. As years pass by, the number of people who first knew the old arrangement will shrink, and with it will shrink the collective understanding that this is a community-driven project that anyone can edit.

The correct way to implement this "view larger version of picture when I click on it" feature is to encourage web browser makers to implement it as a standard feature that applies to any image on any website, subject to user preference and to be enabled and disabled by web pages using CSS. Messing about with custom javascript implementations of it on individual websites, with all its attendant limitations, is a dead end best left to fickle commercial websites.

Also (and as rather an aside to my main points) window-filling pictures are too large. I don't need everyone within a 250m radius to be able to see what I'm looking at. I'm an introverted person, and it makes me feel self-conscious. I certainly wouldn't want to use this media viewer in a public library, for instance. 79.74.105.228 17:17, 9 June 2014 (UTC)

Use this file
"Use this file" should warn against using it before the persons has read the license. Christian75 (talk) 21:55, 9 June 2014 (UTC)

Irritating
Most often, when I click a wikipedia picture is to use it, not to have a cool slideshow. For this, the previous "viewer" was quick and perfect. I've spent a lot of time trying to figure out how to download the original (SVG) version of an illustration I already downloades last week in a couple of seconds; apparently only the screen (PNG) version can be downloaded from the viewer...

I like fancy, fashionable and useful interfaces, but if all three adjectives aren't 100% compatible, please, keep it useful.