Extension talk:Media Viewer/About

Proposal: View Original File


Hi folks, we would appreciate your thoughts about a proposed feature for Media Viewer: "View Original File", as described below.

In our surveys and discussions, many users have asked for either access to original files -- or a zoom feature. These frequent and related requests cover a range of use cases:
 * 1. Goals
 * view the original file in its full resolution
 * edit, crop and/or re-use images
 * zoom in to view details

To address these requests, this feature would enable you to access the original file from Media Viewer, so you can examine it in your browser, and easily edit/re-use it. To view that original file, you would simply click on a new "View original file" button next to the image, as shown in this mockup. This would open the original full-size image in the same browser window, as happens now when you click images in file description pages on Commons. Your browser’s back button would return you to the Media Viewer.
 * 2. Feature

This proposal would support the use cases above by providing the same core functionality editors are used to on file description pages. It would enable you to operate on files (convert/edit them), and also give you the ability to zoom on common file types in modern browsers.

The multimedia team has investigated several other solutions to address these user requests. We developed a Simple Zoom Link, which you can test now on Commons: but we’re concerned that this implementation provides a poor user experience that’s more complex than it needs to be. We also considered a Basic Zoom and a Full Zoom features. But these implementations require more development time than we have right now. We’re eager to wrap up this version of Media Viewer this month, so we can move on to other important issues, such as upgrading UploadWizard or fixing bugs in our technical debt.
 * 3. Alternatives

We’d be grateful for your feedback about this proposal and some of the short-term options we’re considering, by answering these two questions:
 * 4. What do you think?


 * Q1. How important to you is it that we implement “View original file” or a similar feature at this time?
 * a) very important
 * b) somewhat important
 * c) not important


 * Q2. Which of the following options do you think we should develop at this time?
 * a) View Original File (~1 day of work)
 * b) Simple Zoom Link - to original file in a tab (already on Commons, ~1 day to improve)
 * c) Basic Zoom - to original file in Media Viewer (~1 week of work)
 * d) Do Nothing

Thanks in advance for your guidance about this important issue. With your help, we hope to implement a practical solution that can address your most pressing needs in coming weeks. Regards as ever. Fabrice Florin (WMF) (talk) 23:27, 21 May 2014 (UTC)

View Original File: Comments
PKM (talk) 01:21, 22 May 2014 (UTC)
 * Q1: a,
 * Q2: a.
 * Thanks, PKM, much appreciated. Anyone else want to give us advice? Your feedback will help us make an informed decision to address this issue. Much appreciated. Fabrice Florin (WMF) (talk) 18:56, 22 May 2014 (UTC)

Quiddity (talk) 19:37, 23 May 2014 (UTC) If it's easy, I'd like to see the existing file-sizes linked, perhaps at the bottom of the info-area. I.e. Take the  stuff (screenshot) from File:Amerikanischer_Lenkballon_"Scout"_-_CH-BAR_-_3241653.tif and stick it in the MMV page in one of these 3 areas: https://i.imgur.com/EWI9bkC.png (ugly mockup!). But IANAD, so that might be a lot more complicated in practice than theory. HTH.
 * Q1:a.
 * Q2: I don't think a link to "original file" will work, because we have too many gargantuan pictures (dozens or hundreds of megabytes). I generally don't want to see a 80,000px wide image; I generally just want to double the size of whatever I'm looking at.

Dan-nl (talk) 06:15, 24 May 2014 (UTC)
 * Q1: b
 * Q2: a


 * one thing i don’t understand is that currently clicking on the magnifying glass brings you to the original file. that already seems fine to me. i think that all that needs to change is the icon used for the behaviour. the proposed icon is better than the magnifying glass, which i'd expect to represent a zoom feature in this context, but i'd rather see a file icon for the idea of going to the original image.
 * e.g., http://commons.wikimedia.org/wiki/Main_Page#mediaviewer/File:Dawn_on_cloud_nine.jpg
 * also, i think that an accessibility aspect is missing. a hover over the icon “should” tell me what the icon does; currently none of the icons tell me what they do; i have to guess.
 * another thing is that the URL i'm brought to is different than what i'm brought to from the File: page. the magnifying glass brings me to http://upload.wikimedia.org/wikipedia/commons/thumb/0/02/Dawn_on_cloud_nine.jpg/3000px-Dawn_on_cloud_nine.jpg, but a click on the image from the File: page brings me to http://upload.wikimedia.org/wikipedia/commons/0/02/Dawn_on_cloud_nine.jpg. which one is correct?
 * lastly, i'd rather see a link to the original File: page -- that's much more important to me.
 * found the tiny commons icon at the bottom right of the MediaViewer display that brings you to the original File: page. i'd rather see that icon more prominently placed; e.g. as one of the main icons of MediaViewer; e.g., under the double-arrow which triggers full screen display, with a tooltip something along the lines of “View file details’. Dan-nl (talk) 04:25, 28 May 2014 (UTC)

Dominic (talk) 20:31, 27 May 2014 (UTC)
 * Q1: a.
 * Q2: Sorry for not answering with one of the choices provided, but I strongly agree with Quiddity's comment above. I am especially afraid that, because of how MediaWiki handles files like TIFF and SVG, a "view original file" link will lead users to accidentally trigger downloads of files in formats that can't be viewed in-browser, which would be a bad user experience. I hope there is a solution that avoids problems with these edge cases while providing the basic zoom/"view full size" functionality you're proposing.

Comments submitted by email in the multimedia or commons mailing lists -- posted here by Fabrice Florin (WMF) (talk) 08:41, 28 May 2014 (UTC).

Gnangarra - Email sent Wed, May 21, 2014 at 6:01 PM
 * Q2: Zooming should be addressed separately ...

Rupert Thurner - Email sent May 23, 2014, at 10:57 AM
 * Q1: a. View the original file plus older versions is, from a glam upload perspective, mandatory.
 * Q2: a. Yes please.

Samuel Klein - Email sent 24 May 2014 12:28 AM (Right now, that is the primary way to interact with image pages on Commons: The largest active area on the page is the image, which when clicked takes you to the original file.)
 * Q1: a. Very important
 * Q2: Not merely "one more link", something central and obvious.

