Extension talk:Media Viewer/About

From MediaWiki.org
Jump to: navigation, search
Share your feedback
Report bugs

Media Viewer will soon be updated with these new improvements, based on community feedback:

Visit the improvements page for more information.

Try out these new features as they are released in coming weeks, and let us know what you think.

An archive box Archives 

Join the Media Viewer Consultation[edit | edit source]

Media Viewer's new 'minimal design'.


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[edit | edit source]

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. -- 18:18, 30 August 2014 (UTC)

Usability: prefetch more images for better response times[edit | edit source]

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)

It must be possible to turn off prefetch should the user be on a limited download plan of some kind. Not sure if this can be detected, I don't think so, which imply yet another user set option. Perhaps it can be inferred from the IP-address or the speed. If the user is within a IP-range where other users have indicated that they have turned off prefetch, then use this as the default choice. Jeblad (talk) 11:28, 12 October 2014 (UTC)

Media Viewer's Handle is just plain in wrong direction[edit | edit source]

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. — Preceding unsigned comment added by Janra (talkcontribs)

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[edit | edit source]

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)

One month later this is still terribly annoying. If I browse Commons categories and click at some images, the back button becomes useless. It walks me through all of my viewed pictures once again. Can't you fix that somehow? -- 15:02, 8 October 2014 (UTC)

How can i deelete this enervous function?[edit | edit source]

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! — Preceding unsigned comment added by (talkcontribs)

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 w:Greasemonkey and tell it to run the code mw.config.set("wgMediaViewerOnClick", false); on all Wikimedia projects. --Stefan2 (talk) 19:23, 5 September 2014 (UTC)

Picture descriptions better, but could we get headers?[edit | edit source]

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[edit | edit source]

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". :( -- 09:23, 8 September 2014 (UTC)

Die Möglichkeit den Viewer dauerhaft abzuschalten klar sichtbar im Hauptfenster unterbringen und nicht "versteckt"[edit | edit source]

  • Problem:
  • Proposed solution:
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[edit | edit source]

Screenshot of the Media Viewer's new design prototype

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 design prototype). 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[edit | edit source]

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. 13:18, 15 September 2014 (UTC)

Disabeling does not work[edit | edit source]

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

Comparison with another extension[edit | edit source]

I asked a coworker sitting next to me which one is better between these two extension:

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[edit | edit source]

The Media Viewer would be good tool on this special page. But as far as I can see, it does not work here.--[[User:Bmrberlin| Bernd M.]] (talk) 10:20, 23 September 2014 (UTC)

@Bmrberlin: very good request! I filed a bug for the enhancement. Keegan (WMF) (talk) 22:19, 26 September 2014 (UTC)

@Keegan (WMF):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. --[[User:Bmrberlin| Bernd M.]] (talk) 06:56, 27 September 2014 (UTC)

There is more behind the scenes …[edit | edit source]

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? — Preceding unsigned comment added by (talkcontribs)
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[edit | edit source]

Media Viewer's new user interface, with 'More details' button.

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:

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

Next, we plan to work on these other improvements:

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?

The media viewer freezes and is unusable with older browsers such as Firefox 3.5 on a Linux installation with Kernel 2.4. It was not even possible to access the link which disables this feature. -- 12:30, 14 October 2014 (UTC)

Improve the Commons interface instead[edit | edit source]

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)

Show title of work[edit | edit source]

François Clouet 004.jpg

Here is a picture with a work title but no description. Media Viewer doesn't show the title, it says that "no description available". Can it show the title too (also if there is description too)? (fileinfotpl_art_title class) --Tacsipacsi (talk) 10:36, 5 October 2014 (UTC)

@Tacsipacs: it looks like the {{title}} template isn't used to pull CommonsMetaData at all, so it doesn't fall back to title when there is no file description. The "title" is parsed as the file name. How this data is being pulled by Media Viewer in general is being revisited as the software is being reconfigured with logic to deal with caption fields as they are available so that work may help fix this. I appreciate you bringing it up, it'll help engineering in reworking captions and titles for removing the fold :) Keegan (WMF) (talk) 14:58, 8 October 2014 (UTC)

Other pages used in[edit | edit source]

This is probably the biggest piece of information left out of the Media Viewer that makes it hard to use for power editors. If you need to find file usage, you can't without extra clicks. It also makes it very hard to see the [for instance] en-wiki file page of a Commons file, which tends to hide en-wiki featured picture status. Adam Cuerden (talk) 10:50, 6 October 2014 (UTC)

@Adam Cuerden: "Other pages used in" was just removed in the last update to Media Viewer based on a high volume of complaints that this much detail was overwhelming and not helpful :/ Everyone's workflow is different, eh? :) The goal by the end of the month is to truly make Media Viewer a completely different viewing experience than the file page, rather than a replication of the file page but just in a different form. Following that idea you're going to see a few more changes, such as removing the file description and getting rid of the pull-up fold all together and instead display a caption below the image for educational context if it's available. In the end the experience should be pretty different than the one you've been having for the past six months or so. We'll see how the rest of the changes turn out for you, hopefully it'll be for the better. Keegan (WMF) (talk) 08:40, 8 October 2014 (UTC)

