Extension talk:Media Viewer/About

Back Button is broken
If you open an image and then use the back button all you get is black, at least in the current Firefox. All of the functionality that was just obvious on the old page is now hidden, fading in and out and generally making a nuisance of itself. Thanks for being part of the movement to destroy the web by appifying everything.

Honestly, there have been a lot of articles about what's wrong with Wikipedia over the last years; not a single one complained about the media viewer. Great job guys... 93.104.182.210 12:04, 13 July 2014 (UTC)

Image is covered when zooming
When zooming in on Safari (using pinch to zoom on the Mac), the description covers an increasing part of the image. 84.118.208.70 11:36, 28 June 2014 (UTC)

Media viewer does not display well big images on ipad
First of all as frequent Commons user I really do not need this tool. Until now I was too lazy to change my preferences, though I always click it off. But today I realized, MV couldn't display this file in the upright position on an ipad. The whole Image was pressed in the center. Later it was ok.--Oursana (talk) 17:03, 28 June 2014 (UTC)

c:File:After Lucas Cranach the Younger, 17th cent., ‘Portrait of Johann Friederich of Saxony and the Reformers’, Plymouth City Museum and Art Gallery.jpg
This File gets the Filename from other versions gallery in media viewer. Seems to be a bug, please comment and repair.--Oursana (talk) 11:55, 1 July 2014 (UTC)
 * I'm seeing the file name presented from the name of the file, not the other versions. Is this something that you can reproduce, or maybe take a screenshot of? Keegan (WMF) (talk) 18:34, 1 July 2014 (UTC)

How are opt-outs being counted?
It has been stated that opt-outs from Media Viewer are being tracked. Does this include people like me who disable Javascript using NoScript in order to avoid Media Viewer? I've never clicked on any kind of opt-out, but I haven't seen Media Viewer since the week it was introduced (except to specifically check up on the situation, which has captured my interest somewhat). 79.74.105.228 17:33, 1 July 2014 (UTC)
 * There is not a way to count this as the Wikimedia Foundation does not track your browser settings, nor would there be a way of knowing a specific reason why they have Javascript disabled. Thank you for sharing your method and reasoning, though. Keegan (WMF) (talk) 18:36, 1 July 2014 (UTC)

wanted: disable tutorial
How can I disable it? Though it looks nice it's a big pain in the ass on some of my machines, which makes it unusable. -- Kai Burghardt (talk) 20:15, 1 July 2014 (UTC)
 * I mean globally. -- Kai Burghardt (talk) 20:20, 1 July 2014 (UTC)

MediaWiki does not currently support global settings, so you need to disable per-site. That's easy to do though: when MediaViewer opens, you can scroll to the bottom of the page and click "Disable MediaViewer".

Could you share more details on what makes it unusable on some of your machines? --Tgr (WMF) (talk) 21:05, 1 July 2014 (UTC)


 * Ya, I've already found the per-site opt-out, but I wondered why WP still uses the MV though I've deactivated here on MW. That's weird: We can use SUL, but sharing some settings is too complicated? However, I only use a few Wikis. It isn't very usable for high-res pictures: It loads, it shrinks the picture to my actual screensize and my mouse stutters. It made problems before, but now it feels even much heavier. BTW, it's sometimes counterproductive: A picture explained in the article and I won't switch all the time between MV and article view. There's a Ctrl-Tab/Ctrl-shift-Tab much faster. -- Kai Burghardt (talk) 14:50, 4 July 2014 (UTC)
 * In answer to your question about global preferences,, these can't be enabled or designed until there is full SUL of all accounts. That won't happen for a while; it's part of the technical debt that is slowly being worked down. I understand that discussions on how to implement global SUL will be starting fairly soon, and once the principles of who gets "custody" of usernames when there's a dispute is resolved, it will take several months to get all of the accounts aligned. Then it will be time to develop the application(s) for global preferences - though that will take some working out too.  (Being able to have different preferences per site will have to be built in, too.) Best guess would be 2-3 years out before we get this. Risker (talk) 08:26, 13 July 2014 (UTC)

Images still being shown at wrong aspect ratio
Win 7 / IE 11

The problem with some images being shown squashed or stretched is still occurring for me. The latest example I've noticed is http://en.wikipedia.org/wiki/RGB_color_model#mediaviewer/File:CIExy1931_sRGB_gamut_D65.png.

This is a serious problem that really should have been fixed by now. What is happening with it? 86.167.19.242 20:33, 1 July 2014 (UTC)

The bug has been fixed a week ago, and the link works fine for me in Win8/IE11. Might be a cache issue - you could try refreshing via Ctrl-F5, or clearing your browser cache. --Tgr (WMF) (talk) 21:02, 1 July 2014 (UTC)


 * Thanks, that seems to have fixed it, at least for that picture. Do you know whether this failure to download new versions of pages is another bug with Wikipedia, or is it a browser bug? 86.167.19.242 22:53, 1 July 2014 (UTC) Spoke too soon. It displayed OK two or three times, now it is back to being stretched. 86.167.19.242 22:55, 1 July 2014 (UTC)
 * In case it is significant, by the way, it displays in the correct proportion but as a blurry low-res image for about a quarter of a second, then rescales to the wrong proportion. 86.167.19.242 22:57, 1 July 2014 (UTC)

Behaviour is inconsistent and not exactly reproducible. Try this:

In IE, set up bookmark buttons for the following three pages (makes things easier):

http://en.wikipedia.org/wiki/RGB_color_model#mediaviewer/File:CIExy1931_sRGB_gamut_D65.png http://upload.wikimedia.org/wikipedia/commons/0/08/CIExy1931_sRGB_gamut_D65.png http://en.wikipedia.org/wiki/Door_handle