Andrew Gray - Email sent May 24, 2014 at 1:38 PM
 * Q1: a. Very important
 * Q2: I would agree that accessing the image description page/original image really needs to be more obvious than the buried "Commons" link (which is virtually invisible to anyone who doesn't know our site iconography). We've been telling people for years that if you keep clicking on the image file you'll get to our master copy in the end, so clicking on the expanded image seems a natural way to do it :-)

Update: Many thanks to PKM, Quiddity, Dan-nl, Dominic -- and email correspondents cited above. We really appreciate your helpful feedback on possible solutions to this issue. Based on what we've heard so far, most of you think it's a 'very important' issue (Q1). But there doesn't seem to be overwhelming support for this particular 'View original file' proposal (Q2): while some of you think it would useful, others feel strongly that we need another solution, because 'viewing the original file' can lead users to gigantic files that can crash their browser or trigger unwanted downloads; and yet others want a more prominent way to access the original file.

So based on all this feedback, we've been discussing our options and think this 'view original file' proposal should be shelved for now, as it doesn't address effectively the concerns expressed above. Instead, we're now looking to make our current 'Use this file' button more prominent, since it already provides the main functions requested above: its 'Download' panel lets you download or view images in a variety of sizes.

Here are the related feature improvements and bug fixes we are considering for coming weeks, in order of proposed priority:
 * Show larger Commons icon (#583)
 * Open 'Use this file' panel on hover (#662)
 * Put "Download" as the first tab of the "use" panel (#665)
 * Make "preview" shortcut more meaningful (#664)
 * Remember the last selection of the reuse menu (share, embed or download) (#660)
 * Keep the reuse menu open when switching between files (#661)
 * Show attribution credits in download tool (#598)
 * Keep the metadata panel position when switching between files (#501)
 * Turn "use this file" icon into a download shortcut (#663)
 * No way to download original file when the thumbnails have a different file type (#470) (related bug we plan to address anyway)

Together, these features and bug fixes seem to address most of the main issues we've heard so far, by making it easier to access the file page as well as any of the image sizes -- either for download or viewing. These improvements are not intended as a perfect solution, but as a placeholder that could be implemented in the few hours of development time we have left for this project.

Please let us know what you think of that approach -- and which of the improvements above seem most important to you. It's unlikely that we would have time to develop them all for this first release, so these tasks would need to be spread out over time. Thanks again for guiding our work to find a practical solution that can be built now, as a placeholder until we have more development resources. Fabrice Florin (WMF) (talk) 08:41, 28 May 2014 (UTC)

Categories
The categories as they are currently proposed by the Media Viewer are completely misleading. As far as I could guess, Media Viewer picks exactly three categories containing the file, and it is unclear how it picks categories. In most cases it picks one or several hidden categories (like License migration redundant or Flickr images uploaded by Flickr upload bot that are completely useless for viewers) and some irrelevant categories that do not describe the subject (like Males facing right or Black and white photographic portraits of men). Several examples: Such treatment of categories is very misleading and significantly reduces usage of categories, especially for new users who may never figure out how to find the categories. In my view, all categories except hidden should be shown in prominent place within the sight, without the need to scroll down, otherwise we can expect that newbies will never find out who categories work in wiki projects — NickK (talk) 23:29, 21 May 2014 (UTC)
 * go to commons:Category:Photographs by Lewis Carroll and click on File:Samuel Wilberforce.jpg. Obviously you expect to get commons:Category:Samuel Wilberforce to see other photos of this person, but no, you get Black and white photographic portraits of men, CC-PD-Mark, Males facing right (sponsored by Captain Obvious!)
 * go to commons:Category:Males facing right and click on File:Tadeusz Sznuk-2007.jpg. You probably expect to know who is Mr Sznuk and get to commons:Category:Tadeusz Sznuk, but once again no, you get GFDL, License migration redundant, Males facing right (a viewer has nothing to with the two first and already knows the latter).
 * Agree. I had reported part of this under 62277. Jean-Fred (talk) 07:36, 22 May 2014 (UTC)
 * Thanks, NickK and Jean-Fred: I had already filed this development ticket based on Jean-Fred's bug -- and just increased its priority on our current cycle wall. Keep in mind that we have a number of important tickets like this one in the queue, so it may not get done right away. But it's on the 'must-have' pile for now. :) Fabrice Florin (WMF) (talk) 19:05, 22 May 2014 (UTC)
 * This is not limited to hiding hidden categories. This also requires displaying all visible categories and not just first three in the alphabetic order. It should be split into two: 1) do not display hidden categories, 2) display all visible categories, and both are important, the second one is in my opinion even more critical — NickK (talk) 19:47, 22 May 2014 (UTC)
 * Displaying all visible categories is very important, but it would be enough. The file descriptor page should suffice for hidden categories. --ArnoldReinhold (talk) 01:03, 29 May 2014 (UTC)

If it ain't broke, don't fix it.
I'll be blunt: this sucks. It's just change for change's sake. I could get all the information I needed using the old interface. This new one just makes me go through more hurdles to get what I want. Not to mention, it looks out of place with the rest of the Foundation's websites.

I could see this possibly working for those with tablet computers. But not all of us use tablet computers. It's the same mistake Microsoft made with you-know-what.

I recommend giving all users, registered or not, an option to use the traditional image viewing interface if they don't like the new one. Even Google, the king of interface fiascos, still gives Google Maps users an option to switch to the older Google Maps. DaL33T (talk) 20:01, 22 May 2014 (UTC)


 * Blunt feedback is good, honest feedback. Thanks for that. Media Viewer's purpose as of right now is about displaying an image in a manner that does not involve accessing the stacks of information behind an image. Following that, it's definitely not going to be for you if the interest is the metadata and not the file itself. You're welcome to disable it, particularly on Commons if it interferes with your workflow, but I do hope you can find use for it when casually viewing files. If you'd ever like to use it again you can click on "Expand view" on any file page. Keegan (WMF) (talk) 20:27, 22 May 2014 (UTC)
 * Very good. Let me be blunt: you've made a horrid mess.  Did you ever stop to think that any idiot can find a big box on the file description page with the licensing?  Did you ever stop to think that it's easy to click on the normal-size image to get full resolution?  Any idiot who clicks on a smaller image and gets sent to a description page will try to click again and get a bigger image.  It's nice that I'm welcome to disable it, but you've apparently forgotten that you failed to explain how to do it at commons:Commons:Multimedia Features/Media Viewer, and you failed to provide any gadgets.  I've signed up for Wikimedia projects, not Flickr or Facebook, and it would help if Foundation people began to remember that, rather than forcing things on us such as Media Viewer or Flow discussions.  Nyttend (talk) 23:07, 22 May 2014 (UTC)
 * I've added information on disabling Media Viewer to that page on Commons, Nyttend. I appreciate you pointing that out. Keegan (WMF) (talk) 01:38, 23 May 2014 (UTC)
 * You shouldn't be making changes in the first place if you are not intimately acquainted with the one project that it affects the most. You shouldn't need to be informed of that page--it should have been the WMF that created that whole thing in the first place. Explaining the software to the community and providing an opt out should be priority one, in place before any changes actually go live. Trlkly (talk) 04:14, 29 May 2014 (UTC)
 * Is there a way to disable this annoying feature without having to log in? 86.27.176.158 00:20, 6 June 2014 (UTC)
 * "Did you ever stop to think that any idiot can find a big box on the file description page with the licensing?" Let me be blunt in return. Did you ever consider that an 'idiot' just skips over the big annoying box and doesn't actually DO anything with it ? So let's make the attribution and mission education flows better, with that I agree, but let's not kid ourselves that anyone but professional photographers and Wiki(p|m)edians and a few others are actually reading anything in that 'big box' (newspaper usage of Commons material makes this quite clear), let alone understand what it means. There are a LOT better ways to achieve those goals in my opinion and we should definitely be building them, but let's just tackle one problem at a time. TheDJ (talk) 13:12, 4 June 2014 (UTC)

Happy feedback
May I just leave a "useless" feedback like: "Great job! I definitely like this new tool. I have been loving it since the first time I tried it in beta"? Thank you all. :-) --Lucas (talk) 08:02, 23 May 2014 (UTC)


 * I strongly agree with this sentiment. (Unfortunately, most people are just opposed to any change, especially one that benefits readers more than editors.) Jay8g (talk) 01:31, 24 May 2014 (UTC)


 * Lucas, Jay8g: :) The team will be happy to hear. Thanks! Keegan (WMF) (talk) 21:14, 24 May 2014 (UTC)


 * I concur! --129.137.215.245 16:05, 5 June 2014 (UTC)

Can we vote on this? Please?
It seems like there are a good deal of people who are against the implementation of the New Media Viewer. Can we vote on this or something? HMS Indeconstructable (talk) 21:52, 23 May 2014 (UTC)
 * Yes, please.Crisco 1492 (talk) 08:42, 24 May 2014 (UTC)
 * Communities are certainly welcome to discuss Media Viewer as they see fit. Personally, I'd like to make sure that the discussion is not based on "I don't like it and I don't think anyone else does either" but actually had solid numbers and facts on how communities feel about Media Viewer, considering that !voting disenfranchises hundreds of thousands to millions who do not participate in internal project aspects and gives power to those for whom the product is not necessarily intended. Media Viewer's overall feedback is broadly supportive and it's important to consider that when you can disable it on your own. Keegan (WMF) (talk) 21:10, 24 May 2014 (UTC)
 * "Personally, I'd like to make sure that the discussion is not based on "I don't like it and I don't think anyone else does either" but actually had solid numbers and facts on how communities feel about Media Viewer" Thats why I think a vote would be a good idea; anything else is just my opinion vs. their opinion vs. your opinion. So I am correct in my understanding that we both agree that there should be a vote? HMS Indeconstructable (talk) 22:16, 24 May 2014 (UTC)
 * I don't agree with you that there should be a vote. That's not saying that you can't. I think it would be wise to give it time and not launch a !vote based on what can be a natural response to change, that is, not liking it. You are free to do as you please, but I urge you to consider the much broader picture (so to speak) that !voting will not capture the voice of the casual consumer, for whom Media Viewer is primarily intended. You have the option to turn it off. Keegan (WMF) (talk) 04:07, 25 May 2014 (UTC)
 * To supplement, the surveys show that on average 70% of the 7,000+ participants find Media Viewer useful. That's pretty significant, and voting will not capture that. Keegan (WMF) (talk) 04:11, 25 May 2014 (UTC)
 * Who was surveyed? I can see the utility of Media viewer for users of Wikipedia (though even there, I expect you're misinterpreting results that just mean "I just want to see a picture" with how additional information about the picture should be conveyed; two things that are very much conflated in the current implementation); but can't see it being appropriate for Commons. Aldaron (talk) 01:14, 29 May 2014 (UTC)
 * Not taking people's votes into account is by design. The wiki concept, and Wikipedia in general, is not based on votes, but on consensus. It's not called a not-vote just to be cute. We don't vote on things. We decide based on the most convincing arguments, even if only one person makes it. The fact that 70% of viewers like it has no bearing on whether or not it should be implemented. The question is simply whether the benefits outweigh the drawbacks. The question is whether the feature, whether readers want it or not, is actually beneficial to the goal of creating a free encyclopedia. What people "want" or their "feelings" are irrelevant to a !vote, by design. If 10000000 people say they don't like it but don't give a reason, they don't count, any more than if the same number say they like it. Neither "I LIKE IT" nor "I DON'T LIKE IT" is not an accepted reason to do anything on Wikipedia.
 * It's this lack of faith in the community that we have built up that irritates me so much about the WMF lately. The same type of argument was made with the font change. And, predictably, a bunch of people were upset. Just like with this, the first they heard about it was when it was rolled out, and they were upset. They didn't have a chance to be convinced with arguments that it was a good idea. They didn't have a chance to make simple suggestions that would have largely stemmed the controversy.
 * If you think our ways of doing things are bad, then why aren't you trying to change them? Why do you insist on working outside of them in these conferences that most of us can't physically go to or these chats that severely limit the time available? And you don't even get those right, since you miss the freaking bureaucrat of one of your wikis! That shouldn't be possible!
 * I know I sound like a broken record, but I long for the day when the WMF can work as Jimbo originally envisioned, as just users with extra responsibilities. Not some elite group that has to protect us from ourselves. We can handle this sort of thing if we are given a chance. We already have the tools in place to deal with the problems you foresee, including resistance to change.
 * If you'll work from within instead of from without, I think you will be pleasantly surprised at how much better things go. I really get tired of having to see the WMF as the enemy we have to fight in order to preserve the project. Trlkly (talk) 04:05, 29 May 2014 (UTC)
 * Trlkly: I'm always at your disposal for thoughts, questions, comments and concerns about new products the WMF is developing, and I'd also be more than happy at any time to help you get engaged in the development discussions. You can email me, leave me a talk page message here, on meta, or en.wp. By all means, the door is wide open for participation :) Keegan (WMF) (talk) 04:54, 5 June 2014 (UTC)

I can't see a difference ;o)
I looked on sample pages, but I cannot see a difference! Does it require interpretation of javascript? If this is true, the audience must not be confused by statements, that only apply with javascript interpretation activated. Additionally I think, the project is not thought through, if it requires javascript interpretation for more than decorative issues. Better first to complete such a project before exporting such experiments in a confusing way to other wikis like wikibooks ... And especially for wiki types like wikibooks it is obviously more important, that for such a new feature the authors of the books have to explicitly activate such a feature for their book instead of beeing surprised by undesired changes. There could be an additional property to indicate, that such a 'media viewer' matters for the individual media. Additionally especially for SVGs it would be obviously even more relevant to indicate, that no preview raster images has to be presented, but directly the SVG (because the SVG preview generator typically has much more bugs and gaps than an up to date user-agent. If such a media viewer could be convinced to switch off the preview generator for the complete audience (not only for javascript fans), this could be a great benefit for such a tool. Doktorchen (talk) 10:54, 24 May 2014 (UTC)

"Uploaded by" credit
Can I suggest that the "Uploaded by" credit should principally indicate the original uploader of the image ?

At the moment it seems to be crediting the most recent uploader, but that may often be for only a small tweak -- eg rotation or cropping or a colour adjustment.

It seems odd to see "Uploaded by Cropbot" or "Uploaded by Rotatebot".

So where the original uploader is not the most recent uploader, can I suggest "Uploaded by OriginalUploader; most recent version by NewUploader" ? Jheald (talk) 11:04, 24 May 2014 (UTC)
 * That seems like a fairly major issue of attribution...Crisco 1492 (talk) 12:15, 24 May 2014 (UTC)
 * Good suggestion, Jheald :) I see where this gets tricky. Keegan (WMF) (talk) 21:11, 24 May 2014 (UTC)

Template
If a file is described with the template, the Media Viewer displays the field  , which is empty or contains accessory explanations (those, quite often, are redundant for the overwhelmed users ;-), but the most significant field,  , containing the name of an artwork, is not displayed.

As well, the Media Viewer does not display the field  containig the name of a painter, a sculptor... (Dmitry Ivanov (talk) 21:31, 24 May 2014 (UTC))

The template  has more than 550,000 transclusions, and, I think, it deserved some attention of MV’s developers.

Dmitry Ivanov (talk) 20:53, 24 May 2014 (UTC)
 * Yup, I agree. My feeling is that a good bit of problems with what fields are/are not being included in Media Viewer will be solved by the next iteration, provided development of structured metadata and integration with Wikidata makes the progress the two teams are working toward. Keegan (WMF) (talk) 22:25, 27 May 2014 (UTC)

Link to ZoomViewer is missing
For high resolution media like scanned maps it is absolutely essential to have a link to the ZoomViewer feature. But with Media Viewer this link is missing now. Without this function all the high resolution images on Commons suddenly got unusable! --Alexrk2 (talk) 11:05, 25 May 2014 (UTC)


 * PS and if one clicks the magnifying glass for are very large image, he will freez his browser. Thats why we have that "Large Image" warning stub for very high res images (in combination with the ZoomViewer link). Actually I would expect that the magnifying glass would start something like the ZoomViewer, where I can zoom in, zoom out, pan. --Alexrk2 (talk) 17:58, 25 May 2014 (UTC)

Media Viewer on Commons necessary?
I can understand the intention to have one common viewer for all different language versions of wikipedia, e.g. en, de, fr, etc. The idea to present the picture in the same way all the time without the switch to commons, OK so far. I am not really positiv about this as well, but OK. What I really DONT understand at all is, why do we need the media viewer in commons itself. When I click on a picture there, I want to see the whole content all information, everything, because I want to work with that picture. It is really time consuming and frustrating all the time to wait until the picture has been load and then to click once more to see the picture in the way as it was before.

Please make an option in the settings in commons if the media viewer shall be active and used or not! --Mogadir (talk) 13:32, 25 May 2014 (UTC)


 * Mogadir: "When I click on a picture there, I want to see the whole content all information, everything, because I want to work with that picture."


 * About 1/2 (or even 2/3) of the information about a file is lost with the current version of the Media Viewer. The developers of the gadget refer to the results of a survey and say that users do not want information. I think, the results of the survey are quite correct: the users really do not want that much information. No wonder, the people got accustomed to mosaic picture, to clip thinking: no penetrating reading, no reflections, no research... A picture – something is written – go father – a picture – two words – what next... Quickly, quickly, quickly, a spintop is whirling... Many love it, and the Media Viewer gives them what they want.


 * In reality the question of the Media Viewer is not a local, technical, problem of a certain gadget.


 * In reality it is a strategic question, the problem of Commons’ essence, the problem of Commons' mission.


 * What must the Commons be? Must it be under the thumb of mass consumer and see its destination in providing of comfortable surfing through pictures? Or, may be, it must demonstrate the high class of encyclopedic, scientific approach, must show a story behind a picture, must invite to research?..


 * Must the Commons go down to the desires of the customers or must the Commons lead the people to summits?..


 * Must the Commons be one of numerous projects modeled after moulds of the IT-industry or must it keep the spirit of the Enlightenment and encyclopaedic knowledge?..


 * That is the question...


 * Dmitry Ivanov (talk) 19:48, 25 May 2014 (UTC)


 * Dear Mogadir and Dmitry Ivanov: Thanks for pointing out the issues you're experiencing with Media Viewer on Commons. You make some good points, which we will discuss with our team and consider improvements that could be made to address them in coming weeks. Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)

Notification
I wonder if we could get email notifications before WMF breaks stuff so we could tell them not to? Rich Farmbrough 16:33, 25 May 2014 (UTC).


 * sure, just subscribe to wikitech-l. TheDJ (talk) 14:55, 26 May 2014 (UTC)
 * If you're all about making things modern, why are you using such ancient tech as a mailing list? This sort of thing should be on like a Twitter feed or other information ticker something. Actual discussion should be in some sort of forum--or, better yet, a Wikimedia talk page, showing dedication to your design.
 * Its silly to expect the average user to know how to use tech from 1995. Trlkly (talk) 05:49, 29 May 2014 (UTC)


 * Dear Rich: Thanks for bringing up the important issue of notifications for new products. We have announced this new feature extensively, as you can tell from all the links in this release plan. But we will continue to look for more ways, like email notifications, to inform our community about new features like this one. Regards as ever :) Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)
 * @Trlkly: subscribing or navigating the mailing list archives not hard at all. Twitter is more complicated. It is a commercial site running proprietary software which limits the number of characters in a message, probably not optimal for this kind of thing. If you wish to have technical news delivered to your talk page weekly, you can subscribe to Tech/News (there is also an RSS feed), however wikitech-l is more complete. πr2 (t • c) 23:20, 3 June 2014 (UTC)

Can a Media Viewer button be added to thumbnails?
Would it be possiblel for a Media Viewer button to appear in the upper right of a thumbnail, whenever the mouse hovers over the image? (Typically this kind of button has two small arrows pointing to opposite corners of the screen.) This would give users a clear-cut option: clicking that button would launch the Media Viewer, whereas clicking elsewhere would take them to the file description page. --Robert.Allen (talk) 15:23, 25 May 2014 (UTC)


 * Hi Robert.Allen: Thanks for this suggestion. We initially considered design ideas like the one you propose, but found them to be too complex for casual users, and not well-aligned with best practices on the web. Note that you already have the option to bypass Media Viewer, as described in this FAQ. Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)

Option to disable Media Viewer
Hi. Please provide a option in preferences to disable Media Viewer. I don't need at all Media Viewer. As a editor, in most of cases i need to view media's page not media itself. I need to verify licences, descriptions or sources of files. Also, when i am on other, non-native wikis i need to view directly some media's page to copy file license and description as inspiration for file i want to upload. So, please make Media Viewer optionally. Thank you. --XXN (talk) 10:14, 26 May 2014 (UTC)
 * See preferences para desactivar (disable). --MARC912374 (talk) 04:45, 27 May 2014 (UTC)

you are absolutely right. this gadget is useless. when i want to see the picture, i really know how to do it. 82.34.76.218 13:26, 26 May 2014 (UTC)


 * Hi MARC912374: You can disable Media Viewer by turning off this preference. Hope this helps. Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)
 * That does not help at all, why not allow unregistered users the option of disabling this ``feature" instead of forcing it on them

A wikisource need
From wikisource point of view, a Media Viewer should manage:
 * 1) djvu files, the hearth of proofreading procedure, with a viewer similar in performance to DjView
 * 2) if source is Internet Archive, original jp2/jpg files from which djvu has been generated (with a deep degree of image compression and details wasting). --Alex brollo (talk) 10:37, 26 May 2014 (UTC)
 * Alex brollo: Great, good have documented. I appreciate it. Keegan (WMF) (talk) 22:22, 27 May 2014 (UTC)