Wrong image displayed[edit | edit source]

I uploaded a revised version in place of someone else's image (minor tweaks changing a graph to colour version and adding earlier comparative figures); the new image displays properly within the en.Wikipedia page (don't recall needing to Purge to display newly uploaded image) and both WikiCommons & the old image viewing format both properly display newly uploaded version of image, but the new Media Viewer displays the old image (although it does display newer info like my user name as the Owner/Uploader and shows my newer licensing, description, etc info).

Even clicking the Open in Media Viewer link when displaying the new image in commons opens the Media Viewer, displays the new image for just a moment, then reverts the image to the original greyscale image created by another user that originally existed.

Meanwhile, clicking the Download button () then selecting View in browser displays the new image (different from what Media Viewer shows).

There is no Purge opinion in Media Viewer so I can't be sure if the image is just cached on the server (or possibly even locally on my system). en.WP:Who R you? (Talk) 20:17, 6 October 2014 (UTC)

What file page is this so I can check it out? Keegan (WMF) (talk) 14:34, 8 October 2014 (UTC)

Position on page is lost after navigation[edit | edit source]

(Win 7, IE 11)

When I use the browser's "back" button to return to a previous page, normally it restores my position on the page. However, the following sequence of actions, which is quite common for me to do, causes the position information to be lost:

1. Go to any article with images and scroll down a way.
2. Click on any image.
3. In Media Viewer, click the image again to go to the full-size version.
4. Finish looking at the full-size version, so click browser "back" button and then "X" in MV, or click browser "back" button twice.
5. In both cases I am thrown back to the top of the article.

This is not ideal because it means that when you are reading an article and looking at images as you go along, your reading position is continually disrupted. 20:48, 7 October 2014 (UTC)

Sounds like a regression may have happened after the last update, this certainly shouldn't occur. Thanks for the detailed report so this can be fixed. Keegan (WMF) (talk) 08:33, 8 October 2014 (UTC)
And bug filed, it's being looked into. Keegan (WMF) (talk) 14:07, 8 October 2014 (UTC)

Author / Caption update[edit | edit source]

How does the Author and Caption of a Image update? F. Ex. at https://de.wikipedia.org/wiki/Bianca_Walter#mediaviewer/File:BiancaWalter.jpg The Author name is spelled wrong and the caption has changed. --Stefan-Xp (talk) 19:54, 9 October 2014 (UTC)

The caption is always the same text you see in the article, there is no caching involved. Details from the file description page update roughly within a day. --Tgr (WMF) (talk) 16:53, 10 October 2014 (UTC)

Thank you, nice to know :) I think it confuses some people if the "Media Viewer" Page has different data to the Image Description Page. -- 20:04, 20 October 2014 (UTC)

Media Viewer Metrics Update[edit | edit source]

Here are the latest metrics about the new features we just launched, which provide some first results on their impact so far.

Early indicators suggest these improvements are working:

  • Enlarge feature: You can now click on an image to enlarge it in Media Viewer, to support a frequently requested zoom function. We now log about 1 million clicks/day for that feature across all sites -- a dramatic 20x increase from ~50K clicks/day for the previous ‘View original file’ button (see metrics dashboard).
  • File: page button: You can now click on a more prominent ‘More details’ button to go to the File: page, a frequent community request. Since this feature was launched last week, global usage has tripled, surging up to ~60K clicks/day (from ~20K clicks/day on two separate links)
  • Download button: You can now click on a separate download button that's easier to find. Since launch, global usage has tripled to ~66K clicks/day on the new icon (from ~20K/day for 'Use this file' downloads)
  • Disable rates: Since these improvements were launched, global opt-outs by anonymous users have decreased by 60%, down to ~800 disable actions per day (from ~2K/day before new features).

This is consistent with our expectations, based on the latest round of usability research for the recent prototype.

We hope these findings are helpful. We will post more research data on this page in future updates. Fabrice Florin (WMF) (talk) 22:59, 9 October 2014 (UTC)

Note that the performance measurements are not fully reliable (as noted on the linked page). We are working on more robust ways of comparing the speed of MediaViewer and the file page. --Tgr (WMF) (talk) 16:48, 10 October 2014 (UTC)

KISS please!![edit | edit source]

Sorry, if this is documented somewhere, but I could not find that information on a quick search:

Can someone tell me which problem this media viewer thing tries to solve?

I, for one, never had any problems viewing images on Wikipedia. For me, the viewer does not make one single thing better. On the contrary: it is no longer obvious what other resolutions of an image are available and zooming in into an image is not as easy as it was before in my browser.

So, if there is no serious problem that needed to be solved with viewing images in Wikipedia, I would plead for heeding the KISS principle: Keep It Simple, Stupid!

No complicated, error prone, bloated and confusing solution for such a trivial problem as viewing images! (Which was already solved, anyway.)

Please, please, please, don't make the same mistakes as many commercial sites and introduce unnecessary bloatware all over the place. Please, no flash stuff, no blinking animations, no bloated javascript nonsense. Wikipedia should be there for one thing: plain old information which should be as easily and quickly accessible as possible even with old and/or weak hardware.

