Extension talk:Media Viewer/About

The link to the file page on Commons is very well hidden! :)
The share button is a non-obvious place to place the link to the Commons page. We clicked everywhere before finding the link hidden there. And even after clicking the share button, we thought this link was not the link to the Commons page, just the raw jpg file. And we were also dumbfounded at first to not find a clickable link. Only after I copy-pasted the link I had the idea that the chain icon could be clickable... Very frustrating experience to search everywhere for a link that was just weeks before the direct link from the image.

All in all, the feature is maybe in need of user testing along the usual paths of users (my friends is used to go to a WP page, identify interesting images and then go and download them on Commons)
 * I see. Thanks for sharing what frustrated you about the experience. The design is not 100% final, so we'll see what happens there. Keegan (WMF) (talk) 05:25, 18 May 2014 (UTC)

There are two links to the Commons file page: in top right corner of the scrollable metadata panel (in the part which is always visible - this link only appears when logged in), and in the right-side information column of the metadata panel (it even has a big logo and distinctive border and background to jump out more).

The share link has a different purpose, it goes to Commons but also opens MediaViewer there. It is really only meant for sharing the MediaViewer view of the image - basically it is a replacement for sharing the current URL that MediaViewer creates when you pop up an image over some article. Sharing that URL would be problematic, since the image could be removed from the article at any time, so the URL is not permanent - so we offer a link to the image's "home page" instead.

Also, MediaViewer tries to remove the need to go to the article page for really basic stuff like downloading the image - you can do that in the same menu which has the share link. --Tgr (WMF) (talk) 23:05, 18 May 2014 (UTC)

This feature is very inconvenient for research where as much information as possible on each image is needed. Its relationship to Wikipedia, a valuable information source, should carry over as much as possible to images and media captioning. Because the new media feature is imposing itself (gradually, apparently, but out of the blue and very inconveniently for me)as a default, it discourages people who post images from telling as much as they could about the images, because the full information does not show in the viewer. In short, the viewer makes an information + image source into an image showcase like Flickr. But Flickr already exists. We do not need another one.

Another related disadvantage to the MediaViewer is that it does not offer the scaled images sizes of the old viewer. It is useful to be able to access and use images at lower resolution for some purposes, and high ones for others. The MediaViewer should include this option--- and all the information in the earlier mode of display. Until/unless it does, it is merely frustrating and useless for getting images for teaching or research. For those plummeted into it, there should be an easy-to-see OFF button. I hope we will always be able to have the option to turn it off.

How can I have data on all the languages of comment
Some pictures are commented in various languages. For example. I can not see the comments in all languages with the new visioner. So I might add a comment in a language that already exists.

How can we solve that problem?

--Lucyin (talk) 11:14, 16 May 2014 (UTC)
 * Lucyin, I'm not sure what you mean. I'm not seeing a description for the file in anything other than English, and I don't see commentary on the gallery placement. Could you please explain a bit more? Keegan (WMF) (talk) 05:24, 18 May 2014 (UTC)

Why the captions are omitted?
Well, I'll try to be constructive this time. I don't understand why the cutlines/captions are omitted. I mean, without them, the most of the images from an encyclopedia are meaningless, since they are used for improve the explications and not just for decoration. Besides, many of them are diagrams or pictures with numbered parts like this that must have a caption. ¿Why not to include them? Thanks. Albertojuanse (talk) 00:26, 26 April 2014 (UTC)
 * +1. I noticed the same big problem. Most of all a serious lack into comparative galleries. --Salix (talk) 16:30, 27 April 2014 (UTC)
 * They are only omitted on galleries (that bug has been fixed, but the fix has not been rolled out yet). If you do not see the caption for any image that is not inside a gallery, could you provide a link? --Tgr (WMF) (talk) 06:59, 28 April 2014 (UTC)

No, I mean, this is not a bug report, Tgr. What I mean is that I tried the "beta" on esWiki and, when I clicked on an image, there was not the caption of the picture, the explanation of it. Of course, there was the file description and copyright mark, etc; but no the explication which is under the image in the "normal" MediaWiki view.

My point is that without these captions, the explanation of that image, this software is "useless" for a project like Wikipedia, in which the explanations/captations of the image are needed for understand it (maybe not for other proyects, of course, talking about Wikipedia). Thanks. Albertojuanse (talk) 15:20, 28 April 2014 (UTC)
 * Albertojuanse: I think Tgr point was that the no-caption in galleries was a bug which has been fixed since.
 * Unless you feel (like Salix) that the caption should be displayed without scrolling down to the hidden metadata panel, which is tracked on 64132. Does the bug report accurately describes what you are expecting? Jean-Fred (talk) 16:46, 28 April 2014 (UTC)
 * ¿Is it scrollable!!!!!? Then, sorry, Jean-Fred and Tgr, the captions are shown properly when you scroll it.
 * Then, you have to find a way for making people know that the page is scrollable!!! I have no even notice that, so I guess other people won't either. Thanks. Albertojuanse (talk) 11:32, 29 April 2014 (UTC)

Media Viewer problems
Another negative opinion: trying to download SVG file but instead of easy access there are only PNGs served by viewer. Not acceptable. Problem only to be solved via right clicking image, showing in new tab, editing href path - cut out 'thumb/' and parameters following original filename, hit enter, now you've got the SVG that is possible to download. 95.171.99.171 10:54, 25 May 2014 (UTC) And hate that I have to separately register on each Wikipedia PL/EN/.../Wiki Commons.......... Lack of basic functionality is the most irritating. 95.171.99.171 11:00, 25 May 2014 (UTC)

Hi! My experience with Media Viewer has so far been mostly negative. Here are some points:
 * It presents a cleaner interface, but at the same time it hides a lot of valuable information from view.
 * It seems to have a very different interface compared to the normal Commons experience, which may be confusing.
 * I've witnessed at least two instances, where another user could not escape out of Media Viewer in an easy and straightforward manner (no menus etc visible).
 * It seems Media Viewer has gone default on some Wikipedias – including plwp. My preferred browser (Mozilla Camino 2.1.2) doesn't seem to be compatible with Media Viewer, and I'm not proficient enough in Polish to be able to deactivate Media Viewer in my plwp account. This is not good.

If any or all of these things could be addressed, I'd might be more positive to its implementation. But as for now it's a big no-no for me.--Paracel63 (talk) 12:28, 26 April 2014 (UTC)


 * I now found the deactivation command info in the discussion above. Thanks for that.--Paracel63 (talk) 12:48, 26 April 2014 (UTC)


 * BTW, there doesn't seem to be a way of deactivating Media Viewer "in advance"? Next week, I still want to be able to reach Commons, with my preferred brower, through any of these Wikipedias "Dutch, French, Japanese and Spanish". Best of wishes. :-)--Paracel63 (talk) 12:56, 26 April 2014 (UTC)

"Normal Commons experience" is a bit of an oxymoron. Commons file description pages are disorientating jumbles of random information, looking at a cleaner interface after getting used to them might be a bit like taking off the reversing glasses in the perceptual adaptation experiments :-) Yes, change is always confusing, but there is no way to avoid that if we want to transition to a saner user interface.

I've witnessed at least two instances, where another user could not escape out of Media Viewer in an easy and straightforward manner (no menus etc visible) - do you mean that they could not figure out how to exit, or that the normal methods of exiting (X mark, Esc key) did not work? If the latter, can you reproduce that?

Do you have any specifics of how MediaViewer breaks on Camino? Do you get a javascript error, or does it work but look ugly?

--Tgr (WMF) (talk) 07:18, 28 April 2014 (UTC)


 * Hi! Thanks for getting back to me. Yes, Commons of today is a mixed experience, which clearly could need an overhaul, bringing the composition of the content a lot clearer (like an easily accessible standard attribution line for each license and a lot less bulky license presentation).


 * However, what I've seen of Media Viewer does not seem guided towards (active) users of Wikipedia but as a standalone image viewing environment. It's a media viewer per se, but getting important info out of view has its cons. The lack of visible navigation aids is not for me.
 * Those two instances of failed escaping out of lightroom were with the same user, who used MSIE (a later version) on Win7 (or Win8), itself a menu-less experience that is far from my idea of an easy-to-use computer working environment. The whole setup may have been unstable in at least one of the instances, where we resorted to having to restart the whole computer. In the other, earlier instance we were not prepared nor instructed of how to navigate in lightroom.
 * Yes, on Camino I get a JS error: "Error loading Media Viewer: Module oojs has failed dependencies".
 * Sorry if I'm misunderstanding some things with Media Viewer. As I spend my Wikipedia days 99.9 percent of the time through Camino, I may have missed some good points. Now looking at it through Firefox and plwp, I can appreciate the clean interface. But the cons are the same: lots of valuable info hidden out of view. As a contributor to Commons and Wikipedia this thing just isn't for me, and I'm wondering why the current Commons interface couldn't have found a – somewhat less radical – design change instead? MV looks too much like a gadget, and IMHO it should have stayed that way. The oft-repeated explanation around Media Viewer that "change is always confusing" is sounding like a political statement, so I'm not going to comment on this further. Best of wishes--Paracel63 (talk) 13:52, 28 April 2014 (UTC)

