Extension talk:Media Viewer/About/Archive06

Join the Media Viewer Consultation

Media Viewer's new 'minimal design'.

Greetings!

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

Aren't you wasting just a wee bit too much money on this staggeringly abortive project? Almost everyone today understands that the developers behind this smoldering PoS are singularly untalented. They made money that will never be returned. Isn't it more important to tap the leaks in the organisation and weed out the crooks? No one ever wanted this sophomoric media viewer and no one needs it - especially when the feeble minds of the developers can't wrap their mind around the specs of media viewers that really work.

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)

I see an image typically in the right margin. I click on it. The media viewer opens like a popup. There's an 'X' in the URHC. I click it. The media viewer popup disappears. Now I hit my browser 'back' button and I'm back in the media viewer popup again. (I can hit the 'back' button one more time and I'm back where I started.) No other web-based media viewer anywhere behaves like this. It's UNINTUITIVE. As can be seen, this matter has been reported before. How thick are you?

My browser already has an image viewer

To see how abysmal this implementation is, use the 'back' command in your browser after using the viewer. You are violating the User Recognition Principle for no good reason. You should not advance a browser at all. The viewer is a popup on all other implementations online.

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)

→Exactly this! Take this half-finished botch back to the drawing board. The shiny aesthetics get in the way of effective presentation, obscure valuable information such as available image sizes and file formats, and the latest edits add a pop-up notification that overlays the lower right portion of image on the file page. It takes a special kind of incompetence to break functionality on an existing well-designed layout, but that is what the coding experts of WMF seem to bring to the table. --69.11.241.134 02:23, 14 November 2014 (UTC)

And opting out seems to make many images just stop working. Argh. And it stops me from using my browser's own zoom function, so I end up with no zoom at all, just a thumbnail in a viewer that literally makes the image smaller. 174.62.68.53 03:18, 17 November 2014 (UTC)

Somebody's been lining their pockets. This is poorly designed, poorly implemented, and pure embezzlement.

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)

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

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 (talk • contribs)

Agree with this, the handle is just wrong..

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

Tracked in Phabricator
Task T64266

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? --131.152.41.173 15:02, 8 October 2014 (UTC)

Total hell is this back button "media feature". Please roll back to the earlier version.

We're aware that some users find the history behavior frustrating. We're still investigating this one to see what the best possible approach could look like, see phab:T64266 for discussion.--Erik Moeller (WMF) (talk) 08:00, 12 December 2014 (UTC)

How can i delete 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! — Preceding unsigned comment added by 92.229.95.23 (talk • contribs)

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)

Now (30 Oct 2014) it is very easy to disable. Use the "gear" icon to disable Media Viewer. You will have the traditional file detail page. On that page you can enable Media Viewer if you want. 16:26, 30 October 2014 (UTC)

Clicking the "Disable Media Viewer" button does not work for me. Clicking it literally does nothing. I want to disable this but I am forced to continue to have to put up with it against my wishes 2015-07-25

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)

Clicking on an image thumbnail on the front page of en.wikipedia.org does not work in iceweasel. Instead of the expected file page, I get a flashing attempt at media viewer that then dumps me back to the original page with no graceful failure. This is sad and wrong. — Preceding unsigned comment added by 193.174.160.34 (talk • contribs)

Media Viewer is usually disabled on fatal errors, so a second click on the image should work. Can you provide more details of the error (exact browser version, link to the image, contents of browser's JS console if you know how to find that)? --Tgr (WMF) (talk) 09:33, 4 November 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

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

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)

you simply never want to see this

Yes you do.

After years of considering the checkerboard background of images in Wikipedia to be one more piece of evidence that "media viewers" are a bad idea (because native browser support uniformly does a better job than "media viewers"), I finally searched for "why do wikipedia images have that annoying checkerboard pattern" and wound up here. So at least there is a sane reason, some plausible benefit for uglifying so many images. But seriously, it's a major net loss. The excuse seems to be that there might exist SVG images that are "white foreground on transparent background" ... but I've never seen one of those in the wild. DWorley 66.31.109.155 16:20, 14 November 2021 (UTC)

Disabeling does not work

I always disable the media viewer - but today Oct 29 2014 the disable media viewer button isn't there. So I CERTAINLY WILL NO LONGER SEND SUPPORT TO Wikimedia.

--98.204.221.130 21:39, 24 February 2015 (UTC)== 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]

A bit late, but I reported T133900 for this suggestion —TheDJ (Not WMF) (talk • contribs) 13:11, 28 April 2016 (UTC)

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)

If you look very closely to the two, they are closely the same

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

Tracked in Phabricator
Task T73372

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)

• Making a test with fMRI to see the location of IX n. in the brain?! Giving a cube sugar to taste and see the response in the fMRI!--111.252.66.233 21:57, 1 July 2015 (UTC)--111.252.66.233 21:57, 1 July 2015 (UTC)Hsiao Hsian Li, July 2,2015

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? — Preceding unsigned comment added by 128.104.68.117 (talk • contribs)

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

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:

• "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 (try this page), and will be deployed on all Wikipedias this Thursday by 20:00 UTC.

Link doesn't work anymore. Try this permanet link. Bennylin (talk) 16:10, 28 November 2014 (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?

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. --193.174.160.34 12:30, 14 October 2014 (UTC)

Make the media viewer an opt-in feature, not an opt-out one as it is now. --193.174.160.34 08:19, 4 November 2014 (UTC)

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)

Show title of work

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

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

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

Tracked in Phabricator
Task T73796

(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. 86.169.184.165 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)

No it's not a regression. This is supposed to be a popup, not a new page. No image viewer anywhere else on the Internet works this way. Failing to achieve this simple aspect of the overall behaviour is very telling about the crew working on this misfit feature.

Why/how is this basic and easily-fixed flaw still a problem? If this project wasn't going to be followed-through, why was it started? There wasn't any problem at all with how media was handed before this "improvement"

Author / Caption update

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. --134.3.200.4 20:04, 20 October 2014 (UTC)

• 1.Nice work of the cancer map,2.'Gene regulation' could be described with map of chromosome with defect,and gene therapy............Hsiao Hsian Li,June 12,2015

Media Viewer Metrics Update

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

• Performance: Media Viewer continues to outperform the File page for image load times: about 4.6 seconds vs. 7.7 seconds for a median image load time in the 90th percentile.

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!!

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)

Concur. [Another Random User]

Agree again. Keep it as a popup or admit your inadequacy and abandon it completely. [Another Random User]

• Agree.--Nikolas Tales (talk) 00:16, 17 July 2015 (UTC)

Interface issue

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.

1366x768 is pretty good. Perhaps you should reassess your computer use rather than complain about interfaces. No mistake: this 'media viewer' sucks and is only a way for an exclusive group to funnel off significant donations to pad pockets, but still and all: 1366x768 shouldn't hamper you one bit.

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"

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?

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

Hi 109.44.2.248: 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)

But it won't stay disabled. It keeps coming back like a bad penny. 72.145.219.37 04:55, 2 November 2014 (UTC)

It will stay enabled as long as your browser keeps settings (specifically, local storage). If your browser is configured otherwise (e.g. you are using incognito mode) then there is of course no way any configuration change you make could stick around. --Tgr (WMF) (talk) 09:12, 2 November 2014 (UTC)

Not true, I have to re-disable the media viewer periodically and I never mess with the local storage on my browser. I only use the same browser too, so it's not because I changed browser apps. This random re-enabling of the media viewer is quite annoying, and it's why I am here making this comment... I've had to disable the Media Viewer 4 times since I originally disabled it, and I am getting fed up. This Media Viewer feature needs to be disabled by default at the very least or scrapped in its entirety. Certainly if it were up to me given the blatant arrogance and disrespect to the community shown by the design team, I would both scrap it and fire the design team. Ikaruseijin 17:48, 3 November 2014 (UTC)

That would probably be the best solution, fire those incompetent, arrogant wannabe-programmers in SF and kick this useless bling-stuff out. But, unfortunately, those bunch have the de-facto power, and obviously don't give a flying f*** about their customers. --♫ Sänger - Talk - superputsch must go 17:56, 3 November 2014 (UTC)

Due to the way how browser and MediaWiki preferences work, disabling will only effect

• the same user (if logged in) or the same browser (if logged out)
• the same wiki
• the same scheme (http or https) if logged out

Other than that, the settings should stick. If that's not the case, please file a bug. --Tgr (WMF) (talk) 21:35, 3 November 2014 (UTC)

To help you fix something that should never have been implemented? No thanks. Until the media viewer is opt-in or eliminated entirely, I'm not doing anything to help you. You're working against the user base and the community that runs Wikipedia so you'll get no help from me in any way. Ikaruseijin 23:43, 16 November 2014 (UTC)

Once again the Media Viewer enabled itself. I didn't change cookies or anything. It happens randomly about twice a month. I'm tired of it. The default needs to be off. Ikaruseijin 14:34, 6 January 2015 (UTC)

But you've foisted an opt-out system rather than opt-in. You're not even through with development (let's hope not) and you're already defaulting to something that is poorly designed and broken. You should never use opt-out for new features. You still haven't ascertained that most people embrace this feature. From the look of things here, most people have not embraced it. Doing as you've done is simply in bad taste and it will continue to annoy people.

Responsiveness

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)

This is mostly covered by issue phab:T95211 —TheDJ (Not WMF) (talk • contribs) 13:23, 28 April 2016 (UTC)

Media Viewer Update: More Improvements

Media Viewer's new Disable feature

Hi everyone: we just released a few more improvements to Media Viewer, based on community feedback:

• An easier way to disable Media Viewer for personal use
• Re-enable Media Viewer from a file page
• Rename File page button: "Open in Media Viewer"
• Make MediaViewer text larger in Monobook

You need an easy way to enable, not the other way around. Your whole approach is a fail.

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.

The new Disable/Enable features make it much easier to turn Media Viewer on or off, by clicking on a prominent 'cogs' icon, as described in the Help FAQ (see screenshot). Note that these features only work on the site where you activate them: enabling Media Viewer on Wikimedia Commons will not enablie it on your home Wikipedia or other sister projects.

Next, we are working on these last 'must-have' improvements:

• A caption or description right below the image
• Move license label after source and adjust layout

(Note that the layout change for the second ticket above has just been released for testing on MediaWiki.org: you can view it on this test page.)

These features are based on most frequent requests from our recent community consultation and ongoing user research. For more information, visit the Media Viewer Improvements page or the Help FAQ page.

Many thanks to all the community members who suggested these improvements. Our user research so far confirms that they provide a better experience for readers and casual editors, our target audience for Media Viewer.

Please let us know what you think of these improvements. We will send one more update in mid-November, once all these improvements has been released and tested.

Regards as ever. Fabrice Florin (WMF) (talk) 23:38, 28 October 2014 (UTC)

Is there a chance you'll eventually move the "Open in Media Viewer" Button to a more reasonable position (e.g. the bar at the top of file description pages, ID: filetoc)? There was a lengthy discussion on how the button doesn't make any sense where it is right now a long time ago and some people from WMF staff agreed to work on this but nothing ever happened...

Additionally: Can you add a similar button (in a similarly reasonable place) to category pages? I mean there is not much point in opening a single file in MediaViewer (especially when one has already reached a good old file description page), but for browsing through categories the tool might actually be useful! --Patrick87 (talk) 01:08, 29 October 2014 (UTC)

New File Page Button Position Idea

Thanks for your helpful feedback, Patrick87!

We have considered other positions for the the "Open in Media Viewer" Button, as shown in this mockup (see thumbnail). We would like to discuss this idea with the Commons community, now that we're almost done with our 'must-have' improvements for Media Viewer. Before we do, we plan to collect behavioral data on how often people click on the current button, so we can have a more informed discussion; we hope to have that data available later this month, if Gilles can fit it in our development cycle, as outlined in this ticket.

I also like your idea to create a similar button for categories, but this seems less critical, since it is already possible to browse images in a category by clicking on their thumbnails. Thanks again for your constructive suggestions! Fabrice Florin (WMF) (talk) 20:57, 29 October 2014 (UTC)

Actually, there's absolutely no possibility to use MediaViewer from category pages if MediaViewer is disabled by default in user preferences. That means while I don't want to use MediaViewer normally, I can't use it to browse categories (where I think it actually could be quite useful). So (as a user with MediaViewer disabled) I'm faced with the (for me) useless "Open in Media Viewer" button on each and every file description page, while I'm not given any possibility to enable it on category pages were it would be useful (for me). With such issues one somehow gets the feeling WMF staff's point of view is at least as biased as the point of view of community members categorically rejecting MediaViewer. Finally start to think this through from all points of view, so MediaViewer can one day become a useful tool for all community members! --Patrick87 (talk) 21:43, 29 October 2014 (UTC)

As a crappy workaround, you can just right-click the first image, select "copy link URL", edit the address bar, add #mediaviewer/, paste the URL, delete everything between (but not including) #mediaviewer/ and File: and press Enter.