You do not sign the above, but I agree wholeheartedly with you. I raised the same point somewhere in the system months ago, but never got a comment from the instigators, who are probably a bunch of technonerds more interested in the software than the practicality of the system. I long ago disabled Media Viewer in each place where I often view images, simply because it solves no problem for me, but hinders the usability of the system. My message to them is "Don't do something just because you can. Do it only if it is useful." LynwoodF (talk) 08:04, 12 October 2014 (UTC)

Interface issue[edit | edit source]

My least favourite thing about Media Viewer is the massive white box down the bottom. The main reason for this is that I have a 16:9 1366x768 laptop display, and I am already stretched for vertical space. I run my web browser in fullscreen, for example. The fact that Media Viewer defaults to placing a large white box horizontally at the bottom of the screen means that I cannot view images in sufficient detail to make it worth even clicking the thumbnail.

If it could be made to only be seen when hovering over that area, that would fix the problem. Another way it could be fixed is by making fullscreen mode an optional default. However, then the functionality provided by the quick-access stuff in the white box is removed.

Anyway, that's my biggest complaint. Other than this, it's a great tool in my eyes. I don't see why you're getting so much kickback for it.

A big thanks for all your hard work, software developers. Thennicke (talk) 05:38, 17 October 2014 (UTC)

Hi Thennicke: Thanks so much for your helpful feedback about Media Viewer. We're sorry that your screen's 16:9 aspect ratio makes Media Viewer's information panel more prominent than on standard monitors. In future versions of Media Viewer, we could consider making this an option in the new settings panel we're now developing. For now, your best bet is to use the full-screen feature, which still provides access to the information panel on hover. Thanks again for your kind words, which are much appreciated. Fabrice Florin (WMF) (talk) 23:42, 21 October 2014 (UTC)
As 16:9 is the usual ratio on todays monitors, the MV should have been developed with those standard monitors in mind, are there still any old-fashioned 6:4 in use? It should perhaps switch from bottom panel to side panel depending on the screen aspect ratio, or at least make it a setting in preferences. --♫ Sänger - Talk - superputsch must go 05:50, 22 October 2014 (UTC)
A 6:4 (3:2) aspect ratio for computer monitors is practically unheard of (it was mostly used for cameras); the popular sizes (other than 16:9) are 4:3, 5:4 and 16:10. Unsurprisingly, Media Viewer was mostly developed on 16:9 which is what people working with computers tend to use these days.
A side panel would be more efficient in terms of screen real estate, but harder to use - vertical scrolling is a very well understood action while horizontal scrolling not so much. There is no horizontal scroll wheel on the mouse, etc. --Tgr (WMF) (talk) 14:34, 22 October 2014 (UTC)
Ask your colleges at Flow about screen ergonomics, they claim that the screen must not be used in full. So there would be plenty of space to put a vertical scrolling pad there, if extremely narrow Flow layout is really so good as claimed ;) --♫ Sänger - Talk - superputsch must go 15:25, 22 October 2014 (UTC)
I'm not sure how a rule of thumb from typography would be relevant to the presentation of images. Anyway, putting the text to the side would be a trade-off between more screen real estate and more awkwardness in the presentation and manipulation of text. Given that we received very little complaint about the screen area used to show the image not being large enough, but lots of reports about the info panel being difficult to use, so that doesn't look like a good trade-off to me. --Tgr (WMF) (talk) 19:07, 22 October 2014 (UTC)

I want to get rid of this "feature"[edit | edit source]

It completely breaks everything navigationwise, it looks disgusting on my PC screen (as if it was turning it ino an handheld device of some sort), it does not fit with other elements of the Wiki, designwise, workflowwise, and navigationwise - and do not dare to make the rest as ugly as well, you certainly loose a user!

I do not mind having this nonsense if people want it, but then let them choose it by enabling it in their preferences, or?

-- 10:00, 17 October 2014 (UTC)

Hi We're sorry that you don't find Media Viewer useful on your PC. You can easily disable this tool by scrolling down to the bottom of screen, then clicking on 'Disable Media Viewer', as described in this Help FAQ. In coming days, we will make this disable function more prominent, which will make it even easier for you to turn it off. Hope this helps. Fabrice Florin (WMF) (talk) 23:47, 21 October 2014 (UTC)

Responsiveness[edit | edit source]

Since I cannot upload images here, I hosted screenshots on Imgur. The Media Viewer does not respond well on small screen devices. In regular view some details are too small to view. But if enlarging the image with th spread gesture the image caption resizes as well and spreads all over the screen. Once the spread gesture is released from the touch screen, the image pops up to the top left, so you can't even see the spot where you zoomed to. This behavior makes the Media Viewer useless on small touchscreen devices.

Thanks for the screenshots, they're mighty helpful. The "media viewer" on mobile is not the same as the one on the desktop; it was developed by the mobile team. I'll pass this along to them. Keegan (WMF) (talk) 20:25, 21 October 2014 (UTC)