(last is arbitrary article that I thought unlikely to change; it probably doesn't matter)

Close browser, clear local cache and restart browser.

Now keep displaying the three pages one after another. I have three buttons that I keep clicking randomly. Sooner or later (it may take a little while) when you click on the first link you should see the distorted image in MV. If it seems not to be happening, restart the browser. Keep trying until you see the distorted image or get tired of trying. 86.171.42.22 01:44, 3 July 2014 (UTC)

I didn't realise
I could scroll that white stuff at the bottom of images in Media Viewer. Because with Media Viewer, where the page ends and this "floating presentation box" stuff begins is unclear. I was trying to turn it off. The first time I tried, it didn't work (no idea why). The second time, it worked.

I rather expect it will magically reset itself weekly.

This place is turning into Google, where they force arbitrary shit down people's throats every few months and call it improvement.

No tooltips in full screen mode available
On Mac OS X, Firefox 30.0

When I'm in full screen mode of Media Viewer, there are no tooltips available for any of the buttons. Is this on purpose? I think, there should be tooltips, too. Strange thing: I noticed, that if you hover the mouse over the 'end full screen mode' button, there actually does appear a tooltip for it, but only after clicking, the moment the mode has been finished, not before! The same happens, when you hover over the X in full sreen mode and then click. The only difference is, that in this case the old issue with the sticking tooltip occurs.

An addition regarding the already known bug with the ending of the MV full screen mode affecting the full screen Firefox browser window, which I can't find on Bugzilla: Firefox goes unexpectedly out of full screen mode not only on clicking the 'end full screen mode button' in MV, it also changes over to a smaller window, when clicking the X escape button of MV in full screen mode. I expect Firefox to stay in full screen mode for both ways of ending the MV full screen mode. --Miss-Sophie (talk) 14:23, 3 July 2014 (UTC) And another addition regarding this full screen bug. MV goes out of full screen mode also when clicking on one of the links from the panel, that appears, when moving the mouse in full screen mode, e. g. a link to the file this image has been derivated from or a link to the user who derivated this file, a link to the source file on Flickr or the author on Flickr. Examples: and  --Miss-Sophie (talk) 15:33, 6 July 2014 (UTC)


 * I'm not sure about the tooltips issue, that'll get looked into. For the second part, here's the bug that I filed for the fullscreen issue that you were looking for. Keegan (WMF) (talk) 20:11, 3 July 2014 (UTC)
 * We use tipsy which does not work in fullscreen mode (it appends the tooltip to the body instead of the fullscreened element). Tipsy is unmaintained and generally low quality; IMO trying to address its non-critical bugs is not the best use of development time. --Tgr (WMF) (talk) 20:55, 3 July 2014 (UTC)
 * tracks this FWIW. --Tgr (WMF) (talk) 22:46, 3 July 2014 (UTC)
 * Whoa, whoa, whoa. You guys are producing a new flagship feature, and included code from a known-dead and known-low-quality third-party project? Whose idea was that? Which manager approved it? And now when a user reports it failing to operate correctly, your response is to produce a bug report from 2012, indicating that you've collectively been aware of the issue for nearly two years, but then tell the user "trying to address its non-critical bugs is not the best use of development time"? Something has gone badly wrong here at a number of levels. —  Scott  •  talk  08:58, 4 July 2014 (UTC)
 * Tipsy is a module of the core software and used in several more places. Code reuse is usually the preferred strategy, so it's not that strange. This problem should raise the priority of either fixing it or replacing it. Just tossing on another implementation in our global mix is FAR more problematic., please watch out with bringing too much technobabble into the forum here, discussions around picking a library are usually better reserved for Bugzilla. A bug is a bug. TheDJ (talk) 10:18, 4 July 2014 (UTC)
 * I certainly understand and support the principle of code reuse... it was just the admission above that "Tipsy is unmaintained and generally low quality" that was startling. Well, it's good that this isn't something that's freshly entered the system. Even so, and I'm only the peanut gallery here but, that strikes me as quite a serious liability to be willingly left unaddressed, no? I also agree that responders to bug reports should refrain from dumping out developer-grade information on the unwary. —  Scott  •  talk  11:02, 4 July 2014 (UTC)

Another full screen issue: Media Viewer shuts down when opening the license (in a new tab)
Mac Os X, Firefox 30.0

I opened an image in a Wikipedia article with Media Viewer. If I am in full screen mode of MV, move the mouse and click on a Creative Commons license link (e. g. "CC BY 2.0") in the then appearing panel, the Creative Commons license page opens in a new tab, as expected. But when I click on and switch to the old tab, where I left Media Viewer and where the tool is supposed to still be active, Media Viewer has shut down and I'm back on the Wikipedia article page. This only happens in MV full screen mode. In the lightbox mode MV stays active in the old/first tab. --Miss-Sophie (talk) 14:57, 6 July 2014 (UTC)
 * Interesting. Thanks, Miss-Sophie. I'll file a bug for this later. Keegan (WMF) (talk) 00:15, 8 July 2014 (UTC)

This is, probably. The browser exits fullscreen mode when you open a new tab, which causes MediaViewer to exit. --Tgr (WMF) (talk) 00:29, 8 July 2014 (UTC)

If it ain't broke
but you nevertheless feel an overwhelming urge to replace it by something worse, you should at least have the courtesy to make it opt-in rather than the default. Maproom (talk) 21:35, 3 July 2014 (UTC)

Yet another user's opinion
I don't like it. These are my inner thoughts.


 * 1) It doesn't match the rest of wiki at all. In particular the links and tabs one expects to always be at the top of the screen are suddenly gone.
 * 2) My browser is getting awfully slow.
 * 3) Oh I see, this new media viewer thing isn't actually a page in itself, its a giant popup obscuring the entire article under it.
 * 4) There are no headers for many of the metadata fields. The first thing I read below the image is a name. Its not immediately clear if that name is the person who uploaded this file, or the creator of the work. I scroll down to see if theres something more verbose...
 * 5) Oh look, there's a "Created" date. Wait, is that when the original work was produced, or when it was added to wiki, or when it was added to commons?
 * 6) Whatever... so now I want to view the full size image. Now is that the double arrow button?
 * 7) Nope, that makes my browser pretend its the only program running.
 * Oh, its the picture frame button that I can't see now because I covered it with this floating thing.
 * 1) Good thing there's a square with outward pointing curvy arrow button that does the same thing at the cost of another click.
 * 2) But wait, I should check the edit history while I'm here to be sure the last editor didn't screw up the white balance... oh snap, thats not shown here.
 * Oh, if I click on this commons logo or the lovely text link I'm taken to a page that has everything I could ever want.
 * 1) Hmm, I could disable this media viewer thingy and see that nicely structured page without so much clicking.
 * 2) Odd, I disabled it in my preferences but it still comes up.
 * 3) OH! I have to disable it on every Wikimedia site individually...
 * 4) ...and always make sure I'm logged in, even if I'm just here reading...

Krushia (talk) 22:43, 3 July 2014 (UTC)

Why, oh why?
Who on earth decided for this total nonsense? This is the biggest encouragement to skip information concerning authorship and copyright status of any image, and "just proceed to steal it without caring about it". My compliments to the genius who created it. Great educational work --G.dallorto (talk) 13:09, 4 July 2014 (UTC)
 * Far more trouble than it's worth. Why do we have to learn something confusing? Just leave the old link there so we can go straight to it and let the newbies be confused. Carolmooredc (talk) 16:13, 4 July 2014 (UTC)

A missed opportunity!
My experience was similar to Kerushia above.

It's ... really a problem that preferences aren't universal across sites. There's no logical reason for that.

That seems like an actual essential bug that wants fixing. While the image viewer was not broken before -- A bit of an eyesore, but now replaced by a different type of soreness & problems.

Reading some of the other comments: Kevin is kind and totally right, about everything. 82firebird (talk) 15:27, 5 July 2014 (UTC)

