Extension talk:Media Viewer/About/Archive04

Good example image to perhaps test features like this before rolling out ...

http://en.wikipedia.org/wiki/Linux_distributions#mediaviewer/File:Linux_Distribution_Timeline.svg

For some reason the "view original image" link isn't working for me and I found no way on Win7 with Firefox 29 to actually get at that image at a usable size via the new viewer. Finally "Copy Link" on the actual thumbnail on the main wiki page and using that link directly got me the old approach where I can use my browser to zoom to my heart's content.

I agree with others this isn't necessarily a bad feature ... when you want it. But when you don't? Aiieeee.

Can you explain in more detail how "view original image" does not work for you? --Tgr (WMF) (talk) 03:55, 16 June 2014 (UTC)

Tested with FF 30/Ubuntu : opening MMV on this image makes mw.Title throw TypeError: mw.config.get( 'wgFormattedNamespaces' )[ this.namespace ] is undefined in getNamespacePrefix and clicking on the “view original image” does nothing — Ltrlg (talk), 11:27, 22 June 2014 (UTC)

That's bug 66147; there is a patch pending. --Tgr (WMF) (talk) 22:56, 26 June 2014 (UTC)

New features are live!

Hi everyone: To follow up on our earlier update on Media Viewer, I’m happy to report that we just deployed a range of new features today, based on community feedback.

1. New features
These features are now live on English Wikipedia, German Wikipedia and other Media Viewer sites:

