Extension talk:Media Viewer/About/Archive01

This discussion archive includes comments made about version v0.1 of the Media Viewer, from November 2013 to February 2014. Most of these comments were addressed by new versions of Media Viewer -- and other requests were either postponed or not accepted, for a variety of practical reasons.

To give feedback about the current version now in development, please contribute to this discussion.

Many thanks to all contributors to this discussion for your helpful feedback and thoughtful recommendations!

Users of Version 1.0 were asked these questions:

What do you like about Media Viewer?

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)

More intuitive

• I think that this is a more intuitive experience for the casual reader than the current behaviour of clicking on a link which takes you to a page about the image.--NHSavage (talk) 22:40, 18 December 2013 (UTC)

• I find this to be a much more efficient way of viewing content than leaving the main article or taking up space in my generally overcrowded tab bar. Why didn't anyone think of this earlier? --Yea55 (talk) 18:46, 19 December 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.

Also quicklinks to other image sizes are a consideration if we want users to reuse images more easily. 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 [1] 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)
  • Agreed. Also, if there is a lot of text/information below the image, concretely not a lot, just 2-3 sentences, then just a part of that text is shown. To see all that info you must scroll down. I don't say that it's hard or uncomfortable to scroll down, but it's weird to see that chunk of incomplete text. Maybe it's better to make it pop up when user's cursor is on the up directed arrow and make that arrow a little noticeable, in rest just to show general info about that picture. Cornel Punga (talk) 12:38, 31 January 2014 (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)
    • Now I have the issue that MMB-clicking does nothing at all. It was perfect until a few days ago. 79.204.231.133 16:22, 14 December 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)

• On the Media Viewer, images uploaded by partners (GLAM for example) or during a partnership do not have a visible mention of the partnership. The uploader may not be the partner (upload by a bot) And nobody will click on the "Learn more on Wikimedia Commons" link to see if a partner uploaded it or released it. Trizek (talk) 13:42, 18 December 2013 (UTC)

• Touch screen image swipe would be a great feature on mobile devices! The < > arrows are small on a phone. (Until Apple makes a bigger screen for me)

Also, the 'x' seems a little too small to touch on a phone. It takes me a few attempts to close the window. MarkJurgens

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

@Barcex and Raymond: That's where it'll be in the next version, see Multimedia/About Media Viewer#Next Version.--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 -- LLM (talk) 21:33, 22 November 2013 (UTC)

Agreed - this is standard behavior across lightbox scripts. — Scott • talk 13:42, 25 November 2013 (UTC)

Agreed, again. This is how Facebook does it as well, which is probably the most familiar experience to most users, and... well, it's a standard. Why should we deviate from the standard? To make the web more difficult? One last thing -- Google+ will not allow you to click in the empty space to exit, and that is extremely frustrating--for me, at least. Not that anybody uses G+... DanHakimi (talk) 02:41, 19 January 2014 (UTC)

This is bugzilla:56402 (Exit lightbox when clicking on backdrop). –Quiddity (talk) 03:20, 19 January 2014 (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)

I agree with this, at first I was not sure how to close the window with the image in. I resorted to using the escape key, which worked, but I think that to roll it out for general use, you probably need the way to close the window to be very clear.--NHSavage (talk) 22:49, 18 December 2013 (UTC)

...and if you use a touchscreen and no keyboard, you're trapped... I'm using a tablet, and had to go to this current page and conversation to understand there is a cross appearing on mouse hoover. Generally, events triggered by mouse hovering with no alternative (such as menus who can't be clicked) should be avoided, due to the generalization of touch screen devices. Epok13 (talk) 22:55, 28 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

File:WikipicbetaDavey2010.png

New Beta Media Viewer issue

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#mw-prefsection-betafeatures), 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:

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.

--B (talk) 13:51, 22 November 2013 (UTC)

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

An image for testing the version installed on MediaWiki.org.

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)

MarkTraceur: 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)

@Sven Manguard: 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)

I also would like a possibility to turn off this option. I more often want to see full description page than to see bigger image. BartekChom (talk) 00:36, 10 January 2014 (UTC)

Motivation?

I'm not finding anywhere a compelling motivation for this. The feature as currently implemented dramatically reduces the information that's easily accessible about an image, and (despite claims to the contrary) puts the user in a "hard mode" which requires new and unfamiliar controls and actions to recover from. Everything that I can see and experience about how this works is a clear negative from both a usability and information point of view. What am I gaining in exchange? It "looks neat" seems to be the core of most positive reactions. What am I missing? Does this actually do something useful or provide ease of use that I'm not seeing.

A clear statement of the goals for the feature that we could evaluate, and against which we could measure the implementation would be helpful. Aldaron (talk) 13:51, 23 December 2013 (UTC)

Problem with location maps

One thing I have just noticed is that location maps where a background image has dot added on to it to indicate locations does not work well with this feature as it only shows the background map. See for example en:List of monastic houses in Devon. This is probably tricky to fix as you have the same problem at the moment - clicking on the image only shows the backgound map as that is the actual image.--NHSavage (talk) 16:10, 2 January 2014 (UTC)

