Extension talk:Media Viewer/About

Share your feedback

Report bugs

Media Viewer has now been updated with these new improvements, based on community feedback:

• an easier way to enlarge images
• a prominent 'More Details' button linking to the File: page
• separate buttons for Download and Share features
• an easier way to disable the tool for personal use

Please try out these new features, and let us know what you think. Learn more about these improvements.

Media Viewer is now live on all wikis

Hi folks, we're happy to announce that Media Viewer is now live on all wikis hosted by the Wikimedia Foundation!

Media Viewer is testing well on all remaining Wikipedias (e.g.: Chinese, Arabic, Hindu, Indonesian, etc.) and sister sites (e.g.: MetaWiki, Wikibooks, Wikiquotes, Wikiversity, Wiktionary). And the multimedia team worked hard in the last few weeks to develop a range of new improvements, in response to frequent community requests on this page and elsewhere. We hope you will try them out and let us know what you think.

New feature: Click on 'View original file' to zoom on images in your browser.

1. Features on All Wikis
These features are now available on all wikis as of today:

• View original file (#630)
• Scroll down to see more info (#697)
• Show Commons link to logged out users (#429)
• Easy opt-out for registered users (#703)
• Opt-out for anons (#704)
• Add more tooltips to Media Viewer (#546)

You can test these features on this Featured Pictures page on the English Wikipedia.

New feature: 'down arrow' points to more information below images

2. Features on MediaWiki.org only
These features are now available on MediaWiki.org and will be deployed to all wikis by next Thursday:

• Make it easier to find image information (#706)
• Prominent links to different image sizes (#664)
• Disable MediaViewer for certain images (#511)
• Track 'View original file’ and ‘Commons link' clicks (#715, #726)
• Track Media Viewer Opt-outs (/#558, #675)

You can test these features on this demo page on MediaWiki.org, as well as on this metrics dashboard — and learn more on this updated help page.

3. Features in development
Other tasks in development or analysis include:

• Show attribution credits in download tool (#598)
• Make 'Commons link' and 'Use this file' more discoverable (#732)
• Click on image in Media Viewer to help view original file (#712)
• Improve Media Viewer UI on tablets (zoom/scroll) (#716)
• Remember the last selection for ‘Use this file' (#660)

You can view more details about these features on this planning site.

4. Feedback
Overall, we keep getting generally positive feedback worldwide, with these latest results:

• A majority of global respondents find the tool useful (~60% average across surveys)
• Cumulative approval by language: English 29%, French 70%, Spanish 78%, Dutch 59%, Portuguese 81%, German 28%, Hungarian 62%, Catalan 71% as of yesterday
• Daily approval rates have increased on English Wikipedia from about 23% a day after launch to 39% two weeks after launch (and German approval has also increased from 23% to 56% in the same period).
• We anticipate further approval increases on these sites, as more new features get rolled out in coming days, based on community feedback.

We are also starting to track opt-out rates to see how many people turn off Media Viewer in their preferences. As of June 16, about 875 users had disabled this feature on the English Wikipedia, two weeks after launch: this represents about 0.34% of all registered users who touched the site since launch. We are sorry that this small minority of users doesn’t like the tool, but we are glad that so many other users are finding it useful. :)

• For example, I leave it active, because I'm waiting for the day that it no longer appears by default. This statistic says nothing. Hockei (talk) 12:22, 22 June 2014 (UTC)
• Most users aren't critical thinkers who can distinguish good from bad. The ability to turn this off is hidden, so the fact that most people haven't turned it off merely proves they don't know how. Also, that's not a good measure anyway, the proper analysis would look at who uses the wiki most, not the general occasionally browsing public. Torch this awful media ruiner.
• I also keep it on, just to see when this Beast will die. Concerning the survey, of course a simple statistical analysis shows that negative feedback is overwhelming and is even greater on langueages where the feedback button was left longer. As said just above, "Torch this awful media ruiner". --Michel le tigre (talk) 14:56, 9 July 2014 (UTC)
• The opt-out stat is being misused. I haven't bothered to change prefs because I assume problems will be worked out, but they need fixed. These features need incremental roll out, to 1-5-20-50%. Readers need a baseline for comparison, may not have. Tonicmatic (talk) 04:57, 10 July 2014 (UTC)

Please let us know what you think of these new features. Which do you like most? least? Are there other must-have features that need to be developed right away, before we move on to other projects?

Thanks to all the community and team members for all you’ve done to make Media Viewer possible. :) Onward! Fabrice Florin (WMF) (talk) 18:14, 20 June 2014 (UTC)

Comments

• On Feedback: 1. What kind of statistics are those, where you consider all wikis to have the same weight? I want to assume good faith but that approach is either manipulative or incredibly incompetent; 2. I never received any kind of survey in the three wikis where I work: Commons, en Wikipedia and pt Wikipedia. Neither was that survey announced. Caesar's wife must be above suspiction. -- Alvesgaspar (talk) 19:58, 20 June 2014 (UTC)
• On your comment that we are glad that so many other users are finding it useful. :). What kind of decision process in this that changes the default viewing system of all wikis just because 60% of them considered it to be useful for viewing images and learning about them? I want to assume good faith but this approach is either manipulative or incredibly incompetent. Caesar's wife must be above suspiction. Alvesgaspar (talk) 20:43, 20 June 2014 (UTC)
  • I calculated the correct percentage of users (based on the published numbers) who considered the tool useful: it is 55.7%, not 60%. Not very promising, is it? -- Alvesgaspar (talk) 21:45, 20 June 2014 (UTC)
• On your comment that this represents about 0.34% of all registered users who touched the site since launch. We are sorry that this small minority of users doesn’t like the tool. You forgot, of course, to say what is the percentage of all registered users still active. Or to make the distinction between the casual users and the frequent ones. Sorry, but this time it is difficult to me to assume good faith. Alvesgaspar (talk) 21:41, 20 June 2014 (UTC)

• As a frequent Wikipedia user who dowloads many images, I hate the new viewer so much that I ALWAYS either Ctrl-click or middle-click on images so I can view them properly (i.e. on the Wikimedia Commons page). It is annoying to have to open a new tab, but not as annoying as having my screen obscured by a javascript-driven monstrosity. What I want to know is, are users who access the Wikimedia Commons pages like me being counted among those who are not using the new media viewer? I suspect not! Also, regardless of the "approval" figures for the new viewer, what were the disapproval ratings for the old viewing system? I am not aware that there was any widespread dissatisfaction which warranted the introduction of the picture viewer. The Wikimedia commons pages were befitting an encyclopedia, whereas the new picture viewer is reminiscent of a dumbed-down social media site. Very sad. D, 21st June 2014

That's interesting with pressing ctrl in an article! I didn't know, you could directly open the file in Wikimedia Commons this way. Good to know, but that shouldn't be the only way to do so, since many more people apart from me don't know this probably. I partly like Media Viewer (the slide show option), but it's not always what I want to do, so I would like to chose from case to case (see my comments in the section above). And Media Viewer should not hide important information of how to use a file, especially for uninformed readers! That's realy bad right now and I don't understand, why Media Viewer is nevertheless already standard for all readers. I want to remark, that just because I didn't deactivate the application, this doesn't mean I agree with everything the tool involves. What does this mean, people, who opened Media Viewer and didn't deactivate the tool afterwards, find it useful? If you want to imply with this, that they prefer it to the Commons page, this would be putting words into their mouths. Maybe they don't care about it, see it's new and that's all. Even if some think it's better, because the image is presented centered and looks nice and that's most important for them, they might just not mind or see the lacks of Media Viewer, because they focus on how the image looks and is described in a certain article and are not that interested in which and how image information is presented outside of it. That doesn't mean, there are no lacks. -Miss-Sophie (talk) 20:08, 21 June 2014 (UTC)

• Thank you all for your comments about Media Viewer. I have responded below to some of the key concerns you raised above. Fabrice Florin (WMF) (talk) 00:53, 25 June 2014 (UTC)

• Alvesgaspar, in response to your first point above, keep in mind that the primary intent of this short-term Media Viewer survey was to get qualitative feedback from all users, not to provide a long-term quantitative metric of acceptance for this tool. So while the feedback we collected was invaluable and helped us improve a number of issues, we should all interpret the quantitative results with caution. To answer your second question, the survey is now available to all Media Viewer users on enwiki, commons and pt sites: simply open Media Viewer and click on the bullhorn icon to post your feedback in a pop-up window. To answer your third question, over dozens of separate announcements were made in the past two months on all our sites; in the English Wikipedia alone, we invited feedback on the Village Pump and other community hubs (announcement 1, 2, 3, 4, 5, 6, 7, 8, 9 and 10). In response to your fifth point, you are correct that the average across all users is 55.7% (that number had not been verified when I filed this update, which is why I used the number across surveys instead). Note that this average hovered between 60% and 70% approval for months, until the recent launch on the English and German Wikipedias, where post-launch negative feedback brought it back down for a few weeks. However, we observed that the rate of users who find the tool useful is usually lower for the first few weeks after launch, and typically increases after users become familiar with the tool and its new features: for example, Hungarian approvals started at 42% and grew to over 60% in about a month. Similarly, daily approvals from English users started at 23% right after launch and have grown to 48% two weeks later, as shown in this survey dashboard (2nd graph). That said, this survey was never intended to be a long-term metric for this project -- and we plan to end it next month, now that we have enough feedback for development purposes. Going forward, we will focus on image views and disable rates as our main metrics, because they provide a more accurate indication of the tool's actual usage. In response to your sixth point about the 0.34% disable rate, I would like to clarify that it is based on the cumulative number of registered users who disabled Media Viewer in their preferences (875), divided by the total users who made an edit or changed their preferences since Media Viewer was launched on the English Wikipedia (260,450); it is not based on total registered users, which would yield a much lower percentage. We think that metric gives us a better representation of the community's overall acceptance of this feature, particularly now that we've made it much easier for both registered and unregistered users to disable the tool with a single click, right inside Media Viewer. Lastly, your insinuation that we are not working in good faith doesn't seem fair or accurate: over the past year, we have fully disclosed all of our findings, in good faith and gone out of our way to be as transparent as we could. We have also engaged community members extensively at each step of the way, starting with over ten separate discussions since June 2013. The tool was then widely tested by over 25,000 beta users on all our sites since November 2013, as part of our Beta Features program. And in the past two months, we have collected over 15,000 survey responses from a wide range of user groups, as well as on talk pages like this one, and responded to their requests with many new improvements. All this provides ample evidence to support our position that we have consistently acted in good faith and actively engaged community members throughout this project. Fabrice Florin (WMF) (talk) 00:53, 25 June 2014 (UTC)

• Miss-Sophie: I am glad that you found out how to bypass Media Viewer, as further described in this Help FAQ page. Your point is well taken that there are a number of users who have chosen not to disable Media Viewers but still think it has issues. We are working in good faith with these users to improve the tool, as you can tell from the long list of features we just enabled based on their feedback. But we believe that most users who strongly object to the tool will eventually disable it, which should provide us with an objective metric for tracking this disapproval. We welcome other practical ideas for tracking community acceptance consistently across all user groups. But this approach seems reasonable and feasible right away, without requiring more development resources than we currently have. We hope that over time, this and other metrics will help us all make more informed decisions together about next steps for this project. Thanks for your other thoughtful observations on this page, which are much appreciated. Fabrice Florin (WMF) (talk) 00:53, 25 June 2014 (UTC)

• I have logged in to Wikipedia since the launch, but didn't realize that it was live on my account until recently, and then I went into my preferences to try and turn it off and couldn't figure out how. I finally had to click on a random image and click to disable it. I hate this "feature", and I don't think it's any measure of its reception that such a small percentage of people went through the effort to turn it off (chances are most people assumed it was a permanent change that was being foisted on them anyway). It should be off by default. It's going to be annoying to have to log in or turn it off every single time I clear my cookies, or any time I use wikipedia on a new browser. This adds nothing to the old way of doing things, as is abundantly clear from the huge volume of negative comments on this page. 0x0077BE [^talk/_contrib] 01:36, 27 June 2014 (UTC)

• Two style suggestions: (1) Don't utilize icons that can be 'symmetrically interpreted', in this case the arrows. Some think a down-arrow means 'there is more below'; others think it means 'push this thing down'. In this case, I would suggest words: 'more' and 'less'. (2) Don't obscure significant amounts of screen space with a partially hidden object. In this case, roughly 5% (vertically) of the screen, at the bottom, is covered by the mostly-hidden additional info (which the above arrows reveal / hide.) This is one of the things that I think killed the new Google Maps. That said, this seems to me (not a style expert) a harder problem... perhaps a floating, semi-transparent 'switch' somewhere near a corner of the screen (upper right would be my preference, but preferences vary)? My first impression of the new feature was not especially positive, primarily because of the above two issues. DrTLesterThomas (talk) 13:18, 9 July 2014 (UTC)

Words can't be used, as this thing was to be imposed on all languages of WP. Better just kill it.--Michel le tigre (talk) 14:26, 9 July 2014 (UTC)

SurveyMonkey Feedback

Why does Fabrice, who as far as I can tell is one of the main perpetrators of this attack on Wikipedia users, keep waving some randomly chosen figures from a "survey" which clearly has never been anywhere near a statistician. A few things:

• WTF is being meant by the thing "being useful"? Do you realise that usefulness (unless very strictly defined in a particular context) is not a measurable quantity and therefore no good as a metric?

• Why are you asking two questions at once, to which only a single answer can be provided?

• I tried opening the so-called "survey" page multiple times, and as far as I can see, the order of the response choices is not randomised: "Yes" always comes first. I hope you are not aware of first choice bias, otherwise you are being deliberately manipulative.

• Where is the "Elephant in the Room" question? Namely: whether the user would rather use this contraption or the traditional, and mostly well-designed system.

• Why is all the qualitative feedback here being utterly ignored, unless it can be manipulated to further prolong the existence of this crap?

Fabrice, I am well aware of the saying that tells us not to ascribe to malice what can be explained as stupidity. However, I do note they're not mutually exclusive. Making mistakes, sometimes pretty big ones, is part and parcel of any job. Plowing forward after mistakes have been pointed out, especially by attempting to ignore criticism, is irresponsible and a sign of cowardice and immaturity--hardly desirable characteristics in a competent project manager. Take this criticism from a another project manager, having made pretty big and stupid mistakes myself I know what it's like, but as one of my mentors said, one must always come forward, acknowledge one's failures and learn from them. Everyone comes off better in the long run.

And to sign off, let me give you a free pro-tip: when you've got a big and complex product that is used by millions of users, radical and disruptive changes are not welcome. Always proceed in small incremental steps, and be prepared to back off at the first sign of trouble.

Well said! This "Media Viewer" is a disaster, and its implementation and fanatical defense in the face of broad, detailed, sustained criticism is a poor reflection upon the person responsible for leading the debacle. Jdanek007 (talk) 00:12, 3 July 2014 (UTC)

Exactly, and according to the dubious survey only 36.07% of people actually found it useful. I despise this media viewer, and find it hilarious the way it has been forced on everyone, and with this bizarre proclamation that black is white and it's actually wonderful and loved by all. It is utterly utterly dreadful and should be destroyed. --Gjackson123 (talk) 17:09, 7 July 2014 (UTC)

Bug: "Close this tool. Or press Esc to exit" pop up doesn't go away

Tracked in Phabricator
Task T68895

The "Close this tool. Or press Esc to exit" pop up, that appears when moving the mouse on the X in the right upper corner of Media Viwer, doesn't go away under the following conditions: I opened an image from a Wikipedia article with Media Viewer and went with the mouse to the X until the description popped up, then I clicked the X to exit. When I then click on another or the same image from the article, Media Viewer oppens with still showing this pop up, that stays while sliding through the images and only vanishes, when I once again move the mouse onto the X.

Also, comming from a German Wikipedia article, this pop up text is in English instad of a German translation like the rest of the user interface. --Miss-Sophie (talk) 21:17, 20 June 2014 (UTC)

The latter is probably a lack of translation. At the moment everything is translated, so you will see the correct text as soon as the software is updated (within a day, usually). --Tgr (WMF) (talk) 22:10, 20 June 2014 (UTC)

Addition: The pop up not just stays within Media Viewer, it even stays visible in the Wikipedia article after closing Media Viewer! It covers the search field in the right upper corner of the page, when doing what I described. --Miss-Sophie (talk) 00:18, 21 June 2014 (UTC)

Keep Optional

I hope we have the option to keep it disabled. I don't like it because I don't like change or new stuff... Smarkflea (talk) 21:58, 20 June 2014 (UTC)

The option to disable Media Viewer is not going away, no worries :) Keegan (WMF) (talk) 18:11, 21 June 2014 (UTC)

Make it stop

Please. Your tool is unwanted by the vast majority. Its slow, cumbersome, annoying, unintuitive, painful.

Please disable this tool until you have an RfC on each deployed to wiki. DaveJohnson (talk) 03:38, 21 June 2014 (UTC)

Distorted picture + "View original file" not working + content disappearing

Tracked in Phabricator
Task T68998

Win 7 / IE 11

Shut down and reopen browser. Go to http://en.wikipedia.org/wiki/Main_Page. Click on today's featured picture, which is http://commons.wikimedia.org/wiki/File:A_couple_of_Tadorna_ferruginea.jpg. The picture in Media Viewer is stretched horizontally to about twice its correct width, and the "View original file" link does not work either.

Now click left arrow, then right arrow, and all the content (text + buttons) in the lower pane has disappeared.

Retrurning to the picture after viewing other pages, the picture sometimes displays correctly, sometimes not. I do not know the exact circumstances which determine this. However, when I follow the above sequence, it always breaks. 86.179.0.254 02:13, 22 June 2014 (UTC)

I was able to reproduce at least the image being stretched in IE 11 on Windows 7. I cannot reproduce the right/left shifting issues with the specified image since it's no longer in the context of the Main Page and I didn't encounter similar issues with today's Main Page Featured Picture. Thanks for the information so it can get fixed :) Keegan (WMF) (talk) 21:21, 23 June 2014 (UTC)

This seems to be the combination of bug 66244 (for which the fix will be deployed on Thursday) and some different, IE11-specific issue. Couldn't reproduce any issues with "view original file" though.

For next/prev issues, can you share the URL your browser shows when you are viewing ther image? (Preferably with something that's not on the main page, since those links don't work for long.) --Tgr (WMF) (talk) 21:36, 23 June 2014 (UTC)

Very low approval rating

According to their own survey, media viewer has received a very low approval rating on English Wikipedia, where the greater majority of editors and viewers abide, with only a 29% approval rating, which means of course that 71% disapprove. Even with the new features, (an attempt to make media viewer do some of the things that we were able to do in the first place) approval has only increased to 39% recently, which means that 61% disapprove. Then we are told that 875 registered users have disabled it (in only 2+ weeks!) since media viewer was forced on everyone, with the claim that this represents 0.34% of all registered users. Is this globally, or for English Wikipedia?? Since many registered users haven't logged on in weeks, months and even years, this 'statistic' is very deceptive and misleading. Esp since the disable feature was not available at first and continues to be obscure, tucked away at the bottom of the popup screen where it will get unnoticed by the majority of viewers who peek at images in full view occasionally.
Media viewer should only be a default viewer where there is overwhelming approval for it, and it's perfectly clear, there is overwhelming disapproval for it on English Wikipedia. Their own statistics back this up. People who use Wikipedia as an encyclopedia don't need a default slideshow. It should be an option when one clicks on an image -- not the other way around. Why they came up with this viewer in the first place still remains a mystery. To be fair to the debate, they need to take a separate survey of experienced editors and see how it fares. Meanwhile registered and unregistered users continue to leave overwhelmingly negative feed back at the English Wikipedia RfC and here on the media viewer talk page. We can only hope that the individuals who are promoting media viewer share the same spirit of Wikipeida and abide by the same ethics as do most of their fellow editors, and will respect consensus and the decision of the RfC which is presently examining this issue. -- Gwillhickers (talk) 18:01, 22 June 2014 (UTC)

Redundant

My browser has an image viewer, and I don't like this javascript one. 76.185.182.224 20:08, 22 June 2014 (UTC)
This. A thousand times this. You are engaging in one of the classic blunders by this shitty re-implementation of already-existing functionality. Make it opt-in until you have something that is worth using.

Totally what the fellow above says.

Aspect ratio screwed up, confusion about "More details" link to Wikipedia's or Common's file info page

When I click on one of the pics on today's main page (Felipe), Media Viewer displays it with the aspect ratio all wrong; the face about twice as wide as it should be. I'm using IE11 on Win 7.

I'm also noticing that the "More details" button in the lower right for this image goes to the Wikipedia info page, while for another image on today's main page (Olympia), the "More details" link goes to Commons. Which one is it supposed to be?

Further, I still see that Media Viewer interacts unexpectedly with the browser's most important feature: the back navigation button.

These bugs aside, the best solution would be to dump the new annoying Media Viewer altogether. It's not half as well implemented as the similar javascript toys it apes from social media sites etc, and even if it were, it doesn't belong on an encyclopedia.

Hi there.

More details: Why does one say Wikipedia and one say Commons? This isn't a Media Viewer issue, this is an issue of how and where files are stored on Wikimedia projects, and why. The File: pages do not make this much more clear, either. Sometimes there's a box that says that a File is hosted on Commons and everything you see on the English Wikipedia is automagically appearing; other times files are locally hosted and need to be copied to Commons, sometimes local files can't be copied for technical reasons (For example, the Felipe image is temporarily hosted on the English Wikipedia so that it can be protected from vandalism locally while on the main page).

As for the back button, there's a pretty intense debate over this very issue on bugzilla. FWIW, I agree about the back button not behaving as I expect it to, but Gilles makes excellent points about why the browser history behaves as it does and what I expect isn't necessarily the best use case. It's good reading.

I'm sorry that you didn't enjoy Media Viewer and I hope you found the way to disable it for now. Media Viewer will be developed further in the future, I hope you take some time then to see if you like it any better. Thanks for your time. Keegan (WMF) (talk) 19:11, 23 June 2014 (UTC)

Media Viewer can't include certain image descriptions from Commons page

I notice, that for the above linked Olympia painting Media Viewer isn't able to include the description of the painting from Commons, which involves information about the painting technique, the size of this artwork and the museum. Media Viewer doesn't show any description. --Miss-Sophie (talk) 10:16, 23 June 2014 (UTC)

Looks like Media Viewer is having trouble scraping that {{Artwork }} template. Thanks, will look into this. Keegan (WMF) (talk) 19:16, 23 June 2014 (UTC)

Not sure what should be done differently here. We scrape the author, source and date correctly. (Well, for some value of correct - see bug 56794.) There is no description field in the template, nor anything else that should be shown in the metadata panel, as far as I can see. --Tgr (WMF) (talk) 23:07, 26 June 2014 (UTC)

Yay! Shift-click to avoid this rubbish

I was pleased to learn that shift-click opens the proper way mage page. Media Mangler simply does not work in my office environment (probably due to the security settings that I cannot change).

Now, if only there was a way to get rid of this from my mobile device...

I haven't tried it myself, but I suspect that if you do a long click (or press or whatever it's called) then choose the option to open in a new tab (if your mobile browser has this feature, like Firefox), then you might be safe from this sorry piece of unwanted shit that nobody asked for in the first place. Hope this helps.

+1 to the comment regarding 0.34% of user IDs complaining, and how this is a figure completely skewed and manipulated to serve an agenda. I rarely log in to Wikipedia, but use it quite a lot. Remember, any online survey is likely to prove that 100% of the world has internet access... all you're actually proving is that everyone who has internet access has internet access, ignoring the billions who do not.

Scrap Media Mangler now!

Sorry that you didn't care for the Media Viewer experience, do note that even as an IP you can disable Media Viewer by pulling up the fold of information and clicking "Disable Media Viewer." That should work for your mobile device as well. Hope that helps.

0.34% of active users on the English Wikipedia have disabled Media Viewer. This is true. The English Wikipedia has, as of this writing, 126,977 accounts that made at least one edit in the past month. Of those, ~30,000 accounts made at least five edits in the past month- the "active editors." 875 into 30,000 gives a result of 0.34%. Some may not like these numbers, but they are true.

Keegan (WMF) (talk) 18:55, 23 June 2014 (UTC)

• Not so: 875 divided by 30,000 is 2.9%, not 0.34% ! Some may not like Math but is useful at times... -- Alvesgaspar (talk) 21:06, 23 June 2014 (UTC)

• :) You are correct; it seems like the conflict comes from where Fabrice said "all registered users who have touched the site" versus what I'm using as a metric, that is "active users." I confused myself here, sorry about that. To say: 2.9% of active editors have disabled Media Viewer. Keegan (WMF) (talk) 21:32, 23 June 2014 (UTC)

• 1.5% of the active editors, actually. Only about half of those who have disabled were active. --Tgr (WMF) (talk) 00:30, 24 June 2014 (UTC)

You know that it is a very, very big lie. It is only statistics. But... most of users don't know possibility to disable that crap and most users don't work with images. Ahsoous (talk) 20:03, 23 June 2014 (UTC)

The biggest problem with these statistics is of course awareness of how to disable Media Viewer and the very reasonable bias towards not changing settings in general. All designers know that the choice of defaults is incredibly important for user experience. What you need to do is to return to the original file information page by default, offer Media Viewer as an opt-in on the user settings page and see how many chose it. I doubt it would be many even if there was an awareness campaign a la the fundraising banners.

A very big lie. You might as well say, "Only 875 people out of the 7 billion on the planet have disabled the Media Viewer." How stupid do you think we are? DaveJohnson (talk) 03:02, 24 June 2014 (UTC)

Yeah I thought that. Visitors have to disable the thing right now to get key information, like placenames, from larger svg maps for example. And they dont do it? Alexpl (talk) 09:49, 25 June 2014 (UTC)

"... even as an IP you can disable Media Viewer by pulling up the fold of information and clicking "Disable Media Viewer."" Thank you for pointing me to how to disable the media viewer, might I suggest this disable link is placed far more prominently right at the top? Just beforehand I had left a feedback requesting a clear way to disable it, together with my disappointment in the sad trend of ignoring the community by some elements of the foundation. Anyway, the first few times I clicked on an image, expecting to see the usual file description page, I thought I had some gadget or beta feature enabled in my preferences and simply could not find a way to disable it. Please do not require users to hunt for basic stuff such as this. To my mind any globally made changes such as this requires a very clear "return to old behaviour" button. I also was not aware of any survey or questionnaire asking wikipedians about this (I hardly edit now, but still read the articles). -84user (talk) 06:47, 1 July 2014 (UTC)

Bug: While flipping through images in the slide show Media Viewer confuses the author information for certain images (the ones on Wikipedias?)

Tracked in Phabricator
Task T69014

I skipped through the images from the German Rolling Stones article and noticed, that Media Viewer doesn't show the correct author information for this one particular file of the band logo, when clicking the forward or return button. The application takes the author information from the previous or the following file, depending on which button you used. It's the only file of the lot with a Wikipedia location, so maybe it has something to do with this? --Miss-Sophie (talk) 10:25, 23 June 2014 (UTC)

Addition: This seems only to happen under certain conditions. If I start using Media Viewer with the logo file, the problem only occurs when clicking return for at least two images (and then going forward again to the logo file) or forward for at least four images (and then going back again to the logo file). It doesn't happen, when you click back or forward just once to the directly previous or next file. Once it's wrong though, it stays wrong, which means, that when I close Media Viewer and then click again on the logo image, it's still the wrong author information from before. When I start with another image from the refreshed article it is accordingly: The problem starts with an image two steps before the logo (the band montage) and with an image four steps after (the one from Chicago 1975). --Miss-Sophie (talk) 10:40, 23 June 2014 (UTC)

Oh how bizarre this is. I think the problem might lie in the English Wikipedia File page where the logo image is hosted, @Tgr (WMF): Thoughts, when you get time? Keegan (WMF) (talk) 19:02, 23 June 2014 (UTC)

It is a bug with emptying the panel. (The conditions to reproduce are very weird, no idea how that came about.) Thanks for catching! --Tgr (WMF) (talk) 01:44, 24 June 2014 (UTC)

Bug? MV confuses file name with article name

Tracked in Phabricator
Task T69008

I've noticed that, when you open an image on a wikipedia page, the name displayed is the WP page name, instead of the file name. For example: open https://en.wikipedia.org/wiki/Realgar and click on any image. The page name also shows up in the browser history page, which makes it harder to get back to the image later, as both image and article are labelled "Realgar".

My setup: Firefox 30.0/Mac OS-X

No biggie, but an annoyance. --Tillman (talk) 19:19, 23 June 2014 (UTC)

@Tillman: good idea, thanks! --Tgr (WMF) (talk) 22:45, 23 June 2014 (UTC)

I Call FOUL!

To repeat (ad nauseam), I don't hate this tool. I think the dev team did a great job. I object to the implementation, and especially to the misleading info in #Media Viewer is now live on all wikis and similar posts. I make no assumption that anyone is trying to mislead or deliberately cherry-picking data, but the end result is factually misleading.

"Cumulative approval by language: English 29%, French 70%, Spanish 78%, Dutch 59%, Portuguese 81%, German 28%, Hungarian 62%, Catalan 71% as of yesterday." That sounds great until you do the math. I will always AGF, but Disraeli and Twain must be having quite the chuckle over this.

Active users of Wikipedia within the EN (English) or DE (German) projects outnumber all other Wikipedians combined. Within the eight languages surveyed, EN and DE combined represent 76% of the active user base for Wikipedia and 80% of users across all MediaWiki projects. MediaViewer is an image tool and (of projects in those eight languages) EN and DE account for 89% of the Wikipedia images (88% across MediaWIki).

If we take the actual, raw numbers provided, we have to accept one of the following conclusions:

• 39.13% of active Wikipedia users approve of the tool
• 37.84% of MediaWiki users approve of the tool
• 33.29% of users on Wikipedia sites weighted by number of images approve of the tool
• 33.67% of users on MediaWiki projects weighted by number of images approve of the tool
• 73.02% of users approve of this tool because the two languages with largest active Wikipedia user-communities, English and German, just don't matter that much and they'll come to their senses soon enough.

Insert : Where are you getting "73.02%" if an average of only 35% approve?

Insert: I think this was included to illustrate the absurdity of the "logic" that could lead to the conclusion that a majority of users approve of the tool -- i.e., that you would have to ignore English and German projects in order to arrive at a number like this. I could be wrong, but that's how I read it. -Pete F (talk) 18:18, 25 June 2014 (UTC)

Again, I don't hate the tool and I don't hate the team and I don't ascribe conspiratorial or malicious motives onto Media Viewer's supporters. I just want Keegan's request from 24 May honoured: "Personally, I'd like to make sure that the discussion is not based on 'I don't like it and I don't think anyone else does either' but actually had solid numbers and facts on how communities feel about Media Viewer…" Can we please give each other at least that much respect? 159.53.174.145 19:54, 23 June 2014 (UTC) (Kevin)

Hi Kevin,

our rollout strategy was to deploy Media Viewer (after an extensive beta period) to some small wikis, then increasingly larger ones, using the survey results as predictors for the next batch. Obviously that didn't work well for EN/DE, but that only became obvious after we rolled out on those sites; so I am not sure what you find surprising or shady in the choice of surveys.

The huge difference in results per site certainly questions the usefulness of these surveys - given that there is no reason why the viewer would be more useful or less annoying for French readers than for English ones, there should be some external factors causing that difference; and a survey with external factors causing a +-50% bias is not very valuable. That would have been nice to know beforehand, but we didn't; the results before en/de seemed fairly consistent. We should have done small-scale tests on enwiki instead of assuming that the results from other sites can be interpolated, but, well, hindsight is 20/20... --Tgr (WMF) (talk) 07:20, 25 June 2014 (UTC)

@Tgr: A fair and reasonable answer, and I truly appreciate it. I also appreciate the predicament of any product team whose only chance to spot a landmine comes after detonation. It's neither nice nor fun, and I've been down that road more often that I'd like to admit. It chafes that some other members of the team are still trying to hide behind the fig-leaves of dubious statistics and dodgy self-justification, but that's not the point. My concern for future projects outweighs my ire over this one -- We MUST learn from this. We have to rebuild our consensus process to give more weight to naysayers and less to proponents of change. We also have to admit that our decision-making has an intrinsic bias toward "Hard Core Wiki-Wonks" -- we need to compensate to get valid input from a true cross-section, especially non-account-holders whose usage patterns vary wildly from True Believers and whose input is rarely solicited and (when offered) usually ignored. While I am an anon here due to my corporate system setup, I've been an active editor on EN projects since 2003. This really is the first project I've seen that (a) fundamentally changed the user experience and (b) provided no reasonable method to restore the previous experience. Combined with the lack of input from massive, critical sectors of our community (like anons and most Commons people), that should have been recognised as an invitation to disaster. It terrifies me that all of those warning signs were missed and I pray that changes are in the works to prevent the same failure mode for other projects. 159.53.110.140 16:10, 25 June 2014 (UTC)(Kevin)

At this point it's safe to assume that the warning signs weren't missed, they were ignored, just as they are ignoring their own statistics which reveal majority disapproval on English Wikipedia and the overwhelming negative feedback here and at the  RfC where this issue is presently being examined. -- Gwillhickers (talk) 16:57, 25 June 2014 (UTC)

Kevin, we made a lot of effort to get input from various stakeholder groups at Commons. Media Viewer has a discussion page there, we posted to commons-l several times, organized round tables, held office hours on IRC, plus probably did a bunch of things that I don't know about. I am sure we still didn't collect input from most Commons users (there are, what, ten thousand of them?) but we got a pretty good cross-section of the concerns of the Commons community, and enough feature requests to keep us busy for three years. Too bad we only had a half.

 

That is usually underappreciated in these kinds of discussions: that we are talking about projects with finite resources (very finite, given the limitations of being a nonprofit), so fulfilling every person's every expectation is just not an option. The people who work on personality rights feel it will be a huge step backwards if Media Viewer does not warn about them, the people who work with GLAMs think those collaborations are threatened if it does not display institutional templates, the people who work with licenses say it must display all custom attribution and permission details down to the last dot, those who work on categorization feel their work is made meaningless if MediaViewer does not display categories, and so on and so forth. Everyone has their pet topic to push, with a fair amount of overestimation of their importance, as it usually happens with pet topics; the only thing no one seems to care about is the actual user experience of looking at an image. Which sucked horribly. And only, oh, 99% or so of the readers care about that, as opposed to multi-licenses and warnings about panorama freedom and displaying the file history. Someone has to advocate for the needs of the average reader, and that job historically falls to the WMF because no one else seems to be interested. And that means sometimes the WMF has to make decisions which make everyone else unhappy. Considering all that, I think we have gone to great lengths to accommodate the most important requests of the Commons community and have generally done a decent job of prioritizing those requests (although in hindsight we should probably have opted for less kinds of metadata, but better displayed).

 

The anon issue, on the other hand, was a complete blind spot. There was just no way to support all the non-basic usage patterns of the file page, so we relied on Media Viewer having a disable switch, and it never occurred for us that that won't work for anons. Yes, that was stupid. As you say, fundamental changes to the reader's user experience are rare (though not unheard of; the switch to the Vector skin being one example), so there is less organizational memory for handling that sort of stuff. A weak excuse but it's all I have. At least we will now remember for a while to plan for anonymous users, I guess. --Tgr (WMF) (talk) 06:02, 26 June 2014 (UTC)

Tgr (WMF) Quote: "...the only thing no one seems to care about is the actual user experience of looking at an image. Which sucked horribly. And only, oh, 99% or so of the readers care about that..." - Dude, whatever. My experience of "looking at an image" didn't "suck horribly" before the implementation of Media Viewer. But it certainly has now, since MV was forced on me, and deployed universally. Oh, and I assume we're both thinking of the same "suck" metric...sheesh. Jdanek007 (talk) 21:51, 4 July 2014 (UTC)

That is NOT a weak answer; it's directly on point and completely honest (and very much appreciated). A few notes:

• My apologies for an incorrect assumption on engagement level for Commons, but there just isn't anything I could find on the project site to suggest that that base had been covered.
• Anyone who expects a product (especially a new one) to fulfil every expectation from every user need serious attention from a mental health professional.
• I am painfully familiar with "200% demand on 50% resource" teams; it's what I do for a living. ;) I have tried to make sure in every post to respect and recognise the effort of the team who built this product.
• The voice of the consumer (in this case the WMF) is lightning rod of any blame-storm. It's a miserable position to hold when the ship sinks, especially if you had weren't allowed to touch the rudder before the team hit the reef.
• Processes improve through failure, not success. I am (pardon the contradiction) shocked but not surprised that anons were missed. It's easy to miss those who are systemically, structurally excluded from most conversations.

A lot of the rage, imho, came from a small but incredibly critical set of missteps. Honestly, very little outrage was driven directly from the feature set; instead, the features became the whipping boys for procedural failures. I feel they can be summarized (details later if wanted), (1) the sense of surprise; the appearance of (2) denial, (3) condescension and (4) diversion on the part of some defenders; and (5) opacity of project history, process and direction.

I am not backing away from my belief that Media Viewer should not be a default feature and stand by my concerns that the original consensus was flawed. But that ship has sailed (and, imho, sank like a rock). We need to make sure that future projects don't founder on the same rocks and, where possible, equip them with tools to avoid similar situations.159.53.110.143 14:11, 26 June 2014 (UTC)(Kevin)

Strange. Only in the English and German Wikipedia can I find the feedback button. No way to express one's opinion in other languages? is something wrong with my IP or what?--Michel le tigre (talk) 08:43, 5 July 2014 (UTC)

No authorship for no Wiki Commons files

Why the new interface view, not seen authorship images that are not uploaded to the Wiki Commons. In Ukraine there is no freedom of panorama, this many photos loaded on servers is Wikipedia. Thanks in advance for the answer and solution.--AlexusUkr (talk) 10:10, 24 June 2014 (UTC)

Hi @AlexusUkr: please see Multimedia/Media Viewer/Template compatibility. --Tgr (WMF) (talk) 01:08, 25 June 2014 (UTC)

Mistake in German translation

The plural of "Website" is "Websites", also in German. At the moment it says "Webseiten" (eng.: Web pages) instead in the column on the right, where the usages of an image are partly listed. That's a common mistake, because "site" and "seite" sound similar in German. I don't think I'm able to correct this myself (plus to add a translation for the escape button X in the right upper corner)? --Miss-Sophie (talk) 11:09, 24 June 2014 (UTC)

You can translate the messages on Translatewiki. --Tgr (WMF) (talk) 01:06, 25 June 2014 (UTC)

No, I can't. Seemingly I didn't pass their quality test, but they sadly don't tell me precisely, why, in the e-mail. I opened an account and they gave me some things to translate from English into German as a trial, so maybe I didn't get the context right for some of them, or my English is insufficient, even though I seriously did my best. If they hadn't asked me for a translation of those of all things, I wouldn't even have tried to translate them. I just guessed the context and skipped the strangest ones, when I couldn't imagine the meaning/context. That's annoying, since I just would like to see this one wrong plural corrected and a translation for the escape tooltip added. Maybe I should have read their FAQs and all help pages before, but I don't feel like going into all of this. So I have to wait till somebody else maybe translates and corrects the mistake ... --Miss-Sophie (talk) 20:32, 25 June 2014 (UTC)

Uh... I have no idea how that works, to be honest. For smaller languages, you just need to say "Hey, I am willing to translate!" and they shove the bit at you; the German translator community might have their own rules. In that case, just tell them to fix this :-) At any rate, there is no special method for developers to translate things, it has to be done at Translatewiki. --Tgr (WMF) (talk) 21:31, 25 June 2014 (UTC)

Translatewiki deleted my new account twice, after they had told me in the e-mail, I didn't pass. So I think, I would have to ask on one of the talk pages as an IP. I'm feeling a bit put off right now. --Miss-Sophie (talk) 21:53, 25 June 2014 (UTC)

Translatewiki.net changed their process a while ago, after encountering some problems. People need to take a "test", which is then reviewed and accounts approved manually. I don't know what quality standard they use; for a major language like German, it might be quite high. User:Miss-Sophie, I hope that you will consider translating here at MediaWiki instead. We certainly need your help with some high-priority translations and reviews. Whatamidoing (WMF) (talk) 19:36, 30 June 2014 (UTC)

Miss-Sophie, I corrected the translation for you. It will take a day or two for the translation to catch up to MediaWiki. Keegan (WMF) (talk) 02:14, 26 June 2014 (UTC)

I reverted myself for the moment. It looks like "Websites" was used once and Steinsplitter changed it to "Webseiten" as a "typo." I've asked Steinsplitter for clarification over on Commons. Keegan (WMF) (talk) 02:37, 26 June 2014 (UTC)

No, it wasn't a 'typo'/typing error/spelling mistake! It might be a bit complicated for Non-German speakers, but I'll try to explain. First "Webseite" (plural "Webseiten") and "Website" (plural "Websites") are both existing loanwords in German ("web" and "site" being English words, "Seite/-seite" being a German word with the meaning "page"), so none of them is a spelling mistake per se. Secondly the two words mean (or at least can mean) two different things, which have two different German Wikipedia articles, see Webseite and Website. Both articles clarify a difference. The article Website even gives Wikipedia as an example, explaining that German Wikipedia as a Website contains more than four million Webseiten. Also Wiktionary makes this difference: See Webseite, which is defined as a single page of a website. So does duden.de (online version of THE German dictionary), see [1] and [2], that additionally traces back "Webseite" to a loan translation of "web page".

On the other hand: On the talk pages for these German articles there are discussions about this topic, where some users argue, that many Germans use "Website" and "Webseite" as synonyms, so that "Webseite" should be treated as a common synonym for a "Website" in the articles, no matter the literally meanings. Others are against it, explaining that "Seite" (= page) is not a translation of "site" and that its synonymous use is wrong and originated as a false friend. I don't know if this false friend theory is true in general and the reason for the development of an often synonymous use of "Website" and "Webseite", but I can say, that in my case it was. For I somehow thought "site" was the English word for "Seite" in this context, until I one day stumbled across the definition of the difference. And I made this mistake, although I knew the word "page" of course. But I didn't know the vocable "site" or its meaning regarding the Internet.

Now I will try to relate all this to Media Viewer: Media Viewer in German right now uses the singular "Website", saying "Auf dieser Website" (for "On this site"), but the plural "Webseiten", saying "Auf anderen Webseiten" (for "On other sites"). Since "On this site" and "On other sites" are meant as opposites (here versus there) regarding the same thing (a "site"), in my opinion the German translation should accordingly also use the singular and plural form of the same word, not a mixture of two different words. So it would either have to be a) "Auf dieser Webseite" (singular) and "Auf anderen Webseiten" (plural) or b) "Auf dieser Website" (singular) and "Auf anderen Websites" (plural). Based on what I wrote in the first passage of this post, the choice should be b) Website/s. Although a synonymous use of "Website" and "Webseite" may exist (see my second passage), I wouldn't choose "Webseite/n". It's much clearer to use "Website/s", because "Webseite/n" has mainly this other meaning of "wep page/s". The more so as there is also "Auf x Seiten verwendet" (for "Used in x pages"), which again contains the word "Seite", and in fact now with the meaning of a single page (Wikipedia article page)! So the use of "Webseite/n" instad of "Website/s" along with "Seiten" for single Wikipedia article "pages" would be confusing things, that are originally very explicitly separated in the English Media Viewer. I hope I could explain this in an understandable way.

--Miss-Sophie (talk) 11:40, 26 June 2014 (UTC)

Fine by me. Changed it back to Websites. Steinsplitter hasn't commented yet, but other confirm this as well :) Thanks! Keegan (WMF) (talk) 16:52, 26 June 2014 (UTC)

Thank you! I'm glad I could convey my points to you. --Miss-Sophie (talk) 18:22, 26 June 2014 (UTC)

Another issue, this time regarding the tooltip for the full screen mode. At the moment it is "In Vollbild anzeigen", but it should be "Als Vollbild anzeigen". A "Vollbild" is a picture filling the whole page/screen, so right now it says "Show in picture filling the whole screen", which doesn't make sense. "Als Vollbild anzeigen" means "Show as picture filling the whole screen". Alternatively "Im Vollbildmodus anzeigen" - "Show in full screen mode". --Miss-Sophie (talk) 21:01, 29 June 2014 (UTC)

Prepositions don't translate quite so precisely. I understand that both of these are probably okay, but als Vollbild anzeigen sounds better to me. What would you think of just plain "Vollbild anzeigen", with no preposition at all? Whatamidoing (WMF) (talk) 19:30, 30 June 2014 (UTC)

I know, that prepositions don't translate precisely and are one of the most difficult things to learn in a foreign language. I only tried an English translation in a way, that non-German speakers could maybe understand the matter a bit. After you said, both versions are probably okay, I googled them and I noticed, "In Vollbild" is actually also in use (60.700 hits versus 125.000 hits for "als Vollbild"), which sounds totally strange to me. I guess, it's a colloquial, 'lazy' way of saying "in full screen mode" with omiting the word "mode" ("Modus" in German). Though grammatically it then would have to be rather "im Vollbild", because it's "im Vollbildmodus", and you actually find this too on Google. Another likely explanation would be, that people, who say "in Vollbild", simply treat "Vollbild" the same way like when they say for example "in Groß", "in Klein" or "in Blau", "in Rot" (I haven't translated this, for I read in your profile, that you speak some German), which is a different case and not transferable, in my opinion. So what to do? Your suggestion without any preposition would work fine for me anyway and I prefer it much to "In Vollbild anzeigen". --Miss-Sophie (talk) 10:35, 1 July 2014 (UTC)

Does anyone object to dropping the preposition? I believe that Translatewiki.net was having some problems yesterday, and I'm not sure if it's up again, but when it is, I or someone else could make that small change. Whatamidoing (WMF) (talk) 00:13, 11 July 2014 (UTC)

Annoying and Unuseful

I find this very annoying and hard to use. I don't want to see this annoying popup. My antivirus thinks wikipedia is sending me popups. Please remove this feature.

Two minor things

Win 7 / IE 11

1. Sometimes when I am moving quickly left or right through the slideshow, a small blue rectangle appears, adjacent to the left/right arrows. This has no obvious purpose.

2. When I click the "full screen" double-headed arrow icon, I get a message from IE saying "Do you want to view wikipedia.org in full screen?" but the display has already switched to full screen, so the message is pointless. I guess this may be a browser glitch that you have no control over.

86.169.36.18 00:39, 25 June 2014 (UTC)

The first is probably text selection - the browser interprets two close clicks as a double-click and tries to select the arrow element. We prevent this for other browsers but somehow not for IE - will see if that can be improved.

The other thing is standard browser behavior; all browsers switch first and ask later. Probably improves the usability that you can immediately see what is meant by fullscreen; at any rate, we have no control over it. --Tgr (WMF) (talk) 01:02, 25 June 2014 (UTC)

File name

My main issue with Media Viewer is that it takes multiple clicks to find the full file name (e.g. File:Example.png): MediaViewer only shows "Example", making it a bit harder to copy and paste the file name into an article (and URLs are longer, making it difficult to just copy the end of it). Is it possible to expose the full file name somehow, perhaps by a user option, or maybe addding it under the "Uploaded by" metadata list? — [[::User:Microchip08|Microchip08]] ([[::User talk:Microchip08|talk]] · [[::Special:Contributions/Microchip08|contribs]]) 06:20, 25 June 2014 (UTC)

I saw there is a link to embed the file, which you get after clicking on the icon in the middle on the right, which says "use this file" or something (I read it in German right now, don't want to log out to see the English tooltip). It already has Wiki syntax. --Miss-Sophie (talk) 17:53, 25 June 2014 (UTC)

Yes indeed, there is a new embed dialogue out now that offers file links in either wikimarkup or HTML for the original size of the file as well as small, medium and large. Keegan (WMF) (talk) 21:52, 25 June 2014 (UTC)

This is bug 64713. --Tgr (WMF) (talk) 18:53, 26 June 2014 (UTC)

I feel like loosing context/contact to the article when using the slide show (especially for many images)

Some more thoughts that come to my mind, while testing Media Viewer. While I like the idea of a slide show option for images in an article and think it looks nice and gives you a better experience of many of the pictures (not of the file information though), I think it should be improved. I don't feel like still being in the article, when looking through the images in Media Viewer. Especially when there is a long row of pictures, I feel that I loose contact to the article and its context.

Reasons for this are:

• Media Viewer looks completely different from the Wikipedia article page, nothing reminds me of the article anymore. You should at least place the title of the article somewhere above! At the moment the only hint is the url, which I'm sure many people don't look at.
• Furthermore the image caption, which (sometimes more, sometimes less) explains the image in context of the article, is hidden below, while the file name is unnecessarily flashy prominent. Unnecessarily, because it is of minor interest in the context of reading an article. Since Media Viewer should serve the reader of an article and the captions are an integral part of this article, those should not just be treated as "further details" behind an arrow. As far as I know, the naming of the file name is also not part of any license conditions, which would justify a flashy prominent presentation. Sometimes file names also sound very strange for a reader, the more so as Media Viewer doesn't add the word "file" or the file format, like the Wikimedia Commons page does. File names are often just catchwords you can't read as a proper phrase, sometimes not telling at all. It's not like they are always the well thought out titles of artworks; they have mostly a practical function (the thing needs a name, so it can be uploaded). I would like the file names to be smaller and not that much a central element of the presentation. Maybe put the file name to the right, next to the "original file" button, which would be intuitively understandable. I think I would also prefer the addition of the file format (.jpg etc.), which makes it clearer to the reader, that this is a file name. Instead the caption of the image in the article should be immediately visible without having to scroll down or click (which I'm sure many people don't do when flipping through the images). I would like this caption to be more separated from the also included file description (from Commons), which is often partly identical and because of that confusing. I doubt "normal" readers understand, why the description in Media Viewer tells them things about the image content etc. in this repetitive way within two passages. Add soemthing like "from the file description page" (together with a link to this page) after this description and put the caption from the article somewhere else, directly visible, as I said, without scrolling.

--Miss-Sophie (talk) 18:28, 25 June 2014 (UTC)

The placement of the image caption was and still is a significant debate, and I encourage everyone else with opinions to speak up about it. I agree with you about placing the caption above the fold for Wikipedias, because the context is everything, but there is limited space on a screen and decisions had to be made about how to use that space. Licensing and Attribution naturally took first place, but I still think there's a way in future design to get the caption in for relevance. Good to hear this coming from you as well :) As for the rest of the design and placement, there's a nice dashboard tracking which actions are the most frequent and/or popular which will help with future design, I think. Keegan (WMF) (talk) 22:08, 25 June 2014 (UTC)

• Currently too much prominence is given to the filename. If filenames were always well-written descriptions of the image then this wouldn't be so much of a problem, but they are very variable in quality, sometimes not in proper grammatical English, sometimes not in English at all, sometimes containing obscure and unnecessary codes and numbers, sometimes just not explaining the picture at all. 86.169.185.14 03:31, 26 June 2014 (UTC)

  I think you have a point here, indeed. Jean-Fred (talk) 08:05, 26 June 2014 (UTC)

  Yes, that's exactly what I mean. Too prominent (I guess "flashy" wasn't the right word) plus sometimes not telling. Regarding "not in English at all" and "If filenames were always well-written descriptions": From a non-English speaking reader's point of view even a file name in proper English has no meaning. There is always a reader whom the most well-written descriptive file name in the world doesn't say anything, simply because it's written in a language he/she doesn't understand. It's all relative, depending of the language abilities of the particular reader. One reason more to give these readers the image caption in their language in this prominent way instead.--Miss-Sophie (talk) 19:13, 26 June 2014 (UTC)

Hi Miss-Sophie, 86.169.185.14 and Jean-Fred, thanks for bringing up the file name vs. caption question. We considered moving the caption above the fold, as proposed in this card #589. But this would require quite a bit of development, as we would need to move everything around, which could introduce new complications; as Keegan points out, space is at a premium above the fold, and we would have to truncate many captions, which would be frustrating. So for now, we recommend waiting until we can support more descriptive 'file titles', as part of the upcoming Structured Data project with Wikidata (it would be the same as the 'Wikidata label' for each file, a short but descriptive title). For now, we have an opportunity to feature 'styled captions' more prominently below the fold, if you think that would help, as shown in this card #159, which is a much simpler task. Let us know if you think that this styling would make enough of a difference to warrant taking it on as one of our last features, before we move on to other projects this summer. Thanks again for your constructive suggestions! Fabrice Florin (WMF) (talk) 19:30, 26 June 2014 (UTC)

Hm, I thought about it for quite a while, but I'm not convinced by the styled captions at all. I think it even looks more confusing and most notably it doesn't solve the problem of the missing caption above the fold versus the too prominent file name. The styled caption looks confusing, because the bold text makes you think, this is a headline with then a second, subordinated headline (actually the title of the article) below, both belonging to the following short running text (the description from Commons). The line on the left will probably not be understandable as the marking of a quote for most readers and just enhances the look of two associated headlines. This impression may vary depending on the content of the text, but the example on your card #159 surely looks like this, since the wording of the caption resembles a typical headline text (think of an announcement of the exhibition). --Miss-Sophie (talk) 16:56, 27 June 2014 (UTC)

Truncated author information

Since Fabrice Florin (WMF) mentioned the truncateing of text above the fold: You already truncate the authors section, if the text is too long. Without the possibility to click on a link to see the whole text (apart from the link to the file description page). I think this is unacceptable, given license conditions that demand the naming of the author. I have thought about how to improve this, though I can't really judge, if my idea works.

• Assuming that I'm a new reader, who doesn't know MV or Wiki in general yet and is confronted with an image with truncated author information like this one. My logical assumption would be, that clicking on the arrow, which directly below this truncated text promises me to provide more details, will cause the rest of the author information to appear. I don't know what else there will be, but surely the dots, which show a part of the text is missing, have to be replaced with the missing text!? I will soon enough realize, it's not like expected.
• But what if clicking on the upwards arrow would not just unfold the information part below, but would at the same time cause the upper text field above the fold, which presently has a fixed size, to widen upwards, so the complete author information can be displayed in the additional space. I assume, the text field above the fold doesn't need to have a fixed size anymore, the moment the arrow has been clicked, since the unfolding information covers the image anyway.
• Alternative option: Include a "more" link that causes a momentary upwards widening of only the text field above the fold (while leaving the fold itself where it is at the under edge of the screen). This upwards widening would give space to display the complete author information.
• Furthermore: I don't know, if it makes sense to include the image caption above the fold with one these two options to show it completely, in case it had to be truncated? It might be less comfortable to see a truncated image caption than a truncated author information, when using the slide show function. I think you're right, saying this would be frustrating, even, if there was one of the two options to show the cropped caption completely. But somehow there has to be an option to flip through the images and to read the caption at the same time, without having to click on "further details". Maybe somewhere to the left of the image?

--Miss-Sophie (talk) 21:15, 27 June 2014 (UTC)

• Hello Miss-Sophie, and thanks for your good suggestion regarding truncated author information. Great minds think alike! :) We agree with you that it's not acceptable to truncate critical author information without an easy way to expand it -- and plan to address this issue next week, as outlined in this ticket #396 (Expand truncated text fields on click)]. The goal is to let you click on truncated text so you can see all of the author and source information about an image without having to go to the file page. For practical purposes, we would expand the metadata panel to present this full information, then contract it back if you click again. Would that approach work for you? Or do you recommend any simple tweaks? Once we have solved this critical issue, it will be easier to think through some of the other related issues like the caption.Thanks again for your constructive feedback, which is much appreciated :) Fabrice Florin (WMF) (talk) 21:53, 27 June 2014 (UTC)

• Good to know, you intend to change that. Regarding your question - I'm not quite sure, if I fully understand your plan from the ticket, but I'll try to comment. If I'm not mistaken, you don't want to create an option to on click read the full text above the fold. Instead the truncated text would after clicking still be displayed as truncated with the dots and you want to duplicate and complete this text somewhere in the section below the fold. With a link from the truncated text, which you can click to unfold this section. I'm not sure how I would like that. My first thought was, that a duplication instead of a replacement with the full text might not look very 'elegant'. That the amputated text and dots are only provisional, should disappear after clicking and not be part of the final result. Plus not truncated file names and author/source information would then unnecessarily always be displayed in two places in MV (above the fold and below). From other sites I'm used to seeing the text continue, where it broke, after clicking on some kind of "more details" link. But I'll wait and see, how I find it. --Miss-Sophie (talk) 16:39, 28 June 2014 (UTC)

• I now see on the card, that the mockup design there is exactly what I thought it should look like. Somehow I hadn't seen the image of the design there before, when I wrote the above. I thought the metadata panel was just the part below the fold, not also the part above. So when you wrote, you plan to expand the metadata panel to show the completed information, I didn't relate this to the part above the fold, which in the mockup of the card is actually the expanded part (and corresponds with my suggestion). So I was a bit confused and thought, you wanted to not continue the text above the folt but duplicate the information below. --Miss-Sophie (talk) 17:03, 6 July 2014 (UTC)

Is scrapping MV on the table?

An honest question for Keegan, Fabrice Florin, and any others involved in bringing us Media Viewer: You claim to have your ear to the community wanting to know our opinions and thoughts on how your product can be improved. Do you consider scrapping it and returning to the file pages as an option if opinions on Media Viewer continue to be negative, particularly from the large and most-active EN and DE wikipedian communities, or are you steadfast in your course that going forward the only changes will be to further "improve" Media Viewer? - S201676 (talk) 02:49, 26 June 2014 (UTC)

From what I understand, turning Media Viewer off for unhappy projects is not off the table. I do not know what the criteria for measuring that is. Keegan (WMF) (talk) 16:25, 26 June 2014 (UTC)

@Keegan (WMF): Please would you find out what the criteria are. Thank you. RomanSpa (talk) 13:27, 29 June 2014 (UTC)

In general whatever counts as a community recognized consensus (usually trough some sort of RFC) on the wiki in question. TheDJ (talk) 14:34, 1 July 2014 (UTC)

@TheDJ: Can you thus confirm that attention is being paid to the discussion and comments in this RFC, Wikipedia:Media Viewer/June 2014 RfC, where it appears that the sizable majority on EN:wiki is not happy with the feature? Perhaps a consensus has not been achieved there, but specific guidelines for determining when a consensus is achieved and assurances that it would trigger the desired disabling of Media Viewer are sought. - S201676 (talk) 18:16, 1 July 2014 (UTC)

'can you thus confirm attention is being paid to the discussion and comments in this RFC' Can you ? I'm not much different the you as far as I know. Communities form consensus in whatever way they do. A consensus should be used when filing a request in bugzilla for a 'site specific' change to substantiate the communities request to deviate from the defaults. TheDJ (talk) 10:26, 4 July 2014 (UTC)

Missing caption + "View original file" button broken

Win 7 / IE 11

(Reported above, but on a page that subsequently changed and so apparently you could not reproduce it.)

Restart browser. Go to http://en.wikipedia.org/wiki/Henri_Moissan. Click on the infobox portrait to go to MV http://en.wikipedia.org/wiki/Henri_Moissan#mediaviewer/File:Henri_Moissan_HiRes.jpg. "View original file" not functioning. Click browser "back" button to return to article. Click again on the same image in article. This time the filename and other content is lost from the lower pane. 86.169.185.14 03:21, 26 June 2014 (UTC)

Thanks for reproducing! This is caused by mishandling file usage lists with strange namespaces. It will be fixed once ticket 570 gets merged. --Tgr (WMF) (talk) 06:37, 26 June 2014 (UTC)

(For the record, this is bug 66147. --Tgr (WMF) (talk) 22:57, 26 June 2014 (UTC))

Can't get 'Back' to the article

I was reading an article with a lot of images and clicked on an image and the viewer took over. I panned to the next image, and then the next and several more. When I wanted to return to the article I hit the back arrow on my browser but it took me to the previous image, again, and again. To get back to the article I had to revisit all the images I had just viewed, in this case I had to back-track through some ten images to get back to the article. (!) Is there a way to go 'straight' back to the article once a viewer has panned through a number of images? -- Gwillhickers (talk) 15:20, 26 June 2014 (UTC)

Unfortunately not. It irritates me still as well, but GIlles has a point if you read through this conversation about browsing behavior and history interaction. There's still ways around this being discussed. Keegan (WMF) (talk) 16:27, 26 June 2014 (UTC)

To clarify, you can use Esc / the X button to go back to the article; but there is no way to go back in the browser history (to the place from which you visited the article) without going through the MediaViewer entries. (Well, apart from the history jumping functions which the browser provides. bug 67008 would make those easier to use.) --Tgr (WMF) (talk) 17:08, 26 June 2014 (UTC)

Yes, the 'X' icon takes you back, but when you hit the browser 'Back arrow' again, you're right back to media viewer at the last image you viewed, where you have to pan through all the images to get back to the same spot. So if you're reading an article (A) and click on a link that takes you to another article (B) where you begin viewing images, you can't get back to article A. In other words, media viewer blocks your recent history functions and to get back to where you started you have to resort to other measures. Any fixes in sight? -- Gwillhickers (talk) 18:29, 26 June 2014 (UTC)

Tgr linked you to 67008, which is a possible fix in sight. Keegan (WMF) (talk) 18:31, 26 June 2014 (UTC)

Well, not really a fix, it would just make it slightly less annoying. You can read bug 62266 for background - we are relying on native browser behavior here, in an area where browsers don't give you a great deal of control. There are alternatives, but they are either risky or even more surprising for the user. --Tgr (WMF) (talk) 18:51, 26 June 2014 (UTC)

Small display problem

Win 7 / IE 11

Go to http://en.wikipedia.org/wiki/Cyclone_Joy. Click the main image in the infobox to go to MV http://en.wikipedia.org/wiki/Cyclone_Joy#mediaviewer/File:Joy_dec_22_1990_0440Z.jpg. Click the "X" button to go back to the article. In the article, click the same image again. A small white box, which appears to be a drawing error, appears in the top left of MV. The outline of this box persists even after MV is closed. 86.169.185.14 00:28, 27 June 2014 (UTC)

I have also seen the text "Show next image", almost certainly left behind by MV, displayed at the right-hand edge of a Wikipedia article, but I cannot at the moment find the steps to reproduce this. 86.169.185.14 03:20, 27 June 2014 (UTC)

I can't reproduce either of these, but the second sounds like bug 66895, just with the next button. (We will soon remove the tooltip from that button anyway, but we might want to consider a more generic solution for the tooltips.)

A screenshot would help in figuring out what the first issue is. --Tgr (WMF) (talk) 06:27, 27 June 2014 (UTC)

I noticed this blank white spot in the upper left corner, too. It seems to be related to the bug with the tooltip for the Exit button, I reported, and can be reproduced as follows by me: Click on an image in an article and close Media Viewer with the Exit "X" button, before the tooltip for the button appears. Now the spot is already there on the article page as a little object with light blue border. Open the same or another image from the article and the white object becomes that spot on the black background of Media Viewer. The spot vanishes the moment you move to the "X" button and let the tooltip for it appear! But if you click "X" then, you get the already described stuck tooltip in the article over the search field instead. By the way, the problem with the left over "X" tooltip occurs all the time and is pretty annoying. You can't use the search field anymore without having to reload the page before. --Miss-Sophie (talk) 08:37, 27 June 2014 (UTC)

It's exactly the same for me. It seems to be very consistent with all images. Tgr, perhaps the reason you could not reproduce my scenario is to do with the timing of the clicks (e.g. waiting too long or something). 86.179.7.208 11:56, 27 June 2014 (UTC)

Hi Miss-Sophie and 86.179.7.208: Thanks for reporting these issues! As Tgr points out, it would be great if you could give us a more detailed report with a screenshot about the first issue, including info about your operating system and browser version. You can either file the report here on Bugzilla, or email it to us, after joining the multimedia mailing list. Regarding the second issue about the Exit button tooltip still showing up after you close Media Viewer, we're addressing this issue, as shown in this ticket #740 (Tooltips can get stuck when MediaViewer is closed). Thanks again for all your help in improving Media Viewer :) Fabrice Florin (WMF) (talk) 22:15, 27 June 2014 (UTC)

Thanks, but I am going nowhere near Bugzilla as I believe it makes email addresses publically viewable on the Internet, which is totally and utterly unacceptable behaviour. In case still wanted, a screenshot of the first problem is at http://oi60.tinypic.com/1z3xnqs.jpg 86.179.7.208 01:31, 28 June 2014 (UTC)

We figured it out in the meanwhile (well, Miss-Sophie figured it out, really). It's the same issue with tooltips, patch is incoming. --Tgr (WMF) (talk) 22:39, 27 June 2014 (UTC)

Thanks for easy disable

Thanks for easy disable. Some dogs just don't want to learn new tricks. 67.161.254.8 01:10, 28 June 2014 (UTC)

No, not thank you. Not as long as this horrible feature is still the default option. I know many people who are not familiar enough with a computer and will not find the way to disable it. As for myself I do not disable it, just to know when the people in charge, if any, will be sensible enough to understand that it is not wanted and that what they claim to be result of a survey is just a big lie. --125.255.112.142 15:34, 29 June 2014 (UTC)

+1 IP users can not make full use of our mediafiles, as long as this thing is default. That could mean loss of contributions to WP, which is inacceptable. Alexpl (talk) 07:47, 1 July 2014 (UTC)

I am happy to learn new tricks. I am disinclined to be fed shit and be told that it's filet mignon. Further, because of the way that disablements work for IP users, they are not counted. Similarly, people who vote with their right-click or control-click to avoid mediaviewer are not seen by the perpetrators of this piece of software as having opted-out.

Image is covered when zooming

When zooming in on Safari (using pinch to zoom on the Mac), the description covers an increasing part of the image. 84.118.208.70 11:36, 28 June 2014 (UTC)

Media viewer does not display well big images on ipad

First of all as frequent Commons user I really do not need this tool. Until now I was too lazy to change my preferences, though I always click it off. But today I realized, MV couldn't display this file in the upright position on an ipad. The whole Image was pressed in the center. Later it was ok.--Oursana (talk) 17:03, 28 June 2014 (UTC)

c:File:After Lucas Cranach the Younger, 17th cent., ‘Portrait of Johann Friederich of Saxony and the Reformers’, Plymouth City Museum and Art Gallery.jpg

This File gets the Filename from other versions gallery in media viewer. Seems to be a bug, please comment and repair.--Oursana (talk) 11:55, 1 July 2014 (UTC)

I'm seeing the file name presented from the name of the file, not the other versions. Is this something that you can reproduce, or maybe take a screenshot of? Keegan (WMF) (talk) 18:34, 1 July 2014 (UTC)

How are opt-outs being counted?

It has been stated that opt-outs from Media Viewer are being tracked. Does this include people like me who disable Javascript using NoScript in order to avoid Media Viewer? I've never clicked on any kind of opt-out, but I haven't seen Media Viewer since the week it was introduced (except to specifically check up on the situation, which has captured my interest somewhat). 79.74.105.228 17:33, 1 July 2014 (UTC)

There is not a way to count this as the Wikimedia Foundation does not track your browser settings, nor would there be a way of knowing a specific reason why they have Javascript disabled. Thank you for sharing your method and reasoning, though. Keegan (WMF) (talk) 18:36, 1 July 2014 (UTC)

wanted: disable tutorial

How can I disable it? Though it looks nice it's a big pain in the ass on some of my machines, which makes it unusable. -- Kai Burghardt (talk) 20:15, 1 July 2014 (UTC)

I mean globally. -- Kai Burghardt (talk) 20:20, 1 July 2014 (UTC)

MediaWiki does not currently support global settings, so you need to disable per-site. That's easy to do though: when MediaViewer opens, you can scroll to the bottom of the page and click "Disable MediaViewer".

Could you share more details on what makes it unusable on some of your machines? --Tgr (WMF) (talk) 21:05, 1 July 2014 (UTC)

Ya, I've already found the per-site opt-out, but I wondered why WP still uses the MV though I've deactivated here on MW. That's weird: We can use SUL, but sharing some settings is too complicated? However, I only use a few Wikis.
It isn't very usable for high-res pictures: It loads, it shrinks the picture to my actual screensize and my mouse stutters. It made problems before, but now it feels even much heavier.
BTW, it's sometimes counterproductive: A picture explained in the article and I won't switch all the time between MV and article view. There's a Ctrl-Tab/Ctrl-shift-Tab much faster.
-- Kai Burghardt (talk) 14:50, 4 July 2014 (UTC)

Images still being shown at wrong aspect ratio

Win 7 / IE 11

The problem with some images being shown squashed or stretched is still occurring for me. The latest example I've noticed is http://en.wikipedia.org/wiki/RGB_color_model#mediaviewer/File:CIExy1931_sRGB_gamut_D65.png.

This is a serious problem that really should have been fixed by now. What is happening with it? 86.167.19.242 20:33, 1 July 2014 (UTC)

The bug has been fixed a week ago, and the link works fine for me in Win8/IE11. Might be a cache issue - you could try refreshing via Ctrl-F5, or clearing your browser cache. --Tgr (WMF) (talk) 21:02, 1 July 2014 (UTC)

Thanks, that seems to have fixed it, at least for that picture. Do you know whether this failure to download new versions of pages is another bug with Wikipedia, or is it a browser bug? 86.167.19.242 22:53, 1 July 2014 (UTC) Spoke too soon. It displayed OK two or three times, now it is back to being stretched. 86.167.19.242 22:55, 1 July 2014 (UTC)

In case it is significant, by the way, it displays in the correct proportion but as a blurry low-res image for about a quarter of a second, then rescales to the wrong proportion. 86.167.19.242 22:57, 1 July 2014 (UTC)

Behaviour is inconsistent and not exactly reproducible. Try this:

In IE, set up bookmark buttons for the following three pages (makes things easier):

http://en.wikipedia.org/wiki/RGB_color_model#mediaviewer/File:CIExy1931_sRGB_gamut_D65.png
http://upload.wikimedia.org/wikipedia/commons/0/08/CIExy1931_sRGB_gamut_D65.png
http://en.wikipedia.org/wiki/Door_handle

(last is arbitrary article that I thought unlikely to change; it probably doesn't matter)

Close browser, clear local cache and restart browser.

Now keep displaying the three pages one after another. I have three buttons that I keep clicking randomly. Sooner or later (it may take a little while) when you click on the first link you should see the distorted image in MV. If it seems not to be happening, restart the browser. Keep trying until you see the distorted image or get tired of trying. 86.171.42.22 01:44, 3 July 2014 (UTC)

I didn't realise

I could scroll that white stuff at the bottom of images in Media Viewer. Because with Media Viewer, where the page ends and this "floating presentation box" stuff begins is unclear. I was trying to turn it off. The first time I tried, it didn't work (no idea why). The second time, it worked.

I rather expect it will magically reset itself weekly.

This place is turning into Google, where they force arbitrary shit down people's throats every few months and call it improvement.

No tooltips in full screen mode available

On Mac OS X, Firefox 30.0

When I'm in full screen mode of Media Viewer, there are no tooltips available for any of the buttons. Is this on purpose? I think, there should be tooltips, too. Strange thing: I noticed, that if you hover the mouse over the 'end full screen mode' button, there actually does appear a tooltip for it, but only after clicking, the moment the mode has been finished, not before! The same happens, when you hover over the X in full sreen mode and then click. The only difference is, that in this case the old issue with the sticking tooltip occurs.

An addition regarding the already known bug with the ending of the MV full screen mode affecting the full screen Firefox browser window, which I can't find on Bugzilla: Firefox goes unexpectedly out of full screen mode not only on clicking the 'end full screen mode button' in MV, it also changes over to a smaller window, when clicking the X escape button of MV in full screen mode. I expect Firefox to stay in full screen mode for both ways of ending the MV full screen mode. --Miss-Sophie (talk) 14:23, 3 July 2014 (UTC) And another addition regarding this full screen bug. MV goes out of full screen mode also when clicking on one of the links from the panel, that appears, when moving the mouse in full screen mode, e. g. a link to the file this image has been derivated from or a link to the user who derivated this file, a link to the source file on Flickr or the author on Flickr. Examples: [3] and [4] --Miss-Sophie (talk) 15:33, 6 July 2014 (UTC)

I'm not sure about the tooltips issue, that'll get looked into. For the second part, here's the bug that I filed for the fullscreen issue that you were looking for. Keegan (WMF) (talk) 20:11, 3 July 2014 (UTC)

We use tipsy which does not work in fullscreen mode (it appends the tooltip to the body instead of the fullscreened element). Tipsy is unmaintained and generally low quality; IMO trying to address its non-critical bugs is not the best use of development time. --Tgr (WMF) (talk) 20:55, 3 July 2014 (UTC)

bug 41086 tracks this FWIW. --Tgr (WMF) (talk) 22:46, 3 July 2014 (UTC)

Whoa, whoa, whoa. You guys are producing a new flagship feature, and included code from a known-dead and known-low-quality third-party project? Whose idea was that? Which manager approved it? And now when a user reports it failing to operate correctly, your response is to produce a bug report from 2012, indicating that you've collectively been aware of the issue for nearly two years, but then tell the user "trying to address its non-critical bugs is not the best use of development time"? Something has gone badly wrong here at a number of levels. — Scott • talk 08:58, 4 July 2014 (UTC)

Tipsy is a module of the core software and used in several more places. Code reuse is usually the preferred strategy, so it's not that strange. This problem should raise the priority of either fixing it or replacing it. Just tossing on another implementation in our global mix is FAR more problematic. @Tgr (WMF): , please watch out with bringing too much technobabble into the forum here, discussions around picking a library are usually better reserved for Bugzilla. A bug is a bug. TheDJ (talk) 10:18, 4 July 2014 (UTC)

I certainly understand and support the principle of code reuse... it was just the admission above that "Tipsy is unmaintained and generally low quality" that was startling. Well, it's good that this isn't something that's freshly entered the system. Even so, and I'm only the peanut gallery here but, that strikes me as quite a serious liability to be willingly left unaddressed, no? I also agree that responders to bug reports should refrain from dumping out developer-grade information on the unwary. — Scott • talk 11:02, 4 July 2014 (UTC)

Another full screen issue: Media Viewer shuts down when opening the license (in a new tab)

Mac Os X, Firefox 30.0

I opened an image in a Wikipedia article with Media Viewer. If I am in full screen mode of MV, move the mouse and click on a Creative Commons license link (e. g. "CC BY 2.0") in the then appearing panel, the Creative Commons license page opens in a new tab, as expected. But when I click on and switch to the old tab, where I left Media Viewer and where the tool is supposed to still be active, Media Viewer has shut down and I'm back on the Wikipedia article page. This only happens in MV full screen mode. In the lightbox mode MV stays active in the old/first tab. --Miss-Sophie (talk) 14:57, 6 July 2014 (UTC)

Interesting. Thanks, Miss-Sophie. I'll file a bug for this later. Keegan (WMF) (talk) 00:15, 8 July 2014 (UTC)

This is bug 62578, probably. The browser exits fullscreen mode when you open a new tab, which causes MediaViewer to exit. --Tgr (WMF) (talk) 00:29, 8 July 2014 (UTC)

If it ain't broke

but you nevertheless feel an overwhelming urge to replace it by something worse, you should at least have the courtesy to make it opt-in rather than the default. Maproom (talk) 21:35, 3 July 2014 (UTC)

Yet another user's opinion

I don't like it. These are my inner thoughts.

1. It doesn't match the rest of wiki at all. In particular the links and tabs one expects to always be at the top of the screen are suddenly gone.
2. My browser is getting awfully slow.
3. Oh I see, this new media viewer thing isn't actually a page in itself, its a giant popup obscuring the entire article under it.
4. There are no headers for many of the metadata fields. The first thing I read below the image is a name. Its not immediately clear if that name is the person who uploaded this file, or the creator of the work. I scroll down to see if theres something more verbose...
5. Oh look, there's a "Created" date. Wait, is that when the original work was produced, or when it was added to wiki, or when it was added to commons?
6. Whatever... so now I want to view the full size image. Now is that the double arrow button?
7. Nope, that makes my browser pretend its the only program running.
8. Oh, its the picture frame button that I can't see now because I covered it with this floating thing.
9. Good thing there's a square with outward pointing curvy arrow button that does the same thing at the cost of another click.
10. But wait, I should check the edit history while I'm here to be sure the last editor didn't screw up the white balance... oh snap, thats not shown here.
11. Oh, if I click on this commons logo or the lovely text link I'm taken to a page that has everything I could ever want.
12. Hmm, I could disable this media viewer thingy and see that nicely structured page without so much clicking.
13. Odd, I disabled it in my preferences but it still comes up.
14. OH! I have to disable it on every Wikimedia site individually...
15. ...and always make sure I'm logged in, even if I'm just here reading...

Krushia (talk) 22:43, 3 July 2014 (UTC)

Why, oh why?

Who on earth decided for this total nonsense? This is the biggest encouragement to skip information concerning authorship and copyright status of any image, and "just proceed to steal it without caring about it". My compliments to the genius who created it. Great educational work --G.dallorto (talk) 13:09, 4 July 2014 (UTC)

Far more trouble than it's worth. Why do we have to learn something confusing? Just leave the old link there so we can go straight to it and let the newbies be confused. Carolmooredc (talk) 16:13, 4 July 2014 (UTC)

A missed opportunity!

My experience was similar to Kerushia above.

It's ... really a problem that preferences aren't universal across sites. There's no logical reason for that.

That seems like an actual essential bug that wants fixing. While the image viewer was not broken before -- A bit of an eyesore, but now replaced by a different type of soreness & problems.

Reading some of the other comments: Kevin is kind and totally right, about everything. 82firebird (talk) 15:27, 5 July 2014 (UTC)

Customizing Media Viewer with user JavaScript

I'm trying to make the image as displayed in Media Viewer a link to the file description page. By testing in my browser's console, I found that this code does that:

$('.mw-mmv-image img').wrap($('<a>', {href:$('.mw-mmv-repo').attr('href')}));

But my (possible noob) question is: how do I execute that after Media Viewer has loaded? Is there some event I can bind this to? Darkweasel94 (talk) 14:21, 5 July 2014 (UTC)

I think that many people's question is why in God's name has this OBVIOUS feature, that was suggested weeks ago, that is intuitively expected, and that would take someone FIVE MINUTES to implement, not already been added? 86.167.124.250 19:19, 5 July 2014 (UTC)

There are two links to the file description page. The right symbol in the panel directly below the image and a link below the fold, after you have clicked on the down arrow, that expands the panel. --Miss-Sophie (talk) 20:58, 5 July 2014 (UTC)

Yes, but the OBVIOUS thing, that "everyone" would expect to work, or to do something useful, namely clicking on the image, does nothing. 86.167.124.250 22:04, 5 July 2014 (UTC)

Ah, I see. I was under the impression, the first poster above misses a link to the description page and that you agreed. Yes, I would expect to see a larger, zoomed in version on clicking on the image, if that is, what you are thinking of. One has to click on the 'original file' button on the right to get this, which appears as an indirection. --Miss-Sophie (talk) 23:05, 5 July 2014 (UTC)

Annotations

When using Media Viewer to view an annotated file, the annotations do not show up. An example is provided in the thumbnailed image, but more examples can be found here and here. 74.46.254.174 16:19, 5 July 2014 (UTC)

No regression testing for compatibility with major features? That is almost unbelievable, suggests many more uncaught bugs. Tonicmatic (talk) 05:03, 10 July 2014 (UTC)

RfC for Media Viewer

To read further feed back, other discussions and/or to leave a comment/vote about whether Media Viewer should be the default viewer please visit RfC for media viewer. -- Gwillhickers (talk)

Please note, this RfC is specific to the English Wikipedia. -Pete F (talk) 17:17, 5 July 2014 (UTC)

Request for Comment on Commons about Media Viewer

In addition to the RfC linked immediately above (on English Wikipedia), there is an ongoing RfC on Wikimedia Commons about the future of this software feature. Your thoughts welcome. -Pete F (talk) 17:17, 5 July 2014 (UTC)

• Commons:Requests for comment/Media Viewer software feature

Can't give feedback in other languages (only English and German)

I read Wikipedia in several languages. When I am in the Media Viewer, only in the English and German WP is the feedback button available. Is it just on my laptop, something to do with IP or cookies? I tried several browsers and as I move a lot my IP also changes a lot. If users can't give feedback in other languages this will explain why the negative feedback is not increasing in French, Portuguese... and most languages other than English and German.--Michel le tigre (talk) 12:00, 6 July 2014 (UTC)

The survey feedback time concluded and the links were removed, but we did indeed run feedback in French, Catalan, Portuguese, Hungarian and Dutch as well as English and German. The English and German feedback links are being removed this week. Keegan (WMF) (talk) 00:12, 8 July 2014 (UTC)

Does this mean that you have enough feedback to recognize the error of your ways and stop inflicting this on us?

What am I missing here?

I don't get it.

If you wanted to "free" image rendering so that an image dynamically resizes to every User's own custom settings and available browser window-space, just stop forcing the thumb's inner container to a fixed width (220px default user pref setting + 2px padding) and have it inherit a width based on the outer container's width instead. No srcset= x2, x3 ,data-file-width crap required; just some css to outwit the wiki-markup's sloppy hold on IMG elements. You'd still be loading the image at it's actual dimensions at first either way, no?

Try it: open this page on Wikisource and resize your browser window, etc. all you can. The images should resize themselves on the fly - no scroll-bars ever. -- George Orwell III (talk) 13:12, 6 July 2014 (UTC)

Looks very cool @George Orwell III: ! I don't know the ins and outs of CSS well enough to fully understand what you did, but I like the results (as an option to consider). One question: do you think there's a way to have the software intelligently choose a cached version of the image that isn't enormously bigger than the screen? For instance, if you're viewing on a phone at 2g, you don't really need your browser loading an 8000px wide version of an image. -Pete F (talk) 18:54, 6 July 2014 (UTC)

I'm sure there is a way to do just that but it will take someone who knows what they are doing & knows the wiki-code. It's beyond my limited skill-set thats for sure.

But I still don't understand what the point of MediaViewer is [outside of Commons]. I thought images were there to enhance or support the contributed content, not over-shadow it. -- George Orwell III (talk) 19:48, 6 July 2014 (UTC)

OK, well you've created a cool concept regardless. I hope it gets captured somewhere that it doesn't get lost entirely. On the more general point, I think you and I are in complete agreement -- I think the MV is a very big step backwards. -Pete F (talk) 06:31, 7 July 2014 (UTC)

• What difference am I supposed to be seeing? I do not see anything obviously different. 86.167.125.52 11:58, 8 July 2014 (UTC)

Suggestion: Commons language settings should adapt (for IPs)

Let's say I'm not logged in and read a German Wikipedia article as an IP. Then I open an image from the article in Media Viewer and decide to there click on "More details" to go to the file description Commons page. While the surface is in German in Media Viewer, as well as the integrated description from Commons (if there is any available), as soon as I enter the Commons page, everything is in English by default (menues, LICENSE template and other template texts etc.). I can change this setting on the Commons page, since they offer me a link above the image and also in the side bar menue to see the page in German, but when I "return" in my browser to Media Viewer, go to the next image in the slide show and decide again, I want to see more details on Commons also for this picture (or I decide I want to see the details for the same image again; this applies to any image from the slide show), I'm presented the Commons page in English again. That's annoying.

I would like the Commons language settings to

• adapt to the language of the Wikpedia site the reader is coming from (if the clicked on image is in a German Wikipedia article, the Commons page should use the German language settings by default, without having to select them manually)
• be kept (or another language setting, if a reader actually changed this default language for some reason, for example switched from German to English) for the following images from the slide show. So that, when I click "return" in my browser and then click on the Commons link of another image from the MV slide show, I don't have to again choose the language setting I already had activated before.

--Miss-Sophie (talk) 09:17, 8 July 2014 (UTC)

Boycott

It pains me to do this, but there seems to be no other way forward. So long as this bag of misfeatures known as Media Viewer continues to be the default for non-logged-in users of Wikipedia, I will not contribute to, edit, or otherwise support Wikipedia. --128.104.68.125 18:43, 8 July 2014 (UTC)

Likewise, an article-smothering javascript overlay belongs in some earlier version of Facebook or Flickr or other abominable social media, and not what's supposed to be - or at least once was - a serious Community-consensus-driven online encyclopedia. Mic drop.--144.92.71.49 00:09, 9 July 2014 (UTC)

Update on RFCs

The English Wikipedia's "Request for Comment" (RfC) on the continued use of Media Viewer was closed today, with a consensus that MV should be disabled by default for both logged-in and non-logged-in viewers. The consensus has not yet (as of 9 July) been implemented on the site.

• RfC for Media Viewer

On Wikimedia Commons, there is an ongoing RfC on the same topic. Your thoughts welcome. That RfC is expected to run through 27 July.

• Commons:Requests for comment/Media Viewer software feature

-Pete F (talk) 17:04, 9 July 2014 (UTC)

Feedback button

At the right bottom of the Media Viewer there is a "use this file" and a "more details at Wikimedia Commons" button. At the left of them there used to be a feedback button. Please re-add it? :-)

--Gryllida 04:27, 10 July 2014 (UTC)

2nded, even if the feedback button just directs people to a subpage of this page. Tonicmatic (talk) 05:05, 10 July 2014 (UTC)

There's still a link to this talk page below the fold. After the first month of being enabled on any site, we felt free to remove the link to the SurveyMonkey surveys we were running. If you have things to say, we're still listening :) --MarkTraceur (talk) 05:42, 10 July 2014 (UTC)

No better

I've just been invited to look at the latest version of MediaViewer and add a comment here. I don't see any improvement. If a designer had thought "How do people use and want to use Commons images", that designer would never have got into this mess.

If the screen provided a complete filename that could be copied-and-pasted, I think editors might have learned to live with the other nuisances. But it didn't, and it still doesn't, even now. So it's a timewaster. So disable it. Andrew Dalby (talk) 09:18, 10 July 2014 (UTC)

Focus on the the purpose of viewing images and don't try to replace the file description page

Leave the reuse options for a file on the file description page

I see, you have tried to improve the "Use this file" tool. But I really think you should leave all options for using a file on the file description page and remove the download/share/embed toolkit from Media Viewer. Make the "Use this file" link in MV a link to the file description page (opening in a new tab). The using of a file has nothing to do anymore with the immersive viewing experience, you proclaim to be the goal of Media Viewer. When I think about using a file and then download/embed/share it, I'm not viewing any longer. In my opinion you should really focus on improving that viewing experience (it's supposed to be a Media VIEWER) and not try to replace the Wikimedia Commons pages. Users get so many more necessary information about the use of a file on the Wikimedia Commons page:

• a link that leads to a page with information about how to reuse a file from Wiki in general, in different languages like [5] or [6].
• templates with summarized information about the license conditions and important restrictions for the use in certain countries like {{self|Cc-by-sa-2.0}} or {{PD-Pre1978}}. Plus all this in a language they understand (as soon as the Commons language settings are accordingly, see also my comment/suggestion about this topic above), because not everybody understands English! Non-English speakers don't understand, what this linked Creative Commons license text in English on creativecommons.org wants to tell them. (By the way, a reader, who has never before heard about Creative Commons licenses, might not even assume, that these cryptic characters like CC BY-SA 2.0 under an image in MV have to do anything with a license or with using the file at all.) Opposed to this, the file description page on Commons gives a template with summarized information in the respective language (in the license section). The "View terms" link in MV often doesn't help, since unless a template is included in the permission section of the Commons page, which is not always the case, MV does not show this template. In this example the reader is left with the cryptic letters "CC-BY-SA" as terms in MV. (And the "View terms" label does not even give a hint, that these "terms" are related to using a file. Terms for what?)
• templates that warn the reader to respect the personality rights of pictured persons
• certain further information about the content of a file or related to its content, which Media Viewer does not embed as a description but which might be of importance for somebody, who wants to use the file. For example the information in the {{Artwork}} template is not embedded in MV. It might well be, a user is interested in sharing also the there given information regarding the artist, painting technique, location of the artwork etc, when reusing an image (example). In general one should provide the user, who wants to reuse a file, with all available information about a file before, so he can select, which information he wants to use, and judge, which information is relevant for his purpose. MV does invite the user to download/share/embedd without having seen this information on Commons.

If you think, it's necessary to improve the tools for using a file, rather work on the tools next to a file on the Commons page. Maybe integrate some of your ideas for the MV "use this file" tool there. Personally I like the icons and labels on Wikimedia Commons (Download, Use this file on the web, Use this file on a wiki, Email a link to this file, Information about reusing), which are clear and prominent. But don't try by any means to skip the Commons page for the processes of using a file. Many thoughts went into these Commons pages and the templates, which are supposed to hint at certain conditions for using a file. It's obvious and understandable, that users, who think these hints are important, are against Media Viewer in its current concept, when it shows a tendency to block the access to these hints like a kind of 'wall' (yes, the wall has a door, but readers are not obliged to open it, before they use a file). And, to repeat my opinion again, downloading/sharing/embedding has nothing to do with an "immersive viewing experience". It is on the contrary a rather dry, rational act, since it means dealing with license stuff / code / urls etc. So the MV experience should end (or be interrupted), the moment a user decides to reuse a file. To me it looks like Media Viewer is loosing its concept and course here, at the cost of its potential, which would mean to really concentrate on the viewing options.

--Miss-Sophie (talk) 13:59, 10 July 2014 (UTC)

Focus on the viewing options

I think Media Viewer has some potential and things I like. I like, that I can look at all images from an article in larger size in a slideshow. This is especially interesting for images that form a sequence, like images that illustrate a historical development, a progress or a storyline, but also associatively to get a coherent impression of all the related images regarding the same article subject. Several pictures can become a whole that makes a different impact than just a single picture. Though you can look at all the images together in the article, the thumbnails are often too small to reveal interesting/informative details and when I go to Commons to look at a larger version and then go back to the article to there choose the next image, this is always an interrupted experience. It might work in cases, where you read a part of the article, then click on an accompanying image, go back, read on and then click on the next image, but not, if you want to look at the images one after another, to see them as a whole. Also the images on Commons aren't presented well as pictures. If I open a Commons image page, the first things that catch my eye are the file name, the tool menue for reuse and an often only half visible image with the lower half missing, so that I have to scroll down to fully view it (and even then it's not centered and surrounded by other information). Or I have to click on a certain resolution link or the image to see it presented well. I also like the full screen option in MV. So these are the nice things.