--Tgr (WMF) (talk) 18:45, 28 April 2014 (UTC)
 * Tracking the Camino issue as 64562.
 * If by "not guided towards active users" you mean it does not have editing features, it would be very hard to present an interface to change data with the way currently things are stored, in big blobs of wikitext; and it would be a waste of time, sine that is planned to change soon, at least for images hosted on Commons, with the introduction of Wikidata. After that happens, it is possible that MediaViewer will get some editing features.
 * That said, we did make some changes based on the needs of power users (the image page link in the bottom right corner that's accessible without scrolling, for example), so if you have more suggestions, please share them.
 * Commons file pages have just way too much information for their own good. We might be showing less then ideal for a power user (mostly because extracting them from the file page is a lot of effort), but any user-friendly redesign of how readers access file metadata has to start with hiding a lot of it.
 * There were several reasons why not to redesign the file page itself: it would break established workflows (if you don't like MediaViewer, you can just skip it and go to the file page; if the file page itself would be changed, you would be probably much more unhappy); it is a based on a wiki page so it has a lot of baggage from step 0; it is on a different wiki, and that presents a lot of usability problems (lack of cross-wiki preferences, notification, identities...); loading a new HTML page per image is a horribly ineffective way of navigating images.


 * Thanks for the explanation. As long as I can avoid Media Viewer and have a well known, editable workspace, that's enough for me. I notice at Bugzilla that the bug won't likely be followed up upon, as Camino is no longer being developed. If anyone can point me to a modern browser that has a 1+1-button (= easy one-hand access to all the standard editing/tab interfaces) access key standard on OS X, I'd be willing to pay quite a handsome sum of money. The very best of wishes.--Paracel63 (talk) 15:30, 10 May 2014 (UTC)

It takes my time, I hate it
New viewer may have some positive features for viewers, but I found it irritating. As editor I switch to Commons to use the file, edit page or find information on usage of my photo on other wiki. This new viewer is ugly, uploads slowly and needs another click to find what I am looking for. I want to disable it, but did not found how (it is a default feature on cz:wiki)--NoJin (talk) 10:11, 27 April 2014 (UTC)
 * + 1. Many files take more than 5 seconds to focus, and I have a very good fiber Internet connection ! --Salix (talk) 16:35, 27 April 2014 (UTC)
 * + 2 ! A real pain. FredD (talk) 20:35, 17 May 2014 (UTC)

As a fellow editor, can I ask something ? Are both of you aware of shift/command/middle/right clicking an image to open in a new window ? For me clicking links like that is 2nd nature, but I know many users are not used to that. I have warned before about how many editors we have who might not be used to accessing images that way and predicted friction regarding this with the mediaviewer. I think that makes it a good case to give people an easier opt out (ask auto confirmed users on first click, and disable the feature with JS, if the user thinks it is undesirable). TheDJ (talk) 10:50, 28 April 2014 (UTC)
 * I hate it too, how can I turn it off? --Korvatunturi (talk) 09:11, 16 May 2014 (UTC)
 * Hate it. Previous method was easier to use. Mannanan51 (talk) 17:49, 28 May 2014 (UTC)
 * +1.. hate it too. --Stobaios (talk) 13:44, 30 May 2014 (UTC)

Description is not very understandable
MediaWiki:Multimediaviewer-pref-desc currently says (my comments in brackets): "Improve your multimedia viewing experience with this new tool [So far, so good, but what does it do?]. It displays images in larger size on pages that have thumbnails [Hm, so it expands the thumbnails, making them a little larger?]. Images are shown in a nicer [nicer than?] fullscreen [full-window?] interface overlay, and can also be viewed in full-size [full-screen? full-size being 100 % (with scrollbars if necessary)]."

What about "Improve your multimedia viewing experience with this new tool. When thumbnails are clicked, a larger version will be shown in a nice-looking overlay, which can be expanded to full screen if desirable. Media on the same page can easily be navigated." ? Danmichaelo (talk) 09:54, 27 April 2014 (UTC)

Error loading MediaViewer: localStorage is null
When clicking on image, error "Error loading MediaViewer: localStorage is null" is displayed. --Ragimiri (talk) 13:46, 27 April 2014 (UTC)

Hi Ragimiri, what browser/OS are you using? Could you try adding  to the URL before opening MediaViewer, then opening the browser's error console (F12) and copying the error message here? --Tgr (WMF) (talk) 18:12, 27 April 2014 (UTC)

I am using Firefox 28 on Windows 7. I hope, this is it:

"Use of "mwCustomEditButtons" is deprecated. Use mw.toolbar instead." load.php:10015 Výpis zásobníku z load.php, funkce mw</<.log</log.warn, řádek 10017. load.php:10017 "Use of "addOnloadHook" is deprecated. Use jQuery instead." load.php:10015 Výpis zásobníku z load.php, funkce mw</<.log</log.warn, řádek 10017. load.php:10017 "User clicked on thumbnail to open lightbox." load.php:11931 "localStorage is null" load.php:10015 Výpis zásobníku z load.php, funkce mw</<.log</log.warn, řádek 10017. load.php:10017

--Ragimiri (talk) 18:24, 27 April 2014 (UTC)

Might be 64525 --Tgr (WMF) (talk) 07:35, 28 April 2014 (UTC)

Of course I have DOM storage disabled. But there is no reason to use DOM storage to viewing images on wiki. --Ragimiri (talk) 08:37, 28 April 2014 (UTC)

The reason is to avoid annoying users with the same notification endlessly. There is no reason a disabled localStorage should cause a JS error, of course - we are feature-detecting it the wrong way. --Tgr (WMF) (talk) 18:13, 28 April 2014 (UTC)

Superfluous
The Media Viewer is a superfluous, unnecessary and harmful tool, which makes work harder. Commons is not a gallery but tool for work. When we go to the commons, we don't want watch and delight pictures, but obtain information necessary for writing of articles. --Matrek (talk) 04:22, 28 April 2014 (UTC)
 * Media Viewer is meant to work differently on Commons than the other wikis since viewing file pages on Commons is part of the work flow and is much more important than the visual experience we are trying to provide. If you feel that there are ways that Media Viewer can be better integrated into Commons so that it does not interfere with workflow by all means toss out your ideas here. There is always room for improvement for integrating with Commons. Keegan (WMF) (talk) 21:47, 29 April 2014 (UTC)

How this off
I dont know, how it function off.--Toma646 (talk) 17:48, 28 April 2014 (UTC)
 * If Media Viewer is already enabled for all, like it is here, you can disable it in your appearance section of your preferences. If Media Viewer is not enabled for all and is still in Beta Features on your wiki, you can disable it in Beta Features. Keegan (WMF) (talk) 18:48, 29 April 2014 (UTC)

What about most users who do not have an account? how can they turn it off as most will want to?--Michel le tigre (talk) 20:55, 12 May 2014 (UTC)
 * Like any feature in Mediawiki that someone does not like, they can register an account and adjust their preference to suit their needs. Keegan (WMF) (talk) 18:26, 15 May 2014 (UTC)

Alternative
I've had this script enabled for some time now, and I feel like it's a much better alternative than Media Viewer. I'd much rather stay on the same page and just click again when I'm done with the picture, video, etc, rather than having to go to a new page then hitting the Back button and waiting for the page to load again. Supernerd11 (talk) 14:32, 2 May 2014 (UTC)

Useless and annoying
My first word would be "What the fuck ?" Before, when you would see an image at a 100% scale (typically maps in SVG format), it was simple : click on the image, you got on the file page, another click on the image and then you had it in your browser. And now ??? With this media viewer it's impossible to have the file at 100% in the window... The "full screen" button ? Totally useless. The "download" options ? Impossible to download the source SVG, PNG only is available ! But Firefox can display SVGs ! Worst evolution of Wikipedia EVER. I'm not english so excuse my syntax. Bob Dean 2014-05-02 21:29 UTC Edit : Okay, you could get the file on Wikimedia Commons two other clicks away... Still boring.


 * 100% agree. Most idiotisk plug-in. Wonder why people would put any efforts in a such a useless thing. Image should give clear and direct access to just two options: text information (caption, copyright, categories) and 100% and/or fullscreen view. If these options are obscured - it is just an annoying obstacle.78.73.55.57 18:39, 9 May 2014 (UTC)


 * PS will you instead do something usefull, e.g. this : Project:Requests, so I will appear myself? 78.73.55.57 18:44, 9 May 2014 (UTC)

From Tucvbif
From Russian Wikipedia: -Gryllida 15:18, 3 May 2014 (UTC)
 * 1) Incorrect translation, 'learn more at wikiemdia commons' as 'подробнее на скада', should be "подробнее на складе", other tense of the noun, I tried to find at translatewiki and there is the 'подробнее на $1' bit but not the 'склада';
 * 2) how to link to a mediaviewer preview from wikilink. PageName tries to find a heading, and fails.