Broken transparent pictures

The generated background of transparent pictures is black, which makes it impossible to read any text in many pictures. If transparency was translated to a white background - or better yet, the good ol' grey checkers - That would be perfect. ElŞahin (talk) 03:19, 8 January 2014 (UTC)

Yes. See the first diagram under w:en:Nacre#Physical characteristics for example. Timothy Gu (talk) 19:19, 12 January 2014 (UTC)

Regression with where clicking an image goes...

With a note that people may react negatively to change, including one of positive nature, please understand that clicking an image took me to the image page, before, with author and licensing information. Now, the behaviour suddenly changed... --Gryllida 02:58, 30 January 2014 (UTC)

Additional click

... with people being more likely, perhaps, to be reluctant to click again to reach the file information page. --Gryllida 02:55, 30 January 2014 (UTC)

‘License’?

It's further made worse by calling the link in a quite unintuitive way, show license, with people perhaps could find file info more interesting? (The info contains other things than the license, it has description, it has author, it has history. Those are all valuable informations.) --Gryllida 02:55, 30 January 2014 (UTC)

Keeping people on solid ground

Now, new contributors will also be likely to be disoriented more, without understanding where the image is uploaded to (the image page rather clearly shows that it's at Commons.) --Gryllida 02:55, 30 January 2014 (UTC)

The right arrow

...takes to an unrelated image. Where does that come from? What would the reader expect? What does he or she actually want to see? Lack of logic, unintuitive, unexpected, sorry. --Gryllida 02:55, 30 January 2014 (UTC)

Ways to preview?

Please look how other websites do it, probably additional widgets or hints in the corner of the image. (I don't find examples at the moment, later more on this if I do.) --Gryllida 02:55, 30 January 2014 (UTC)

Preview size

Would it perhaps leave 10% of page width free at each size, so it's relatively easy to click outside of the preview. --Gryllida 00:55, 1 February 2014 (UTC)

Drawings

As stupid as my GIMP expertise is, that's what I could come up with.

Preview button

Note that this is not necessary; it might be acceptable to just change the on-click behaviour, granted it's sufficiently verbose (per the second image).

The preview

The preview is distinguished by these characteristics:

• Occupies only a part of the screen. You see that you still are near the article somewhere. You're not lost.
• Clicking outside of the preview closes it. You don't have to run like a headless chicken trying to locate a single X button.
• I did this on a light background. It may be possible to do it on a dark background instead, but I wouldn't; people have been watching this on white background for years and I don't regret them.
• Detailed description from Commons is shown.
• Author is shown, with license short name in braces.
• 3 prominent links are present:
  • File details and history — link to its commons page.
  • Commons — link to Commons homepage.
  • a sister project — link to WP:SISTER (or an equivalent, eg WS:SISTER at Wikisource).

--Gryllida 03:50, 1 February 2014 (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)
  • +1 (I went into a little detail of this below). -Pete F (talk) 18:33, 26 December 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)
  • +1 Pete F (talk)
  • +1 129.94.239.191 05:54, 10 February 2014 (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)
  • +1 (as per Daniele Pugliese -- the reader should be returned to wherever he/she came from, just like pressing "Esc" or clicking the close "X".)
  • -1. Painfully confusing for a person who sees the article first time. 129.94.239.191 05:54, 10 February 2014 (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)
  • +1, the reader should have as consistent an experience as possible, and having a Media Viewer for some kinds of image files but not others would be confusing. I also agree that the Internet Archive/Open Library people would be great to consult with on this, they have been doing great stuff in this arena with free software. -Pete F (talk) 18:33, 26 December 2013 (UTC)
  • +1, 129.94.239.191 05:54, 10 February 2014 (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)
  • Links to several resolution versions, as exists on the current media page, might be preferable -- see my comments below at #Image resolution, downloads, and license. -Pete F (talk) 18:33, 26 December 2013 (UTC)

Thanks, guys. Based on your feedback, we are starting work on this Zoom feature, which we hope to include in v0.2, if time allows. Fabrice Florin (WMF) (talk) 09:11, 19 February 2014 (UTC)

• Why not show license at the media page?--Zhangjintao(Connect to me at zh.wikipedia.org 04:41, 7 November 2013 (UTC)
• +1 129.94.239.191 05:54, 10 February 2014 (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)
  • -1 129.94.239.191 05:54, 10 February 2014 (UTC)

Thanks for this recommendation. We have included View files in slideshow mode for the next version v0.3, tentatively scheduled for next quarter. Fabrice Florin (WMF) (talk) 09:11, 19 February 2014 (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)
• +1, see my further comments on this below at: #Image resolution, downloads, and license -Pete F (talk) 18:33, 26 December 2013 (UTC)

• • +1 129.94.239.191 05:54, 10 February 2014 (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)

 Comment: this is a duplicate of the second bullet point of this section. -Pete F (talk) 18:33, 26 December 2013 (UTC)

• • +1; And these large empty spaces should be there instead of black thing everywhere ... 129.94.239.191 05:54, 10 February 2014 (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)
  • +1, supporting the collaborative practices and processes of our projects is an important value. -Pete F (talk) 18:33, 26 December 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)
  • It looks like this has been addressed. -Pete F (talk) 18:33, 26 December 2013 (UTC)
  • +1 129.94.239.191 05:54, 10 February 2014 (UTC)
• Different resolutions. MrScorch6200 (talk) 17:10, 1 December 2013 (UTC)
  • +1, see my more detailed comments below at #Image resolution, downloads, and license -Pete F (talk) 18:33, 26 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)
  • +1 129.94.239.191 05:54, 10 February 2014 (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)
  • -1, annoying 129.94.239.191 05:54, 10 February 2014 (UTC)
• Pre-loading the next image(s) would facilitate the navigation. Currenttly, loading the next image is only done when the next arrow is pressed. Pre-loading is invisible to the user and greately increase the loading perception time. --Pannini (talk) 13:43, 22 January 2014 (UTC)

Thanks for this suggestion. We are now working on this feature to preload the next and previous images. Fabrice Florin (WMF) (talk) 09:11, 19 February 2014 (UTC)

• Displaying a loading indication and/or a low resolution version of the image before the full image is displayed would help the user better understand that something is loading. --Pannini (talk) 13:43, 22 January 2014 (UTC)
  • +1, show indication 129.94.239.191 05:54, 10 February 2014 (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: bugzilla:56666 --MarkTraceur (talk) 01:19, 22 November 2013 (UTC)

What bugs or issues have you found with Media Viewer?

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 commons: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)

   This date shown (in December 1969) is in fact 2010 seconds before 1 January 1970 00:00 UTC, which seens to be used like the base date for Unix timestamps (or the time() and localtime() API's and similar in standard C language libraries).

   "2010" alone is not interpreted as a year, but as an Unix timestamp (Unix timestamps are not used in image description page for the date field, dates containing only digits, possibly without any separators as in this case where there's only a year) should be interpreted using ISO parsing rules). Additionally the display format used to render it should not add any unspecified precision (here we just have a year, but NO month, NO day of month, NO day of week, and NOo time of day in hours, minutes, seconds). Parsing should be done like date properties in Wikidata.

   Verdy p (talk) 20:10, 5 January 2014 (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):

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

Skalman (talk) 07:21, 22 November 2013 (UTC)

After enabling the feature, I also have this comment:

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

--Pannini (talk) 23:20, 8 December 2013 (UTC)

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)

Wouldn't the "x" be easiest to find if it was in the top right corner (not of the image, but on the very right of the browser space, on black background, always visible). Of course, if the image dimensions are right, it will extend to the very right corner of the space. Then, the current system makes sense. But because the dimensions have to match perfectly for that, it's a rare case anyway. Julian Herzog (talk) 10:25, 28 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)

I presume the bug report above records that the software inserts an extra https: in the address. Someone should fix it! Chris55 (talk) 15:06, 5 January 2014 (UTC)

View on Commons in non-English Wikipedia

Another error: in Polish Wikipedia you are taken to page "File:Plik:Filename.ext" and informed that doesn't exist (e.g. [2] links to [3]). It happens because "Plik" means "File" in Polish and should be omitted, but it isn't. I suppose it may happen in other language versions as well. Szczureq (talk) 13:19, 7 January 2014 (UTC)

It's fixed, thanks. Szczureq (talk) 15:14, 15 January 2014 (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 bugzilla: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 cmdtype=runnamed 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 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)

I agree that this is a significant problem. If one of the goals is to help the reader browse and discover content on Commons, categories seem like an indispensible tool for doing that. Flickr offers tags and sets in its Media Viewer. Are we content to offer nothing analogous on Commons? -Pete F (talk) 18:19, 26 December 2013 (UTC)

Right. It's well pointed. I was thinking that something is wrong, something is missing :D Very, very important to have access to images in Commons.

Date with time

The creation time of this picture 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 '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 [4]) you should display "—" 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)

Invalid date in Media Viewer (Russian Wikipedia)

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)