really hopeless windows8-like solution - how to switch it off?
how to switch this sh*t off? is wikipedia going to be another useless gadget? because it looks on my computer like anytime i try to find any information on my samsung smartphone. completely useless. only one move more to switch it off. but this time i can not see how to switch it off. 82.34.76.218 13:24, 26 May 2014 (UTC)


 * Hi 82.34.76.218: You can disable Media Viewer by turning off this preference. Hope this helps. Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)


 * No. It does not help. It's like: "Choose: useless annoying tool or create an account. Tertium non datur". --2.112.192.13 14:33, 4 June 2014 (UTC)

Bad, very bad
Este visor multimedia no sirve para nada, miro las photos desde Wikipedia y solamente da problemas, además de ser incómodo para ver las images in high resolution. Opino que deberían eliminarlo, y cuanto antes. La Fundación Wikimedia debería gastar el dinero en cosas de mayor utilidad para la Wikipedia. Saludos. --MARC912374 (talk) 00:24, 27 May 2014 (UTC)
 * Lo he desactivado en mis preferences, pero sigo opinando lo mismo. Es superfluo para Wikipedia y para Wikimedia Commons. Good bye. --MARC912374 (talk) 04:37, 27 May 2014 (UTC)
 * Gracias diciendo lo que piensas. Keegan (WMF) (talk) 03:01, 28 May 2014 (UTC)

I can't get it to turn off
I un-clicked the selection box for "Enable new media viewing experience" on my preferences page, logged out, and logged back in, and I still can't turn this off. Also, it's hellish trying to find out where to turn it off -- did I get the right setting? -- it would help if you actually used the phrase "Media Viewer" so people could at least search for it. HELLLLLP. Mary Mark Ockerbloom (talk) 14:24, 28 May 2014 (UTC)


 * I can't figure out how to turn it of either. Where did this thing come from? Aldaron (talk) 01:00, 29 May 2014 (UTC)


 * Hi Mary Mark Ockerbloom: You can disable Media Viewer by turning off this preference. Hope this helps. Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)

Why is this happening?
Why is this happening? It's important not only that we are able to disable it for ourselves, but also that we have a way of disabling it for the images we've upload, for all users. The fact that such a terrible "feature" made it so far is a clear demonstration that the process for approving such features is broken. Aldaron (talk) 01:00, 29 May 2014 (UTC)


 * Hi Aldaron: Thanks for your feedback about Media Viewer. We're sorry the tool is not useful to you. We have been testing it extensively as a Beta Feature since November 2013, with tens of thousands of beta testers worldwide -- and they have started many discussions in their home wikis, [|as outlined in our release plan]. We are also running user surveys in 8 different languages with over nine thousand users so far, and a majority of respondents are telling us they find the tool useful. What specific improvements would you recommend to this careful, methodical community engagement process? Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)

Alt text
I would like some way for Alt text for the visually impaired to be associated with images and displayed in the media viewer. Even better would be including an edit mode, so viewers can create and edit the Alt text. A small info icon could link to a page that tells how to create Alt text. While it is regarded as important for people who access Wikipedia via screen readers, there is hardly any Alt text available. Encouraging readers to add Alt text would be a valuable new service for the Media Viewer.--ArnoldReinhold (talk) 01:00, 29 May 2014 (UTC)


 * The problem with this is that the Alt information is part of the article rather than part of the image page. Putting it in the viewer would imply that it attached to the image, not the article. It's an interesting idea to provide some sort of default ALT tag that is used if one is not provided, but that would require more than just a change to the viewer. Trlkly (talk) 05:44, 29 May 2014 (UTC)


 * Hi ArnoldReinhold: Thanks for suggesting a solution to better support accessibility on the Media Viewer. We have been discussing different ways to address this concern and will take a closer look at your 'Alt text' proposal. Our front-end developer Mark is now adding tooltips to Media Viewer and we will discuss addressing  accessibility issues next.  Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)

My actual problem with the viewer: Fair Use
First off, I want to say that I don't think it's all that bad a beta piece of software. I object more to how it is being rolled out than to the software itself. But I do have a problem.

This software assumes that images can be enlarged. Yet my experience is that a large portion of images used in En.Wiki are fair use, and specifically made to be the same size as used in the article. Sometimes they can be a tiny bit larger, but they still have to be 0.1 megapixels by policy, which isn't going to fill up anyone's screen.

Furthermore, our legal usage of such images is based entirely on them being discussed in a scholarly manner. Yet no such discussion appears on the file pages. This is acceptable because they are really just administrative pages. They weren't designed to be a place where you'd view the image. But this new viewer is designed to show images, and gets its information from those same file pages. And with the "next image" option, the user doesn't even have to have seen any thing about the image.

It really seems to me that this viewer does not play well with fair use as we handle the term on Wikipedia. We are much more strict than Wikia where this idea came from. Wikipedia is not a fair use image gallery. Trlkly (talk) 05:33, 29 May 2014 (UTC)


 * Thanks, Trlkly: I appreciate your kind words about the software -- and your recommendations about fair use issues. What specific improvements could we make to Media Viewer to address them? Should we consider disabling Media Viewer for fair use images altogether? Or displaying a label to let users know when an image is fair use? Do you recommend a simple, machine-readable way to consistently tell when an image is fair use? Look forward to your practical suggestions to address this issue, keeping in mind that we have limited development resources. Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)

Now actual bugs
The above was my major problem, but I've noticed some little things that haven't been mentioned.


 * 1) The chevron is really light and hard to see. Plus clicking white space in the description should probably work, too.
 * 2) The smaller text on Commons also affects the viewer, even looking at the same image.
 * 3) The low res image while the image is being thumbnailed makes the viewer seem slow.
 * 4) The status bar link is the same whether the link goes to the file page or to the viewer.
 * 5) The Commons logo is really small, despite having a ton of space
 * 6) The buttons on the image itself do not have tooltips. Particularly, this makes the fullscreen button unclear in function, since that icon does not always mean fullscreen. (In Gmail, for example, it makes the Compose window float. On Facebook, it used to open a separate page for chat users.)
 * 7) The animation of the meta data is strange and jerky. It would make more sense to have it just start on the bottom.
 * 8) There is no obvious way to use the new viewer from its actual description page. Someone may want a full screen view rather than to download the entire image.
 * 9) The thumbnailing progress bar is inaccurate. If accurate information can't be found, another indicator would probably be better.

That's all I see right off, but I'm sure there are more. Again, this is clearly beta. Trlkly (talk) 06:24, 29 May 2014 (UTC)


 * Hi Trlkly: Thanks for your detailed and helpful comments on improvements you propose to Media Viewer. We are developing a range of solutions aimed to address the issues you brought up, such as: making the chevron easier to see, displaying a larger Commons logo, adding tooltips to Media Viewer, to name but a few. We have also significantly improved image load times, which are now faster than opening up the file page on Commons, as shown in this metrics dashboard -- and will keep looking for solutions to other concerns you told us about. Much appreciated. Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)

Additional button
Another suggestion is an additional button right below the enlargement arrows or the magnification glass in the right corner. That button should be called COMPARISON. By clicking there, all associated categories should open.

This idea picks up the remarks user Dmitry Ivanov made above: people nowadays scroll through pictures in random order with no reflections. Leading them into categories could be a way to make them familiar with comparison as a tool of analysis.

This idea differs from the current next file arrow because it should be very clear what the common ground between the next and the actual file is, and that is the category of the users intentional choice.--Jaybepo (talk) 06:59, 29 May 2014 (UTC)