--Tgr (WMF) (talk) 17:53, 3 May 2014 (UTC)
 * 1) You can translate here and here. Usually this sort of stuff is done with   (  or something like that - what options GRAMMAR has depends on the language, I don't know how it is used in Russian).
 * 2) The link format is  . You can use   in templates:   will result in [#mediaviewer/ link]. (We should probably put this in a FAQ somewhere.) Read this mail if you are interested in how this format came to be.

Multiple licenses
The Media Viewer has a confusing experience for multi-licensed images. For example, File:Populus angustifolia CO.jpg is multi-licensed under CC BY-SA 3.0 as well as the GFDL. When viewing this image in the Media Viewer, however, the image name is accompanied by a CC logo and the text "CC BY-SA 3.0". However, this text is linked to the GFDL:



This image is tagged with, which takes multiple licenses. In this case, the page has the CC BY-SA 3.0 metadata followed by the GFDL metadata. It would be much less confusing if the viewer would consistently pick a license when more than one is found, and ideally it would show all of them.

– Minh Nguyễn (talk, contribs) 21:38, 3 May 2014 (UTC)


 * Hello Minh Nguyễn: Thanks for bringing up this issue, which is now high on our priority list. Here is our development ticket for handling multiple licenses. We are working with our designer Pau Giner to come up with a simple solution to let users know there is more than one license without cluttering up the user interface: for example, we might show an ‘other license’ link next to the first license label, linking to the License Details where that second license would be shown in full. We're open to other approaches, as long as they are easy to develop and can displayed in a compact way to users. Thanks for taking the time to report this issue. :) Fabrice Florin (WMF) (talk) 17:55, 13 May 2014 (UTC)

Please roll it back
It's not pleasing nor useful, in my opinion. I liked it just the way it was before. Changing things just for the sake of 'advancement' is entering the road to oblivion. I'm sure there are other useful inventions that could be implemented. Put resources on that. Please. --OSeveno (talk) 22:10, 3 May 2014 (UTC)

A supprimer d'urgence
C'est nul, c'est moche, ça ne sert à rien, un retour en arrière sur l'ancienne fonctionnalité serait une décision intelligente.Piso17 (talk) 11:23, 5 May 2014 (UTC)

Sorry, most maps become illegible
The new Media viewer is a big setback for maps on Wikipedia. The reason: there's no "zoom to 100%" feature in the new media viewer. As most maps are contributed on high resolution, the maps become illegible. In fact, I get messages from users asking if I have changed my maps. No, I haven't; a poor viewer has been installed and here's how you turn it off: go to your preferences, select the tab "appearance" and disable "Media viewer" under the "files" section. Wikipedia team: please turn this viewer off by default, or add a zoom feature in the new viewer. 82.157.194.130 16:46, 5 May 2014 (UTC)
 * This is planned in a future release (can't tell which, the URL does not load for me, which I hope is just a problem with my connection). Gryllida 10:30, 6 May 2014 (UTC)
 * Thanks for bringing up this issue, which many of pointed out to us as well (a zoom feature is by far the most frequent request in our surveys). To address this problem, we are now working on this simple link solution (#588)], which we hope to release in coming weeks. It would either link to the original image outside of the Media Viewer, or to the ZoomViewer gadget, developed by Dschwen. If we have more time later this year, we may be able to develop a built-in solution inside Media Viewer, such as this Basic Zoom feature (#504) -- or the more labor-intensive Full Zoom feature (#167) cited by Gryllida. Either way, we will provide a simple zoom capability shortly, as it is clearly needed (see Gerrit #132133). Thanks for your patience. Fabrice Florin (WMF) (talk) 17:18, 8 May 2014 (UTC)
 * to give an different example, also texts become illegible. to open the original file and use the browser or operating system image viewer to view the image it takes 5 clicks, instead of 2 before. --ThurnerRupert (talk) 13:12, 10 May 2014 (UTC)
 * You can click on the commons/site icon to go to the file page directly, so it is only +1 click. Also, you can use "Use this file" > "Download" > "preview" which is 3 clicks but probably actually faster than the old 2 click method because you don't need to wait for the file description page to load. --Tgr (WMF) (talk) 21:30, 16 May 2014 (UTC)
 * it is _only_ plus one click for billions of users???? i do not think this is the right attitude to tackle problems, minus one click should be the goal, +1 is +30% in this case ... --ThurnerRupert (talk) 04:18, 17 May 2014 (UTC)
 * According to our tests, MediaViewer displays the first image about three times faster than clicking through to the the file page did - and at the same time in a significantly larger size. The subsequent images are displayed basically instantly if you click through them in order, while the old method of navigating back and doing another file page load for every image was extremely cumbersome. So the changes benefit users greatly for the huge majority of images; there are a small number of outliers like maps where scaling the image to the size of the window is not good enough, and MediaViewer makes viewing the image slightly more complicated than it used to be. On the whole, that's a good trade-off.
 * It would be great if we didn't have to make trade-offs and just made it work well in all cases instead. While that's technically possible, practically - as Fabrice said - it's not. It would require a big time investment, and with the same effort we can make changes which are much more helpful to editors (such as fixing some of the brokenness around file uploads). So for a while we'll have to live with MediaViewer only improving the user experience of image viewing for most images, not all of them :) --Tgr (WMF) (talk) 02:42, 19 May 2014 (UTC)

License link
In lightbox mode, a license is shown next to the file name, below the image. Unfortunately the license links to its English text, even though I am viewing on Russian Wikipedia, and I had set Russian interface language on both sites (Russian Wikipedia and Commons). Gryllida 10:12, 6 May 2014 (UTC)

We rely on license templates to get the links. If the template is localized, this might be a bug (depending on how it was localized - there are several methods and we don't support all of them), otherwise MediaViewer just does not have access to the right information. --Tgr (WMF) (talk) 15:49, 6 May 2014 (UTC)

Full-screen button
The documentation mentions a full-screen button (two arrows) at the right of an image, but I don't see such button in Media Viewer (not on Russian Wikipedia nor here). Gryllida 10:14, 6 May 2014 (UTC)
 * The button is not displayed if your browser does not support the Fullscreen API. If it does support it, and you think this is a bug, please add browser details. --Tgr (WMF) (talk) 15:52, 6 May 2014 (UTC)

When speaking of the «Use this file» tool, the documentation says «Also, please include all required credits and links to comply with those terms: these credits are included in the Download panel, where you can copy and paste them for your purposes.». However I do not see such information included in the Download panel (not here nor on Russian Wikipedia). Gryllida 10:27, 6 May 2014 (UTC)
 * That part has not been implemented due to lack of time. --Tgr (WMF) (talk) 15:52, 6 May 2014 (UTC)
 * Hi Gryllida, thanks for reporting this issue about the lack of attribution info in the Download panel. I have filed this ticket for it, so we don't lose track of this requirement: #598 Show attribution credits in download tool. Due to our limited bandwidth, we may not get to it right away; so for now, I recommend we change the FAQ to have folks look for that attribution info in the Embed panel, which I will do later today. Thanks again for bringing this up! All the best :) Fabrice Florin (WMF) (talk) 21:55, 14 May 2014 (UTC)

How to justify the text
I know this is not the place but if you can help me... I would like to set in my preferences the old feature "justify the text". How can I do it? --Circuit-fantasist (talk) 18:07, 8 May 2014 (UTC)

CC BY SA with GFDL link
For images like File:"After Franz Hals" by Lawrence Saint.jpg which are dual licensed, media viewer shows license as CC BY-SA 3.0 with a link to GFDL (CC BY-SA 3.0) while accessing from the Wikipedia article. J ee 16:32, 9 May 2014 (UTC)
 * Same issue as . --Tgr (WMF) (talk) 17:09, 13 May 2014 (UTC)

Link title to the source page in Commons
Why not link the title to the source page in Commons? It is the "best practice" to satisfy the attribution requirements as in the most prominent location. J ee 15:35, 14 May 2014 (UTC)
 * I think of the title of the file is similar to how you see File:FileName at the top of the page except now it's at the bottom, and there's a link to the Commons page. I'm fairly certain our layout satisfies the attribution requirement. Keegan (WMF) (talk) 20:50, 14 May 2014 (UTC)
 * It's OK, if you think so. I just pointed the CC recommendation as we already provided a link to the license just right of the title. CC recommends, "title" with a link to source + "license name/icon" with a link to the license deed/legal code. (You can see here how I implemented it in a very prominent location.) J ee 02:16, 15 May 2014 (UTC)

Did not understand it, turned it off - no exif information
I like to see exif information, I might not be a good photographer but I enjoyed seeing that information. I tried to see it using the new interface but couldnt. Therefore I created an account to be able of turning it off. I use Google Chrome but assume the functionalities of the feature is fully harmonized with that browser
 * You can disable Media Viewer by (while logged in) un-select your "Enable new media viewing experience" under Files. You have to do this for each wiki. After that you'll be taken to the file page directly. Hope that helps. Keegan (WMF) (talk) 07:24, 15 May 2014 (UTC)
 * It is not ready. Another VisualEditor type implementation. Titodutta (talk) 16:25, 16 May 2014 (UTC)

Disabled
I couldn't see or add categories in Commons, disabled it immediately as I do a lot of file organisation. HelenOnline (talk) 21:14, 15 May 2014 (UTC)
 * Thank you for letting us know how Media Viewer did not mesh with your workflow. I'll be sure to contact you should we enhance category support in the future. Keegan (WMF) (talk) 23:21, 15 May 2014 (UTC)
 * I have disabled too. Titodutta (talk) 16:23, 16 May 2014 (UTC)
 * Titodutta: I appreciate you letting us know. Was it for the same or similar reasons as HelenOnline, or another reason or two? Feedback for what didn't work for you would be great. Keegan (WMF) (talk) 23:24, 16 May 2014 (UTC)
 * Above I see you say that it is not ready. What needs improved? Keegan (WMF) (talk) 00:08, 17 May 2014 (UTC)
 * Keegan (WMF), there are many issues. See this file for example
 * at first look, I find no details on file size, file resolution, options to see in other resolutions,
 * For external attributions, now mediwaviewer URL parameter is capturing a portion of the URL, which need to be removed manually. Yes, "Use this file" works, but using Ctrl L browser shortcut is easier.
 * No heading for Description section
 * License is not properly highlighted
 * templates not working (see the Ukrainian template in general view),
 * Lang code in description is not working
 * click on the "use this file arrow", and then click on the link, it'll select the entire link, but in Wikipedia(s), we need the last part File:. . . only,
 * Again "Use this file" is incomplete, the first link is just the fileURL, it could be easily copied using Ctrl L Ctrl C so far (browser keboard shortcut), why should I scroll down, click on "use this file" icon to get the link.
 * arrows are confusing, no title text clarifying "next" "previous" image of which series?,
 * zoom is confusing and is not actually working as zoom,
 * more details may be linked to #Summary, as visitor has already seen the file in MediaViewer and there are many more issues. Titodutta (talk) 20:39, 24 May 2014 (UTC)
 * Thanks for going into detail, I can now see where your discontent is coming from. I think it's safe to say that there is no way Media Viewer can display all information in the ways that people want it to or, probably more significantly, are used to. I think a lot of opportunity to rectify this will come with work, starting this summer with the Wikidata team, to integrate structured metadata on Commons. Media Viewer pulls the metadata that it is instructed to, but I think we're aware that as of now Commons has no standard in use for every single file. There's thousands of images from 2005 that still don't have Information, for example. "Use this file" is being worked to make it more usable as this version is wrapped up, and we all agree that the zoom function leaves a lot to be desired. We're looking for community input on how to best work-around zoom for now by providing easy access to the original file resolution. Completely fair criticism that we're working to resolve, and again thanks for sharing it. I think that you might be pleased with how Media Viewer will develop in its next iteration based on feedback like yours. Keegan (WMF) (talk) 20:58, 24 May 2014 (UTC)
 * Then why did you roll it out as a non-beta feature if it wasn't finished? Why didn't you get together with the editors on Commons and get that stuff fixed before rolling out the change? Commons images are the only images where this sort of thing is even remotely useful, since fair use images are just large enough to fit in the articles and are not intended for casual viewing. (In fact, doing that would violate fair use.)

Heck, if you'd thought ahead, you could have designed new templates that you could pull up directly so that the community could work on what information is essential. That way you preserve the Wiki spirit of community. See, all these suggestions that could have been made and discussed if only the average user knew about it. That's the strength of the community. Trlkly (talk) 04:36, 29 May 2014 (UTC)

How to disable MediaViewer for some images




We’ve been discussing on the multimedia and commons mailing lists various ideas for disabling Media Viewer for some images that are confusing to users. For example:
 * metadata images (e.g. small icons, flags), which are not related to the page's topic;
 * other images that do not render well, making them unsuitable for Media Viewer (such as maps using weird CSS/JS tricks, or images which use a clipping template).

We initially discussed the idea of creating a special CSS class (e.g. class="noviewer") to mark these images and prevent them from showing up in Media Viewer, as proposed on [this ticket #511]. But after exploring this idea on the mailing lists for a while, we didn't hear a strong consensus, with a lot of diverging responses -- which may suggest that this original proposal to use a separate class may not be the best solution for addressing this issue. We're also getting increasingly concerned that using a separate class (e.g. ’noviewer’) that it could introduce more confusion for our users, due to inconsistent usage (with some editors disabling certain images in some places, but not in others).

So we would like to propose a simpler approach, which would be to use existing methods to disable Media Viewer for some images, such as adding a "metadata" class or a link parameter, as proposed in the FAQ draft below.

What do you guys think of that approach? Is there a more practical solution we haven't thought of? If this new proposal works for you, would you recommend any changes to the wording of the FAQ? Fabrice Florin (WMF) (talk) 17:58, 16 May 2014 (UTC)

PROPOSED FAQ (To be added to our 'Help FAQ Page' once we reach consensus.)

Sometimes, Media Viewer displays images that are confusing for our users. This includes metadata images (e.g. small icons, flags), which are not related to the page's topic; other images do not render well and are not suitable for Media Viewer (such as maps using weird CSS/JS tricks, or images which use a clipping template).
 * How can I disable Media Viewer for unrelated or unsuitable images?

We invite editors to prevent these images from appearing in Media Viewer, using one of these two methods: To enable users to access file information, consider adding a link in the file’s caption, so people can still access its file information page:
 * For metadata images, simply add this "metadata" class for unrelated images like icons or flags:
 * For images that are not metadata, but which don’t really render well in Media Viewer, consider using a 'link parameter' to disable them in Media Viewer:

Other methods may be available to exclude images in Media Viewer, but we encourage community editors to start marking metadata images right away, using the first method above, since that is work that should be taking place anyway.

(End of proposed FAQ)

________________________

Comments

 * I've read the mailing list discussion and I was surprised to see that nobody had mentioned link=|, so I'm glad that's covered above: as I understand, that disable mediaviewer, right? Is there any evidence that using link= is not enough to solve most problems? --Nemo 18:12, 16 May 2014 (UTC)
 * One problem with link=| is that it blocks the path to Commons, which is is how we often find the images. I do not think we want to block link to commons only to the Media Viewer. One of the issues with blocking the link to Commons is that many images are shared on CC licenses which require the user of the image to attribute the image creator. Right now that requirement is fulfilled by the link, but without link (or the attribution text on the page) those files become copyright violations.  --Jarekt (talk) 18:58, 16 May 2014 (UTC)
 * Thanks, Nemo and Jarekt. Nemo, I'm glad you think link=| might work for this purpose, but share Jarekt's concern about linking to the file page, so people can see attributions and license info. This is why I proposed adding that link in the caption, so people can still access that info. This could be done with a script like: . I realize that this is not the most elegant solution, but in rare cases where this is needed, it would do the trick. If that's not good enough, we could consider a new class like 'noviewer', but wanted to explore all currently available solutions before introducing more complexity. Fabrice Florin (WMF) (talk) 20:30, 16 May 2014 (UTC)
 * only works with thumbnail formats which do not have a visible caption, IIRC. For non-PD images it's possible to do horrible things like  but I would rather not go there. The main use case for this is tricky CSS-using templates, I think (position map, labeled map, clipped image etc) and it possible to add the link as a part of the template there. Usually much less disruptive than sending the user to the file page on any image click, too. --Tgr (WMF) (talk) 21:26, 16 May 2014 (UTC)
 * Using link destroys our attribution path. You cannot abuse it for that. TheDJ (talk) 16:20, 19 May 2014 (UTC)
 * Thanks for your good insights, TheDJ, Tgr (WMF), Nemo and Jarekt. Given the issues with using  which you report above, should we go ahead with our original proposal for a 'noviewer' class, so people can use it to disable images in Media Viewer for special use cases? I'm starting to lean in that direction, because the alternatives we explored above do not seem practical, and we need to provide that function, IMHO. Fabrice Florin (WMF) (talk) 21:55, 20 May 2014 (UTC)
 * I feel this would be the best idea, as |link= is problematic and "metadata" is too specific as to what it is used for and too vague as to what it does. Jay8g (talk) 00:54, 21 May 2014 (UTC)
 * I once created a definition of the .metadata class on en.wp: Used to mark elements in articles that are considered not to be part of the proper content of the article. These are annotations, maintenance templates, navigation links, media controls etc. These elements are often filtered out of 'alternative' views of the content, like CD-ROM editions, bookprint, webpage print, mobile views etc. Note that it explicitly states articles, so it is about metadata of the content of the wiki, that we 'author' inside the actual content. When printing for instance, it only works in ns-0 for en.wp. TheDJ (talk) 09:18, 21 May 2014 (UTC)
 * Hi Nemo, Jarekt, TheDJ, Jay8g, Tgr (WMF) and MarkTraceur: Thanks for your good insights on this topic. For now, I have added this entry to our Help FAQ, to document the ‘metadata’ solution, with the caveats recommended by TheDJ. Based on your guidance, that FAQ item now discourages editors from using the ‘=link’ option to disable Media Viewer for images. At this point, it seems that we should implement the ‘noviewer’ class idea, if we have consensus that it’s needed as an alternative to the metadata solution. Could you please let us know if you recommend that option or not? Thanks! Fabrice Florin (WMF) (talk) 21:07, 29 May 2014 (UTC)

My use cases for Wikipedia and Commons
I generally like the concept of Media Viewer used on Wikipedia; however it makes little sense to me on Commons, where most of the time when we click on a file is because we want to see or edit its metadata or categories. None of those tasks can be done well with the viewer, which is not able to show data stored in more advanced infoboxes like c:template:Artwork (go to c:Category:Mona Lisa and click on one of the images), and which is not able too show/edit categories. I think it should be disabled by default on Commons. My main purpose of clicking on images on Wikipedia is to: Only first task is helped by the current version of Media Viewer, but I think it is more useful than current going to the wikipedia clone of the commons file page, which often does not handle commons templates well. So with or without Media Viewer, most of the time it takes me 2 clicks to get where I want to go to. However to be fair, I think it is perfect for average Wikipedia user who is not involved in the projects. --Jarekt (talk) 18:50, 16 May 2014 (UTC)
 * enlarge the photograph
 * see the metadata (see above),
 * ensure the image is properly categorized,
 * find matching category with other related images (Commons have interwiki links to Wikipeia, but Wikipedia does not have interwiki links to Commons :(some articles use en:template:Commonscat but it is hard to find on the large pages), or
 * check if image have annotations identifying people or objects.


 * Yes, I agree on Jarekt’s opnion: descriptions in are shown quite incorrectly.


 * And, yes, the Media Viewer is in whole useless for an editor. May be, it would be liked by non-editing readers. But... It seems to me, that the Media Viewer can transform the informative, encyclopedic Commons into one of numerous photo hostings, just into a storage of nice pictures... Dmitry Ivanov (talk) 19:54, 16 May 2014 (UTC)
 * Thanks for letting us know how Media Viewer fits (or doesn't, should I say) into your work on Commons. Currently the Viewer is designed and built to help you consume what you are seeing. I can see why it wouldn't be helpful to work on Commons because it's not for working, it's for viewing. Perhaps we can work in some editing functionality in the future, but that's not on the table at the moment. I hope that you do get the opportunity to use Media Viewer when you want to just look through images :) Keegan (WMF) (talk) 21:05, 16 May 2014 (UTC)


 * Keegan, The needs of the infrequent "visitors" are very different than needs of experienced editors and very few tools will be equally useful for both. That is to be expected, and I think Media Viewer is a fine tool for "visitors", from whom it is unlikely you will hear on this page. As for tool for "when you want to just look through images", I hate to say it but I prefer the GallerySlideshow gadget: it starts when I want it (and not otherwise), shows basic metadata (like Media Viewer), but also categories and license info. Also I do not think there is this long delay before the blurry image gets sharp. --Jarekt (talk) 04:18, 18 May 2014 (UTC)
 * Absolutely noted. Keegan (WMF) (talk) 04:59, 18 May 2014 (UTC)


 * I agree completely with Jarekt. As a Commons Admin, when I click on a thumbnail, I don't want to see a big, slow-to-load, image -- I want to see all of other information on the upload page.  Media Viewer puts me a second click away from where I really want to be, and wastes several seconds loading, even on a 10 megabit connection.
 * More to the point, how do we turn it off? The help page says it must be enabled under my Beta link, but it doesn't even appear there. It suddenly appeared this morning and I certainly don't want it. Jameslwoodward (talk) 11:10, 17 May 2014 (UTC)


 * I also agree completely with Jarekt. It's useless for editors on the Commons. It also makes it harder to edit Wikipedia. It's very annoying not to have the name of the file, its categories and other information readily apparent. Parabolooidal (talk) 16:53, 17 May 2014 (UTC)
 * Thank y'all, Parabolooidal and Jameslwoodward, for taking the time to come over hear and let us know you agree with Jarekt. I hope we can make it more useful for you in future development. Keegan (WMF) (talk) 02:36, 18 May 2014 (UTC)
 * I think that an effort to accommodate the needs of Admins on Commons would be wasted. The fundamental problem is that the tool is intended to show off the image in a large size. We don't need full size images, so the several seconds they take to download is wasted. On an active day, I may look at 300-500 images, so two seconds a each is 10+ minutes of wasted time. We do need all of the other information on the image's page, not all of which the tool provides correctly. While the latter could be fixed, the former cannot.
 * Maybe there is a something. I note that it is possible, if you choose to use the tool, to opt out on a case-by-case basis by pressing CTRL-SHIFT while clicking on an image. Perhaps you could provide for the opposite -- to be able to opt into using the tool on a case-by-case basis. Jameslwoodward (talk) 10:24, 19 May 2014 (UTC)

other versions cannot be seen easily
This is an example introduced recently for GLAMs. Many pictures will be uploaded in original quality coming out of the scanner. To easier display, they will be overwritten with a smaller, autoconverted version. Automatic conversion reaches good quality not in all cases, so the idea is that users are aware of the original and do a manual, better, conversion. Could you provide a link to the original resp others versions please? --ThurnerRupert (talk) 04:31, 17 May 2014 (UTC)
 * ThurnerRupert: The current design allows a simple click through to get to the file page where they can get to a higher resolution. Instead of providing yet another link in the interface, I think the better approach will be tackled when Media Viewer is revisted in v0.3 and there's a nicely integrated zoom feature. If we add too many more elements to the Media Viewer experience then we've just jumbled it up as much as the file page :) Keegan (WMF) (talk) 02:33, 18 May 2014 (UTC)
 * Also, we do have the option to view fullscreen in Media Viewer. Keegan (WMF) (talk) 05:06, 18 May 2014 (UTC)

I assume this request is about the other_versions field of the info template? The use of that field is just too diverse to include it in the interface, IMO. You can always just add a link in the image description, though. --Tgr (WMF) (talk) 23:08, 18 May 2014 (UTC)


 * No. It is about seeing earlier versions. It is praxis in some cases to overwrite originals with modified versions, better for ordinary viewing. The file description page automatically shows thumbnails of earlier versions, with the comment provided at time of overwriting and a link to the old version.


 * I think this is an other case showing editors need the real file description page and should have the media viewer disabled most of the time (i.e. activated manually only for some images).


 * --LPfi (talk) 06:19, 23 May 2014 (UTC)

It's horrible! How do I disable it?
Good for viewing, but a complete pain for editing and using images. I hate it. How do I make it go away, only to be used if selected? I can't relate Keegan's comments above ("If Media Viewer is already enabled for all, like it is here, you can disable it in your appearance section of your preferences. If Media Viewer is not enabled for all and is still in Beta Features on your wiki, you can disable it in Beta Features. Keegan (WMF)" (talk) 18:48, 29 April 2014 (UTC)") to my Preferences on Wikimedia Commons - neither option seems to work there. Whose bright idea was it to impose this? Johnbod (talk) 12:32, 17 May 2014 (UTC)
 * Johnbod, go here, and you've find the box underneath "Files." Keegan (WMF) (talk) 00:22, 18 May 2014 (UTC)


 * Please add this information (up to "Enable new media viewing experience") to some manuals. Ain92 (talk) 18:10, 18 May 2014 (UTC)
 * What a coincidence - I've just this minute managed to do it, and amended the Commons page to make clear that you have to untick the highly cryptic "Enable new media viewing experience". Really, you guys! Hopeless. Johnbod (talk) 22:20, 31 May 2014 (UTC)

Feedback
Hi, I really, really like the current version of the new Media Viewer. Its great to see it has made such great process since the first beta! And its great to have a much more image friendly viewing experience now. But it has some bugs I'm sure you are aware of, but just in case.... --Sebaso (talk) 16:19, 17 May 2014 (UTC)
 * 1) As the viewer is great for, uhm, viewing - its really hard to find out as user that you could and should re-use the images you are looking at. Maybe the icon should be replace with a big button "re-use this file"
 * 2) "Use this file"-tabs: order should be "embed", "download", "share" - I guess its more often used to embed a file in a wiki page or blog than to share it without any context
 * 3) Sharing link: Its broken on Twitter (you would to need support https://dev.twitter.com/docs/cards I guess) and quite ugly on Facebook - so its not really useful right now for sharing
 * 4) Link to file: should be near the image (so I could go to the commons page directly from the page a picture is embedded) and in media viewer should the link be visible instead of the commons logo (which is not a barrier-free visual sign for "here is the link to the original file with all information about it")
 * 5) The "more information" drawer should be open on mouseover, as it's the place for very useful meta data
 * 6) Exif information should be shown in the drawer
 * 7) If the media viewer is not in full screen mode it should indicate that it is an overlay of a wikipage and how you could get back to this page
 * Dear Sebaso: Thank you so much for your kind words and for your invaluable feedback! I really appreciate your recommendations for improvement, which are well thought-out and very reasonable. We will discuss them in our next design meeting with Pau Giner and other team members -- and we will file new tickets based on your recommendations.


 * If we could only do a couple of these improvements, which ones do you think are most critical? Keep in mind that we are looking at a long list of other requests, shown on this board for our current cycle. Realistically, we can only address a few more of these issues right away, as we are wrapping up feature development for this release in a few weeks. So it would be really helpful if you and others could help us prioritize them -- and I will post an invitation for this next week. Rest assured that important requests that cannot be addressed for this cycle will definitely be considered for the next upgrade. Thanks again for your help in improving this product! Fabrice Florin (WMF) (talk) 19:03, 17 May 2014 (UTC)
 * If you still have a ton of changes that need to be made, you shouldn't have rolled it out in the first place. I know I'm getting repetitive, but that's how important I think it is to hammer this in. You shouldn't be rolling out software by default when it is still in beta. There's no harm in rolling back your implementation dates until you are finished. This is the same reason people had problems with both of the other big changes, Visual Editor and Style refresh. You keep rolling things out before they are finished. Trlkly (talk) 04:45, 29 May 2014 (UTC)