But in my opinion the tool doesn't use its potential well and looses its course by trying to be a replacement of the Commons page. Regarding the use of MV on Wikipedia pages, MV has (or could have) one important advantage over viewing the images from an article on Commons: It can (or could) show the larger sized images in context of the article, as opposed to independent Commons file pages, which also show larger images, but of which each is a separated unit without direct relation to the article. One means to reach this is the already mentioned slideshow, which merges the images from an article. Another important ingredient is the image caption, which links an image with the article text. Mind you, the caption is not part of the file description page but just part of the article, and if MV shows this caption together with a larger image, it does something Commons can't do! (Commons file descriptions may differ from the caption). But here MV disappoints, for it hides this caption and gives the not article relevant file name a prominent role instead. MV also sadly doesn't display the title of the article, which would help to not forget, which article these images you are browsing through belong to, and would work as a visible connecting 'frame'. The help page and advertising for MV always stress, that MV shows the file on the same page as the clicked on image, on the article page. My issue with this claim is, that it doesn't really feel like being in the article because of the things I have just stated. There might be other reasons as well, like MV completely covering the article page.

If one wants to develop the image-article connection in MV even further, I think the following would be really cool and upvalue MV a lot for the use on a Wikipedia page: One could add a "quote function". This would allow to add (in a new parameter for the file template?) a 'quote' of limited length from the running text of the article to an image, in addition to the caption. The quote would be displayed together with the image in MV and is supposed to contain an excerpt from the article, that is directly illustrated by / related to the image, if such a text passage exists. If not, no quote will be added. (As an editor I try to not randomly choose and place images in an article but in the context of the content, so the running text might contain information related to the image, that is not in the caption, also because I try to avoid too long captions, when I need space for more images one below the other.) It doesn't have to be a real quote but can for practical reasons also be a modified quote or kind of summary of the relevant passage. Maybe one could make room for this quote to the left of the image in MV (in a column or window with scalable width and a scroll bar?), with an option to deactivate or activate the column / the displaying of the quote. The size of images (especially in a landscape format) would then have to be able to adapt: An image might have to become smaller to be still completely displayed, when the quote function is active, since the column needs room. If the column width was scalable by the user, the user could decide individually and from image to image (which have different formats), how much room he wants to leave for the column-window, he reads and scrolls the text in, and how much for the image, he simultaneously views in context of this text. (One user on this discussion page developed some code for size adapting images in browser windows of different sizes, see [7], which shows what I'm thinking of here regarding adapting image sizes). I'm sorry, if I don't use the correct technical terms here, but I'm no webdesigner and only a user who suggests, what kind of tool she would like. I hope, it's comprehensible. :-)