Image description
I think the image description is very essential, so it should be readable next to the image without scrolling or extra-clicking (and in good readable letters). P.S. Look how it is done on flickr, at least you can see the image title in big white letters.--Sinuhe20 (talk) 19:26, 30 May 2014 (UTC)

Simple a bad template
Strong for this template. Unnecessary and useless, the template displays the images information incomplete. Why all this? --Alchemist-hp (talk) 15:03, 1 June 2014 (UTC)

Two major design flaws (image description not easy accessible / field names missing)
There are two major design flaws in MediaViewer:

First of all the *most* important part of an image - it's description - is only visible after clicking a light gray and nearly invisible small arrow-like symbol at the bottom of the page. That's a no-go (especially for inexperienced readers who are the target audience for MediaViewer)!

Secondly the MediaViewer totally omits field names as they are known from the image Information templates (like Description, Author, Source, Date, etc.). While the occasional reader might recognize a date, I'm almost sure he'll mix up author/source and description fields which are displayed side-by-side in MediaViewer without even an iconic hint on what information is displayed.

This should be fixed as fast as possible (I don't even understand how MediaViewer could be deployed on many Wikis already with this going unnoticed). --Patrick87 (talk) 21:26, 1 June 2014 (UTC)

Is it possible to control which images are galleried and which aren't?
To elaborate: why not have a tag like, say, gallery=bigpics so that the left and right arrows cycle through the only the images that have the 'bigpics' tag in common; gallery=off could suppress the viewer for that image.

The high-handed imposition of this feature is really sticking in my craw: until today I thought I was a citizen here; now I feel like a subject. I can see a certain amount of light at the end of the tunnel, but it seems essential to give article-editors control of the feature. Trust the compositor, please. Munrogue (talk) 20:52, 2 June 2014 (UTC)

A detailed and thorough response of the Media Viewers problems and why it isn't good for the site
I just got done attending the NYC Wikimedia WikiConference and have had the opportunity to talk with other members of the community and to Keegan about the Media Viewer. The discussions I've had brought me to give a more concise and expanded criticism of the Media Viewer, which made me want to address this forum again. I'll be doing it is a bullet point again, since it is easier to read.

- The Media Viewer has way too many negatives for its two meager positives - The Media Viewer gives you an enlarged image and lets you flip easily through images on a single page. That's basically it. The first issue is commonly solved by clicking through the image link to a larger image, which hardly seems difficult. If the original file is also too big, then they have the option of looking at different files below, giving you a greater flexibility for looking at file sizes. The problem that the Media Viewer has with larger images is that it stalls and takes time to load that splash image when you click on it, which is a pretty big negative considering the original method is much faster.

The second issue is one that has no real answer or solution outside of the media viewer. It is currently the only real "win" of the media viewer. Giving that, it seems borderline insane when you rack up those two positives against the list of negatives.

- The Media Viewer divorces content from photos - This is currently my biggest problem with the media viewer. The Media Viewer's purpose is to turn the Wikimedia Commons into a large slideshow, to reduce all images to a larger picture and a caption. It seems to be created from the viewpoint that the Commons is just a massive dump of photos and nothing more, so you would want to be able create a viewer that makes those pictures easier to look at. If you were designing the Media Viewer from this laughably simple and bad viewpoint, it does that, but it does it at the cost of everything else, and such an oversight of the design committee is extremely worrying.

- The Media Viewer is a wall few will ever get past - The Media Viewer is currently so unwieldy and difficult to understand that it brought me to my knees when I was trying to figure out how to get past it. For people who don't realize that there is information past it, or don't want to put the effort into getting past it, the Media Viewer will effectively be a wall few will get past. Casual users will not be clicking past it. Moderate users will see little reason to get past it. Only the hardcore will go past it to see the wealth of Metadata that it blocks from view.

'''- People have spent years making this metadata that few will now ever see. - ''' The Media Viewer sees Wikimedia content wants to simply reduce everything to a photo and a caption. Almost everything else is chopped out to accommodate this, including the years of work people have put into the Commons up to this point. To accommodate for an odd and closed system, people have found ways to work around and within the restrictions of Wikimedia infopages to create context and provide additional information, which are usually hosted in specials templates or designs that exist outside of the description field. For example, I host all of my work on Wikimedia and use my own userpage to create galleries that sorts and catalogs this information. The best way that I can let people know about this is through the image infopage, where I have a template for drawing attention to my userpages and these galleries.

- Templates are the only good way to show that the uploader has more content to offer -  User-specific templates are some of the most important templates, because it lets you know that there is more in a series from a specific person. It lets you know that that uploader has a presence on Wikimedia/Wikipedia larger than this single photo and opens you to more photos or galleries or similar images. Many Wikimedia Commons power users and uploaders have these authorship templates, which is what lead me to their pages in my early days on Wikimedia. When I see a photo taken by someone, I want to learn more about how they did it and why, because that inspires me to take photos. Without this, I might have not gotten into photo taking in the first place.

- The Media Viewer divorces the uploader/photographer from photos -  By reducing authorship to a text field, an uploader's importance is effectively divorced from the photo. Considering that it's already a losing battle for authorship when people take photos from Wikimedia and use them without accreditation, to have the role be so minimal on the actual page is so insulting it makes me want to walk away from Wikimedia entirely. There is now even less of a draw for people to upload quality content to Wikimedia. Given the state of Wikimedia's terrible ability to bring in good photographers, something that drastically reduces that is enough to rethink about the Media Viewer's implementation.

- The Media Viewer creates little incentive for people to upload dedicated content -  It's a tall order to devote your time to a project like Wikipedia/Wikimedia for free, but even more so for created content like photos. Photos are a different beast than article editing, because while text editing is community driven and very malleable, photos are extremely definite. Photos created and uploaded to Wikimedia are solely owned by the original photographer and have to be explicitly given away by that person. These photos can require a lot of resources and money to create, depending on the quality of photo produced. And while the resulting product can possibly have a commercial value beyond the site, it is still required to be given away for free forever by being put on Wikimedia.

Given that relationship, the least some people (like myself) would ask for is something on the infopage that shows authorship, like a user-created template. The Media Viewer and its desire to reduce authors to footnotes is like a kick in the teeth. Wikimedia is already very unfriendly to people producing quality photos, but this could easily be seen as the end of the line. If it not for the fact that I was already indebted to creating content because of my Kickstarter obligations, then I could easily see myself giving up producing content for Wikimedia based on these policies. It's a dangerous game to impose more restrictions when the site is already hurting enough for quality content, as is.

- The Media Viewer will damage relationships with GLAM institutions in the same way -  I have spoken to other WIkipedian's-in-Residence and people involved with the GLAM movement and the Media Viewer is a disaster for these people as well. Much like how the Media Viewer creates little incentive for photographers to upload their own work, Museums will also have less reason to do so given the Media Viewers gutting of information and metadata. Many museums have complex licences and rules for putting photos of their collections onto Wikimedia, and require special templates for such. It is already very hard to convince these institutions to bring their extremely important, high quality, educational work to Wikimedia for a number of reasons. When you approach a museum you have to sell them on the positives, like how people can see that the image belongs to a museum or a collection and use that to generate interest back to the museum. This has largely been done through templates and many of these templates exist already and are on pages right now. These will all be gone now with the media viewer. If someone from a museum wants to look at Wikimedia content to see if they want to bring their collection to the site, they'll see the media viewer and decide that it is not worth it for them.

- User and community templates are too important to lose - Again, for the reasons above, the templates that already exist and are currently on pages that are too numerous and important to be cut out. This drastically reduces the ability of Wikimedia as a platform and cripples the information on the site. Content will have to be designed around the Media Viewer and we all know that this won't happen. By solving a very minor problem the Media Viewer has now added to Wikimedia's already-massive problem: context.

- The number-one problem with Wikimedia is context - We have so much good material on Wikimedia that will sadly never be found or used. Why? Because it was massively dumped onto the site with little or no context. When someone takes a massive collection of photos from an institution and uploads them to Wikimedia, that creates an enormous backlog of work. We're still wading through massive collections of photos that have bare or useless descriptions, are not well categorized, are not placed in articles, or are separate from other photos that provide context for the photo in the first place. People who have spent valuable time working on this huge and relatively thankless task of doing this will often use templates for this, and all of that work is gone.

- The Media Viewer is not good for Wikimedia or the site - Given this big list of problems that the Media Viewer now creates for the honestly trivial good it does, the Media Viewer is not something that should be used on the site. It literally does so little at the cost of so much that I can't believe how tone-deaf its production must have been. Talking with people at Wikimedia, the implementation came as a surprise to them. It came as a surprise to me! The amount of people working in GLAM or working to create large amount of good content for Wikimedia is so small it's a wonder that none of them were apparently asked for input until the Media Viewer was rolled out. I think that the Media Viewer certainly shows this by its massive problems.

To end this, I think that the Media Viewer should not be used or should only be a tool enabled for spefically created galleries that will work with its shortcomings. My recommendation is for tools that work on the presentation of data at the category level, or make it easier to create galleries. We need to work on creating context and relationships between pictures, to make them easier to find in searches, to make adding this data to photos easier. The last thing we need is something that removes it. --- Evan-Amos (talk) 17:46, 2 June 2014 (UTC)

Account-Holders Only Need Apply
I am curious how you reached consensus to require an account to disable this feature, instead of requiring an account to add it to the user experience. Is it possible that the method you used for feedback was flawed? Your project page cites a survey with 1727 responses prior to roll-out. Is it possible that your response-base might have been heavily (or entirely) weighted toward project participants along with their friends and family, a group with an emotional investment in the tool? In contrast, the post-production feedback shown on this page seems overwhelmingly negative.

I use Commons frequently and do not use an account because it's a hassle; cookies and site data are constantly purged from my heavily-locked corporate system. Did participants in the survey have accounts? I'm guessing that they did, implicitly excluding the very majority on whom this is imposed by fiat. I am most interested in the response from Keegan to MMO: "Media Viewer is primarily going to be a tool for non-editors..." It is a delightfully-phrased self-fulfilling prophesy: Those without accounts are not editors (by definition) and only account-holders can turn it off (by design).

One last note: "Many users do not notice right away that they can click on the 'X' button or press 'escape' to close the Media Viewer," a quote from the survey page, is a maddening and ludicrous statement. All that button does is take you back to the page from whence you came, not close this intrusive and difficult tool and take you to the image page. In fact, without an account, I am unable to find ANY WAY AT ALL to get to the image page itself! All roads lead through this well-meaning tool. 159.53.110.143 18:36, 2 June 2014 (UTC)


 * I totally agree with you. And I would like to add that the guys at the WMF look like they give it for granted that all the people who don't like the Media Viewer it's just because they are too conservative. --2.112.192.13 14:42, 4 June 2014 (UTC)


 * This can be disabled? HOW????? I believe the page you want is hidden on the right immediately beneath the black field containing the image - tehre's a tiny Commons symbol there that leads to Commons (took me 2 visits to find it). Yngvadottir (talk) 21:36, 3 June 2014 (UTC)
 * To disable it, go to Special:Preferences at each wiki, and unmark the checkbox in the "Files" section that says "Enable Media Viewer" or "Enable new media viewing experience" or similar (depending on the wiki/language). Quiddity (WMF) (talk) 21:49, 3 June 2014 (UTC)

Blurry image
The Media Viewer looks quite nice. There's, however, a thing that bothers me: When an image is loaded, it's first displayed as a scaled-up, extremely blurry thumbnail. Then, after a few seconds, it's loaded in acceptable quality. Users often aren't very patient - I think it's quite possible that some will have clicked the image away, thinking "horrible quality!" before it's fully loaded. And who wants to see such an image mush, anyway? What's the advantage? It seems to me that it would be preferrable to either just have to wait the few seconds for the image to appear (without the blurry "fullsize preview"), or have the image load the traditional way, filling the screen from the top as it loads. Gestumblindi (talk) 20:20, 2 June 2014 (UTC)


 * Showing some "preview" makes the image loading feel faster. Browsers display a part of the image for the same reason (actually they do display the whole image immediately in a smaller resolution if they can - that's called progressive rendering, but needs specially prepared images); that would not work well here, because MediaWiki might need to do some extra stuff before it can start sending the image, so you would stare at an empty screen for a while. We show a very prominent progress bar to make it clear that the image is still loading. --Tgr (WMF) (talk) 23:45, 3 June 2014 (UTC)

Beautiful
Wow! Nice job. This makes up for the visual editing thing before. It works so well on the iPad. Can't wait to test it on iOS 8 when it finishes installing!
 * Keegan (WMF) (talk) 21:51, 3 June 2014 (UTC)
 * well it looks pretty horrible on everything else, take you stupid apple shit and shove it where the sun don't shine, but before that get rid of this steaming pile of shit! Ed Poor

Seriously less good
As someone else says above, this takes ages to load, which suggests it may not work at all on a slow connection or when my computer is otherwise busy. Meanwhile, it gives me eyestrain. The information I generally click on an image to see - the Commons information - is hidden away in tiny print and the first time I was confronted with this format, I failed to find the icon at all. Most recently I just clicked on an image to see whether it was protected and am still none the wiser; it's included in that category, but is it actually protected?? Where's the history, so I can check? For that matter, how would I protect it if I needed to? Please, please, please stop changing the interface from something functional to something spiffy that requires a brand-new computer and hides everything away. And don't tell me 6-point type is editor-friendly either. Yngvadottir (talk) 21:33, 3 June 2014 (UTC)
 * Yngvadottir: thanks for the honest critical feedback. There is more work to do to make Media Viewer more editor friendly, up to and including better category support, and these improvements will show up in the next version of Media Viewer. I wish you found it more useful as it is now, but hopefully we can make it more friendly for you in the future. As for the load time, there's a funny thing there: Media Viewer actually usually loads faster than a File page, but it seems slower because a little trick about the File page: it only loads when the page is complete. Consequently when you look at a white screen for a second before the File page loads, it seems to be loading faster than Media Viewer, since Media Viewer instantly shows up while the image loads. You can see the metrics comparing Media Viewer and the File page here. Great care was taken to make sure that Media Viewer would not harm or hinder slow connections or limited system resources. Again, I hope you find it useful in the future. Keegan (WMF) (talk) 21:50, 3 June 2014 (UTC)
 * As someone has since said below, it resembles interface changes on Flickr that have been unpopular. I fail to see the advantage of the change. Also looking elsewhere, I've found out why I was unable to see whether the image was protected: MediaViewer will not show me the page for the image on en.wikipedia. That's a nasty disadvantage - luckily at the Village Pump I was told how to disable it in my preferences (I should have looked there, but after the Visual Ed experience I'd stopped looking there), and was able to see that I didn't need to protect the image. As to load time, it may seem petty of me, but I don't like loading methods that hurt my eyes! Please reconsider making these changes. What on earth are the benefits? Yngvadottir (talk) 22:16, 3 June 2014 (UTC)
 * From the page that this is the talk page for:
 * The purpose of this tool is to:
 * Provide a richer multimedia experience, to match user expectations
 * Display images in larger size, on the same page as the thumbnail you click on
 * Reduce confusion when users click on thumbnails (bypass duplicate file info page on Wikipedias)
 * Again, it's unfortunate that you do not find it useful. I hope that changes in the future. Keegan (WMF) (talk) 22:28, 3 June 2014 (UTC)

Media Viewer sucks
Media Viewer sucks. They should get rid of it. Put your signature below here of you agree. --109.77.179.224 21:41, 3 June 2014 (UTC) LOL. But seriously, it's a big mistake that's got to go and go fast. can you do a favor and remove it? Millions will thank you. --109.77.184.196 16:52, 4 June 2014 (UTC)
 * Strong I helped write the thing, I know how terrible it really is. Did you know the government implanted tracking devices inside of the black backdrop to log your movements? ;) --MarkTraceur (talk) 23:03, 3 June 2014 (UTC)
 * My response was an attempt to teach you that simply asserting an opinion and asking for democratic support won't get you anywhere around these communities - if you have issues with the tool, you should articulate them and then propose solutions. "Remove the tool" doesn't help fix the tool ;) --MarkTraceur (talk) 17:23, 4 June 2014 (UTC)

Media Viewer is broken no matter what you do with it. I do not want it fixed, I want it removed and removed now. It seems that everyone with a brain hates it and wants it removed. Jimbo would hate to see what you're doing. I realize you spent a lot of time working on this but it seems that you didn't even bother to test it. If you keep putting things like this, people will start hating you and sending out death threats (not me though, I'm not that type of person). Again, I strongly urge you and your fellow programmers to remove this feature for the sake of the internet. --109.77.184.196 18:20, 4 June 2014 (UTC)
 * So uh, what are the issues you're having? Legoktm (talk) 07:47, 5 June 2014 (UTC)

Can't stand the Media Viewer
Personally, I cannot stand the Media Viewer

First, it appears to add nothing to my experience. It provides me with the same information the old image page display did — but lacks the ability to edit the summary, author, source, and date. It forces me to click an obscure, tiny icon on the middle-lower-right (one hardly identifed) in order to access metadata, file useage, file history, or to see which categories the image is in.

Second, it duplicates the file title twice.

Third, the font size in the summary section is so large that I now must scroll about the page to see any summary longer than 675 characters.

Fourth, much of the information about the image is concealed, if the image is a large one. This means I must scroll yet again to see the summary, uploader information, author, source, and date.

Fifth, it's too easy to click on the "image right"/"image left" arrows that pop up... especially since they are right next to the scroll bar uselessly inserted into the image. So now if I'm just a little sloppy moving my cursor about, I suddenly am taken to another image (hardly a user-friendly option). X-ing out of the image takes me back to the Category page — not to the image page, which is where I want to go.

Sixth, the "Use This File" button defaults to the most useless feature ("Download this File"), when most users want to embed the file in a Wiki article.

Seventh, it's not clear to me why the "Share" option exists. Users in the old image page could simply have copied the URL in their location bar in their browser. That information is now obscurbed by excess URL information in the Media Viewer. So no wonder a "Share" tab had to be added! But what "Share" gives the user is nothing more than a bare URL link. Some users want that. But to get actual HMTL or Embed code, the user has to avoid "Share" (which is counter-intuitive) and go to "Embed" — even though "Embed" has a very, very, very different meaning from "HTML Code" and "share as a link". Eighth, the "Embed" code is not really embedding, it's Wiki-encoded.

Ninth, the "Embed" code forces the user to delete a fairly useless caption. The "suggested" caption creates a file name that merely repeating the file's file name, as well as includes file size information (useless, again!).

Tenth, the HTML "Embed" code is the clunkiest, most user-UNFRIENDLY code I've seen since the early 1990s. Yes, it preserves WikiCommons' licensing and source data. No, no one is going to use that. They're going to strip out all that code. And WikiCommons succeeds....how?

The upshot is: Am I using this feature? Answer: No. I desperately seek to get past it so that I can use the features on the old image display page. As a user who uploads a lot of images from free sites (Library of Congress in the U.S., or Flickr), I find that my most common need after uploading an image is correcting copyright license (to narrow it or correct it) and editing the summary description (to eliminate typos). I can do neither in Media Viewer. My second-most common need is to create a derivative file from an existing one. I cannot do this in Media Viewer. I have to use the original image display page.

Media Viewer seems designed to accommodate users who know next to nothing about Wiki. It seems designed to obscure "frightening" or "scary" amounts of information that might discourage a new user from using the image, and it seems designed to automate useage in such a way as to encourage new users to utilize images more. Frankly, it sacrifices useability in favor of catering to the needs of newbies. It's a swift kick in the head to everyone who actually uploads and uses images. (It seems, amazingly, just like the changes Flickr made to their site in 2013-2014. And those have gone over like a lead balloon, too...) - 68.55.245.12 21:53, 3 June 2014 (UTC)
 * I see you are calling many things "useless." What could you suggest to make things "useful" and be a bit more proactive with your feedback for the future development of Media Viewer? Keegan (WMF) (talk) 22:03, 3 June 2014 (UTC)


 * Well you could look at getty images to see how they do it (basically move the information with place below the image to the side of the image). The problem you have is that for most commons work the information comes first and the image is pretty secondary. Sure mediaviewer can and will be turned off but that creates friction with new uses where experienced used aren't familiar with what new users are seeing.Geni (talk) 01:48, 4 June 2014 (UTC)
 * Yup, sure, Geni, you make a fair point about information first and image second is often the case for Commons work. The challenge is finding the balance between work on Commons and how Commons is being used in general. The click-through stats on pulling up the fold in Media Viewer to see metadata on Commons is only something like 1:300. I'll have to dig to find this metric, if someone else beats me to it, great! I think with the data Media Viewer's use is providing and upcoming work on structured metadata for Commons will help us bridge the gap between the Repository nature of Commons as well as its extensive galleries in categories. As for the friction that can grow in communities when some choose not to adopt new features, that's an entirely different animal :) Keegan (WMF) (talk) 04:01, 4 June 2014 (UTC)
 * If we would have a Flickr/Getty style description panel in an image view, we could give it state and remember locally if a users wants that panel visible by default or not. Seems like a good idea for a next generation. TheDJ (talk) 12:39, 4 June 2014 (UTC)

Lack of attribution is ridiculous
I've just spotted the Media Viewer on English Wikipedia. Photographers already bemoan the fact that Wikipedia does not attribute their work on the article page, and must instead click through to the File page. And now attribution is not even shown on the Media Viewer page.

I appreciate what the Media Viewer aims to do, but how can you roll out this feature without getting the basics right? Users can download and share the image without ever knowing how it must be attributed. This is ridiculous. - Hahnchen (talk) 22:37, 3 June 2014 (UTC)
 * Taking a look further, the cause of this omission is because the licensing template is not inside the information template. There are lots of files where the licensing template is not inside the information template. - Hahnchen (talk) 22:47, 3 June 2014 (UTC)


 * This is relatively easy to fix. If you look at the file description, you could change the author and source to be more useful for this purpose.
 * However, a valid point is that there's a licensetpl_attr machine-readable thing that we don't handle currently. Adding support for that, and dropping it in place of the author/source combination, may be our answer here.
 * I have opened a ticket in our Mingle system that will track this user story. I think we'll be able to take it on sometime this month.
 * Thanks for the pointer, we love new edge cases that we can help support :) --MarkTraceur (talk) 22:52, 3 June 2014 (UTC)
 * If there is an attribution line specified, it should be shown in place of the source and author. The source and author fields are correct.  Viewers should be able to see the mandated attribution line without having to look below the fold. - Hahnchen (talk) 15:45, 4 June 2014 (UTC)
 * What file description? Media Viewer turns finding that into a game of "guess where to click" (which incidentally is why its unusable on commons).Geni (talk) 01:04, 4 June 2014 (UTC)
 * Is the problem that you have not yet learned where to click (first square bottom right that when hovered says "More details on "Wikimedia Commons") or is there something else that is obstructing you in this regard ? Also remember that you can open the link in a new tab or window, by using your browser/operating system defaults (often middle click or command, shift or ctrl -click), which automatically bypasses the Multimedia viewer. TheDJ (talk) 12:35, 4 June 2014 (UTC)
 * Clicking a project's logo takes you that project's main page. That the expected behavior. I know how to avoid activating the mediaviewer its just that it is less effort to switch it off entirely.Geni (talk) 16:12, 4 June 2014 (UTC)
 * This was 57460 which has just been fixed (cc MarkTraceur). Jean-Fred (talk) 20:02, 5 June 2014 (UTC)
 * Actually that was only the backend part - Media Viewer still won't use that information until we add another few bits of code. --MarkTraceur (talk) 20:08, 5 June 2014 (UTC)

Well-made feature
Well, for some native inhabitants of Wikipedia-City this may look new and unfamiliar - and in fact it is new. As far as I'm concerned, this feature presents the images in an up-to-date manner, without much of that wiki-meta overhead. A Fresh & modern design, though progressive download could be a little bit faster. --Hedonil (talk) 01:43, 4 June 2014 (UTC)
 * Glad you like it, and thanks for a pointer where it could be improved. Images will load faster and faster as they are cached for reuse as well. The more likely an image has been viewed and cached, the more likely you are to get a faster load. Thanks again. Keegan (WMF) (talk) 03:40, 4 June 2014 (UTC)

Another 'improvement'??
Can we please make this feature an OPTION on English Wikipedia?? I do a lot of editing and correcting in the file summaries for given images by clicking on 'description', which takes took me directly to commons. That option is gone and now we have to take the long way around the block to get to commons file summaries. ALSO -- some images require a second click to see the largest view available, which came in handy for viewing maps and other images with detail that is not otherwise discernible. That feature is now gone. Last, often times there is other information about the file/subject in the description field, along with 'other versions' which 'were' readily viewable. Poof! That feature also is now gone to English Wikipedia viewers. This is an 'improvement'?? We don't need a slide show feature every time we click on one image. Please make this 'new feature' an option, not an only choice, when we click on an image. -- Gwillhickers
 * You can turn off Media Viewer on the English Wikipedia in your Preferences, untick the box that says "Enable Media Viewer" underneath the "Files" section. I hope that helps you to keep up with your work. Keegan (WMF) (talk) 03:28, 4 June 2014 (UTC)
 * Hmm, session data fail. I had more there in response that didn't make it.
 * Re: full/high resolution - see this section above, particularly the "Update" section from Fabrice. Access to full/high resolution and a zoom feature are not as easy integration as they seem, and they will be approached again in the next cycle of Media Viewer development.
 * There is still work to do and it will be done, I look forward to incorporating your feedback into v.03. Keegan (WMF) (talk) 03:37, 4 June 2014 (UTC)
 * -- For some reason the preferences you linked to were different than mine on English Wikipedia, as I did not have this option under Appearances on English Wikipedia. In any case, I un-ticked the Media viewer via the link you provided and it solved 'my' problem, only. Question: Do we really 'need' this feature? Was there some sort of demand or problem that prompted its arrival? This has caused nothing but problems and uncertainty for many editors. -- Gwillhickers (talk) 04:05, 4 June 2014 (UTC)
 * Thanks, I disabled it because I don't like it. That said, I don't like it because I care about Commons' categories, and I want to be able to go there in one click to check them out. For most people, including most newbies, the Viewer with it's sleek design may be better, and so I am actually weakly supporting it being a default option. Wikipedia interface needs to be "sexier" to attract "new kids", IMHO. --Piotrus (talk) 08:54, 4 June 2014 (UTC)
 * thanks, but how to disable needs broadcast, Media View needs to be described at preferences. The link provided here is the only way to restore the Wikimedia Commons feature, which acts as footnote information to confirm proper sourcing in an article. Thanks for the link here, for me, and thanks to Gwhillickers for cluing me into the fix found only here in this string. Who knew there was something called a "Media Viewer"? At a minimum the innovation should be broadcast in a banner on all editor pages. I have tried twice to 'opt in' using cut and paste to ensure I missed nothing, and failed to open a User page here; the process is another of my disappointments at how things work from the wrong side of the digital divide. "Sexier for new kids" without proper introduction just seems like capricious wild west jerk around.
 * For this new innovation, it is not intuitive how to get past the blowup enlargement. How did you achieve that? At the minimum there should be a box to click labeled "Wikimedia Commons" somewhere on each image at the English Wikipedia to reach the source data comparable to a footnote, Wikipedia is to be a sourced online encyclopedia, open to everyone. -- see "How do I turn this off?" section below for a confirmation of the problem. TheVirginiaHistorian (talk) 09:17, 4 June 2014 (UTC)
 * please note that in no way, shape, or form is the Multimedia team saying that Media Viewer is supposed to be "sexier for new kids" or any language like that. Media Viewer has a utilitarian function, its purpose is not supposed to be trendy :) Now, as for broadcasting how to disable Media Viewer, sure, there could be better ways that we need to develop without discouraging use, or worse is that people may turn it off without ever really giving it a chance. I've been using it on my volunteer account for nearly six months and now it's weird to me when Media Viewer does not open. I think future developments about notifying users about Beta Features, updates and streamlining communications in general will help with this. If you have thoughts on this process you can always email me or leave me a message on my talk page. Keegan (WMF) (talk) 21:13, 4 June 2014 (UTC)

Media Viewer functions as a discreet page making navigation awkward
First, I'll be blunt: I don't care for this new media viewer and I don't see what purpose it serves on an encyclopedia. I use Wikipedia for a fair amount of image research for personal projects, as it's a great way to find things in the commons. As such I often click on images, read their description pages, and figure out if I can use them or not before continuing my research. Not only is the information that was readily available just last week now buried in the fine print, but the "application" apparently functions as a separate page, even though it in no means looks like one. If you close the "application", as you would visually similar applications on popular social and photo-sharing websites, and later hit the back button the navigate to your original search, you find that it takes you to the media viewer. If you've viewed and closed multiple images on a page this can lead to an unnecessarily large amount of clicking to navigate back to a page you thought was immediately previous to the one present.
 * I agree with you that this is not what a user would be expecting. I have filed a bug report about it. TheDJ (talk) 12:21, 4 June 2014 (UTC)

Great work; please keep it opt-out-able
I think it looks good. The target is pretty clearly the readers as opposed to editors, which is great (they are, of course, why we are here). Since 90% of the time if I click on an image I am doing so to check copyright status, etc, I quickly disabled the viewer as it adds clicks. Please be sure to keep the opt-out option for those of us who are more on the curation than the multimedia/user side of things. Thank you! VQuakr (talk) 07:40, 4 June 2014 (UTC)
 * It shall remain opt-out :) Keegan (WMF) (talk) 20:48, 4 June 2014 (UTC)

