Extension talk:Media Viewer/About

Please share your feedback about the Media Viewer in the sections provided.

Clarity

 * I like that I can see all the most relevant information about the image in one page only and the graphic display. --Daniele Pugliesi (talk) 06:29, 9 November 2013 (UTC)
 * I like that it is possible to watch more details present on a picture, exactly text explaining what a part or a component of some graph means, so eliminates some confusion of not being sure what is on that picture. Cornel24 (talk) 17:53, 10 November 2013 (UTC)
 * Hello, it's a very good idea : now we can have a look on the picture without having to go to Commons and then click again to see it in a larger size. It is quite clear, also : we easily and quickly see the picture and the information, and all the links we need are there. Thank you for this new feature ! Best regards, --Daehan (talk) 10:06, 22 November 2013 (UTC)
 * Very good all round. Being able to just click on images to see data without having to leave the page or open another tab on my browser is very useful. It's also far smoother than most similar functions on other sites. A big thumbs-up from me. --ProtoDrake (talk) 11:52, 25 November 2013 (UTC)
 * Неплохое нововведение, на мой счёт. Теперь можно посмотреть информацию о изображении не покидая страницу. Я не знаю, что можно добавить или изменить, но уверена, что в будущем всё будет просто идеально. Julia-Marina Savelieva (talk) 17:03, 25 November 2013 (UTC)
 * It's very good that such an application is being updated by the Wikimedia team. It really helps to save time and in the mean time shows a clarified image. --Shalini Ghose (talk) 2:43, 3rd December 2013

Context
The Media Viewer is a good idea for viewing pictures at a larger size without having to jump away from a page with their file description content. It loads rather slowly, which could be improved, but it is nice I can enlarge thumbnails wihtout having to go to another page to see the bigger picture. Arcane21 (talk) 06:34, 5 November 2013 (UTC)Arcane21


 * Thanks for your thoughtful comments, Arcane21. I'm glad you generally like the Media Viewer concept, and your feedback is much appreciated :) We are already working to improve the image loading speed, but your input is helping us give this task a higher priority. We are now fixing the most urgent bugs, and will be rolling out more tweaks and new features in coming weeks, with our next release due on 21 November, and more updates in December. If you have any more suggestions or questions, you are welcome to post them here, and/or on this Media Viewer discussion page. I am out of office until 19 November, but you can contact our community liaison Keegan (WMF) or lead developer Mark Homquist with any urgent requests. Thanks again for helping us improve this tool! Fabrice Florin (WMF) (talk) 03:09, 12 November 2013 (UTC)