And of course MV, as a tool that wants to improve the viewing experience, should include a zoom function and other visual tools (some people here mentioned the annotations, for example). In my opinion you should focus on this and all the above, not on replacing the Commons page. I would like Media Viewer to be an additional tool, I can choose to use in a certain case, not a replacement and default tool for every user. P. S.: For viewing images on Wikimedia Commons the tool might need different features, I only referred to MV on Wikipedia.

• Media Viewer: View an image from the article in larger size and in context of other images from the the article (slideshow), as well as in context of the article text (caption and quote) - plus show the link to and some information from Commons (one has to carefully think about, which one make sense here), like the author attribution (also other possibly obligatory things dictated by license conditions) and below the fold the file description. But leave the license details together with the reuse options on the file description page (see my comments in the paragraph above); only name the license, make the "View terms" label clearer (e. g. : "View terms for file use") and link it to the file description page.
• File description page: Show all information regarding the file, ways and conditions to use it, ways to edit and discuss it, other functions

--Miss-Sophie (talk) 13:59, 10 July 2014 (UTC)

Response to the Media Viewer RfC on English Wikipedia

Hi folks. We wanted to let you know that we just responded to the Media Viewer RfC on English Wikipedia, which closed yesterday.

Here is what we posted on that discussion page:

"Thanks for sharing your comments about Media Viewer.

