Extension talk:Media Viewer/About

Join the Media Viewer Consultation


Greetings!

We would like to invite you to participate in a global consultation about Media Viewer.

Please take a moment to join the discussion and add your suggestions for improvement. The goal of this consultation is to review the current status of this project and identify any critical issues that still need to be addressed. The consultation will remain open until September 7th, and will help us plan our next steps, based on your feedback.

To learn more about planned development tasks for Media Viewer, visit this improvements page, where our team will post regular progress updates.

Thanks for helping improve the viewing experience on Wikimedia sites. :) Fabrice Florin (WMF) (talk) 21:31, 28 August 2014 (UTC)

My browser already has an image viewer
Reinvent the wheel, remove access to crucial information about images, require an opt-out rather than an opt-in. Just recording my discontent with this tool and confused why the community response appears not to be listened to. --99.245.191.227 18:18, 30 August 2014 (UTC)

Usability: prefetch more images for better response times
The media viewer currently seems to prefetch one image: If I view a picture for several seconds, switching to the next one immediately displays it. However, when switching to an image with an offset greater than one, I always have to wait a bit (up to several seconds) for the next picture to display, which is really annoying. This may be related to my not too fast internet connection (2 or 3 Mbit/s), but the media viewer (in my opinion) should also have minimal response times on such a connection. So please prefetch more images to fix this issue. --Simified (talk) 00:43, 31 August 2014 (UTC)

Media Viewer's Handle is just plain in wrong direction
I do not want to enter the discussion about nice/ugly or useful/not useful etc. but just want to point out, that the handle at the lower edge of the browser canvas, the handle to click on for more details on a certain image, it points in the wrong direction. When the details are hidden, in normal mode, the arrow points downwards which is not the direction the drawer would move once clicked. It would move up to reveal the details. This is counterintuitive, feels wrong, misleading. Vice versa.

It originally pointed up, which was counterintuitive to another group of people. We are looking into designs which have no handle (and possibly no drawer) at all. --Tgr (WMF) (talk) 13:02, 3 September 2014 (UTC)

Very annoying, especially when viewing multiple images
I find that it is annoying that when I close an image in the MV, and then use the 'back button' on my browser, it acts like the image was a page, and I have to hit back again. I also do not like not being able to click the image to view the full file. And lastly, I do not know about everyone else, but I happen to like seeing the EXIF info for certain images. If they were shown on the bottom of the MV below the description, it would be fine. --Mcdudeman (talk) 18:05, 3 September 2014 (UTC)

How can i deelete this enervous function?
Execuse me, this is really varry énervant that this popps on the compleet moniteur alldays, i want to have again the old fonction when i can view the explanations Commons page directely! Merci beaucoup!
 * You can disable it if you create an account and go to Special:Preferences on every project you are using. If this is no option, try installing Greasemonkey and tell it to run the code  on all Wikimedia projects. --Stefan2 (talk) 19:23, 5 September 2014 (UTC)

Picture descriptions better, but could we get headers?
I'm happy to see the viewer now shows the description from both the page it appears in and the original page on the Commons (et al). But perhaps we could clarify things by adding headers to the sections so you know which is which? Maury Markowitz (talk) 17:52, 6 September 2014 (UTC)