What would you change in Media Viewer?

 * I'd make the initial view/popup show a larger image size. The full screen shot of the bird is a great size. Something closer to that without needing a second click would be great. Quicklinks to other image sizes are a must. MarkJurgens
 * I agree with MarkJurgens: it makes no sense to click two times, 1 click is enough. Moreover, I don't like the initial trasparent view, it is usefulness. --Daniele Pugliesi (talk) 06:29, 9 November 2013 (UTC)
 * I also agree. One clicks on the image to see a larger version of the image, not a smaller version. --FrankDev (talk) 17:43, 23 November 2013 (UTC)
 * I also agree! Ideally it should dynamically adjust itself to comfortably fit the resolution of your screen.Ballofstring (talk) 00:04, 4 December 2013 (UTC)


 * The "created on YYYY-MM-DD" placed just above "by X" seem to imply that the user uploading created it on that day. That will be correct for images taken by the user, but for uploads of old images it will be strange, making it look like the user was alive hundreds of years ago. --Ainali (talk) 09:07, 2 November 2013 (UTC)


 * The smily face in front of "by X" is strange to me, especially with the word "by". Either have a upload symbol so the row can be interpreted as "Uploaded by X" or remove the "by" So it reads as "User X". --Ainali (talk) 09:07, 2 November 2013 (UTC)
 * I suggest to replace the smily face with an icon showing an arrow going in a box, similar to this one: File:Crystal Clear app ark2.png. --Daniele Pugliesi (talk) 06:29, 9 November 2013 (UTC)


 * I'd like to see all the main information in a summary that could be quickly copy/pasted by people willing to reuse the file. I think that author, license and source should be provided in an easy format that allows the license to be respected even if the reuser doesn't know, well, anything about how licenses work. --Elitre (WMF) (talk) 14:03, 4 November 2013 (UTC)
 * This is really important. Our readers are already struggling how to reuse files, please don't make it any harder for them. Note that the uploader is not necessarily the author! (cf. uploads from flickr by bots) --Church of emacs talk · contrib 12:55, 9 November 2013 (UTC)


 * I'm quite a fan of the links which quickly allow you to switch among image sizes. Small or full screen are not exactly my favorite formats :) --Elitre (WMF) (talk) 14:15, 4 November 2013 (UTC)


 * Clicking outside of the modal should close it. Theopolisme (talk) 21:56, 4 November 2013 (UTC)
 * +1 JamesA (talk) 23:27, 5 November 2013 (UTC)
 * This is a natural thing for me that most image viewers support, please please add this. --Nicereddy (talk) 01:29, 3 December 2013 (UTC)


 * "Use this file" menu should have the option to "copy to clipboard" or any other option that can be used together with the VisualEditor.--Micru (talk) 01:16, 5 November 2013 (UTC)
 * Yes, I also thought about this. +1 Micru :) Cornel24 (talk) 16:26, 12 November 2013 (UTC)


 * The resize arrow shouldn't change the size to full screen. It should have several size steps (2-3) before changing to full screen.--Micru (talk) 01:16, 5 November 2013 (UTC)
 * I disagree: instead to have to click many times to see the full screen it, it could be easier to have some links to click to change the image in the desired format, like it happens in Flickr. See for example here, where you can choose the format of the picture in the section "Sizes". --Daniele Pugliesi (talk) 06:29, 9 November 2013 (UTC)


 * I prefer much better other color schemes and designs like the one used in "Picasa Viewer". Related images could be shown in a gallery on the lower part.--Micru (talk) 01:16, 5 November 2013 (UTC)
 * +1 Shubhamkanodia (talk) 14:12, 6 November 2013 (UTC)


 * Give more room to the image. Other sites (500px, Flickr) are handling this far better. --Frank Schulenburg (talk) 21:05, 7 November 2013 (UTC)


 * TALK PAGE! - Wikipedia is all about read-write capability and when I have this option enabled it makes it LESS write and MORE read. A button that links to the existing talk page ANYWHERE would be nice, otherwise I think this is a great tool. Victorgrigas (talk) 04:00, 25 November 2013 (UTC)
 * I agree that the Talk Page should be more easily visible. I think when scrolling down a tabbed interface would work well. The default tab being "Info" and then a second tab called "Discussion" which would load the talk page in-frame. This will look better once Flow is released, but generally I think adding it in now would be preferable to later. --Nicereddy (talk) 01:42, 3 December 2013 (UTC)


 * It loads photos sloooooowwwwly. For me (on a fast connection and a fast computer), images take between 3 seconds and about 25 seconds to load.--Ragesoss (talk) 03:40, 8 November 2013 (UTC)
 * Me too. Way too slowly. --Another Believer (talk) 03:44, 8 November 2013 (UTC)
 * Maybe we can solve it giving the possibility to change the image resolution. --Daniele Pugliesi (talk) 06:29, 9 November 2013 (UTC)
 * Or maybe have a preview with a lower resolution and only if user wants full screen load the picture in best resolution. Some users have slower connections, others faster, somebody access from smartphones, others from tablets and so on. I think it's appropriate to have a standard resolution for every category of devices. Cornel24 (talk) 17:39, 10 November 2013 (UTC)
 * Perhaps whatever's loaded so far could be shown on the screen, like how loading images are typically shown? --Yair rand (talk) 03:46, 13 November 2013 (UTC)
 * yep, would a VipsScaler implementation help ? Slowking4 (talk) 03:09, 15 November 2013 (UTC)


 * The file information should be balanced centrally with the image, instead of jutting to the left. The layout seems to divide in the middle between the metadata (on the right) and the description (on the left), but the metadata is much more compact than a typical description, making the whole text area feel lopsided.--Ragesoss (talk) 03:40, 8 November 2013 (UTC)


 * The transparent background against the file information is distracting. I would prefer that the text have an opaque background.--Ragesoss (talk) 03:40, 8 November 2013 (UTC)
 * Agreed. --Another Believer (talk) 03:46, 8 November 2013 (UTC)
 * The entire page should be overlaid with a darker semi-transparent color -- 80% black, for instance -- with the text in a white box. Lightboxes tend to work that way, for good reason. equazcion � 09:02, 8 Nov 2013 (UTC)
 * Totally agree, dark grey or black semi-transparent background would be the best. It's easier on the eyes and allows to focus on the image. Mayast (talk) 21:27, 22 November 2013 (UTC)
 * Another voice for dark semi-transparent background. This is how most lightboxes do it and it works well. —  Scott  •  talk  13:45, 25 November 2013 (UTC)
 * I would prefer no transparency at all: just show it in another page. --Daniele Pugliesi (talk) 06:29, 9 November 2013 (UTC)
 * Yes, I'm agree too. No transparency will fit better. Or why not let the user choose what he wants? Just to have a checkbox. :) Cornel24 (talk) 17:49, 10 November 2013 (UTC)


 * Each field has its own issues mostly due large variety of Commons:Infoboxes and how they are used. Some good galleries to try: Musée_du_Louvre:Inventory or Stroop_Report
 * Primary Info ( shown above the image):
 * File name - I think this one should link to the file itself so if other links fail (like for this image), this one should be always there.
 * Author - should work with creator templates like here, might need to distinguish between the photographer and the original artist, like here or here. It works here but not here. If author is "unknown" than it is hard to tell what is unknown about the image since nothing says that this field is an author. Some usernames can be also be confusing like User:Vsop.de. Another example: J. Stroop is not the author of this photo only the report this photo come from.
 * Source - source can have large variety of inputs, like here. Anything more complicated than "own work" or "self-photographed" should be skipped or replaced with "see image", so we do not get situations like with this. Source of this image seem to be too long and irrelevant.
 * License Info I think this one works fine: some licenses are recognized like CC-BY others are not and are linking to the page.
 * Secondary Info ( shown below the image): this image is missing all secondary info
 * Description sometimes like in this photo description was not found.
 * Uploader name is this the first or last uploader? I removed a lot of watermarks over the years, but some minor change like this should not make me the uploader. May be both?
 * Creation Date very few date formats seem to be recognized, like here, or here giving "Created on Invalid Date" message when date is quite clear.
 * Hope this helps. --Jarekt (talk) 17:39, 8 November 2013 (UTC)


 * I filed a few of these as bugs: 57307 (date formats), 57308 (multiple uploaders), 57311 (description missing). Will come back for more later. --Tgr (WMF) (talk) 16:56, 20 November 2013 (UTC)


 * The "Use this file" option should generate the proper attribution for use outside Wikimedia sites, according to the license of the file. Rsocol (talk) 19:29, 9 November 2013 (UTC)


 * I think it would make sense if clicking a photo with the middle mouse button (MMB) would open it in a new tab, as opening it in the Media Viewer intuitively happens through LMB. For people editing Categories or looking for fast access to the full-sized file, this would avoid having to go through the right-click menu. (Browser tested: Chrome) Julian Herzog (talk) 19:05, 13 November 2013 (UTC)
 * Thanks, works now. Julian Herzog (talk) 11:19, 24 November 2013 (UTC)


 * The Close button (the 'X') should be on the opposite side of the image frame. It's counter-intuitive for it to be on the left side. FreeRangeFrog (talk) 04:54, 20 November 2013 (UTC)


 * Easier/clearer way to get the full-size image. I think that's what a lot of users click on an image for. At the moment, you do this by following the licencing link. I'd ideally like to see a link that does it directly, though. BTW, I basically like the feature. FormerIP (talk) 00:45, 22 November 2013 (UTC)


 * Cool but don't force this to be the default setting without let the option to the user to deactivate it. I'm from the Wiktionnaire (french wiktionary) and on our project click on image redirect automatically to Commons, and it's kind of practical when we are contributors. Vive la Rosière (talk) 01:45, 22 November 2013 (UTC)


 * I suggest to put a frame around the Media Viewer : as it stands now, it looks kind of messed-up, scattered, to me. --Daehan (talk) 10:11, 22 November 2013 (UTC)


 * With the newer layout, where you need to scroll below the 'fold' to read the more information, i'm missing a queue that this is an action I should take. My mac doesn't draw scrollbars, unless I'm scrolling, so i'm not being visually informed of the presence of this information, and even if i put scrollbars to render always, it's still not very visible. Suggest downward facing arrows somewhere in the bar above the fold to indicate that there is more content, i need a queue to be made aware of this 'pagination' action that is expected of me. TheDJ (talk) 18:11, 26 November 2013 (UTC)
 * I think adding a "View more" button on the bottom right of the bottom toolbar, which would automatically scroll you down, would work well. I agree that this isn't very obvious right now. --Nicereddy (talk) 01:39, 3 December 2013 (UTC)


 * Title of image should link to information page, Copyright title ("CC BY-SA 3.0" for example) should link to information on what that specific license entails. Even better would be if, when clicking the copyright license title, a simple dialog appeared describing what the license permitted. Currently, the license links to the image's dedicated wiki page and the title of the image does nothing. Personally, I think this is confusing for the common user. Image showing what part I'm referring to (imgur link because I didn't want to go through the trouble of uploading to Wikimedia, apologies): http://i.imgur.com/4RTPayo.png --Nicereddy (talk) 02:28, 3 December 2013 (UTC)

Closing the window
I feel weird that the "X" to close the view is on the top left and not in the top right. Of course, there is nothing inherently wrong with this. Barcex (talk) 17:58, 9 November 2013 (UTC)
 * +1 I expected the closing X on the top right position too. Raymond (talk) 21:38, 9 November 2013 (UTC)
 * +1 I expected too the closing X on the top right, as it is usual in most programs. Codex December 3, 2013


 * That's where it'll be in the next version, see Multimedia/About Media Viewer.--Eloquence (talk) 21:54, 9 November 2013 (UTC)
 * I don't feel such discomfort, maybe because I'm left-handed and right-handed too. But, I'm agree that most users expect the closing X at right. Cornel24 (talk) 16:14, 12 November 2013 (UTC)
 * It probably should be consistent at least. For me that button is too flat. No hover highlight feedback for instance. TheDJ (talk) 09:15, 22 November 2013 (UTC)

I expected the window to close if I click on the empty space that is available very much in the surroundings of the viewer. Looking for an X is very slow and annoying (even if it was in the right corner, where I'd expect it to be). --2003:63:2F00:D800:98DD:D5CA:240B:868A 14:16, 22 November 2013 (UTC)
 * In most lightbox scripts the image can be closed by clicking on the "X", clicking on the background (my usual choice), or pressing "ESC". I think that those other options should be introduced here as well. When I used the Media Viewer for the first time, I spent at least a few seconds clicking on the background, until I noticed the "X"... Mayast (talk) 21:27, 22 November 2013 (UTC)
 * +1 to close the lightbox by clicking on the background. I'm too lazy to move pointer over the close button and click, I just want to click Face-smile.svg -- LLM (talk) 21:33, 22 November 2013 (UTC)
 * Agreed - this is standard behavior across lightbox scripts. —  Scott  •  talk  13:42, 25 November 2013 (UTC)


 * Merged into this thread from another thread.

The "x" should be at right and the full screen at left. No ? --SleaY (talk) 00:12, 22 November 2013 (UTC)
 * I blame designers, who use Macs. :)
 * In all seriousness, the new version (on mediawiki.org RIGHT NOW) has the close button on the right side, inside the image. --MarkTraceur (talk) 01:22, 22 November 2013 (UTC)
 * The version on English Wikipedia has the X box on the left side (top left corner, next to the image). As a lifelong PC user (don't go all holy wars on me, I'll consider switching the day my library of video games works on a Mac and not a day before that), the placement of the close box is disorienting. Sven Manguard (talk) 03:22, 23 November 2013 (UTC)
 * End merged thread.

Some usability suggestions: The X shouldn't change position based on the size of the image. The X shouldn't be visible only on hover. These two things make the user have to 'hunt' for the function, hoping it's available somewhere. The effect is I feel 'stuck' in full screen mode. Worse, the image is in a slightly different spot each time based on image size. Please no more roll-over on new usability designs. Don't hide functionality. Display the X in the top right hand corner of the screen. Visible at all times. MarkJurgens
 * +1. Additonally close on clicking empty space. --2003:63:2F21:B200:CE2:8A44:3B29:E754 09:29, 5 December 2013 (UTC)
 * +1 same feeling of being stuck. Always display the "x" and at the same place. I also think viewer should close when clicking on the background (like to say "I want to go back to the page in the background, which is the article page). --Pannini (talk) 23:30, 8 December 2013 (UTC)


 * Not sure if someone said it but you guys need to leave the X visible, a user shouldn't be hovering the mouse around to close an image. That's just plain bad design --Camilo Sanchez (talk) 15:34, 10 December 2013 (UTC)

Description should be on the top
Hi! I'm Himanis Das of English Wikipeida, I find the Media viewer quite in-acceptable because when I opened a file through it, the Source info appears in the top between the close 'X' and 'View license' button; and the Description info is present in the left side in the bottom of the file opened.

No! The description info should be in the place of source info. It'll allow people to access easy understanding of the file rather than gaining knowledge where from the respective file has been derived.

Drew: Am I correct ?

Himanis Das (talk) 08:05, 14 November 2013 (UTC)
 * We decided to put the description lower because, while the description may better explain the image, it will often also be very long. It's hard to reserve enough space for the image when the description takes up a bunch of screen real estate. We are considering putting the caption in the interface, though - would that be better than e.g. the title of the image for articulating its purpose? --MarkTraceur (talk) 01:35, 22 November 2013 (UTC)


 * I, personally, would prefer the description to be placed under the image. That's where it is usually placed in typical lightbox scripts, and after many years of surfing the Internet and seeing hundreds of websites and galleries, I got used to that. So I would think that many other users did, too. I also agree that descriptions are sometimes long. Image title should be at the top, not the description. Mayast (talk) 21:34, 22 November 2013 (UTC)

Media Viewer size problem
Hi, Trying the new Media Viewer & it doesn't all show up (see image), To browser zoom in & out would be a pain so hoping it could be fixed?

Thanks Davey2010 (talk) 00:35, 22 November 2013 (UTC)
 * This should be fixed in the second version coming out very soon, and already deployed on mediawiki.org - try opening the thumbnail you created on this page with the viewer (you may need to enable the preference in Special:Preferences), and let us know if it's better. --MarkTraceur (talk) 01:19, 22 November 2013 (UTC)
 * Wow that's alot better definitely, Apart from this it's great! )
 * Thanks for your help, Davey2010 (talk) 02:14, 22 November 2013 (UTC)
 * No problem! That's what I like to hear :) --MarkTraceur (talk) 03:09, 22 November 2013 (UTC)

Load image instantly
A thumbnail of the image has already loaded when entering the Media Viewer, so why not load the thumbnail first (it'll be big and blurry), and the higher resolution one will be displayed when it has loaded. Skalman (talk) 07:31, 22 November 2013 (UTC)
 * +1. It took 20 seconds to load the second image from Multimedia/About Media Viewer. Helder 14:14, 22 November 2013 (UTC)
 * Was just about to suggest this myself. A scaled-up blurry version is better to look at than a spinny loading widget. —  Scott  •  talk  13:30, 25 November 2013 (UTC)

Licensing and attribution
I have several problems with the media viewer: --B (talk) 13:51, 22 November 2013 (UTC)
 * 1) The "Use this file on another website" has a relative link to the image description page - "/wiki/File:Donna Shalala - Knight Foundation.jpg".  That link is not going to work if you are using the image on another website.
 * 2) Many images are not suitable for reuse on every conceivable website.  For example, fair use images should definitely not have anything encouraging people to reuse them.  And even some of our licensed images - if it's not public domain and not creative commons, then we shouldn't encourage someone to use it without reading the detailed licensing information.  If you just embed a GFDL image, for instance, you are probably not in compliance with the terms of the license.
 * 3) It's not obvious which thing on the popup is the author.  Unless you already know who the author of a particular image is, you're going to think that the uploader is the author and would incorrectly attribute that person.
 * 4) We've been telling photo contributors that if someone clicks on an image, it will take them to the description page, which will show their license, attribution information, etc.  Now, that's not necessarily true any more.
 * 5) It doesn't actually do anything useful for the reader - they are already one click away from viewing an enlarged version of the image ... you've just made the click do something different.
 * Ich empfinde den Link für eine externe Seite bei "Diese Datei weiterverwenden" auch als eher schwierig. Bei CC-BY-SA soll vom Verwendenden eine Namensnennung erfolgen, aber darauf wird er nicht hingewiesen. Wenn diese Namensnennung in spezieller Form erfolgen soll, sieht er das nicht einmal. Er kann einfach einen Link kopieren. --C. König, 23. November 2013
 * This is absolutely vital. Any software hosted by Wikimedia should meet not only the legal requirements of attribution, but should provide an example that respects the spririt of the licenses by providing meaningful and easy to find attribution. The summary page does not name the author or link to their user page. The software shouldn't go out of beta until this is added. -Pete F (talk) 23:31, 30 November 2013 (UTC)
 * +1, and then some! The new viewer is very attractive, but unfortunately it optimizes the graphic display by making the attribution information less visible. We need to compensate for this by adding an image credit section along with the references on the article page. Can adding an image credit section to articles be automated somehow as a part of this project?
 * We need to be proactive about making image attribution visible because it is so important to image donors! The software should not go out of beta without consulting with our donor partners on this question. Djembayz (talk) 06:50, 1 December 2013 (UTC)

