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

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)

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)

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)

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)

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

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)

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!
 * 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.


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

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

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.

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)

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)

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.