Customizing Media Viewer with user JavaScript
I'm trying to make the image as displayed in Media Viewer a link to the file description page. By testing in my browser's console, I found that this code does that: $('.mw-mmv-image img').wrap($('', {href:$('.mw-mmv-repo').attr('href')})); But my (possible noob) question is: how do I execute that after Media Viewer has loaded? Is there some event I can bind this to? Darkweasel94 (talk) 14:21, 5 July 2014 (UTC)
 * I think that many people's question is why in God's name has this OBVIOUS feature, that was suggested weeks ago, that is intuitively expected, and that would take someone FIVE MINUTES to implement, not already been added? 86.167.124.250 19:19, 5 July 2014 (UTC)
 * There are two links to the file description page. The right symbol in the panel directly below the image and a link below the fold, after you have clicked on the down arrow, that expands the panel. --Miss-Sophie (talk) 20:58, 5 July 2014 (UTC)
 * Yes, but the OBVIOUS thing, that "everyone" would expect to work, or to do something useful, namely clicking on the image, does nothing. 86.167.124.250 22:04, 5 July 2014 (UTC)
 * Ah, I see. I was under the impression, the first poster above misses a link to the description page and that you agreed. Yes, I would expect to see a larger, zoomed in version on clicking on the image, if that is, what you are thinking of. One has to click on the 'original file' button on the right to get this, which appears as an indirection. --Miss-Sophie (talk) 23:05, 5 July 2014 (UTC)

Annotations
When using Media Viewer to view an annotated file, the annotations do not show up. An example is provided in the thumbnailed image, but more examples can be found here and here. 74.46.254.174 16:19, 5 July 2014 (UTC)
 * No regression testing for compatibility with major features? That is almost unbelievable, suggests many more uncaught bugs. Tonicmatic (talk) 05:03, 10 July 2014 (UTC)
 * Annotations are a customization made by the Commons community on top of the software. The MediaWiki developers do not support it. If you want it to be compatible with MMV, you will have to ask the volunteer community members to add support to it for MMV. TheDJ (talk) 13:03, 15 July 2014 (UTC)

RfC for Media Viewer
To read further feed back, other discussions and/or to leave a comment/vote about whether Media Viewer should be the default viewer please visit RfC for media viewer. -- Gwillhickers (talk)
 * Please note, this RfC is specific to the English Wikipedia. -Pete F (talk) 17:17, 5 July 2014 (UTC)

Request for Comment on Commons about Media Viewer
In addition to the RfC linked immediately above (on English Wikipedia), there is an ongoing RfC on Wikimedia Commons about the future of this software feature. Your thoughts welcome. -Pete F (talk) 17:17, 5 July 2014 (UTC)
 * Commons:Requests for comment/Media Viewer software feature

Can't give feedback in other languages (only English and German)
I read Wikipedia in several languages. When I am in the Media Viewer, only in the English and German WP is the feedback button available. Is it just on my laptop, something to do with IP or cookies? I tried several browsers and as I move a lot my IP also changes a lot. If users can't give feedback in other languages this will explain why the negative feedback is not increasing in French, Portuguese... and most languages other than English and German.--Michel le tigre (talk) 12:00, 6 July 2014 (UTC)
 * The survey feedback time concluded and the links were removed, but we did indeed run feedback in French, Catalan, Portuguese, Hungarian and Dutch as well as English and German. The English and German feedback links are being removed this week. Keegan (WMF) (talk) 00:12, 8 July 2014 (UTC)
 * Does this mean that you have enough feedback to recognize the error of your ways and stop inflicting this on us?

What am I missing here?
I don't get it.

If you wanted to "free" image rendering so that an image dynamically resizes to every User's own custom settings and available browser window-space, just stop forcing the thumb's inner container to a fixed width (220px default user pref setting + 2px padding) and have it inherit a width based on the outer container's width instead. No srcset= x2, x3 ,data-file-width crap required; just some css to outwit the wiki-markup's sloppy hold on IMG elements. You'd still be loading the image at it's actual dimensions at first either way, no?

Try it: open this page on Wikisource and resize your browser window, etc. all you can. The images should resize themselves on the fly - no scroll-bars ever. -- George Orwell III (talk) 13:12, 6 July 2014 (UTC)


 * Looks very cool ! I don't know the ins and outs of CSS well enough to fully understand what you did, but I like the results (as an option to consider). One question: do you think there's a way to have the software intelligently choose a cached version of the image that isn't enormously bigger than the screen? For instance, if you're viewing on a phone at 2g, you don't really need your browser loading an 8000px wide version of an image. -Pete F (talk) 18:54, 6 July 2014 (UTC)


 * I'm sure there is a way to do just that but it will take someone who knows what they are doing & knows the wiki-code. It's beyond my limited skill-set thats for sure. But I still don't understand what the point of MediaViewer is [outside of Commons]. I thought images were there to enhance or support the contributed content, not over-shadow it. -- George Orwell III (talk) 19:48, 6 July 2014 (UTC)


 * OK, well you've created a cool concept regardless. I hope it gets captured somewhere that it doesn't get lost entirely. On the more general point, I think you and I are in complete agreement -- I think the MV is a very big step backwards. -Pete F (talk) 06:31, 7 July 2014 (UTC)


 * What difference am I supposed to be seeing? I do not see anything obviously different. 86.167.125.52 11:58, 8 July 2014 (UTC)

Suggestion: Commons language settings should adapt (for IPs)
Let's say I'm not logged in and read a German Wikipedia article as an IP. Then I open an image from the article in Media Viewer and decide to there click on "More details" to go to the file description Commons page. While the surface is in German in Media Viewer, as well as the integrated description from Commons (if there is any available), as soon as I enter the Commons page, everything is in English by default (menues, LICENSE template and other template texts etc.). I can change this setting on the Commons page, since they offer me a link above the image and also in the side bar menue to see the page in German, but when I "return" in my browser to Media Viewer, go to the next image in the slide show and decide again, I want to see more details on Commons also for this picture (or I decide I want to see the details for the same image again; this applies to any image from the slide show), I'm presented the Commons page in English again. That's annoying.

I would like the Commons language settings to
 * adapt to the language of the Wikpedia site the reader is coming from (if the clicked on image is in a German Wikipedia article, the Commons page should use the German language settings by default, without having to select them manually)
 * be kept (or another language setting, if a reader actually changed this default language for some reason, for example switched from German to English) for the following images from the slide show. So that, when I click "return" in my browser and then click on the Commons link of another image from the MV slide show, I don't have to again choose the language setting I already had activated before.

--Miss-Sophie (talk) 09:17, 8 July 2014 (UTC)

Boycott
It pains me to do this, but there seems to be no other way forward. So long as this bag of misfeatures known as Media Viewer continues to be the default for non-logged-in users of Wikipedia, I will not contribute to, edit, or otherwise support Wikipedia. --128.104.68.125 18:43, 8 July 2014 (UTC)

Likewise, an article-smothering javascript overlay belongs in some earlier version of Facebook or Flickr or other abominable social media, and not what's supposed to be - or at least once was - a serious Community-consensus-driven online encyclopedia. Mic drop.--144.92.71.49 00:09, 9 July 2014 (UTC)


 * me three! fck this sh!t! Media Viewer is crap and WMF's abominable implementation of it, their disregard for enWP consensus and bullying of admins has cost them my support. C-ya! Jdanek007 (talk) 07:25, 18 July 2014 (UTC)