As a slightly less crappy workaround, here is a bookmarklet/gadget snippet/whatever:

$( '.gallery .image img' ).first().each( function () {
    mw.mmv.bootstrap.openImage( this, mw.Title.newFromImg( this ) );
} );

--Tgr (WMF) (talk) 22:04, 29 October 2014 (UTC)

Thanks, this works well when executed from Firefox JavaScript console. I'll probably incorporate this into a button loaded from my "common.js" on Category pages as a workaround. In the long run I hope this is fixed directly in MediaViewer though (since fiddling with JavaScript seems not really user friendly and not exactly advertising for the software)? --Patrick87 (talk) 23:26, 29 October 2014 (UTC)

You still have that stupid cog to disable it... mystery meat navigation is bad, as I have told you repeatedly. But you've never deigned to respond to me anyway. Your "easier way to disable Media Viewer for personal use" is still as confusing as ever. It remains to be seen if your anonymous opt out will stick in these new changes. When are you going to acknowledge that your #1 bit of feedback is that Media Viewer IS NOT AN IMPROVEMENT and respond to that feedback by disabling it by default instead of playing this game of making tiny, ineffectual "fixes"? The entire concept is flawed and these changes won't help. Your false cordiality does nothing to disguise your obvious contempt for your users by forcing this terrible software down our throats. It remains as clear as ever that the WMF only cares about meeting its internal goals, not creating software people actually want to use. And that's sad. Stop this charade. --98.207.91.246 15:45, 29 October 2014 (UTC)

Parent comment is correct. The following comment is just more of the same old same old.

Hi 98.207.91.246. Thanks for your comment about the Disable/Enable feature. The use of a cogs icon is pretty standard nowadays for changing your settings, and the new button is also a lot more prominent now. So we expect that the new disable/enable feature will make it easier for people to turn Media Viewer on and off. The data we're collecting seems to support this view: we saw the number of anon opt-outs double on the day after we launched the feature on Commons, as shown on this metrics dashboard; and the number of anon opt-ins tripled on that day as well. So this suggests that these users are able to find the cog icon easily. Regarding your other personal comments, I'm sorry that you find my 'false cordiality' annoying: I'm a friendly person by nature, and sincerely care about what our users think of our work; but we can't please everyone, and have to balance the needs of our readers with those of advanced users, which we aim to do based on usage data and user studies, not personal opinions. Fabrice Florin (WMF) (talk) 20:57, 29 October 2014 (UTC)

Not only do you make absolutely no attempt to accept that this "feature" is declined by an overwhelming majority of the users in your own data, you talk about your data in a misleading way. You say anon opt-ins tripled, while opt-outs only doubled. There are about 6 times anon opt-outs in the graph compared to anon opt-ins. You fail to mention that and continue working on this media viewer thing.

Anyone who has basic knowledge on the foundation's and your ways in this matter must be mad to take part in the current fundraising campaign. With this background, I find it strongly insolent to advertise fundraising for a foundation which acts in this way.

As there is still no sign of understanding on the side of the foundation in this matter, I continue stopping my activities in Wikipedia and Commons, which date back to 2002. As a person who likes to contribute to real sharing projects I'm shocked to find my work in the hands of WMF acting in such a way. --193.18.240.18 14:03, 31 October 2014 (UTC)

Good to see the progress and improvements made. From a first quick glance here are some issues I still see:

• 1) The button label on the right says "More details" which is identical to the mouse over label on the down arrow. Having the exact same text for two different destinations, without being able to distinguish between them, is confusing.
• 2) Regarding the "Share or embed this file" button; a) for editors who want to use the image to add to an article the generic term "Embed", without any reference to Wikipedia, might be less clear than the "Use this file" option on Commons next to the Wikipedia icon. Can this be clarified with a sentence? b) On the "Embed" tab scrolling (using the mouse scroll wheel) through the drop-down box with options for image sizes very quickly leads to the info section at the bottom of the image scrolling up which is annoying.
• 3) It is unclear for readers and editors that the info which is displayed below the image title relates to the Author and Source fields. If no author of the image is known the first word displayed is "Unknown" which, without any further context, is completely ambiguous and unclear. I can understand there is probably not enough space to display the "Author" and "Source" labels in full but why not at least display an intuitive icon in front of both fields with these labels as pop-up text?
• 4) The enlarge feature, clicking on an image in Media Viewer to enlarge it, is nice but serves no purpose if no larger version of the image is available. As an example, Spencer_gore.jpg is already shown in the MV in the largest available size (345 × 496). The only thing that happens if you click on the image is that the exact same size image is shown again but now without the surrounding navigation and suddenly on a white background. No benefit and confusing. In my view the enlarge feature should only be enabled if a larger image is available than the image first shown in the MV.
• 5) Change the pop-up label of the 'X' button in the top-right corner from "Close this tool (esc)" to "Close Media Viewer (esc)". An average viewer will not think of this functionality as a 'tool' (technospeak). Also for consistency with the enable/disable button pop-up label.

--Wolbo (talk) 01:09, 31 October 2014 (UTC)

Thanks for the feedback, Wolbo! Re: 1), you are absolutely correct, we are working on that. Re: 3), we are introducing a person icon before the author name. Is there a situation where the lack of a source icon could be similarly confusing? (Also, not sure what would be an intuitive icon for "source".) Note that we do show the labels as popup text already. Re: 5), "Media Viewer" is even more confusing for the average viewer. Maybe we could simply go with "Close". --Tgr (WMF) (talk) 21:46, 3 November 2014 (UTC)

Terrible

A complete waste of time, worse than having nothing at all, makes it harder to zoom, just awful. Please kill it, please please GET RID OF THE MEDIA VIEWER or have it off by default--87.242.202.85 15:02, 29 October 2014 (UTC)

Will You Hear a Funding Boycott?

I'm sure many people hate the new media viewer as much as I do. You never listen to the people viewing en.wikipedia.org. I used to send hundreds of dollars to Wikimedia each year, but this year I decided not to send any money. The en.wikipedia.org still doesn't hear me. So maybe it's time for viewers to start organizing a funding boycott of wikimedia.org. And in time people will find or create another web site that is like what en.wikipedia.org used to be. Then maybe Wikimedia will KISS - KEEP IT SIMPLE STUPID! Do you remember what happened to geocities.com and so many other web sites that self-destructed?

I second this and will be directing my charitable contributions elsewhere. There are plenty of worthy causes, most of whom don't engage in such levels of wrong-headedness.

I agree. I will no longer donate anything to Wikipedia and it's associated organizations until the media viewer is scrapped entirely, and ideally the managers of this project that have completely ignored both the numbers and the Wikipedia editors, should be removed from positions of authority. I will be encouraging my friends and associated to do the same. Ikaruseijin 19:03, 9 November 2014 (UTC)

Seems like there's a Gollum running this project who can't get rid of his precious.

Bring back the "Disable Media Viewer" Button

As of Oct 29 2014, the "Disable Media Viewer" button is gone, probably because nearly everybody is disabling the new media viewer. Since I found the button, I always disabled the media viewer every time I view an image at en.wikipedia.org. The button being removed indicates to me that the designers of this new media viewer intend to change things and are probably very well aware that WE HATE IT. Maybe they have taken a personal bribe or favor from commercial web sites that want to destroy the competition. All indicates that the designers of the new media viewer don't care about the viewers of en.wikipedia.org. I guess nothing good last forever.

Because en.wikipedia.org doesn't hear us, it maybe time to boycott wikimedia funding and seek other web sites. Maybe then en.wikimedia.org will hear us and at least bring back the "Disable Media Viewer" button. Or maybe en.wikimedia.org will continue to make things worse such as adding a requirement for every viewer to open an account and log-in using email and real names and birthdays and other personal information that we should refuse to give them. For now, I guess I'll be looking at reddit.com to see if there is some hope there. We must have plans in place to move quickly whenever a good web site decides to destroy its self. — Preceding unsigned comment added by 208.53.79.70 (talk • contribs)

The button has been moved to a more prominent location - see Help:Extension:Media_Viewer#How can I turn off this feature? for detailed help on how to use it. As can be seen from the stats, this has been pretty effective in making the optout option easier to find. --Tgr (WMF) (talk) 12:24, 30 October 2014 (UTC)

When will the foundation hear us and end this mess? FYI: I'm not logged in for this edit because I'm on strike because of the foundation's ways. I discourage everybody to pay in the fundraising campaign for this bloated and, obviously learn-resistant organisation. Wikipedia and editing has been part of my life since 2002. It's a pity that this might have to end in this way. --193.18.240.18 12:37, 30 October 2014 (UTC)

So now I have to know to click on the unlabeled flower-shaped icon to bring up the option to disable this media viewer? It seems also that the commons file page is now defaced by your cack-handed meddling. There is now a completely superfluous notification that media viewer is disabled placed on top of the image that I am trying to view. Since I did not suffer a severe head injury (perhaps unlike you?), I can remember that I had disabled media viewer mere seconds ago and do not need a notification which requires another click to dismiss. Why do you keep inflicting your redundant piece of shit on an unwelcoming audience? Does bringing us annoyance make you happy in some way? I will join in this fundraising boycott and encourage others to do the same. I also re-announce my pledge to not contribute content or make edits to Wikipedia while media viewer is the default or while the file page has diminished functionality as a result of media viewer.

My reply to Tgr (WMF) 30 Oct 2014:

The chart at "from the stats" shows more op-outs after Oct 27th. I guess the cause maybe more wikipedia sites have been "Enable by default" for the media viewer?

As of November 1st 2014 The Media Viewer Release Plan clearly shows the media viewer is being pushed against wiki community wishes:

https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan

June 3 (2014) - Tenth release- Enable by default on more large sites- English and German Wikipedias - (Note special Tuesday deployment) Gerrit change 134811 and Gerrit change 134812 - (checkmark-yes) Done against community wishes.

English Wikipedia decided to remove the feature as a default setting, effective July 9. (X) Rejected for implementation

German Wikipedia decided to remove the feature as a default setting, effective August 8. (X) Rejected for implementation

June 19 - Eleventh and final release: Enable by default on all wikis - (checkmark-yes) Done

The above MV release plan shows the media viewer isn't wanted, software developers know it and they push it anyway. I guess the efforts by English and German wikipedia to get the media viewer disabled by default have been overruled in "Rejected for implementation".

So, the question still remains unanswered - Who and why is the media viewer software bloat being added to wikimedia?

If an honest survey was done, they'd ask "Is the media viewer an improvement?" 95 Percent of English and German viewers would probably say no. Wikimedia could at least make the media viewer disabled by default. The 5% who like it could enable it, and the other 95 percent could still enjoy wikipedia as a great web site. Currently November 1st with the media viewer enabled by default, most viewers probably never learn now to disable the media viewer, therefor in EACH and EVERY image view they put up with the annoyance of waiting for the media viewer to load then having to click through the "more details" in the media viewer to view the page of different image sizes. That may have the same level of annoyance as the pop-up ads did to geocities.com. For those who don't know, Geocities.com was a 1990s web site that was very successful than failed after "improvements" were made. I don't want wikipedia to fail.

Besides the whole pro/contra MediaViewer conflict going on, removing this optio from user preferences is a very bad step in my opinion. Instead of unifying the UI and collecting all settings in a clear and structured way in one place (the user preferences... thus the name) more and more preferences are scattered across tools in different places of the UI reachable by different ways. This "maximization of inconsistency" is a really bad habit and will decrease the overall user experience people will have with the MediaWiki software (especially as used on WMF Wikis). --Patrick87 (talk) 12:05, 2 November 2014 (UTC)

Is anyone really contemplating such nonsense? Of course all prefs have to have an option in user prefs. If it's as well possible to change them "on the fly" in situations where it's appropriate, like with MV on pic pages, is a nice add-on, but there must never ever be any preference, that can't be changed in user preferences. --♫ Sänger - Talk - superputsch must go 12:40, 2 November 2014 (UTC)

To clarify, the "Disable Media Viewer" link at the bottom of Media Viewer has been replaced with the cog icon. The Special:Preferences option hasn't changed since April or so. --Tgr (WMF) (talk) 21:37, 3 November 2014 (UTC)

The cog icon is a bad idea, because with some images, in particular those with a light background, it is hard to see. If the media viewer is to remain, the disabling button must be more prominent. Better yet, do not make the media viewer a default feature, but let users opt in if they want to use it. --Schlosser67 (talk) 07:21, 7 November 2014 (UTC)

It's clear from the stats that the cog is much more prominent than the old link. I guess it could be improved further with a black outline. --Tgr (WMF) (talk) 15:29, 7 November 2014 (UTC)

It seems you are doctoring with symptoms, and not curing the illness. As for the statistics, the website mentioned by Tgr (WMF) does not show anything meaningful in Internet Explorer 9. I thought Wiki{media|pedia|whatever} was supposed to be browser-independent? --193.174.160.41 13:46, 10 November 2014 (UTC)