The Wikimedia Foundation appreciates feedback about features we develop, and we respectfully acknowledge this group’s proposal to disable Media Viewer on the English Wikipedia.

After carefully reviewing this proposal, we recommend that Media Viewer remain enabled on the English Wikipedia, for a number of reasons:

• We believe that an RfC of this type is not representative of our much wider user base.
• Readers in particular are not represented at all in this kind of discussion, and they are a key user group for this feature.
• Media Viewer was developed with extensive community guidance from a more diverse user base for over a year, through beta testing, online discussions, usability studies and other feedback channels.

Media Viewer provides important benefits to users:

• Larger images: this tool shows images more prominently, with a single click.
• Faster image load: files are shown twice as fast as the previous solution, since you don’t have to go to a separate page.
• Easier browsing: more users click on the next and previous buttons than on thumbnails, increasing overall image views.
• Better use of space: less scrolling is required to find information, due to a more compact layout.

Other factors were considered in reaching this decision:

• Media Viewer is a central part of our strategy and vision to modernize our multimedia software and user experience.
• As recognized by the Wikipedia:Consensus policy, software development is not subject to the same policies which bind English Wikipedia editors.
• Users who do not want this feature can easily turn it off, and only a small percentage of English Wikipedia users have chosen to opt out so far. We encourage users who don't like Media Viewer to disable it.