Update on RFCs
The English Wikipedia's "Request for Comment" (RfC) on the continued use of Media Viewer was closed today, with a consensus that MV should be disabled by default for both logged-in and non-logged-in viewers. The consensus has not yet (as of 9 July) been implemented on the site.
 * RfC for Media Viewer

On Wikimedia Commons, there is an ongoing RfC on the same topic. Your thoughts welcome. That RfC is expected to run through 27 July. -Pete F (talk) 17:04, 9 July 2014 (UTC)
 * Commons:Requests for comment/Media Viewer software feature

Feedback button
At the right bottom of the Media Viewer there is a "use this file" and a "more details at Wikimedia Commons" button. At the left of them there used to be a feedback button. Please re-add it? :-)

--Gryllida 04:27, 10 July 2014 (UTC)
 * 2nded, even if the feedback button just directs people to a subpage of this page. Tonicmatic (talk) 05:05, 10 July 2014 (UTC)
 * There's still a link to this talk page below the fold. After the first month of being enabled on any site, we felt free to remove the link to the SurveyMonkey surveys we were running. If you have things to say, we're still listening :) --MarkTraceur (talk) 05:42, 10 July 2014 (UTC)

No better
I've just been invited to look at the latest version of MediaViewer and add a comment here. I don't see any improvement. If a designer had thought "How do people use and want to use Commons images", that designer would never have got into this mess.

If the screen provided a complete filename that could be copied-and-pasted, I think editors might have learned to live with the other nuisances. But it didn't, and it still doesn't, even now. So it's a timewaster. So disable it. Andrew Dalby (talk) 09:18, 10 July 2014 (UTC)

Leave the reuse options for a file on the file description page
I see, you have tried to improve the "Use this file" tool. But I really think you should leave the options for using a file, with the exception of maybe the "share this link" option, on the file description page. Make the "Use this file" options in MV for the cases of embedding and downloading links to the file description page (opening in a new tab). The use of a file, especially as soon as it means dealing with licenses and conditions for using a downloaded image or embedding an image on a webpage, has nothing to do anymore with the immersive viewing experience, you proclaim to be the goal of Media Viewer. When I think about using a file and then download/embed/share it, I'm not viewing any longer. The "share this link" in MV doesn't lead to missuse, though (as far as I can tell), and maybe somebody wants to link to the image (or the slideshow) presented in Media Viewer, so I'm okay with having the option for it there. For embedding the file on a webpage outside Wiki, a link to the image in Media Viewer might also sometimes be wanted, but this option could be included in the "embed" tool on the file description page. If one thinks about it, sharing a link is not using a file (its image content) anyway, so I think two separated buttons could be a possibility: a) share this link; b) use this file (for downloading and embedding), with b) linking to the file description page. In my opinion you should really focus on improving that viewing experience (it's supposed to be a Media VIEWER) and not try to replace the Wikimedia Commons pages. Users get so many more necessary information about the use of a file on the Wikimedia Commons file description page:
 * at the top of or next to an image a link that leads to a page with information about how to reuse a file from Wiki in general, in different languages like or.
 * templates with summarized information about the license conditions and important restrictions for the use in certain countries like template:Cc-by-sa-3.0 or template:PD-US-no notice. Plus all this in a language they understand (as soon as the Commons language settings are accordingly, see also my comment/suggestion about this topic above), because not everybody understands English! Non-English speakers don't understand, what this linked Creative Commons license text in English on creativecommons.org wants to tell them. (By the way, a reader, who has never before heard about Creative Commons licenses, might not even assume, that these cryptic characters like CC BY-SA 2.0 under an image in MV have to do anything with a license or with using the file at all.) Opposed to this, the file description page on Commons gives a template with summarized information in their respective languages (in the license section). The "View terms" link in MV often doesn't help, since MV does not show a license template unless it is included in the permission parameter of template:information on the Commons page, which is not always the case. The documentation for template:information even recommends to leave this parameter blank in a certain, very possible case: "License and other usage limitations and warnings. Due to the size of many license templates they are often placed in a separate section below template. In such a case please leave this field blank." In this example the reader is left with the cryptic letters "CC-BY-SA" as terms in MV, which is also not better than a blank field. (And the "View terms" label does not even give a hint, that these "terms" are related to using a file. Terms for what?)
 * templates that warn the reader to respect the personality rights of pictured persons
 * certain further information about the content of a file or related to its content, which Media Viewer does not embed as a description but which might be of importance for somebody, who wants to use the file. For example the information in the template is largely not embedded in MV. It might well be, a user is interested in using the there given information regarding the artist, painting technique, location of the artwork etc, when reusing an image (exmple). In the case of this template the reader often gets the information, there was no description available. This actually means, no description in a description parameter, but there exists lots of descriptive information in the template. I don't think the reader (and possible user) necessarily expects there to be information about the artwork somewhere else, when he's told there is none. In general one should provide the user, who wants to reuse a file, with all available information about a file before, so he can select, which information he wants to use, and judge, which information is relevant for his purpose. MV does invite the user to download/share/embedd without having seen this information on Commons.

If you think, it's necessary to improve the tools for using (downloading and embedding) a file, rather work on the tools next to a file on the Commons page. Maybe integrate some of your ideas for the MV "use this file" tool there. Personally I like the icons and labels on Wikimedia Commons (Download, Use this file on the web, Use this file on a wiki, Email a link to this file, Information about reusing), which are clear and prominent. But don't try by any means to skip the Commons page for the processes of downloading and embedding a file. Many thoughts went into these Commons pages and the templates, which are supposed to hint at certain conditions for using a file. It's obvious and understandable, that users, who think these hints are important, are against Media Viewer in its current concept, when it shows a tendency to block the access to these hints like a kind of 'wall' (yes, the wall has a door, but readers are not obliged to open it, before they use a file). And, to repeat my opinion again, downloading/embedding (and sharing) has nothing to do with an "immersive viewing experience". It is on the contrary a rather dry, rational act, since it means dealing with license stuff / code / urls etc. So the MV experience should end (or be interrupted), the moment a user decides to download or embed a file. To me it looks like Media Viewer is loosing its concept and course here, at the cost of its potential, which would mean to really concentrate on the viewing options.

--Miss-Sophie (talk) 13:59, 10 July 2014 (UTC)

Focus on the viewing options
I think Media Viewer has some potential and things I like. I like, that I can look at all images from an article in larger size in a slideshow. This is especially interesting for images that form a sequence, like images that illustrate a historical development, a progress or a storyline, but also associatively to get a coherent impression of all the related images regarding the same article subject. Several pictures can become a whole that makes a different impact than just a single picture. Though you can look at all the images together in the article, the thumbnails are often too small to reveal interesting/informative details and when I go to Commons to look at a larger version and then go back to the article to there choose the next image, this is always an interrupted experience. It might work in cases, where you read a part of the article, then click on an accompanying image, go back, read on and then click on the next image, but not, if you want to look at the images one after another, to see them as a whole. Also the images on Commons aren't presented well as pictures. If I open a Commons image page, the first things that catch my eye are the file name, the tool menue for reuse and an often only half visible image with the lower half missing, so that I have to scroll down to fully view it (and even then it's not centered and surrounded by other information). Or I have to click on a certain resolution link or the image to see it presented well. I also like the full screen option in MV. So these are the nice things.