Probably most viewers still don't know about the cog icon. They just put up with the unwanted Media Viewer. In the long run, fewer people will view en.wiki, fewer will add content, and then fewer will donate to wikimedia. More will go to Google or reddit.com.

The stats "Opt-in and opt-out" show about 3000 opt-out vs only about 250 opt-in. That's only 8 percent. The default should be set to opt-out, so more first time visitors can enjoy en.wiki and the minority 8 percent could bother to figure out how to learn about the cog icon to opt-in. http://multimedia-metrics.wmflabs.org/dashboards/mmv#opt_in_and_opt_out-graphs-tab

The stats "Actions" show about 10M or 10,000,000 thumbnail clicks. Remembering 3000 opt-out plus another 250 op-in, the 10,000,000 thumbnail clicks indicate that a very tiny minority learn about and use the cog icon. http://multimedia-metrics.wmflabs.org/dashboards/mmv#actions-graphs-tab

To be fair, the survey should ask if the Media Viewer added months ago is better than what en.wiki had before. Probably nearly everyone who views en.wiki and de.wiki would say they don't like the Media Viewer, get rid of it.

I was really glad that there was this link to "Discuss the Media Viewer" where I found that I have to click on a particular icon to get rid of that annoyance. Many people won't do this and get more annoyed with Wikipedia. I guess that most of the 8% of people that didn't opt-out belong to this category. So please bring back a prominently-visible opt-out button for that annoying javascript bloat. Thanks. 85.183.43.23 15:40, 31 December 2014 (UTC)

Why wasn't this supposed software tested before putting it into production? How unprofessional is it to do things this way and incur the wrath of so many Wikipedia supporters? What happened to the Wikipedia organisation? Who are the people responsible for this mess and why are they still around?

Who's pushing the Media Viewer bloat?

We should know the name of the individuals who are pushing the new media viewer!

We must know, so he or she or they will have to explain why the money donated to Wikimedia is being wasted. He or she will have to answer why the viewing experience is being destroyed for en.wikipedia.org viewers. Maybe the designers of the new media viewer are in the pockets of a commercial web site that is losing viewers to en.wikipedia.org. Commercial web sites such as Yahoo or Facebook have added software bloat that has made viewing more difficult. Some web sites now require use of the viewer's real name and birthdate and allowing tracking and giving up privacy. Most will not find a hidden op-out menu. The real bug in en.wikipedia.org's new media viewer maybe the project software engineers, those that made the decision to make the new media viewer set to default and hide the opt out button - they care more about Yahoo or Facebook than viewers who came to Wikimedia to get away from software bloat. I can't think of another reason why the producers of the new media viewer would continue to hinder or disrupt the en.wikipedia.org viewing experience. So who are the culprits?

In doing more study of this industry-wide problem of software bloat and how it's damaged en.wikipedia.org, it appears that Wikimedia's meeting with companies such as Google has falsely convinced Wikipedia to "modernize" the web site design to look more like mobile media. Wikimedia having spent money on developing the media viewer released in 2014, seems to refuse to admit the whole Media Viewer project has failed for English and German viewers at least. I think Wikimedia must admit they made mistake, and set the media viewer to "disabled by default" so en.wikipedia.org can remain a favorite web site for everyone.

Wo ist der Abschaltknopf hin???

Jetzt hakts aber langsam richtig bei den "Herrschern" dieser Plattform - darf dieser §$%?&$§%&$?!!! jetzt noch nicht mal mehr abgeschaltet werden?! Unfassbar x_x

Das komische Zahnrad/Blüte oben rechts ist der neue Abschaltknopf, der soll wohl bloß nicht zu offensichtlich sein, damit dieses merkbefreite Glitzerdingelchen von Softwareschrott nicht so oft abgeschaltet wird. Da die Leute in SF ja einen Scheißdreck auf die Community geben, sondern möglichst effektiv die Schreiber vergraulen wollen durch antidemokratische Durchsetzung ihrer idiotischen Ergüsse wie dem blöden MV, darf es den Nutzern natürlich nicht zu einfach gemacht werden, den Ausschaltknopf zu finden. --♫ Sänger - Talk - superputsch must go 16:04, 5 November 2014 (UTC)

annotations missing

all the annotations are missing at http://commons.wikimedia.org/wiki/File:Pieter_Bruegel_the_Elder_-_The_Dutch_Proverbs_-_Google_Art_Project.jpg — Preceding unsigned comment added by 91.143.103.164 (talk • contribs)

Annotations are not currently supported (bug 56666). --Tgr (WMF) (talk) 16:41, 6 November 2014 (UTC)

Please roll back media viewer to an opt-in development project until it has such obvious bugs fixed. It is not ready for public use, even were it welcome (it is not).

Need to add a button to edit

Tracked in Phabricator
Task T77655

In order to encourage the categorization of images, as well as improving the descriptions of the images, I think it is important to edit a button that sends the user to directly edit the image, without having to go through "More details" in commons --Wilfredor (talk) 16:38, 7 November 2014 (UTC)

Another RfC in enWP, another slap in the face of the community or will the WMF this time act pro community?

The community confirmed the old RfC for implementation of MV as default opt-in with a 2:1 majority. Last time you (the WMF) chose to act with brutal force against the communities, do you still want to be an enemy of enWP?
It's the communities that generate the money the WMF-staffers are paid with by their content, the community is, if not strictly legal but de facto, the employer of all staffers, they should show at least some respect, not like up until now with MV utter contempt. --♫ Sänger - Talk - superputsch must go 10:43, 9 November 2014 (UTC)

Es hat keinen Zweck. Die Damen und Herren der Foundation äußern sich nur auf Einlassungen, die sich auf ihrer Linie "MV mit der Community verbessern" befinden. Alles andere ignorieren sie. Ich erkenne an, dass man auf manches, was hier in aller Schärfe formuliert ist, nicht antworten will. Doch ist die Härte mancher Wortbeiträge oft ein Zeichen tiefen emotionalen Mißtrauens gegenüber der foundation. Da sich die Damen und Herren der Foundation nicht die Mühe machen, ihre Position zum opt-in-Stellen oder gar zum "ob" des media viewer zu überdenken oder sich dazu zu äußern, mache ich mir auch gar nicht die Mühe, das auf englisch zu schreiben. Nach über 12 Jahren WP bin ich wegen dieser foundation so gut wie weg.

Manche mögen es als persönlichen Angriff sehen, wenn man danach fragt, was die foundation so mit ihrem Geld anstellt, das die Leute auf der Welt spenden. Ich halte es aber sowohl für eine absolute Notwendigkeit, dass das öffentlich gemacht wird (das ist ja wohl der Fall), und dass man sich Gedanken darüber macht, wie das Geld ausgegeben wird. Und wenn ich mir die reinen Angestelltenzahlen so anschaue und versuche zu verstehen, was die tun (Was, nochmal, macht die foundation mit dem Geld?), ist es die verdammte Pflicht der foundation, zu erklären, ob sie mit den gar nicht so geringen Geldflüssen nette Austragsposten für "Angestellte" schafft, oder ob das für die Mission erforderlich ist. Interessant finde ich in diesem Zusammenhang, dass das Spendenbanner diesmal keinen Link auf ein Wiki enthält, sondern nur links auf Bezahlsysteme. Sieht fast so aus, als ob sie sich bei den Spenden lästige Diskussionen vom Leib halten möchten. --193.18.240.18 09:05, 10 November 2014 (UTC)

Du hast ja recht, ganz offensichtlich geben die einen feuchten Kehricht auf die Community, die wollen ihr Ding durchziehen ohne von der Realität belästigt zu werden. So'n Glitzertand, wie ihn der MV darstellt, also reine Oberfläche ohne echten Nutzen, scheint bei denen wichtiger zu sein als echte Unterstützung der und Zusammenarbeit mit den Autoren. Ich weiß auch nicht so genau, wie mensch diesem völlig abgehobenen Haufen in SF irgendwie wieder auf den Boden zurück holen könnte, zuhören gehört ja nun mal nicht zu deren Stärken. Ich bin mir nicht mal sicher. ob die überhaupt gemerkt haben, was sie mit Ihrem völlig unverhältnismäßigen Tun angerichtet haben, oder ob die ihr Wolkenkuckucksheim tatsächlich glauben, das sie sich da so hinphantasieren. Die WMF ist unn mal die Serviceorganisation für die diversen Projekte im Wikiversum, die meinetwegen auch ein wenig auf externe Nutzer der Software eingehen darf, aber nur, wenn's den Kern nicht stört. Ohne aktive Einbindung der Projekte des Wikiversums haben die ihren Job verfehlt, die sind in der Bringschuld für Kommunikation, die sind in keinster Weise die Chefs. --109.235.137.238 10:00, 10 November 2014 (UTC)

EW about whitewashing

The history of the forceful releases was whitewashed three times (Why are this working difflinks red?), twice by Edokter, once by an IP. The release history with all its brutal force by the WMF against the communities should either be mentioned with all those aspects, or not at all. To conceal the use of force against the communities in this history is just plain, deceitful whitewash. I deleted the whole paragraph, if someone wants to reinstate it, please do so correct with all aspects. --♫ Sänger - Talk - superputsch must go 15:47, 10 November 2014 (UTC)

Please remember that mediawiki.org is related to developing and improving the software only. Even thought said software is released under the WMF umbrella, this website is by no means a platform to discuss the positions of other projects. These dicsussions should be held at meta:, not here. -- [[User:Edokter]] {{talk}} 18:53, 10 November 2014 (UTC)

Mediawiki is the software "department" of the Wikiverse, primarily for WP and it's sisters/cousins, and as well for other projects. AFAIK it's paid for by the WMF, thus by donations generated by the content the diverse WP etc. editors create. The main purpose of this software is to make the editors and readers of the diverse WP-projects happy. Everything else is just a nice add-on. So the dealings of the WMF with it's main customers is of essential significance here, not just this useless, whitewashed dates of deployment. Not mentioning that this piece of bling bloatware was implemented with brutal force against the explicit wishes of the communities and that it's not wanted in it's current outfit as opt-out is plain, deceitful whitewash. --♫ Sänger - Talk - superputsch must go 19:42, 10 November 2014 (UTC)

MediaWiki.org is the website for MediaWiki developers and people who want to install MediaWiki software. The release history is useful primarily to tell people how old the software is and whether anyone is currently maintaining it.

There are many thousands of organizations using MediaWiki. In the long-term, their technical staff are the people most likely to be reading "Extension" pages on MediaWiki.org—not Wikipedia editors. They are unlikely to care about what some Wikipedia editors said. Instead, they are mostly likely to care about how to install it and how to use it. It is the normal practice here to write "Extension" pages with that audience and their needs in mind. As Edokter says, discussions about which communities hold which opinions, and what should be done about that, are normally handled at Meta. Whatamidoing (WMF) (talk) 20:09, 10 November 2014 (UTC)

Dear WMF advocates,

Then why does the foundation not discuss the "opt-in" or, in consequence, the "abandon" part in this media viewer catastrophe there? They ask about the how and act as if everything were ok then. Why do they set the "discuss this feature" link to this very page? Dear WMF advocates, this very much sounds like adjusting the reality to the ideas of the foundation to me, and very much like giving a shit about what communities think. --89.12.206.191 21:20, 10 November 2014 (UTC)

It is whitewash, full stop. I know that the WMF doesn't care about the communities, does want to have this repugnant behaviour by the WMF against the communities be buried out of sight. It's soap-boxing to active prohibit the controversial implementation history and sugar-coat it's deployment on the advertisement page. You are the "servants" of the communities, not the bosses. You are paid by the communities, please begin to listen to them. You have implemented this piece with brutal of bling without any real, merited justification besides "because we say so". There was absolutely no need for the use of force, but you putsched against you employers nevertheless. I don't know why you did so, there really is no reason at all besides some dents in mega-egos, but a) you did and b) you seem to show no remorse for your evil deeds. But with all this sugar-coating, deletion sprees etc. about the issue you seem at least to recognise that your deeds do not make you shine in a good light. --♫ Sänger - Talk - superputsch must go 05:27, 11 November 2014 (UTC)

Image size

As currently implemented, the user does not know what the image size is without clicking on "More details", and so will not be aware if an image is large enough to crash the browser before an attempt is made to view the full size image. This seems like a significant oversight. WolfmanSF (talk) 01:27, 12 November 2014 (UTC)

You are right. Without the media viewer, the user is shown a moderately sized preview and all relevant information including the full size of the original image. In my view, the media viewer simply is not up to its job and should not have been introduced at all, considering all its shortcomings. --193.174.160.41 08:16, 12 November 2014 (UTC)

In the normal file pages you can click on various sizes the picture is offered and decide by yourself what resolution is good for you. With this superficial bling gadget there is no such option. They don't care about the users wishes, they just want their stupid gadget pushed in everyone's face. I fail to see any reason why this bling thing is made opt-out instead of opt-in, it's only about the egos at the WMF, bugger their customers and the community. --♫ Sänger - Talk - superputsch must go 17:06, 28 November 2014 (UTC)