Media-viewer ignores credit-line template
It is very bad that Media Viewer does not utilize (aka ignores) the credit information presented by the "Credit line" template, which was created on Commons and is used especially to make it easier for re-users to properly credit images which require attribution. See for example File:Arena AufSchalke Innen bei Konzert.jpg which is used en:Veltins-Arena or File:MeinKarl2014 Aachen 8349.jpg which is used in en:Charlemagne. In both cases the information that was put into the credit-line entry is not presented by the Media Viewer. This may lead re-users to wrongly crediting the author and consequently comitting a license violation, which may expose them to litigation. --Túrelio (talk) 18:03, 17 May 2014 (UTC)
 * 183,901 transclusions for that template is no small number. I've filled a bug report for it. Fabrice Florin, something to look into here. Keegan (WMF) (talk) 00:32, 18 May 2014 (UTC)

These are just my random thoughts, but this might be something we want to revisit after Wikidata has been integrated. There are just too many ways of requested attribution right now (license template, credit line template, permission parameter of the info template), they are used inconsistently, we cannot assume anything about the format or syntax of how they are used (could be anything from a simple name to a huge HTML table with decorative colors and all). Readers deserve better than recreating the mess of file description pages in the viewer. --Tgr (WMF) (talk) 23:15, 18 May 2014 (UTC)
 * I would think that if anyone deserves anything, it would be the author of a file, who has the legal right to specify how their work is credited. That the several existing templates to specify an attribution request are used inconsistently on Commons simply does not justify omission of such fields in the viewer. Strictly speaking this probably constitutes a license violation. Wutsje (talk) 18:00, 19 May 2014 (UTC)