• View original file: A prominent button to open the original image in your browser (#630)
• Show Commons link to logged out users: now all users can quickly access the file description page (#429)
• Scroll down for more info: Use either up or down arrows to open the metadata panel below the image (#697)

Try them out with these sample images and let us know what you think using the built-in feedback tool in Media Viewer — or in this discussion page. You can find these new buttons at the lower right corner of the Media Viewer tool. All three features address frequent community requests — especially the ‘View original file’ button, which lets you use your browser to zoom in, or download images for re-use.

2. Next features
We're now working on these next features, to address other community requests:

• Instant Opt-out (#703) (*)
• Opt-out for anons (#704) (*)
• View different image sizes (#664)
• Add tooltips to Media Viewer (#546)
• Make it easier to find image information (#706)
• Disable MediaViewer for certain images (#511)
• Show attribution credits in download tool (#598)

The first two opt-out features asterisked above (*) can now be tested here on MediaWiki.org, on this demo page — open the metadata panel and scroll down to the bottom, then click ‘Disable Media Viewer’. To learn more about these features, click on the relevant cards on the current sprint wall of our planning site.

We aim to deploy these next features on MediaWiki.org by next Thursday, then to all other sites the following week. To accelerate deployment, we may back-port the most important improvements to all Media Viewer sites next week, if they test well on production.

3. Next releases
We are preparing to deploy Media Viewer on all wikis next Thursday, June 19, if all goes well with the testing of these new features. We’ll keep you posted as the release date approaches.

4. Metrics
We are now logging about 24 million global image views per day for Media Viewer, doubling overall traffic since last week. The most active sites are the English Wikipedia (10M views/day), the German Wikipedia (3M views/day) and the Spanish Wikipedia (2M views/day), as shown on this global image view dashboard. Global network performance has remained stable, at about 2.5 seconds per image served for 90% of our users (~4 seconds for the 95th percentile).

5. Surveys
We continue to see favorable global feedback across all surveys:

• about 60% of 13,891 global respondents find the tool useful, on average.
• approval breakdown by language: French 71%, Spanish 78%, Dutch 60%, Portuguese 81%, Hungarian 63%, English 29%, German 26%.
• approval rates have stabilized for all languages that have used the tool for over a month (excluding English and German).
• English and German approval rates are lower than other languages, partly because Media Viewer was only launched one week ago on their sites.
• English daily approval rates have increased from 23% a day after launch — up to 35% a week after launch.

We expect approval rates on Enwiki and Dewiki to keep increasing over time, as new features get rolled out based on community feedback. For comparison purposes, approvals on the Hungarian Wikipedia started at 42% and grew to 63% in just a few weeks, once we addressed the most important community issues. To learn more, visit the survey results page.

Please let us know if you have any questions. We’ll keep you posted on the next major developments.

Thanks to everyone who gave us constructive feedback in recent days: we really appreciate your guidance and look further to improving Media Viewer further in coming days, with your help. :) Fabrice Florin (WMF) (talk) 22:12, 12 June 2014 (UTC)

• I still believe that clicking the image should do something -- either show the original file or go to the traditional image page. 86.160.87.249 13:18, 13 June 2014 (UTC)

Fabrice, this improves the tool and improves the experience. The anon issues are high priority and that is appreciated. Is there a mechanism to note this in a retrospective other teams can access? The dismissal of the anon user community's needs was (guessing from the flames erupting on this page and others) a major blow to the project and likely to the WikiWorld as a whole. I'd love to see this avoided for future projects. There are still a lot of critical objections (especially around copyright as discussed on this page and the archives), but this set of features certainly made great strides. One other note: the images selected on your demo page brilliantly showcase the power of this tool. Good job on that! 159.53.174.144 15:55, 13 June 2014 (UTC) (same Kevin)

Yes, there will be a launch retrospective which is shared with other teams (well, all retrospectives are shared, but launch retrospectives tend to be read, too :), and doing beta testing with anonymous users + being prepared for implementing an anon optout are certainly some of the main take-home messages in my opinion. --Tgr (WMF) (talk) 07:28, 25 June 2014 (UTC)

Let go of coding the opt-out, this is very powerful fertilizer (a.k.a. a steaming bowl of crap) and should be opt-in only! It adds no useful functionality and makes Wikipedia harder to use. If I wanted useless and pretty, I'd look on Instagram, not Wikipedia.

This new viewer is obtrusive and poorly designed.

I use Wikipedia for personal and professional reasons more or less every day and I had no idea this feature was even in development until it suddenly popped up one day. The fact that this huge of a change appeared without any notice was already suspicious. After spending just a short time researching actual written feedback here and on other discussion sites, it's very clear that pretty much no one wants or enjoys this feature, and that its implementation is mostly annoying and disruptive. However, it is defended staunchly by a few dedicated people who are apparently involved with the project. I have seen incidental discussion about money and funding being wasted. It seems pretty obvious that someone needed a place to spend money, ended up with this terrible feature, and now needs to justify it with a couple poorly worded public surveys and by just pushing it into full implementation without any discussion about the possibility of scrapping the project. Hope I'm wrong and this disappears soon.

How do I disable Media Viewer on Commons?

There is no option to disable Media Viewer in the preferences on Wikimedia Commons. How can I do it? --Jonund (talk) 16:39, 13 June 2014 (UTC)

@Jonund: You should be able to find it here, untick the box in the "Files" section that says "Enable Media Viewer." Hope that helps. Keegan (WMF) (talk) 17:35, 13 June 2014 (UTC)

Unticking does not disable this stupid, no damn good, value-subtracted feature. USNorseman (talk) 00:50, 19 June 2014 (UTC)

New version: still horrible

"Try out these new features and let us know what you think." Still hate it. Completely. There is not a single good thing about the new media viewer. You're replacing a good, useful, basic thing, with an annoying, stupid, useless, over-designed, web-2.0-bullshit thing. OH YAY, ANOTHER SITE WHERE I NEED TO MOUSE OVER EVERYTHING AND CLICK RANDOMLY TO SEE WHAT HAPPENS FOR SOMETHING THAT SHOULD BE TOTALLY BASIC. This is a mountain of shit. Kill it with fire. BrianAshe (talk) 05:56, 24 June 2014 (UTC)

This is pretty well what I feel about it. I have not seen a convincing argument for doing it in the first place and when someone described it as "very professional", I thought, "Looks pretty amateurish to me!" LynwoodF (talk) 08:25, 24 June 2014 (UTC)

Description

I have some issues concerning the description. Normally, the description in Media Viewer consists of two lines whereas the first line is the caption from the article in wikipedia and the second line is the description from the description page on wikimedia commons. This is an example of an image used in the article de:Zervreilahorn, where everything works fine. But in the following cases, Media Viewer behaves different:

• if the image is used in the infobox, the caption from wikipedia is not shown (example)
• if the image is not from wikimedia commons, even the caption from the description site is not shown (example)
• if the image is used in a template, the caption from wikipedia is not shown (example)

--Capricorn4049 (talk) 18:04, 13 June 2014 (UTC)

@Capricorn4049: This is being fixed, see (multimedia/#513) Caption not shown for images which do not have |thumb| in their wikitext. For the issue in your second bullet point, see commons:Commons:MRD about how to mark up description templates so that they are understood by Media Viewer. --Tgr (WMF) (talk) 03:41, 16 June 2014 (UTC)

Problem with Lage Images

Tracked in Phabricator
Task T68657

Well, the only purpose why we have files like this one is because people would want to view parts of it by zooming in. Either I'm stupid, or it doenst work. Klicking on "View original file" ("Originaldatei anzeigen" in german) changes nothing. So good I understand URLs and can edit it to [1] but that certainly can do only 1% of wikipedia readers. --Dan-yell (talk) 18:08, 13 June 2014 (UTC)

@Dan-yell: For me, "View original file" links to the same URL you have given. If that works differently for you, can you describe in more detail? --Tgr (WMF) (talk) 02:17, 16 June 2014 (UTC) @Dan-yell: : Actually, this file is running into a bug, that is causing this behavior. I have filed it in bugzilla and it is linked to the top right of this topic. TheDJ (talk) 09:25, 16 June 2014 (UTC)

"Derivative versions not eligible"

Elsewhere on this talk page, someone linked to this page. There it says "Derivative versions, GFDL, License migration not eligible". This sounds as if the image is ineligible for three things: licence migration, GFDL and derivative versions. In other words, it sounds as if I can't make derivative works and that I can't use the image under the GNU Free Document Licence, implying (because of the derivative works issue) that the image is unfree. Please improve the wording.

Also, users who are not logged in are usually not shown hidden categories, but for some reason, the media viewer shows all hidden categories. How does the category choice work? The file appears in five categories: four hidden and one visible. The media viewer shows three of the four hidden categories but not the last hidden category and not the visible category. --Stefan2 (talk) 18:17, 13 June 2014 (UTC)

@Stefan2: These are categories, taken from the image page. Not sure what wording we could improve.

Categories are currently chosen in a rather dumb way, we just pick the first three returned by MediaWiki (I think these correspond to their order in the wikitext source, but I am not sure). Hidden/non-hidden is not taken into account since that information is not easy to access at the place where Media Viewer processes categories. --Tgr (WMF) (talk) 04:15, 16 June 2014 (UTC)

Tsunami of criticism

I can see tsunami of criticism of the whole idea of Media Viewer, but I can't see any reaction of authors of this idea. --Matrek (talk) 01:51, 14 June 2014 (UTC)

I think it's horrible

This new way of forcing users to view images in a media player seriously detracts from the usabilitu of Wikipedia. I click on an image for more information ABOUT THAT IMAGE, is a larger view and some meta info, NOT so that I can be taken away from my current page into an all-consuming app.

Please, please, please, can we have a GLOBAL opt-out of this new imposition FORNON REGISTERED USERS. Despite being a subject matter expert I stopped logging in and editing Wikipedia some time ago when various policies changed and made Wikipedia a less useful place to support. I know I'm not just a voice in the wilderness - a LOT of people seem to find this new 'feature' a disaster.

Please, let us have the simple old image viewer system back. Doing whizzy stuff 'because you can' is NOT a justification. — Preceding unsigned comment added by 92.40.248.66 (talk • contribs) 2014-06-14T07:40:48

Unfortunately there is no easy way to have global settings, not even for registered users, much less for anonymous visitors. --Tgr (WMF) (talk) 03:48, 16 June 2014 (UTC)

What do you mean by "no easy way"? With the Unified login, once users logs in one of the wikis, all other wikis also automatically recognize him/her. Is the addition of one more bit to that shared information exceptionally difficult? — 128.32.220.21 20:34, 16 June 2014 (UTC)

Yes. You can track the progress of global preferences at bug 14950 if you are interested. --Tgr (WMF) (talk) 21:29, 16 June 2014 (UTC)

I hate it

This "feature" adds nothing, but it does make Wikipedia harder to use, and MUCH more annoying.

Who asked for this garbage anyway? Certainly not I.

I hate it too, and was shocked to find that it's universally-enabled. No one asked ME if I wanted such a useless feature, something which farts-out a blob of a picture when I click on an embedded image - devoid of useful context, something I'd expect would appeal more to social media misfits high on Adderall, and wholly inappropriate for serious, registered (or even anonymous) contributors to a supposedly respectable online knowledge project. Harrrumppff!! Azx2 (talk) 01:48, 25 June 2014 (UTC)

Useless when looking at magnified webpages

I always view webpages with a degree of magnification to avoid eyestrain (i.e. I use "Ctrl+"). With the old system, I would click on a picture and go to a page which showed a larger picture, plus other available resolutions, plus associated info. The new viewer takes me to a picture which is the SAME size or even SMALLER (because the page I left was already enlarged), and with associated info obscured. Because of the magnification, if I scroll down to try and find metadata, it is all in unreadably giant letters. Pic in the new new viewer cannot be enlarged by Ctrl+. The whole experience is a HORRIBLE step backwards for Wikipedia, which I had assumed was run too intelligently to fall for the modern fad of making websites less usable for reasons of being "trendy". Please disable the disaster as soon as possible and return to the old system, which was far more informative, professional, and befitting an encyclopaedia!

I would argue that by using additional tools that change the presentation of the page (your magnification tool), the weight is on you to disable the feature instead of require that it be disabled for everyone (surely if you're using magnification all the time, you've found that a great deal of sites don't handle it well). Bear in mind that you can always disable the feature for the old one if the tools you use don't play nicely with MV.

The image in the MV should also definitely not be smaller. I believe that you're confusing physical size and resolution. The higher resolution image that MV displays should show a great deal of quality that is not in the thumbnails (even with magnification).

Regarding the metadata being large, I'm not sure exactly what you're expecting. I attempted to zoom in several times and while the text got bigger (as expected), it was always readable. With that said, you have a good point that the image cannot be zoomed in on (in fact, zooming makes the image smaller). In my opinion, a one-click "show real size" feature needs to be implemented, and this full-sized image should play nicely with magnification tools.

As a workaround, you can click the "view original file" icon in the bottom (the thing that looks like an icon for a Windows photo viewer), and that plain image should be supported by browser zooming features. Hofmic (talk) 18:22, 17 June 2014 (UTC)

In answer - no, I'm talking about physical size on the screen, not resolution. As for the metadata text, it is magnified much more than the text on the wikipedia page I navigated from.

Media Viewer Sucks

How do I turn it off? Wee Curry Monster (talk) 21:34, 14 June 2014 (UTC)

You can disable it in your preferences. Unfortunately MediaWiki does not currently support global preferences, so it depends on which wiki you would like to turn it off. Click on the "Preferences" link you see at the top of the site, go to Appearance, and untick "Enable Media Viewer" in the "Files" section. This is a quick link for the English Wikipedia, for example. Keegan (WMF) (talk) 21:57, 14 June 2014 (UTC)

Why we have to disable feature on our side? Just because group of few MV authors want to force that idea to be default feature? You guys should disable whole idea of MV --Matrek (talk) 04:39, 17 June 2014 (UTC)

For the same reasons that you'd have to disable any feature if you don't like it. Software change happens. At least MW provided the ability to disable the feature natively (more than can be said about, say, how Microsoft handled the changes to the start menu, which still require third party software to revert). And to be fair, I wouldn't say that MV is all bad (although I do think it was rushed without enough acceptance testing). Hofmic (talk) 18:05, 17 June 2014 (UTC)

Microsoft is a privately owned commercial company, handling its own business risk. Wikimedia Commons is not a private enterprise, at least as long, as long Wikimedia Foundation asks for our donations, and for our contributions. --Matrek (talk) 04:05, 22 June 2014 (UTC)

Thanks for explanation :)--Shanghainese.ua (talk) 09:10, 19 June 2014 (UTC)

No, I can't disable it. Those directions don't work for me; not without creating an account, logging in, and staying logged in (not an option). When I click/tap on an image (or preferably right-click but that's not an option on a touchscreen), I expect to see info about the image and any other resolutions. I'm not interested in a slideshow of all the images in the article. 72.145.224.180 19:34, 20 June 2014 (UTC)

You can disable it by bringing up the information panel (just scroll down or tap at the little down arrow at the bottom) and selecting the option at the very bottom. --Tgr (WMF) (talk) 19:43, 20 June 2014 (UTC)

Pointless Change and a Distraction

This is a case of a change of feature for the sake of changing a feature. The supposed benefits of this "media viewer" are "it looks different."

I specified in the survey the points why I feel the media viewer fails in doing anything useful, and I won't go into all of them here, but I feel so strongly about this that I actually made an account so I could add my objection to this discussion. I apologize in advance if I am not doing this right since I haven't done this before.

Just like so many websites have in the past 4 years, some person in charge of web design says "Hey nobody has changed anything with how this part of the website is done in ages... people will get bored!" So they come up with a completely superficial idea to change things around, make it look "new" and "exciting." The only problem is that it almost always reduces functionality and adds no real benefit, because it's all about how it 'looks' not what it does. This is exactly the same problem, now afflicting Wikipedia.

To the web designer whose smartypants idea this is: I don't want an "immersive" experience with the images, I am looking at an image in context with the article it's attached to. All I want is perhaps a slightly larger image, or to view the details such as copyright. An "Immersive" image is a distraction and a complication in my trying to absorb the information in the article. I'm not viewing a gallery of images like on Flickr, I am looking at an image that's connected to an article.

So no, I want nothing to do with this. I want to disable this "Media Viewer" nonsense permanently and return to the simple but efficient layout that I enjoyed before.

I would welcome any new layout that adds means of accessing more information about something. I welcome change that adds more to the content without removing features, or needlessly complicating the experience. This adds nothing except superficial scripting, removes features, and makes it more complicated to use.

Since it's clear that there is a bias towards accepting this new "Media Viewer" by the administration of Wikipedia, and as such this entire thread of objections is likely to be ignored, and this foolish idea adopted anyway... I will now proceed to find a way to disable this feature on my end of things. Ikaruseijin 23:12, 14 June 2014 (UTC)

It's a big shit

Sorry, but it's a big shit ! Rgds user:Tonton Bernardo

Author not clear

I like to use images from wikimedia resorces. But in this new viewer I often do not find the author of an image. Therefore this new viewer it's a step back. I do not like it. Please take it away and let it as it was before. Thank you.

Bogus survey

The people who are pushing this unusable new "feature" onto wikipedia users are hiding behind the results of a worthless survey. The survey results would only be meaningful if they could be compared to a survey conducted before rollout of the new viewer, asking people if they were satisfied with the results of clicking on a picture. I strongly suspect that most users were satisfied with the old system, or more tellingly, likely very few users were dissatisfied. After all, clicking on a picture under the old system did everything any user would require, whether a casual user or advanced. I very much doubt that there was any dissatisfaction amongst the user base, and so there was no problem which needed to be addressed. Reducing functionality for the sake of being "cool" is pretty lame for a encyclopaedia, and hiding behind the survey is reprehensible. Listen to the frequent and advanced users and permanently remove the new picture viewer.

I still dont know who was asked to participate in that survey. Maybe mobile users, whos preferences and taste were formed by Instagram or something, feel more comfortable with that new lack of usefulness. Alexpl (talk) 12:11, 16 June 2014 (UTC)

One more person who hates Media Viewer

I only found out about Media Viewer when I clicked on an image and was surprised by this obtrusive and annoying full-screen popup that appeared. I use wikipedia all the time, and I only do edits on rare occasions. This "improved" feature is just a piece of garbage. The regular File: page was perfect and simple, and it provided everything that any user, casual or what ever, would need. Blacking out the rest of the screen and article is just dumb. If the Media Viewer is just going to cover up the entire page and take over everything, I'd rather just go to the File: page. And I'd rather go to the File: page even if the Media Viewer gets a change to its black background and full screen popup, because it's not necessary and just ruins the flow of the wiki. It also just looks horrible, so if you were trying to make something that looks cool and new, you failed. And besides, why are you trying to do that? This is a wiki encyclopedia, plain and simple functionality should be it's main goal. Get rid of this horrible downgrade and fire the moron(s) who implemented it.

-- Someone Who Hates Media Viewer

+1,000,000 .... ⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖⇖THIS!!!! Azx2 (talk) 02:08, 25 June 2014 (UTC)

I speak only a few English, so I'll make it as short as possible: BULLSHIT!

Country roads, take me home!

And another...

Yes, I've turned it off - for myself anyway. I don't have the power to turn it off generally. As I commented at en-wiki, utter crap. A solution without a problem to justify it. Presumably a similarity to something found in social media, where I find the image viewing to be usually appalling anyway.Interesting that the 'survey' was so much in favour, but the proportion of happy little bunnies on this page seems vastly different. When I click on an image, I want to see the image and possibly magnify it, and sometimes to read the data. With this, magnifying becomes complicated and not obvious, and the data on its silly little sliding thing has become almost unreadable - except perhaps for those who sit nine inches from the screen and are short-sighted anyway. You asked for feedback. You're getting feedback. Will notice be taken of it? Doubtful. Peridon (talk) 13:50, 16 June 2014 (UTC)

Major flaws still exist

After all that's been said and done about improvements to media viewer, it still has its major flaws:

• MV doesn't allow the user to readily see an image in its max resolution by simply clicking a second time. Instead, users have to click on an icon in the lower right, and you have to hover over it to see what its for, where the little pop-up message says "More details on a Wikimedia Commons", which doesn't even hint that there is access to an image's max resolution. This will be ignored by most viewers, so I think it's safe to assume that the quality of all the hi-res images (e.g.'Today's featured picture', 'Picture of the Day', etc) will be denied to the casual users we were told are the first priority by the few individuals who have pushed MV into its default existence.
• There is no readily available way to disable the viewer, still, and in fact there is not even a hint of how to do so for the average reader and users with limited experience. -- Gwillhickers (talk) 16:12, 16 June 2014 (UTC)

Contrary to the approval rating we were told about MV, that it's "a useful tool" (a "tool"?), it's rather clear that it is not wanted here at English Wikipedia. Had there been a list of features (and lack thereof) presented in the original approval survey compared to those of the standard viewing system, I think we can assume most rational adults would have said, 'don't bother'. Instead they were presented a gallery of images and told to view them with MV where the naive user was mesmerized by the slide show feature as they skipped along from one image to the next. No doubt the "approval" is based on this feature alone, simply because it was (and still is) its only feature. Disappointed. -- Gwillhickers (talk) 16:12, 16 June 2014 (UTC)

@Gwillhickers: : You can one-click the mountain icon in the bottom left right _{sips morning coffee} corner to go straight to the full resolution of the image; you don't need to go to Commons. I'm not sure it's 100% how you would have it implemented but I hope it'll work for you. As for one-click disable, that is now live right here on MediaWiki and is going out to Wikimedia Commons tomorrow, then it will be backported to all the other wikis. This fix took an extra bit of testing to make sure it worked properly. Hope that helps :/ Keegan (WMF) (talk) 16:51, 16 June 2014 (UTC)

@Keegan (WMF): . Ahhgg!! ... yes, you're right. Please accept my apologies on that note. However, it might be helpful to give the viewers something more than an ambiguous icon (whatever happened to labels? e.g.'Max-Res') After all, I missed it, no doubt others will, esp if they don't know about max resolutions in the first place. I would recommend 'something' that indicates that there's a provision for viewing an image's max resolution besides the cryptic icon in the lower right. Also, an indication of the image's resolution would be nice. (e.g. 1024 x 2036) -- One last bit of feed back: When I first encountered media viewer it was almost like running into a wall. A very abrupt visual change. It looked as if I had left Wikipedia altogether. Can you make the viewer look like we're still in the world of Wikipedia? I would recommend a Wiki' view first before going to 'the dark zone' with the black background and the completely different look. Hopefully the instant disable feature you say is coming along will not be equally as fuzzy to discern. -- 107.215.12.158 19:48, 16 June 2014 (UTC)

@ Keegan - why you guys are forcing this commonly unwanted format? Can't you really see, that no-one wants it? That the only people wanting MV are it's authors? --Matrek (talk) 04:34, 17 June 2014 (UTC)

Please show the image annotations

Hi!

I have to say that, contrary to most commenters, I actually like this media viewer. Browsing through an article's images is now really fast and enjoyable.

However, for annotated images, it would be really nice if the viewer displayed the annotations. Right now, the annotations are two clicks away from the page (open the viewer, then click on "More details on Wikimedia Commons"). Not really worse than before on English Wikipedia, however, in the French Wikipedia it is worse, as the commons page used to be at only one click distance from the Wikipedia page.

Example: in an "encyclopedic" context, the image https://en.wikipedia.org/wiki/Nikon_FE#mediaviewer/File:Nikon_FE_top_view.jpg would really be more useful with the annotations seen in commons:File:Nikon_FE_top_view.jpg

Regards,

Edit: a bonus suggestion: If an annotation is available in several languages, and the current Wikipedia language is among them, then only display the annotation in that language. E.g., when I click on the example image above from en.wikipedia.org, I would like to see the annotations in English. When I click on the same image from fr.wikipedia.org, I would like to see them in French.

— Edgar.bonet (talk) 16:31, 16 June 2014 (UTC)

Thanks for the feedback, Edgar.bonet. Annotations have been pointed out by others as well, and Media Viewer should be able to support them in the future. There's interface interaction complexities in making annotations work across platforms. I too look forward to the support. Keegan (WMF) (talk) 20:40, 16 June 2014 (UTC)

Please, please don't force this "feature" on us!

All the other criticisms people have mentioned on this page are valid. Additionally, the media viewer is highly buggy and literally unusable on mobile devices running the desktop version of Wikipedia. Please restore the older, highly functional image pages as the default way to view images because not everybody has a Wikipedia account and access to a preferences menu! 2601:8:9100:7B1:4CF8:961F:C99C:5099 17:59, 16 June 2014 (UTC)

Candid question: who is in charge on this?

I have a candid (albeit not malicious) question: who is in charge on this? Who decides if, yes, or no, the new Media Viewer becomes the new standard? I'm used at Commons and English Wikipedia to reaching decisions by consensus. Doesn't seem to be the case on this matter, as this particular decison is being taken against a strong opposition of the users! -- Alvesgaspar (talk) 19:34, 16 June 2014 (UTC)

• Nobody knows or cares? Hard to believe! -- Alvesgaspar (talk) 19:57, 17 June 2014 (UTC)

Mr. Florin from Wikimedia is in charge as can be noted from his profile. It's part of the 'Multimedia Vision 2016'. Note: The opposition comes mainly from intermediate users like you and not from the 'silent majority' of potential Wikipedia beginners. Therefore, the decision in favor of the Viewer is 'consensus'. More precise: A consensus between prospective customers of the Wikimedia Foundation and its fleet of technical staff to create tons of annoying, but immersive scripts (like the keyboard that keeps popping up in the editor window at every keystroke) rather than keeping the technical side of Wikipedia understandable as it used to be. That's not profitable. But that's the way it goes, Alvesgaspar. Seems like you and your knowledge become obsolete here. Make room for beginners and professionals.

• This kind of arrogance is not acceptable, especially when addressed to a volunteer editor, and makes me re-evaluate my long collaboration in the project. Alvesgaspar (talk) 11:49, 18 June 2014 (UTC)

Alvesgaspar: For the sake of clarity, the above message was posted by the anon 92.201.117.152 (talk · contribs). Whatever the merits of their (obviously negative) opinion of MediaViewer, this is not a message from the WMF team. As much as one can disagree with them, to my knowledge neither Fabrice nor anyone on his team has ever displayed such arrogance towards community members (in which case I would also be outraged of course :). Hope this clarifies the situation. Jean-Fred (talk) 13:26, 18 June 2014 (UTC)

• It does, thank you. I was fooled by the scarcastic tone of the anonymous user and wrongly assumed that he was part of the WMF team. My fault, sorry. However, my initial doubts about the legitimacy of the process still hold. Alvesgaspar (talk) 13:32, 18 June 2014 (UTC)

• Hello Alvesgaspar, and thanks for your question. The ultimate decision-maker on whether or not to keep Media Viewer enabled by default is Lila Tretikov, Wikimedia Foundation's Executive Director. On a day-to-day basis, I am in charge of this project as its product manager, in consultation with the multimedia team, and taking into account quantitative measures and feedback from our users. Note that we strive to take all viewpoints in consideration when making these types of feature decisions: the editor community, the readers we all serve and the developers who are most familiar with these features. All those perspectives are considered regularly, through a variety of channels, such as this one. Fabrice Florin (WMF) (talk) 15:30, 18 June 2014 (UTC)

Why does this still exist?!

Last time I was polite. This time I won't be. You're still attacking all wiki users with this crap's continued existence, and now I'm sick of being polite with this garbage shoved in my face on a daily basis.

I'm doing something SIMPLE. I'm reading an article, and want to look at the pictures, sometimes accessing information on them. Somehow you've managed to make this a problem! How the hell do you make something simple into a problem?! Why the bloody hell is this garbage still live? Doing basic tasks now takes twenty-thirty times as long - twice-thrice as many steps, and each takes ten times as long to load!

This garbage DOES NOT OFFER EVEN A SINGLE ADVANTAGE OVER THE OLD INTERFACE IN ANY WAY. None, at all, whatsoever. There is absolutely NO REASON FOR IT TO EXIST.

Old interface:

• Pros:
  • Quick to load.
  • Easy selection of image size.
  • Lets me choose the tradeoff between detail and download time.
  • Easy access to image information, such as uploader and pages containing, loaded instantly with the rest of the page.
  • Image loading status, pan, zoom, etc provided by the browser, working quickly and correctly.
  • Properly separates content and presentation.
  • Integrates perfectly with browser's navigation, because the browser WORKS.
  • Lets me see both a small-size image and the description at once.
  • Had clear text links, works well for everyone.
• Cons:
  • ????

New interface:

• Pros:
  • ???
• Cons:
  • Slow as fuck. Seriously. Garbage like this makes me want to turn off javascript permanently.
  • No access to select image size. Accessing the original image takes a half dozen clicks, every one of which is slow as fuck. And none of the clicks even work until after the rest of the slow-as-fuck crap finishes loading.
  • No ability to pick whether I want to see lots of detail, or want to see it soon.
  • Slow access to image information. First you have to wait for it to load (which is slow as fuck), then you have to click to access it... which is slow as fuck. How the fuck do you make simply displaying more info slow? Does your javascript run loops counting to a billion for the hell of it?

    (EDIT: Gah! It actually fucking DOES! (in effect, at least) The god damn slow as fuck appearance of the info is INTENTIONAL! Someone actually WROTE CODE TO MAKE IT FUCKING TAKE LONGER! This goes beyond smoking crack and well into PCP territory!)

  • Ugly, huge, wasteful, slow as fuck image loading status bar, no pan or zoom. And, of course, no progressive loading - you have to sit there doing nothing until the entire image loads, rather than being able to see parts of it as it loads.
  • Combines content and presentation, doing a piss-poor job of it, duplicating built-in browser features, worse.
  • Viewing an image causes THREE (count them, THREE!) useless URLs to end up in the browser's history, for every single image you view. This means you might need to click "back" dozens of times to return to the last page you were reading - and the ability to quickly navigate pages is one of the things that makes wikis nice.
  • Can't see both the whole image, in any size, and the text at once
  • Uses ugly, large, cryptic icons for navigation, giving people no idea what they do, probably breaking it for people with poor vision - obviously they don't need access to images, right? (And it breaks if you use any zoom feature, too!)

And, last but most definitely not least, even if all of the above were somehow magically fixed, this simply isn't how I (or, judging from the comments, just about anyone else) want to interact with images. Functionality issues aside, it's just not what anyone wants. There is no fixing this. People want to interact with images in a way they find pleasant, and this is not, never can be, and never will be it.

This "feature" NEEDS TO DIE. I'm sure someone spent a lot of effort on it (after all, duplicating existing browser functionality can't be easy!), but it is entirely ill-conceived and ill-executed, and should not exist. It provides no benefits, gets in the way, goes against every concept of good web design, and generally should be stuck firmly in the bit bucket where it belongs. 74.207.250.159 04:38, 17 June 2014 (UTC)

Sucks

I just discovered this horrible feature. What a bad idea, and badly implemented. Seriously, just roll back the code-base. It sucks.

Could be a useful feature, but needs some work

Personally, I have mixed opinions. I can see how it would be useful (quick, appropriate sized preview of an image without having to go to the image page), but the UI is very weak. There's tons of ambiguous buttons that don't even have tooltips. I don't feel icons are always the best idea. Perhaps including labels on the icons (or using just labels) would be clearer. When an image is still loading, the navigation arrows are sometimes not shown.

It was difficult to find out how to get different sizes of the image. Not to mention they're hidden behind multiple clicks, now. When licensing details is large, it's partially hidden and you have to click to show it, and even then nest scrollbars.

A way to view large images easily is sorely needed. Some images need to be viewed in their full resolution and panned to be readable. Perhaps for sufficiently large images, we could click on the image to switch to a fullsized, pan-able version?

I'd also like to see a one-click button accessible on the media viewer and file pages for toggling the viewer on and off (presumably saving to the account if the user is logged in or local storage for anon users).

With that said, performance for loading an image of an optimal size for browsing is something I like. But at the moment (and more so when first released), it seems like a feature that is imperfect. Hofmic (talk) 17:54, 17 June 2014 (UTC)

Hello Hofmic: Most of your issues are being addressed in a release of Media Viewer that is now live here on MediaWiki and also on WIkimedia Commons. There is now a one-click disable/enable for registered users as well as anons found by pulling up the fold. You can access the large file size by clicking on the mountain icon in the bottom right corner. Tooltips will be available as well. You'll find most of these changes being released to the English Wikipedia tomorrow (Thursday). I hope that help you find Media Viewer a more complete product. Keegan (WMF) (talk) 16:55, 18 June 2014 (UTC)

As of the time signature shown, a disable feature for anons is not live on Commons. 159.53.174.143 22:58, 18 June 2014 (UTC)(Kevin)

We are storing the opt-out flag in localStorage. The option will only appear if your browser and your privacy settings allow for that. The feature was enabled on Commons a day ago. --Tgr (WMF) (talk) 00:09, 19 June 2014 (UTC)

Improvement

Thanks. Better now with "enlarge-button", but it could be more obvious.--Milseburg (talk) 17:56, 17 June 2014 (UTC)

I agree, it could be more obvious. "Prominent" (like it is promoted) is something different. I also have very mixed feelings about this Media Viewer. --Miss-Sophie (talk) 14:36, 18 June 2014 (UTC)

Clicking image

Why does clicking the image still not take you to the full resolution version? 86.179.5.128 02:17, 18 June 2014 (UTC)

Hi there. The action that happens when you click on the image itself is being "reserved," so-to-speak, for future development. The next version of Media Viewer will have full zoom-and-pan options so there is an option there; Media Viewer should also eventually support annotations in files, and clicking on the image might be needed for that. Those are just two of several possible use cases. Sorry that clicking on the image is not as intuitive as it was based on the old way of getting to full resolution :/ Keegan (WMF) (talk) 16:09, 19 June 2014 (UTC)

GREAT improvement! Almost a fifth as good as if this malware never existed.

Pictures like this Mappe Of The Knowne Worlde need to be handled by the browser, with no layer hiding the page source in between.

Ceterum censeo: Media Viewer esse delendam. Tatzelbrumm (talk) 06:42, 18 June 2014 (UTC)

This is the best section on this entire page. ツ ツ I hereby award the best comment ribbon. Fylbecatulous (talk) 14:43, 26 June 2014 (UTC)

Where's quickie for the old image page?

I would have stuck it out if the help page had explained how to easily click through to what I had before, the plain old image upload page. I couldn't find that explained in under a minute or two, so I switched it off in my user preferences. As a general rule, I hardly ever like improvements that pretend that the ugly under-the-hood predecessor doesn't exist (or confine it's mention to an obscure footnote). Nor am I willing to wade through the documentation carefully until it's proven the feature and I can successfully co-exist. This Catch 22 scenario often makes me a late adopter. 154.20.45.238 07:09, 18 June 2014 (UTC)

What is the green hammer thing for?

What is the green hammer thing for that you get to by clicking on "use this image"? Also why doesn't the "preview in browser" link underneath it work. This pimple on Wikipedia just seems to get worse. Please cut your losses and just get rid of it!

Can you give a link to the case for which it is not working ? Because this option always works for me. Also please detail you browser and it's version, perhaps it is a browser specific problem. TheDJ (talk) 14:15, 18 June 2014 (UTC)

Cut your losses, guys

It must be pretty obvious to you all that this project has been a miserable failure. I have disabled it wherever I find it popping up. It does nothing for me, but it irritates me greatly. Why not just abandon it? If there is some problem you think it solves, design a solution from scratch. LynwoodF (talk) 16:25, 18 June 2014 (UTC)

Rename link "expanded view" as "show in Media Viewer" and add logo or title

I write the following under the pre-condition, that the reader (imagine an IP-user) is on the Wikimedia Commons page of a file, looking around for the various options, links etc.:

The link description on the button, which says "expanded view", is misleading. It gives the impression of either getting more information about the image than already are on the Commons page or - more likely - of immediately getting a larger version/the original resolution of this picture. Both isn't true (you only get the original file after a seond click within the Viewer, something that can much more easily be achieved by simply once clicking on the image on the Commons page, where the user is at this moment anyway).

I would prefer to call it by its name and write on the button "Show in/with Media Viewer". In additon I would like a little logo/title (if you partly copy Flickr, why not this element, too?) reading "Media Viewer" in the left upper corner, that tells the reader which tool he is using and enables him to draw a connection to the suggested button inscription and every Wiki (help) text that mentions Media Viewer. The small impressum at the end of the page ("About Media Viewer") escapes notice too easily. --Miss-Sophie (talk) 09:49, 19 June 2014 (UTC)

Lessons Unlearned

The latest version released to MediaWiki addresses many of the most critical concerns about the tool itself. I think the tool is nearing the point that it is a viable, shippable product. My question remains: How and when did you reach consensus to make the late-May version the universal default for all Wikis?

Did you, as Sven Manguard strongly recommended on 23 Nov 2013, consult any substantial portion of the Commons community? Why were the warnings of Vive la Rosière (22 Nov 2013) dismissed or deferred? When Pete F warned on 16 Feb that "enabling the Media Viewer by default will [likely] be rejected by the Wikimedia community," his narrow and immediate concerns were addressed but why was the larger point, that different workflow and usage patterns made MV a dangerous change that might be (and proved to be) incredibly disruptive and unpopular?

I don't hate the tool. I think the team did phenomenal work with the best interest of the WikiWorld at heart. I don't oppose change on first principle (far from it; I am an agile transformation specialist and change is both my life and my career). I just think that this implementation event is a massive red flag (a) that our consensus process is seriously broken, (b) that repeated, often-strident warnings from highly-respected editors were ignored and (c) that we have forgotten the lessons of history (Wikipedia Main Page Transformation, for instance) which taught us never, ever, ever to make fundamental changes to the user experience without exhaustive testing with the widest possible range of users.

I applaud the team and their work. It is an impressive tool for a certain type of user, showcasing first-rate code quality and a clean and highly-professional interface. I am terrified, however, that this is a sign of a sea change in our attitudes toward the user community. Editorship, collaboration and trust have eroded steadily since over the past six years. Is it inappropriate for us to request expect demand that project teams "first do not harm"? </soapbox> 159.53.110.143 01:04, 19 June 2014 (UTC) (Kevin)

Kevin, I'm glad my comments didn't go unnoticed. I continue to believe that there were major problems with both the process and the final product, and that the end result is a step backward, not a step forward. The two things that concern me the most are (1) the Media Viewer does a worse job of reporting information about personality rights, not better; and (2) end users will be less likely to see a path toward becoming contributors, when we should try to make them more likely to do so. Anyway, here is a link to the comment you reference: /Archive01#Towards enabling the Media Viewer by default -Pete F (talk) 04:04, 25 June 2014 (UTC)

@Peteforsyth: end users will be less likely to see a path toward becoming contributors - this sounds like it could be turned into a testable hypothesis. Basically you are predicting that there is a significant number of a) useful image edits or b) first edits after registration in the File: namespaces, and enabling MediaViewer causes these to drop. Does that sound correct? --Tgr (WMF) (talk) 07:35, 25 June 2014 (UTC)

@Tgr (WMF):

• Yes, it's a (theoretically) testable hypothesis.
• Constructing an effective test would be difficult and time consuming, mainly because the percentage of people starting to edit after viewing a file is tiny to begin with.
• Good grief -- now is when we start talking about testing stuff like this??!! -Pete F (talk) 14:28, 25 June 2014 (UTC)

Well if the number of people starting their career as Wikimedians on a file page is tiny (that would be my expectation as well), then the negative effect MediaViewer can have on them, if it exists, would be also tiny. So maybe your concerns are overstated? --Tgr (WMF) (talk) 04:46, 26 June 2014 (UTC)

Bug: when full screen mode is shut down, my browser window goes out of full screen mode, too

Tracked in Phabricator
Task T68854

I use my Firefox browser on a Mac and usually in full screen mode. Now I find, that when I end the full screen mode for an image in Media Viewer, my browser window goes from full screen mode to a smaller window. The browser window should stay full screen sized, only Media Viewer should return to normal size. --Miss-Sophie (talk) 10:28, 19 June 2014 (UTC)

Reproduced and confirmed. I'll file the bug. Good catch, Miss-Sophie. Keegan (WMF) (talk) 17:08, 19 June 2014 (UTC)

Add a link in Wikipedia articles that leads directly to the file description page (avoiding Media Viewer)

There are many users (probably many with an account but also IPs without), that want to go directly to the file description page (on Commons or a local Wikipedia) for an image they see within a Wikipedia article. They don't want to go to Media Viewer first to then click on the Wikimedia Commons link there. So please give them the opportunity to do so, without the need to have an account and to be looged in, which is the only way at the moment to avoid Media Viwer by deactivating it in one's user settings.

My suggestion: There is this little button in the right lower corner of images within a Wikipedia article (an exception are images in infoboxes, maybe other forms I'm not aware of right now, too), the one that says "enlarge" when you go over it with a mouse. This button does the same like clicking on the image itself and is, I assume, hardly used, because clicking on the image is a much more direct way. Clicking on the image and clicking on the button both lead you to Media Viewer now. Why not give this button a new function and let it take the user to the description page (Commons page)? Give the button a new layout/symbol for clarification and invent something to also add this button to images within info boxes. --Miss-Sophie (talk) 11:18, 19 June 2014 (UTC)

I now have read, that one can also disable Media Viewer as an IP, by clicking a link in Media Viewer at the bottom, which leads to a file being saved on the IP's computer. I suppose this is a cookie? In the user settings of my browser I made Firefox always delete all cookies, once I have ended the application, because of security reasons. Since deleting cookies from time to time makes the Media Viewer cookie useless, so you would have to repeatedly disable Media Viewer (annoying), I still suggest the direct link to the description page. --Miss-Sophie (talk) 00:24, 20 June 2014 (UTC)

Actually the "file" that gets saved is an entry in the browser's localStorage object, which is not necessarily supported on all browsers. We don't track this at all, in fact, the value doesn't get sent to the server at all. You can turn off the viewer, as an IP, without any record on the server. Deleting your local tracking information may or may not delete the localStorage - check your settings for that :) --MarkTraceur (talk) 04:10, 20 June 2014 (UTC)

One reason more to think about my suggestion, if this file storage is not supported by every browser and might or might not work after deleting of local tracking information. Give people, depending on the role they are using Wikipedia in at a certain time (learner, photo viewer, editor, ...), the possibility to chose, if they need Media Viewer right now or the original file description page. From case to case, picture to picture, right there at the roots of chosing an image within a Wikipedia article for closer examination, not in general by deactivating and undeactivating the application. Some interesting thoughts also by others below, like the sidebar thing, though I would prefer to have the option for every single image. --Miss-Sophie (talk) 09:01, 20 June 2014 (UTC)

We have discussed that and similar approaches (display a small icon with a direct link on hover, add an option to the right-click menu). The main concern is the lack of discoverability: browsing help pages would be pretty much the only way of learning of such a feature. --Tgr (WMF) (talk) 22:12, 20 June 2014 (UTC)

Thats your own fault. You guys wanted this smartphone-style design, which doesnt ask people to participate or contribute but only to consume. So everything besides the compressed image is hard to discover - exept for those useless navigation arrows and the even more useless fullscreen mode of course. Alexpl (talk) 12:24, 21 June 2014 (UTC)

I imagine it must be easy to redirect the link from the little icon in thumbnails, which already exists, to the file description page (like it was before) and to give it a new label instead of "enlarge" plus a new design. Seemingly there weren't any worries about a lack of discoverability for the existing icon, as it is there, and also I had no problem with noticeing it on my own. You would then have to create the possibility to apply the same icon to images in infoboxes and galleries. I can't judge, how difficult the realization of the latter is. But you could start with the first change at least, which already would affect the largest part of images within articles. --Miss-Sophie (talk) 23:17, 22 June 2014 (UTC)

I would like the button/toggle functionality to view the file description with a one-click, so that I can enjoy Media Viewer as a general reader, then with one click convert the page disabling Media Viewer to check sourcing as an editor. In this way it would be a default feature, as I check through subsidiary/related articles for additional information as a reader and consistency as an editor. Then each time I returned to a page, I could easily go to any image and disable Media View to source check or better view charts or maps, especially those with great detail.

That's my "druthers", I don't think it should be either-or, I'd like it to be both available at a click on an image at each image, my choice. Otherwise, maybe a disabling opt out for the entire article in the "Tools" list on the sidebar. TheVirginiaHistorian (talk) 07:27, 20 June 2014 (UTC)

Toggle for every single image in an article to activate/deactivate Media Viewer for the click on the image

Another, I think better, idea based on what TheVirginiaHistorian wrote: I like the idea of a toggle. But it should be a toggle for every separate image in an article, not just for the whole page (since I understand, that is what he/she suggested). A toggle, that is in thumbnails placed instead of the icon "enlarge" and looks like the icon on Wikimedia Commons for the "expanded view" link (the picture with a landscape). This toggle provokes, that Media Viewer is either active for this certain image or not, with "active" meaning a one click on the image opens the file in Media Viewer and "not active" meaning a one click on the image opens the file description (Commons) page. The colour of the icon/toggle indicates, whether the Viewer is on or off (for example it is light blue, when it is active and grey, when it is not). Make it possible to apply the toggle/icon to images in infoboxes and galleries. One has to determine though, what should be the default setting when loading a page. I think, considering it is an encoclypedia and you can find more information on the description page, the default setting should be the not active icon. But every user should be able to change this in his user settings. So if somebody wants Media Viewer to be active / the toogle to be on as a standard, he can change this. Maybe make this setting also possible for IPs, like now with the stored file for Media Viewer. Plus place a toggler with the same icon at the beginning of the article page or in the sidebar tools, which allows to deactivate/activate Media Viewer for all images at once. What do you think, is this possible? --Miss-Sophie (talk) 13:16, 23 June 2014 (UTC)

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 [2] and [3], 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.

Still doesn't play friendly with mobile

The media viewer is still displaying all kinds of functionality-breaking bugs when I browse Wikipedia on Dolphin Browser for Android--I use the desktop rather than the mobile or tablet user agent. Zooming in or out causes the image and metadata to change size unpredictably and cover each other, most of the time making essential buttons inaccessable. This also happens frequently when simply scrolling around. Also, the double arrow button in the upper right hand corner of images is nonfunctional.

I have a lot of other gripes with the media viewer, but I'll keep this edit focused on a few specific bugs. Thanks for finally allowing unregistered users to opt out! 75.165.107.92 03:27, 20 July 2014 (UTC)

Back Button is broken

If you open an image and then use the back button all you get is black, at least in the current Firefox. All of the functionality that was just obvious on the old page is now hidden, fading in and out and generally making a nuisance of itself. Thanks for being part of the movement to destroy the web by appifying everything.

Honestly, there have been a lot of articles about what's wrong with Wikipedia over the last years; not a single one complained about the media viewer. Great job guys... 93.104.182.210 12:04, 13 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)

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)

In answer to your question about global preferences, Kai Burghardt, these can't be enabled or designed until there is full SUL of all accounts. That won't happen for a while; it's part of the technical debt that is slowly being worked down. I understand that discussions on how to implement global SUL will be starting fairly soon, and once the principles of who gets "custody" of usernames when there's a dispute is resolved, it will take several months to get all of the accounts aligned. Then it will be time to develop the application(s) for global preferences - though that will take some working out too. (Being able to have different preferences per site will have to be built in, too.) Best guess would be 2-3 years out before we get this. Risker (talk) 08:26, 13 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: [4] and [5] --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)

All solid and valid points! 75.165.107.92 03:13, 20 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)

Annotations are a customization made by the Commons community on top of the software. The MediaWiki developers do not support it. If you want it to be compatible with MMV, you will have to ask the volunteer community members to add support to it for MMV. TheDJ (talk) 13:03, 15 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)

me three! fck this sh!t! Media Viewer is crap and WMF's abominable implementation of it, their disregard for enWP consensus and bullying of admins has cost them my support. C-ya! Jdanek007 (talk) 07:25, 18 July 2014 (UTC)

me four! Bothered me enough that I finally landed up here just to complain. Get rid of this ASAP, please.

me five! This is absolutely awful software and I have grave reservations about Wikipedia's leadership the longer this thing sticks around.

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 the options for using a file, with the exception of maybe the "share this link" option, on the file description page. Make the "Use this file" options in MV for the cases of embedding and downloading links to the file description page (opening in a new tab). The use of a file, especially as soon as it means dealing with licenses and conditions for using a downloaded image or embedding an image on a webpage, 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. The "share this link" in MV doesn't lead to missuse, though (as far as I can tell), and maybe somebody wants to link to the image (or the slideshow) presented in Media Viewer, so I'm okay with having the option for it there. For embedding the file on a webpage outside Wiki, a link to the image in Media Viewer might also sometimes be wanted, but this option could be included in the "embed" tool on the file description page. If one thinks about it, sharing a link is not using a file (its image content) anyway, so I think two separated buttons could be a possibility: a) share this link; b) use this file (for downloading and embedding), with b) linking to the file description page. 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 file description page:

• at the top of or next to an image a link that leads to a page with information about how to reuse a file from Wiki in general, in different languages like [6] or [7].
• templates with summarized information about the license conditions and important restrictions for the use in certain countries like template:Cc-by-sa-3.0 or template:PD-US-no notice. 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 their respective languages (in the license section). The "View terms" link in MV often doesn't help, since MV does not show a license template unless it is included in the permission parameter of template:information on the Commons page, which is not always the case. The documentation for template:information even recommends to leave this parameter blank in a certain, very possible case: "License and other usage limitations and warnings. Due to the size of many license templates they are often placed in a separate section below {{information}} template. In such a case please leave this field blank." In this example the reader is left with the cryptic letters "CC-BY-SA" as terms in MV, which is also not better than a blank field. (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 largely not embedded in MV. It might well be, a user is interested in using the there given information regarding the artist, painting technique, location of the artwork etc, when reusing an image (exmple). In the case of this template the reader often gets the information, there was no description available. This actually means, no description in a description parameter, but there exists lots of descriptive information in the template. I don't think the reader (and possible user) necessarily expects there to be information about the artwork somewhere else, when he's told there is none. 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 (downloading and embedding) 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 downloading and embedding 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/embedding (and sharing) 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 download or embed 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 [8], 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 download and embed 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)

You have just convinced me to stop editing Wikipedia and made me give up any idea of taking up a Commons account. There's no point in my investing time and effort to try to produce a quality encyclopedia and media repository if Wikimedia can foist unwanted software on the Wiki projects (against their editors' expressed consensus) and ruin the user experience. English Wikipedia has been wondering why occasional editors have been leaving - we're simply not prepared to put up with Wikimedia's interference any more. 86.129.165.210 16:35, 11 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) - makes building user interfaces easier.
• Improvements to image scaling were made and there are even more good considerations - this what I call core support.
• Community engagement by hangouts and openness during development -- a "disable link" has been installed - I like that and how the MV team addressed concerns about feature. Nearly all feedback got at least a thought and could be discussed.
• A tool was created that is truly useful to visitors who only want to watch the image - Personal experience with Wikipedia visitors has shown that the tool is well-accepted. Whether it was really required -- I think it doesn't make a huge difference, it just looks nicer.

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 **** now.
• People working with files do not need it. It's a nuisance for them.
• … and a lot more listed above and in the RfCs.

I'd also like to take the opportunity to thank for various improvements such as adding the revision timestamps of files to the log, the new gallery design and for Special:AllMyUploads. -- Rillke (talk) 22:10, 10 July 2014 (UTC)

I wonder though, what's the ratio of photographers who are dissatisfied because MediaViewer does not display their combined GFDL-CC-BY-SA-CC-BY-NC licence with custom attribution line, to those who have been dissatisfied until now because their work was shown to the readers in half a postcard size? --Tgr (WMF) (talk) 01:31, 12 July 2014 (UTC)

Misuse of 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)

We support noviewer as an alternative. --Tgr (WMF) (talk) 21:33, 11 July 2014 (UTC)

Based on the description I found I had the impression these classes serve very different purposes. Images marked with noviewer don't open the viewer on click but are still part of the slideshow, right? Images marked with metadata are excluded from the slideshow. That's what I expected, simply because there are two very different explanations for these classes. If they are identical, why not explain they are identical? Can we start "misusing" noviewer or will one change it's behavior some day? --TMg 10:19, 13 July 2014 (UTC)

The definitions are based on the English Wikipedia. .metadata in English Wikipedia is a class given to anything that is 'metadata' to the content proper (so stuff NOT part of the article, yet defined inside the article). It was used to strip maintenance templates and other community annotations and utilities from print, books, PDF and mobile views. It is usually NOT put on images, but on the div/table's surrounding the image. noviewer is more specific to MMV however, much as noprint is more specific to the print medium. TheDJ (talk)

The behavior of metadata and noviewer is fully identical (if it's not, that is a bug). I can't think of a good use case for showing something in the slideshow but not showing on click. The FAQ seems to suggest the same to me, but then I am probably not the best person to determine whether the text is confusing for someone not familiar with MediaViewer. Suggestions for better phrasings are always welcome. --Tgr (WMF) (talk) 03:17, 14 July 2014 (UTC)

@TMg: Their effects ON MediaViewer should be identical (and if they are not that should be reported). But metadata also has effects outside of mediaviewer (it is a semantic classname) and noviewer is MediaViewer only (it is a purely functional classname). metadata is a subset of what decorative (also semantic) would be. I guess a decorative class could also apply to a flag next to a country name in the content. metadata would not apply to that specific case. Should this perhaps be configurable per wiki trough a MediaWiki message ? TheDJ (talk) 15:18, 22 July 2014 (UTC)

@TheDJ: What the English community does is a painful misuse of the term "metadata". Metadata is not "stuff that's unrelated to the article content". The opposite is true. Look how the German community uses the class. That's how it should be: Certain infobox rows can be metadata. The person data template is metadata. Metadata is hidden by default and can be made visible if a user is interested in metadata. But maintenance templates are not metadata. The German community marks them with class="noprint". It's ok that the MediaViewer knows about class="metadata" and ignores images in such blocks by default. But this should not be advertised as an "official" way. The fact that the German community uses the same class name in a completely different way should be proof enough that MediaViewer needs to support an other class name. --TMg 07:58, 24 July 2014 (UTC)

That's what I said, perhaps we need a more configurable approach here, because these classes across the various wiki's have a long history. If I remember correctly, the English Wikipedia metadata classname stems all the way back to the 2005 initiated WP 1.0 project. It's not a misuse, it's simply not the same class, they have different definitions and different content types (metadata of the topic vs. metadata of the community). TheDJ (talk) 09:11, 24 July 2014 (UTC)

Italic text in the description is displayed as plain text

First, thanks for fixing the problem with the sticking tooltip of the X-button (in Firefox)! The ugly white 'spot' on the left is still there, though. And it's also better without the tooltips on the back and forward buttons.

I noticed, that MV doesn't display italic text from the description page, like in this case. Instead it shows plain text. I wrote the book title in the description in italic letters and it looks very confusing without. I don't know, if there are maybe more issues regarding formatted text in MV? --Miss-Sophie (talk) 11:48, 11 July 2014 (UTC)

Could you make a screenshot of the white spot? It's hard to guess what could be the cause without seeing.

We strip all formatting from the description except for links; it tends to contain tables and other horrible things which would mess up any interface trying to include it. Making an exception for italic/bold seems harmless enough, though; added bug 67887 for that. --Tgr (WMF) (talk) 21:25, 11 July 2014 (UTC)

@Tgr (WMF), thanks for writing the report about italic/bold text. I hope, these styles will be added. Regarding the white spot, I thought the problem was clear by now, since you even commented on the reports of it in a way, that made me assume, the issue had been reproduced. Others and I explained it here here. One IP user made a screenshot and uploaded it. The white spot/object is marked with a red arrow in the screenshot. While the tooltip, which I thought could be related to the spot, now luckily doesn't stick on the search field anymore, the spot is still an irritating object on the black background of MV. --Miss-Sophie (talk) 22:22, 11 July 2014 (UTC)

Thanks! I thought that was fixed with bug 66895, but apparently not. The spot is clearly the edge of a tooltip though. Opened bug 67894. --Tgr (WMF) (talk) 22:34, 11 July 2014 (UTC)

My two cents

Sorry to say, but the media viewer in its current version is not useful - not to say aweful... I don't know if it's my settings fault or if the system is just bad - but actually I don't care though; because in my opinion, it should work for everyone. Ok, so what's my problem? Well,

1. the media viewer obviously opens on a new site. That's shit, because if you wanna look at several images (always after closing the previous pic by clicking the "X"-button) and then have to go back to the article you have read before, you have to go back through like dozens of picture previews to get there. So, please: Let the viewer open in a pop-up or something - that also works e.g. on Facebook; and even there without Java!

2. there are some bugs, which are really annoying. For example, when I want to close the viewer, sometimes the screen just turns black and i have to reload the page - which is kinda shit. I can't tell you the reason, but it'd be great if you fix this..

3. it just doesn't look better then the old viewer! Honestly, a media viewer is basically a great idea. But: I don't really get the advantages of this one! With the old system (which worked btw) you had categories, licences, download options and all other information in front of you. Now, there's just this huge picture and you can't even copy its file-name to place it into an article!

Because of that I deactivated this system in my settings. But I hope, you'll improve these bugs soon, so i can work with it properly :-) Thanks and greetings, 111Alleskönner (talk) 18:06, 11 July 2014 (UTC)

Thanks for taking the time. Point one is tricky and is being actively discussed on bugzilla if you're interested in following along. For point two, do let us know under what circumstance this happens, and what browser/operation system combo you're using. Point three, well, there's nothing to say there really. I hope you like future improvements. Keegan (WMF) (talk) 20:30, 11 July 2014 (UTC)

@Keegan (WMF): -- I brought "point one" to WMF's attention more than two weeks ago. Anyway, I came here wondering what happen to the feedback link that used to be on MV. -- Gwillhickers (talk) 21:23, 12 July 2014 (UTC)

@Gwillhickers: if you read that bug report that I link to, which I gave you when you did bring this up two weeks ago, you'll see that it's been under discussion since March. I encourage you to read the bug report to get an understanding of the complexity of working with browser histories. The link to the survey, the bullhorn, has been removed as the survey ended last week. Keegan (WMF) (talk) 20:37, 13 July 2014 (UTC)

@Keegan (WMF): As we have had an ongoing 'bug report' here on the feedback page and on two RfC's I really don't need to go anywhere else to know, and as an end-user/editor I'm not really interested in the complexities from a programming perspective. The prior viewing system had none of these faults. Hopefully some day this idea will get through to you guys. An all around 'fix' would be restoring Wikipedia to where it was before, but since too much time and money has been committed to this project, I can understand, sort of, why that's not in the project team's particular game plan. In any case, there have been criticisms from MV proponents that the feedback page and the RfC did not have enough user input so I would recommend that you restore the feedback link. Without it new and returning users won't know about where to go to voice opinions and they won't learn about the RfC at Commons and the current Arb'Com request. -- Gwillhickers (talk) 16:08, 14 July 2014 (UTC)

What is the resolution?

I remember I really liked that I could clearly see which resolution a certain image had. Now, this is not possible with this new thing going on. --90.226.181.130 18:40, 11 July 2014 (UTC)

You can get to the original file page with one click in Media Viewer by clicking on the local file icon or the Commons icon in the bottom right of the screen; or you can control/command click on the image to open up the file page in a new tab. I hope you enjoy other features in Media Viewer; for example you can click the download button and choose which image resolution size you'd like to download. Keegan (WMF) (talk) 20:34, 11 July 2014 (UTC)

The other way is to click on the "Use this file" button, and select the "Download tab" in the dialog which appears (if you are using it for the first time, this will be the default). The resolution will be displayed on the main button. --Tgr (WMF) (talk) 21:19, 11 July 2014 (UTC)

Improving licence information

The Media Viewer makes good progress, I like the "You need to attribute the author"-Button. I have two improvement suggestions:

• Please do NOT view the "You need to attribute the author"-button for works in the public domain!
• Add an little i-Icon (like ) beside the license name (next to the imagename) witch, when clicked opens a little pop-up with a short description of the license – similar to the CC-deed.

Keep on with the good work! -- MichaelSchoenitzer (talk) 23:15, 12 July 2014 (UTC)

Great, thanks for the input and thoughts about licensing linking. These are great ideas that the team can look into. Keegan (WMF) (talk) 03:33, 14 July 2014 (UTC)

Font size awfully small - and can disable "link" be more visible?

When looking at a few images tonight, I noticed that the font size in the "below the fold" section is awfully small; in fact, it looks smaller to me than the last time I looked at it. It was difficult for my more "mature" eyes to see.

I'm glad that the page has a built-in disable link - good for you for adding it. But perhaps it could be more prominent? Combined with the small font size, and the fact that most people won't look below the fold, it's not quite as accessible as it could be.

Thanks Risker (talk) 08:32, 13 July 2014 (UTC)

Thanks, Risker. There's an active discussion about reworking the disable/enable option that I hope we see in development in the next couple of weeks. As for the font size, I'll have to differ that answer. Keegan (WMF) (talk) 03:35, 14 July 2014 (UTC)

Categories

Tracked in Phabricator
Task T64277

Why does the Media Viewer still show hidden categories when there are un-dispalyed normal categories, which the general viewing public would find much more useful. Also the category icon's meaning is not obvious. I don't think general viewers have any idea what the list of words next to it means. Adding the word "Categories:" would be much more useful. The other two icons in that area are followed by explanatory words ("Uploaded by", "Created").--ArnoldReinhold (talk) 10:34, 13 July 2014 (UTC)

I agree. I tried to recognize, what the category icon depicts, but I'm not sure. Is it an envelope? And if so, I don't understand, why? Some users might guess, what these words mean, but it could be clearer. There should be an option to see all non-hidden categories, while hidden categories should not be shown at all. --Miss-Sophie (talk) 10:59, 14 July 2014 (UTC)

This is a known issue. It's a problem that propagates from core to API to MMV, so it's not entirely trivial to solve because of that, but it is fixable. TheDJ (talk) 11:33, 15 July 2014 (UTC)

Okay. But while we're at it: What does the icon depict? --Miss-Sophie (talk) 13:39, 15 July 2014 (UTC)

Thanks, TheDJ. The icon is a curation label/tag, like what one would find in an antique shop or a museum. Its origins come from the Page Curation toolset (ref: commons:File:Curation_Bar_Icon_Tag.png). Keegan (WMF) (talk) 23:25, 15 July 2014 (UTC)

Thanks for your explanation. I didn't recognize it as a tag. But how does one depict a thing like a tag in a recognizable way for such a tiny icon anyway? After some Google research I found, a 'tag' icon is not uncommon for the meaning of "category". Personally I would have expected it to be some kind of container, a folder maybe, because the images are in a category. --Miss-Sophie (talk) 10:29, 16 July 2014 (UTC)

Coincidental ?

Looking at the software used by the LA Times to navigate readers through galleries (article w. gallery), it looks quite compareable to the MV (background, nav-arrows left & right, fullscreen symbol). Could that be an issue? Alexpl (talk) 12:23, 14 July 2014 (UTC)

I don't think it's an issue, but thank you very much for pointing it out. Keegan (WMF) (talk) 23:26, 15 July 2014 (UTC)

Requests for Arbitration

(copied from Commons) Statements regarding the fate of Media Viewer and the role assumed by various individuals on the WFM project team have been and continue to be presented to the Arbitration Committee. -- Gwillhickers (talk) 02:25, 13 July 2014 (UTC)

Note, that is the English Wikipedia's ArbCom. -Pete F (talk) 04:06, 14 July 2014 (UTC)

High density displays

Will MV address issues of high pixel density displays? I get that for the viewer itself the images may be large enough but NFC is limited to 300px and certainly images on article pages are rather small these days. Saffron Blaze (talk) 22:22, 14 July 2014 (UTC)

Saffron Blaze, can you clarify what issues you mean? MediaViewer does take pixel density into account when selecting the image size to request from the server. --Tgr (WMF) (talk) 20:51, 17 July 2014 (UTC)

Loading bar

Does there have to be a loading bar every time an image doesn't appear at once? It's not exactly beautiful and I find it superfluous for cases, where it takes just 1 or 2 seconds to load. I think, if the picture looks blurry for 2 seconds or less, this won't irritate me so much, that I need a sign of progress. The bar is especially annoying in situations, where you click fast to maybe browse through a few images of a very long slideshow, you don't find that interesting. Meaning, I click the 'forward' button, the moment an image has just become sharp or even before it has been loaded properly and is still blurry, to get to the more intersting ones; and this perhaps several times for several uninteresting images. In these cases I click on the forward button about once every second or 1.5 seconds, and for all images I want to quickly skip, this blue bar starts to run from the left to the right of my screen, gets interrupted on clicking 'forward' and starts again with the next image. Because the quick clicks seem to overburden MV somehow, so it shows blurry images and the loading bar pretty regularily for every quickly skipped image (which doesn't happen, when I click a little more slowly). I tested this with the long slideshow of all images on this page: Lightbox demo.

Could you not make the loading bar only appear, when it takes longer than 2 seconds (or 1.5? You might determine the duration of a hold-up, when users start to wonder, if the image is actually that blurry and will stay like that)? --Miss-Sophie (talk) 12:55, 15 July 2014 (UTC)

I think the ultimate problem here is the lack of a better way to navigate between images, without triggering a preloading of them. The plan is to solve this with a navigation strip, although that won't happen anytime soon. --Tgr (WMF) (talk) 21:01, 17 July 2014 (UTC)

Loading in the "Category Slideshow" tool from Wikimedia Commons

I had only used the already existing tool for viewing a category slideshow on Wikimedia Commons a few times. But now I did deliberately to further test Media Viewer, which means I compared the slideshow function of both tools. I used this category: [9]. While MV is clearly presenting the image better (larger images, not sticking them on the under edge of the screen, 'full screen' mode), I have to say, I prefer the process of loading the images in the "Category slideshow" tool. I'm no computer scientist, but I got the impression, the Commons tool maybe preloads all images to be shown, while MV always only loads the current one? Whatever the reason, I like, that I can browse through the pictures even quickly with hardly any hold-up, where the tool is loading an image (if you click really fast it happens a few times). In MV you get the ugly loading bar and blurry images for the whole slideshow, when clicking quickly, and for some images also, when clicking slowly. I should add, that it takes slightly longer in the Commons tool, until the first image appears (in my example 5 seconds vs 3 seconds in MV (until it's sharp)), so MV is a bit better in this respect. And I noticed, the idea of the blurry image, that appears in MV during the loading process, though ugly, is not a bad thing in general. For with the Commons tool it happens, that you accidentally skip an image, that is still loading, because you don't see it (it's all black screen, until it has been loaded). But I would like to see the occurrence of the loading bar and blurry images being reduced to a minimum by maybe adopting the loading process from the Commons tool. What do you think? Or is there a certain reason, why you didn't do it this way? Not possible? --Miss-Sophie (talk) 10:20, 17 July 2014 (UTC)