I love this but it's not for me
This is a tremendous gadget, and I honestly can see it being deployed as the default with very few changes from how it is now. I would ask, however, that if this does become the default, there is a way to turn it off. As someone that works with files, when I click on an image, I want to go directly to the local file description page (i.e. as it functions now), because the work that I'm doing with files happens on that page (and because my internet is so bad right now that the extra loading time for the large versions of images will be problematic.) So yeah, I think that for 99% of the people that use Wikipedia, this is a great thing. But for the 1% of people that spend a lot of time in the File namespace, doing the behind the scenes stuff, please make sure that there's a way to skip the lightbox. Sven Manguard (talk) 03:34, 23 November 2013 (UTC)


 * I like the idea a lot, but I'm not seeing how it's improving on just going to the image description page in the first place. For one thing, every image I've clicked on (using Firefox 16 so far) doesn't appear that much larger in the lightroom screen. I sort of sit there feeling disappointed. I've never clicked on a picture and ended up feeling disappointed before lol. Loads way too slowly, but I think that's been said. Also, I would've liked a darker screen around the image, but at least it's not bright white. Keraunoscopia (talk) 07:26, 23 November 2013 (UTC)


 * You should try the newer version on MediaWiki.org - it's much bigger. We're also working on getting it to load faster by helping test this RfC in a limited fashion, which should make the load time a little better. A dark background is on the way (as always, I blame the designers!) --MarkTraceur (talk) 18:51, 23 November 2013 (UTC)
 * I've added an image to this section for people to quickly see what you're referring to. It's definitely better than the version currently live on wikipedia.org - thanks. —  Scott  •  talk  13:37, 25 November 2013 (UTC)


 * Sven, thanks for the qualified support :) it wouldn't be unreasonable to allow a preference to be turned off, switching off the lightbox. We have a lot of improvements coming to this project in the coming weeks, so I'd urge you to forego final judgement until then, but it would be technically trivial to keep an opt-out preference around for those of you who dislike the new experience - as long as we come to that consensus, I guess (i.e. I can't promise it, sorry). --MarkTraceur (talk) 18:51, 23 November 2013 (UTC)
 * On English Wikipedia, at least, there's almost always a consensus for things being opt-out when there's a valid reason for people to want to opt out. In this case, there certainly is, and I can imagine both file workers and admins wanting to be able to skip over the lightbox in order to do their work. Sven Manguard (talk) 04:43, 24 November 2013 (UTC)
 * Why not add a modifier key to the click, that would bypass lightbox and take you straight to the description page. Easy to do, simple to learn for advanced users, doesn't bother the rest of the users. TheDJ (talk) 18:03, 26 November 2013 (UTC)
 * Adding an off switch also doesn't bother the rest of the users. I don't like modifier keys, because I prefer to do as much as possible with the mouse. It's also very tedious for someone that, on some days, will view 200, 300 images in rapid succession, to have to constantly use a modifier key. Sven Manguard (talk) 19:57, 26 November 2013 (UTC)


 * Do you typically open these in background tabs? Just curious, because if you do, that should already bypass the media viewer (it only triggers on a direct click).--Eloquence (talk) 01:51, 27 November 2013 (UTC)


 * Yes and no. In certain tasks, like when I work with portals, I do open in new tabs. When I'm reviewing individual images as part of NFCC work, though, I open up one at a time, not in a new tab. Although, if there isn't an off switch, I suppose I can do those as new tabs too. Sven Manguard (talk) 05:20, 27 November 2013 (UTC)
 * Same here. I just thought of an other possibility to investigate. You could have a hover effect, and have a small area that would open the description page. Bigger than the magnify icon, because that's too small a hit target, but still no more than just a fragment of the image itself. If consistently positioned, then that might also work. (basically exactly as gmail shows an image attachment these days) TheDJ (talk) 07:52, 27 November 2013 (UTC)
 * That sounds more complicated than an off switch, and would also needlessly slow me down. I don't like that idea. Sven Manguard (talk) 00:32, 2 December 2013 (UTC)

Caption or title at the bottom?
I would have thought that the title of the image is less useful than the caption that was there before the image was enlarged. Particularly for a scientific article, the cation often annotates features of the image. This would be a genuine improvememnt over the old system whereby you could eith look at the caption or the enlarged image but never both at once. Evolution and evolvability (talk) 11:42, 9 December 2013 (UTC)

What new Media Viewer features would you like to see?

 * In the Light box I think it would be nice if the image is a link to the Commons file-page. Ainali (talk) 08:52, 2 November 2013 (UTC)


 * In Ligh box mode, clicking outside the boundraries of the light box should return you to the article. Ainali (talk) 09:07, 2 November 2013 (UTC)
 * +1 --Daniele Pugliesi (talk) 06:34, 9 November 2013 (UTC)
 * +1 Skalman (talk) 07:23, 22 November 2013 (UTC)
 * +1 MAssaf (talk) 23:35, 9 December 2013 (UTC)


 * Add left and right arrows to navigate to other media in the article.--Micru (talk) 01:16, 5 November 2013 (UTC)
 * I agree to this proposal in the case you click on the image in a Wikipedia article. When instead you click the image inside a Commons category, the left and right arrows have to be used to navigate to other media in the category. I would really appreciate this function. --Daniele Pugliesi (talk) 06:29, 9 November 2013 (UTC)
 * +1 Skalman (talk) 07:23, 22 November 2013 (UTC)
 * +1--Saehrimnir (talk) 19:05, 23 November 2013 (UTC)
 * +1 This, that and the other (talk) 09:37, 6 December 2013 (UTC)
 * +1 --Underlying lk (talk) 03:32, 7 December 2013 (UTC)


 * Support for multiple page documents (Djvu, PDF, PPT, etc). For some inspiration you can take a look to the IA Book reader.--Micru (talk) 01:19, 5 November 2013 (UTC)


 * Zooming would be useful. --FocalPoint (talk) 16:26, 6 November 2013 (UTC)
 * +1 --Daniele Pugliesi (talk) 06:34, 9 November 2013 (UTC)
 * +1--Saehrimnir (talk) 19:05, 23 November 2013 (UTC)
 * +1 --Stu Phillips (talk) 18:03, 28 November 2013 (UTC)
 * Why not show license at the media page?--Zhangjintao(Connect to me at zh.wikipedia.org 04:41, 7 November 2013 (UTC)


 * Annotations, for images like File:1911 Solvay conference.jpg. See Commons:Help:Gadget-ImageAnnotator --Jarekt (talk) 19:33, 8 November 2013 (UTC)


 * It could be nice a function to see a slideshow of the images in the same Commons category or in the same Wikipedia page, showing the next image after few seconds. It could be great a tool to create a personalized list of pictures, then see the slideshow and to save it as a .ppt file, so it can be used to create easily and quickly some presentation to use offline (for example by the teacher in a school during a lesson). --Daniele Pugliesi (talk) 06:45, 9 November 2013 (UTC)


 * In the absence of zooming, a direct link to the raw file/full size image would help. --Duplode (talk) 01:15, 22 November 2013 (UTC)
 * +1. Actually, even with zooming, a direct link to the raw file will be immensely useful if I need to save the image, edit it, and so on. Dllu (talk) 06:03, 1 December 2013 (UTC)
 * +1. Agree with Dilu. It is often desirable to examine the full resolution image. Zero0000 (talk) 10:05, 1 December 2013 (UTC)


 * Close viewer when clicking on the large empty spaces around it and not having to search a tiny "X" somewhere. --2003:63:2F00:D800:98DD:D5CA:240B:868A 14:17, 22 November 2013 (UTC)


 * I would like to have the lightbox note somehow that an image is a Featured Picture on the local project that the image is being viewed from. Just because. Preferably, it should note both local and Commons FP status, although that might be harder. Sven Manguard (talk) 03:30, 23 November 2013 (UTC)


 * Please show the filename! This is vital for editors who want to add the image to an article and for people doing template work. — Mr. Stradivarius  ♪ talk ♪ 03:55, 23 November 2013 (UTC)


 * Different resolutions. MrScorch6200 (talk) 17:10, 1 December 2013 (UTC)


 * Please provide a link to the actual file page on Commons or wherever the image is hosted. John Reaves (talk) 03:01, 3 December 2013 (UTC)


 * When paging with the arrows trough images on a page, use short css transformations to go from one image to the next. That would give the change less of a 'pop' effect when there are Aspect Ratio changes. TheDJ (talk) 13:47, 14 December 2013 (UTC)

Notes?
Is it possible to display the image notes like on commons? --Hans Haase (talk) 01:07, 22 November 2013 (UTC)
 * You probably mean annotations? If so, we have a bug open for that: 56666 --MarkTraceur (talk) 01:19, 22 November 2013 (UTC)

Some more feedback
Please feel free to ignore/strike if I'm missing something obvious here.
 * Sunrise over fishing boats in Kerala is missing the license at the top right corner, and says date is invalid;
 * Lu3 TIFF file - missing license;
 * San-Francisco-Aerial-View-Photo-5 - invalid date;
 * Tropical Fish Aquarium - California Academy of Sciences - missing license;
 * Pentacle SVG file - missing license;
 * BetaFeatures-MediaViewer-Thumbnail - missing license;
 * Animated GIF - took a lot to load the first time, missing license;
 * 05 Micro-Macro - missing license;
 * Sydney Tower Panorama - missing license;
 * Nijkerk-grote-kerk-toren-2011- - missing license, invalid date. --Elitre (WMF) (talk) 14:15, 4 November 2013 (UTC)

There is no obvious interface for getting to a larger version or the original media file. This is particularly important in screenshots, for example, which may be unusable in the thumbnail or lightbox size and resolution. —Michael Z. 2013-11-06 15:49 z 


 * 1) It takes much longer (10 seconds or more) than normally to load/view an image. Normally i open files in a new tab which is quicker.
 * 2) The date given is wrong. For example "Erstellt am -2147483629. Dezember 1969" (=photo taken december 1969) when you view the photo commons:File:Hattingen - Rathausplatz - Rathaus 03 ies.jpg on Ennepe-Ruhr-Kreis. I don't know from where the media viewer could have taken this information. The photo was made in 2010 see its information template and the exif informations. Holger1959 (talk) 21:32, 7 November 2013 (UTC)