The Commons File page is the primary source of information, not a "More details" page
The Media Viewer needs to display the file name as a blue link to the image File page at the top of the info section (at the bottom of the Media Viewer page). It should be the first thing provided in that section. The "More details" button should discarded. The editable File page is the primary source of information about any image on Commons and should be readily accessible. The Media Viewer is a non-Wiki add-on and should not try to hide or replace the File page. It almost seems opposed to the basic Wiki concept, since the Media Viewer makes it obscure and difficult for users to find and edit the File page. --Robert.Allen (talk) 04:31, 18 May 2014 (UTC)
 * Thank you for the detailed feedback, Robert.Allen. It will be taken into account when reviewing final design improvement before final release. Do keep in mind that any and all issues can be revisted during the next cycle of Media Viewer development. Keegan (WMF) (talk) 05:17, 18 May 2014 (UTC)
 * I have come to the conclusion that linking this viewer from image thumbnails is a very poor idea. This is especially true for thumbnails in galleries (whether on a Gallery page in Commons or on a File page, where galleries are added for other versions), where the linked file name is not present. The Media Viewer as now implemented has become an obstacle, rather than a help, preventing editors from quickly reaching and editing the page on Commons which presents the standard Wikipedia format for editing the image description, and viewing the edit history, and the image upload history. The current "More details" button in the Media Viewer is too obscure, and the whole process of getting past the viewer to the File page is very annoying. The thumbnails should link directly to the File page. The "Expand view" button on the file page is more than sufficient for users to find and use this tool. --Robert.Allen (talk) 09:27, 25 May 2014 (UTC)