But in my opinion the tool doesn't use its potential well and looses its course by trying to be a replacement of the Commons page. Regarding the use of MV on Wikipedia pages, MV has (or could have) one important advantage over viewing the images from an article on Commons: It can (or could) show the larger sized images in context of the article, as opposed to independent Commons file pages, which also show larger images, but of which each is a separated unit without direct relation to the article. One means to reach this is the already mentioned slideshow, which merges the images from an article. Another important ingredient is the image caption, which links an image with the article text. Mind you, the caption is not part of the file description page but just part of the article, and if MV shows this caption together with a larger image, it does something Commons can't do! (Commons file descriptions may differ from the caption). But here MV disappoints, for it hides this caption and gives the not article relevant file name a prominent role instead. MV also sadly doesn't display the title of the article, which would help to not forget, which article these images you are browsing through belong to, and would work as a visible connecting 'frame'. The help page and advertising for MV always stress, that MV shows the file on the same page as the clicked on image, on the article page. My issue with this claim is, that it doesn't really feel like being in the article because of the things I have just stated. There might be other reasons as well, like MV completely covering the article page.

If one wants to develop the image-article connection in MV even further, I think the following would be really cool and upvalue MV a lot for the use on a Wikipedia page: One could add a "quote function". This would allow to add (in a new parameter for the file template?) a 'quote' of limited length from the running text of the article to an image, in addition to the caption. The quote would be displayed together with the image in MV and is supposed to contain an excerpt from the article, that is directly illustrated by / related to the image, if such a text passage exists. If not, no quote will be added. (As an editor I try to not randomly choose and place images in an article but in the context of the content, so the running text might contain information related to the image, that is not in the caption, also because I try to avoid too long captions, when I need space for more images one below the other.) It doesn't have to be a real quote but can for practical reasons also be a modified quote or kind of summary of the relevant passage. Maybe one could make room for this quote to the left of the image in MV (in a column or window with scalable width and a scroll bar?), with an option to deactivate or activate the column / the displaying of the quote. The size of images (especially in a landscape format) would then have to be able to adapt: An image might have to become smaller to be still completely displayed, when the quote function is active, since the column needs room. If the column width was scalable by the user, the user could decide individually and from image to image (which have different formats), how much room he wants to leave for the column-window, he reads and scrolls the text in, and how much for the image, he simultaneously views in context of this text. (One user on this discussion page developed some code for size adapting images in browser windows of different sizes, see, which shows what I'm thinking of here regarding adapting image sizes). I'm sorry, if I don't use the correct technical terms here, but I'm no webdesigner and only a user who suggests, what kind of tool she would like. I hope, it's comprehensible. :-)

And of course MV, as a tool that wants to improve the viewing experience, should include a zoom function and other visual tools (some people here mentioned the annotations, for example). In my opinion you should focus on this and all the above, not on replacing the Commons page. I would like Media Viewer to be an additional tool, I can choose to use in a certain case, not a replacement and default tool for every user. P. S.: For viewing images on Wikimedia Commons the tool might need different features, I only referred to MV on Wikipedia.


 * Media Viewer: View an image from the article in larger size and in context of other images from the the article (slideshow), as well as in context of the article text (caption and quote) - plus show the link to and some information from Commons (one has to carefully think about, which one make sense here), like the author attribution (also other possibly obligatory things dictated by license conditions) and below the fold the file description. But leave the license details together with the download and embed options on the file description page (see my comments in the paragraph above); only name the license, make the "View terms" label clearer (e. g. : "View terms for file use") and link it to the file description page.
 * File description page: Show all information regarding the file, ways and conditions to use it, ways to edit and discuss it, other functions

--Miss-Sophie (talk) 13:59, 10 July 2014 (UTC)

Response to the Media Viewer RfC on English Wikipedia
Hi folks. We wanted to let you know that we just responded to the Media Viewer RfC on English Wikipedia, which closed yesterday.

Here is what we posted on that discussion page:

"Thanks for sharing your comments about Media Viewer.

The Wikimedia Foundation appreciates feedback about features we develop, and we respectfully acknowledge this group’s proposal to disable Media Viewer on the English Wikipedia.

After carefully reviewing this proposal, we recommend that Media Viewer remain enabled on the English Wikipedia, for a number of reasons:
 * We believe that an RfC of this type is not representative of our much wider user base.
 * Readers in particular are not represented at all in this kind of discussion, and they are a key user group for this feature.
 * Media Viewer was developed with extensive community guidance from a more diverse user base for over a year, through beta testing, online discussions, usability studies and other feedback channels.

Media Viewer provides important benefits to users:
 * Larger images: this tool shows images more prominently, with a single click.
 * Faster image load: files are shown twice as fast as the previous solution, since you don’t have to go to a separate page.
 * Easier browsing: more users click on the next and previous buttons than on thumbnails, increasing overall image views.
 * Better use of space: less scrolling is required to find information, due to a more compact layout.

Other factors were considered in reaching this decision:
 * Media Viewer is a central part of our strategy and vision to modernize our multimedia software and user experience.
 * As recognized by the Wikipedia:Consensus policy, software development is not subject to the same policies which bind English Wikipedia editors.
 * Users who do not want this feature can easily turn it off, and only a small percentage of English Wikipedia users have chosen to opt out so far. We encourage users who don't like Media Viewer to disable it.

Overall, we believe that Media Viewer’s benefits far outweigh its downsides. And while the feature still has some limitations, we have collectively identified practical ways to improve it over time.

We deeply appreciate your help in making this tool better and we hope that more users will come to value this feature as a result. Thank you so much for your feedback. Fabrice Florin (WMF) (talk) 17:52, 10 July 2014 (UTC)"

Comments
so you will understand it is shit? Sorry, I do not like to be rude, but if this is your choice we have to.--87.13.242.13 22:18, 10 July 2014 (UTC)
 * Do we have to rub your face in it?

You have just convinced me to stop editing Wikipedia and made me give up any idea of taking up a Commons account. There's no point in my investing time and effort to try to produce a quality encyclopedia and media repository if Wikimedia can foist unwanted software on the Wiki projects (against their editors' expressed consensus) and ruin the user experience. English Wikipedia has been wondering why occasional editors have been leaving - we're simply not prepared to put up with Wikimedia's interference any more. 86.129.165.210 16:35, 11 July 2014 (UTC)