There is already a user script for that - Picture Popups
There is already a user script that displays images in larger sizes on the article pages - en:User:Zocky/Picture Popups. It's advantage is that it does not gray out the whole article when showing the images, instead they open in windows which you can move around the page and you can open multiple such windows. My suggestion is to allow this behaviour in Media Viewer as well. --V111P (talk) 21:37, 6 November 2013 (UTC)
 * media viewer hangs on large images (over 50mb) ? integrating VipsScaler would be a nice fix ? Slowking4 (talk) 03:32, 8 November 2013 (UTC)

Sorry
Simply adjust the settings in preferences (appearance / file) for quick viewing and better than what is proposed by default. I use daily (1280x1024) and 300px for miniature; Its gives a result better and faster than what is proposed by this beta. The caption data is very fragmented and they are not directly accessible. This gadget is slow and I do not see the interest. --Archaeodontosaurus (talk) 13:36, 8 November 2013 (UTC)

Invalid date
All my pictures have correct dates and times in the information template. The information template translates the dates correctly to different languages. However, this viewers says that the date is "Invalid". Barcex (talk) 18:05, 9 November 2013 (UTC)
 * Same for me, all my images are tagged with the global standard time and date notation (2013-09-07 17:59:30). In the normal view, this is interpreted correctly, the Media Viewer regards it as "invalid". Julian Herzog (talk) 15:08, 10 November 2013 (UTC)
 * Interestingly, as I just found out, it's interpreted correctly here: commons:File:Eurojet EJ200 for Eurofighter Typhoon PAS 2013 01 free.jpg, only the displayed format of the date is still wrong then (what's "6/19/2013"?). I have my date display preference set to "2013-11-10T15:11:17", but that seems to be ignored. Julian Herzog (talk) 15:12, 10 November 2013 (UTC)
 * +1 Im deutschsprachigen Layout ist die Zeitangabe auch nur als "invalide date" zu sehen. --C. König, 23. November 2013
 * Curiously, if I set my language in English I get the date in Spanish: "Created on jueves, 30 de mayo de 2013". Setting my language in Spanish, or any other one, I get "Invalid date" for the same image. --Vriullop (talk) 09:58, 26 November 2013 (UTC)
 * Because invalid date on my photos?--Paulo rsmenezes (talk) 11:15, 1 December 2013 (UTC)