How this image should look

How it looks in Media Viewer. Notice that you can't tell the black parts are there.

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)

Yes! See for example he:טריצרטופס, images comparing size of man and dinosaur. Kotz (talk) 07:30, 17 December 2013 (UTC)

+1 on that, for transparent illustrations, the standard background should be white or light grey. Julian Herzog (talk) 10:20, 28 December 2013 (UTC)

I agree as well. It is pretty useless for the exploded view of the en:International Space Station as well.--NHSavage (talk) 15:03, 31 December 2013 (UTC)

Not to mention tens of thousands of chemical structures – most of them are pure black on transparent. --Anypodetos (talk) 12:16, 26 January 2014 (UTC)

I also agree. This is the reason I've disabled the media viewer, and the reason I've come to this talk page. --Keithonearth (talk) 18:25, 28 January 2014 (UTC)

(Me too) I have been getting tired of getting a black screen and having to go back to open a new tab to see information. Disabled! Nanite (talk) 13:52, 8 February 2014 (UTC)

• +1, black text on transparent images disappears completely, see [5] for an example of this.--Underlying lk (talk) 06:21, 14 February 2014 (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 bug

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 an 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; this wiki doesn't have the gadget. (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)

I completely agree with this. Either white or perhaps with the option to switch? Evolution and evolvability (talk) 09:04, 15 December 2013 (UTC)

The black background in the large display area may be OK, but the image itself clearly needs a white background instead (or at least the skyblue-whte checkers pattern) for images with transparent backgrounds.

Those transparent images (or half-transparent with alpha channels) are unreadable. the bacground can be black ONLY for photos that don't have any transparencies (most of them are JPEG), but this black background is a nuisance for most graphics, and notably most SVG images, and many PNG or GIF images.

If needed, include a bacground color selector in the Media Viewer:

• include at least the choice between "white", "black", "light checkers", or "automatic";
• you may also include a color chooser, or a lightness gauge from 0% to 100% for using any gray between back and white;
• you could also allow the user to specify another bacground image by giving its File:Name, that background mage can combine with a background color behind it);
• for the "automatic" choice, use "black" only for JPEG images or videos; use "white" for PNG, GIF, SVG, PDF, DJVU; if GIF images or JPEG2000 include an alpha channel or maps a transparent color, use the "light checkers" as default;
• for the default choice among these options (settable by a clikable button "set as default") use a stored user preference;
• if there's currently no stored user preference (or the user is not logged in), use the choice "automatic" by default (however even a non-logged in user may want to have a semi-permanent choice, kept at least in a session cookie).