Please stop this project!
Thank you not to impose your useless gadgets. They waste time and especially important information captions. Please stop this project! --Archaeodontosaurus (talk) 12:41, 18 May 2014 (UTC)
 * Caption integration is still in development. I hope you find it more useful then, so check back in a few weeks and see if it helps your experience. Keegan (WMF) (talk) 20:51, 18 May 2014 (UTC)
 * Why o why didnt WMF and WMDE coordinate so that the Media Viewer was released after the metadata for Commons Media pages was migrated to Wikidata, instead of WMF building its own Commons Media page parser...? I suspect this will be a very large timesink for volunteers and paid staff alike. ;-(  User:Keegan (WMF), perhaps it might be possible to convince the powers that be to *only* enable the media viewer for an image if the image page parser *correctly* (100%) understands the image page contents. John Vandenberg (talk) 14:14, 19 May 2014 (UTC)
 * File pages will need to be parsed in the process of the migration; any tool that supports that is probably already not really wasted.
 * Local images on non-Commons wikis probably won't have Wikidata integration, so they need a lasting metadata parsing solution.
 * The metadata parser was actually a surprisingly small part of the work; it was developed last fall and barely changed since then.
 * --Tgr (WMF) (talk) 14:36, 19 May 2014 (UTC)
 * That very little time has been spent on it isnt a feature. My point was that it isnt working correctly, and may require a never ending amount of work to support every variation of image page(s), and may also cause the community to do a lot of 'busy work' fixing the image pages so that they can be parsed by this parser.  e.g., the front page of en.wp includes File:Sitta_europaea_wildlife_2_1.jpg right now, and the parser doesnt understand it.  There are so many strange cases; e.g. en:File:Wikipedia-logo-v2.svg is used on en:Wikipedia, and the Media Viewer doesnt correctly understand it.  The description should be obtained from commons:File:Wikipedia-logo-v2.svg.  I am surprised that nobody tested this software on the logo of the Wikipedia page about Wikipedia. doh!
 * The api created may be used in the migration to wikidata, but that may also be the source of many headaches. There are many bots already written which have very good understanding of image page syntax variations and will be likely what should be used.
 * Local uploads on many wikis are full of copyright violations; displaying them at high res, out of context, and without displaying the detailed fair use rationale is probably a bug rather than a feature...not just from a legal perspective but also the communities position on fair use. Enjoy. John Vandenberg (talk) 15:40, 19 May 2014 (UTC)

Definitely No!
--Hockei (talk) 18:52, 18 May 2014 (UTC)
 * You offer to download the files without to show important things about the license. Especially whitout additional information about the conditions for using the files given by the author on the project page.
 * The project page is hardly to find.
 * Hockei:How would you improve the download experience with regards to that information? Keegan (WMF) (talk) 20:53, 18 May 2014 (UTC)
 * I cannot solve this problem. It cannot be that you open this mediaviewer by default without to show all important information. When using files outside they have to write my name and the licence in the way as I say. But you ignore it with this mediaviewer now? Nobody will read it, not even the basic information. Furthermore mediaviewer is awkwardly to use. It is sensless in my opinion. --Hockei (talk) 10:48, 20 May 2014 (UTC)

I think I will stop to give new pictures as long as WMF flouts the license with this mediaviewer. You say accept it or let it be. Apparently you don't matter. --Hockei (talk) 14:48, 25 May 2014 (UTC)

Useless to editors
I do not like the new Media viewer. It loads slow, does not provide the information I want, and in short is an extra click for me to the actuall information page. As an active editor on several Wikimediaprojects, I now have to shut down this media viewer on several projects I work on seperately. This is a waste of my time.

Next time announce this type of change more before introducing it, so people that actually work on the projects can explain the obvious flaws beforehand. Next time give active editors the option to opt out on their first experience sp they dont have to get annoyed to the point they have to ask how to shut it down.

I think it comes across rude to introduce this to projects without people having the feeling they could have some say in its introduction. This is not a small change. I am a bureaucrat on the Dutch Wikipedia, I can easily say that this viewer came unexpected. The general opinion among editors is not favorable. People are discussing in our general talkpage that the editors no longer count to Wikimedia. Obviously this is not your intend, but it makes the sentiment you create clear. This is simply not a good way to treat the people that volunteer to create the project. They feel mistreated. Feedback on the projectpages is not answered. Simply not a good introduction on the Dutch Wikipedia!

In the end it will get introduced in some way or another, that is clear, but more thought beforehand and discussion with the involved projects would have made the change easier. Taketa (talk) 19:21, 18 May 2014 (UTC)
 * /nod/ Understood. It's unfortunate that our outreach on the Dutch Wikipedia did not find you and I look forward to hearing how you think we can better engage the Dutch community. I'm already following the discussion you mentioned on the Dutch Wikipedia. Thanks. Keegan (WMF) (talk) 20:39, 18 May 2014 (UTC)

Catégories
Pourquoi toutes les catégories ne figurent-elles pas à droite dans la liste ? L'utilisateur qui n'a pas de compte ne peut plus utiliser WIKIMEDIA correctement.

Ralph Hammann (talk) 06:19, 19 May 2014 (UTC)

Sorry, not acceptable
Please stop the viewer immediately! It violates the licenses. The files are offered in the download section without the licence or an indication of how the licence is specified. Licenses offered are sometimes quite disregarded. That's not acceptable! Additional a lot of necessary information is missing: FoP, personality rights, trade marks, permissions. That is not acceptable too! The repository page is the main page. There is no hint for this page and the link is very hard to find. "Learn more" is bewildering. And there is no hint for using the image and the licence conditions. Other useful information is reduced or missing too: full list of categories, hints for assessements, information about other versions and so on.--XRay (talk) 06:54, 19 May 2014 (UTC)
 * It's really difficult with the licence hint. No one can see the necessary license notice. It's to easy, just download, no respect to the author and the licence. Please change this behaviour and show the licence term as the author wrote on the repository page.--XRay (talk) 17:04, 19 May 2014 (UTC)

Where can I see the maximum resolution now? O.o
I can't choose other sizes for the images now. This new Media Viewer is flop.


 * Viewing at max. resolution is something I miss as well. I do not think the Media Viewer is a flop, quite the contrary. Alex P. Kok (talk) 16:13, 19 May 2014 (UTC)

Image page parser
Could someone point me to the image page parser used by Media Viewer? John Vandenberg (talk) 13:58, 19 May 2014 (UTC)
 * Extension:CommonsMetadata. --Tgr (WMF) (talk) 14:23, 19 May 2014 (UTC)

Some remarks about this new viewer
With all due respect for those who have put their time and energy in the creation of this viewer, after having been confronted with this "new media viewing experience" on nl:wiki for a few weeks now, I'd like to make some remarks about it. Not necessarily in order of importance: Wutsje (talk) 17:30, 19 May 2014 (UTC)
 * 1) Not the uploader of a file should be mentioned, but its author: it's normally the latter who owns the copy rights to it (when applicable). Above that, the uploader and the author are not necessarily the same person. Mentioning just the uploader increases the risk that they are wrongly credited as the author of the file, even if they're clearly not.
 * 2) The contents of any Attribution field is ignored, so even if the author of a file has explicitly specified how it should be credited (as some licenses allow), this is not shown: there is just a link to the general license conditions. Legally this does not seem correct to me. It also increases the risk that a re-used file is not properly credited.
 * 3) Even if a file is published under a dual license (e.g. CC-BY-SA and GFDL), only one of them is shown, which I don't think is legally okay either.
 * 4) With regard to images specifically: I really, really dislike the fact that those can't be easily seen in full resolution anymore, which used to be possible with one simple mouse click. Even if an image is very large and shows lots of details, most readers just won't notice, because the possibility to zoom in on it easily has disappeared. The viewer does not even mention the file size, so there is no indication how large and detailed an image actually is. The link to the Commons page on which an image is published is in fact too well hidden to be actually helpful in this respect (its text should be changed to something like More information about this file on Wikimedia Commons or even better, there should be a View image in full resolution link). Over the past six years I've uploaded quite a lot of sometimes rather large photos to Commons, but I'm now considering publishing any future work on Flickr, where anyone interested can indeed easily see any image in full resolution.
 * 5) Any information in the Other versions field is not shown, so even if there are possibly useful other versions of a file, the reader won't see them.
 * 6) Some of the icons used in the viewer are quite confusing for text-oriented readers, for instance: that a small square with a smiley is supposed to signify the contents of the Author field, or some kind of suitcase label (?) the Categories in which a file can be found, is certainly not self-explanatory. These icons should i.m.o. be replaced by text.
 * 7) If a file is listed in more than one Commons category, to avoid confusion those should be separated by anything other than a comma: a comma is very often part of Commons category titles too.
 * 8) On nl:wiki the viewer only shows descriptions in Dutch, even if those in other languages contain much more information. If there is no description in Dutch at all, as is very often the case, nothing is shown, although the vast majority of Dutch speaking people are quite capable of reading descriptions in languages like English, German or French. I'm quite sure the same is true for native speakers of other smaller languages.
 * 9) There may be more problematic aspects to this new viewer, I haven't taken a look into how movies and audio fragments are displayed, but it probably won't come as a surprise that even just the points mentioned above alone have already brought me to the decision to disable this new media viewing experience in my local prefs on all wikis on which I'm regularly active. In its present form I consider this viewer to be a serious step backward: it reduces Commons from a serious publication platform for freely usable images to a mere picture book facilitation site. That this viewer has been implemented on nl:wiki by default for every reader, without any form of consultation of the local community, is something to be deeply deplored and afaic that decision should be revoked immediately.
 * I agree with your statements. So the viewer should be stopped now. The development should be finished with respect to the requirements before starting again. It's a good idea, but it does not respect the authors work, the authors themselves and the licence conditions. I'm really not happy. --XRay (talk) 18:08, 19 May 2014 (UTC)


 * Wutsje: It's unfortunate that you did not see any of the outreach and consultation we had with the Dutch Wikipedia (Romaine's announcement, for example). What would you suggest that is something that you would notice? As for the rest of your feedback, thank you for the time writing out such detail. Fortunately most, if not all, of what you've found to not work for you is being actively finished up (Multiple licenses is just up this page, for example). I'm sorry you were disappointed by the experience. Keegan (WMF) (talk) 18:20, 19 May 2014 (UTC)
 * Keegan,there is a talkpage at w:nl:Overleg Wikipedia:Mediaviewer where people give feedback on the mediaviewer on the Dutch Wikipedia, not sure if you have seen it. Wutsje posted his comments there two weeks ago. Just in case, here is the French feedback and German feedback. Sincerely, Taketa (talk) 19:20, 19 May 2014 (UTC)
 * I had seen but thank you for providing links for others. Any and all issues with how Media Viewer displays licensing is of concern and is going to be listened to.
 * Here's what needs to be considered: I can ask 100 different people what they think should be including in licensing, reuse, where and how to present it, and I will get 100 different answers. When that is the case the best we can do is synthesize what community members are requesting, legal obligations to the creator(s) and end-user(s), and the needs of the half a billion people a month that use Wikimedia projects to learn. If we do not synthesize but instead incorporate everyone's ideas, then we wind up recreating the file page experience all over again. A mixed-up page of confusing and sometimes conflicting licensing information that wildly varies upon how much information is on the file page and detracts from the media in question. We're keeping all required legal notices and as much additional information as we can provide while still making an enhanced image viewing experience. If you want to continue working with all available file information to help curate, you'll still have to go to the file page. Media Viewer is not going to change that. Keegan (WMF) (talk) 22:24, 19 May 2014 (UTC)

Title
I click on an image to copy its title 99 times of 100. So, please, put the title back at the top in big letter as it was before. Don't make me scroll down. I will hate it. Sometimes I want to enlarge. Happens mostly with maps. But this has been discussed here. Please, put the title at the top. Big easy letters. --93.72.155.13 22:35, 19 May 2014 (UTC)

I assume you are copying the title to either link to the image or include it in some page, so this sounds like it should conceptually belong to the share/reuse dialog. I wonder if there are ways of making that more useful to you? --Tgr (WMF) (talk) 18:12, 20 May 2014 (UTC)


 * Put the title at the top in big letters, please, as it is now. You'll save tons of seconds and clicks for me and others. --194.44.219.225 09:43, 21 May 2014 (UTC)


 * No need to have big letters, but yes, copy/paste is a basic function, which many people know how to use. Needing to go through dialogues (or to scroll) is just frustrating for those of us who know how to use the file name. --LPfi (talk) 07:05, 23 May 2014 (UTC)

Preferences link
At the bottom of the media viewer is a set of links "About Media Viewer | Discuss this feature | Help | Preferences". 'Preferences' placed here suggests that the mediaviewer may be customised, whereas the link only allows the user to disable it. John Vandenberg (talk) 02:21, 20 May 2014 (UTC)
 * There are not many ways to slice it, John Vandenberg. Users (editors) would like a link to enable or disable Media Viewer actually in the viewer and this is found in preferences. We can't call it "Settings", that would be worse. We can't say "Disable" because it's also meant for people to link to re-enable Media Viewer. Following that, "Disable/Enable" doesn't work because people will expect a toggle. What would your suggestion be, keeping in mind it should be one word that's compatible with internationalization? Keegan (WMF) (talk) 04:09, 20 May 2014 (UTC)
 * I am not seeing why 'Disable' wouldn't work. It could be an AJAX automatic pref change, as was suggested by Daniel Schwen in the thread "[Wikitech-l] Deployments of new, radically different default features", and it could then be a toggle to Enable it again if the user suddenly has a change of mind.  If the user has disabled Media Viewer previously, they will not reach this UI component, as it isnt possible to get there except maybe by hand-crafting a URL. John Vandenberg (talk) 04:36, 20 May 2014 (UTC)
 * Interesting point with the AJAX. That is beyond my ken, though, the developers will have to weigh in on that. Semantically, "Disable" can also be confused with "close" after it has been translated which leads to users inadvertently disabling Media Viewer. As far as "it isnt possible to get there..." this isn't the case. The "Expanded view" option on every file page opens up Media Viewer. It's not inconceivable for someone to disable it, forget about it, and then have that viewing option allow them to re-enable it :) Keegan (WMF) (talk) 04:59, 20 May 2014 (UTC)
 * Hi! I've talked with Keegan about this briefly, and I have to say the solution is much more elegant than our current one. Sadly, I think the UI work we'd have to do, particularly to avoid accidental disable button clicks and making sure the user knows how to re-enable if they want to later on, would be more than we have capacity for. We're starting to shift our priorities to UploadWizard, TimedMediaHandler, and more core issues like the image scalers. I'm going to start tracking the progress for this on Mingle, but it's not something we can schedule in the near future. If any community developers (or WMF staff with spare time) feel like picking it up, we'd be happy to help them through the process. Thanks for the idea, I hope we get to bring it to conclusion soon! --MarkTraceur (talk) 21:36, 20 May 2014 (UTC)
 * No worries. This isnt really important, otherwise I would have put it into bugzilla.  I expect the developers will soon be drowned in real issues very soon. John Vandenberg (talk) 00:17, 21 May 2014 (UTC)

View Terms button
I've noticed that MV puts a "view terms" button that displays the licensing information if the license tags are in the "Permssions" field of the Information template (e.g. File:'Hawaiian_Canoes_on_the_Shore_at_Waikiki'_by_Hugo_Fisher,_1896,_watercolor.JPG or File:Frances_Perkins_TIME_FC_1933.jpg). However, if the image has the tags in the Licensing section these are not displayed with a "view terms" button. As an example, see File:"L'Absinthe", par Edgar Degas (1876).jpg; the fact that the re-use of this image might be restricted in jurisdictions that allow copyright for photographs that reproduce a two-dimensional public domain work is not displayed. More topically, File:Perón_Funeral.jpg, which is identified by MV as "public domain" and displayed with no "view terms" button, does not display the license tag that warns it might not be PD in the United States. This is annoying, inconsistent, and can result in important information not being shown. I think the proper solution is to parse, extract, and combine the content from the "Permissions" field, the Licensing section, the Commons, etc. and display all of these when you click "Terms". —RP88 (talk) 10:10, 20 May 2014 (UTC)