I like…
I like that:
 * Extension:CommonsMetadata was developed - it will ease migration to Wikidata and is useful for third parties fetching attribution information.
 * Improvements to OOjs UI (also thanks to the VE team) - makes building user interfaces easier.
 * Improvements to image scaling were made and there are even more good considerations - this what I call core support.
 * Community engagement by hangouts and openness during development -- a "disable link" has been installed - I like that and how the MV team addressed concerns about feature. Nearly all feedback got at least a thought and could be discussed.
 * A tool was created that is truly useful to visitors who only want to watch the image - Personal experience with Wikipedia visitors has shown that the tool is well-accepted. Whether it was really required -- I think it doesn't make a huge difference, it just looks nicer.

The issue is that:
 * Photographers who were used to be able to design their own big fat authorship templates and put all kind of **** on the file description pages, are dissatisfied that the reader will most likely not see all this **** now.
 * People working with files do not need it. It's a nuisance for them.
 * … and a lot more listed above and in the RfCs.

I'd also like to take the opportunity to thank for various improvements such as adding the revision timestamps of files to the log, the new gallery design and for Special:AllMyUploads. -- Rillke (talk) 22:10, 10 July 2014 (UTC)

I wonder though, what's the ratio of photographers who are dissatisfied because MediaViewer does not display their combined GFDL-CC-BY-SA-CC-BY-NC licence with custom attribution line, to those who have been dissatisfied until now because their work was shown to the readers in half a postcard size? --Tgr (WMF) (talk) 01:31, 12 July 2014 (UTC)