It's because the size that the Commons tool uses is much more likely to already exist on the server and thus not require on the fly thumbnail generation on the server side. This is a known issue that is being worked on, but it has quite big hardware impact, so it will take quite some time to fix. TheDJ (talk) 13:00, 17 July 2014 (UTC)

Commons gadget does a) pre-fetch b) uses common thumbnail sizes. The loading bar in MV is indeed distracting. -- Rillke (talk) 22:11, 18 July 2014 (UTC)

Truncating the description or author

When you truncate either the description or the author, please can you include a clickable "... (more)" that expands just that field. As a model, I'm imagining what Facebook do when they truncate comments. --99of9 (talk) 02:05, 16 July 2014 (UTC)

Hi 99of9. Thanks for this helpful suggestion! I am happy to say that we are working on a new feature that will let you expand truncated text fields, as described in this development ticket. If all goes well, this feature should be deployed in the next few days. Hope this helps :) Fabrice Florin (WMF) (talk) 21:01, 16 July 2014 (UTC)

Ok, glad you're on to it. --99of9 (talk) 07:23, 18 July 2014 (UTC)

Large files, e.g., Anselmus van Hulle, not shown at highest resolution

Media viewer (QuickTime plugin) does not display large images at full resolution, click at the header. Regards, Hansmuller (talk) 14:46, 17 July 2014 (UTC)

We currently fall back to the browser for full-size display, and browsers generally don't display TIFF images. --Tgr (WMF) (talk) 20:48, 17 July 2014 (UTC)