How do I turn this off?
I don't like it. How do I turn it off? I don't have an account on Wikipedia so I can't do that whole going into Preferences thing. (And I don't intend to get one just for this.) — Preceding unsigned comment added by 68.116.85.62 (talk) 08:37, 4 June 2014‎

Requested wording change
Please could you change "Learn more on Vikipedia Commons" to "Learn more on Wikimedia Commons" in the roll up info bar at the bottom of the page. Many thanks. Philg88 (talk) 08:41, 4 June 2014 (UTC)
 * , where did you see this exactly, because for me it is currently saying "Learn more on Wikimedia Commons". TheDJ (talk) 12:04, 4 June 2014 (UTC)
 * Sorry, I forget now - I see a lot of pics/maps every day. If I come across it again I will let you know. Philg88 (talk) 14:24, 5 June 2014 (UTC)

Argh!
Wanted to view an svg file in my browser so I can zoom into it. Now I only get to that stupid viewer and it's really hard to get to the original svg file. It's not a feature, it's a bug. Please fix it asap! — Preceding unsigned comment added by 2a02:2028:1f1:a231:818b:2e2c:aa5:8d4c (talk) 08:58, 4 June 2014
 * There is an outstanding bug report for this and some related discussion a bit higher up on the page. TheDJ (talk) 12:09, 4 June 2014 (UTC)