Crashes
Your media viewer unfortunately repeatedly crashes on my older firefox/linux system. Before that, I never had any troubles viewing the images at WP by clicking on the .jpg-links/images in articles, and I cannot understand at all how this could be "too complicated" for anyone and thus needed a "solution". "Why fix it if it aint broken" comes to my mind, cause now, for me, its broken. In my opinion, you guys have just too much donation money at hand and you are spending it in bad ways. So, uh... thanks for ruining my WP experience, called "progress". :( --87.167.252.140 09:23, 8 September 2014 (UTC)

Die Möglichkeit den Viewer dauerhaft abzuschalten klar sichtbar im Hauptfenster unterbringen und nicht "versteckt"

 * Problem:


 * Proposed solution:


 * Proposal of 93.215.28.67 20:51, 9 September 2014 (UTC)


 * Moved from m:Talk:Community Engagement (Product)/Media Viewer consultation. --Elitre (WMF) (talk) 12:58, 10 September 2014 (UTC)
 * This is already listed as a planned improvement. Best, --Elitre (WMF) (talk) 13:02, 10 September 2014 (UTC)

Media Viewer Consultation Results
Thanks to all contributors who participated in the recent Media Viewer Consultation!

The Multimedia team appreciates the many constructive suggestions to improve the viewing experience for readers and casual editors on Wikimedia projects. We reviewed about 130 community suggestions and prioritized a number of important development tasks for the next release of this feature. Those prioritized tasks have now been added to the improvements list on the consultation page.

We have already started development on the most critical ('must-have') improvements suggested by the community and validated through user testing (see research findings and ). We plan to complete all “must have” improvements by the end of October and deploy them incrementally, starting this week. See the multimedia team's improvements plan and development planning site for details.

As we release these improvements, we will post regular updates on this Media Viewer talk page. We invite you to review these improvements and share your feedback.

The foundation is also launching a file metadata cleanup drive to add machine-readable attributions and licenses on files lack them. This will lay the groundwork for the structured data partnership with the Wikidata team, to enable better search and re-use of media in our projects and many other features. We encourage everyone to join these efforts.

This community consultation was very productive for us and we look forward to more collaborations in the future. Thanks again to all our gracious contributors! Fabrice Florin (WMF) (talk) 01:04, 12 September 2014 (UTC)

Transparent background showing as checkerboard
Once again I would like to point out the undesirability of MV showing the checkerboard pattern for transparent areas of SVGs. When you are viewing a picture, you simply never want to see this. Last time this was raised, it was mentioned that making the background white would break images that have a white foreground. In my opinion, the benefits of having a clean white background for the 99% of images that will work with it outweigh the marginal utility of being able, with difficulty, to discern a crude outline of a rare white image against the checkerboard. Or, to cover all eventualities, MV could have a toggle to change SVG background from white to black. 217.44.215.14 13:18, 15 September 2014 (UTC)

Disabeling does not work
I can't disable this nonsense. Clicking on the button disable media viewer does not change anything.

Comparison with another extension
I asked a coworker sitting next to me which one is better between these two extension:
 * Extension:MultimediaViewer (MV)
 * Extension:FancyBoxThumbs (FBT),

and she chose the second without a slightest doubt, which prompted me to compare the two. As a background, I was showing her the two extensions in our private company wiki, which includes a lot of thumbnails; and it is safe to say that she's not techie, thus represent average visitors of WMF wikis. For those who never uses the FBT, here's the visible comparison with MV (for technical details, see each extension page), which hopefully could be useful for the future development of MV. I will only focusing on features that exist in FBT, but not in MV, and not the vica versa.

Image viewing:
 * MV have black background, while FBT using grey semi-transparent background (with shadowed white box). [Observed on live WMF project also].
 * FBT have smooth pop-up animation
 * (as a result) MV occupy the whole screen, and feels like you're on a different page, while using FBT, the users knows instinctively that they're still on the same page

Closing image window:
 * In MV, the X button is way on the top right corner of the page. For small images, it means too much black background, and X (close) button too far from the image (albeit in a fixed place). In FBT, the X button is right on the top right corner of the image, therefore it is easier to click the X button, the visualization is better, and better for small images. [Observed on live WMF project also].
 * In MV, you can't escape by clicking the area outside the image (i.e. the black background), while in FBT you can (with smooth fade-out animation too).
 * (as a result) Closing the image window is more intuitive using FBT. [Note: Both windows are closeable with Esc]

Transparent images:
 * In MV, transparent images are shown with checkered grey-and-white box (too techie, I think an average Jane would think that the image background is checkered, instead of transparent), while in FBT, it is shown seamlessly (i.e. transparent on white background). Combine the checkered image with black surrounding, it's just plain ugly. [Observed on live WMF project also]. (edit: also previously reported by anon above)

Images with white background:
 * For majority of images with white background (or transparent as above), viewing the image on black-background (MV) is not pleasant at all, and the sharp contrast is just too much for me personally. [Observed on live WMF project also].

Displayed texts:
 * (I can't comment much about this aspect, because I tested FBT in private wiki only, and in private wiki, the image description is almost non-existent)
 * FBT displays the file name with the extension (i.e. XYT.png), while MV doesn't display the image extension (XYZ). Not a major drawback, and probably there's some reasoning behind it, but I don't think there's harm in putting the extension name in the description. [Observed on live WMF project also].

All observation was based on a private wiki installation, based on the extension I downloaded today (MultimediaViewer-REL1_23-fb6216c.tar.gz for MW 1.23) with the observation on live WMF project in bracket. That said, our wiki had been using FBT, and will keep using it for now.

PS: MV Bug report (same steps, but producing different errors on private and WMF wikis)
 * On the private wiki I tested, if I Ctrl mouse scroll up (enlarge), until certain very large size, the image will become very small. If I close the MV, then click the image again, it will still become very small (few pixel wide). To reset it, I can't just reset to the default size (i.e. Ctrl+0), but I had to click the "view original file" (bottom right) icon, and go back one page. [It is not observed on live WMF project].
 * On live WMF project (I tested jv.wp with MonoBook skin), click on an image (like the FA image), and on not so fast connection (or very large file), while the image is not finished rendered yet [key point], enlarge that still-loading image to the maximum, and then reset (Ctrl+0), the image's location now will be below the visible screen, and I can't scroll down, I can't see the description, basically I can't revert it back to normal by normal means. (F12 on Firefox will do the trick though). After the image finished loading, the whole page enlarge correctly, though.

Bennylin (talk) 10:29, 22 September 2014 (UTC)
 * Interesting comparison, Bennylin. I haven't used FancyBoxThumbs, I'll have to give it a whirl. I'll look into your bugs, the detail is certainly appreciated. Keegan (WMF) (talk) 19:53, 22 September 2014 (UTC)

unused images
The Media Viewer would be good tool on this special page. But as far as I can see, it does not work here.--&#91;&#91;User:Bmrberlin&#124; Bernd M.&#93;&#93; (talk) 10:20, 23 September 2014 (UTC)
 * very good request! I filed a bug for the enhancement. Keegan (WMF) (talk) 22:19, 26 September 2014 (UTC)

Hello Mr. Keegan, Nice name. Always reminds me of Kevin Keegan. I'm using the FancyBox now. Installation is simple and does the job of displaying image files very nice. --&#91;&#91;User:Bmrberlin&#124; Bernd M.&#93;&#93; (talk) 06:56, 27 September 2014 (UTC)

There is more behind the scenes …
Hi, I was just wondering how to explain to a new user how she can overwrite a recently uploaded file or how she can nominate a recently uploaded file for deletion, when she gets presented the Media Viewer (which after all, is a viewer) by default. The standard welcome message on commons gives some hints on Made a mistake, but these hints are quite useless with the media viewer. The link More details about this file is tricky to find and you will not expect edit functions behind. Well, answers are appreciated, but improving the features of Media Viewer to help users to cope with mistakes is also appreciated. I feel that the MV also needs a basic (& configurable) menu, e.g. edit button. regards --Herzi Pinki (talk) 11:27, 27 September 2014 (UTC)
 * Hello. Good points about a complicated issue to resolve. At this time there are not plans to develop Media Viewer to be editable since it is not intended to be a substitute for a file page. In the next month even most of the extra metadata that Media Viewer displays is going to be removed in order to create the simple, clean viewing experience that it is supposed to provide. Following that, the More details about this file is going to be much more prominent and clearly labeled both in words and with the Commons icon for context if appropriate. I hope these changes make it much more clear on where to go for file information. As for the scenario you describe with new users on Commons, last month Media Viewer was disabled for all logged-in users on Commons so the instructions in welcome templates and in other places should still work just fine, without confusion. Keegan (WMF) (talk) 20:28, 30 September 2014 (UTC)
 * So, this shitpile that you have inflicted on us will convey even less information? Let us have links from the image or caption directly to the commons page from the picture then! We'll even consider adding a link to this media-viewer for people who want an extra layer of javascript between them and the image file. Why do you like doing this to us? What is wrong with you?


 * Hi Keegan, thanks for answering. Although the button to More Details is now big enough that you cannot oversee it (I consider this an improvement), this will not help in the end for my point mentioned above. As editing is considered to be different from (view) more details. Would it be possible to add an extra button Modify file / Edit file / Edit file description or something like this making it clear that the stuff can be changed? As anywhere else in the Wikiverse? You can move the button /icon to the right border, where there are already a lot of menu entries. Which would be similar to e.g. Flickr. Or scroll in the menu on moving the mouse to the border (I leave details to your UI designers). In general, I think it would be feasible to have a configurable menu (like the one we have in the description page) directly on the media viewer. It also can be moved in on mouse events. Optimally the content of the menu is the same as on the description page (restricted to maybe some subsections like tools), one stop configuration for both. This will allow to trigger the same operations from the Media Viewer Page as from the File description page without the intermediate More Details button. regards --Herzi Pinki (talk) 10:18, 2 October 2014 (UTC)
 * Herzi Pink, sure, these are things that can be tested to an extent. I, for one, am a proponent of the button saying "View and Edit" Details instead of "More" details, but space is a tad limited for wording it seems. There's still room to see through usability what wording works best. The "More Details" will get its chance and then we can check it against click-thru rates to the File page. Keegan (WMF) (talk) 20:48, 2 October 2014 (UTC)

Media Viewer Update: First Improvements
Hi folks, I am happy to announce that we have just released a first round of improvements to Media Viewer, based on community feedback.

The goal for these improvements is to make Media Viewer easier to use by readers and casual editors, our primary target users for this tool.

To that end, we created a new 'minimal design’, with these features:
 * "More Details" button - A more prominent link to the File: page
 * separate icons for "Download" and "Share or Embed" features
 * an easier way to enlarge images by clicking on them
 * a simpler metadata panel with fewer items
 * faster image load with thumbnail pre-rendering

These features are now live on Wikimedia Commons and sister projects, and will be deployed on all Wikipedias this Thursday by 20:00 UTC.

Next, we plan to work on these other improvements:
 * an easier way to disable Media Viewer for personal use
 * A caption or description right below the image

Learn more about these features on the Media Viewer Improvements page. They are based on findings from our recent community consultation and ongoing user research. For more information, visit the Help FAQ page.

We would like to thank all the community members who suggested these improvements. Our research suggests that they offer a better user experience, that is both clearer and simpler -- and that clarifies the relationship between Media Viewer and the File: description page.

Please let us know what you think of these improvements. We will send another update in October, once the next round of improvements has been released.

Onward! Fabrice Florin (WMF) (talk) 23:02, 30 September 2014 (UTC)


 * Clicking on the image at http://commons.wikimedia.org/wiki/File:Wide-field_view_of_the_Rho_Ophiuchi_star_forming_region_in_visible_light.jpg#mediaviewer/File:Wide-field_view_of_the_Rho_Ophiuchi_star_forming_region_in_visible_light.jpg will result in your computer trying to download a 442.61 MB 346 megapixel file without warning. Do we have data on what percentage of browsers will survive that?.Geni (talk) 00:02, 1 October 2014 (UTC)
 * Good call, Geni. That is "problematic" to make an understatement. That danger is inherent in the file page as well; far too many times I've clicked on the image for full resolution without looking at the original file size located below. Media Viewer exacerbates this problem by not even having the resolution size :( The Multimedia team has this on their radar now, Pau is going to start working on usability design to figure out the best way to curtail this. Keegan (WMF) (talk) 19:22, 1 October 2014 (UTC)
 * Thanks, Geni and Keegan! This is not a new issue, as this is the same functionality we have provided for years on the File: page. But Media Viewer makes it a lot easier for users to accidentally load a huge file. So we would like to provide a warning, if we can identify a threshold that is at least partly informed by data and best practices. Does anyone here have data on what an average threshold might be for file sizes that can crash your browser? Or do you know what best practices are on that point? If we can't find reliable data or best practices, we might have to determine this threshold together, based on common sense. In that case, what do you think would be a reasonable threshold when we would start giving the warning? 50Mb or above? 100Mb or above? For now, I just filed this ticket #933 to track this issue. Thanks again for bringing this up, and we welcome any recommendations for solving this issue. Fabrice Florin (WMF) (talk) 19:32, 1 October 2014 (UTC)
 * Double the size of the screen resolution, or triple, but a) not much more and b) no fixed value. --Sänger S.G (talk) 20:45, 1 October 2014 (UTC)
 * NB: why did it take the this huge uproar and you extreme hostility with superputsch to make you finally listen to the communities? Why didn't you engage sooner and waited for making it default until the mayor bugs were eliminated?

Improve the Commons interface instead
You should improve the Commons structure and interface itself instead of creating such autotelic viewer which is an obstacle in the linking from Wikipedia projects to Commons project. The viewer make the Commons categorization (and some othe information from Commons) inaccessible (hidden), offering a nonsensical and useless sequence instead. Moreover, the arrangement and graphics of the viewer are not just better than ones of Commons file pages.

If there is any benefit or advantage of the viewer, it should be implemented directly to the Commons. --ŠJů (talk) 15:27, 3 October 2014 (UTC)
 * Hello there. The upside is that work is beginning to improve the Commons structure with metadata integration with Wikidata's software. I hope you follow along as that develops as it should help the interface of all Commons-related tools. Keegan (WMF) (talk) 00:14, 4 October 2014 (UTC)