The "x", again
So the X moved to the right side, good. But there are still problems (Firefox): Skalman (talk) 07:21, 22 November 2013 (UTC)
 * Before the first image has loaded it is visible on the top right
 * While an image is loading, the X isn't visible (important if you're on a slow connection)
 * You have to hover the image to see the X (annoying for small images) (why can't it be in the very top right always?)
 * I imagine that people with poor eyesight will have problems seeing the X. Add more/darker shadow
 * It goes off the screen if I scroll down to view (I suggest position:fixed)

After enabling the feature, I also have this comment: --Pannini (talk) 23:20, 8 December 2013 (UTC)
 * the "x" should be always visible, displaying it only on hover needs discoverability, for small images this is not obvious.
 * I think research has to be done to decide if it should be placed at top right of the image, or top right of the viewer page (always at the same place, independently from the image size).

I agree on the visibility/discoverability issue. I opened an image, and then when I wanted to close it I couldn't figure it out right away. First, I tried clicking on the background page - many similar image viewers support that as a way to close the image. Then I tried scrolling to see if somehow the close link got hidden off an edge of the page. I only found the X when I happened to move the mouse over the image on the way to somewhere else. I didn't think to hover over the image, because it seems strange to click on the image in order to close it. Katie Ryan A (talk) 15:35, 9 December 2013 (UTC)

Jiggle when resizing the window
Resizing the window (e.g. by going to fullscreen mode) makes the UI jiggle around a bit (Firefox). Skalman (talk) 07:21, 22 November 2013 (UTC)

Some tiny issues

 * The "x" still appears on the upperleft corner. I guess it hasn't been fixed yet. Btw I use Google Chrome.
 * When the there is a template on the space "author" it looks weird. (see Smit.Faces of Lorises.jpg).

--Andresisrael (talk) 14:31, 22 November 2013 (UTC)


 * I believe that the update hasn't been rolled out to all wikis, but do you have this issue also on this wiki (example page with images). Skalman (talk) 17:12, 22 November 2013 (UTC)

Text too small in Monobook
In both the older Wikipedia version and the newer version here, the text is very small when using Monobook. This seems to be a common issue with new features. Jay8g (talk) 04:30, 23 November 2013 (UTC)

Full screen
When I view images full screen, pressing the full screen button, there is a delay before the image is full screen, there shoudl be a timer or something that signales that this process is happening.Victorgrigas (talk) 03:58, 25 November 2013 (UTC)

Arrow keys for scrolling
Usually inside a page I can use the arrow keys to scroll up and down in the page. When the Multimedia Viewer is open, it seems these keys are captured, and the scrolling isn't working. TheDJ (talk) 22:25, 26 November 2013 (UTC)

View on Commons link doesn't
Clicking on the "Learn more on Wikimedia Commons" link during picture preview actually takes the user to a fullpage view of the image on Wikipedia. She then has to click a new link "description page there" to be actually taken into Commons. -- Brianhe (talk) 08:34, 27 November 2013 (UTC)
 * Came here to give this feedback as well. I would like the link to go directly to the file on commons.wikimedia.org. The file's read-only mirrored page on en.wikipedia.org is never useful. --Delirium (talk) 08:32, 28 November 2013 (UTC)
 * For wikis where is local upload disabled is local file page totally useless. Please, give direct (and bigger)link to commons. JAn Dudík (talk) 08:12, 3 December 2013 (UTC)
 * Seconded, please link directly to the Commons page and save us from having to click to the next page every time.--Underlying lk (talk) 15:57, 5 December 2013 (UTC)
 * I noticed this is bug 57842 on Bugzilla but it doesn't reflect this bug-finder count. - Brianhe (talk) 17:07, 10 December 2013 (UTC)

Single & double click modes
I would like too see

1. A reader oriented mode activated by a single click: Show only what the ordinary user is interested in, show the picture in a clean as possible environment!

2. An editing "mode" activated by a double click, working as today, goes directly to Wiki Commons

Svjo-2 (talk) 16:15, 30 November 2013 (UTC)

Twinkle
Hi again,

Seems either this or Nearby Pages feature is causing Twinkle not to work?

parsererror "OK" occurred while contacting the API.

All day it's not worked for me & as soon as I disable both beta features it works....

Cheers Davey2010 (talk) 00:42, 23 November 2013 (UTC)
 * Davey already knows this, but for others who might be looking for an answer.. This problem is in Nearby pages. It is being tracked in 57556. TheDJ (talk) 18:05, 26 November 2013 (UTC)

Regarding list of known bugs
Can someone change the "many known bugs" link in this page's lead section to one that does not require a Bugzilla login (probably using the regular Bugzilla search feature, which does not appear to generate a  query parameter on other installations I've tried) or explain why this is not possible? --SoledadKabocha (talk) 01:12, 23 November 2013 (UTC) (+clarified 18:28, 23 November 2013 (UTC))
 * Does [//bugzilla.wikimedia.org/buglist.cgi?resolution=---&component=MultimediaViewer this link] work for you? --TMg 13:50, 25 November 2013 (UTC)
 * Yes, that works. --SoledadKabocha (talk) 01:41, 29 November 2013 (UTC)

Categories?
When you click on an image and the viewer displays it, the categories in which the image lives are not included. Unless I am overlooking something? --Another Believer (talk) 19:30, 23 November 2013 (UTC)
 * You observed correctly. TheDJ (talk) 20:05, 26 November 2013 (UTC)

Date with time
The creation time of is shown as "Invalid Date" on this article from it.wiki. I think it's because the time is included in the date field, it should be fixed because (at least until some time ago) Wikimedia Commons' Upload Wizard detected and inserted the time by default when uploading a file. --Una giornata uggiosa &#39;94 (talk) 22:31, 26 November 2013 (UTC)

Request - file page link
I like the viewer to view but I cant click through to the image page can a link be added so that its one click away. Gnangarra (talk) 01:24, 27 November 2013 (UTC)

"Invalid date"
Hi.

Instead of displaying "Invalid Date" (e.g. for ) you should display "&mdash;" or add it (the message) to translations and change it to something more appropriate for end-users (e.g. "unknown" or something like that). --Nux (talk) 18:02, 27 November 2013 (UTC)

Slow
It seems that this is slower to show the image than simply loading the whole page which takes away the appeal for me. Rmhermen (talk) 21:42, 27 November 2013 (UTC)

Tears of Africa


 * +1, I have the same impression. File Description Site loads almost instantly with image. Media Viewer needs like 3 seconds to display image. --2003:63:2F00:D800:946B:F52D:F075:BC6D 11:30, 28 November 2013 (UTC)
 * This has mostly to do with the fact that the image thumbnail used for file pages is often already generated. For the lightbox it still needs to be done while it is requesting the image. The developers are aware of this and working on a solution TheDJ (talk) 12:54, 28 November 2013 (UTC)
 * Too slow to be useful Shoshie8 (talk) 21:03, 29 November 2013 (UTC)

Invalid date (RuWiki)
What's happened with date in Russian Wikipedia? All files dated: -2147483629 December 1969. --U-leo (talk) 15:53, 28 November 2013 (UTC)

Sideways scrolling opens Media Viewer
When scrolling sideways with the arrow keys or touchpad, the media viewer automatically opens, even if no image is selected. This seems to be an issue with the new scrolling through images feature. This only shows up on the newer version here, not the Wikipedia version. Vector, Firefox, Windows 7. Jay8g (talk) 18:50, 7 December 2013 (UTC)

A black background is not the best idea (at least for transparent images)
On transparent images, a black background doesn't work well. On images with black parts, you can't even tell they are there. On other transparent images, it simply looks bad. Jay8g (talk) 03:42, 10 December 2013 (UTC)

OT?: Activation in Preferences does not work
Using here Opera Version 12.16 Build 1860  Plattform Win32  Betriebssystem Windows 7 (Opera/9.80 (Windows NT 6.1) Presto/2.12.388 Version/12.16) gives me no change in the checkbox for activating the helpertool. Thanks, Conny (talk) 09:47, 11 December 2013 (UTC).

Dark-on-light.
This doesn't work if the dark-on-light preference (" Use a black background with green text on the Monobook skin") is enabled. This is increasingly useful mode (lower energy use with OLED displays). At en, its at https://en.wikipedia.org/w/index.php?title=Special:Preferences&success=1#mw-prefsection-gadgets under Appearance. (Can someone confirm this is reproducible? I have a lot of custom settings.) By 'doesn't work' I mean the text is unreadable.--Elvey (talk) 21:55, 11 December 2013 (UTC)

Maintenance icons in the viewer
This is hardly a major issue, but maintenance icons such as probably should not appear when navigating between the article's images.--Underlying lk (talk) 09:13, 13 December 2013 (UTC)
 * Agreed. icons that are children of blocks with class .metadata should probably be excluded. TheDJ (talk) 13:01, 14 December 2013 (UTC)

Thanks for your great feedback!
Thank you all for your wonderful feedback, everyone! Especially Daniele Pugliesi, Cornel24, MarkJurgens, Ainali, Elitre, Micru, Ragesoss, Jarekt, Holger1959, Barcex, Raymond and Julian Herzog, to name but a few. Your detailed feedback is absolutely invaluable to us -- and much, much appreciated :) We are passing on to our development team recommendations to address the issues you raised. Some of these issues were already on our to-do list, but your comments are helping us give these tasks a higher priority. We are now fixing the most urgent bugs, and will be rolling out more tweaks and new features in coming weeks, with our next release due on 21 November, and more updates in December. If you have any more suggestions or questions, you are welcome to post them here, and/or on this Media Viewer discussion page. I am out of office until 19 November, but you can contact our community liaison Keegan (WMF) or lead developer Mark Homquist with any urgent requests. Thanks again for your amazing suggestions, and for all that you are doing to help improve this tool as a collaboration between the community and the foundation! Fabrice Florin (WMF) (talk) 03:11, 12 November 2013 (UTC)