How the media view put a donation of 100,000 high quality educational images at risk
During a meeting last week with the Digital Images Library at the Wellcome Trust, the largest and most powerful charity in the UK, we put up a draft project page and some test images as they were currently viewable on Commons (not using my account, nor my machine, but one supplied in the meeting room). The poorly rendered image in the media viewing pane (which automatically showed rather than the image page after someone clicked on a test image on the project page) caused the Head of the department to say "yuck", and as there seems to be a bug when using Windows Internet Explorer, there was no obvious link to take us to the image page as the icon that appears to the bottom right of the image pane in Firefox was not displayed on IE. We were unable to examine the image page template being used, or properly discuss the metadata we would need for the 100,000 images due to be uploaded.

At that point, I gave up on the demonstration and we talked in general terms, without referring to what could actually be seen on Wikimedia Commons.

Unimpressive. --Fæ (talk) 10:27, 4 June 2014 (UTC)
 * TheDJ (talk) 11:55, 4 June 2014 (UTC)
 * did you happen to make note of the OS version and IE version that was being used ? TheDJ (talk) 11:58, 4 June 2014 (UTC)
 * Sorry, no. It looked like a bog standard implementation of IE, very vanilla. My brief look gave me the impression that the layout was the same as it looks in Firefox, just the icon/link taking you back to the image page has vanished. --Fæ (talk) 16:45, 4 June 2014 (UTC)


 * I have had some problems with Media Viewer because I have difficulty accessing metadata which I need. I do not know how to articulate my personal problems, but I can say that I have been depending on progress in this Wellcome Trust media donation as they had a lot of content of interest to multiple WikiProjects. I would like for Fae's concerns to be addressed as I and others have already invested a lot in our relationship with this organization, and sudden changes to infrastructure increase the risk that a media donation which could be valued in tens of thousands of dollars could be lost.
 * If anything less than tens of thousands of dollars is being put into user experience on this project then the problems are are not worth the trouble at this time. Please stay in good communication with the Wikipedia community. Could I have someone who is paid staff working on this Media Viewer project state acknowledgement that they have received a complaint that the Media Viewer Project has potential to cause great financial losses to communities, and to please confirm that their supervisors have a system for calculating the financial impact of harms when rolling out new projects? Thank you.  Blue Rasberry    (talk)   14:13, 4 June 2014 (UTC)


 * Dear Fæ: I am sorry to hear that you experienced issues with Media Viewer during your demonstration at the Wellcome Trust. Do you remember if you were logged in on that machine? Currently, the Commons icon linking to the file description page only appears if you are logged in; to address this issue, we now plan to make it available to logged out users as well ticket #429, and aim to release that fix next week.
 * In the meantime, note that there are two other ways to access the file description page, besides the icon described above:
 * 1) Shift-click or cntrl-click on any thumbnail to bypass Media Viewer and go straight to the file page (see FAQ); or
 * 2) open the meta panel in Media Viewer, scroll down and click on 'Learn more' with Wikimedia Commons icon on the right column (see FAQ).
 * So my hope is that one of the three solutions above will help avoid these issues in the future, as our users become more familiar with Media Viewer. If there are other issues related to IE, it would be great to get the specific browser version, so we can troubleshoot if needed, as TheDJ kindly points out above.
 * Thanks for responding here so promptly. The browser was being driven by someone else, it is unlikely to have been logged in, and I tend to avoid logging in on machines I do not control. I find it unintuitive that a basic display tool where most users will be readers rather than editors would behave differently when not logged in, and demonstrations at workshops would often run without being logged in, so a bug like this would tend to hit where it hurts with regard to public visibility (please assume this will be the case for many presentations at Wikimania). I am glad this is being fixed, though I think you should consider this a requirement for testing in advance of release to production, rather than afterwards. --Fæ (talk) 10:29, 5 June 2014 (UTC)


 * Dear Blue Rasberry: Thanks for your thoughtful comment about this unfortunate incident, which we regret as much as you do. We appreciate your concerns about the possible impact of technology updates on image donations; in all of our projects, we aim to minimize any adverse effects caused by new software deployments -- and try to respond quickly to requests for improvement. As product manager for the multimedia team, I can acknowledge receipt of your complaint and confirm that we are taking steps to prevent these issues, as described above. We will also pass on to our supervisors your request that the foundation calculate the financial impact of technology changes we make; my personal view on this point is that it may not be practical to implement, due to the high frequency of such changes and the speculative nature of such estimates. But I can assure you that we take issues like these very seriously, and that we will continue to exert our best efforts to reduce their impact on our communities, as we keep upgrading our aging infrastructure. My hope is that the Wellcome Trust will accept our apologies for any inconvenience this software update may have caused, and that they will reconsider your proposal; please remind them that Wikipedia is a work in progress and that issues like these are not uncommon on the Internet, but that we all work together in good faith to address them as quickly as possible. Thanks for your patience and understanding. Fabrice Florin (WMF) (talk)

