Extension talk:Media Viewer/About

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.

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 on the English Wikipedia.

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)

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)

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.

Bug: "Close this tool. Or press Esc to exit" pop up doesn't go away
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
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 (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, 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, 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 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 .) 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?)
I skipped through the images from the 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, 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
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)

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

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

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? — Microchip08 (talk · 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. --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. --Miss-Sophie (talk) 21:15, 27 June 2014 (UTC)
 * 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?


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

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)

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 gets merged. --Tgr (WMF) (talk) 06:37, 26 June 2014 (UTC)
 * (For the record, this is . --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. 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 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, 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)

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)

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) 17:29, 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)