Page view statistics
If a reader is on the English Wikipedia front page, will viewing a Commons image in the Media Viewer register as a page view against the Commons file page? John Vandenberg (talk) 12:39, 20 May 2014 (UTC)
 * No request is made to Commons except for the userinfo API call, and a few DB calls for image information that are pretty likely to be cached by enwiki. Is it important to track views of each image? Could we accomplish this by some other means, perhaps? --MarkTraceur (talk) 21:40, 20 May 2014 (UTC)
 * Tracking Commons file page views is a very broken method anyway. Compare enwiki and Commons file page views for the current main page news section image - about 2% of the users who visit the file page follow through to Commons. --Tgr (WMF) (talk) 22:10, 20 May 2014 (UTC)
 * , my apologies, I should have asked whether it will register as a hit against either the commons file page or the en.wp 'copy' of it. But it sounds like the answer is 'no'.
 * I expect that if you ask stakeholders, you will receive a very resounding 'yes, we care about page views'. That especially applies to front page material, as tracking page views for any item on the front page is a measure of impact and impact is why people invest so much time in perfecting the content so it is ready for the main page and in working through the relevant community process to have their work featured on the main page.  This is especially relevant for w:WP:POTD, which has no other 'page' to track clicks against.  However it also applies to the featured pics in the other sections of the front page, and the same principle applies to every image used on a content page on any project - without pageviews, the uploader doesnt have a way to see how valuable the media is.  I know a few photographers who take a lot of pride in the fact that their work receives not just pageviews on the content page, but is good enough that people are regularly clicking through to see the file page.  Also I have include file page pageviews to GLAMs after content donations, so they can see their donation is being seen by the public (the content page doesnt say "donated by xyz"; only the file page says that). John Vandenberg (talk) 00:13, 21 May 2014 (UTC)
 * What is the use case for tracking views (as opposed to the current workarounds)? That is, if you had a crystal ball which could track any user action, what would you count? How often people see an image? How often they try to download? How often they check where the image comes from? --Tgr (WMF) (talk) 14:56, 23 May 2014 (UTC)
 * The two links you are asking me to compare above are giving the same data. -TonyTheTiger (talk) 08:13, 24 May 2014 (UTC)
 * I figured it out.--TonyTheTiger (talk) 08:15, 24 May 2014 (UTC)
 * For everyone else; the 'enwiki' link above should be http://stats.grok.se/en/latest30/File:Narendra_Damodardas_Modi_(cropped).jpg John Vandenberg (talk) 09:01, 24 May 2014 (UTC)
 * I gave a use case; GLAMs counting who has seen the metadata which shows that they donated the media to Wikimedia Commons. Which roughly equates to impact, or at least visibility of their impact. John Vandenberg (talk) 08:26, 24 May 2014 (UTC)
 * I believe GLAMs would be interested in knowing how many (unique or accumulated) visitors gave meaningful attention to images they contributed on Wikipedia articles, such as by clicking it or stopping for some duration in the slideshow view (as opposed to just scroll over in .1 sec). They might also want to know how many clicked further to visit their source website (if linked), but this can be tracked on their own server. I'm not sure how much they are interested in knowing how many visited the file description pages either on Wikipedia or on Commons. whym (talk) 08:43, 24 May 2014 (UTC)
 * I can confirm that I have been in discussions about providing these figures to GLAMs - so yes they are interested, and indeed AIUI the availability of these figurers can be a deciding factor in motivating a donation. Rich Farmbrough 14:20, 25 May 2014 (UTC).

This is a GLAM Metadata Disaster
I'm working as a Wikipedian in residence with a GLAM institution, and one of the parts of my job is to ensure that the images I'm releasing for the institution have appropriate templates describing their metadata and correctly attributing the image in ways that recognize the donor that donated an image/object to the institution, the collection that it is part of, the photographer who took a picture of it, the institution contributing that image to Wikipedia, the licensing agreements/conditions that apply.... long story short, lots of complicated information that is VERY important to the Gallery, library, archive or museum that is agreeing to share the information, and essential in correctly describing and attributing it from a metadata point of view. NONE OF IT IS VISIBLE UNDER THIS ... reworking ... of Commons. Nor is it in any possible way making my work easier -- I intended to upload some images today, but I think I'll look at my to-do list and find something else to do. It does NOT help me to make commons look like a flickr knockoff. PLEASE roll this back. PLEASE. PLEAAAAAAAASE. Hear my dying pleas... (descent into melodrama detected) Mary Mark Ockerbloom (talk) 18:13, 20 May 2014 (UTC)
 * I hear your dying pleas, Mary Mark Ockerbloom. Thank you for your WiR work and spending your time developing cultural partnerships. I love these endeavors :)
 * Please keep up your work with uploading files and organizing metadata, it's certainly vital to our mission. Media Viewer doesn't have to get in the way of your workflow, you can disable it if you have not already. Media Viewer is primarily going to be a tool for non-editors, or for editors to use when they are just in reading-and-looking mode. It is not going to replace File pages or any of the important information that those pages hold. You'll be getting more support for your work in the near future with UploadWizard development being picked back up, as well as looking to support Wikidata for media metadata. Keegan (WMF) (talk) 22:00, 20 May 2014 (UTC)
 * "Media Viewer is primarily going to be a tool for non-editors" : But metadata isn't just important for editors. We put it up, but it's there because we believe it's of value to everyone viewing the images. It's really a serious concern to me that this viewer obscures the metadata that is such an important part of establishing context for GLAM images. For some examples, see Canonical Examples Mary Mark Ockerbloom (talk) 08:51, 21 May 2014 (UTC)
 * The structured metadata work needs to be completed before that can work for MMW. That's step 2 of the MMV development process, in my mind it should not have been released to the general public without that work finished, but on the other hand I can understand that it is problematic to have code waiting for usage for a year. TheDJ (talk) 09:34, 21 May 2014 (UTC)