Far from happy with the change- we need non.svg files eg png jpg gif, captions for the pictures and choice of sizes to download
new design would be ok if the non svg files were available to download with the same choices of size and with picture captions
 * could you please try to describe your problem a bit more thoroughly ? I'm not quite sure if I fully understood what your concern was. TheDJ (talk) 12:23, 4 June 2014 (UTC)
 * the captions are still there i see them now. but before today, I was able to view or download any SVG picture file in, usually, png or maybe jpg or gif, and to choose different sizes of the pictures. this is vital to me and maybe others.
 * click the "use this file"-button then pick the "Download" section and select what kind of download you would prefer. TheDJ (talk) 12:49, 4 June 2014 (UTC)
 * problem solved, thank you. also, learning how to use this message forum wasn't easy. is there an easy way i'm missing how to do it? had to guess to click on edit contrib and to copy the replyto, i'm only a basic wikipedia user, not a coder
 * unfortunately not yet. There is a different feature under development called Flow that is working on this, but it is a long term project. TheDJ (talk) 13:16, 4 June 2014 (UTC)
 * hi, i have just noticed that when i scroll left and right and back and forth between several pictures on one article alot it eats up my browser back pages... ie if i right click my back page button in my browser there are lots and lots of the same wikipedia article page.. which is a pain, making it harder to navigate forwards and backwards through tab history

Can't zoom in on large files with hi resolution
People who come to Wikipedia just for info, often times from just clicking on search results, are now unable to view some images in their full capacity. Take for example an image of a galaxy with a resolution of 15,852 × 12,392 pixels. It has to be clicked on a second time to see the image in its full resolution, but the average viewer with no account, (and the registered editors who have to come here to set their preferences) can't see it in its full resolution. Instead they get the dumbed down media viewer version. Again, was there some sort of demand or problem that made this media viewer an only choice for most viewers?? PLEASE MAKE THE MEDIA VIEWER AN OPTION FOR ALL VIEWERS WHEN THEY CLICK ON AN IMAGE -- NOT AN ONLY CHOICE. Gwillhickers (talk) 14:38, 4 June 2014 (UTC) Gwillhickers.

Can't control with keyboard, too slow, impedes browsing, unintuitive

 * The keyboard cannot be used to browse. The description of an image is primary content which is confined to an internal frame that must be scrolled with the mouse and can't be scrolled with universal scrolling controls. The need to do this cannot be detected without using the mouse if the text does not happen to suggest it's been cut off, and even still one must think to hover over the block of text rather than simply scrolling as universally defined as a window-level interface/control.
 * So, the page up and down keys will work as usual. The arrow keys are backwards because of the chevron icon. I have hated this change since we made it, but the product and design teams seem convinced that it's the Right Way To Go. I'll take another whack at convincing them otherwise. --MarkTraceur (talk) 18:11, 5 June 2014 (UTC)
 * The keyboard controls are unpredictable choices - the part hidden is what would be "below-the-fold" content one could scroll down to see. Content with an unpredictable means of access is content effectively missing. See.
 * The choices of keyboard controls made forbid one from using normal navigation to see below-the-fold content besides at an arbitrary fixed size. If that were implemented it would have revealed to the designer that the controls are reversed to actual browsing direction. Dynamic content is not toggleable, because it's not an optional augmentation of website functionality.
 * Loading at moderate size instead of dynamically rescaling means one can reliably load images at a reasonable size for when fast page loads are needed, including when one doesn't want to look at the image so much as read the description or download the image at largest size. Javascript unnecessarily hinders this common browsing task.
 * The information is organized into meaningless divisions. These divisions impose a limitation of growth for all content types placed in a subordinate area - tags and categories are in fact a primary form of navigation for those who use them, and they are regularly used on Wikipedia if nowhere else. In a subordinate position they are difficult to access, and in a non-extreme position they can't be accessed per muscular impulse.
 * Not easy to identify significance of the divisions by eye and thus know which segments of page will contain information relevant to the reader. Those identifications are most easily done by being able to identify the separation of information types by eye (license sections had graphically identifying segmentation before) and then scan for text headings against one's browsing interests. Eye tracking research shows an F pattern is the placement in which users will try to find these scannable content identifiers and for the content it identified before having to stop browsing and think/recall what they were on that page in order to do. LokiClock (talk) 14:40, 4 June 2014 (UTC)
 * LokiClock, thank you for taking time to give details, constructive criticism and feedback. Opportunities with categories, displaying various image sizes, and general navigation will be addressed in the next iteration of Media Viewer. It sounds like you might be interested in following the metrics dashboard to see how some of the issues you highlight are showing up. Again, I appreciate your time, and we'll see how your issues can be addressed in the future :) Keegan (WMF) (talk) 04:46, 5 June 2014 (UTC)
 * Hi LokiClock, thanks for your helpful feedback. At MarkTraceur's recommendation, we have filed this ticket #697 to support scrolling down to access metadata in Media Viewer. This issue has been brought up a number of times before, and it seems worth reconsidering, if we can find a practical solution that could be implemented quickly. To that end, we have encouraged our designer Pau to consider a practical alternative that could enable users to use a keyboard down arrow or other scrolling method to find information with a method they are familiar with. This may require revisiting the current ‘metadata panel’ metaphor and thinking more of a ‘page section’ concept instead. The site Medium.com offers some nice design examples of that could be done: a page can show a fullscreen photo in its top section, and contain more information below that image. We will also review your other suggestions below, but the first one seems to match what we have heard from other users, so we are likely to give it higher priority. Thanks again for your comments. Fabrice Florin (WMF) (talk) 21:28, 5 June 2014 (UTC)

Shift-Click
I definitely like the shift-click option to skip the Viewer. Unfortunately it opens the image in another explorer window. Could it be in the same window instead? --2.112.192.13 14:56, 4 June 2014 (UTC)
 * That's a native browser behaviour, so while we feasibly *could* modify it, I'm squeamish about the idea.
 * You could also control-click on the thumbnail to open it in a new tab in most modern browsers, or right-click on the image and choose "copy link location" to put the URL wherever you'd like.
 * Any further modifications to click behaviour would need to be on a client basis...you could probably pull this off with a gadget, e.g., though "officially" we don't have any real framework for addons and modifications :) --MarkTraceur (talk) 16:13, 4 June 2014 (UTC)

Also middle-button-click opens in a new tab in most modern browsers. --Tgr (WMF) (talk) 21:11, 4 June 2014 (UTC)

Use Opera. Right-click->Open means "open in this window, regardless of what the website wants to do". It's such a handy feature, I'm amazed no other browser has copied it. --Carnildo (talk) 00:33, 5 June 2014 (UTC)

I hate it, it gets in the way of what I'm actually trying to do
Like so many others above, I hate it. It conceals the actual name of the file, which is usually what I'm after, and I have to ferret around for it. :-( Bishonen (talk) 15:13, 4 June 2014 (UTC).
 * Thanks for giving it a shot, Bish, and letting us know what didn't work for you. Media Viewer will continue development in another cycle and we'll revisit things like this. I trust you managed to turn it off? Keegan (WMF) (talk) 21:22, 4 June 2014 (UTC)

A usability disaster
Whoever came up with this abomination has no idea what they are doing.

Images with white or transparent background look horrible in this. I did not even realize that those were categories below the upload date. What is it with the useless bumping, fading and sliding in of white boxes with giant fonts? And why does the "Learn more" link look like it is in a search box?

I have seen countless improvements on the web over the last 17 years (especially on Wikipedia), and this is definitely not one of them. Wikipedia is not a slideshow.

-- 79.253.58.136 16:23, 4 June 2014 (UTC)

PS: The fact that the spreadsheet of the survey is hosted on Google Docs, the survey itself on Surveymonkey and the feature list on Thoughtworks speaks volumes. There is even a "Share on Twitter" feature in the foundation's Multimedia Vision 2016. Seriously, if that is your vision of where Wikipedia should be heading, then you guys are f'ing this up, and you need to stop.

PPS: Off to writing a browser extension that disables Media Viewer by default.

Terrible for teachers
Hello. I can appreciate innovation and trying new things, but only if you know when to kill it. It has actually been a topic of discussion in my school district, and the general consensus is that it takes way more time and effort to find information, and that it just doesn't add any value whatsoever. It seems like a decent option for tablets or specifically for children, but overall this feels like innovation for the sake of innovation. Very sad to see wikipedia following that trend. I hope it gets killed soon.
 * What information were you trying to find ? Perhaps we can make it easier to find. TheDJ (talk) 08:53, 6 June 2014 (UTC)

Don't like it
It takes too long to load, lacks important information, and I often get Error messages. It may be better eye candy on some systems, but it definitely should not be on by default. Chris Fynn (talk) 17:08, 4 June 2014 (UTC)
 * Hey Chris Fynn, could you let us know what browser/operating system you are using that might cause these error messages? Keegan (WMF) (talk) 17:32, 4 June 2014 (UTC)

Hate it
I can't get to the page I really want to view. Please revert ASAP! --66.41.154.0 21:01, 4 June 2014 (UTC)
 * Access to the File page if you do not have an account or are not logged in will be much more accessible in short order. Keegan (WMF) (talk) 21:15, 4 June 2014 (UTC)

Awful
You finally convinced me to log back into my wiki account just so I could disable this awful change. Just like the search bar change of a few years ago, Wiki is going the route of Firefox, from a UX perspective. Saddening. Riffraffselbow (talk) 23:58, 4 June 2014 (UTC)

I haven't logged in in years and I would like to second this. There was absolutely nothing wrong with the way that it was set up previously. Teak the Kiwi (talk) 08:25, 6 June 2014 (UTC)

Unanswered questions

 * This will be the third time I am asking this question: -- Was there some sort of demand for this viewer, or was there some sort of wide spread "problem" that needed to be 'solved' that brought about this viewer?     i.e.Why was this viewer forced on everyone?


 * Most importantly, is this viewer going to remain the default viewer much longer?