IMO it does not help if you say that Media Viewer is a stupid superficial bling gadget and that they don't care about the community. I've seen you have said the same things so many times that you should already drop a stick. I still believe WMF cares about the users wishes. But you know, everyone can't be always happy about what they do, not even me. But whatever, I'm not calling them as uncaring people and raging everywhere. --Stryn (talk) 20:38, 28 November 2014 (UTC)

How can you POSSIBLY believe that the WMF cares about the users wishes when they ignore their own polls and the community? It's pretty clear they came up with some strawman hypothetical "readers" and "casual editors" and designed Media Viewer for them. When Media Viewer was roundly rejected by nearly everyone, including their intended audience, they rationalized forcing it on everyone by claiming it works for the silent majority that nobody has heard from rather than admitting they wasted so much in the way of engineering resources on something essentially nobody wanted. That's how people act when they're trying to preserve their organization and their jobs, not how they act when they care about their customers. --98.207.91.246 20:20, 29 November 2014 (UTC)

WMF proved without any doubt that they want to act explicitly against the communities with their use of force against the communities, especially with superputsch against the deWP. They really didn't leave any doubt about their contempt of the "unwashed masses". The communities should continue to donate content and money, and otherwise shut the fuck up. --♫ Sänger - Talk - superputsch must go 21:34, 29 November 2014 (UTC)

Related bug: phab:T77812 Warn users if they click to enlarge huge images --Tgr (WMF) (talk) 19:32, 18 December 2014 (UTC)

A possible compromise?

Until such time as all the above mentioned issues with the media viewer are sorted out, I should like to propose the following compromise: Selecting an image or other media file in a Wikipedia article shall lead to the traditional description page for said file (such as en.wikipedia.org/wiki/File:..., commons.wikimedia.org/wiki/File:... or their equivalents in other languages and projects), but the "Open in media viewer" buttons on the description pages shall be kept. Pop-ups shall not be used. This way, users can test the media viewer at their leisure and give feedback, while the files are presented in a tried, proven, inobtrusive, and reliable manner. --Schlosser67 (talk) 11:46, 14 November 2014 (UTC)yur mum 'yur mum

Will not donate in 2014 - reason: the "Media Viewer"

If Wikimedia's developers have the time and the money to deal with unnecessary bullshit like this "Media Viewer", there still seems to be a lot of money in the purse. This stuff is absolutely unusable, especially on mobile devices. And yes: users were able to perfectly view pictures without it, and for years!

In past years, I usually donated a 2-digit Euro amount for Wikipedia. This year, I will restrain from this custom.

Revert to the previous state, and I will donate again. Hopefully, you understand this language.

Me too. My dollars are going elsewhere this year.--146.151.205.174 18:20, 25 November 2014 (UTC)

Me three. Utter garbage, a bad solution where there was no problem. --87.242.202.85

Me four. I used to donate hundreds of dollars per year, not any more until media viewer is removed and the programmers fired.

Me five. Bis auf weiteres kein Geld mehr an die Stiftung!

Me sixth, this Feature is bad 120.146.157.227

Notification damages file page

There is a notification that the dedicated professionals of media viewer have added to the file page. It serves to notify the reader that they have disabled media viewer. This is superfluous, since the user has just clicked on the unlabeled button and actively disabled this blight so they already know what they have just done. The notification is also a slap in the face of the reader, since it is placed to cover over part of the image and thus demonstrates the contempt that the dedicated professionals of media viewer have for the choice of the reader to not use their pustule on Wikipedia. The offending code:

<div class="tipsy mw-mmv-tipsy-dialog tipsy-sw" style="top: 451.433px; left: 290px; visibility: visible; display: block; opacity: 1;">
    <div class="tipsy-arrow"></div>
    <div class="tipsy-inner">
        <div class="mw-mmv-tipsy-dialog-disable"></div>
        <div class="mw-mmv-tipsy-dialog-title"></div>
           You have disabled Media Viewer
        </div>
        You can still view individual files with Media Viewer.
    </div>
</div>

Seriously, what kind of institutionalized vandalism is this? Media viewer is leaking.

I do agree on this one: we know we have disabled media viewer, by reminding us this fact every time we look at an image, you are taking us as stupid people or what? I have voluntarily disabled media viewer for several reasons: it doesn't work at all on some computers ; when it works, functionally, it's a huge regression from the simple original file viewer ; it hides major information ; ... Why do you need to put this ugly button in the middle of a page ? Many people don't want to have anything to do with MV, please remove this button. --NicoV (talk) 10:53, 19 November 2014 (UTC)

What you see when you disable Media Viewer

What you see if you open a file page with Media Viewer disabled

I just checked this, since I hadn't seen it before. There is an 'X' in the corner of the box. If you click that, then the box goes away, and stays gone for all subsequent image views.

I assume that the rationale for having a confirmation box is that people usually like knowing that their effort to disable it actually worked. "I clicked, but nothing seemed to happen" is not very comforting. Whatamidoing (WMF) (talk) 19:20, 1 January 2015 (UTC)

It's pretty evident that disabling it worked because one is looking at the file page and not media viewer. All adding this confirmation does is add an extra click to dismiss it. If a user needs confirmation that they are seeing what they are looking at, they should get help with either their eyes or their sanity.--69.11.241.134 05:44, 8 January 2015 (UTC)

If you look at the image, I believe you will agree with me that the user is still looking at Media Viewer when this confirmation appears.

In the second image, you can reach the file page by opening an image in a tab (my normal method), so you can reach this regardless of Media Viewer's settings. But imagine that I navigated to that page and then disabled it. The options are: (a) nothing at all happens or (b) there's some sort of notice that it worked. I think that acknowledging that it worked is the better choice. Whatamidoing (WMF) (talk) 18:34, 16 January 2015 (UTC)

I can see why you might need a feature like this given your use case and psychological need for confirmation. Even so, the positioning of this notification so as to cover over important parts of the file page UI (e.g., available image sizes) and part of the image itself is so inept as to be insulting. --69.11.241.134 07:21, 18 January 2015 (UTC)

Legal ?

@ http://de.wikipedia.org/wiki/Wieland_Herzfelde#mediaviewer/File:Grab_von_Wieland_Herzfelde.jpg

Is it legal to present only the uploader, not the author? 91.65.51.204 10:42, 19 November 2014 (UTC)

in this special case, the "source" section of the file was not properly formated, with the authors name blocked by a "nowiki" tag. If that is fixed, the authors name should appear on the left and the (last) uploaders name on the right. Alexpl (talk) 08:53, 8 December 2014 (UTC)

Media Viewer Update: Last Improvements

Media Viewer now shows captions right below the images.

Hi folks: we're happy to let you know that our multimedia team has completed all the requested 'must-have' improvements to Media Viewer for this release, based on community feedback.

Here are the new features that are now live on all Wikimedia-hosted sites:

• A caption or description right below the image -  Done (new)
• Move license label after source and adjust layout -  Done (new)
• An easier way to enlarge images by clicking on them -  Done
• "More Details" button: a more prominent link to the File: page -  Done
• Separate buttons for "Download" and "Share or Embed" -  Done
• An easier way to disable Media Viewer for personal use -  Done
• Re-enable Media Viewer from a file page -  Done
• Rename File page button: "Open in Media Viewer" -  Done
• Make MediaViewer text larger in Monobook -  Done
• A simpler metadata panel with fewer items -  Done
• Faster image load with thumbnail pre-rendering -  Done

These features are now live on all Wikipedias and sister projects. You can try them out on this 'Featured pictures' page.

These features are based on the most frequent requests from our recent community consultation and ongoing user research. We are now conducting a final round of usability research to confirm that they provide a better experience for readers and casual editors, the primary target users for Media Viewer.

Many thanks to all the community members who suggested these improvements! Your feedback was invaluable and helped us build a better product together. :)

Please let us know what you think. We will post one more update in December, to share our research findings. Best regards. Fabrice Florin (WMF) (talk) 00:21, 22 November 2014 (UTC)

Well, as you can see in comments in this page (if you take them into account...), the "Re-enable Media Viewer from a file page" feature is not seen as an improvement by many. If you really think that some people find this useful, could you at least add an option in the user preferences to entirely remove this button from the file page and any reminder that we have disabled MV (I know I have disabled it, and I'm not interested in it, and apparently I'm far from being the only one) ? --NicoV (talk) 08:04, 22 November 2014 (UTC)

I've always thought that the file page was extremely user unfriendly, and so was the fact that on too many occasions, you need to see the caption when seeing the image, which was impossible in the previous system. So it's something I had in mind for years. And I say that despite the shortcomings of the initial implementation, which is kind of a habit for new features it seems. So I support this development. I hate the stupid smiley cubes, however. A way to hide those would be appreciated. Cenarium (talk) 17:17, 22 November 2014 (UTC)

The abovementioned changes only show that the media viewer was badly implemented from the outset. The "File: ..." page can do most of the important things listed above (it loads fast, it shows caption and descriptions, it allows to download copies of the file, it allows to view larger versions of images, it shows metadata and licenses ...) which leads me to the logical conclusion that the media viewer has not been necessary at all from the beginning, and we can do just fine, if not better, without it. As a side note, as a "reader and casual editor" I'd rather see more than fewer metadata, so the "simpler metadata panel with fewer items" is a rotten idea in my book. Furthermore, I agree with NicoV - the repeated reminders that we have switched off the media viewer are unnecessary and annoying. --188.108.142.35 20:23, 23 November 2014 (UTC)

After all these fixes, it's still a slow lightbox that hides the caption (what's up with 589... you cut off the caption and pretend that is showing it... lame), other useful metadata, and attempts (unnecessarily) to replace the native image viewing capabilities of my browser. As I've been saying all along, even if you fix all the issues with the viewer, it's still a bad idea that is not fit for it's supposed use on an encyclopedia. It is only useful as a slideshow, something of little use on an encyclopedia article, especially with the captions hidden! Still outstanding bugs: opt-out does not stick for people without accounts, media viewer still displays when someone links directly to the media viewer page, even if media viewer is disabled. Can you please finally listen to your users and turn this terrible software off by default? --98.207.91.246 01:13, 24 November 2014 (UTC)

Media viewer still is not an option, but dictated on us. Perhaps WMF wants me not to see Wikipedia (as an editor and as a reader) as an option? With the WMF and you I come back to the opinion that centralizing knowledge is a bad idea, and probably will focus on ideas and possibilities to de-centralize knowledge. This will mean to support very widely distributed knowledge (and encyclopedia-like articles) and means of finding that knowledge, not to forget means to contribute to that. The behaviour of the WMFs ways is a reason for that. --193.18.240.18 08:53, 24 November 2014 (UTC)

One more criticism: Image categories are not displayed in the media viewer. All in all, it cannot do more than any halfway modern browser can do (usually faster than the viewer) in the File: pages, and it is therefore a superfluous piece of software. WMF should give up the media viewer as a bad job. --193.174.160.41 08:56, 24 November 2014 (UTC)

The #1 requested "must-have" improvement continues to be that media viewer be returned to development as an opt-in project. It's not fit for purpose and remains worse than nothing. Why do you like doing this to us? I used to be a "reader and casual editor", but I will not contribute any content until media viewer is gone.--128.104.68.48 16:03, 24 November 2014 (UTC)

Fumbling my way into this media Viewer again, I found myself saying out loud: "Oh it's horrible, all web 2.0 and yukky". That's probably wrong, it's full of barely-functional AJAX that breaks the "printed page" expectation of an Encyclopedia, and replaces it with mystery meat icons, extremely slow "blur-loading" progressive image display, a thing that slides up from the bottom unexpectedly and gets in the way with any futile attempt to scroll down, amongst a general inability to find out simple details about the image, or what it even looks like 1:1 (yet to find out how to do that without having to download it). It's not a phone, it's an encyclopedia! Adx (talk) 22:58, 27 November 2014 (UTC)

