WT:Media Viewer

Welcome to the Media Viewer discussion on English Wikipedia!

Media Viewer is a new tool that aims to improve the multimedia viewing experience on Wikipedia and its sister sites. This multimedia browser displays images in larger size and with less clutter, providing a more immersive user experience, as described here. It was developed in collaboration with many community members around the world -- including over 15,000 beta users here on English Wikipedia, who tested it from November 2013 to June 2014.

Can you share your feedback about this tool? You can now click on any thumbnail image on this site to see it in larger size in the Media Viewer. For more info, check out these testing tips or this Help page.

Once you've tried the tool, please share your feedback here, to help improve this feature. You're also welcome to take this quick survey Archived 2014-07-14 at the Wayback Machine -- or join this wider discussion on MediaWiki.org, if you prefer. Thanks for sharing your insights!

Here are some sample images for you to test Media Viewer with. To use this tool, check out these testing tips. Fabrice Florin (WMF) (talk) 01:28, 25 April 2014 (UTC) Tɛmplet:Collapsetop

Note that it takes about two weeks for new improvements to be deployed on English Wikipedia. To test the latest features, you can also use this test page on MediaWiki.org -- or if you are feeling adventurous, try this beta site, which is the most current, but slower and less stable. Tɛmplet:Collapsebottom

There is no way to zoom in. This is a major, huge problem, which makes the Media Viewer less useful than simply using the article page the image is transcluded onto.

Using the image in a different website is also much, much harder than before.

Old workflow:

1. Click on image (move to image's page on en.wiki)
2. Click on image (move to upload.wikimedia.org's page)
3. Copy URL
4. Paste into other usage

New workflow:

1. Click on image (open's MediaViewer)
2. Find the "use this file" icon, hidden in the corner
3. Click on it
4. Click "Embed"
5. Click "HTML"
6. Copy the highlighted text (no way to copy only part of it)
7. Paste into other usage
8. Remove most of the copied text, which includes way more info than needed for copyright reasons.

Aside from these two major issues, and that there's no way to go the file page on en.wiki (the page that used to be reached by click on an image), it's very nice (although I'm still not sure what the point of it is). -- Ypnypn (talk) 02:30, 2 May 2014 (UTC)

Dear Ypnypn, thanks so much for your clear and detailed feedback, which is very helpful to us.

You make a very good point about the need to zoom in: we're now working on a basic zoom feature^{[permanent dead link]} to address this request in coming weeks.

Your workflow analysis for 'Use this file' is also very useful. We are considering adding a direct file link in the Share panel, which would reduce the number of steps required to match the old workflow. We could also remove an extra step in the Embed workflow (e.g. select HTML by default), to save time. However, the HTML links were carefully discussed with our legal team, as well as other community members, who made a strong case for the need to provide credits and HTML links for the file page, author, license and file repository , to comply with the terms of Creative Commons and other licenses. In the past, people have very lax about giving proper credits and required links, which this HTML code addresses effectively.

In consultation with other community members, we chose to link directly to the file page on Commons or the actual file repository where people need to go to make file edits (instead of the duplicate enwiki page which cannot be edited anyway). The local file page on enwiki remains accessible, but it is not clear to us what purpose it serves at this time.

Thanks again for your good insights, and we look forward to improving this product based on your feedback. :) Fabrice Florin (WMF) (talk) 19:12, 2 May 2014 (UTC)

We measured the time it takes to load a file description page, and it takes over 3 seconds on average. The image itself might take a while to load, either. So while the old workflow might have less clicks, that does not make it faster, as it involves waiting for the browser to load.

You can get a direct URL to the file in the Share this file/Download menu, via the preview link (admittedly this is hard to find).

Also worth noting that using the code from the Share panel will protect you from mistakes such as using a raw SVG file (which might work in your browser but fail completely for your visitors).

Fabrice: the HTML option is selected by default if you are not logged in. --Tgr (WMF) (talk) 23:41, 2 May 2014 (UTC)

TheDJ suggested we try media viewer.

• Knowing little about it,

1. used beta >
2. pref >
3. went to an article, e.g. Inferior temporal gyrus >
4. clicked [image size widget] under a thumbnail in that article >
5. entered image viewer >
6. clicked the viewer's [> widget] to successively browse the images of that article.
7. my navigation keys, (the < and > keys) work like the widgets. nice.

• I immediately missed being able to read the text of the article while browsing. It's a whole new way to step thru the article. Is there a way to see the captions, at least?

1. my up / down navigation keys open/close up the provenance for the image.
2. is there a way to read the captions of my article this way?

• Figured out a way

1. open up a 2nd browser
2. size them so that they can both fit side by side on the screen
3. article on the left, viewer on the right, use the navigation keys to step thru the images, as I read the article
4. when I use the expand widget on a small image, full screen takes over, instead of expanding to the size of the viewer's browser (not my full screen) and I have to rebuild the setup I described above.

Thank you for your work so far. --Ancheta Wis   (talk | contribs) 13:01, 13 May 2014 (UTC)

Dear Ancheta Wis, thanks so much for your helpful feedback :). To respond to some points you raised, we have a few tickets under consideration in our development pipeline, which I think could address a few of your issues:

• #589: Show caption above the fold in Media Viewer^{[permanent dead link]} - What do you think of this proposal? (note this is a pretty major change)
• #501: Don't move the metadata panel when going next/prev if it is not needed^{[permanent dead link]} - What do you think of this proposal? (note this pretty easy to implement)

Which of these two solutions do you prefer? Either of these proposed changes could take a few weeks to develop and release on English Wikipedia, if they are selected. In the meantime, I am glad that you found a creative solution to address your immediate needs :). Thanks again for your good insights! Fabrice Florin (WMF) (talk) 19:24, 14 May 2014 (UTC)

Fabrice, I am replying about #589, as it looked the most promising for my problem. I am trying to follow content which I know about from my reading. But I have a problem: when I read Insular cortex using the method described above, I follow File:Human_brain_frontal_(coronal)_section_description_2.JPG ‎which has a nice description page from Wikimedia Commons: with numbered items 1. Medulla spinalis 2. Decussatio pyramidum etc. These are not part of the caption on the Media viewer as I try to read Insular cortex. Currently I disable Media viewer on the text browser, so that I can read the Commons description page on File:Human_brain_frontal_(coronal)_section_description_2.JPG . Then I can re-enable it after reading the article.

#501 does not help my problem. Regards, --Ancheta Wis   (talk | contribs) 19:02, 20 May 2014 (UTC)

Looks like we should make sanitizing the description more permissive. --Tgr (WMF) (talk) 21:45, 20 May 2014 (UTC)

Tɛmplet:Od 12:38, 13 June 2014 (UTC) I saw Fabrice Florin (WMF)'s note that changes were being put in place last night on enwiki so I:

1. re-enabled media viewer (note: I use Navigation Popups by default)
2. it appears to me that View different image sizes (#664) Add tooltips to Media Viewer (#546) Make it easier to find image information (#706) Disable MediaViewer for certain images (#511) are the items of interest for me
3. Operculum (brain) was my most recent file of interest (had to page back to find one with images)
4. clicked on first image to start the slideshow
5. my keyboard has arrow keys [>] [<] [^] [v] which I use to navigate in the viewer.
6. used my [>] key until I got to Operculum_(brain)#mediaviewer/File:Human_temporal_lobe_areas.png
7. used my [^] and [v] (up and down) keys to view caption, and then return to image
8. observed that the caption included both the article's thumb text and the common's description text. Good job on #706.
9. I am unable to verify that the magnification function is working. Operculum_(brain)#mediaviewer/File:Gray731.png did not magnify, for example
10. navpop is working in the article, but not in media viewer (I'm not worried because I still have access to navpop after exiting the media viewer).
11. tooltips just work, they play nicely with navpop
12. I found a test case for #664: Marginal_sulcus#mediaviewer/File:Gray727_marginal_sulcus.svg displays counter-intuitive behavior when I use the [ctrl][-] to minify the image. Sometimes this key combination magnifies the image, instead. It seems to take multiple presses of [ctrl][-] to wake up the image resizer. Also, [ctrl][+] appears not to work for multiple presses; perhaps there is an offset problem into the array of multiple image sizes?
13. If I restart with Marginal_sulcus#mediaviewer/File:Gray727_marginal_sulcus.svg I get a base sized image to display the counter-intuitive behavior: [ctrl][-] says "zoom 67%", repeat [ctrl][-] gives "zoom 50%" but the image got bigger. repeat [ctrl][-] gives "zoom 33%" and image got smaller.
14. text still predominates for me. It took me effort just to come up with an example with pertinent text coordinated with images for your feedback. Doubtless that as you do more engineering, images will be more fluent. That should introduce the wikipedia editions to additional people.

--Ancheta Wis   (talk | contribs) 12:38, 13 June 2014 (UTC)

Thank you for this new feature! I was wondering if the background color could be white instead of black, it currently looks very similar to the newly designed Flickr pages and I found it very confusing. I think the white would be easier to tell I am using a different program but also a more tasteful design. Jooojay (talk) 06:30, 6 June 2014 (UTC)

There seems to be a range of options on what would be best (white, black, transparent, semitransparent...), there is no way to make everyone happy. You can change it for yourself by setting

.mw-mmv-overlay { background-color: white; }

in your user CSS if you want. --Tgr (WMF) (talk) 19:39, 6 June 2014 (UTC)

In full-screen mode, Firefox advises me to use Esc to get back to non-fullscreen (windowed). However, after a stutter, this also causes the media viewer itself. Thus effectively you jump back two "levels" in one go (page->media viewer->fullscreen---->page), which took me by surprise. - Jarry1250 ^{[Vacation needed]} 22:14, 14 May 2014 (UTC)

This is T64578. --Tgr (WMF) (talk) 22:23, 14 May 2014 (UTC)

Considering the present ability to choose resolution on the image page, including native resolution, image zoom in/out and the full-screen function in most browsers. 76.113.29.108 (talk) 14:01, 27 May 2014 (UTC)

Minor nuisance. Almost always my aim is to see the metadata. Captions, geocoords, etc. So, it needs an extra click. Probably the majority of readers, not editors, will differ. Jim.henderson (talk) 23:23, 3 June 2014 (UTC)

<nod> Thanks, Jim.henderson. Keegan (WMF) (talk) 23:43, 3 June 2014 (UTC)

How is this not a big deal if the loading time of this "Media Viewer" is horribly long and the file page link is not obvious? 192.12.184.7 (talk) 05:18, 4 June 2014 (UTC)

The loading time of the Media Viewer is actually substantially shorter than loading a File page. Here's the data Archived 2015-09-24 at the Wayback Machine. There is a perception difference because the File page remains a blank, white space while the entire page loads, whilst Media Viewer loads immediately and calls for the image. The more images are viewed, the more are cached, and even faster it gets. There will be tweaks to make links more prominent/accessible as we get feedback like yours. I appreciate it! Keegan (WMF) (talk) 06:07, 4 June 2014 (UTC)

Not true in my case. The File page displays almost immediately, while the image loads, so useful metadata and much of the higher resolution image is able to be seen well before the Media Viewer would have loaded its high resolution image. Having just clicked on the low resolution image in an article, I already know what it generally looks like, so upscaling that and keeping it there to delay display of the higher resolution version until it has completed loading, is actually counterproductive. "The data" you link to is a measure of the domready event, which may even have no noticeable (visible) effect at the time it fires, so I'd argue is not really a user-relevant metric without further information. In any case I don't see "substantially shorter", if I'm reading it right they are pretty close to identical for the 90th percentile results, as would be expected from roughly the same payload. Objectivity seems to be a moving target these days, apologies for being snarky but in general I don't appreciate being told my perception is flawed because evangelical convictions of some development team have caused possibly invalid stats to be misrepresented as observations of scientific fact (when it's patently wrong to any competent observer). Not singling you out, it's just the way it is these days - broken. 222.152.213.11 (talk) 00:22, 28 November 2014 (UTC) Sorry, didn't mean to post anonymously, I thought I was logged in. I won't now because it'd make my IP address public. I'm not the person who you replied to above. 222.152.213.11 (talk) 00:26, 28 November 2014 (UTC)

We have switched a while ago from domready to the ResourceTiming API, which should be a fairly accurate measurement of when the image becomes fully visible. The graph already shows that, but we forgot to update the graph description; I'll fix that. --Tgr (WMF) (talk) 08:00, 1 December 2014 (UTC)

The Media Viewer is utterly needless and makes a mess of big images containing lots of detail. It makes all the detail small and hard to discern. There was absolutely nothing wrong with the way things worked before. Abandon this project as a waste of time, an annoyance and anything but an improvement. Kelisi (talk) 04:16, 4 June 2014 (UTC)

Agreed. I know the need for Wikipedia to evolve, but why mess with a fundamental feature that worked perfectly beforehand? Peter Greenwell (talk) 05:11, 4 June 2014 (UTC)

But in the articles, media viewer activates only on a click. As I understand it, you can still read articles in the way we have been used to. I was coming to this talk page to provide feedback, to state that https://en.wikipedia.org/wiki/Marginal_sulcus#mediaviewer/File:Cingulate_sulcus_of_Vervet_Monkey.png has a very nice caption, as distinguished from some other images. For me, what the editor of this image set up was helpful to my search (I was searching for 'ascending ramus'). To the media viewer team, this might serve as a guide to use the media viewer. --Ancheta Wis   (talk | contribs) 19:58, 4 June 2014 (UTC)

I believe it displays whatever description is on the description page at Commons. WhatamIdoing (talk) 17:30, 5 June 2014 (UTC)

Based on Tgr(WMF)'s response, there is a layer of filtering between the Commons description page and the Media Viewer description page. --Ancheta Wis   (talk | contribs) 18:34, 5 June 2014 (UTC)

Yes, we remove all formatting except links. --Tgr (WMF) (talk) 20:08, 5 June 2014 (UTC)

+1 Agree, get rid of this please. If you want to make this the default for mobile platforms perhaps that's something worth investigating, but for the desktop please get rid of it. Let's make this a petition (or if there already is one, please link to it). Crazycasta (talk) 19:02, 5 June 2014 (UTC)

You can get rid of it for yourself. Untick the box that says "Enable Media Viewer." Petitions are not generally helpful on the English Wikipedia, since it is driven by consensus and not vote. If you have useful, fruitful comments and criticisms for Media Viewer other than that you do not like it, those would be great to hear so we can make a better product for you to use and enjoy as well. Keegan (WMF) (talk) 23:27, 5 June 2014 (UTC)

To disable it do (At the top, right side of your screen|Preferences|Appearance|Files|Uncheck Media Viewer|Scrolldown|Save, wait for "Your preferences have been saved" in green)

In the viewer, at the top right, there are little arrows to expand or contract the image.

Keegan, I followed the sequence and discovered that old UI cursor changes shape when hovering. The cursor has the little magnifying glass with (+) or (-) to expand or contract thumbnail images. How about using this in media viewer as additional functionality for thumbnail images ?

In media viewer, for [1] at the lower right corner, there are three widgets. Click on the middle one | preview in browser | cursor now displays the little magnifying glass with (+) or (-) to expand or contract fullscreen image.

--Ancheta Wis   (talk | contribs) 12:00, 6 June 2014 (UTC)

I am only seeing two widgets, but whatever. That is completely unintuitive and seems to be unnecessary extra clicking. Why can't zooming be done right from where you are? SpinningSpark 13:17, 6 June 2014 (UTC)

Spinningspark, just based on my experience with one high magnification file it appears that the little magnifying glass with (+) or (-) needs to have an array of sizes of image to display. So MediaWiki will have to pre-generate the array of differently sized images before the zoom feature can respond quickly enough. Otherwise, special grahics hardware might be required? Also, MediaWiki will have to decide on the array of sizes to be displayed, so that they can use standard processing.

The arrow cursor morphs into a magnifying glass when it hovers over the image. But in Media Viewer, the arrow cursor appears to be insensitive to its location, whether it is hovering over image or just the black background.

I see that the image display software from Google search appears to be using a similar software base with the same inability to zoom that Media Viewer suffers. The image sizes appear to be hard-coded from the image sources there. The Google images are not uniformly sized, either. Just like MWF. --Ancheta Wis   (talk | contribs) 18:51, 6 June 2014 (UTC)

Okay, fine, let me be more clear. There is absolutely nothing that I find acceptable about the new system. It does not work. It does not allow me to zoom (the quality just goes down but the picture doesn't get any bigger). The link for "More details on Wikimedia Commons" needs to be renamed because it took me about 3-5 minutes of clicking on this link and that link to figure out how to get to the old page. The pictures seem to load slower. Overall, when I want to see a larger version of a picture or zoom in on a picture the old system was extremely quick and useful for that. Click on the picture in the article, click on the picture on the next page, which was generally large enough to be very fast to move the mouse to and then use my browser to zoom in/pan as necessary. To conclude, I can not see any benefit of the new system and I see a lot of down sides.

As for how to get to the old page, something like "No media-viewer" or something would make more sense. However, most of all, I am appalled that this new system seems to have been pushed out against the wishes of the community. You talk about consensus, but I don't think there is any consensus whatsoever that this is a good tool for wikipedia. The only consensus I see is that this is bad and that there was nothing particularly wrong with the old system. As to your comment for disabling it, I regularly use computers other then my own, sometimes other people's computers (as opposed to just public computers). I don't want to have to log into my account on every computer I use just to disable this "feature". The only way I would accept this is as an opt-in feature. If you want to run banners or whatever at the top of the page suggesting that we might like to opt in to this new media viewer thing, fine, but please don't make it the default for what seems to be the majority of us. Crazycasta (talk) 08:30, 6 June 2014 (UTC)

I think you are looking at this too much from the point of view of an editor. The first priority must always be the experience of the reader. The encyclopaedia is here for the readers, not for the benefit of the editors, and what the reader primarily needs on clicking on an image is an enlarged version and not a lot of guff about copyright, history and the creator of the page. In that respect MediaViewer is a good thing. That's not to say that editor experience is not important, it is, but it is secondary. For one, I am happy to have an extra click in exchange for a vastly improved reader experience.

I think you are right about the zoom issue though. We can presume in the majority of cases that the reader clicked on the image because they want to zoom in on it. For some images even filling the window is not sufficient to be able to get all the detail. Example: File:All_palaeotemps.png which looks like this in MediaViewer with no way to be able to zoom in and read the small text legends. Even my browser's (Firefox) Ctrl+ zoom function does not work in MediaViewer. Of course, that would only make the image more pixelated if it did work, but it is strange that MediaViewer finds a need to suppress this. SpinningSpark 11:08, 6 June 2014 (UTC)

Crazycasta, I know it seems like Media Viewer is slower than the old system, but it's actually faster than the old system. It seems slow because it doesn't just hang there for a couple of seconds with a blank white page, but shows you all the steps that it's doing. Measuring from when you first click on the image to when the full image is finally displayed on your screen, it's saving you time.

I understand that an enhanced zoom feature is likely to be on the program for the WMF's next fiscal year (which starts on July 1).

As for the allegedly non-existent consensus, the survey results are showing so much support that Media Viewer might be able to pass an WP:RFA soon. Tɛmplet:Smiley It's always important in these discussions to remember that people who dislike it are likely to complain, while people who do like it don't say much. After all, the person who has a problem usually has something specific and very informative to say (e.g., it urgently needs a zoom feature!), whereas the person who likes it can't usually say much more than "I like it" or "It works for me". "I like it" may be pleasant to hear, but it's not necessarily practical information, so most people don't bother posting it. The net result is that the team should be getting useful feedback, but you need to be very cautious about assuming that "people who had something they thought was worth posting here" is the same as "everyone". WhatamIdoing (talk) 19:46, 6 June 2014 (UTC)

I'm taking everything into account as far as load time. When I zoom or do anything it seems to want to load more. Also you should know that JavaScript heavy things such as this have a tendency to vary greatly from machine to machine in terms of performance. When I say "load time" I admit that I may not be referring only to the pure downloading of data from Wikipedia but also JavaScript representation of it to me. With the old system I never noticed any delay between clicking on an image and the next page coming up. As far as I could tell it was instant. The new system seems to take a second or two to load.

As far as consensus is concerned, I guess your poll is polling a different group of people then I interact with. Of my numerous friends that I have asked about this feature I have gotten only negative response. Not even neutral responses. As the poll doesn't seem to be terribly well advertised I would have to ask whether the results are prone to bias from those advocating for the tool. Crazycasta (talk) 08:39, 7 June 2014 (UTC)

I am not looking at this at all from the point of view of an editor. I primarily use Wikipedia as a reader and this **significantly** impedes my ability to do so with anything that relates to images. I'm not sure if I have ever edited a picture, if so it was only once or twice. I have never once wanted to see the images related to a wikipedia page as a slideshow. This may be useful for some other sites like wikimedia or something, but I have no interest in flipping through pictures on wikipedia. Crazycasta (talk) 08:39, 7 June 2014 (UTC)

@Crazycasta:: do you have any suggestions instead of "more details"? We want to avoid anything like "file page" or "description page" which is incomprehensible for the average reader.

As Keegan mentioned some sections earlier, we measure image load performance, and MediaViewer loads significantly faster than the file page. It is always possible we made a mistake or aren't aware of some special conditions which affect this for some users, so we are very interested in details (browser/OS type, screen size, time to load image in MediaViewer, time to open file page) if you perceive otherwise. See mw:Multimedia/Media_Viewer/Speed_reports.

Well, the suggestion I gave was something like "No media-viewer", I guess "Non-media-viewer" would work too. I'm afraid the "more details" description is completely incomprehensible to this reader. Like how am I supposed to know "more details" means plain view. Crazycasta (talk) 08:39, 7 June 2014 (UTC)

@Spinningspark:: disabling Ctrl-plus/minus is kind of a side-effect. The way browsers handle zoom varies and is usually opaque to the application, so MediaViewer resizes the image immediately to fit the screen. We plan to fix that eventually, there was just easier and more useful stuff to do (and will be for a while, probably). --Tgr (WMF) (talk) 19:50, 6 June 2014 (UTC)

I think the media viewer is an appalling idea. First, it sneaked up on me and I tried to find out what had happened. I spent a long time searching on Wikipedia not knowing what I was searching for and then adjusting my settings in my browser and doing a system restore thinking something must have changed at my end. I was flummoxed until I sent out a 'help me' when some kind soul was good enough to tell me I was not going mad. Why anyone would think it is a good idea to have to click through every picture on a page to get to the one you want is beyond me. And I was shown how to turn it off in 'Preferences' but that only works if I'm logged in. So if I want to do a quick check on one thing on Wikipedia I have to log in to get rid of the execrable viewer. A perfect case of people fiddling using the motto of 'If it ain't broke, break it!' Cannonmc (talk) 22:53, 12 June 2014 (UTC)

After a few weeks uf using Wikipedia with the so-called media viewer, I have come to the conclusion that I could very well do without it, at least in its present form, because I find it awkward to use. For one, it messes up the browsing history. Closing a file in the viewer should lead back to the article page and not advance to it. Even when I was a casual user, I found the display on a separate page with all the metadata more helpful than confusing. However, I do not thing we need to get rid of it, perhaps it will (better zooming, display of other media), but I would prefer if it were switched off by default as long as there are issues with it. Whatever media are stored on Wikipedia, I can always display with other programs, often better than the browser can do. In general, such new developments should be announced well in advance before they are introduced, and at least for a few months or so they should not be made the default. Rather, users should unobtrusively be invited to try them out for a while and give feedback. Only when they work well enough we can talk, poll, vote, ... about its general introduction. --Schlosser67 (talk) 07:30, 15 August 2014 (UTC)

As usual our industrious techies have their hearts in the right place but failed in delivery. Introduction was abrupt and, to many experienced editors, mysterious and disruptive. The product was mildly buggy, and still lacks at least one vital feature: Zoom. Not that this is a comprehensive list. So, it must go back in the oven and, when judged properly baked, must be better announced. Jim.henderson (talk) 16:28, 16 August 2014 (UTC)

Media viewer seems to take the licence details from the information template. This frequently has only "see below" entered, expecting the user to be on the file page and see the licence templates immediately below. But this is meaningless and unhelpful in the media viewer. I noticed this after responding to an editor on the help desk. The "old hands" will soon learn the ropes here, but user's who are not editors and who just wnat to reuse the image are going to have a hard time figuring it out. SpinningSpark 23:47, 4 June 2014 (UTC)

Hey Spinning Spark: the licensing is taken from the HTML markup in templates, so even if {{Information}} template is missing or says something like "See below" the licensing has to be somewhere on the page and it picks that up and displays it. Media Viewer will display licensing and link to information about that license as long as there is some sort of license template anywhere on the File page. HTH. Keegan (WMF) (talk) 03:13, 5 June 2014 (UTC)

More (technical) information: Commons:Machine-readable_data. Keegan (WMF) (talk) 03:28, 5 June 2014 (UTC)

That is not correct, the licence template is not displayed by Media Viewer, it just displays "see below" with nothing underneath it. See for instance this example. One has to click through to the file page before the licence templates are displayed. How can you not think that is confusing, especially when the link the reader needs to click is above, not below that statement? SpinningSpark 10:48, 5 June 2014 (UTC)

I see what you mean. But all Media Viewer aside, I can't figure out why you, as the contributor, would put "See below" in the permission field. Why would you not just put {{CC-by-sa}} or however you choose to release it in the information box? How you are releasing your content is vital information for you to fill out. Why would you not have the permission parameter properly filled out and leave it to chance that your contribution gets separated from the licensing field? That in-of-itself is not Media Viewer's problem, it's the lack of structured metadata for files both on-wiki here and on Commons. Fortunately the Multimedia team will be taking up this work in the coming months with the Wikidata team to work on getting these licensing field inconsistencies in check. Keegan (WMF) (talk) 19:43, 5 June 2014 (UTC)

Bawolff has informed me that "See below" is the default for a lot of upload tools at least the {{Information}} template here on English. This is ungood; we'll work to find a solution here. Keegan (WMF) (talk) 19:46, 5 June 2014 (UTC)

Its also the default for the same template on commons. Bawolff (talk) 19:51, 5 June 2014 (UTC)

I suppose it might make sense to replace the id="fileinfotpl_perm" part of template:information/commons:template:information with {{#if:{{{Permission|{{{permission|}}}}}}|id="fileinfotpl_perm"|}} in order to make it more consistent with the intent of Commons:Machine-readable_data. Bawolff (talk) 19:54, 5 June 2014 (UTC)

@Spinningspark: In my volunteer capacity I added the above code to {{Information}}. Now when I open up your example in Media Viewer, it says "View license" that is clearly clickable and takes me straight to the file page. While this isn't the most elegant solution, it sure looks a heck of a lot better than an empty "See below" field. This will continue to get work, and thank you very much for noticing this. Keegan (talk) 01:54, 6 June 2014 (UTC)

Well thanks for the thanks! SpinningSpark 07:48, 6 June 2014 (UTC)

Request for Comment at Wikipedia:Media Viewer/June 2014 RfC. I am not voting but I see that a number of editors have expressed opinions, especially here on MediaWiki, and I think it would be beneficial for the English Wikipedia community to have a consensus about this issue. --Pine^✉ 07:57, 7 June 2014 (UTC)

Thanks for the RfC. I am strongly opposed to the new default and have added 10 reasons why. -- 79.253.58.136 (talk) 21:01, 7 June 2014 (UTC)

Based on the community's experience with other intrusive features (like the font change), I think we'd get more useful information if we waited another week or two. If you think back to the font change, a lot of people were upset for a few days, but two weeks later, most people had either gotten used to it or found a way to disable it and no longer cared.

I hear that very few editors have disabled this so far. It will be interesting to see what happens whenever the next database report on prefs is run. WhatamIdoing (talk) 21:40, 7 June 2014 (UTC)

Actually the last I've heard (a couple of days ago) between 400-500 registered users have disabled this viewer in the few days it has been the default viewer, and that number would be higher if there was an upfront and easy way for users to do so. Let's see what that number has grown to in a week from now. IMO, the "approval" that is claimed for this viewer is less than sincere and is obtained from mainly inexperienced users who are unaware of all the faults and short comings of this viewer. It seems they have been asked very generic questions. e.g."Do you find the viewer useful"? After looking at a few images of course many occasional and inexperienced users are going to say e.g. "gee-wiz, sure I find it useful". It's like they've asked a group of swimmers if they found the water "useful", not knowing they have been given a swimming pool to swim in rather than a lake. The entire article for this viewer is biased, less than neutral and written by people trying to promote the viewer. To get an idea of why there is so much disapproval simply go to :

• Wikipedia:Media Viewer/June 2014 RfC
• Media Viewer feedback -- Gwillhickers (talk) 04:43, 9 June 2014 (UTC)

550-ish now. Compared with the number of users who have been active since MediaViewer has been enabled, the ratio is pretty stable over time (about a third of a percent). Agreed that it will be an important metric to track. (We intend to create public dashboards showing how opt-out numbers change but haven't gotten to it yet.)

You are missing the point. Or was the point to ensure better tracking for your NSA friends by making anonymous access unusable? Congratulatios. You have succeeded. What will be next, mandatory https for "security"? Removal of edit history "so it is less confusing" and plants cannot be traced to the gov IPs? There was a time I considered time invested in WP fixing as well spent. Not anymore. WP started a war against advanced users and focus on the sheep only. Controlling the sheep was the end goal after all, was it not? A shame, pure and only.83.240.117.207 (talk) 21:07, 14 February 2015 (UTC)

I don't think that considering the opinion of "inexperienced" users is healthy, though. Less frequent editors might have different priorities than you do; that does not make their opinion somehow invalid. If most people are unaware of the alleged benefits of the description pages, that might be indication that those benefits are just not relevant for them, and they might find the significantly faster loading times or the more immersive image viewing experience more important. --Tgr (WMF) (talk) 05:26, 9 June 2014 (UTC)

You're right, I don't think considering the opinions of inexperienced users is healthy either. Many don't know what they're missing in terms of looking at images in their highest resolution, reading file summary information, looking at categories, etc, etc. There are many image files like this whose highest resolution and other information are completely unavailable with media viewer. Many image files contain extra information about the image, the history or science involved, etc. The idea that this info is "confusing" to new readers makes it seem like someone is reaching for reasons to justify the existence of media viewer -- a reader would have to be something of an idiot to get confused here. We don't need to be dumbing down Wikipedia. I'm still wondering why at this late date provisions for viewing everything about an image file continues to be withheld from this media viewer. The complaints are numerous and there has been plenty of time to bring media viewer up to speed. Presently it's little more than a glorified slideshow feature. Whose in charge over there? -- Gwillhickers (talk) 14:52, 9 June 2014 (UTC)

Hey Gwillhickers: you know that Fabrice is the product manager for Media Viewer; you've been talking with him over on mediawiki.org :) Keegan (WMF) (talk) 18:06, 9 June 2014 (UTC)

Yes, I know, and my question was rhetorical. Seems if he was in charge he could have saw to it, by now, to bring media viewer up to speed, provide a way for anyone to instantly disable it, etc, etc. All we seem to be getting are smiley attempts to skirt these prospects. As you've been told repeatedly, media viewer's biggest flaw is that it doesn't allow the average non-logged in viewer to see images in their max resolution. (So much for the efforts of the Picture of the day folks.) Yet we were told that the average reader was your primary concern. (!) Are we starting to get it yet? -- Gwillhickers (talk) 21:37, 9 June 2014 (UTC)

Sure. He'll be bringing this all up to speed tomorrow. We spent several hours today talking about our options, including a possible instant opt-out and more clear was to get to a full resolution of the image for someone not logged-in/without an account. I give smiley faces because much is lost though text and I very much am intent on keeping this an amicable conversation. When I say that I'm listening to what you are saying, I truly am, and hopefully we can get some positive results out of this working together. Stay tuned, you'll be getting an update. Keegan (WMF) (talk) 23:04, 9 June 2014 (UTC)

@Keegan (WMF) and Fabrice Florin (WMF): Fair enough. A slide show would even be a welcomed feature from time to time, allowing one to go from image to image with ease within an article, esp one with lots of images, but for all practical purposes most readers just look at one image at a time as they read along within a given article. The idea that a slideshow was taking the place of a system that has worked fine for so many editors and readers for so many years, by a few individuals who were aware of all its faults, was a bit unsettling. Many editors have given much of their time, years, uploading and/or editing images, adding information, putting them in categories, etc, etc, to see it all go unnoticed by the many occasional viewers out there, not to mention the ones who frequent Wikipedia and rely on it as an encyclopedia, not an entertainment center. For a while it seemed that all our concerns were just being brushed aside. Hence my less than friendly tone from time to time. If the new viewer 'readily' allows full view of hi-res' images, a place where we can click on Description to add/edit info, license info, and allows us to add/delete/edit categories just as easily, you will at least have my blessing, for whatever it's worth. -- Gwillhickers (talk) 01:12, 10 June 2014 (UTC)

Hi folks, thanks for all your helpful feedback about Media Viewer in recent days. We really appreciate your candid recommendations on this page — and survey comments also confirm many of the issues you’ve raised.

The multimedia team is taking your feedback to heart, and we are sorry for any inconvenience caused by this tool. To respond quickly to the most frequent requests, we have now pushed back other projects to focus on Media Viewer for the next few weeks.

Here are some of the new features we are now developing for you, based on community suggestions.

1. Disable Media Viewer quickly:

• Instant Opt-in: A more prominent way for registered users to disable Media Viewer, without having to go to preferences. (#703^{[permanent dead link]})
• Opt-out for anons: An easy way for anonymous users to disable Media Viewer, using localstorage. (#704^{[permanent dead link]})

Except that I, as an actual user rather than the mere pretend ones from your user stories (btw, Agile methodology and all that bollocks, eh? How cute), I cannot permanently disable the thing, as my browser does not keep any state (not even local storage, which you should not be using for this anyway) after closing the session.

Of course, I tried to enter an actual user story on that Web 2.0 dashboard of yours, but alas, it seems to be party members only. Anyway, keep digging. — Preceding unsigned comment added by 109.81.211.11 (talk) 17:52, 16 August 2014 (UTC)

2. View images in larger/different sizes:

• View original file: A prominent button to open the original image in your browser, so you can zoom in to see its details, or download it for re-use. (#630^{[permanent dead link]})
• View different sizes: Prominent links to view images in different sizes from the Download panel, so you can open them in your browser. (#664^{[permanent dead link]})

3. Discover image information:

• Make it easier to find image information: Provide clear visual cues that more information is available, with links to open the metadata panel. (#706^{[permanent dead link]})
• Scroll down to see more info: Use either up or down arrows to open the metadata panel below the image, to make it easier to find. (#697^{[permanent dead link]})

4. Edit / Learn more on Commons:

• Show Commons link to logged out users: Show a prominent link to the Commons file page to all users, so they can learn more about this image. (#429^{[permanent dead link]})

5. Learn to use Media Viewer:

• Add tooltips to Media Viewer: Show more tooltips in Media Viewer, so that users can tell what each button will do. (#546^{[permanent dead link]})

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

We are working hard to get these changes completed by tomorrow, so we can test them before releasing them to production. If all goes well, we expect to deploy some of them to the English Wikipedia and other Media Viewer sites by Thursday evening. The rest of them will be deployed the following week.

Please let us know what you think. Which of these features seem most useful to you? Are there other critical features that you think we should consider next? We look forward to improving Media Viewer based on your feedback. Fabrice Florin (WMF) (talk) 00:31, 11 June 2014 (UTC)

"Please let us know what you think." -- What the fuck for? So you can ignore it? You've got three RfCs (en, de, wikimedia) all telling you what we think. You've got an ArbCom case, which you have been invited to, but you don't even have a clue what an ArbCom case is anyway. And someone has gone crying mom and implemented a "fix" in record time so that we could not disable your horrible abortion of a project ourselves: [2]. This is well beyond a joke.

Opt-out for anons - but surely the logical default for people who are not logged in should be for the viewer to be disabled as by definition you can't save preferencesCannonmc (talk) 08:03, 13 June 2014 (UTC)

Absolutely. This has to be "opt-in" for everyone. I have an extremely irate partner who strongly prefers to use Wikipedia anonymously, but who needs to look at maps at the highest possible resolution and read their underlying information (sources etc.). Cookies are a no-no, apparently, so "opted out" has to be the default position. Personally I don't really like this functionality either, but at least I can switch it off (and have). But I'm getting more earache over this change to Wikipedia than anything else in a very long time. Let me repeat: this must be "opt-in" for everyone. Thanks. RomanSpa (talk) 11:03, 14 June 2014 (UTC)

@RomanSpa: It's too little to late to save your ears from your partner, but there is a fix that will allow your partner to disable Media Viewer even while not logged-in. It's currently live on MediaWiki if you'd like to log out and test it there (as I just did myself; just pull up the fold and click "Disable Media Viewer"). This goes out to Wikimedia Commons tomorrow and then it will be backported to all the projects. Doesn't change the past, but I hope it helps in the future. Also, sorry I wasn't able to get back to you immediately over the weekend. Keegan (WMF) (talk) 19:16, 16 June 2014 (UTC)

Keegan (WMF): Thanks for this. I'll take a look at it just now, and pass the information on later today. RomanSpa (talk) 06:08, 17 June 2014 (UTC)

(Later): I've tried this on my machine, and can't resolve the problem on MediaWiki, as I can't see how to disable the functionality. I've also tried this on my partner's machine, but somehow it's now not showing MediaViewer at all, despite not being logged on as an editor. I suspect this may be because scripts for Wikipedia have now been disabled. RomanSpa (talk) 06:40, 17 June 2014 (UTC)

Hi RomanSpa: The new opt-out feature for anonymous users is now working on all wikis, along with all the other features listed below. Simply scroll down to the bottom of Media Viewer and click 'Disable Media Viewer', as described in this Help FAQ. We hope this addresses your concerns. Thanks again for suggesting this improvement. :) Fabrice Florin (WMF) (talk) 18:28, 20 June 2014 (UTC)

It needs to be opt-in, not opt-out. I, like this guy's partner, strongly prefer to use this thing anonymously, but I also browse permanently in porn mode, so any opt-out is lost after I shut down my browser. You broke it: it's up to you to fix it. — Preceding unsigned comment added by 109.81.211.240 (talk) 21:12, 10 August 2014 (UTC)

Would it not be more useful to have 'Disable Media Viewer' right at the top of any page, next to the log-in box rather than having to click on a picture, get the view you don't want, then scroll to the bottom of that page to find the 'disable' button. One prominent button at top of the first page in any Wikipedia session (anonymous or logged in)and everyone is happy! Cannonmc (talk) 08:09, 31 July 2014 (UTC)

Not to mention that after disabling, the thing stays on the MediaMangler page, instead of at least directing you to the real content page. So the process is: click on the image, find the "disable" link, click on it, hit the "Back" button on your browser, click again on the image. — Preceding unsigned comment added by 109.81.211.240 (talk) 21:15, 10 August 2014 (UTC)

Hi folks, we're happy to announce that we just released many new improvements to Media Viewer, in response to frequent community requests on this page and elsewhere. We hope you will try them out and let us know what you think.

1. Features on All Wikis
These features are now available on all wikis as of today:

• View original file (#630)
• Scroll down to see more info (#697)
• Show Commons link to logged out users (#429)
• Easy opt-out for registered users (#703)
• Opt-out for anons (#704)
• Add more tooltips to Media Viewer (#546)

You can test these features on this Featured Pictures page on the English Wikipedia.

2. Features on MediaWiki.org only
These features are now available on MediaWiki.org and will be deployed to all wikis by next Thursday:

• Make it easier to find image information (#706)
• Prominent links to different image sizes (#664)
• Disable MediaViewer for certain images (#511)
• Track 'View original file’ and ‘Commons link' clicks (#715, #726)
• Track Media Viewer Opt-outs (/#558, #675)

You can test these features on this demo page on MediaWiki.org, as well as on this metrics dashboard Archived 2015-09-24 at the Wayback Machine — and learn more on this updated help page.

3. Features in development
Other tasks in development or analysis include:

• Show attribution credits in download tool (#598)
• Make 'Commons link' and 'Use this file' more discoverable (#732)
• Click on image in Media Viewer to help view original file (#712)
• Improve Media Viewer UI on tablets (zoom/scroll) (#716)
• Remember the last selection for ‘Use this file' (#660)

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

4. Feedback
Overall, we keep getting generally positive feedback worldwide, with these latest results:

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

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

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

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

Let me re-write some of your statement above without the positive spin:

Overall, we keep getting huge volumes of negative feedback, with these latest results:

• A distressing number of global respondents find the tool not useful for its intended purpose (~40% average across surveys), even with the loaded wording on the Survey Monkey survey.
• Cumulative disapproval by language: English 71%, French 30%, Spanish 22%, Dutch 41%, Portugese 81%, German 72%, Hungarian 38%, Catalan 29% Even in our best case, about one out of every five respondents found the tool not useful.
• Even after a substantial overhaul, the disapproval rate has only fallen from 77% to 61%.
• These numbers, unfortunately, mean nothing anyway, since there is no data from the original media page with which we can compare these numbers.

I just came here again when looking at the image on Usenet Usenet#mediaviewer/File:Usenet_servers_and_clients.svg. It's impossible to see both the image and the caption which explains the image simultaneously. Seriously. Please kill this thing with fire. I recognize and commend the good intentions, but I unfortunately must condemn the end result. Leebert (talk) 02:50, 21 June 2014 (UTC)

How to turn it off. --Ancheta Wis   (talk | contribs) 03:38, 21 June 2014 (UTC)

Which, as best as I can tell, requires me to either always be logged in, or not clear all cookies when I close the browser. Neither of those is true. Besides, it's not relevant -- the point is that it's fundamentally broken. Leebert (talk) 11:30, 21 June 2014 (UTC)

Fabrice Florin clarified above that anonymous users can also scroll down to the bottom of Media Viewer and click 'Disable Media Viewer'. --Ancheta Wis   (talk | contribs) 15:46, 21 June 2014 (UTC)

Again, as I said above, it requires me to accept persistent cookies, which I do not do. Leebert (talk) 01:39, 22 June 2014 (UTC)

• In my opinion the above survey is not serious and serves one single purpose: to justify a posteriori a decision that was already made. It is not serious because:

• The statistics are wrong. When we count the number of users (and not the number of wikis) we get 55.7%, not 60%
• What kind of decision process is this that changes the default viewing system in all wikis because 55.7% of the inquiries considered it to be useful for viewing images and learning about them? Weird criterium!
• What kind of survey is this that gives the same weight to all responses, knowing that about 80% of the inquiries are not regular editors and never uploaded or used an image? Did you try to relate the yes/no answers to the experience of the users?
• The comment this represents about 0.34% of all registered users who touched the site since launch. We are sorry that this small minority of users doesn’t like the tool is not honest. We all know that most of the registered users are not active and that turning the new viewer off is hardly obvious.

• This whole process is really a shame and is making me re-evaluate my future contribution as a volunteer editor and creator. -- Alvesgaspar (talk) 12:32, 21 June 2014 (UTC)

pinging user:Fabrice Florin. --Ancheta Wis   (talk | contribs)

He's probably more likely to see a ping for User:Fabrice Florin (WMF) :) I'll drop him a line as well. Keegan (WMF) (talk) 18:21, 21 June 2014 (UTC)

I'm afraid some of the thoughtful detractors are taking too narrow a view. Yes, a breakdown of respondents according to experience and activity levels might be useful. Perhaps the most averse class would be us photographers and other busy editors, whilst the happiest class would be people who consume Wikipedia, have never made an editorial contribution, and are uninterested in how it is made. The latter class, far as I see, are far the biggest, thus the most relevant class of users and probably underrepresented in the survey, so yes, the defaults should be adjusted to suit them and we worker bees should adjust our options to suit ourselves. We're not making Wikipedia to serve people like us; we're making a consumer product. Jim.henderson (talk) 14:47, 23 June 2014 (UTC)

• Hello Leebert, Ancheta Wis, Alvesgaspar and Jim.henderson: Thank you all for your thoughtful feedback about Media Viewer. I have responded below to each of you, and really appreciate that you took the time to share your insights, so we can improve this tool with your help. Fabrice Florin (WMF) (talk) 01:46, 24 June 2014 (UTC)

• Leebert, I understand that you personally don't like Media Viewer, but encourage you to consider Jim's observation that "we're not making Wikipedia to serve people like us; we're making a consumer product." Media Viewer was developed to provide a better viewing experience for all users -- with a particular focus on our 500 million readers. This is why a survey was needed to get qualitative feedback from readers, who are usually uncomfortable responding on talk pages. We appreciate your concerns about the survey results and agree that they are not an ideal metric for measuring the impact of this tool on an ongoing basis. As a result, we plan to discontinue all surveys next week, now that we have collected the general feedback we needed for development purposes. But we wanted to share our key findings, for full disclosure, with the caveat that they are not a precise quantitative measure. Going forward, we plan to use image views and number of enabled/disabled users as our new metrics for Media Viewer. For now, if you would like to compare the performance of Media Viewer with the file pages, we invite you to check this dashboard Archived 2015-09-24 at the Wayback Machine, which indicates that Media Viewer loads images about twice as fast as the file pages. Fabrice Florin (WMF) (talk) 01:46, 24 June 2014 (UTC)

• Ancheta Wis, thanks for clarifying that both anonymous and registered users can scroll down to the bottom of Media Viewer and click 'Disable Media Viewer'. More information about this one-click opt-out feature can be found on this help page. Fabrice Florin (WMF) (talk) 01:46, 24 June 2014 (UTC)

• Alvesgaspar, I am sorry that you think the purpose of this survey is to "justify a decision that was already made": on the contrary, we started the survey months ago to learn from our users, and did not deploy the tool widely until we felt confident that it was useful to a majority of users around the world. You are correct that the average across all users is 55.7% (that number had not been verified when I filed this update, which is why I used the number across surveys instead); note that this average hovered between 60% and 70% for months, until the recent launch on the English and German Wikipedias, where post-launch negative feedback brought it back down. In any case, all these numbers have been fully disclosed at each step of the way, in good faith and to insure maximum transparency. Starting next week, we will end this survey and start tracking image views and disable rates instead, as more objective metrics. In response to your comment about the 0.34% disable rate, I would like to clarify that it is based on the cumulative number of registered users who disabled Media Viewer in their preferences, divided by the total users who edited a page since Media Viewer was launched on the English Wikipedia; so far, these rates have held steady, but they are expected to rise now that we’ve deployed easier opt-out tools. Fabrice Florin (WMF) (talk) 01:46, 24 June 2014 (UTC)

• Jim Henderson, I really appreciate your perspective as photographer and editor -- and I applaud your willingness to place the needs of our primary users above your own. I also agree with your insight that readers tend to find the tool more useful than editors, as we observed in this first study, which is consistent with our latest findings. We hope that over time, Media Viewer can expose your photographs to more people, so they may see them in larger size and learn from your work. Be well. Fabrice Florin (WMF) (talk) 01:46, 24 June 2014 (UTC)

I'm one of the people who has opted out and I want to correct the assumption that it's because I don't like the new feature, it's not. For what it does it looks to be fine but I'm an admin and a lot of my time is looking at files where I need to see the image page directly and I don't want to spend my time clicking through to get to the image page which I need to review or edit.

That said I think there is room for improvement in the layout of MV, putting the image caption rather than the image title in the first line below the image would be useful as it allows some context (assuming the caption makes sense) to be applied to the image. I used MV to look through a GA and the images made no sense at first view and I had to keep scrolling down to get the faintest impression why the image was appearing in the article. It's also not really helpful for location maps to appear in MV without the pin in them, a blank map of an area is a chocolate fireguard. Nthep (talk) 14:53, 24 June 2014 (UTC)

I find that updating my preferences | appearance | custom.css | with:

 .mw-mmv-overlay { background-color: transparent; 
                 color: white;
 }

gets rid of the black bars which are distracting. --Ancheta Wis   (talk | contribs) 01:34, 29 June 2014 (UTC)

• Right, Nthep, the best tool depends on who we are and what we are doing. The old view is better for us stagehands working behind the scenes. I spend some of my time handling my own photos, and more time clerking others including many that are older than me. In either case I am studying and improving the information about the picture, including its categories and geotag, more than I'm examining what's in the picture. Commons being mostly a back office of this business, the virtues of the new viewer are less relevant there, than here in Wikipedia where the audience sit. Jim.henderson (talk) 11:45, 28 June 2014 (UTC)

The expandable panel displaying license details is good - thank you. However, when expanded it offers an Tɛmplet:Bigger icon in the top right corner to collapse the panel. That's the wrong icon; it signifies closing a window completely. It should be something like instead. — Scott • talk 15:29, 30 June 2014 (UTC)

The number one reason I ever click through an image on WP (or hit the "Enlarge" button) is to see the image in a different size. For example, the graphs on this page: https://en.wikipedia.org/wiki/Thermocouple#Type_J , which happen to be SVGs. But when they appear in Media Viewer, I have not discovered any way to zoom them or explicitly select a different size (ie: to actually see an "enlarged" view). Am I missing something? Gwideman (talk) 20:40, 7 July 2014 (UTC)

In Chrome and in Firefox 29, you can use [ctrl][ - ] to shrink the image, and [ctrl][ + ] to enlarge the image. --Ancheta Wis   (talk | contribs) 21:24, 7 July 2014 (UTC)

No you can't.

Actually, for Chrome and Firefox 29, maybe you can, but for Firefox 31, a more recent version than 29, this system in no way allows for zooming.

[ctrl][ - ] and [ctrl][ + ] are Firefox's text-resize features. This means that [ctrl][ - ] shrinks the image just fine, but it also shrinks the bottom text and resizes the text for any other windows you have open. You'll have to resize the image back up in order to go back to any other pages. And moreover, when you then try to [ctrl][ + ] to zoom, the bottom text enlarges with the image... and when the bottom text enlarges, this leaves less room on the page for the image, so the image actually ends up shrinking, instead of zooming like intended. If you fiddle around with it, you can sometimes get the image to zoom in, but the user has minimal control over the level at which you'll find the zoom, and in any case, it can still only happen at the cost of screen size, such that overall, you're left being able to see significantly less of the image than your screen would otherwise allow.

This is why I disabled "media viewer" entirely today: because it doesn't let me view media.

And to anyone from the administration listening, I must inform you that I also take great exception to the fact that there was no public-opt-in beta testing done on this feature before it became the standard used across Wikipedia. I remember quite vividly that there was a time when no opting-out was possible. Admittedly, I'm too young to have ever donated to Wikipedia before, but the potential this site holds for disseminating free information synchs quite well with my ethical precepts, such that I was considering setting myself up to make a monthly donation. No longer. If this site can't be bothered to act democratically, I can't be bothered, as a member of the demos, to support it. Oh well.

172.0.9.89 (talk) 01:47, 29 July 2014 (UTC)

I undid another user's undo of my edit changing the word "confusing" to "educational". Is the text surrounding the images educational? I say yes. Is it confusing? I say no. Further, the claim that the image is "larger" doesn't bear out, for me at least. Does anyone else see a problem with my changes? or is it only Satellizer? 74.46.254.174 (talk) 00:27, 11 July 2014 (UTC)

I'm not a fan of the media viewer myself, but I agree that the change from "confusing" to "educational" is not an improvement to the page. The description page may be useful to experienced editors, but I can see how it could be very confusing to new users. ​—DoRD (talk)​ 12:40, 11 July 2014 (UTC)

I agree with what DoRD said above, and he pretty much explained why I reverted your edit. Additionally, I'm no fan of the media viewer either, having disabled it, but I fail to see how file description pages are "educational" - they only contain licensing and copyright information. Satellizer (´ ･ ω ･ `) 01:43, 12 July 2014 (UTC)

it has nothing to do with my personal views on Media Viewer, but the text provided with the image was supplied by the uploader as educational text, not confusing. Had the uploaders been informed that any text provided with their upload would be considered "confusing", and would be hidden, i doubt that those uploaders would have bothered entering it. further, last time i looked, our mission statement was about education. sometimes education is confusing but people learn... and not by hiding text. this example image is shown by Media Viewer in 320px resolution, so that's not "larger size". in addition, the "confusing text" that goes with that image is:

The eight frames image show how Fata Morgana mirage is changing constantly the appearance of the two ships. Four frames in the first column is ship # 1, and four frames in the second column is ship # 2. i do not see how hiding this text reduces 'confusion', given the image, i would say that the text is imperative to understanding what's going on in the image. 74.46.254.174 (talk) 17:50, 12 July 2014 (UTC)

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

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

Rich Farmbrough 19:04, 17 July 2014 (UTC).
(also posted at Media Wiki

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

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

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

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

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

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

In this example, the problem is not limited to users with visual impairment, and that is bad enough, but the problem will be far more common, blocking the reading of more and more graphical content, so long as Media Viewer's design continues to circumvent browser accessibility features. --j⚛e decker^talk 20:05, 11 August 2014 (UTC)

You are missing the point. The PURPOSE is to entertain not to have people looking at details. And sadly, it works. Most average users will rather abandon the ieda of checking the detail than fighting the interface. Objective accomplished! 83.240.20.46 (talk) 12:36, 4 July 2015 (UTC)

Who had this stupid idea, and why did it become a default option? Utter crap. --189.245.68.181 (talk) 23:10, 19 August 2014 (UTC)

Agreed, this may be the most frustrating thing Wikipedia has ever done. 99.127.157.202 (talk) 17:42, 3 October 2014 (UTC)

This may be of interest to readers here - Meta:Letter to Wikimedia Foundation: Superprotect and Media Viewer. VQuakr (talk) 03:43, 21 August 2014 (UTC)

Is it just me, or does this page read like a PR piece? This page talks about how everybody loves Media Viewer, and reads like an advert aimed at promoting Media Viewer. Surely this page would be better off being written in a more neutral manner? --benlisquare_T•C•E 09:44, 22 August 2014 (UTC)

Comments invited at Wikipedia:Village pump (proposals)/Media viewer 2014. Alsee (talk) 05:51, 8 October 2014 (UTC)

Occasionally MediaViewer will stretch an image, I'm not sure why. I'm using IE11 on Windows 7 if that helps. Eman235/talk 07:09, 12 October 2014 (UTC)

That's odd, Eman. Does the same image do that repeatedly, or does the same image show correctly one time and then stretched the next? I'm sure that User:Keegan (WMF) would love to have an example of one that consistently is stretched for you (if that happens). Whatamidoing (WMF) (talk) 00:32, 18 October 2014 (UTC)

@Whatamidoing (WMF):Usually it happens on tall images, like on Gibson ES-339. What happens here is I open it -- it's fine -- it stretches -- then if I close it and open again it stays normal. If I refresh the browser it does the same thing. Eman235/talk 03:09, 18 October 2014 (UTC)

Thanks for the reply. The infobox image looks okay on my computer, but that's meaningless, since I've got a different kind of computer. Does it stretch taller or wider? Whatamidoing (WMF) (talk) 04:52, 20 October 2014 (UTC)

@Whatamidoing (WMF): Wider. And it doesn't do it all the time. Right now it's not doing it. Actually, there are two computers in my house, both Windows 7, and I'm not sure if it doesn't only do it on one. Tɛmplet:P I will get back to you if I get some more "evidence"...Eman235/talk 05:30, 20 October 2014 (UTC)

I can't find the bug report right off the bat, but this is a known IE bug that does show up only under certain image size conditions. Thanks for the report! Keegan (WMF) (talk) 18:48, 20 October 2014 (UTC)

Keegan -- thanks. I think it's images that are tall enough to touch both the top and bottom of the frame, with no blank space at the top/bottom. Instead of shrinking them, it just stretches them. Eman235/talk 23:05, 20 October 2014 (UTC)

The following was originally posted at Wikipedia:Bot requests:

At an RFC about media viewer, some editors complained that editors are linking directly to the media viewer page instead of using File links that respect user's preferences. A bot that changes these links to File links would fix this issue. Oiyarbepsy (talk) 15:46, 7 November 2014 (UTC)

If you're referring to my complaint specifically, a bot would not solve my problem. A bot can't fix links on, say, Reddit. --98.207.91.246 (talk) 21:09, 7 November 2014 (UTC)

Oh - in that case, we need a Mediawiki solution where media viewer urls are the same as file urls? Oiyarbepsy (talk) 21:20, 7 November 2014 (UTC)

Pretty much. A MediaViewer URL includes the name of the page where the image was clicked; if that URL is pasted elsewhere, it's not just out of context: if followed, your browser loads the page you're not interested in and then goes to the MV page. It might be the WMF's way of implementing a referer. --Redrose64 (talk) 22:20, 7 November 2014 (UTC)

A MediaViewer link is not the same as a file page; it is a way to refer to an image within the context of an article. You can't do that with a "conventional" link. An automatic redirect from the Media Viewer URL to the file page for users who have disabled Media Viewer is doable but not necessarily useful. --Tgr (WMF) (talk) 00:29, 8 November 2014 (UTC)

Well, a lot of folks here absolutely despise it, so a quick preference check followed by a redirect to the non-MV file page would be hugely useful to them, Oiyarbepsy (talk) 00:35, 8 November 2014 (UTC)

Oiyarbepsy, I should have probably clarified that Media Viewer opens up regardless of your preferences if you visit a Media Viewer-specific URL. I'm not sure we want to change that as a default, but if you are interested in a gadget or user script that disables that behavior and does something else, I can write one. (I would probably show some sort of notification with a link to the file page, but if you prefer to just redirect there without any warning, that's certainly possible.) --Tgr (WMF) (talk) 09:08, 20 November 2014 (UTC)

As noted above, the user really having a problem with this is an IP editor, who can't use such a gadget, so this is missing the point. Internet users copying the url think they are copying the link to an image, not an article with an image on it, so the url in the screen should be an image. Oiyarbepsy (talk) 15:25, 20 November 2014 (UTC)

I think you are not giving enough credit to internet users :) It is fairly intuitive that sharing the URL you see in your browser's address bar will reproduce the same state you are in - if you are looking at an image on top of an article, it will load the image on top of an article. Anecdotally, users seem to appreciate the feature.

The main goal of having a disable option is so that Media Viewer does not get into the way for people who do regular image curation, or otherwise need to access the file page often, and would be inconvenienced by the extra click Media Viewer introduces in that process. Since following Media Viewer-specific URLs does not happen in the process of such image curation, and there is no "classical" URL which would encompass all the information in such an URL, there is no reason to apply the disable preference in such a case, and I imagine most users would prefer the Media Viewer view to being sent to the file page with no context whatsoever.

If someone is bothered by that, the easiest option is registering a user account, I suppose. Media Viewer is pretty unique in that it allows having preferences anonymously at all (if you e.g. don't like the Vector skin, and want to remain an IP editor, tough luck), but there will always be limits to how far you can customize your Wikipedia experience if you don't want to log in. Although if you are persistent enough, you can get around that with tools like Greasemonkey. --Tgr (WMF) (talk) 22:10, 20 November 2014 (UTC)

Some images should always be excluded from the "next image" button in Media Viewer. As an example, if you scroll through the images at World War 2, near the end you see this, this, and this, and others. Things like logos for Wikimedia projects, symbols of article types (like the featured article star) and graphics like that should be skipped when browsing thru images, since they are of no value on the vast majority of pages. Oiyarbepsy (talk) 23:45, 7 November 2014 (UTC)

My understanding is that templates like navboxes or amboxes should have a metadata class. MediaViewer ignores any image found inside elements with such a class. (Also, it is a good idea to make the icon link to the site it represents, instead of the file description page. Images which link somewhere are also ignored by MediaViewer.) --Tgr (WMF) (talk) 00:25, 8 November 2014 (UTC)

@Tgr (WMF): Is this something that I, as Joe Editor, could fix? Oiyarbepsy (talk) 15:28, 20 November 2014 (UTC)

Yes, you could just add class="metadata" to the outermost element of the template. That will make MediaViewer ignore the contents, and it will also make sure the template does not appear in various views where navigational templates don't make much sense (print, PDF, mobile...). --Tgr (WMF) (talk) 18:41, 20 November 2014 (UTC)

Apparently, this doesn't work. The images in Template:Sister project links still show up in Media Viewer, dispite the template having the metadata class. Is this a bug? -- [[User:Edokter]] {{talk}} 16:34, 11 December 2014 (UTC)

Edokter: they don't. If you see those icons, they are included somewhere else on the page (such as {{World War II}} for example). Here is a debugging snippet you can use to get a list of the thumbnails which are handled by Media Viewer (you will need to open and close Media Viewer first for this to work, it is lazy-initialized): mw.mmv.bootstrap.viewer.thumbs.map(function(i){return i.$thumb[0]}) --Tgr (WMF) (talk) 23:12, 11 December 2014 (UTC)

Ah... It was another template! -- [[User:Edokter]] {{talk}} 23:28, 11 December 2014 (UTC)

I just requested this change at a fully-protected template Template talk:Portal and was told it would make the template useless for mobile users. We need a better solution if that's the case. Oiyarbepsy (talk) 07:07, 22 November 2014 (UTC)

You can use the noviewer class instead if you don't want any side effects. --Tgr (WMF) (talk) 01:08, 25 November 2014 (UTC)

I used to be able to open images pretty easily on Wikipedia. Now they're all slow, and often they just hang blurry forever. I gather that the Media Viewer is the reason why. Not a good look, Wikipedia. — Preceding unsigned comment added by 203.152.114.160 (talk) 03:10, 4 December 2014 (UTC)

Same here. Image loading is slow of late, whether inside media viewer or not (even the thumbnails would sometimes load slowly). SorcererofDM (talk) 01:31, 24 April 2015 (UTC)

Well, that last comment is not really germane to this discussion, but yeah, the Media Viewer is definitely slow, at least on Firefox. Despite the claims of WhatamIdoing in #Get rid of it!, I have consistently found it to be much slower than right-clicking to open an image page in a new tab, and no, it's not an illusion. I haven't ever had it hang forever loading an image, AFAIK, but I frequently get impatient looking at a black page for many many seconds and give up and open the image's page instead. I just discovered the setting in Special:Preferences → Appearance to disable Media Viewer, and have finally done so. --Dan Harkless (talk) 05:10, 26 April 2017 (UTC)

There have been some reports of this. If you are willing to do some debugging, see mw:Reading/Multimedia/Media Viewer/Speed reports. --Tgr (WMF) (talk) 12:39, 27 April 2017 (UTC)

Thank you for the pointer. I won't have time to do so immediately, but I'll try to collect some data in different browsing circumstances and report when I'm able. --Dan Harkless (talk) 02:40, 28 April 2017 (UTC)

I never did have time to try to help with debugging this, but I'll say that on occasion, I won't be logged into my account (which still has the Media Viewer disabled, as I prefer that setup regardless of speed) while accessing Wikipedia, and I've no longer found the Media Viewer to be painfully slow in such circumstances. Very substantial performance improvements have been made to Firefox since 2017, particularly in the area of JavaScript garbage collection, so this may no longer be an issue (at least with Firefox). --Dan Harkless (talk) 08:35, 4 July 2019 (UTC)

I edit and read Wikipedia on a 1920 × 1200 monitor. I like how Media Viewer incorporates the description when showing File:Writing systems worldwide.png. But why be so chintzy with the space allowed to show the description? In this example, I only see two lines, and now I see (at first I did not, which was very misleading) three dots indicating that it's been truncated. There are two inches of black border between the image and the description – what's the point of that? I was pondering why they left the color keys out for China, Japan and Korea (or were they hidden somewhere? Where?) when I finally realized I could get the third line by scrolling. In fact, I can scroll the whole thing up to the "About Media Viewer | Discuss this feature | Help" line and still leave an adequate eighth-inch wide black border. Why isn't that the default? I suppose I could then pull it down if I wanted it to look pretty. I see that there are "More details"... and more details. This image is a bit useless without its description and color key. I can see where scrolling might be useful if the description etc. were larger than the black border area. Then it might be more obvious that part of it was truncated. Wbm1058 (talk) 21:42, 20 February 2015 (UTC)

Compare File:Thure_de_Thulstrup_-_L._Prang_and_Co._-_Battle_of_Gettysburg_-_Restoration_by_Adam_Cuerden.jpg - where I am credited - with The media viewer version, which hides all mention of my work. If MediaViewer can't handle basic attribution, it needs fixed, and if it can't be fixed, it needs turned off. If I recall correctly, issues with creator templates were reported months ago, and I didn't raise a fuss then as I was assured that they'd be fixed.

If you can't do it right, don't make it look like you are doing it right when you aren't. If MediaViewer can't interpret something, it's far better to say "see file page" than to mislead. Adam Cuerden ^(talk) 12:19, 9 March 2015 (UTC)

For me, it describes what the image depicts and then says "restoration by Adam Cuerden", so I'm not sure why we're not seeing the same thing. Oiyarbepsy (talk) 14:27, 9 March 2015 (UTC)

Ah, I see that now, but it's not included in the XML data, marked as what to copy and paste, which it really should be. Adam Cuerden ^(talk) 14:35, 9 March 2015 (UTC)

Hi. In general I do like the format. Is there a way to make it compatible with any of the image annotators e.g.:

• Template:Annotated_image_4
• Wikimedia image annotator

Currently all annotations disappear when viewing the image full-screen. Alternatively, is there an annotator that is currently compatible (the ones above just happen to be the ones I know about)? Thanks, T.Shafee(Evo﹠Evo)^talk 01:10, 27 March 2015 (UTC)

It's been quite a while since this "piece" was introduced. ... And I never liked it! (There are several reasons for that but that's of no concern for this comment.)
It got on my nerves all along --- but some time ago I was happy again (for just some hours). That was when I realized the option to turn it off! I always ignored the "smartphone" GUI elements of the Media Viewer since I never wanted to use it, so I never looked behind the gear symbol before.
But now I can see the uselessness of this option. - Why is its setting not saved (e.g. by a cookie)???
At first I thought the problem was made by myself - with most browsers I choose the deletion of all cookies after a clean shut down of the process. But my Firefox normally runs for days or weeks, only restarting when its CPU and memory consumption is getting too big. And still I have to re-set this option on every day, for every computer and every Wikipedia language version?!

Why are you torturing accountless people all over the world? — Preceding unsigned comment added by 141.76.83.180 (talk) 09:20, 13 May 2015 (UTC)

Some people in WM are sadists. Live with it. Yes, this "improvement" is a piece of **** made by either by morons or purely evil people with intent to make only signed usage practical. A proven salami method. Nuf said.83.240.20.46 (talk) 12:33, 4 July 2015 (UTC)

Hi, a strip at the bottom of this picture is being cropped off by Media Viewer. It looks as if it is being drawn and then overwritten with a black strip. This happens both in IE and in Chrome (Win 7). It may be sensitive to browser width, so if it doesn't reproduce at first, try varying the browser window size and refreshing. Also, in IE, when you scroll up and down to show/hide the details panel, the image jumps in a way that does not look intended. 109.153.244.75 (talk) 02:28, 21 June 2015 (UTC)

Battle of Rossbach I was testing a new computer, looked in this article and wondered why the Viewer didn't show a link to Details or to Commons. So, now I'm on the old computer and, same thing, and it also happens in other articles and other pictures. How do I get from Media Viewer, to picture details, to Commons? Has something new been broken? Jim.henderson (talk) 22:15, 1 September 2015 (UTC)

It started working again yesterday. Thanks, if you repaired it. Jim.henderson (talk) 10:13, 3 September 2015 (UTC)

Wikipedia:Alternative text for images says that images used in articles should include the alt parameter with alternative text that "allows the content and function of an image to be understood by text-only readers." However this practice is more the exception than the rule on Wikipedia. One problem with alt text is that it is not easily visible without a specialized screen reader. I think it would be helpful if the Media Viewer showed the alternative text when present, making it easier for users to see if it is present and what it says. This should be simple enough to implement. A button or feature to allow adding or editing of alternative text would be even better, though obviously a much bigger project.--agr (talk) 11:22, 25 September 2015 (UTC)

@ArnoldReinhold: Media Viewer is an image viewer, not an editor. (That is VisualEditor and it already supports alt text.) Media Viewer includes the alt text where it makes sense (T75923, T66519) but there is already confusion from displaying two different descriptions (the caption and the text from the information template on the file page) and adding a third one which is explicitly not meant to be displayed does not help. (I'd love to see T77152 figured out though so that people who want to use Media Viewer for some uncommon purpose can tweak it.) --Tgr (WMF) (talk) 21:56, 25 September 2015 (UTC)

@Tgr (WMF): Thanks for your reply. Our guideline WP:ACCIM which reflects the WMF Non-discrimination policy [3] Archived 2017-01-28 at the Wayback Machine says images should include an alt attribute. Few do. In large part, I suggest this is because as you say alt text is “not meant to be displayed.” There is no easy way for users who are not employing specialized screen readers to detect if alt text is even present. One must view the article in edit mode and comb through each file reference. Thus Alt text is too much bother for editors to pay attention to, out of sight = out of mind. The Media Viewer seems like a straightforward and natural place to help rectify this problem. I don’t think adding the alt text (in the rare cases where it is present) to the block of text at the bottom of the media view would be confusing. But if that is your main concern, a “View alt text” link much like the present “View license” link would still be helpful. It might read “No alt text” when none is present and link to WP:ALT or some other explanation and instructions. Improving Wikipedia accessibility should be part of every project. --agr (talk) 14:07, 27 September 2015 (UTC)

I cannot figure out how to disable the Media Viewer on mobile devices (Chrome browser at least). I've tried disabling it in the preferences page and adding "mw.config.set("wgMediaViewerOnClick", false);" in global.js. Both of these tricks seem to work on my desktop, but the setting is ignored on my Android phone. Also, the "cogs" icon is not visible in the mobile browser. I can't stand the Media Viewer as it breaks the now "back" function in the browser and make annoying jumps when zooming on and hides useful image information. — Preceding unsigned comment added by MortenBakkedal (talk • contribs) 21:06, 11 January 2017 (UTC)

Media Viewer is desktop-only. The mobile interface has its own image viewer (which looks vaguely similar). Phabricator is probably a better place to report issues about it. (As far as I know it though, it does not interfere with the "back" functionality in any way.) --Tgr (WMF) (talk) 21:55, 14 January 2017 (UTC)

I've noticed, for example, that if a work was created in say, 2002 (without a specific date), Media Viewer will display the date as "31 December 2001". It does the same for months; if a work was created in February 1975, without a specific date, it will display the date as "31 January 1975". Would this be able to be corrected? Thanks! MB298 (talk) 22:15, 13 May 2017 (UTC)

@MB298: Not sure what's the state of date parsing Javascript libraries this days but back when I was still working on MediaViewer there just wasn't one that could deal with partial dates. T58794 is the related task. --Tgr (WMF) (talk) 21:07, 16 May 2017 (UTC)

If you are bothered about the one-day difference specifically, that's probably a time zone issue and might be worth a separate bug report. --Tgr (WMF) (talk) 21:08, 16 May 2017 (UTC)

I had previously disabled Media Viewer, but as of this morning it popped up when I clicked on an image. When I tried to use the settings to disable it again, clicking the "Disable Media Viewer" button did nothing, i.e. the button animation happened but the panel did not even close. The "Cancel" button worked, but that is not what I wanted to do. I am using Firefox and am not logged in to Wikipedia as I am just a casual user and have no need of an account. 81.140.176.161 (talk) 08:23, 9 September 2017 (UTC)

Can't reproduce that. Do you see any javascript error?

Disable settings not lasting forever when you are not logged in is intentional (I think it lasts for 30 days), to avoid public machines getting stuck with random settings. --Tgr (WMF) (talk) 06:08, 11 September 2017 (UTC)

The problem went away for no apparent reason shortly after I first reported it, i.e. the site respected my previously stated preference not to use the viewer, but today it has come back again and I still cannot disable it, i.e. if I click the "Disable Media Viewer" button nothing happens and the popup settings panel just sits there. I'm seeing the following

JQMIGRATE: Migrate is installed with logging active, version 3.0.1 load.php:139:615 This page is using the deprecated ResourceLoader module "jquery.tipsy". load.php:5:664 ReferenceError: reference to undefined property "outsideClickHandler"[Learn More] load.php:49:498 ReferenceError: reference to undefined property "nodeType"[Learn More] load.php:72:204 ReferenceError: reference to undefined property 0[Learn More] load.php:23:652 ReferenceError: reference to undefined property "then"[Learn More] load.php:52:1 ReferenceError: reference to undefined property "panelShrinkTimeout"[Learn More] load.php:82:645 ReferenceError: reference to undefined property Symbol.toPrimitive[Learn More] load.php:321:729

Frankly the idea that the site would forget a normal, i.e. not logged in, user's settings after 30 days because of problems a very tiny percentage of systems might have, is bizarre and I have never had the setting drop after 30 days before81.154.118.145 (talk) 14:25, 11 November 2017 (UTC)

As an example of where Media Viewer appears not to fulfil its mission, the article Christopher Columbus has a map with his four transatlantic voyages, Viajes_de_colon_en.svg. The image description page renders it as a 512x343 PNG by default, but since it's a vector image there is the option to see it at higher resolutions with none of the blockiness this would introduce in a raster image. The 1280x858 option fills my screen nicely.

If Media Viewer is supposed to give users an 'immersive' experience, and pops up an interface that covers the article and sidebar to allow maximum space to the image, how come it too renders the SVG at 512x343, barely bigger than the thumbnail I clicked on to bring it up? Shouldn't Media Viewer render vector images to fill the viewer's screen? Otherwise what is the point of it? Why not just take us through to the image description page where at least the option to see it in large format is explicitly offered? Beorhtwulf (talk) 18:40, 8 October 2018 (UTC)

For a while now (a few months at least) the X button returns to the top of the article instead of to where you left off in Firefox. If this is normal behavior under FF it should probably not be used unless it can be fixed. Otherwise it's something affecting some users, maybe related to extensions, though unlikely since Wikipedia doesn't have ads. My current FF version is 70.0.1. --184.20.10.253 (talk) 19:29, 4 December 2019 (UTC)

Seconded - would love to know more about this. Ahuskay 17:50, 10 December 2019 (UTC)

Thirded. — Preceding unsigned comment added by 2604:6000:1514:453A:A509:A634:74BB:8FBD (talk) 16:36, 15 December 2019 (UTC)

Confirmed, using FF 70.0. Rather annoying bug. Wulfila 20 December 2019 —Preceding undated comment added 23:57, 19 December 2019 (UTC)

I've got this happening on version 71.0 (64-bit). It's been annoying me to no end. Happens on my work and home PCs (both using Firefox on Windows 10). Zyzzek (talk) 10:24, 23 December 2019 (UTC)

This is due to Firefox lately implemented asynchronous history navigation Archived 2019-12-30 at the Wayback Machine in version 70 last October, this was reported to Mozilla's Bugzilla as Bug 1594345 (where its status is currently fix-optional only in firefox72), and Wikimedia's Phabricator as T229484 . --Khaled Khalil (talk) 14:08, 2 January 2020 (UTC)

As a workaround, you can press the escape button or a "go back" button if your mouse has one. DxhaFFer (talk) 13:58, 8 May 2020 (UTC)

This is not an exclusively Firefox specific issue. It's been happening in Chrome for a while. 98.114.95.90 (talk) 09:44, 9 November 2020 (UTC)

Hi all. Did Media Viewer change recently? I thought the first line would be whatever caption is set on the file description page, not the caption on the enwiki article... Is there a way to choose which one to use on Media Viewer? I'd like to give more information by using a different caption on the article vs. the media viewer caption. Thanks, ɱ (talk) 13:13, 17 September 2020 (UTC)

WHat about the icons in media viewer? Such as Fair use icon, Public Domain icon, why no icons uploaded here on Wikimedia COmmons, Wikipedia?

Eaaaaugh (talk) 01:14, 10 December 2020 (UTC)

Hello, is it possible to see which are the most viewed images through Media Viewer? I found this page but i'm unsure on is counted as view.

Also an API endpoint would be fine!

Thank you! --Sette-quattro (talk) 12:49, 17 June 2022 (UTC)

@ 196.191.189.177 (talk) 20:51, 26 May 2023 (UTC)