-- Gwillhickers (talk) 00:45, 5 June 2014 (UTC)
 * Hey Gwillhickers, I've asked Fabrice to give you a proper response. He is the product manager for the Multimedia team, and the best to address your questions. Keegan (WMF) (talk) 04:31, 5 June 2014 (UTC)


 * Hello Gwillhickers: thanks for your candid questions about the rationale for the Media Viewer and long term goals for this tool. I will respond to these questions one at a time.


 * This new tool was developed to support these goals:
 * Provide a richer multimedia experience, to match user expectations
 * Display images in larger size, on the same page where you click
 * Reduce confusion when users click on thumbnails


 * Up until now, viewing images on Wikimedia sites was a frustrating experience for casual users: when they clicked on a thumbnail in an article, they were taken to a separate page where the image was shown in medium size and surrounded with a lot of text information that was confusing to readers. That page was a duplicate of the file description page on Wikimedia Commons and couldn't be edited: you had to click one more time to go edit file information on Commons. When users landed on Commons, they had no idea where they were or how they got there (see diagram to the right). To be frank, it was a pretty bad user experience, by modern design standards.


 * To address these issues, Media Viewer now displays images in larger size when you click on their thumbnails, as an overlay on the current page. To reduce visual clutter, all information is shown below the image, and can be expanded at a click of a button, with prominent links to other details. Usability studies suggest that Media Viewer provides a more immersive multimedia experience, right where people expect it. They tell us they can see the images more clearly, without having to jump to separate pages -- and that the interface is more intuitive, offering easy access to images and key data.


 * To answer your second question, we plan to keep Media Viewer enabled as the default viewer going forward, based on overwhelming user response. It has been tested extensively around the world, and the feedback collected from over ten thousand users suggests that this tool is useful to 70% of them, as outlined in these survey results. Moreover, the rate of favorable feedback keeps increasing across all languages over time. In the past six months, tens of thousands of beta users tested the tool extensively since it was introduced as a beta feature in November 2013 -- and their feedback was used regularly to improve the tool. Based on these findings, Media Viewer is now being enabled on all wikis, as described in this release plan.


 * Last but not least, Media Viewer is strategically important for implementing the three-year multimedia vision that guides our work. Besides improving the viewing experience, this tool will needed to provide a range of other contribution, curation and editing features over time (such as the 'thanks' tool shown in the thumbnail to the right). I hope this answers your questions. Thanks again for contacting us about this project. Fabrice Florin (WMF) (talk) 07:47, 5 June 2014 (UTC)


 * Is there any evidence that supports the thus-far unsubstantiated assertion that the conventional image metadata page was indeed "a frustrating experience for casual users" or that readers often regard encountering "a lot of text information" to be a "confusing" experience? After all, the entire purpose of a wiki - and especially Wikipedia - is to convey complex information in an organized and comprehensive way, and to do that primarily via the medium of text. It'd be fairly astonishing to me to discover that people who visit Wikipedia to use it for its explicitly intended purpose would somehow be bewildered by exposure to comprehensive text-based information.


 * Images are typically embedded into Wikipedia articles to exemplify the information being discussed in the text, and are generally uploaded to the Commons precisely in order to be used as article content. Why, then, is this new media viewer apparently designed under the assumption that images embedded in Wikipedia articles are standalone content intended to be viewed for their own sake?  This interface might be appropriate for a site like Flickr, where images are indeed standalone content, and are organized into galleries that users browse in sequence, but that clearly isn't the use case of images in this context.


 * When I click on a image in a Wikipedia article, I'm generally after more detailed information about the image, or seeking to re-use the image elsewhere, or looking for other related metadata. I'm certainly not interested in merely looking at the image in a more "immersive" way - whatever that means.  Having to take extra steps to bypass this unnecessary UI cruft just to use the wiki for its fundamental purpose - accessing information - is the real "frustrating experience" here. (And, note, I'm a "casual" enough user that I don't even have an account - but I was annoyed enough by this usability regression to come post here.)


 * BTW, this is the first I've heard of the "multimedia vision" you're alluding to, but I find the existence of such a thing very concerning. There's a noticeable trend of leaders of open-source/open-content projects attempting to behave in an increasingly cathedral-like manner, and it seems to be especially prominent in projects that have large, formal institutions behind them, e.g. the Wikimedia Foundation.  I hope that users will regard the attempt to shoehorn open-content, community-driven projects like Wikipedia into grand, top-down visions to be a product of organizational pathos, and aggressively prod developers to focus on work for which there's manifest bottom-up demand, rather than stand by as they yield to intra-organizational groupthink. 108.132.212.98 18:19, 5 June 2014 (UTC)

No sir, I don't like it.
Like many others, I find this change to be awkward in terms of usability, not to mention that it's ultimately unnecessary. I disabled this new feature immediately. The way it was before — going straight to the image page, which contained all the necessary info as well as various options on file size and type (when available) — has worked perfectly fine in the nearly ten years I've been coming to this website. If it's not broke, don't fix it. JGoodman (talk) 02:54, 5 June 2014 (UTC)

This is So Bad!
You can't zoom in on pictures any more. It's just useless eye candy, costing resources while delivering nothing useful. And it's impossible for people who aren't editors to avoid using this thing.

And, by the way, which idiot was reponsible for letting a private company run the survey? I might trust Wikipedia to leave a cookie or run a script on my machine, but only someone who is remarkably ill-informed would trust Survey Monkey. Are you deliberately following in Google's footsteps?

Anyway, unless someone signs up as an editor, they can't get rid of this tiresome "improvement". Please go back to how things were, as quickly as possible.

Thankyou.
 * The zoom feature as well as view in other sizes, including full resolution, will be an integral part of the next cycle of Media Viewer development. There were attempts to implement these features in this version, but we did not feel that they were of the quality that is deserved. Media Viewer will continue development in coming cycles and we will work to address this. As for Survey Monkey, that's not something that I can address effectively; it was also mentioned in a section above. ?Keegan (WMF) (talk) 04:40, 5 June 2014 (UTC)

This thing is awful
They say the Devil finds work for idle hands. I can only assume that your programmers have not had any real problems to work on. — Preceding unsigned comment added by 76.102.36.28 (talk) 04:34, 5 June 2014‎

It looks like tablets are to blame...
Originally, what really bugged me about the new Media Viewer was the fact that I had been stripped of the ability to view an image in it's entirety. This new tool would no longer allow you to view high resolution images. Arguably the main reason why a user would choose to click on an image is not to view the metadata behind it, but to view a larger version of it, allowing him to pick out more detail that would have otherwise gone unnoticed. Although this did rub me the wrong way, I did later learn that I could opt-out of it entirely (of course, I had to be logged in first). All's well that ends well, right? Well, no. There was still something else that bothered me about it, but I couldn't place my finger on what. Then it hit me: It's now apparent that even Wikipedia is not immune to optimization for tablet computing.

Although this tool would be great for a tablet, as pointless as they are, it leaves PC users to suffer. Unfortunately for most organizations that opt to reorganize their websites around this emerging market that may possibly (and hopefully) have no future, most people don't have a tablet computer. Be that as it may, these organizations are so optimistic about tablets that they're simply not willing to respond to consumer outcry that their favourite websites are becoming clunky, Metro-style disasters. I hope that those in charge of the Wikimedia Foundation will remember this simple, but elegant, truth regarding consumers: If they don't like it, they'll take their business elsewhere. Now, seeing as I don't have to use this new feature (again, I have to be logged in first), I'm not suggesting that this new Media Viewer tool will stop me from using Wikipedia entirely, but it does signal that more changes are sure to follow. The more you add such sudden changes to a site, the less people will use it. After all, does anybody really visit Myspace anymore? They were but one of many sites that chose to focus on form at the expense of function. However, in almost every other discipline on the planet, function trumps form every time. Form can be a major impediment to function. It can make something difficult or annoying to use, increase the likelihood of bugs or glitches, or this relentless pursuit of form could simply cause the developer to overlook function entirely. Yes, the old way of doing things wasn't pretty, sleek or "sexy", but it worked. If people insist that you make your website tablet-friendly, there is always the option of creating an app that is purpose built for tablets. Facebook chose to do this, and avoided the problems of having to radically change their website entirely. As more websites strive for beauty at the expense of efficiency, I would urge the Wikimedia Foundation to keep it's websites ugly, bland, and, most importantly, functional. --EbolaRocks08 (talk) 05:11, 5 June 2014 (UTC)
 * EbolaRocks08: There is not a lot for me to say other than thank you for taking the time to write out critical, constructive feedback. Media Viewer will continue to be developed, and it is feedback like yours that will help us in the next go-around. Being able to zoom in on and image as well as viewing the file in full resolution or different sizes is a high priority for the next release. I do know that Media Viewer is not about tablets or mobile viewing. While by far the most rapidly growing platform, mobile still only makes up for about 25% of Wikipedia traffic. Desktop/laptop viewing is just as important as mobile. Do let me know of any other ways you think Media Viewer can be improved to make it a more effective and educational tool for viewing files. Keegan (WMF) (talk) 06:09, 5 June 2014 (UTC)

This new media viewer reminds me of Flickr... and that's not a compliment!
I visited Wikipedia today to seek out a photo I could legally reuse and was greeted by this new "Media Viewer" interface when I click on a photo. I strongly dislike it. It took me considerable time to find where I could download the original size photo. It is not easy to access. Since Wikipedia is based on creative commons and public domain material, it should be extremely easy for people to find where they can download materials. Furthermore, the overall interface reminds me of Flickr's recent redesign which is also horrible. Less content, overly large interface graphics, lack of actual information presented to the user, and difficult to navigate. It is overly simple and appears designed for phone users. A lot of us still use old fashioned Laptop computers, and even a few of us might even use *gasp* a "Desktop Computer" and it is frustrating to see the needs of such users dismissed.
 * Please see my comment just above this section. Thank you for taking your time to let us know what you think. Keegan (WMF) (talk) 06:10, 5 June 2014 (UTC)

STOP IT
Slow rendition, surprisingly troublesome pop-up effect, confusing and unimportant infos all around. Give it up, folks, give it up. --130.34.157.13 06:27, 5 June 2014 (UTC)

Some issues
So I go.

It lists the file name minus the ".jpg" and then under that it says "Unknown." Unknown what? On the it describes the "Author" as "Unknown". That's clear enough, but the mediaviewer page is not telling me what this "Unknown" is supposed to describe. It continues onto "Immediate source" but cuts this off with an ellipsis. Further down it says "License details / See below." But there doesn't appear to be anywhere below where these license details occur. Firefox 29.0.1 Windows 7 64-bit SP1. --Atethnekos (talk) 09:08, 5 June 2014 (UTC)
 * This is a bit of a problem yes, we should find a way to make this a bit clearer in cases like this. TheDJ (talk) 08:50, 6 June 2014 (UTC)

Meh, Was This Really Necessary?
I understand that you guys are trying to make a more streamlined and cleaner appearance with a better user interface to make the experience easier for users like me. However, I myself had absolutely NO problem with the old interface and actually saw no reason for it to change in the first place. It was simple, understandable, and gave readers all the information they needed on the file. I'm not against change in anyway but if there is so much uproar and negative feedback on this, I would give everyone an option to still use the older interface with the media viewer being just an option. I would recommend this to please people like us and avoid comments like these. I am hoping that my suggestion it taken with serious thought. Ventura19 (talk • contributions) 7:00, 5 June 2014 (UTC)
 * Ventura19: all suggestions, comments, concerns, criticisms, you suck, you're awesome, etc. are actually read by me, a real person, and taken into fair consideration. Thank you for sharing your feedback. Keegan (WMF) (talk) 21:35, 5 June 2014 (UTC)

No usefull way to see large panoramas
Very cumbersome or even impossible to look at large panoramas in full size. Most normal users will not be able to see them properly. It would be better to enlarge it by clicking on it. Improve this viewer or delete it. --Milseburg (talk) 12:01, 5 June 2014 (UTC)

Petition to revert to the original format
Sign your name here if you want to revert to the way it was before media viewer. Don't forget to add as much as possible.


 * 1) Random wiki user. --109.77.184.196 12:12, 5 June 2014 (UTC)
 * Just a note. There's nothing to stop random (IP) users from voting more than once. For this petition to have any credibility only registered editors who have been active for at least 30 days should weigh in, which it seems they already have. Appreciate the effort though. -- Gwillhickers (talk) 16:44, 5 June 2014 (UTC)

Don't worry, I won't sign it more than once but I still encourage a lot of signatures. --109.77.184.196 16:59, 5 June 2014 (UTC)
 * Don't worry, this IP wasn't clever enough to get a new address since their last petition attempt, so I doubt it will be an issue here. :) --MarkTraceur (talk) 18:22, 5 June 2014 (UTC)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)