Regarding the title: do you mean there will be no more update, :) ? I suggest changing the title (including #Media Viewer Update: First Improvements above too) to something fixed (month would be a good choice), and won't be expired soon (otherwise, you'll soon run into problem: Media Viewer Update: Last Improvements, Second Edition?)

Also, linking 'Featured pictures' page is not a good idea, since they're only there for a period of time. Consider linking to a more permanent example for the sake of future readers. Cheers. Bennylin (talk) 10:09, 16 December 2014 (UTC)

Bug: The first caption of a Template:Multiple image is shown for all its images

Tracked in Phabricator
Task T85354

See for example en:Template_talk:Multiple_image#More_parameters_please. The viewer captions all images as The Old Mill, which is the caption of the first image. (System: Windows 7, Google Chrome 39, Internet Explorer 11). Olli Niemitalo (talk) 14:25, 1 December 2014 (UTC)

Yeah, multiple image templates has a host of problems. it's a creative craft work and not a supported software feature though. As such, it is expected to break in some subtle ways. —TheDJ (Not WMF) (talk • contribs) 12:23, 18 December 2014 (UTC)

This should be fixed now (thanks to M4tx for writing the patch!). Will go live mid-January. --Tgr (WMF) (talk) 09:00, 30 December 2014 (UTC)

Waste of time and money

I honestly consider Media Viewer a serious waste of time and money. Nobody asked for it, nobody needs it. Donated money should be spent on storage, bandwith and content-related activities, or put aside for future use. Wikipedia is about a free encyclopedia, not about funding nerdy projects of software developers. Somebody at WMF should be fired for this scandal. --92.105.193.61 17:20, 2 December 2014 (UTC)

Agree save for one minor detail: MV is not a waste of money for those getting paid to develop it. Major WMF funding's been diverted for this amateurish (and dishonest) venture.

MediaViewer takes up too much screen real estate.

I had the misfortune of clicking on an image that I wanted to see in more detail, and coming into what I discover to be "mediaviewer." I really wanted to "X out" of everything, but it is not clear to me how this is done. The grey box at the bottom of the page is annoying as hell. Maddening is an understatement for this cruft. Mandatory feature request: way to disable the whole kit and caboodle once and for all. Really, you're making enemies with this thing. 67.171.121.248 15:05, 4 December 2014 (UTC)

You can disable the whole MV, just click on the cog at the top right and select "Disable Media Viewer". (@MV development team: it seems that this cog isn't a good idea and many people don't find it. I suggest to revert to the earlier bottom-text version.) On the other hand, I like MV so that I ask you to don't remove it entirely from the Wikimedia wikis. I don't mind if it's opt-out or opt-in, but it'll be easier if it could be enabled/disabled centrally (when the central accounts are in the progress to enable central preferences). --Tacsipacsi (talk) 22:06, 4 December 2014 (UTC)

The cog icon gets more than twice as much clicks as the bottom text did. --Tgr (WMF) (talk) 19:49, 18 December 2014 (UTC)

If the cog does get that many clicks, it is a sign that many people do not like the media viewer, or do not like having it forced upon them. Thus, something needs to be done, see the sections about compromises. --193.174.160.41 07:32, 8 January 2015 (UTC)

Proposing another compromise

Some people prefer the file page, and others prefer the media viewer. Some do not want the latter at all, others want to keep it. No consensus seems to be in reach. Thus I propose that - instead of the images themselves serving as links - in the future two links should be offered next to every image in the Wikipedia articles and in related projects, one leading to the file page, and the other to the media viewer, so that all users can chose the option that suits them best, without being bothered by the option that they do not want. --193.174.160.41 15:55, 12 December 2014 (UTC)

Why don't you just turn it off ? —TheDJ (Not WMF) (talk • contribs) 11:57, 18 December 2014 (UTC)

We considered something like that (phab:T77731) but images can be used in complex ways and adding markup on top of them would almost certainly break things. --Tgr (WMF) (talk) 19:51, 18 December 2014 (UTC)

Markup on top of the picture was not asked here. That's too complicated anyway. I guess it was rather meant that e.g. clicking on the picture could lead ot the media viewer, and clicking on the caption to the normal file page (or perhaps vice versa), or maybe that two buttons (say, "File" and "Viewer" are shown next to each image. Keep it simple and fast. Switching off the media viewer is only a crutch, not a solution. --188.108.130.91 20:31, 3 January 2015 (UTC)

We considered that too at some point (and using the magnifier icon as well); but it is very confusing behavior if you are not aware of it. Any method to select between the viewer and the file page should work for users who are not so familiar with MediaWiki and not clear about the difference. I think the cog icon does that well; a simple "hidden link" to the file page wouldn't.

Also, like the overlay, it's easy to do for a standard thumbnail, but it can't be done for images used in other ways (which don't necessarily have captions). --Tgr (WMF) (talk) 00:39, 4 January 2015 (UTC)

Why are you always writing about "overlays", "hidden links", and the like? You are making it way too complicated. It is so simple: Next to each caption is already a link icon (two interlaced rectangles) that used to lead to the file page (or still does if the viewer is shut off). Keep this, add an "F" for "file page" to it, and add another icon, maybe something with an eye with a "V" for "viewer", next to it that leads to the media viewer. Make captions obligatory, too, that's the way it should be in an encyclopedia. --193.174.160.41 07:29, 8 January 2015 (UTC)

The "cog" icon does not do it well, but too late. And it requires cookies if I do not want to click it over and over again. When I see it, MediaViewer is opened already, which is especially painful (takes long) if the original image is big. And many images are big indeed, which starts at resolutions around 3000x2000 pixels. It is not a good solution if users cannot decide before the "tool" is started. --193.18.240.18 15:18, 26 January 2015 (UTC)

Please turn this off by default (german WP)

It takes up to 5 seconds to "load" some pics, the screen and frames jump back and forth, shows a blurry view until it settles on a "final" view. Aggravating. I don't see a net gain. --92.202.122.17 13:49, 13 December 2014 (UTC)

In these cases, the opriginal commons page loads much faster, because it uses a smaller sized version of the image, which can be viewed in full resolution with only one click. This is also possible with Firefox on Android, I don't see how to do this with Media Viewer on any browser on any OS.

The only net gain I see about MV is the possibility to browse all images of an article, commons cat. or whatever. But MV is not fit for that, e.g. for these reasons.

There are other issues with Mediawiki which, at least for me, would be of more use than MV. The mobile edition, which is, as it seems, default for WP on Android, either does not have or does not make obvious all functions MediaWiki has for readers. It "folds away" nav bars and useful links, which makes the history or link tools (what links here etc.) difficult to use. A good style for mobile devices, which is useful for both editors and readers, could help the community, the readers and, in consequence, the mission, more than this inadequate "feature". Perhaps, it would even yield a decent solution for browsing images which cold benefit the non-mobile styles as well if it replaced the current MV. --193.18.240.18 10:22, 16 December 2014 (UTC)

Media Viewer is desktop-only. The mobile website uses a completely different system for showing media. Whatamidoing (WMF) (talk) 19:25, 1 January 2015 (UTC)

Which is rotten and makes me use the desktop version. Please do not use such misleading, empty answers on me. --193.18.240.18 08:40, 9 February 2015 (UTC)

Kill it

PLEASE disable this by default. Listen to the community, nobody wants it; this is a solution to a problem that didn't exist. Just get rid of it.--90.192.131.143 21:15, 21 December 2014 (UTC)

All I wanted for Christmas this year was for media viewer to go back to being an opt-in development project until it is both usable and useful. --75.101.25.232 02:01, 5 January 2015 (UTC)

It's 2016, and I haven't contributed any edits to WP in the past year. It pains me to see things I could fix or add to, but I will not do so while this shitpile is still the default. Join the edit boycott today! --69.11.241.134 04:33, 11 January 2016 (UTC)

This Sucks Big Time

Annoying, cumbersome, unnecessary, intrusive...I literally do not have enough descriptive adjectives to express how horrible this thing is. Stop changing shit just for the sake of change and go back to building an awesome encyclopedia please. If you paid nothing to whoever coded this digital turd it was STILL too much. This comment unsigned.

I agree completely 206.217.95.210 21:17, 12 January 2015 (UTC)

Android

Have you tried this with _any_ Android browser? In the selection of 7 browsers installed on my machine this makes the picture unviewable 94.174.119.101 01:55, 27 December 2014 (UTC)

Media Viewer is desktop-only. The mobile website uses a completely different system for showing media. Whatamidoing (WMF) (talk) 19:26, 1 January 2015 (UTC)

Yes, but many Android browsers (especially on tablets) use the desktop view of Wikipedia. MW should detect if the browser cannot display MV and if so, it should use the old image page. (P.S. It works perfectly on Safari/iOS 8.) --Tacsipacsi (talk) 21:21, 1 January 2015 (UTC)

It works in both Firefox and Chrome on my phone (Nexus 4 / Lollipop). --Tgr (WMF) (talk) 17:13, 3 January 2015 (UTC)

The mobile version is totally inadequate in many ways:

• It folds sections, which makes the loaded article unreadable,
• it does not show a TOC of the article, which makes it difficult to browse long articles,
• it does not offer any of the important links in the default view, which is: history, and the tool links usually in the left nav bar.

The most important link is: "Desktop". Then, MV is default again, which, as stated above, sucks on Android devices. --193.18.240.18 08:39, 8 January 2015 (UTC)

Maxthon

Tracked in Phabricator
Task T85843

Der MediaViewer lässt sich im Maxthon Browser (e.g. Android 4.1.2) nicht abschalten. Das entsprechende Symbol ist nicht vorhanden/sichbar. Bitte fixen.

Bug: Incorrect "created" date

I recently uploaded an image to commons ( File:USAF Boeing KC-97 stratotanker ORD.JPG ) and was concerned to find media viewer displayed a "created" date of December 31,1972. I have no idea where this erroneous information came from. Aside from that, I have no quibble with MV. Bruce Marlin (talk) 02:29, 9 January 2015 (UTC)

MV reads that date for the |date= field of the information template (it does say January 31, 1973 for me). -- [[User:Edokter]] {{talk}} 18:05, 9 January 2015 (UTC)

Delete File/Rename File function

Where is it Delete File/Rename File function for uploader. I've uploaded the file, and a little mistake in the title, now renamed easiest way is not possible. As well as to delete the file. Can add file management functions for uploader. 4Sage Wiki (talk) 14:39, 19 January 2015 (UTC)

Non permanence of links

Tracked in Phabricator
Task T87813

Links to mediaviewer images only work as long as the image linked to remains on the page it was on when it was linked to. For example the traditional link https://en.wikipedia.org/wiki/File:Mute_Swan_800mm.jpg will remain working unless the image is deleted or moved. https://en.wikipedia.org/wiki/User:Geni/temp#mediaviewer/File:Mute_Swan_800mm.jpg breaks as sooon as the image is removed from the page it was viewed on.Geni (talk) 11:39, 21 January 2015 (UTC)

Please disable it

"To disable Media Viewer, click on the 'cogs' icon at the top right corner of Media Viewer (see screenshot)." - but I don't have any icons on the top right corner and on any other corners too. Don't say that is something wrong with my browser, just disable it. It's "Annoying, cumbersome, unnecessary, intrusive...I literally do not have enough descriptive adjectives to express how horrible this thing is.".

20150725 I second this. I have a cog, and even a giant button that reads "Disable Media Viewer". However, clicking it literally does nothing! No idea why they changed something that worked so well. And they didnt even just change it, they made it terrible

MV fails to show descriotions for this image

This image does not show a description in MV:

http://commons.wikimedia.org/wiki/File:Scottish_Crown.jpg?uselang=de#mediaviewer/File:Scottish_Crown.jpg

And I still do not understand why everybody is forced to open this MV thing before being able to go to the file page. --193.18.240.18 15:23, 26 January 2015 (UTC)

Because it requires machine-readable data (e.g. via {{information}} template). --Tacsipacsi (talk) 17:11, 26 January 2015 (UTC)

So you tell me that media viewer needs a machine that checks if 16 million items have such "machine-readable data" and a myriad of humans to modify a fraction of these 16 million items to adapt them? I'd call this an epic fail. --193.18.240.18 07:50, 28 January 2015 (UTC)

Yes, that's exactly what was done: They invented something with complete disregard for the reality, on bogus interpretations of some dream-land of templates. Digging into the deep of the real world of media stored in commons and the different wikis would have been far too complicated to those nincompoops. That would have meant real work, not just the shiny bling-nonsense they created. Perhaps they really believed the world was flat and were quite surprised by the intrusion of the reality into their wishful thinking. --♫ Sänger - Talk - superputsch must go 17:40, 28 January 2015 (UTC)

Please disable by default

CristianChirita (talk) 12:51, 27 January 2015 (UTC)

Seconded. This is never what I want, and I cannot think of a single person for whom this would be what they either want or expect. And it's not like anyone I know is a techie: I'm thinking of standard people who have no idea about how Wikipedia works. 31.54.195.124 23:33, 15 February 2015 (UTC)

Pictures incorrectly cropped

Tracked in Phabricator
Task T89631

Tracked in Phabricator
Task T89679

Win 7: IE 11 & Chrome 40

In both IE and Chrome, MV loses a significant portion from the bottom of the picture it is displaying. I'm surprised that I (or no one else) hasn't noticed this before, so perhaps it is a new bug inadvertently caused by some othert change. Additionally, in Chrome, toolbars obscure the top of the image (MV seems to be using the wrong number to calculate screen extent -- one that does not allow for the space taken by toolbars). 86.152.163.55 21:16, 15 February 2015 (UTC)

Can you link to an example image where this happens? Does it happen on all images / some / a lot? Does it happen every time or is it non-deterministic? Also, a screenshot would be great (you can drag-and-dop images to the comment box at phab:T89631). --Tgr (WMF) (talk) 06:25, 16 February 2015 (UTC)

The cropping at the bottom seems to happen consistently every time with every image I have tried.

Example of cropping in IE:

http://tinypic.com/view.php?pic=1zcl1zp&s=8#.VOJc7SxyYU8

Example of cropping in Chrome:

http://tinypic.com/view.php?pic=2evgilv&s=8#.VOJd2SxyYU8

Example of additional problem with extreme cropping/distortion:

http://tinypic.com/view.php?pic=rido4k&s=8#.VOJeVixyYU8

This last category of problem happens less predictably, but often enough to be a pain. I have reported this at least twice before (e.g. here) but it has never been fixed. Sometimes the image is streched vertically (as in this example), and sometimes horizontally. 109.145.180.34 21:26, 16 February 2015 (UTC)

Uhh, sorry about ignoring your previous bug report :( That shouldn't happen.

I realize it shouldn't be your job to do that, but if you register to Phabricator and report bugs there, there is much less chance of them being missed/forgotten/archived by accident.

The Chrome bug is probably from a change we did a few weeks ago.

Can you clarify what Additionally, in Chrome, toolbars obscure the top of the image means? I don't see anything like that on the screenshot. By toolbar, do you mean the bookmarks bar? --Tgr (WMF) (talk) 22:33, 16 February 2015 (UTC)

No, not the bookmarks bar but an additional third-party toolbar. None of the above screenshots demonstrate this problem. I hid the toolbar as part of testing (to check that this would reveal the obscured top of the image) but now I cannot find a way to show it again, so I cannot get a screenshot. 109.145.180.34 22:57, 16 February 2015 (UTC)

Is this a Chrome extension? Which one? --Tgr (WMF) (talk) 23:22, 16 February 2015 (UTC)

It is a Norton toolbar. I managed to get it to show again. Here is a screenshot: http://tinypic.com/view.php?pic=10df81u&s=8#.VONGPyxyYU8

Thanks for the screenshot! Filed as phab:T89740, but I doubt we'll have the time to look into this one. --Tgr (WMF) (talk) 18:43, 17 February 2015 (UTC)

Add a dismiss button and a preference to just turn it off. It consistantly irreversably crops the bottom of the picture. It actually PREVENTS VIEWING THE IMAGE in a tool called IMAGE VIEWER. See here:

Example of incompetant programmer's work, you can't see the bottom of the image.

Riventree (talk) 16:05, 20 February 2015 (UTC)

Media Viewer 2014 Reports

Check out the Media Viewer Research 2014 Slides, for a visual presentation of key findings.

Daily image views for Media Viewer and File Page, May-Dec. 2014. Source: WMF.

Percent of global logged-in users with Media Viewer enabled or disabled as of Dec. 8, 2014, by user group. Source: WMF.

Hi folks,

The multimedia team completed a review of Media Viewer in recent weeks, and we'd like to share a few highlights of what we learned from this project in 2014.

1. Research
Here are some key findings from our research about this product:

• Media Viewer serves a lot more images than before (17M intentional views/day)
• Most users keep Media Viewer enabled (99.5% enabled)
• Media Viewer key features were found easy to use
• Media Viewer is more useful for readers than active editors

More information can be found in this Media Viewer Research 2014 report. It summarizes our collective research from last year: image views, enabled rates, activity and performance metrics, as well as usability tests and user feedback.

Check out these companion slides, for a visual presentation of more findings (see thumbnails to the right). Some of these slides were included in the multimedia team's Quarterly Review meeting.

2. Retrospective
The multimedia team also discussed lessons learned from this project in 2014, identifying what worked and what didn’t work, in order to inform future product development.

Here are some highlights of that team review.

The Media Viewer project ran from July 2013 to November 2014 and was more challenging than expected. While the product received favorable or neutral feedback on most Wikimedia sites, it was met with negative reactions from many contributors on the English and German Wikipedias, as well as on Wikimedia Commons. This caused the team to work longer than planned, to improve features based on user feedback.

What worked well:

• Detailed activity and performance metrics.
• Design research -- before and after implementing a feature.
• Working with community champions in different projects.
• Agile development process and tools.
• Unit tests to improve the code.

What didn't work well:

• Many community discussions did not effectively inform product development.
• Surveys were not representative, because they were optional.
• We lacked the tools to get productive feedback from different user groups.
• Juggling feature and platform development at the same time was hard.
• Scope creep; the workload kept growing beyond available resources.
• No clear success metric; we couldn't tell if we had met our goal.

More findings can be found in this Media Viewer Retrospective summary.

We also discussed some of these findings in a special session on user-facing feature releases at the MediaWiki Developer Summit in San Francisco. This discussion led to a number of possible solutions for improving the way we develop and release features like Media Viewer. Here are the Etherpad notes from that discussion.

Please let us know if you have any questions about this research or retrospective.

We're grateful to all the team members who worked on these documents, especially Gergő and Gilles. These findings can help us better understand how Media Viewer serves our users — and how we can improve not only this product but also our development and release process.

This will be my last post on behalf of the multimedia team, as I have now transitioned into a new role at the Wikimedia Foundation, working as Movement Communications Manager for our communications team. Senior engineer Gilles Dubuc is now leading the multimedia team and can answer questions related to upcoming projects.

I’d like to thank all the community members who worked closely with us on this project, as well as my colleagues on the multimedia and product teams. We learned a lot together, and I really enjoyed creating a better product with you all. I look forward to more collaborations in coming years. Fabrice Florin (WMF) (talk) 08:13, 18 February 2015 (UTC)

Fabrice, your statistics are flawed, or rather the approach to them is. You will of course get a high percentage of users who have the viewer enabled if you make it the default, in particular if occasional users do not bother to log in, and view only a single picture, or only a few pictures. Granted you have improved the "product" (that's an inapproriate word, by the way, because you do not sell it - "products" have no place in a free encyclopedia), but it is still flawed, viz. the many complaints about long loading times and other shortcomings. Notice also that the percentage of enabling the viewer decreases with intensity of use. Should that not ring a bell?

That having said, I'd like to suggest one major improvement: Once the viewer is disabled in a single Wikipedia, it should be disabled in all others; e.g. if I disable the viewer in the Spanish Wikipedia, and then move to the Polish one, or to Wikimedia Commons, it should already be disabled there, too, without me having to disable it again. Gilles, how about that? --193.174.160.34 08:16, 24 February 2015 (UTC)

99.5% is for all logged-in users (we didn't measure anonymous users as that is a lot harder both technically and conceptually).

Complaints about slow loading times do not match actual measurements - the research report has some details about that.

There is no support for global preferences currently, neither in browsers nor in MediaWiki, so Media Viewer won't have them either until that changes. If you are logged in, you can use a global script to disable it everywhere - I added some instructions to the help page.

While I don't really like the word product myself, it's fairly standard in the software industry, even for open source software (e.g. Mozilla products, Canonical products); and it comes from the verb produce, not related to selling in any way. --Tgr (WMF) (talk) 23:58, 24 February 2015 (UTC)

Has the multimedia team considered commissioning an independent assessment of this "product", as this report seems to be more of a whitewash? The majority of the comments on this page make it abundantly clear that the team is in deep denial. 81.154.114.151 19:00, 30 January 2016 (UTC)

MediaViewer doesn't show the hole picture, a text box overlaps bottom part, no "X" button to close this box (de: Der Medienbetrachter zeigt nicht das ganze Bild, eine Textbox überlagert den unteren Rand und es gibt keine Schließen-Schaltfläche)

In English Look at this, using the Medienbetrachter (Media Viewer): [[1]]

A text box, presenting the name of the picture and itsauthor overlaps the bottom part of the picture. You even can enlarge this box by scrolling down (me, I expected the incompletely shown picture to scroll!), but it misses a "X" button to close it! An even better alternative would be, that Media Viewer would resize the picture already from the start, so that it completely fits in the space above this box, with no overlapping.

Unbelievable for me, that such a fundamental malfunction is included in an already released tool such as Media Viewer. Please hurry to fix this.

Auf Deutsch Sehen Sie sich dies mit dem Medienbetrachter an: [[2]]

Eine Textbox, die den Namen des Bildes und seinen Autor anzeigt überlagert den unteren Rand des Bildes. Man kann diese Textbox sogar noch durch Herunterscrollen vergrößern (ich hatte erwartet, dass das unvollständig gezeigte Bild scrollt!), es fehlt jedoch eine "X"-Schaltfläche um sie zu schließen! Eine noch bessere Alternative bestünde darin, dass der Medienbetrachter das Bild gleich von Beginn an so verkleinern würde, dass es vollständig in den Bereich oberhalb der Box passt, ganz ohne Überlappungen.

Es ist für mich unbegreiflich, dass solche eine grundlegende Fehlfunktion in einem bereits veröffentlichten Tool wie dem Medienbetrachter enthalten ist. Bitte beeilen Sie sich darin, sie zu beseitigen.

--212.204.79.69 10:36, 20 February 2015 (UTC)

To do I see the same problem in several other pictures e.g. here, please fix! --Bigbossfarin (talk) 19:08, 20 February 2015 (UTC)

Same bug two sections upper, see bug numbers there. --Tacsipacsi (talk) 21:22, 20 February 2015 (UTC)

Seems to be solved, see here. Thanks a lot. --95.90.216.202 22:11, 22 March 2015 (UTC)

Why are some remarks quickly deleted?

Some remarks are quickly deleted by reverting to the previous state of the page. Why? To me, stating that this MV is a piece of shit is very constructive indeed. It might hopefully make you understand that it is a big mistake, costing a lot of money. Beside, your arguments about satisfaction are grossly biased and saying that images are loaded faster than with the original way is just a lie. No money from me while MV remains the default viewer on all the languages I use.--86.68.63.85 13:45, 28 February 2015 (UTC)

Have you seen the hyper-glossed marketing-speak they dare label a "report" not two sections above this? They're not even on the same plane of _reality_ as the average Wikipedia browser anymore. You're surprised they're deleting shit?

A four letter word comes to fingertips when you try to zoom a pic in an Android, buggy buggy Android. This MV thingy is really not something you want to help you out when viewing pictures. --84.250.122.35 18:32, 20 April 2015 (UTC)

Some positivity

I just wanted to say, to counteract all the negativity in this page, I love this feature. I think the old media viewer was clunky, bloated, ugly, and outdated, and I hated the way it made you leave the article page. This is a huge step forward, and I think a lot of the casual viewers would agree with me. Keep it up, developers! --2605:E000:1C04:801C:B8D2:32CE:111E:1482 05:12, 3 March 2015 (UTC)

2605:E000:1C04:801C:B8D2:32CE:111E:1482, you realize IP addresses aren't anonymous, right? Especially given the rarity of IP6. Given your position at the WMF, this "anonymous user" vote of support feels a bit phony to me.

The WMF's own survey of our causal viewers shows that a majority of our global readership find Media Viewer to be "Not Useful", and an overwhelming majority of English language readers find it "Not Useful".... and that is with some survey respondents responding "yes" to the "useful" question explicitly because they interpreted the question as asking "does it work". I studied the WMF's survey responses. When you look at the text-field responses to the survey, the response ratio was over twenty negative responses for each positive response. An utterly miniscule percentage of surveyed readers had anything positive to say about it. So yes YOU like Media Viewer, and a small minority of our readers like Media Viewer, but don't say "a lot of causal readers agree with you" when we have the data showing it isn't true. Not to mention five RfC's across three wikis all overwhelmingly concluding Media Viewer should be opt-in. And if I recall correctly, I think 100% of the non-editors who responded to the RfCs did so objecting to Media Viewer. Alsee (talk) 08:32, 3 March 2015 (UTC)

I do not recall any "old media viewer" - there is only one that has evolved over time, but still does not feel quite right ... at least not when using it on a desktop for which I still find the file page much more useful, chiefly because it allows to explore file categories more easily than the media viewer, and because it usually loads a preview and is therefore faster. I cannot comment on its usefulness on mobile phones, as I do not own an internet-capable one. --193.174.160.34 13:27, 3 March 2015 (UTC)

Basic EXIF Data in MV?

Hi, It would be very very helpful if the MV would show basic Exif Data like camera model, aperture, focal length, exposure time, ISO and lens. Is this coming in the near future? --Sebaso (talk) 15:06, 14 March 2015 (UTC)

A feature showing EXIF by default would probably not get accepted as that's not interesting for most readers and the goal of MediaViewer is exactly showing a clutter-free image view which only contains information that is of general interest. The blocker task for that is bug T77152. Unfortunately, no major improvements are planned for MediaViewer for the foreseeable future as there are more pressing tasks. --Tgr (WMF) (talk) 05:03, 16 March 2015 (UTC)

And yet, displaying EXIF data is something that the file page is able to do in one click from the article without detracting from viewing the image. Why do you take pride in having less functionality? What is wrong with you?

Extra features really should be a priority

It greatly concerns me to read above that no further changes are planned as there are "more pressing tasks". If the WMF is at all concerned about the general quality of the organisation and presentation of files on Commons in categories and galleries, then it really should be listening to feedback here. If you can't find the time/money to do it yourself, at the very least consider grant funding it. You really won't regret it (even if the benefits to the mission won't be immediately obvious to you).

Simply put, the MV has been a great addition to experienced Commons editors like me, who now find it an invaluable addition to the toolset we use to improve the presentation and organisation of files in batches of anywhere from 10 to 200 at a time (and it's not unusual to tackle a batch of a 1,000 or more). But as good as it is to be able to scroll through these files in large size and to see the basic details, it would be even better for us in expediting our tasks, if even more information was provided.

In practical terms, to expand on the request above, not only would providing full EXIF data be fantastic (or at the very least both the date and time), it would also be invaluable to display the following:

• all categories (including hidden)
• resolution
• direction and object/camera coord data
• file usage
• the full unprocessed source parameter (because whatever MV does to display it is often not working)
• all templates present (retouch, extracted from, etc)

I tried to make these points during the consultation, but it appears to have been mis-interpreted as support for the current minimalist design aimed at novices, which it really wasn't. Whatever the WMF developers might think or have been told by other supposedly experienced users, the alternative method of manually opening the image description page to get this info is simply not practical at all.

And the other analysis/data extraction tools aren't all that great either - assuming they even work - CatScan has been undergoing a rewrite now for what seems like forever. And what you can do with tools like HotCat and VisualFileChange is greatly limited by what you know about the files in the first place. By far the biggest issue though is the complete absence AFAIK of any tool that can identify/process the timestamp of creation, rather than first/last upload, which is something that the MV currently mitigates against, but of course only as far as the date, not the time.

I frankly don't know how I managed to find the time/patience to do any of this manually before the MV came along, or before I became aware of the other tools. Now I find myself loath to do it the manual way, because I can actually get more work done with the tools in other ways. A better MV would change that.

While I fully understand why the WMF seemingly doesn't want this functionality provided in the standard MV, I don't see why it couldn't be done as a user preference to alter what appears in the expansion view. You presumably already sill have the code which displayed the categories and other stuff that was in previous releases. Ultra7 (talk) 15:21, 25 March 2015 (UTC)

I love it!

Today, April 25, 2015 is my first encounter with the Media Viewer.

I have always taken care to make credit annotations when using images from the 'net. Today, I found it extremely easy to do, not to mention being able to choose the size of the image. Now I can collect medium sized images and not have to ponder "do I really want" this huge full sized image on my computer.

I use images mainly for inspiration and reference work in my artistic life.

I appreciate the Media Viewer making my life easier.

Thank You!

How does Media Viewer work?

It doesn't. --92.202.108.72 00:35, 14 May 2015 (UTC)

CC-BY/Beerware dual license displayed as Public Domain

Most files on this page are licensed under both CC-BY and Beerware. When I click on one of those files in their respective articles, this Media Viewer thing erroneously describes them as Public Domain, some sort of reverse copyfraud. There are already so many people using my files without attribution, and this only makes it worse. Adelbrecht (talk) 21:58, 16 May 2015 (UTC)

@Adelbrecht: It’s not an error of MV, but an error of Commons templates. {{Beerware }} uses {{PD-Layout }}, which automatically adds PD tags. You should change it to {{Other License-Layout }} as it’s not a PD license. --Tacsipacsi (talk) 22:31, 16 May 2015 (UTC)

@Tacsipacsi: Thank you very much. It hasn't changed in the viewer yet, but that is probably a cache thing or something like that. Adelbrecht (talk) 18:59, 17 May 2015 (UTC)

Yup, cache thing, seems okay on my end now. Adelbrecht (talk) 19:04, 17 May 2015 (UTC)

Calloo! Callay! I finally figured out how to disable this piece of shit!

Why was this section quickly removed?--210.168.187.134 12:34, 19 May 2015 (UTC)

They don't like critics here, only lackeys. How did you manage to do it as an IP? --Grüße vom Sänger ♫^(Reden)_{superputsch must go} 15:34, 19 May 2015 (UTC)

@Sänger: You can do that. See here if you want to do so. --Tacsipacsi (talk) 16:34, 19 May 2015 (UTC)

@Tacsipacsi: I can do, and of course I have done, I don't like this piece of mindless facebookisation at all, like a lot of users, but I have an account and thus preferences. An IP doesn't have either. And what's that link supposed show? Grüße vom Sänger ♫^(Reden)_{superputsch must go} 16:40, 19 May 2015 (UTC)

@Sänger: It’s a link to another section of this talk page, where you can find two pictures showing how to turn off it without preferences (it works for logged-in users as well, and it can be useful if somehow it turns back). --Tacsipacsi (talk) 16:50, 19 May 2015 (UTC)

Yes, once you've been hit by it, and until you close your browser, or whenever you delete cookies. Not "die feine englische Art", as we say here in Germany. Grüße vom Sänger ♫^(Reden)_{superputsch must go} 17:59, 19 May 2015 (UTC)

Truly dreadful

What a waste of time and money. It should be disabled by default. --82.132.220.222 09:37, 14 June 2015 (UTC)

And they are asking for money. There will be no money from me while this dreadful thing is enabled by default on all the languages I read. --180.27.11.175 12:54, 14 June 2015 (UTC)

I agree, why 'fix' something that isn't broken. Sorry, no more money from me either. --84.137.134.251 23:14, 16 June 2015 (UTC)

Still much too slow

The viewer is still much too slow for everyday use, in particular on a slow connection or during busy times. If it showed a preview of the image of moderate size (say, longest side 640 or 800 pixels) instead of the full picture, just like the file page does, it would be much more convenient (but then, the file pages already did an excellent job, and introducing the viewer was not necessary at all, at least not for desktop users). --178.3.247.132 04:48, 24 June 2015 (UTC)

I agree, absolutly. --Fr.Latreille (talk) 21:41, 29 September 2015 (UTC)

Please see Multimedia/Media_Viewer/Speed_reports. --Tgr (WMF) (talk) 22:16, 29 September 2015 (UTC)

Getting file name

As an editor and content builder, one of the primary reasons I click on an image is to get the file name to place the image in other parts of the encyclopaedia. The media viewer offers no way of finding out that information. Could this be shown in small text somewhere in the media viewer? Or perhaps there could be an icon to copy the file name to clipboard? I think this could be achieved without being obtrusive, as for non-editors this is not a key detail. Sillyfolkboy (talk) 12:13, 12 July 2015 (UTC)

You can get it. It’s at the right side, below the license (and it’s also part of the URL). --Tacsipacsi (talk) 12:28, 12 July 2015 (UTC)

@Tacsipacsi: Thanks! I'd never noticed until now that you can scroll down while in Media Viewer. I've never really seen another webpage designed in that way before (particularly for a gallery). Maybe a button to scroll down would make this more intuitive. The web address was an inelegant way of getting this info as underscores needed to be replaced with spaces manually. Cheers. Sillyfolkboy (talk) 22:30, 12 July 2015 (UTC)

Still not usable for public

By error (or rather because I was given a direct Media Viewer link to an image by a third party) I used Media Viewer again today after having it disabled at all other times.

My conclusion is sobering:
Media Viewer is still completely unusable – yet it is enabled by default for the public.

My biggest point of criticism: Fundamental meta-information (Author, License) is still not presented in any reasonable way.

• Author and license fields (as all other fields) are represented by tiny vacuous icons. E.g. author is a smiley – what the hell?
• There's not even a tooltip to actually tell what those icons really mean.
• Somebody who does not already know what those fields mean for sure won't get it. It's obvious Media Viewer was build with design but not with functionality in mind.
  On a side note: Have the devs at any time had the idea to ask their grandparents if they understood the information presented? Certainly not...

--Patrick87 (talk) 12:12, 20 July 2015 (UTC)

I agree. Someone not very computer savvy will not be able to get any information from this thing, nor will he be able to disable it. As long as it is enabled by default I will not give money to Wikipedia. --62.212.113.136 17:23, 20 July 2015 (UTC)

I agree, the theming is horrendous. The text should be black and large. Filed as T108793 (likely duplicate, but it'll say so in a few minutes after someone triages it). Gryllida 07:24, 12 August 2015 (UTC)

Icons

The icon next to username is highly disturbing for three reasons:

1. it's not consistent with the rest of the wiki interface, and
2. it is just outright ugly and
3. redundant.

Please remove it. If you insist, please roll it out consistently as a beta feature and explain why it is needed in all languages. Gryllida 07:18, 12 August 2015 (UTC)

phab:T108794. Gryllida 07:26, 12 August 2015 (UTC)

Editing and upload features

Please make it clear in the media viewer that all users, readers, and contributors alike can edit and upload pictures. Gryllida 07:22, 12 August 2015 (UTC)

T77655 has some of the early plans, but in the end there did not seem to be a real need. Articles already have edit links, which should be the primary way to upload images, and for editing the details of an image, the big "more details" link is suggestive enough. --Tgr (WMF) (talk) 08:02, 12 August 2015 (UTC)

Probleme mit dem Browserverlauf

Wenn man ein Bild betrachtet und dann per Schließen-Button (Kreuzchen oben rechts) rausgeht, kommt man zurück zum Artikel. So weit so gut. Aber wenn man dann im Browser "eine Seite zurück" geht, öffnet sich erstmal das aufgerufene Bild, danach der Artikel und erst dann die (wirklich) letzte Seite. Das ist nervig und Null nutzerfreundlich. Im Sinne der freundlichen Einladung (Die Wikimedia Foundation würde gerne von dir hören, was du denkst), die sich IMHO mit der Tatsache beißt, dass man uns das unfertige Ding einfach reingedrückt und dann mit einem eigens dafür eingerichteten Werkzeug dafür gesorgt hat, dass das diesbezügliche Mitspracherecht der Community gegen Null tendiert, hinterlasse ich diese meine Wünsche einfach mal hier. Irgendein bezahlter Mitarbeiter wird sich hoffentlich drum kümmern. --Der irrende Memnel (talk) 15:54, 27 August 2015 (UTC)

This was discussed in phab:T64266. --Tgr (WMF) (talk) 17:26, 27 August 2015 (UTC)

Browser history issues still not solved

Tracked in Phabricator
Task T64266

I like the Media Viewer, but it's still very awkward that it creates browser history entries. This is counter-intuitive. It should behave like any other pop-up image viewer (e.g. the WordPress Lightbox extension). When I hit the Back button, I want to go back to the last article I viewed, not the last picture.

changing captions

How do I change the caption under an image of Lincliff that I captured, altered, and am using in an article I am writing about Eleanor Silliman Belknap Humphrey? The current caption makes it appear to be my own original image, which it is not.Mitzi.humphrey (talk) 18:33, 1 September 2015 (UTC)

Everything Media Viewer shows comes from the file description page or the image caption text in the article, so you'll need to edit one of those. --Tgr (WMF) (talk) 19:11, 1 September 2015 (UTC)

Anzeige in realer Auflösung / Größe

Gibt es eine Möglichkeit, mit der ich die Bilder im Multimediaviewer in der Originalauflösung (scrollbar) anzeigen lassen kann? Ich habe sehr große Bilder, diese werden stark verkleinert, damit sie auf den Bildschirm passen und sind daher kaum zu erkennen...

Eigentlich sollte draufklicken klappen, allerdings kann mensch sich nicht mehr, wie bei den richtigen Dateiseiten mit den vollständigen Informationen, die gewünschte Auflösung aussuchen, sondern bekommt entweder die angepasste oder gleich die ganz große angezeigt, was bei Volumentarifen oder langsamen Verbindungen ggf. etwas suboptimal ist. Aber wen interessieren schon Nutzbarkeit etc., wenn es um das "erste große Projekt der Abteilung" geht, da hat alles praktische zurückzustehen. Grüße vom Sänger ♫^(Reden)_{superputsch must go} 08:48, 2 September 2015 (UTC)

"More details" button has disappeared?

Tracked in Phabricator
Task T111156

What has happened to the "More details" button? Has it been removed? Is there really now no way to get from an image in an article to that image's page at Commons, other than disabling Media Viewer? Unlike most commenters I was happy with Media Viewer, but if there's now no way to click through to Commons I will be forced to disable it. - Htonl (talk) 10:52, 2 September 2015 (UTC)

Yes, how can I go to Commons from the media viewer? I don't want to disable it. Please solve quickly. Thank you! --= (talk) 13:14, 2 September 2015 (UTC)

Yes it has dissapeared - and is there a possibility to disable the Media Viewer centrally, so that I get to the Commons page directly? --Kersti (talk) 13:47, 2 September 2015 (UTC)

Unfortunately not centrally for your SUL-account, but just wiki-by-wiki in your preferences. I've done so in my usual wikis, MV just sucks.

If the button really has disappeared, that's a major bug, as only the proper file pages show the proper licenses and authors, without this direct link the MV commits license infractions in a huge manner. --Grüße vom Sänger ♫^(Reden)_{superputsch must go} 15:20, 2 September 2015 (UTC)

This is a bad thing, ever since yesterday. I've been leaving MV enabled, hoping it gets better. However, if this feature doesn't work tomorrow (not doing many picture things today) then I must disable it, and disabling it becomes one of the first things a newbie picture handler must learn. Jim.henderson (talk) 15:32, 2 September 2015 (UTC)

Sorry I missed this discussion earlier, but I see the "More details" button on enwiki, and on this site, so it's possible that the SWAT patches we deployed today fixed them. Sorry about that! Please let me know if you have continued issues. --MarkTraceur (talk) 17:51, 2 September 2015 (UTC)

Splendid; it was just a bug. I was afraid this might be a stupid design decision that would never be overturned. I noticed nearly an hour ago that it was working again, but didn't quite believe it. Perhaps someone in our hard working coder team ought to check this page more than once a day. Jim.henderson (talk) 18:10, 2 September 2015 (UTC)

There are two time slots every day when updates to Wikimedia software can be deployed, roughly corresponding to beginning and end of work in the PDT timezone; this bug was reported late evening PDT. How often this page is checked had little to do with bugfix turnaround time. @Kersti: see How can I turn off this feature? in the FAQ. --Tgr (WMF) (talk) 18:31, 2 September 2015 (UTC)

Bug in Media Viewer

Using Safari browser on Mac with OS X 10.10.5 (the current "Yosemite"):

If the file "https://en.wikipedia.org/wiki/File:Crab_Nebula.jpg" is viewed (by default) with Media Viewer at the highest resolution of 3,864 × 3,864 pixels, the display degenerates into a continuously flashing screen of repeated lines of tiny thumbnails of various images.

Turning off media viewer restores the expected normal view at the high resolution

With media viewer disabled, using the "View with Media Viewer" button the image also displays normally.

- en:wikipedia.org/User: Leonard G.

@Leonard G.: what do you mean by "at the highest resolution"? --Tgr (WMF) (talk) 05:02, 24 September 2015 (UTC)

Media Viewer is an extremely annoying and poor feature

Please at least give us the option of viewing an image in the way we have always done! Please desist from trying to take control of our browsers - you remind me of Google, Facebook et al who all nowadays do not seem to be able to help themselves from helping themselves so to speak.

This so-called feature 'Media Viewer' is horrible, utterly horrible; a big step backwards.

I repeat - please at least give us the option of viewing and/or downloading images in the way we always have done.

Thank you.

100 % OK with this opinion ! Jean-Jacques MILAN (talk) 10:30, 28 October 2015 (UTC) 10:30, 28 October 2015 (UTC)

Not showing multiple licenses

In case of multi-licensed content, only one license is showed in Media Viewer. --KuboF (talk) 15:34, 17 October 2015 (UTC)

Misleading 'You need to attribute the author' button output

Tracked in Phabricator
Task T119686

I have a suggestion for the author attribution to improve the output of the 'You need to attribute the author' button. I will use the example https://commons.wikimedia.org/wiki/File:Iglesia_de_San_Pedro,_Teruel,_Espa%C3%B1a,_2014-01-10,_DD_11-12_HDR.JPG

When you click on the 'You need to attribute the author' button you get this

"Iglesia de San Pedro, Teruel, España, 2014-01-10, DD 11-12 HDR" by Diego Delso. Licensed under CC BY-SA 4.0 via Wikimedia Commons - https://commons.wikimedia.org/wiki/File:Iglesia_de_San_Pedro,_Teruel,_Espa%C3%B1a,_2014-01-10,_DD_11-12_HDR.JPG#/media/File:Iglesia_de_San_Pedro,_Teruel,_Espa%C3%B1a,_2014-01-10,_DD_11-12_HDR.JPG

To attribute an image you only need to include the author and the license, the wording implies that the title of the work and the giant url is a legal requirement for the license which it is not. The legally required license is:

Diego Delso. Licensed under CC BY-SA 4.0

I would suggest having such a large description would discourage people from reusing the image especially for offline media, the length of the attribution is simply to long to be practical.

Perhaps a better way to approach this is to have a few options for the text to generate where the legally required information is always present but the title and Wikimedia URL are optional.

John Cummings (talk) 10:40, 30 October 2015 (UTC)

@John Cummings: the credit line should link back to the original image, for both legal reasons (CC requires preserving the URL and in older versions even the title; a backlink to the description page is probably enough to do that) and practical ones (like access to the file in a larger resolution, or access to the image description). But apart from that, you are quite right about the length making it disfunctional. I opened T119686 about it. --Tgr (WMF) (talk) 00:42, 26 November 2015 (UTC)

@Tgr (WMF): Thanks very much, I've subscribed to the task. John Cummings (talk) 16:34, 2 December 2015 (UTC)

Voll behindert

Niemand will das. 71.199.199.144 02:05, 10 November 2015 (UTC)

"Uploaded by" may creating confusion to reusers

Tracked in Phabricator
Task T59308

I was surprised by the credit here. It is very bad. I think the misinformation is picked from the Media Viewer. In fact, it was not uploaded by me; but last revert was by me. Any way such negligible information is not relevant to copyright and need not be showcased. Jee 12:41, 25 November 2015 (UTC)

@Jkadavoor: that's T59308. Would it help if it was fixed, though? Crediting the uploader is a broken thing to do in any case (and this case it wouldn't even be the real uploader since it was done by a bot). MediaViewer does provide a credit line that's supposed to be legally correct; I would rather focus on improving that and/or figuring out why people are not using it. (For the record, this is the image.) --Tgr (WMF) (talk) 00:10, 26 November 2015 (UTC)

See also the discussion above ("Misleading..."). --Tgr (WMF) (talk) 00:42, 26 November 2015 (UTC)

Tgr (WMF), I'm confused by this. The image was uploaded in 2013, long before the Media Viewer was launched; it lists the author according to best practices, exactly the way the Upload Wizard would do it. The Media Viewer, which treats Commons data as though it were structured, should at least deal properly with normal, uncontroversial cases like this correctly, shouldn't it? Why is Russavia or Jkadavoor mentioned at all in this perfectly normal case, when the credit clearly belongs to the legal entity listed under "Author"? -Pete F (talk) 03:06, 26 November 2015 (UTC)

Russavia is mentioned because his name is included in the source field of the information template, and MediaViewer uses <author> - <source> as the byline. Jkadavoor is named as the uploader (which is technically correct since he is the owner of the current revision of the file, but not really useful - see linked bug). --Tgr (WMF) (talk) 06:22, 26 November 2015 (UTC)

Sure, of course there is a technical reason why it shows up, but that's not my question. What is the purpose? I see we're in agreement on this point, but this is something that should have been resolved long before the software was released...not long after. -Pete F (talk) 18:41, 26 November 2015 (UTC)

Pete, let's follow up on that in the linked bug, but I'll reiterate that it is a distraction from the main issue, which is that some reusers don't use the attribution dialog provided by MediaViewer. If someone tries to craft an attribution by themselves, they are almost certain to mess up (e.g. the example linked by Jee was also missing the license); such is the case with using the file page as well (see e.g. the recent commons-l thread about a contributor suing reusers for some examples). What can we do to make the generated attribution more prominent and more useful (apart from T119686) is the relevant question here IMO. --Tgr (WMF) (talk) 01:47, 29 November 2015 (UTC)

"I would rather focus on improving that and/or figuring out why people are not using it." – Really? Are you kidding? This exact issue was raised by the community time and time again even before the launch of MediaViewer. It was also elegantly ignored time and time again by the MediaViewer develeopment team. And now – a year after the launch – you want to "figure out why people are not using it"? Why are even trying to give feedback? --Patrick87 (talk) 15:37, 26 November 2015 (UTC)

Simple solution: Only use MV in those cases, where it's able to show the proper licensing, in other cases simpla use the normal file page. And perhaps leave a marker on that file page, so that it can be maintained to be usable in the future (a task for those, who pushed the MV, not the community). --Grüße vom Sänger ♫^(Reden) 08:41, 29 November 2015 (UTC)

It was one of the main reasons of the rejection of the media viewer by the deWP that it didn't care about proper licensing if the files were not licensed in the very restrict way the MV was able to comprehend. Only weeks after the disaster with superputsch they started to do something about it by starting some template fixing in commons files, way too late, and way too ignorant, like this whole enterprise was managed. It was known from the beginning, that file pages that were completely fine licensed for any human eye were unfathomable for this piece of software. But they didn't care before forced deployment, they only cared superficial after the superputsch disaster, and it seems they don't care even now after one year of forced deployment.
A proper solution was mentioned by several people several times as well: Simply use this software only in cases of 100% clear and proper license readability and use the normal file pages in all other cases. Make those who desperately want this software as default responsible for changing the file pages in a way that it's pet software is capable of reading. Anyway, it's just some superficial viewer, nothing really important that has to be kept. --Grüße vom Sänger ♫^(Reden) 05:24, 27 November 2015 (UTC)

Sorry for the late response, Tgr (WMF). I just read T59308, you provided. I fully agree with Pete F there; there is no need to mention first, last or any intermediate uploader in Media Viewer. Earlier some bots mentioned uploader name in source or author field in Commons; now we're removing it. Out priority should be to provide only important (especially copyright-wise) information to the viewer/re-user. That should come from TASL - Title, Author, Source, License; not from any other field. MediaWiki software not supporting a "title" option; so we're using description instead of it. Date also can be mentioned as it helps to know whether copyright is expired. So the current layout is good except the inclusion of "Uploaded by". People may not well differentiate the difference between "Uploaded by" and "Created/Copyright by". So better avoid that unimportant (copyright-wise) field. (I remember, I had pointed about this in a discussion about making PDF of Wikipedia pages. There also the PDF had wrongly credited to last editor of some files. I don't know whether it is fixed now.) Jee 14:21, 1 December 2015 (UTC)

I agree with Jee. Uploader information is not priority and often misleading. If someone wants to find out who uploaded/tweaked/categorised/described an image then they can click through to the Commons file description page and look at the page or version history. Uploading is no more credit-worthy than categorisation or inserting the image on a WP page. If the author information is missing then that's Commons problem to sort out and fix, we should not have web pages deciding to use some random history field like who uploaded. Getting attribution right is a vital aspect of out mission, and not a nice-to-have. If we can all agree what fields/templates are used to tag the TASL information then it can be a job for the Community to fix badly described files. -- Colin (talk) 10:05, 4 December 2015 (UTC)

The maps are outdated, Crimea is now Russia!

The two maps on your sites about future enlargement of EU are not valid, because Crimea is NOT Ukraine since 2014. The people of Crime voted on a referendum to become part of Russia. So, Crimea is Russia now and Crimea will never be Ukraine. Please correct your maps.

Crimea si part of the Ukraine, that was unlawful annected by force by Russia. Russia doesn't believe this, and has quite expansive prpaganda running, but a fact' a fact. --Grüße vom Sänger ♫^(Reden) 15:13, 17 December 2015 (UTC)

It's true Crimea was unlawfully annexed, but on the other hand almost every piece of land on the map was unlawfully annexed at some point and nearly every border on the map was drawn by unlawful annexation. Furthermore, an encyclopaedia should document, and although Crimea should be part the Ukraine, it is part of Russia and should be drawn as such. Doing otherwise would violate NPOV.

Disabling Media Viewer

It would be nice to have a way of disabling Media Viewer that did not involve either registering an account or locally storing cookies. Could this be implemented in a future build? -98.111.199.230 01:45, 21 December 2015 (UTC)

How do you think? As far as I know, there is no other way to store this data. --Tacsipacsi (talk) 14:04, 21 December 2015 (UTC)

Surely a cookie would do the trick?

It does, but above the anon asked without cookies. --Tacsipacsi (talk) 18:36, 21 December 2015 (UTC)

You can write JS to disable it and install that JS as a browser extension in your browser. That might sound crazy, and that's why cookies and accounts are so ubiquitous :) —TheDJ (Not WMF) (talk • contribs) 18:47, 21 December 2015

Maybe by storing the preference info on Wikipedia's end, rather than mine? Or making it opt-in, instead of opt-out? Not sure - I'm not really a technical person. I would just rather not store cookies, as I have them disabled by default. -98.111.199.230 15:11, 29 December 2015 (UTC)

MediaWiki can’t identify you (unless you log in). Your IP number can vary often (e.g. every time you turn your computer off), so it can’t be used for storing data. Making opt-in can work, but WMF doesn’t support this (and as I see, won’t support in the next years). Personally I don’t have problem with this solution, but as I like this feature, I won’t like if the whole project will be abandoned. --Tacsipacsi (talk) 16:40, 29 December 2015 (UTC)

Errors in Order of Admission Map

Two errors I quickly see: When Virginia was admitted, it included not only West Virginia but also Kentucky, and should be shown that way until Kentucky was admitted separately. When New York was admitted, it included Vermont as well, and should be shown that way until Vermont was admitted separately. Jaknouse (talk) 04:16, 31 May 2016 (UTC)