Note The user default should be separate between the standard website version and the mobile site versions (where black is more desrable to preserve battery.

In fact the mobile version of Wikimedia sites (or the Wikimedia applications available on application stores) should also include a preference for using a dark skin with a black background (and light text) as most as possible (unfortunately we have lots of infoboxes that would need tweaking for supporting an "inverted video" skin, specally tuned for mobile users (OLED color displays are draining the battery too fast with too much white color; on Android for example, the default UI is black with gray texts and very small uses of plain white).

We desesperately need full support for a Vector-like dark skin supported by default in MediaWiki. This developement should also be made for accessibility (i.e. an option for high contrast, for people having difficulties to read, and a personal setting for defining the base font size, which is REALLY too small, even smaller than the browser's default font size).

Verdy p (talk) 19:32, 5 January 2014 (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)

On Wikipedia, links don't go to Commons

In the current version of the Media Viewer, if you view a file on Wikipedia, the "Learn more on Wikimedia Commons" and uploaded by links go to the corresponding pages on Wikipedia, instead of on Wikimedia Commons like they should. This will be particularly confusing in cases where the user who uploaded it to Commons doesn't have an account on that wiki.--Sage Ross (WMF) (talk) 21:15, 15 December 2013 (UTC)

This is a bug that also affects Meta-Wiki, the links to "Learn more on Wikimedia Commons" are in fact going to the page File:File:Name on Commons. Verdy p (talk) 19:35, 5 January 2014 (UTC)

Suppressing CTRL-click

On my Windows 7 + latest Firefox setup, I *think* the viewer is suppressing the CTRL-click ("open in new tab") option, which I use frequently. This seems like unintentional behaviour :) Jarry1250 (talk) 11:38, 16 December 2013 (UTC)

The same goes for Shift-click and Ctrl-shift-click. Skalman (talk) 11:41, 16 December 2013 (UTC)

It even suppresses it on the magnify icon. TheDJ (talk) 13:47, 16 December 2013 (UTC)

+1 on Chrome / ubuntu => To open in a new tab : No Ctrl + Click, no middle click. Symac (talk) 15:02, 18 December 2013 (UTC)

+1, as mentioned above, on Chrome/Win7. No middle-clicking or any other direct way of opening a file in a new tab. This basically doubles the amount of clicks I need to navigate files. Julian Herzog (talk) 10:29, 28 December 2013 (UTC)

Get gallery with unrelated extra picture when clicking on a single picture?

I clicked on the image in Lucy Maria Field Wanzer and it gave me a popup of the image (good!) but also a right arrow that, when clicked on, showed me a completely different, unrelated, unlinked image. Not sure how that got in there? Weird bug. -LuisVilla (talk) 19:33, 19 December 2013 (UTC)

Note: I just fixed the link in the above comment, which I assume was meant to go to English Wikipedia. -Pete F (talk) 18:57, 26 December 2013 (UTC)

@Luis, I figured out what's going on. The Media Viewer, in this context, uses the arrows to display all images in the source article; in this case, there are exactly two images in the article. The "mystery image" is a tiny thumbnail in the w:en:Template:Women's-History-stub template, so it is displayed when you click the right arrow. -Pete F (talk) 19:46, 27 December 2013 (UTC)

Resolved, mostly -- unless it seems worthwhile to exempt images contained in stub templates. -Pete F (talk) 19:46, 27 December 2013 (UTC)

Thanks for fixing the link, Pete. I actually do think it seems worthwhile to exempt images contained in stub templates - it will be confusing for users to see these images treated as "first class" members of the article when they aren't. -LuisVilla (talk)

(See the section below #Maintenance icons in the viewer as well, maybe there is a way to label stub images to prevent this. -Pete F (talk) 23:45, 4 January 2014 (UTC))

I agree with Luis that this issue needs to be solved. Not just images from stub templates, but almost every transcluded image should be excluded from the MW, including base images for dot maps and the icons from flag templates.--Underlying lk (talk) 03:39, 8 January 2014 (UTC)

This is all fine by me -- I only marked it "done" because it seems far less of a problem than some of the other stuff discussed on this page. But you're right, it is a problem, and it shouldn't be all that hard to solve. -Pete F (talk) 22:04, 30 January 2014 (UTC)

"Learn more on [sitename]" goes... straight to commons

In an interesting reversal from earlier times when "learn more on Commons" went to the local page, now "learn more on [sitename]" goes straight to the Commons page.Jay8g (talk) 02:32, 31 January 2014 (UTC)

Hangs my Browser

I've given up on the Media Viewer, every time I tried to use it, it hangs my browser. Using Windows Explorer 9. Wee Curry Monster (talk) 10:30, 1 February 2014 (UTC)

Scrolling broken in Monobook

In Monobook, the information scrolls up beyond the bottom of the screen (see screenshot). Monobook, Firefox 26, Windows 7 Jay8g (talk) 20:14, 9 February 2014 (UTC)

Link

Hi, the link on images says "Learn more on Wikipedia", but links to Commons. Thanks, Matty.007 (talk) 20:25, 4 February 2014 (UTC)

• Seems to be fixed, but in ruwiki it requires grammar:prepositional while seems to be grammar:genitive. Ignatus (talk) 19:12, 7 February 2014 (UTC)

Malware from Media Viewer?

I don't know if this is true or not, but my PC start experiencing a problem regarding loading videos from Niconico ever since I activated Media Viewer on December 5, 2013 which was a Thursday. The videos loaded properly before it was activated, but it doesn't completely load properly even after disabling Media Viewer. The PC can still load videos from YouTube and BBC, so only Niconico videos have the problem. Can anyone help investigate on this? I really appreciate if someone could rescue me from this troubling abyss, since I'm pretty much low on solutions now. Thank you. --Bumblezellio (talk) 20:50, 8 December 2013 (UTC)

Media Viewer bug

Hello, When Media Viewer is activated we can't play a diaporama. I tested it here. 92.89.123.3 12:10, 12 December 2013 (UTC)

Thank you for the feedback, I filed a bug for this enhancement here. Keegan (WMF) (talk) 22:56, 21 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)

Fabrice, can you clarify when you are planning on making the new beta live on Commons and other sites? I think the version there is still "v1"-- it looks very different from the "v2" on this site. Was there ever an update in November / December? Has it been pushed back? -Pete F (talk) 23:33, 4 January 2014 (UTC)

Image resolution, downloads, and license

The media viewer currently does not indicate to the viewer that other (specifically higher) resolutions may exist, or how to download them. Since reuse is an important value of the Wikimedia movement, some useful information about downloads should be available on the main screen. As it currently stands, clicking on "use this file" also does not indicate that there are higher resolutions available; one has to know to click "Learn more on Wikimedia Commons" in order to find them.

To somebody not familiar, "Learn more on Wikimedia Commons" is not a very appealing link -- this is the kind of language that many sites use to link to a very generic "about us" or "about this site" page, not specific information tailored to a specific image (as is the case here). I am concerned that an Internet savvy (but not Wikimedia savvy) audience will completely overlook this highly useful link.

The "CC BY-SA" (or other) license abbreviation looks like a Martian language to most readers. It should be introduced with text like "You are free to reuse this image in accordance with this license" (which should automatically detect when the file is Public Domain, and say something more like "You are free to reuse this image, to which nobody has ownership rights.") Also, this text should probably be next to the "Use this file" link -- the license is currently in a different part of the UI.

Some parts of this, but not all, are addressed in v2, available on mediawiki.org. -Pete F (talk) 23:41, 4 January 2014 (UTC)

Personality rights are currently not addressed in the UI. The WMF board and many community members have expressed that it's important for files to indicate clearly, where needed, that the subject has consented to its broad publication. This tool should reflect that desire.

Longtime readers of Commons and other MediaWiki-based sites may be very used to the idea that clicking the image itself brings you all the information available about the file. In this case, once one is in the Media Viewer, clicking on the photo itself does nothing. In order to respect the principle of least astonishment (as an idea, not a policy), this should be altered so that the second click on the photo (i.e., the first click within the Media Viewer) takes one to the expected place, i.e. the full Commons description page.

The following issue is addressed in v2, visible on Mediawiki.org. -Pete F (talk) 23:41, 4 January 2014 (UTC) Finally, a small detail: the "X" used to close the box is in a slightly different place than on sites like Flickr and Facebook. Conforming to evolving design consensus seems like a good idea. On those sites, the "X" is in the upper right corner of the window, not the upper right corner of the image. (Nice to see that the escape key works as expected, though.) -Pete F (talk) 18:13, 26 December 2013 (UTC)

addendum This last one might not seem significant depending on what file you're looking at -- I suggest a narrow, portrait-oriented photo like File:Washington County Fair drop ride 3 - Hillsboro, Oregon.JPG. (The dark background also contributes to the difficulty finding the X.) -Pete F (talk) 18:54, 26 December 2013 (UTC)

Hi Pete F, we are now developing a brand new version of 'Use this file', which will address many of the issues you raise above. The key specifications for this improved feature are included in these three Mingle tickets:

• Share this file
• Download this file
• Embed this file

We appreciate all your detailed suggestions above, and are taking them into consideration. This doesn't mean, however, that we will implement them all. I would be happy to discuss them with you in greater detail in our upcoming IRC 'office hours' chat on Fri. Feb. 21 at 10am PT -- or set up a separate call to go over this, since you have so many ideas that would take too long to respond to individually in this discussion. Cheers. Fabrice Florin (WMF) (talk) 09:11, 19 February 2014 (UTC)

Author info difficult to read

I can't read the author info (eg: A.Savin (userpage · contact) - Own work) which balck on black or blue on black background. See https://commons.wikimedia.org/wiki/Commons:Featured_picture_candidates/File:Isabelle_Faust_B_09-2012.jpg/2 for example. Jkadavoor (talk) 15:59, 30 December 2013 (UTC)

Now OK; thanks. Jkadavoor (talk) 07:16, 31 December 2013 (UTC)

Attribution in a little more depth

It seems like some improvement has been made around attribution since this discussion was started (but it's hard to tell what has changed, I haven't seen any response on this from the dev team?)

As it currently stands, the name of the "author" appears below the file name. This is a good place for it, but in many cases it is not apparent that this is attribution to the author/photographer etc. Many of these will be Wikimedia usernames, which at first glance might not appear to represent a person. We also have readers and authors from many different cultures, so a name is not always recognizable as such.

I'm not sure what the best way to resolve this is, because in some cases "photographer" might be the best title, in others "producer," etc. But it seems to me we have used "Author" pretty consistently on Commons, and it works OK. So I think unless somebody has a better idea, the name should be preceded by "Author: "

-Pete F (talk) 19:20, 31 December 2013 (UTC)

Thanks, Pete F. Our current plan is to add a 'By' label in front of the author name, which should clarify that this person is responsible for creating that image, without taking up any more space than needed. This is also consistent with the attribution practices of Creative Commons, and therefore with other parts of our user experience. Fabrice Florin (WMF) (talk) 09:11, 19 February 2014 (UTC)

Spinning wheel

The spinning wheel icon looks broken/strange on black background. --Atlasowa (talk) 12:19, 9 January 2014 (UTC)

+1. Especially since the GIF isn't of that great of a quality. Timothy Gu (talk) 19:22, 12 January 2014 (UTC)

The spinner has been removed in the latest version which is currently running on this wiki, and I think now on Enwiki, too. :) (For other spinner-related bugs, see bugzilla:54814 and bugzilla:28318.) –Quiddity (talk) 20:14, 19 January 2014 (UTC)

licence link

• There is almost no licence info on mediaviewer page, just a View license link which is broken (facepalm. "Learn more on Wikimedia Commons" link is broken too). Mediaviewer informs me that "This file is lacking author information." and nevertheless invites me to Use this file.
• OTOH, here i get good licence info, CC BY-SA 3.0 with a nice CC logo (but the link is broken too).
• Mustn't the licence term be linked, right at the mediaviewer page? Not 3 degrees/clicks away. This is legal stuff and it is important for reuse.
• You need to facilitate licence-compliant reuse and sharing. Have a close look at how people share/link to "Wikipedia images" on twitter. Hotlinking to upload.wikimedia.org, different sizes etc. Use this file doesn't explain how to share. --Atlasowa (talk) 13:02, 9 January 2014 (UTC)

  It seems Media viewer failed to understand all licenses, including new CC BY 4.0/CC BY-SA 4.0 Jkadavoor (talk) 08:54, 13 January 2014 (UTC)

• @Atlasowa: Hi! I'd like to assure you that we're working on it - most CC licenses should be supported now, but if you see issues with that you should definitely continue to file bugs. Other licenses are harder to support, but we have them in the backs of our minds. We will support a greater range of license information before releasing out of beta. However, the license terms being linked from the media viewer appears to be a non-starter - too many files are licensed under CC-BY-SA but have different restrictions that can only be found on the file page. That's why we decided to link to the file page itself. As for use-this-file, we specifically include the license and author/source in the HTML version of the share feature, but admittedly haven't found a good way to include attribution in the raw URL ones. In this iteration we're actually redesigning the reuse feature, but there's definitely still room for more redesign work that could include more work towards license compliance. Thanks for your thoughts! --MarkTraceur (talk) 20:04, 9 February 2014 (UTC)

Black bar in Media Viewer covering up description text

There's a black bar covering up my text.

See image. Sorry if this was already brought up. Sven Manguard (talk) 21:03, 14 January 2014 (UTC)

@Sven Manguard: Is this still an ongoing problem? It was for me a while ago, but seemed to be fixed for the last few weeks. Possibly try clearing your browser cache? (And test it at this wiki, which has 1-week-newer code than Enwiki). If it is still a problem, tell us your browser/OS please? Thanks. –Quiddity (talk) 20:17, 19 January 2014 (UTC)

@Sven Manguard: Actually this seems like a bug relating to the image in question not having source or author, so the description is the first thing that shows up after the title. I will see if I can reproduce this locally. We will track this bug at Mingle. --MarkTraceur (talk) 19:54, 9 February 2014 (UTC)

Thanks for your feedback!

Thank you all for your thoughtful comments about the Media Viewer! Your suggestions are really helpful to our multimedia team, and we have been acting on many of them already.

Some of your key recommendations have been outlined in this feedback section of our main product page, then turned into concrete action items on our Mingle project management system.

For example, requests for a larger image size (by MarkJurgens, Daniele Pugliesi, Frank Schulenburg) and a darker background (Ragesoss, Another Believer, equazcion, Daniele Pugliesi, Cornel24, Kelvinsong) have already been addressed in the current version. Concerns about slow image load (by (Mono, Arcane21, Ragesoss, Another Believer, Daniele Pugliesi, Cornel24, Holger1959) have been the focus of a couple development sprints devoted to improving performance in a variety of ways (see #154, #155, #126 or #146, to name but a few possible solutions). We're also taking to heart the many recommendations that we improve the 'Use this file' panel to attribute files correctly, with a quick summary of author, source and license (Amada44, Elitre, Church of emacs, Rsocol): these are being addressed in this new 'Use this file' panel which includes attribution-friendly Embed, Download and other functions. Requests for a Zoom feature are now being designed on this card. Other requests for a pop-up explaining the license terms are now under development (see cards #118 and #197); and we're preparing a whole new batch of features to support slideshows and other file formats, as described in this updated 'Next Version' section of our overview page for Media Viewer.

These are just some examples of how your insights are being incorporated in our release plans. We're also reviewing your longer-term recommendations, which will take more time to implement, but are under consideration nonetheless. Our focus this quarter is on completing the current version v0.2 and starting work on the next version v0.3 of the Media Viewer, to provide a better viewing experience for all users.

Sorry if we haven't been more responsive on this page in recent weeks: we have all been busy improving the product, based on your earlier feedback. In a few days, we will invite your comments on an updated beta version v0.2, which we are about to release shortly. As that date approaches, we will start archiving many of the comments above which have been addressed, to reduce clutter and to invite us all to focus on the new features and improvements. To keep up with our work and participate in our conversations, we also invite you to subscribe to our multimedia mailing list. And if you're feeling adventurous, you can test the latest features before they are released, on this beta site, but performance will be much slower on that site (you will also need to create an account, then enable Media Viewer in your Beta preferences).

Thanks again to everyone who has already contributed so productively on this page: keep your great insights coming! Keegan, MarkTraceur, other team members and I will do our best to answer your questions (for a faster response, you are welcome to mention our user name in your comments, so we are notified and can get back to you more quickly). But even if don't always respond right away, rest assured that we are reading your comments and considering every suggestion carefully. :) Fabrice Florin (WMF) (talk) 21:35, 9 February 2014 (UTC)

Thanks! A half of my suggestions weren't there. I've added them in. --Gryllida 05:55, 10 February 2014 (UTC)

I'm particularly surprised that 'make preview bigger' and others are on the list, while I didn't expect it to occupy the whole page. Previously the preview shown on image click (without media viewer) was rather small. Having a small preview benefits the reader as he sees that he did not leave the article and didn't enter a weird new full-screen app. Some might think was "was I hacked?" or "where did I come?". --Gryllida 06:04, 10 February 2014 (UTC)

Thanks, Gryllida. We're reviewing your suggestions and will respond to them once we've heard from team members. As a rule of thumb, we tend to implement features which are requested by large number of users, rather than individual requests by a single community member. For example, I understand you are a big proponent of a proposed 'Preview' function, though I'm not hearing this as being a priority feature from other team or community members. I should also point out that this proposal doesn't match best practices on other top multimedia sites we've been studying for this upgrade. So I am not optimistic that this particular feature would be implemented in the near-term, though we will give it careful consideration for future releases. On the other hand, I'm happy to let you know that we plan to implement other features you are advocating, such as making the link to the file repository more prominent, as well as support for multiple page documents. Thanks again for your interest in this project. Fabrice Florin (WMF) (talk) 01:03, 11 February 2014 (UTC)

It'd be interesting to learn that websites have a best practice of ... occupying a whole page with a preview, with black non-transparent background. I'll watch the presentation, expect it to be interesting. :-) Again thanks for the detail. Gryllida 05:45, 11 February 2014 (UTC)

Transparency

The lightbox doesn't really work that well with transparent images. Might I suggest:

.mlb-image img { /* or using :hover */
 background: url("//upload.wikimedia.org/wikipedia/commons/5/5d/Checker-16x16.png") repeat;
}

or

.mlb-image img {
 background-color: white;
}

or

.mlb-image img {
	background-color: white;
}
.mlb-image img:hover {
	background: url("//upload.wikimedia.org/wikipedia/commons/5/5d/Checker-16x16.png") repeat;
}

• Thanks for the feedback. I'll pass it along to development and we'll see if it helps. Keegan (WMF) (talk) 20:47, 17 February 2014 (UTC)

Towards enabling the Media Viewer by default

It appears likely to me that, whenever the time comes, enabling the Media Viewer by default will be rejected by the Wikimedia community, for reasons deriving from our shared vision for all people to freely share in the sum of all knowledge. I think that would be unfortunate, considering all the good work that has gone into it, so I'd like to point out the high-level issues I see. I hope Fabrice and the engineering team will take a step back as well, and consider adjusting feature priorities accordingly. (Maybe this is already part of the plan; but recent communications make it appear that it's getting missed.)

According to the engineering team, the Media Viewer aims for three goals:

• Provide a richer multimedia experience
• Display images in larger size
• Reduce confusion

These are worthy goals, and I'm sure all serious Wikimedians would support them. When the question gets raised, though, of whether to replace the current default view with the MV, less lofty considerations will come into play: does this new feature sufficiently meet the basic requirements already, more or less, met by the current default view? I think the answer is a decisive "no," and am skeptical about whether the apparent plan for refining the Media Viewer will change that.

What requirements am I talking about? I would summarize them as follows:

1. Are all copyrights and personality rights adequately protected?
   1. Have we met the minimum legal standard?
   2. Have we met the expectations of rights-holders sufficiently that they will feel good about contributing to Wikimedia projects?
2. Are (potential) reusers shown a clear path forward?
   1. Are they given sufficient guidance in overcoming practical obstacles to reusing materials presented by the Media Viewer?
   2. Are they given sufficient guidance in meeting relevant legal obligations?
   3. Are they given sufficiently convenient access to the right links, including a file download link?
3. Have we appropriately exposed the strengths of Wikimedia Commons to our users? For instance:
   1. Commons provides strong assurances that all its content is freely reusable, with minimal requirements, unlike Flickr and other repositories. Is that expressed clearly?
   2. Commons is more organized than media repositories like Flickr (eg, category system).
   3. Commons invites anybody to contribute materials that serve its educational mission.

While my list above may or may not be complete, I am pretty sure it more or less reflects what most Wikimedians will have in mind, when considering whether or not the Media Viewer should be enabled by default. Whether the Media Viewer has exciting and worthwhile new features is certainly important, but it is subordinate to meeting the minimum standard of reflecting our shared values, at least as adequately as the current default media view does.

Current efforts to refine the Media Viewer seem (to me) to be missing the significance of these basic considerations. I would expect that, unless the engineering team prioritizes feedback relating to basic adequacy (reflected, more or less, by my numbered list above) more highly than feedback about improving functionality, the Media Viewer will not (and should not) be approved as a default feature by the Wikimedia community. -Pete F (talk) 04:36, 16 February 2014 (UTC)

I'm not a developer of this project, but do know quite a bit about it where it's coming from and I can tell you that at least the first consideration is high on the visibility list of the team. HOWEVER. it is also the most difficult problem to solve and requires a lot of technical work. This work is taking place, but it is not directly visible to most users. This frontend is using a new API to get the information that you are pointing out, and that will be developed specifically to meet these goals. BUT there is still a lot of work to do there and in the way we register licenses and copyrights of files. This project is being used as the driving force to develop this new API. I too would suggest not to enable this for ALL anonymous users until that goal is met, but having it as beta will help garner the feedback that is required to develop the backend systems for license/copyrights/authors.

I have recently met this team and I have great confidence in them. But I too support your statement that the team needs to watch out for the above concerns. Especially the Commons and top 5 wikipedia projects are sticklers for correctness when it comes to legal requirements and EDUCATING users regarding licensing. These aspects need to be extremely well thought out and balanced, so any development would at some point have to be validated against these basic community principals. TheDJ (talk) 11:40, 17 February 2014 (UTC)

Hi Pete F, thanks again for your thoughtful recommendations above, which we are reviewing. We are now hard at work on addressing the first two points you raise above about copyright protection and appropriate tools for re-users. Regarding your third point, Media Viewer already links to Commons in many places, and we will consider making those links even more prominent, while still aiming to reduce confusion for users. We would be happy to discuss your advice in greater detail in our upcoming IRC 'office hours' chat this Fri. Feb. 21 at 10am PT -- and am also open to a separate call to go over this 1:1, if you like. Thanks again, and regards as ever. Fabrice Florin (WMF) (talk) 09:11, 19 February 2014 (UTC)

President of the United States .

The President of the United States is no longer Obama (as listed on MediaWiki. It is Donald Trump.