Best way?
Hi! I suppose the Media Viewer is not (temporarily) suspended ... So I will update all my repository pages (if necessary) with the best informations. (Don't worry: They actually already fits well.) Please tell us the best way to show informations of the image from the repository page. Especially this informations:


 * Attribution (Name, Licence)
 * Categories (only non hidden categories but all non hidden categories)
 * Author
 * Licence conditions
 * Title
 * Assessments

One key feature is the information template. Another the self template. Is there any other recommended way?--XRay (talk) 18:38, 20 May 2014 (UTC)
 * Media Viewer pulls its file metadata from the Commons Information template, as you mention. As long as your information is as complete as possible the proper file information should be shown. Keegan (WMF) (talk) 01:36, 21 May 2014 (UTC)

How Can This Feature Get Turned Off?
This feature has disabled my ability to download SVGs. Would like it off.

How will the 5.2 billion daily visitors (who don't have accounts) turn this off?

Terrible feature... Has stripped away functionality. Epic. Fail.
 * You can turn off Media Viewer on Commons in your preferences. Media Viewer cannot be turned off if you do not have an account, which is not as big of a concern considering that readers find Media Viewer most useful and the tool was built for them. I hope you can find a way to use it to enjoy images and not just work with them. Keegan (WMF) (talk) 01:26, 21 May 2014 (UTC)

That's like saying, "More people like top 40 music so we're making it impossible for people to listen to classical." The problem here is this "added functionality" is really just an attempt to make the site look more modern and reduces peoples' ability to access different file types (e.g., SVG). Gaining access to these file types is now more difficult for the average user and (in my opinion) goes against what wiki is really about and sadly was done for the sake of adding sex appeal rather than actual functionality.
 * Well, your assertions are categorically not why Media Viewer was developed, as outlined here, but you are certainly welcome to your own assumptions. Keegan (WMF) (talk) 02:41, 21 May 2014 (UTC)
 * I think you need to reread that page. "Provide a rich multimedia experience" corresponds to his "add sex appeal." "To match user expectations" matches up with "look more modern." Trlkly (talk) 05:02, 29 May 2014 (UTC)

The "Use file"->"Download" feature should support this workflow, but there is a bug in the MMV implementation, I have filed a bug report about it. TheDJ (talk) 09:31, 21 May 2014 (UTC)

The Media Viewer severely hurts power users, people uploading high quality images and viewers of these images
I'm a power user that uploads lots of high resolution, high quality images to Wikimedia that are used extensively in certain Wikipedia subjects. My experience so far with the media viewer has been very negative, as it has offered little improvements and managed to obfuscate many commonly used features. It's easier to make a list of my problems and suggestions, so here it is:

- Full-size downloading needs to be clear and upfront. My images are massive and saved at the highest quality JPG files, but the media viewer ruins this. If the average person is seeing the massive image from the viewer, they're going to think that's the best image, when it's actually a lossy and smaller version of the original. Right-clicking and saving this file also names it as the original file, giving no indication that it isn't the original. There needs to be a very large and clear icon with text (not hover text) that says something like "download original, full size version". This is the one of the most important aspects of Wikimedia and you guys buried it, guaranteeing almost no one will be saving the original file from the viewer.

- Remove the magnifying glass if it isn't going to go to the original size Mostly said in the reason above, but it makes no sense that this wouldn't display the original image. Right now it gives me a nonsensical 3000px version that is still down-converted from the original file.

- Media viewer removes a lot of information for no good reason The idea that you would force most people to look at a stripped and dumbed-down version of files' pages while hiding the original makes little sense. Metadata, exif info, user-created templates and more are removed and hid away where most people will never see them. Even community-appointed templates like "valued image" are gone!

- Media viewer should be a tool enabled by users for galleries, not forced over everything It would make the most sense that the media viewer be a tool that could be enabled in galleries, and that could be controlled to create a richer experience. By forcing it on all users as a default, it removes all of the care that went into creating gallery pages and detailed page info in all of the years up to this point. The media viewer could be a great thing, but it certainly isn't better or more useful for much of the site's current content.

- Needs ability for user-created templates When you have images that come from certain sources, like museums or personal collections, there is usually a template or box that the institution wants on the page. The purpose of this is to provide information about the collection and the institution and serves to enrich the user. Also, many of the highest valued images on Wikimedia use special templates. The media viewer removes all of this, but could be bettered by allowing a user to create a box that appears within the viewer.

- Don't be Windows 8 In its current state, the media viewer is like Windows 8, which tries to bend too heavily to casual users and a "simple" interface at the cost of usability, but ends up being too obtuse for all users. The choice of non-text icons for important features and the useless rebranding of things, where the command "go to info page" becomes the nonsensical "learn more - the free media repository" brought me to a standstill. The old style might be seen as being scary and overwhelming to casual users, but everything is still laid out clearly on the page, where it can be found by just looking at it. Also, the current media viewer seems intent on locking you into the viewer, making getting to the original info page very difficult. If I have to struggle and look up how to get to the info page, then that's a massive problem. It's not an issue of me "just needing to learn the new way."

To sum up, I find the media viewer in its current state (and being forced across the entire site) to be a detriment to Wikimedia. If the media viewer makes it difficult to even identify and download the original image, then it's already got big enough problems that should prevent it from being implemented. That, combined with the problems where it strips insane amounts of information from most of the images already on Wikimedia, makes it something that needs a lot of reconsideration. Evan-Amos (talk) 12:39, 21 May 2014 (UTC)


 * Hello Evan-Amos, and thanks for your candid feedback. I'm sorry you are not happy with Media Viewer, and really appreciate that you took the time to clearly point out the issues you have with this tool. This level of detail is very helpful to us. :)


 * Here are my comments on the points you raised:


 * - Full-size downloading needs to be clear and upfront:
 * We appreciate that you would like people to be able to view your images in full resolution -- and we have received similar requests from users that wanted that feature as well. To address this reasonable request, we would like to propose a new feature for Media Viewer: "View Original File", and would be grateful for your thoughts about it.


 * This feature would let you access the original file from Media Viewer, so you can examine it in your browser, and easily edit/re-use it. To view that original file, you would simply click on a new "View original file" button next to the image, as shown in this mockup. This would open the original full-size image in the same browser window, as happens now when you click images in file description pages on Commons. Your browser’s back button would return you to the Media Viewer. In short, "View Original File" would provide the same core functionality you are used to on file description pages. It would enable you to operate on files (convert/edit them), and also give you the ability to zoom on common file types in modern browsers.


 * What do you think? Would this approach work for you? If you have a moment, we invite you to add your comments this discussion thread.


 * - Remove the magnifying glass if it isn't going to go to the original size:
 * The magnifying glass is an experiment we did last week to see if it would address the issue above. We developed this Simple Zoom Link as a quick hack, for discussion purposes; and the intent of the 3000px version was to prevent people from opening gigantic files that might crash their browsers. But we agree that this implementation provides a poor user experience in its current form, and plan to remove it from Commons on Tuesday. We also considered a Basic Zoom and a Full Zoom features. But these implementations require more development time than we have right now. So we hope that the "View Original File" option can support your needs, without requiring a major development.


 * - Media viewer removes a lot of information for no good reason:
 * The goal was to remove some of the visual clutter that makes current file pages overwhelming for the 500 million readers whom we serve. Most of these readers do not want that much information, which is why we selectively picked the most important items and included them in the metadata panel. We also provide two prominent links to the file page on Commons, where users can read more if they like. This approach has been well received by over seven thousand survey respondents around the world, 70% of whom find the tool useful, on average. Over time, we are prepared to add more information into the metadata panel, but would like to get more user feedback before we overload it with more data than casual users need.


 * - Media viewer should be a tool enabled by users for galleries, not forced over everything:
 * Best practices in user interface design are to provide a consistent experience, that works the same way in a variety of settings. Users are likely to get confused if Media Viewer opens when they clickon some thumbnails, but not others. The goal here is to avoid that confusion and provide a consistent viewing experience across our sites.


 * - Needs ability for user-created templates:
 * We appreciate that museums or personal collections wish to provide information about their institution. That information will continue to be available on the file description page. If they wish to include it in Media Viewer as well, one possible option would be to add it in the description, as a special paragraph. We are also considering adding this partnership information in future versions, which could be used for this purposes you describe. But it doesn't seem practical to require Media Viewer to display any template a user might want to create. As we start to implement structured data on Commons in coming months, we recommend focusing on the most important templates for tools like these, and aim to migrate data from lesser used templates into shared fields, to provide better database support. More on this later.


 * - Don't be Windows 8:
 * I'm not convinced that your Windows 8 analogy is accurate. While the Media Viewer is not perfect in its first implementation, extensive usability studies so far suggest that Media Viewer provides a better experience, right where people expect it. They tell us they can see the images more clearly, without having to jump to separate pages -- and that the interface is more intuitive, offering easy access to images and metadata. We provide two separate links to the file info page, both above and below the fold, and only a few users have reported the types of issues you describe, out of thousands of feedback posts we've reviewed to date.


 * Evan-Amos, I hope that over time, you will come to appreciate the value of this new tool, which already provides a better experience for the majority of users we've heard from. While you are correct that Media Viewer still has flaws, we are working hard to address the most critical issues (e.g. the "View Original File proposal above"). And as more improvements are made in coming months, we expect that the benefits of this richer multimedia experience will outweigh the temporary discomfort which you are experiencing right now. Thanks again for your patience, and for your courteous and thoughtful observations, which we will take to heart as we continue to improve this tool based on your feedback. Be well :) Fabrice Florin (WMF) (talk) 00:12, 23 May 2014 (UTC)


 * I will concede that there is a use for the media viewer, but I will state that it hurts more than helps in certain places. Some users have spent hundreds of hours uploading and working on content for Wikimedia, being the relatively few who provide a lion's share of the site's content.  The media viewer guts a lot of the information that these users have spent much time and effort producing, so that their work can be reduced to a picture and a caption.  To say it chaffs is an understatement.


 * If there was any one thing that I'd like for the media viewer, it would be the option for it to be disabled on the page level to all users. For instance, I would be able to add to my Wikimedia gallery page (mediaviewer="off"), so that when people view images on my page, it doesn't initiate the media viewer.  Right now the media viewer wrecks the design of my Wikimedia gallery, on my own userpage, and would require a massive overhaul to compensate for it.  I could put in all of that work in the future, but until I do, I'd like to be able to present the work as it was designed before the media viewer was implemented.  I'm sure that many people with extensive personal collections would like this option as well.  Evan-Amos (talk) 17:32, 25 May 2014 (UTC)


 * I have to agree with Evan on this one. I sometimes upload 50 megapixel architectural panoramas, and there should be a mid-way between thumbnail view and 40 megabytes of image file (especially when the user is on a slow connection). Looking at the Commons POTD, it appears that this image supports viewers much more than editors. There's nowhere to change categories, for instance, and the side-bar for uploading new versions or for cropping or deleting (or pretty much anything) is covered up. Yes, we can do all these things by clicking the (tiny) Commons symbol, but why make us have to click twice for something we can do with one click now? I hate Flickr's new design, and this mimics it way too much; I'll be sticking with the original design.Crisco 1492 (talk) 08:39, 24 May 2014 (UTC)

Proposal: View Original File


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

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

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

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

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

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


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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I recommend giving all users, registered or not, an option to use the traditional image viewing interface if they don't like the new one. Even Google, the king of interface fiascos, still gives Google Maps users an option to switch to the older Google Maps. 20:01, 22 May 2014 (UTC)
 * Blunt feedback is good, honest feedback. Thanks for that. Media Viewer's purpose as of right now is about displaying an image in a manner that does not involve accessing the stacks of information behind an image. Following that, it's definitely not going to be for you if the interest is the metadata and not the file itself. You're welcome to disable it, particularly on Commons if it interferes with your workflow, but I do hope you can find use for it when casually viewing files. If you'd ever like to use it again you can click on "Expand view" on any file page. Keegan (WMF) (talk) 20:27, 22 May 2014 (UTC)
 * Very good. Let me be blunt: you've made a horrid mess.  Did you ever stop to think that any idiot can find a big box on the file description page with the licensing?  Did you ever stop to think that it's easy to click on the normal-size image to get full resolution?  Any idiot who clicks on a smaller image and gets sent to a description page will try to click again and get a bigger image.  It's nice that I'm welcome to disable it, but you've apparently forgotten that you failed to explain how to do it at commons:Commons:Multimedia Features/Media Viewer, and you failed to provide any gadgets.  I've signed up for Wikimedia projects, not Flickr or Facebook, and it would help if Foundation people began to remember that, rather than forcing things on us such as Media Viewer or Flow discussions.  Nyttend (talk) 23:07, 22 May 2014 (UTC)
 * I've added information on disabling Media Viewer to that page on Commons, Nyttend. I appreciate you pointing that out. Keegan (WMF) (talk) 01:38, 23 May 2014 (UTC)
 * You shouldn't be making changes in the first place if you are not intimately acquainted with the one project that it affects the most. You shouldn't need to be informed of that page--it should have been the WMF that created that whole thing in the first place. Explaining the software to the community and providing an opt out should be priority one, in place before any changes actually go live. Trlkly (talk) 04:14, 29 May 2014 (UTC)

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


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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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


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


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


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


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


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


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


 * That is the question...


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


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

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


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


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

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


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

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

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


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

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

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


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

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

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


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


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

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


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

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


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


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

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

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

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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

One last note: "Many users do not notice right away that they can click on the 'X' button or press 'escape' to close the Media Viewer," a quote from the survey page, is a maddening and ludicrous statement. All that button does is take you back to the page from whence you came, not close this intrusive and difficult tool and take you to the image page. In fact, without an account, I am unable to find ANY WAY AT ALL to get to the image page itself! All roads lead through this well-meaning tool. 159.53.110.143 18:36, 2 June 2014 (UTC)
 * This can be disabled? HOW????? I believe the page you want is hidden on the right immediately beneath the black field containing the image - tehre's a tiny Commons symbol there that leads to Commons (took me 2 visits to find it). Yngvadottir (talk) 21:36, 3 June 2014 (UTC)
 * To disable it, go to Special:Preferences at each wiki, and unmark the checkbox in the "Files" section that says "Enable Media Viewer" or "Enable new media viewing experience" or similar (depending on the wiki/language). Quiddity (WMF) (talk) 21:49, 3 June 2014 (UTC)

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


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

Beautiful
Wow! Nice job. This makes up for the visual editing thing before. It works so well on the iPad. Can't wait to test it on iOS 8 when it finishes installing!
 * Keegan (WMF) (talk) 21:51, 3 June 2014 (UTC)

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

Media Viewer sucks
Media Viewer sucks. They should get rid of it. Put your signature below here of you agree. --109.77.179.224 21:41, 3 June 2014 (UTC)
 * Strong I helped write the thing, I know how terrible it really is. Did you know the government implanted tracking devices inside of the black backdrop to log your movements? ;) --MarkTraceur (talk) 23:03, 3 June 2014 (UTC)

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

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

Second, it duplicates the file title twice.

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

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

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

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

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

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

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

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

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

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

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


 * This is relatively easy to fix. If you look at the file description, you could change the author and source to be more useful for this purpose.
 * However, a valid point is that there's a licensetpl_attr machine-readable thing that we don't handle currently. Adding support for that, and dropping it in place of the author/source combination, may be our answer here.
 * I have opened a ticket in our Mingle system that will track this user story. I think we'll be able to take it on sometime this month.
 * Thanks for the pointer, we love new edge cases that we can help support :) --MarkTraceur (talk) 22:52, 3 June 2014 (UTC)
 * What file description? Media Viewer turns finding that into a game of "guess where to click" (which incidentally is why its unusable on commons).Geni (talk) 01:04, 4 June 2014 (UTC)