Need to change the metadata class name
Two reasons: I suggest  or something in the line of   (source). --TMg 22:30, 10 July 2014 (UTC)
 * 1) Icons are not "metadata". Metadata is "data about data", e.g. the author of an image. Icons are, well, icons. An optional graphical representation of the actual (text) content.
 * 2) The German community uses this class name since at least 2007 for exactly what it says: metadata. Metadata (may it be an infobox row or a whole template) is hidden by default and shown by enabling a tiny CSS gadget.


 * We support  as an alternative. --Tgr (WMF) (talk) 21:33, 11 July 2014 (UTC)
 * Based on the description I found I had the impression these classes serve very different purposes. Images marked with  don't open the viewer on click but are still part of the slideshow, right? Images marked with   are excluded from the slideshow. That's what I expected, simply because there are two very different explanations for these classes. If they are identical, why not explain they are identical? Can we start "misusing"   or will one change it's behavior some day? --TMg 10:19, 13 July 2014 (UTC)
 * The definitions are based on the English Wikipedia. .metadata in English Wikipedia is a class given to anything that is 'metadata' to the content proper (so stuff NOT part of the article, yet defined inside the article). It was used to strip maintenance templates and other community annotations and utilities from print, books, PDF and mobile views. It is usually NOT put on images, but on the div/table's surrounding the image. noviewer is more specific to MMV however, much as noprint is more specific to the print medium. TheDJ (talk)
 * The behavior of  and   is fully identical (if it's not, that is a bug). I can't think of a good use case for showing something in the slideshow but not showing on click. The FAQ seems to suggest the same to me, but then I am probably not the best person to determine whether the text is confusing for someone not familiar with MediaViewer. Suggestions for better phrasings are always welcome. --Tgr (WMF) (talk) 03:17, 14 July 2014 (UTC)

Italic text in the description is displayed as plain text
First, thanks for fixing the problem with the sticking tooltip of the X-button (in Firefox)! The ugly white 'spot' on the left is still there, though. And it's also better without the tooltips on the back and forward buttons.

I noticed, that MV doesn't display italic text from the description page, like in. Instead it shows plain text. I wrote the book title in the description in italic letters and it looks very confusing without. I don't know, if there are maybe more issues regarding formatted text in MV? --Miss-Sophie (talk) 11:48, 11 July 2014 (UTC)

Could you make a screenshot of the white spot? It's hard to guess what could be the cause without seeing.

We strip all formatting from the description except for links; it tends to contain tables and other horrible things which would mess up any interface trying to include it. Making an exception for italic/bold seems harmless enough, though; added for that. --Tgr (WMF) (talk) 21:25, 11 July 2014 (UTC)


 * @Tgr (WMF), thanks for writing the report about italic/bold text. I hope, these styles will be added. Regarding the white spot, I thought the problem was clear by now, since you even commented on the reports of it in a way, that made me assume, the issue had been reproduced. Others and I explained it here here. One IP user made a screenshot and uploaded it. The white spot/object is marked with a red arrow in the screenshot. While the tooltip, which I thought could be related to the spot, now luckily doesn't stick on the search field anymore, the spot is still an irritating object on the black background of MV. --Miss-Sophie (talk) 22:22, 11 July 2014 (UTC)
 * Thanks! I thought that was fixed with, but apparently not. The spot is clearly the edge of a tooltip though. Opened . --Tgr (WMF) (talk) 22:34, 11 July 2014 (UTC)

My two cents
Sorry to say, but the media viewer in its current version is not useful - not to say aweful... I don't know if it's my settings fault or if the system is just bad - but actually I don't care though; because in my opinion, it should work for everyone. Ok, so what's my problem? Well,

1. the media viewer obviously opens on a new site. That's shit, because if you wanna look at several images (always after closing the previous pic by clicking the "X"-button) and then have to go back to the article you have read before, you have to go back through like dozens of picture previews to get there. So, please: Let the viewer open in a pop-up or something - that also works e.g. on Facebook; and even there without Java!

2. there are some bugs, which are really annoying. For example, when I want to close the viewer, sometimes the screen just turns black and i have to reload the page - which is kinda shit. I can't tell you the reason, but it'd be great if you fix this..

3. it just doesn't look better then the old viewer! Honestly, a media viewer is basically a great idea. But: I don't really get the advantages of this one! With the old system (which worked btw) you had categories, licences, download options and all other information in front of you. Now, there's just this huge picture and you can't even copy its file-name to place it into an article!

Because of that I deactivated this system in my settings. But I hope, you'll improve these bugs soon, so i can work with it properly :-) Thanks and greetings, 111Alleskönner (talk) 18:06, 11 July 2014 (UTC)
 * Thanks for taking the time. Point one is tricky and is being actively discussed on bugzilla if you're interested in following along. For point two, do let us know under what circumstance this happens, and what browser/operation system combo you're using. Point three, well, there's nothing to say there really. I hope you like future improvements. Keegan (WMF) (talk) 20:30, 11 July 2014 (UTC)
 * -- I brought "point one" to WMF's attention more than two weeks ago. Anyway, I came here wondering what happen to the feedback link that used to be on MV. -- Gwillhickers (talk) 21:23, 12 July 2014 (UTC)
 * if you read that bug report that I link to, which I gave you when you did bring this up two weeks ago, you'll see that it's been under discussion since March. I encourage you to read the bug report to get an understanding of the complexity of working with browser histories. The link to the survey, the bullhorn, has been removed as the survey ended last week. Keegan (WMF) (talk) 20:37, 13 July 2014 (UTC)
 * As we have had an ongoing 'bug report' here on the feedback page and on two RfC's I really don't need to go anywhere else to know, and as an end-user/editor I'm not really interested in the complexities from a programming perspective. The prior viewing system had none of these faults. Hopefully some day this idea will get through to you guys. An all around 'fix' would be restoring Wikipedia to where it was before, but since too much time and money has been committed to this project, I can understand, sort of, why that's not in the project team's particular game plan. In any case, there have been criticisms from MV proponents that the feedback page and the RfC did not have enough user input so I would recommend that you restore the feedback link. Without it new and returning users won't know about where to go to voice opinions and they won't learn about the RfC at Commons and the current Arb'Com request. -- Gwillhickers (talk) 16:08, 14 July 2014 (UTC)

What is the resolution?
I remember I really liked that I could clearly see which resolution a certain image had. Now, this is not possible with this new thing going on. --90.226.181.130 18:40, 11 July 2014 (UTC)
 * You can get to the original file page with one click in Media Viewer by clicking on the local file icon or the Commons icon in the bottom right of the screen; or you can control/command click on the image to open up the file page in a new tab. I hope you enjoy other features in Media Viewer; for example you can click the download button and choose which image resolution size you'd like to download. Keegan (WMF) (talk) 20:34, 11 July 2014 (UTC)

The other way is to click on the "Use this file" button, and select the "Download tab" in the dialog which appears (if you are using it for the first time, this will be the default). The resolution will be displayed on the main button. --Tgr (WMF) (talk) 21:19, 11 July 2014 (UTC)

Improving licence information
The Media Viewer makes good progress, I like the "You need to attribute the author"-Button. I have two improvement suggestions: Keep on with the good work! -- MichaelSchoenitzer (talk) 23:15, 12 July 2014 (UTC)
 * Please do NOT view the "You need to attribute the author"-button for works in the public domain!
 * Add an little i-Icon (like info.svg) beside the license name (next to the imagename) witch, when clicked opens a little pop-up with a short description of the license – similar to the CC-deed.
 * Great, thanks for the input and thoughts about licensing linking. These are great ideas that the team can look into. Keegan (WMF) (talk) 03:33, 14 July 2014 (UTC)

Font size awfully small - and can disable "link" be more visible?
When looking at a few images tonight, I noticed that the font size in the "below the fold" section is awfully small; in fact, it looks smaller to me than the last time I looked at it. It was difficult for my more "mature" eyes to see.

I'm glad that the page has a built-in disable link - good for you for adding it. But perhaps it could be more prominent? Combined with the small font size, and the fact that most people won't look below the fold, it's not quite as accessible as it could be.

Thanks Risker (talk) 08:32, 13 July 2014 (UTC)
 * Thanks, Risker. There's an active discussion about reworking the disable/enable option that I hope we see in development in the next couple of weeks. As for the font size, I'll have to differ that answer. Keegan (WMF) (talk) 03:35, 14 July 2014 (UTC)

Categories
Why does the Media Viewer still show hidden categories when there are un-dispalyed normal categories, which the general viewing public would find much more useful. Also the category icon's meaning is not obvious. I don't think general viewers have any idea what the list of words next to it means. Adding the word "Categories:" would be much more useful. The other two icons in that area are followed by explanatory words ("Uploaded by", "Created").--ArnoldReinhold (talk) 10:34, 13 July 2014 (UTC)
 * I agree. I tried to recognize, what the category icon depicts, but I'm not sure. Is it an envelope? And if so, I don't understand, why? Some users might guess, what these words mean, but it could be clearer. There should be an option to see all non-hidden categories, while hidden categories should not be shown at all. --Miss-Sophie (talk) 10:59, 14 July 2014 (UTC)
 * This is a known issue. It's a problem that propagates from core to API to MMV, so it's not entirely trivial to solve because of that, but it is fixable. TheDJ (talk) 11:33, 15 July 2014 (UTC)
 * Okay. But while we're at it: What does the icon depict? --Miss-Sophie (talk) 13:39, 15 July 2014 (UTC)
 * Thanks, TheDJ. The icon is a curation label/tag, like what one would find in an antique shop or a museum. Its origins come from the Page Curation toolset (ref: commons:File:Curation_Bar_Icon_Tag.png). Keegan (WMF) (talk) 23:25, 15 July 2014 (UTC)
 * Thanks for your explanation. I didn't recognize it as a tag. But how does one depict a thing like a tag in a recognizable way for such a tiny icon anyway? After some Google research I found, a 'tag' icon is not uncommon for the meaning of "category". Personally I would have expected it to be some kind of container, a folder maybe, because the images are in a category. --Miss-Sophie (talk) 10:29, 16 July 2014 (UTC)

Coincidental ?
Looking at the software used by the LA Times to navigate readers through galleries (article w. gallery), it looks quite compareable to the MV (background, nav-arrows left & right, fullscreen symbol). Could that be an issue? Alexpl (talk) 12:23, 14 July 2014 (UTC)
 * I don't think it's an issue, but thank you very much for pointing it out. Keegan (WMF) (talk) 23:26, 15 July 2014 (UTC)

Requests for Arbitration
( copied from Commons ) Statements regarding the fate of Media Viewer and the role assumed by various individuals on the WFM project team have been and continue to be presented to the Arbitration Committee. -- Gwillhickers 02:25, 13 July 2014 (UTC)
 * Note, that is the English Wikipedia's ArbCom. -Pete F 04:06, 14 July 2014 (UTC)

High density displays
Will MV address issues of high pixel density displays? I get that for the viewer itself the images may be large enough but NFC is limited to 300px and certainly images on article pages are rather small these days. Saffron Blaze (talk) 22:22, 14 July 2014 (UTC)

Saffron Blaze, can you clarify what issues you mean? MediaViewer does take pixel density into account when selecting the image size to request from the server. --Tgr (WMF) (talk) 20:51, 17 July 2014 (UTC)

Loading bar
Does there have to be a loading bar every time an image doesn't appear at once? It's not exactly beautiful and I find it superfluous for cases, where it takes just 1 or 2 seconds to load. I think, if the picture looks blurry for 2 seconds or less, this won't irritate me so much, that I need a sign of progress. The bar is especially annoying in situations, where you click fast to maybe browse through a few images of a very long slideshow, you don't find that interesting. Meaning, I click the 'forward' button, the moment an image has just become sharp or even before it has been loaded properly and is still blurry, to get to the more intersting ones; and this perhaps several times for several uninteresting images. In these cases I click on the forward button about once every second or 1.5 seconds, and for all images I want to quickly skip, this blue bar starts to run from the left to the right of my screen, gets interrupted on clicking 'forward' and starts again with the next image. Because the quick clicks seem to overburden MV somehow, so it shows blurry images and the loading bar pretty regularily for every quickly skipped image (which doesn't happen, when I click a little more slowly). I tested this with the long slideshow of all images on this page: Lightbox demo.

Could you not make the loading bar only appear, when it takes longer than 2 seconds (or 1.5? You might determine the duration of a hold-up, when users start to wonder, if the image is actually that blurry and will stay like that)? --Miss-Sophie (talk) 12:55, 15 July 2014 (UTC)

I think the ultimate problem here is the lack of a better way to navigate between images, without triggering a preloading of them. The plan is to solve this with a navigation strip, although that won't happen anytime soon. --Tgr (WMF) (talk) 21:01, 17 July 2014 (UTC)

Loading in the "Category Slideshow" tool from Wikimedia Commons
I had only used the already existing tool for viewing a category slideshow on Wikimedia Commons a few times. But now I did deliberately to further test Media Viewer, which means I compared the slideshow function of both tools. I used this category:. While MV is clearly presenting the image better (larger images, not sticking them on the under edge of the screen, 'full screen' mode), I have to say, I prefer the process of loading the images in the "Category slideshow" tool. I'm no computer scientist, but I got the impression, the Commons tool maybe preloads all images to be shown, while MV always only loads the current one? Whatever the reason, I like, that I can browse through the pictures even quickly with hardly any hold-up, where the tool is loading an image (if you click really fast it happens a few times). In MV you get the ugly loading bar and blurry images for the whole slideshow, when clicking quickly, and for some images also, when clicking slowly. I should add, that it takes slightly longer in the Commons tool, until the first image appears (in my example 5 seconds vs 3 seconds in MV (until it's sharp)), so MV is a bit better in this respect. And I noticed, the idea of the blurry image, that appears in MV during the loading process, though ugly, is not a bad thing in general. For with the Commons tool it happens, that you accidentally skip an image, that is still loading, because you don't see it (it's all black screen, until it has been loaded). But I would like to see the occurrence of the loading bar and blurry images being reduced to a minimum by maybe adopting the loading process from the Commons tool. What do you think? Or is there a certain reason, why you didn't do it this way? Not possible? --Miss-Sophie (talk) 10:20, 17 July 2014 (UTC)
 * It's because the size that the Commons tool uses is much more likely to already exist on the server and thus not require on the fly thumbnail generation on the server side. This is a known issue that is being worked on, but it has quite big hardware impact, so it will take quite some time to fix. TheDJ (talk) 13:00, 17 July 2014 (UTC)
 * Commons gadget does a) pre-fetch b) uses common thumbnail sizes. The loading bar in MV is indeed distracting. -- Rillke (talk) 22:11, 18 July 2014 (UTC)