Overall, we believe that Media Viewer’s benefits far outweigh its downsides. And while the feature still has some limitations, we have collectively identified practical ways to improve it over time.

We deeply appreciate your help in making this tool better and we hope that more users will come to value this feature as a result. Thank you so much for your feedback. Fabrice Florin (WMF) (talk) 17:52, 10 July 2014 (UTC)"

Comments

• Do we have to rub your face in it?

so you will understand it is shit? Sorry, I do not like to be rude, but if this is your choice we have to.--87.13.242.13 22:18, 10 July 2014 (UTC)

I like…

I like that:

• Extension:CommonsMetadata was developed - it will ease migration to Wikidata and is useful for third parties fetching attribution information.
• Improvements to OOjs UI (also thanks to the VE team).
• Improvements to image scaling were made and there are even more good considerations.
• Community engagement by hangouts and openness during development -- a "disable link" has been installed.
• A tool was created that is truly useful to visitors who only want to watch the image.

The issue is that:

• Photographers who were used to be able to design their own big fat authorship templates and put all kind of **** on the file description pages, are dissatisfied that the reader will most likely not see all this ****.
• People working with files do not need it. It's a nuisance for them.
• … and a lot more listed above and in the RfCs.

-- Rillke (talk) 22:10, 10 July 2014 (UTC)

Need to change the metadata class name

Two reasons:

1. Icons are not "metadata". Metadata is "data about data", e.g. the author of an image. Icons are, well, icons. An optional graphical representation of the actual (text) content.
2. The German community uses this class name since at least 2007 for exactly what it says: metadata. Metadata (may it be an infobox row or a whole template) is hidden by default (display: none) and shown by enabling a tiny CSS gadget.

I suggest class="icon" or something in the line of class="decorative" (source). --TMg 22:30, 10 July 2014 (UTC)