Truncating the description or author
When you truncate either the description or the author, please can you include a clickable "... (more)" that expands just that field. As a model, I'm imagining what Facebook do when they truncate comments. --99of9 (talk) 02:05, 16 July 2014 (UTC)


 * Hi 99of9. Thanks for this helpful suggestion! I am happy to say that we are working on a new feature that will let you expand truncated text fields, as described in this development ticket. If all goes well, this feature should be deployed in the next few days. Hope this helps :) Fabrice Florin (WMF) (talk) 21:01, 16 July 2014 (UTC)


 * Ok, glad you're on to it. --99of9 (talk) 07:23, 18 July 2014 (UTC)

Large files, e.g., Anselmus van Hulle, not shown at highest resolution
Media viewer (QuickTime plugin) does not display large images at full resolution, click at the header. Regards, Hansmuller (talk) 14:46, 17 July 2014 (UTC)

We currently fall back to the browser for full-size display, and browsers generally don't display TIFF images. --Tgr (WMF) (talk) 20:48, 17 July 2014 (UTC)

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

Make Media Viewer image clickable
Normally, I could open the description in new tab with middle-click, and/or open image in new tab with middle-click from the description.

Now, I can open description in new tab, but after opening Media Viewer in the single tab, I can no longer open image in new tab at all. The "open image" icon cannot be middle-clicked and is far too small compared with normal behavior.

--50.136.155.136 23:14, 17 July 2014 (UTC)

Show categories
Media view is ok, but it would be great if it couls show in the image page the categories link, to surf quickly in case you opened it for mistake. Would be very appreciated by advancer users (like me, uh) --Sailko (talk) 10:54, 18 July 2014 (UTC)

Update: Quick access to enable/disable, opt-in/opt-out metrics




Hi everyone. We appreciate the ongoing conversation about Media Viewer, and we’ve been discussing practical ways to address concerns and improve metrics used to establish the default configuration for this tool.

With that in mind, we would like to propose a new feature which we think can address many of the issues you reported here: the Viewing Options Panel would make it much easier to disable (or enable) Media Viewer. This feature would prominently display a ‘cog’ icon at the top right corner of the screen, as shown in the thumbnails to the right — and in this rough prototype. Clicking on that icon would display a settings panel with two viewing options:
 * 'View quickly’ — enable Media Viewer (or keep it enabled)
 * 'View all the details’ — disable Media Viewer and show the file page instead

The Viewing Options Panel would let users quickly select the mode that works best for them, switching back and forth to compare them. (Note that Media Viewer already includes a “Disable/Enable’ link, but it is located below the fold and can be hard to find; this new feature would bring it above the fold, where everyone can see it.)

This would make it easier for users to decide for themselves if they want Media Viewer enabled or not. It would also enable us to collect better user data on whether or not this tool is useful -- which can inform our discussions about default state for different user groups. To that end, we plan to track the number of enable and disable events by user group on this existing opt-in/out dashboard (this dashboard now tracks clicks on the “Disable/Enable’ links, which would be replaced by the Viewing Options Panel).

What do you think of this new feature? Does it seem worth developing at this time? Any suggestions for improvement?

We are also considering a controlled experiment on the English Wikipedia. We invite you to comment on that separate proposal on its research page.

Thanks again for taking the time to share your thoughts and feedback on Media Viewer. Your comments are really helpful to us, and we look forward to working with you in coming days to find a resolution to your concerns. To be continued, Fabrice Florin (WMF) (talk) 16:31, 18 July 2014 (UTC)


 * Formally, there is consensus on English Wikipedia that this tool should not be enabled by default. Informally, there appears to be strong consensus on Wikimedia Commons to that effect, and similar sentiments expressed strongly on this discussion page. There is also relevant discussion emerging on the German Wikipedia. Until there is some action on the part of WMF to reduce the intrusion of this inadequate software into the daily experience of many millions of readers, I have no interest in discussing small tweaks to the software. If and when it is changed to "opt-in," I will be happy to discuss improvements. -Pete F (talk) 17:41, 18 July 2014 (UTC)


 * I agree with Peter F. The consensus for "opt-in" is strong. I used to send links to Wikipedia pages to people who are not very computer literate. Now they are confused by the Media Viewer intrusion and are not able to read the page and look at full size images as they normally did in their browser. You guys at WMF are living in an ivory tower and are not aware of the real Internet world. Users and contributors will thank you when you make this thing opt-in and you will not lose face in doing that.--Michel le tigre (talk) 18:57, 18 July 2014 (UTC)


 * This would be more intuitive to visitors. Right now they possibly do not know what Media Viewer is. With the layout graphics, it more becomes obvious what MediaViewer is. I can't assess whether it's worth though; if it fits your development strategy, implement it. -- Rillke (talk) 22:05, 18 July 2014 (UTC)