Extension talk:Media Viewer/About/Archive03

Proposal: View Original File

Latest comment: 10 years ago9 comments5 people in discussion

Mockup for "View Original File" feature.

Hi folks, we would appreciate your thoughts about a proposed feature for Media Viewer: "View Original File", as described below.

1. Goals

In our surveys and discussions, many users have asked for either access to original files -- or a zoom feature.
These frequent and related requests cover a range of use cases:

view the original file in its full resolution
edit, crop and/or re-use images
zoom in to view details

2. Feature

To address these requests, this feature would enable you to access the original file from Media Viewer, so you can examine it in your browser, and easily edit/re-use it. To view that original file, you would simply click on a new "View original file" button next to the image, as shown in this mockup. This would open the original full-size image in the same browser window, as happens now when you click images in file description pages on Commons. Your browser’s back button would return you to the Media Viewer.

This proposal would support the use cases above by providing the same core functionality editors are used to on file description pages. It would enable you to operate on files (convert/edit them), and also give you the ability to zoom on common file types in modern browsers.

3. Alternatives

The multimedia team has investigated several other solutions to address these user requests. We developed a Simple Zoom Link, which you can test now on Commons: but we’re concerned that this implementation provides a poor user experience that’s more complex than it needs to be. We also considered a Basic Zoom and a Full Zoom features. But these implementations require more development time than we have right now. We’re eager to wrap up this version of Media Viewer this month, so we can move on to other important issues, such as upgrading UploadWizard or fixing bugs in our technical debt.

4. What do you think?

We’d be grateful for your feedback about this proposal and some of the short-term options we’re considering, by answering these two questions:

Q1. How important to you is it that we implement “View original file” or a similar feature at this time?
- a) very important
- b) somewhat important
- c) not important

Q2. Which of the following options do you think we should develop at this time?
- a) View Original File (~1 day of work)
- b) Simple Zoom Link - to original file in a tab (already on Commons, ~1 day to improve)
- c) Basic Zoom - to original file in Media Viewer (~1 week of work)
- d) Do Nothing

Thanks in advance for your guidance about this important issue. With your help, we hope to implement a practical solution that can address your most pressing needs in coming weeks. Regards as ever. Fabrice Florin (WMF) (talk) 23:27, 21 May 2014 (UTC)Reply

View Original File: Comments

PKM (talk) 01:21, 22 May 2014 (UTC)Reply

Q1: a,
Q2: a.

Thanks, PKM, much appreciated. Anyone else want to give us advice? Your feedback will help us make an informed decision to address this issue. Much appreciated. Fabrice Florin (WMF) (talk) 18:56, 22 May 2014 (UTC)Reply

Quiddity (talk) 19:37, 23 May 2014 (UTC)Reply

Q1:a.
Q2: I don't think a link to "original file" will work, because we have too many gargantuan pictures (dozens or hundreds of megabytes). I generally don't want to see a 80,000px wide image; I generally just want to double the size of whatever I'm looking at.
If it's easy, I'd like to see the existing file-sizes linked, perhaps at the bottom of the info-area. I.e. Take the <div class="mw-filepage-resolutioninfo"> stuff (screenshot) from File:Amerikanischer_Lenkballon_"Scout"_-_CH-BAR_-_3241653.tif and stick it in the MMV page in one of these 3 areas: https://i.imgur.com/EWI9bkC.png (ugly mockup!). But IANAD, so that might be a lot more complicated in practice than theory. HTH.

Dan-nl (talk) 06:15, 24 May 2014 (UTC)Reply

Q1: b
Q2: a

one thing i don’t understand is that currently clicking on the magnifying glass brings you to the original file. that already seems fine to me. i think that all that needs to change is the icon used for the behaviour. the proposed icon is better than the magnifying glass, which i'd expect to represent a zoom feature in this context, but i'd rather see a file icon for the idea of going to the original image.
- e.g., http://commons.wikimedia.org/wiki/Main_Page#mediaviewer/File:Dawn_on_cloud_nine.jpg
also, i think that an accessibility aspect is missing. a hover over the icon “should” tell me what the icon does; currently none of the icons tell me what they do; i have to guess.
another thing is that the URL i'm brought to is different than what i'm brought to from the File: page. the magnifying glass brings me to http://upload.wikimedia.org/wikipedia/commons/thumb/0/02/Dawn_on_cloud_nine.jpg/3000px-Dawn_on_cloud_nine.jpg, but a click on the image from the File: page brings me to http://upload.wikimedia.org/wikipedia/commons/0/02/Dawn_on_cloud_nine.jpg. which one is correct?
lastly, i'd rather see a link to the original File: page -- that's much more important to me.
- found the tiny commons icon at the bottom right of the MediaViewer display that brings you to the original File: page. i'd rather see that icon more prominently placed; e.g. as one of the main icons of MediaViewer; e.g., under the double-arrow which triggers full screen display, with a tooltip something along the lines of “View file details’. Dan-nl (talk) 04:25, 28 May 2014 (UTC)Reply

Dominic (talk) 20:31, 27 May 2014 (UTC)Reply

Q1: a.
Q2: Sorry for not answering with one of the choices provided, but I strongly agree with Quiddity's comment above. I am especially afraid that, because of how MediaWiki handles files like TIFF and SVG, a "view original file" link will lead users to accidentally trigger downloads of files in formats that can't be viewed in-browser, which would be a bad user experience. I hope there is a solution that avoids problems with these edge cases while providing the basic zoom/"view full size" functionality you're proposing.

Comments submitted by email in the multimedia or commons mailing lists -- posted here by Fabrice Florin (WMF) (talk) 08:41, 28 May 2014 (UTC).Reply

Gnangarra - Email sent Wed, May 21, 2014 at 6:01 PM

Q2: Zooming should be addressed separately ...

Rupert Thurner - Email sent May 23, 2014, at 10:57 AM

Q1: a. View the original file plus older versions is, from a glam upload perspective, mandatory.
Q2: a. Yes please.

Samuel Klein - Email sent 24 May 2014 12:28 AM

Q1: a. Very important
Q2: Not merely "one more link", something central and obvious.

(Right now, that is the primary way to interact with image pages on Commons: The largest active area on the page is the image, which when clicked takes you to the original file.)

Andrew Gray - Email sent May 24, 2014 at 1:38 PM

Q1: a. Very important
Q2: I would agree that accessing the image description page/original image really needs to be more obvious than the buried "Commons" link (which is virtually invisible to anyone who doesn't know our site iconography). We've been telling people for years that if you keep clicking on the image file you'll get to our master copy in the end, so clicking on the expanded image seems a natural way to do it :-)

Update: Many thanks to PKM, Quiddity, Dan-nl, Dominic -- and email correspondents cited above. We really appreciate your helpful feedback on possible solutions to this issue. Based on what we've heard so far, most of you think it's a 'very important' issue (Q1). But there doesn't seem to be overwhelming support for this particular 'View original file' proposal (Q2): while some of you think it would useful, others feel strongly that we need another solution, because 'viewing the original file' can lead users to gigantic files that can crash their browser or trigger unwanted downloads; and yet others want a more prominent way to access the original file.

So based on all this feedback, we've been discussing our options and think this 'view original file' proposal should be shelved for now, as it doesn't address effectively the concerns expressed above. Instead, we're now looking to make our current 'Use this file' button more prominent, since it already provides the main functions requested above: its 'Download' panel lets you download or view images in a variety of sizes.

Here are the related feature improvements and bug fixes we are considering for coming weeks, in order of proposed priority:

Together, these features and bug fixes seem to address most of the main issues we've heard so far, by making it easier to access the file page as well as any of the image sizes -- either for download or viewing. These improvements are not intended as a perfect solution, but as a placeholder that could be implemented in the few hours of development time we have left for this project.

Please let us know what you think of that approach -- and which of the improvements above seem most important to you. It's unlikely that we would have time to develop them all for this first release, so these tasks would need to be spread out over time. Thanks again for guiding our work to find a practical solution that can be built now, as a placeholder until we have more development resources. Fabrice Florin (WMF) (talk) 08:41, 28 May 2014 (UTC)Reply

If it ain't broke, don't fix it.

Latest comment: 10 years ago8 comments7 people in discussion

I'll be blunt: this sucks. It's just change for change's sake. I could get all the information I needed using the old interface. This new one just makes me go through more hurdles to get what I want. Not to mention, it looks out of place with the rest of the Foundation's websites.

I could see this possibly working for those with tablet computers. But not all of us use tablet computers. It's the same mistake Microsoft made with you-know-what.

I recommend giving all users, registered or not, an option to use the traditional image viewing interface if they don't like the new one. Even Google, the king of interface fiascos, still gives Google Maps users an option to switch to the older Google Maps. DaL33T (talk) 20:01, 22 May 2014 (UTC)Reply

Blunt feedback is good, honest feedback. Thanks for that. Media Viewer's purpose as of right now is about displaying an image in a manner that does not involve accessing the stacks of information behind an image. Following that, it's definitely not going to be for you if the interest is the metadata and not the file itself. You're welcome to disable it, particularly on Commons if it interferes with your workflow, but I do hope you can find use for it when casually viewing files. If you'd ever like to use it again you can click on "Expand view" on any file page. Keegan (WMF) (talk) 20:27, 22 May 2014 (UTC)Reply

Very good. Let me be blunt: you've made a horrid mess. Did you ever stop to think that any idiot can find a big box on the file description page with the licensing? Did you ever stop to think that it's easy to click on the normal-size image to get full resolution? Any idiot who clicks on a smaller image and gets sent to a description page will try to click again and get a bigger image. It's nice that I'm welcome to disable it, but you've apparently forgotten that you failed to explain how to do it at commons:Commons:Multimedia Features/Media Viewer, and you failed to provide any gadgets. I've signed up for Wikimedia projects, not Flickr or Facebook, and it would help if Foundation people began to remember that, rather than forcing things on us such as Media Viewer or Flow discussions. Nyttend (talk) 23:07, 22 May 2014 (UTC)Reply

I've added information on disabling Media Viewer to that page on Commons, Nyttend. I appreciate you pointing that out. Keegan (WMF) (talk) 01:38, 23 May 2014 (UTC)Reply

You shouldn't be making changes in the first place if you are not intimately acquainted with the one project that it affects the most. You shouldn't need to be informed of that page--it should have been the WMF that created that whole thing in the first place. Explaining the software to the community and providing an opt out should be priority one, in place before any changes actually go live. Trlkly (talk) 04:14, 29 May 2014 (UTC)Reply

Is there a way to disable this annoying feature without having to log in? 86.27.176.158 00:20, 6 June 2014 (UTC)Reply

"Did you ever stop to think that any idiot can find a big box on the file description page with the licensing?" Let me be blunt in return. Did you ever consider that an 'idiot' just skips over the big annoying box and doesn't actually DO anything with it ? So let's make the attribution and mission education flows better, with that I agree, but let's not kid ourselves that anyone but professional photographers and Wiki(p|m)edians and a few others are actually reading anything in that 'big box' (newspaper usage of Commons material makes this quite clear), let alone understand what it means. There are a LOT better ways to achieve those goals in my opinion and we should definitely be building them, but let's just tackle one problem at a time. TheDJ (talk) 13:12, 4 June 2014 (UTC)Reply

I agree, it looks horrible and is harder to use.--Smithers654612 (talk)

Great, a horrible thing that blocks pictures when you scroll, animates things that need to just disappear, obscures the Wikipedia interface, obscures the file, and raises hardware requirements for no reason. Fantastic. Also you need a fucking account to disable it. Not happening. Not fucking happening.71.34.240.167 13:02, 9 June 2014 (UTC)Reply

Happy feedback

Latest comment: 10 years ago4 comments4 people in discussion

May I just leave a "useless" feedback like: "Great job! I definitely like this new tool. I have been loving it since the first time I tried it in beta"? Thank you all. :-) --Lucas (talk) 08:02, 23 May 2014 (UTC)Reply

I strongly agree with this sentiment. (Unfortunately, most people are just opposed to any change, especially one that benefits readers more than editors.) Jay8g (talk) 01:31, 24 May 2014 (UTC)Reply

"benefits readers more than editors" You say that based on what? I'm a reader (very occasionally correct the most hideous spelling mistakes or obvious typos), and I find the thing atrocious. The previous system was:

perfectly fine,
familiar to any regular user,
discoverable, since all the needed information was visible or directly linked from the picture page,
efficient on a wide range of screen formats.

This system is:

unnecessary (Mr. "Lucas" above says he's "been loving it"... well, what does he "love" about it? The convoluted design? The silly presentation? Its effectiveness at hiding important stuff such as the description of the picture, which is now always below the fold--and I only realised that the ruddy thing "slides" up by mistake!),
non-discoverable: See comment above about how I happened upon the description of the image by mistake--I inadvertently scrolled the mouse wheel while the cursor was over the bottom part of the screen (yes, there is an up-arrow icon... WTF does an up-arrow mean? Like, "this title refers to this image above"? It doesn't even have a bloody tooltip!
Long-winded to use: I usually want to see the full-size image, even though it does not fit on my usual reading device (a netbook, occasionally a phone, less frequently a dual-monitor workstation)... on the old thing I could just click on the "Original size" link which was right there beneath the image. After clicking everywhere on this new excuse for an interface, guess where I found it: (Nondescript icon with a "Use this file" tooltip) -> "Download"(!) -> "Download original size", and then follow the "Preview in browser" link. Never mind that I had no intention whatsoever of downloading the image, and that I did not want to "pre-"view it. I wanted to view it plain and simple.
Inefficient. Whereas before I could see most of the information related to the file (description, licence, EXIF data) in a single screen, with an obvious link to the full-size image, now all I can see is a half-arsed image which is neither small enough to get out of the way nor big enough to be useful (remember, this is on a netbook), and the image title (I presume) and licence in big letters (thank you, but I'm not short-sighted and if I was, my browser and operating system already have standard mechanisms to deal with that).
Redundant. While hunting for the full-size image, I noticed there is that "Share" tab. Know what it does? It shows the URL of the image. Last I heard browsers has something called an address bar with exactly the same info, or you can copy an image's location from its context menu, or directly "share" it properly via mechanisms built into the browser or platform. That's utterly useless and against good design principles (do not obscure your URLs).

To Keegan (WMF): I presume that if "the team" are happy to hear feedback such as the above, which the originator has himself quite rightly qualified as "useless", they will be downright orgasmic about hearing of the actual, objective, reproducible, and measurable issues that I have just outlined. I would also like to think that they will be professional enough to recognise the extent to which this is a waste of (my and other contributors') money and will stop pissing it up on uncalled for stuff. Instead, how about getting the pages to load at the speed they used to a couple of years back, before things started freezing (in Firefox anyway) around a "Waiting for bits.wikisomething.org" message? Just an example of where efforts could go. I know, it's boring, it's not "visible", probably does not look so great on their CV, but at least that would be useful. I shall certainly think twice about ever donating again.

Lucas, Jay8g: :) The team will be happy to hear. Thanks! Keegan (WMF) (talk) 21:14, 24 May 2014 (UTC)Reply

I concur! --129.137.215.245 16:05, 5 June 2014 (UTC)Reply

Can we vote on this? Please?

Latest comment: 10 years ago11 comments7 people in discussion

It seems like there are a good deal of people who are against the implementation of the New Media Viewer. Can we vote on this or something? HMS Indeconstructable (talk) 21:52, 23 May 2014 (UTC)Reply

Yes, please.Crisco 1492 (talk) 08:42, 24 May 2014 (UTC)Reply

Communities are certainly welcome to discuss Media Viewer as they see fit. 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, considering that !voting disenfranchises hundreds of thousands to millions who do not participate in internal project aspects and gives power to those for whom the product is not necessarily intended. Media Viewer's overall feedback is broadly supportive and it's important to consider that when you can disable it on your own. Keegan (WMF) (talk) 21:10, 24 May 2014 (UTC)Reply

"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" Thats why I think a vote would be a good idea; anything else is just my opinion vs. their opinion vs. your opinion. So I am correct in my understanding that we both agree that there should be a vote? HMS Indeconstructable (talk) 22:16, 24 May 2014 (UTC)Reply

I don't agree with you that there should be a vote. That's not saying that you can't. I think it would be wise to give it time and not launch a !vote based on what can be a natural response to change, that is, not liking it. You are free to do as you please, but I urge you to consider the much broader picture (so to speak) that !voting will not capture the voice of the casual consumer, for whom Media Viewer is primarily intended. You have the option to turn it off. Keegan (WMF) (talk) 04:07, 25 May 2014 (UTC)Reply

To supplement, the surveys show that on average 70% of the 7,000+ participants find Media Viewer useful. That's pretty significant, and voting will not capture that. Keegan (WMF) (talk) 04:11, 25 May 2014 (UTC)Reply

Who was surveyed? I can see the utility of Media viewer for users of Wikipedia (though even there, I expect you're misinterpreting results that just mean "I just want to see a picture" with how additional information about the picture should be conveyed; two things that are very much conflated in the current implementation); but can't see it being appropriate for Commons. Aldaron (talk) 01:14, 29 May 2014 (UTC)Reply

"Useful" isn't the same as "More useful than the original system". The latter is what matters in making the decision whether to keep or abandon Media Viewer, but it hasn't been assessed by the survey. So, using the survey to justify keeping rather than abandoning Media Viewer is unsound. 86.27.176.158 03:45, 9 June 2014 (UTC)Reply

Not taking people's votes into account is by design. The wiki concept, and Wikipedia in general, is not based on votes, but on consensus. It's not called a not-vote just to be cute. We don't vote on things. We decide based on the most convincing arguments, even if only one person makes it. The fact that 70% of viewers like it has no bearing on whether or not it should be implemented. The question is simply whether the benefits outweigh the drawbacks. The question is whether the feature, whether readers want it or not, is actually beneficial to the goal of creating a free encyclopedia. What people "want" or their "feelings" are irrelevant to a !vote, by design. If 10000000 people say they don't like it but don't give a reason, they don't count, any more than if the same number say they like it. Neither "I LIKE IT" nor "I DON'T LIKE IT" is not an accepted reason to do anything on Wikipedia.

It's this lack of faith in the community that we have built up that irritates me so much about the WMF lately. The same type of argument was made with the font change. And, predictably, a bunch of people were upset. Just like with this, the first they heard about it was when it was rolled out, and they were upset. They didn't have a chance to be convinced with arguments that it was a good idea. They didn't have a chance to make simple suggestions that would have largely stemmed the controversy.

If you think our ways of doing things are bad, then why aren't you trying to change them? Why do you insist on working outside of them in these conferences that most of us can't physically go to or these chats that severely limit the time available? And you don't even get those right, since you miss the freaking bureaucrat of one of your wikis! That shouldn't be possible!

I know I sound like a broken record, but I long for the day when the WMF can work as Jimbo originally envisioned, as just users with extra responsibilities. Not some elite group that has to protect us from ourselves. We can handle this sort of thing if we are given a chance. We already have the tools in place to deal with the problems you foresee, including resistance to change.

If you'll work from within instead of from without, I think you will be pleasantly surprised at how much better things go. I really get tired of having to see the WMF as the enemy we have to fight in order to preserve the project. Trlkly (talk) 04:05, 29 May 2014 (UTC)Reply

Trlkly: I'm always at your disposal for thoughts, questions, comments and concerns about new products the WMF is developing, and I'd also be more than happy at any time to help you get engaged in the development discussions. You can email me, leave me a talk page message here, on meta, or en.wp. By all means, the door is wide open for participation :) Keegan (WMF) (talk) 04:54, 5 June 2014 (UTC)Reply

That page about the survey is out of date anyway, and very sneaky. It doesn't talk about the German or English results specifically, because barely a quarter of respondents said they did find it useful. It talked about the English results in the May 5 update, presumably because they were favorable then.--Smithers654612 (talk) 10:27, 7 June 2014 (UTC)Reply

I can't see a difference ;o)

Latest comment: 10 years ago1 comment1 person in discussion

I looked on sample pages, but I cannot see a difference! Does it require interpretation of javascript? If this is true, the audience must not be confused by statements, that only apply with javascript interpretation activated. Additionally I think, the project is not thought through, if it requires javascript interpretation for more than decorative issues. Better first to complete such a project before exporting such experiments in a confusing way to other wikis like wikibooks ... And especially for wiki types like wikibooks it is obviously more important, that for such a new feature the authors of the books have to explicitly activate such a feature for their book instead of beeing surprised by undesired changes. There could be an additional property to indicate, that such a 'media viewer' matters for the individual media. Additionally especially for SVGs it would be obviously even more relevant to indicate, that no preview raster images has to be presented, but directly the SVG (because the SVG preview generator typically has much more bugs and gaps than an up to date user-agent. If such a media viewer could be convinced to switch off the preview generator for the complete audience (not only for javascript fans), this could be a great benefit for such a tool. Doktorchen (talk) 10:54, 24 May 2014 (UTC)Reply

"Uploaded by" credit

Latest comment: 10 years ago3 comments3 people in discussion

Tracked in Phabricator
Task T59308

Can I suggest that the "Uploaded by" credit should principally indicate the original uploader of the image ?

At the moment it seems to be crediting the most recent uploader, but that may often be for only a small tweak -- eg rotation or cropping or a colour adjustment.

It seems odd to see "Uploaded by Cropbot" or "Uploaded by Rotatebot".

So where the original uploader is not the most recent uploader, can I suggest "Uploaded by OriginalUploader; most recent version by NewUploader" ? Jheald (talk) 11:04, 24 May 2014 (UTC)Reply

That seems like a fairly major issue of attribution...Crisco 1492 (talk) 12:15, 24 May 2014 (UTC)Reply

Good suggestion, Jheald :) I see where this gets tricky. Keegan (WMF) (talk) 21:11, 24 May 2014 (UTC)Reply

Template {{Artwork}}

Latest comment: 10 years ago3 comments2 people in discussion

If a file is described with the template {{Artwork}}, the Media Viewer displays the field Description, which is empty or contains accessory explanations (those, quite often, are redundant for the overwhelmed users ;-), but the most significant field, Title, containing the name of an artwork, is not displayed.

As well, the Media Viewer does not display the field Artist containig the name of a painter, a sculptor... (Dmitry Ivanov (talk) 21:31, 24 May 2014 (UTC))Reply

The template {{Artwork}} has more than 550,000 transclusions, and, I think, it deserved some attention of MV’s developers.

Dmitry Ivanov (talk) 20:53, 24 May 2014 (UTC)Reply

Yup, I agree. My feeling is that a good bit of problems with what fields are/are not being included in Media Viewer will be solved by the next iteration, provided development of structured metadata and integration with Wikidata makes the progress the two teams are working toward. Keegan (WMF) (talk) 22:25, 27 May 2014 (UTC)Reply

Link to ZoomViewer is missing

Latest comment: 10 years ago3 comments2 people in discussion

For high resolution media like scanned maps it is absolutely essential to have a link to the ZoomViewer feature. But with Media Viewer this link is missing now. Without this function all the high resolution images on Commons suddenly got unusable! --Alexrk2 (talk) 11:05, 25 May 2014 (UTC)Reply

PS and if one clicks the magnifying glass for are very large image, he will freez his browser. Thats why we have that "Large Image" warning stub for very high res images (in combination with the ZoomViewer link). Actually I would expect that the magnifying glass would start something like the ZoomViewer, where I can zoom in, zoom out, pan. --Alexrk2 (talk) 17:58, 25 May 2014 (UTC)Reply

Exactly, many pictures are now useless! 91.158.173.19 23:34, 8 June 2014 (UTC)Reply

Media Viewer on Commons necessary?

Latest comment: 10 years ago3 comments3 people in discussion

I can understand the intention to have one common viewer for all different language versions of wikipedia, e.g. en, de, fr, etc. The idea to present the picture in the same way all the time without the switch to commons, OK so far. I am not really positiv about this as well, but OK. What I really DONT understand at all is, why do we need the media viewer in commons itself. When I click on a picture there, I want to see the whole content all information, everything, because I want to work with that picture. It is really time consuming and frustrating all the time to wait until the picture has been load and then to click once more to see the picture in the way as it was before.

Please make an option in the settings in commons if the media viewer shall be active and used or not! --Mogadir (talk) 13:32, 25 May 2014 (UTC)Reply

Mogadir: "When I click on a picture there, I want to see the whole content all information, everything, because I want to work with that picture."

About 1/2 (or even 2/3) of the information about a file is lost with the current version of the Media Viewer. The developers of the gadget refer to the results of a survey and say that users do not want information. I think, the results of the survey are quite correct: the users really do not want that much information. No wonder, the people got accustomed to mosaic picture, to clip thinking: no penetrating reading, no reflections, no research... A picture – something is written – go father – a picture – two words – what next... Quickly, quickly, quickly, a spintop is whirling... Many love it, and the Media Viewer gives them what they want.

In reality the question of the Media Viewer is not a local, technical, problem of a certain gadget.

In reality it is a strategic question, the problem of Commons’ essence, the problem of Commons' mission.

What must the Commons be? Must it be under the thumb of mass consumer and see its destination in providing of comfortable surfing through pictures? Or, may be, it must demonstrate the high class of encyclopedic, scientific approach, must show a story behind a picture, must invite to research?..

Must the Commons go down to the desires of the customers or must the Commons lead the people to summits?..

Must the Commons be one of numerous projects modeled after moulds of the IT-industry or must it keep the spirit of the Enlightenment and encyclopaedic knowledge?..

That is the question...

Dmitry Ivanov (talk) 19:48, 25 May 2014 (UTC)Reply

Dear Mogadir and Dmitry Ivanov: Thanks for pointing out the issues you're experiencing with Media Viewer on Commons. You make some good points, which we will discuss with our team and consider improvements that could be made to address them in coming weeks. Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)Reply

Notification

Latest comment: 10 years ago5 comments5 people in discussion

I wonder if we could get email notifications before WMF breaks stuff so we could tell them not to? Rich Farmbrough 16:33, 25 May 2014 (UTC).Reply

sure, just subscribe to wikitech-l. TheDJ (talk) 14:55, 26 May 2014 (UTC)Reply

If you're all about making things modern, why are you using such ancient tech as a mailing list? This sort of thing should be on like a Twitter feed or other information ticker something. Actual discussion should be in some sort of forum--or, better yet, a Wikimedia talk page, showing dedication to your design.

Its silly to expect the average user to know how to use tech from 1995. Trlkly (talk) 05:49, 29 May 2014 (UTC)Reply

Dear Rich: Thanks for bringing up the important issue of notifications for new products. We have announced this new feature extensively, as you can tell from all the links in this release plan. But we will continue to look for more ways, like email notifications, to inform our community about new features like this one. Regards as ever :) Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)Reply

@Trlkly: subscribing or navigating the mailing list archives not hard at all. Twitter is more complicated. It is a commercial site running proprietary software which limits the number of characters in a message, probably not optimal for this kind of thing. If you wish to have technical news delivered to your talk page weekly, you can subscribe to m:Tech/News (there is also an RSS feed), however wikitech-l is more complete. πr² (t • c) 23:20, 3 June 2014 (UTC)Reply

Can a Media Viewer button be added to thumbnails?

Latest comment: 10 years ago2 comments2 people in discussion

Would it be possiblel for a Media Viewer button to appear in the upper right of a thumbnail, whenever the mouse hovers over the image? (Typically this kind of button has two small arrows pointing to opposite corners of the screen.) This would give users a clear-cut option: clicking that button would launch the Media Viewer, whereas clicking elsewhere would take them to the file description page. --Robert.Allen (talk) 15:23, 25 May 2014 (UTC)Reply

Hi Robert.Allen: Thanks for this suggestion. We initially considered design ideas like the one you propose, but found them to be too complex for casual users, and not well-aligned with best practices on the web. Note that you already have the option to bypass Media Viewer, as described in this FAQ. Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)Reply

Option to disable Media Viewer

Latest comment: 10 years ago4 comments4 people in discussion

Hi. Please provide a option in preferences to disable Media Viewer. I don't need at all Media Viewer. As a editor, in most of cases i need to view media's page not media itself. I need to verify licences, descriptions or sources of files. Also, when i am on other, non-native wikis i need to view directly some media's page to copy file license and description as inspiration for file i want to upload. So, please make Media Viewer optionally. Thank you. --XXN (talk) 10:14, 26 May 2014 (UTC)Reply

See preferences para desactivar (disable). --MARC912374 (talk) 04:45, 27 May 2014 (UTC)Reply

you are absolutely right. this gadget is useless. when i want to see the picture, i really know how to do it. 82.34.76.218 13:26, 26 May 2014 (UTC)Reply

Hi MARC912374: You can disable Media Viewer by turning off this preference. Hope this helps. Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)Reply

That does not help at all, why not allow unregistered users the option of disabling this ``feature" instead of forcing it on them

A wikisource need

Latest comment: 10 years ago2 comments2 people in discussion

From wikisource point of view, a Media Viewer should manage:

djvu files, the hearth of proofreading procedure, with a viewer similar in performance to DjView
if source is Internet Archive, original jp2/jpg files from which djvu has been generated (with a deep degree of image compression and details wasting). --Alex brollo (talk) 10:37, 26 May 2014 (UTC)Reply

Alex brollo: Great, good have documented. I appreciate it. Keegan (WMF) (talk) 22:22, 27 May 2014 (UTC)Reply

really hopeless windows8-like solution - how to switch it off?

Latest comment: 10 years ago3 comments3 people in discussion

how to switch this sh*t off? is wikipedia going to be another useless gadget? because it looks on my computer like anytime i try to find any information on my samsung smartphone. completely useless. only one move more to switch it off. but this time i can not see how to switch it off. 82.34.76.218 13:24, 26 May 2014 (UTC)Reply

Hi 82.34.76.218: You can disable Media Viewer by turning off this preference. Hope this helps. Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)Reply

No. It does not help. It's like: "Choose: useless annoying tool or create an account. Tertium non datur". --2.112.192.13 14:33, 4 June 2014 (UTC)Reply

Bad, very bad

Latest comment: 10 years ago3 comments2 people in discussion

Este visor multimedia no sirve para nada, miro las photos desde Wikipedia y solamente da problemas, además de ser incómodo para ver las images in high resolution. Opino que deberían eliminarlo, y cuanto antes. La Fundación Wikimedia debería gastar el dinero en cosas de mayor utilidad para la Wikipedia. Saludos. --MARC912374 (talk) 00:24, 27 May 2014 (UTC)Reply

Lo he desactivado en mis preferences, pero sigo opinando lo mismo. Es superfluo para Wikipedia y para Wikimedia Commons. Good bye. --MARC912374 (talk) 04:37, 27 May 2014 (UTC)Reply

Gracias diciendo lo que piensas. Keegan (WMF) (talk) 03:01, 28 May 2014 (UTC)Reply

I can't get it to turn off

Latest comment: 10 years ago3 comments3 people in discussion

I un-clicked the selection box for "Enable new media viewing experience" on my preferences page, logged out, and logged back in, and I still can't turn this off. Also, it's hellish trying to find out where to turn it off -- did I get the right setting? -- it would help if you actually used the phrase "Media Viewer" so people could at least search for it. HELLLLLP. Mary Mark Ockerbloom (talk) 14:24, 28 May 2014 (UTC)Reply

I can't figure out how to turn it of either. Where did this thing come from? Aldaron (talk) 01:00, 29 May 2014 (UTC)Reply

Hi Mary Mark Ockerbloom: You can disable Media Viewer by turning off this preference. Hope this helps. Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)Reply

Why is this happening?

Latest comment: 10 years ago4 comments4 people in discussion

Why is this happening? It's important not only that we are able to disable it for ourselves, but also that we have a way of disabling it for the images we've upload, for all users. The fact that such a terrible "feature" made it so far is a clear demonstration that the process for approving such features is broken. Aldaron (talk) 01:00, 29 May 2014 (UTC)Reply

Hi Aldaron: Thanks for your feedback about Media Viewer. We're sorry the tool is not useful to you. We have been testing it extensively as a Beta Feature since November 2013, with tens of thousands of beta testers worldwide -- and they have started many discussions in their home wikis, [outlined in our release plan]. We are also running user surveys in 8 different languages with over nine thousand users so far, and a majority of respondents are telling us they find the tool useful. What specific improvements would you recommend to this careful, methodical community engagement process? Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)Reply

The "process" is clearly broken as it is based on the same sort of blinkered thinking behind Microsoft's development of Metro and Canonical's development of Unity. I've seen both justified by statements similar to those above. You can see the problem in the blurb with phrases such as "Immersive experience". Really? This is an encyclopaedia not an on-line game or a silly marketing exercise. 86.143.57.206 20:56, 7 June 2014 (UTC)Reply

Suggestion. Pay another survey and ask the following question about the previous way of viewing images: "Do you find the current way of displaying images, with a first click showing an enlarged picture with all information, and a second click showing an even enlarged picture useful?". This would be a meaningful survey, not biased like what was done. Anyway, comments on this page show that negative feedback is overwhelming.--Michel le tigre (talk) 21:49, 8 June 2014 (UTC)Reply

Alt text

Latest comment: 10 years ago3 comments3 people in discussion

I would like some way for Alt text for the visually impaired to be associated with images and displayed in the media viewer. Even better would be including an edit mode, so viewers can create and edit the Alt text. A small info icon could link to a page that tells how to create Alt text. While it is regarded as important for people who access Wikipedia via screen readers, there is hardly any Alt text available. Encouraging readers to add Alt text would be a valuable new service for the Media Viewer.--ArnoldReinhold (talk) 01:00, 29 May 2014 (UTC)Reply

The problem with this is that the Alt information is part of the article rather than part of the image page. Putting it in the viewer would imply that it attached to the image, not the article. It's an interesting idea to provide some sort of default ALT tag that is used if one is not provided, but that would require more than just a change to the viewer. Trlkly (talk) 05:44, 29 May 2014 (UTC)Reply

Hi ArnoldReinhold: Thanks for suggesting a solution to better support accessibility on the Media Viewer. We have been discussing different ways to address this concern and will take a closer look at your 'Alt text' proposal. Our front-end developer Mark is now adding tooltips to Media Viewer and we will discuss addressing accessibility issues next. Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)Reply

My actual problem with the viewer: Fair Use

Latest comment: 10 years ago2 comments2 people in discussion

First off, I want to say that I don't think it's all that bad a beta piece of software. I object more to how it is being rolled out than to the software itself. But I do have a problem.

This software assumes that images can be enlarged. Yet my experience is that a large portion of images used in En.Wiki are fair use, and specifically made to be the same size as used in the article. Sometimes they can be a tiny bit larger, but they still have to be 0.1 megapixels by policy, which isn't going to fill up anyone's screen.

Furthermore, our legal usage of such images is based entirely on them being discussed in a scholarly manner. Yet no such discussion appears on the file pages. This is acceptable because they are really just administrative pages. They weren't designed to be a place where you'd view the image. But this new viewer is designed to show images, and gets its information from those same file pages. And with the "next image" option, the user doesn't even have to have seen any thing about the image.

It really seems to me that this viewer does not play well with fair use as we handle the term on Wikipedia. We are much more strict than Wikia where this idea came from. Wikipedia is not a fair use image gallery. Trlkly (talk) 05:33, 29 May 2014 (UTC)Reply

Thanks, Trlkly: I appreciate your kind words about the software -- and your recommendations about fair use issues. What specific improvements could we make to Media Viewer to address them? Should we consider disabling Media Viewer for fair use images altogether? Or displaying a label to let users know when an image is fair use? Do you recommend a simple, machine-readable way to consistently tell when an image is fair use? Look forward to your practical suggestions to address this issue, keeping in mind that we have limited development resources. Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)Reply

Now actual bugs

Latest comment: 10 years ago2 comments2 people in discussion

The above was my major problem, but I've noticed some little things that haven't been mentioned.

The chevron is really light and hard to see. Plus clicking white space in the description should probably work, too.
The smaller text on Commons also affects the viewer, even looking at the same image.
The low res image while the image is being thumbnailed makes the viewer seem slow.
The status bar link is the same whether the link goes to the file page or to the viewer.
The Commons logo is really small, despite having a ton of space
The buttons on the image itself do not have tooltips. Particularly, this makes the fullscreen button unclear in function, since that icon does not always mean fullscreen. (In Gmail, for example, it makes the Compose window float. On Facebook, it used to open a separate page for chat users.)
The animation of the meta data is strange and jerky. It would make more sense to have it just start on the bottom.
There is no obvious way to use the new viewer from its actual description page. Someone may want a full screen view rather than to download the entire image.
The thumbnailing progress bar is inaccurate. If accurate information can't be found, another indicator would probably be better.

That's all I see right off, but I'm sure there are more. Again, this is clearly beta. Trlkly (talk) 06:24, 29 May 2014 (UTC)Reply

Hi Trlkly: Thanks for your detailed and helpful comments on improvements you propose to Media Viewer. We are developing a range of solutions aimed to address the issues you brought up, such as: making the chevron easier to see, displaying a larger Commons logo, adding tooltips to Media Viewer, to name but a few. We have also significantly improved image load times, which are now faster than opening up the file page on Commons, as shown in this metrics dashboard -- and will keep looking for solutions to other concerns you told us about. Much appreciated. Fabrice Florin (WMF) (talk) 20:12, 2 June 2014 (UTC)Reply

Additional button

Latest comment: 10 years ago2 comments2 people in discussion

Another suggestion is an additional button right below the enlargement arrows or the magnification glass in the right corner. That button should be called COMPARISON. By clicking there, all associated categories should open.

This idea picks up the remarks user Dmitry Ivanov made above: people nowadays scroll through pictures in random order with no reflections. Leading them into categories could be a way to make them familiar with comparison as a tool of analysis.

This idea differs from the current next file arrow because it should be very clear what the common ground between the next and the actual file is, and that is the category of the users intentional choice.--Jaybepo (talk) 06:59, 29 May 2014 (UTC)Reply

@Jaybepo: Good suggestion! Better entry/insight to the Category system, is part of the Multimedia team's plan for the Upload Wizard improvements this year, so I know they'll be looking into that aspect of categories later. The work on Structured Data might also help this along. Also the plans to improve the "Add media to an article" process, with a rough mockup at slide 21, might be able to use Categories more effectively. Implementing it in the Media Viewer itself, will probably have to wait till much of that research and work is done, but I agree it should be on the future-feature list - Exploring tangents, is half of fun of reading/working on Wiki content. Thanks. Quiddity (WMF) (talk) 20:01, 7 June 2014 (UTC)Reply

Image description

Latest comment: 10 years ago1 comment1 person in discussion

I think the image description is very essential, so it should be readable next to the image without scrolling or extra-clicking (and in good readable letters). P.S. Look how it is done on flickr, at least you can see the image title in big white letters.--Sinuhe20 (talk) 19:26, 30 May 2014 (UTC)Reply

Simple a bad template

Latest comment: 10 years ago1 comment1 person in discussion

Strong Oppose for this template. Unnecessary and useless, the template displays the images information incomplete. Why all this? --Alchemist-hp (talk) 15:03, 1 June 2014 (UTC)Reply

Two major design flaws (image description not easy accessible / field names missing)

Latest comment: 10 years ago1 comment1 person in discussion

There are two major design flaws in MediaViewer:

First of all the *most* important part of an image - it's description - is only visible after clicking a light gray and nearly invisible small arrow-like symbol at the bottom of the page. That's a no-go (especially for inexperienced readers who are the target audience for MediaViewer)!

Secondly the MediaViewer totally omits field names as they are known from the image {{Information }} templates (like Description, Author, Source, Date, etc.). While the occasional reader might recognize a date, I'm almost sure he'll mix up author/source and description fields which are displayed side-by-side in MediaViewer without even an iconic hint on what information is displayed.

This should be fixed as fast as possible (I don't even understand how MediaViewer could be deployed on many Wikis already with this going unnoticed). --Patrick87 (talk) 21:26, 1 June 2014 (UTC)Reply

Is it possible to control which images are galleried and which aren't?

Latest comment: 10 years ago2 comments2 people in discussion

To elaborate: why not have a tag like, say, gallery=bigpics so that the left and right arrows cycle through the only the images that have the 'bigpics' tag in common; gallery=off could suppress the viewer for that image.

The high-handed imposition of this feature is really sticking in my craw: until today I thought I was a citizen here; now I feel like a subject. I can see a certain amount of light at the end of the tunnel, but it seems essential to give article-editors control of the feature. Trust the compositor, please. Munrogue (talk) 20:52, 2 June 2014 (UTC)Reply

@Munrogue: Re: the features deployment: Fwiw, the Media Viewer was one of the Beta Features for the last 6 months, and there were many requests for feedback, and changes based on that feedback over the period. There does need to be a better system for announcing these "new/updated/upcoming" system changes, and a number of people are working on various possibilities (from increasing the number and type of Echo/Notification announcements; to a better set of Newsletter systems, so that we can each subscribe to the parts we want out of the existing torrents of information).

Re: excluding images - Hmm, there was a discussion about this at this thread and this email thread, but I'm not sure what the resolution was. I'll ping the devs for an update. HTH. Quiddity (WMF) (talk) 20:44, 7 June 2014 (UTC)Reply

A detailed and thorough response of the Media Viewers problems and why it isn't good for the site

Latest comment: 10 years ago2 comments2 people in discussion

I just got done attending the NYC Wikimedia WikiConference and have had the opportunity to talk with other members of the community and to Keegan about the Media Viewer. The discussions I've had brought me to give a more concise and expanded criticism of the Media Viewer, which made me want to address this forum again. I'll be doing it is a bullet point again, since it is easier to read.

- The Media Viewer has way too many negatives for its two meager positives - The Media Viewer gives you an enlarged image and lets you flip easily through images on a single page. That's basically it. The first issue is commonly solved by clicking through the image link to a larger image, which hardly seems difficult. If the original file is also too big, then they have the option of looking at different files below, giving you a greater flexibility for looking at file sizes. The problem that the Media Viewer has with larger images is that it stalls and takes time to load that splash image when you click on it, which is a pretty big negative considering the original method is much faster.

The second issue is one that has no real answer or solution outside of the media viewer. It is currently the only real "win" of the media viewer. Giving that, it seems borderline insane when you rack up those two positives against the list of negatives.

- The Media Viewer divorces content from photos - This is currently my biggest problem with the media viewer. The Media Viewer's purpose is to turn the Wikimedia Commons into a large slideshow, to reduce all images to a larger picture and a caption. It seems to be created from the viewpoint that the Commons is just a massive dump of photos and nothing more, so you would want to be able create a viewer that makes those pictures easier to look at. If you were designing the Media Viewer from this laughably simple and bad viewpoint, it does that, but it does it at the cost of everything else, and such an oversight of the design committee is extremely worrying.

- The Media Viewer is a wall few will ever get past - The Media Viewer is currently so unwieldy and difficult to understand that it brought me to my knees when I was trying to figure out how to get past it. For people who don't realize that there is information past it, or don't want to put the effort into getting past it, the Media Viewer will effectively be a wall few will get past. Casual users will not be clicking past it. Moderate users will see little reason to get past it. Only the hardcore will go past it to see the wealth of Metadata that it blocks from view.

- People have spent years making this metadata that few will now ever see. - The Media Viewer sees Wikimedia content wants to simply reduce everything to a photo and a caption. Almost everything else is chopped out to accommodate this, including the years of work people have put into the Commons up to this point. To accommodate for an odd and closed system, people have found ways to work around and within the restrictions of Wikimedia infopages to create context and provide additional information, which are usually hosted in specials templates or designs that exist outside of the description field. For example, I host all of my work on Wikimedia and use my own userpage to create galleries that sorts and catalogs this information. The best way that I can let people know about this is through the image infopage, where I have a template for drawing attention to my userpages and these galleries.

- Templates are the only good way to show that the uploader has more content to offer - User-specific templates are some of the most important templates, because it lets you know that there is more in a series from a specific person. It lets you know that that uploader has a presence on Wikimedia/Wikipedia larger than this single photo and opens you to more photos or galleries or similar images. Many Wikimedia Commons power users and uploaders have these authorship templates, which is what lead me to their pages in my early days on Wikimedia. When I see a photo taken by someone, I want to learn more about how they did it and why, because that inspires me to take photos. Without this, I might have not gotten into photo taking in the first place.

- The Media Viewer divorces the uploader/photographer from photos - By reducing authorship to a text field, an uploader's importance is effectively divorced from the photo. Considering that it's already a losing battle for authorship when people take photos from Wikimedia and use them without accreditation, to have the role be so minimal on the actual page is so insulting it makes me want to walk away from Wikimedia entirely. There is now even less of a draw for people to upload quality content to Wikimedia. Given the state of Wikimedia's terrible ability to bring in good photographers, something that drastically reduces that is enough to rethink about the Media Viewer's implementation.

- The Media Viewer creates little incentive for people to upload dedicated content - It's a tall order to devote your time to a project like Wikipedia/Wikimedia for free, but even more so for created content like photos. Photos are a different beast than article editing, because while text editing is community driven and very malleable, photos are extremely definite. Photos created and uploaded to Wikimedia are solely owned by the original photographer and have to be explicitly given away by that person. These photos can require a lot of resources and money to create, depending on the quality of photo produced. And while the resulting product can possibly have a commercial value beyond the site, it is still required to be given away for free forever by being put on Wikimedia.

Given that relationship, the least some people (like myself) would ask for is something on the infopage that shows authorship, like a user-created template. The Media Viewer and its desire to reduce authors to footnotes is like a kick in the teeth. Wikimedia is already very unfriendly to people producing quality photos, but this could easily be seen as the end of the line. If it not for the fact that I was already indebted to creating content because of my Kickstarter obligations, then I could easily see myself giving up producing content for Wikimedia based on these policies. It's a dangerous game to impose more restrictions when the site is already hurting enough for quality content, as is.

- The Media Viewer will damage relationships with GLAM institutions in the same way - I have spoken to other WIkipedian's-in-Residence and people involved with the GLAM movement and the Media Viewer is a disaster for these people as well. Much like how the Media Viewer creates little incentive for photographers to upload their own work, Museums will also have less reason to do so given the Media Viewers gutting of information and metadata. Many museums have complex licences and rules for putting photos of their collections onto Wikimedia, and require special templates for such. It is already very hard to convince these institutions to bring their extremely important, high quality, educational work to Wikimedia for a number of reasons. When you approach a museum you have to sell them on the positives, like how people can see that the image belongs to a museum or a collection and use that to generate interest back to the museum. This has largely been done through templates and many of these templates exist already and are on pages right now. These will all be gone now with the media viewer. If someone from a museum wants to look at Wikimedia content to see if they want to bring their collection to the site, they'll see the media viewer and decide that it is not worth it for them.

- User and community templates are too important to lose - Again, for the reasons above, the templates that already exist and are currently on pages that are too numerous and important to be cut out. This drastically reduces the ability of Wikimedia as a platform and cripples the information on the site. Content will have to be designed around the Media Viewer and we all know that this won't happen. By solving a very minor problem the Media Viewer has now added to Wikimedia's already-massive problem: context.

- The number-one problem with Wikimedia is context - We have so much good material on Wikimedia that will sadly never be found or used. Why? Because it was massively dumped onto the site with little or no context. When someone takes a massive collection of photos from an institution and uploads them to Wikimedia, that creates an enormous backlog of work. We're still wading through massive collections of photos that have bare or useless descriptions, are not well categorized, are not placed in articles, or are separate from other photos that provide context for the photo in the first place. People who have spent valuable time working on this huge and relatively thankless task of doing this will often use templates for this, and all of that work is gone.

- The Media Viewer is not good for Wikimedia or the site - Given this big list of problems that the Media Viewer now creates for the honestly trivial good it does, the Media Viewer is not something that should be used on the site. It literally does so little at the cost of so much that I can't believe how tone-deaf its production must have been. Talking with people at Wikimedia, the implementation came as a surprise to them. It came as a surprise to me! The amount of people working in GLAM or working to create large amount of good content for Wikimedia is so small it's a wonder that none of them were apparently asked for input until the Media Viewer was rolled out. I think that the Media Viewer certainly shows this by its massive problems.

To end this, I think that the Media Viewer should not be used or should only be a tool enabled for spefically created galleries that will work with its shortcomings. My recommendation is for tools that work on the presentation of data at the category level, or make it easier to create galleries. We need to work on creating context and relationships between pictures, to make them easier to find in searches, to make adding this data to photos easier. The last thing we need is something that removes it. --- Evan-Amos (talk) 17:46, 2 June 2014 (UTC)Reply

What about the main problem about it ? The interface is just horrible, i'm using a PC, not a goddamn 3 inch smartphone ! So please give me an interface that does not feel like it was made for a phone ! Plus, i just want to be able to see images in their full size with my own software (an ad on that i chose for chrome specifically for being much more convenient to use, or even the default browser viewer, which is still 10x better than the full screen mode we're provided with), and the overall feeling is just horrible. Do people actually test out and look at their creations with a neutral point of view before imposing them for other people to suffer ? 122.106.86.0 14:26, 6 June 2014 (UTC)Reply

Account-Holders Only Need Apply

Latest comment: 10 years ago5 comments5 people in discussion

I am curious how you reached consensus to require an account to disable this feature, instead of requiring an account to add it to the user experience. Is it possible that the method you used for feedback was flawed? Your project page cites a survey with 1727 responses prior to roll-out. Is it possible that your response-base might have been heavily (or entirely) weighted toward project participants along with their friends and family, a group with an emotional investment in the tool? In contrast, the post-production feedback shown on this page seems overwhelmingly negative.

I use Commons frequently and do not use an account because it's a hassle; cookies and site data are constantly purged from my heavily-locked corporate system. Did participants in the survey have accounts? I'm guessing that they did, implicitly excluding the very majority on whom this is imposed by fiat. I am most interested in the response from Keegan to MMO: "Media Viewer is primarily going to be a tool for non-editors..." It is a delightfully-phrased self-fulfilling prophesy: Those without accounts are not editors (by definition) and only account-holders can turn it off (by design).

One last note: "Many users do not notice right away that they can click on the 'X' button or press 'escape' to close the Media Viewer," a quote from the survey page, is a maddening and ludicrous statement. All that button does is take you back to the page from whence you came, not close this intrusive and difficult tool and take you to the image page. In fact, without an account, I am unable to find ANY WAY AT ALL to get to the image page itself! All roads lead through this well-meaning tool. 159.53.110.143 18:36, 2 June 2014 (UTC)Reply

I totally agree with you. And I would like to add that the guys at the WMF look like they give it for granted that all the people who don't like the Media Viewer it's just because they are too conservative. --2.112.192.13 14:42, 4 June 2014 (UTC)Reply

This can be disabled? HOW????? I believe the page you want is hidden on the right immediately beneath the black field containing the image - tehre's a tiny Commons symbol there that leads to Commons (took me 2 visits to find it). Yngvadottir (talk) 21:36, 3 June 2014 (UTC)Reply

@Yngvadottir: To disable it, go to Special:Preferences#mw-prefsection-rendering at each wiki, and unmark the checkbox in the "Files" section that says "Enable Media Viewer" or "Enable new media viewing experience" or similar (depending on the wiki/language). Quiddity (WMF) (talk) 21:49, 3 June 2014 (UTC)Reply

@Quiddity: THANK YOU for so vividly making the point that is, indeed, the title of this thread. You can't do what you describe unless you are logged in with an account, something that many user cannot or will not do. Cheers! 159.53.78.142 16:17, 6 June 2014 (UTC)Reply

Blurry image

Latest comment: 10 years ago3 comments3 people in discussion

The Media Viewer looks quite nice. There's, however, a thing that bothers me: When an image is loaded, it's first displayed as a scaled-up, extremely blurry thumbnail. Then, after a few seconds, it's loaded in acceptable quality. Users often aren't very patient - I think it's quite possible that some will have clicked the image away, thinking "horrible quality!" before it's fully loaded. And who wants to see such an image mush, anyway? What's the advantage? It seems to me that it would be preferrable to either just have to wait the few seconds for the image to appear (without the blurry "fullsize preview"), or have the image load the traditional way, filling the screen from the top as it loads. Gestumblindi (talk) 20:20, 2 June 2014 (UTC)Reply

Showing some "preview" makes the image loading feel faster. Browsers display a part of the image for the same reason (actually they do display the whole image immediately in a smaller resolution if they can - that's called progressive rendering, but needs specially prepared images); that would not work well here, because MediaWiki might need to do some extra stuff before it can start sending the image, so you would stare at an empty screen for a while. We show a very prominent progress bar to make it clear that the image is still loading. --Tgr (WMF) (talk) 23:45, 3 June 2014 (UTC)Reply

I can imagine high quality photographers are scared seeing a blurred version of their magnificent photo. Other sites have a progress indicator overlay so it's more obvious that the full size is still loading. That said, the MV team is really engaged to make thumbnailing faster: Their plan is to pre-render thumbnails directly after uploading and storing them in our MediaStorage; however there are space limitations for so many thumbnails currently but this is being worked on, as far as I understand. They also consider other means for making thumbnailing for extremely high resolution images faster: Storing some intermediate sizes and thumbnail from them. You see they are not idle :) -- Rillke (talk) 21:33, 10 July 2014 (UTC)Reply

Beautiful

Latest comment: 10 years ago1 comment1 person in discussion

Wow! Nice job. This makes up for the visual editing thing before. It works so well on the iPad. Can't wait to test it on iOS 8 when it finishes installing!

Keegan (WMF) (talk) 21:51, 3 June 2014 (UTC)Reply

well it looks pretty horrible on everything else, take you stupid apple shit and shove it where the sun don't shine, but before that get rid of this steaming pile of shit! Ed Poor

Seriously less good

Latest comment: 10 years ago4 comments2 people in discussion

As someone else says above, this takes ages to load, which suggests it may not work at all on a slow connection or when my computer is otherwise busy. Meanwhile, it gives me eyestrain. The information I generally click on an image to see - the Commons information - is hidden away in tiny print and the first time I was confronted with this format, I failed to find the icon at all. Most recently I just clicked on an image to see whether it was protected and am still none the wiser; it's included in that category, but is it actually protected?? Where's the history, so I can check? For that matter, how would I protect it if I needed to? Please, please, please stop changing the interface from something functional to something spiffy that requires a brand-new computer and hides everything away. And don't tell me 6-point type is editor-friendly either. Yngvadottir (talk) 21:33, 3 June 2014 (UTC)Reply

Yngvadottir: thanks for the honest critical feedback. There is more work to do to make Media Viewer more editor friendly, up to and including better category support, and these improvements will show up in the next version of Media Viewer. I wish you found it more useful as it is now, but hopefully we can make it more friendly for you in the future. As for the load time, there's a funny thing there: Media Viewer actually usually loads faster than a File page, but it seems slower because a little trick about the File page: it only loads when the page is complete. Consequently when you look at a white screen for a second before the File page loads, it seems to be loading faster than Media Viewer, since Media Viewer instantly shows up while the image loads. You can see the metrics comparing Media Viewer and the File page here. Great care was taken to make sure that Media Viewer would not harm or hinder slow connections or limited system resources. Again, I hope you find it useful in the future. Keegan (WMF) (talk) 21:50, 3 June 2014 (UTC)Reply

As someone has since said below, it resembles interface changes on Flickr that have been unpopular. I fail to see the advantage of the change. Also looking elsewhere, I've found out why I was unable to see whether the image was protected: MediaViewer will not show me the page for the image on en.wikipedia. That's a nasty disadvantage - luckily at the Village Pump I was told how to disable it in my preferences (I should have looked there, but after the Visual Ed experience I'd stopped looking there), and was able to see that I didn't need to protect the image. As to load time, it may seem petty of me, but I don't like loading methods that hurt my eyes! Please reconsider making these changes. What on earth are the benefits? Yngvadottir (talk) 22:16, 3 June 2014 (UTC)Reply

From the page that this is the talk page for:

The purpose of this tool is to:

Provide a richer multimedia experience, to match user expectations
Display images in larger size, on the same page as the thumbnail you click on
Reduce confusion when users click on thumbnails (bypass duplicate file info page on Wikipedias)

Again, it's unfortunate that you do not find it useful. I hope that changes in the future. Keegan (WMF) (talk) 22:28, 3 June 2014 (UTC)Reply

Media Viewer sucks

Latest comment: 10 years ago7 comments5 people in discussion

Media Viewer sucks. They should get rid of it. Put your signature below here of you agree. --109.77.179.224 21:41, 3 June 2014 (UTC)Reply

Strong Support I helped write the thing, I know how terrible it really is. Did you know the government implanted tracking devices inside of the black backdrop to log your movements? ;) --MarkTraceur (talk) 23:03, 3 June 2014 (UTC)Reply
- Actually it was the MV-team using Extension:EventLogging, not the Government -- unless Mark or tgr work for both institutions. -- Rillke (talk) 21:39, 10 July 2014 (UTC)Reply

LOL. But seriously, it's a big mistake that's got to go and go fast. can you do a favor and remove it? Millions will thank you. --109.77.184.196 16:52, 4 June 2014 (UTC)Reply

My response was an attempt to teach you that simply asserting an opinion and asking for democratic support won't get you anywhere around these communities - if you have issues with the tool, you should articulate them and then propose solutions. "Remove the tool" doesn't help fix the tool ;) --MarkTraceur (talk) 17:23, 4 June 2014 (UTC)Reply

Media Viewer is broken no matter what you do with it. I do not want it fixed, I want it removed and removed now. It seems that everyone with a brain hates it and wants it removed. Jimbo would hate to see what you're doing. I realize you spent a lot of time working on this but it seems that you didn't even bother to test it. If you keep putting things like this, people will start hating you and sending out death threats (not me though, I'm not that type of person). Again, I strongly urge you and your fellow programmers to remove this feature for the sake of the internet. --109.77.184.196 18:20, 4 June 2014 (UTC)Reply

So uh, what are the issues you're having? Legoktm (talk) 07:47, 5 June 2014 (UTC)Reply

Can't stand the Media Viewer

Latest comment: 10 years ago5 comments4 people in discussion

Personally, I cannot stand the Media Viewer

First, it appears to add nothing to my experience. It provides me with the same information the old image page display did — but lacks the ability to edit the summary, author, source, and date. It forces me to click an obscure, tiny icon on the middle-lower-right (one hardly identifed) in order to access metadata, file useage, file history, or to see which categories the image is in.

Second, it duplicates the file title twice.

Third, the font size in the summary section is so large that I now must scroll about the page to see any summary longer than 675 characters.

Fourth, much of the information about the image is concealed, if the image is a large one. This means I must scroll yet again to see the summary, uploader information, author, source, and date.

Fifth, it's too easy to click on the "image right"/"image left" arrows that pop up... especially since they are right next to the scroll bar uselessly inserted into the image. So now if I'm just a little sloppy moving my cursor about, I suddenly am taken to another image (hardly a user-friendly option). X-ing out of the image takes me back to the Category page — not to the image page, which is where I want to go.

Sixth, the "Use This File" button defaults to the most useless feature ("Download this File"), when most users want to embed the file in a Wiki article.

Seventh, it's not clear to me why the "Share" option exists. Users in the old image page could simply have copied the URL in their location bar in their browser. That information is now obscurbed by excess URL information in the Media Viewer. So no wonder a "Share" tab had to be added! But what "Share" gives the user is nothing more than a bare URL link. Some users want that. But to get actual HMTL or Embed code, the user has to avoid "Share" (which is counter-intuitive) and go to "Embed" — even though "Embed" has a very, very, very different meaning from "HTML Code" and "share as a link".

Eighth, the "Embed" code is not really embedding, it's Wiki-encoded.

Ninth, the "Embed" code forces the user to delete a fairly useless caption. The "suggested" caption creates a file name that merely repeating the file's file name, as well as includes file size information (useless, again!).

Tenth, the HTML "Embed" code is the clunkiest, most user-UNFRIENDLY code I've seen since the early 1990s. Yes, it preserves WikiCommons' licensing and source data. No, no one is going to use that. They're going to strip out all that code. And WikiCommons succeeds....how?

The upshot is: Am I using this feature? Answer: No. I desperately seek to get past it so that I can use the features on the old image display page. As a user who uploads a lot of images from free sites (Library of Congress in the U.S., or Flickr), I find that my most common need after uploading an image is correcting copyright license (to narrow it or correct it) and editing the summary description (to eliminate typos). I can do neither in Media Viewer. My second-most common need is to create a derivative file from an existing one. I cannot do this in Media Viewer. I have to use the original image display page.

Media Viewer seems designed to accommodate users who know next to nothing about Wiki. It seems designed to obscure "frightening" or "scary" amounts of information that might discourage a new user from using the image, and it seems designed to automate useage in such a way as to encourage new users to utilize images more. Frankly, it sacrifices useability in favor of catering to the needs of newbies. It's a swift kick in the head to everyone who actually uploads and uses images. (It seems, amazingly, just like the changes Flickr made to their site in 2013-2014. And those have gone over like a lead balloon, too...) - 68.55.245.12 21:53, 3 June 2014 (UTC)Reply

I see you are calling many things "useless." What could you suggest to make things "useful" and be a bit more proactive with your feedback for the future development of Media Viewer? Keegan (WMF) (talk) 22:03, 3 June 2014 (UTC)Reply

Well you could look at getty images to see how they do it (basically move the information with place below the image to the side of the image). The problem you have is that for most commons work the information comes first and the image is pretty secondary. Sure mediaviewer can and will be turned off but that creates friction with new uses where experienced used aren't familiar with what new users are seeing.Geni (talk) 01:48, 4 June 2014 (UTC)Reply

Yup, sure, Geni, you make a fair point about information first and image second is often the case for Commons work. The challenge is finding the balance between work on Commons and how Commons is being used in general. The click-through stats on pulling up the fold in Media Viewer to see metadata on Commons is only something like 1:300. I'll have to dig to find this metric, if someone else beats me to it, great! I think with the data Media Viewer's use is providing and upcoming work on structured metadata for Commons will help us bridge the gap between the Repository nature of Commons as well as its extensive galleries in categories. As for the friction that can grow in communities when some choose not to adopt new features, that's an entirely different animal :) Keegan (WMF) (talk) 04:01, 4 June 2014 (UTC)Reply

If we would have a Flickr/Getty style description panel in an image view, we could give it state and remember locally if a users wants that panel visible by default or not. Seems like a good idea for a next generation. TheDJ (talk) 12:39, 4 June 2014 (UTC)Reply

Lack of attribution is ridiculous

Latest comment: 10 years ago9 comments5 people in discussion

Click on this image, and the media viewer doesn't even show the attribution line mandated by the license, not even in the further detail below the fold.

I've just spotted the Media Viewer on English Wikipedia. Photographers already bemoan the fact that Wikipedia does not attribute their work on the article page, and must instead click through to the File page. And now attribution is not even shown on the Media Viewer page.

I appreciate what the Media Viewer aims to do, but how can you roll out this feature without getting the basics right? Users can download and share the image without ever knowing how it must be attributed. This is ridiculous. - Hahnchen (talk) 22:37, 3 June 2014 (UTC)Reply

Taking a look further, the cause of this omission is because the licensing template is not inside the information template. There are lots of files where the licensing template is not inside the information template. - Hahnchen (talk) 22:47, 3 June 2014 (UTC)Reply

This is relatively easy to fix. If you look at the file description, you could change the author and source to be more useful for this purpose.

However, a valid point is that there's a licensetpl_attr machine-readable thing that we don't handle currently. Adding support for that, and dropping it in place of the author/source combination, may be our answer here.

I have opened a ticket in our Mingle system that will track this user story. I think we'll be able to take it on sometime this month.

Thanks for the pointer, we love new edge cases that we can help support :) --MarkTraceur (talk) 22:52, 3 June 2014 (UTC)Reply

If there is an attribution line specified, it should be shown in place of the source and author. The source and author fields are correct. Viewers should be able to see the mandated attribution line without having to look below the fold. - Hahnchen (talk) 15:45, 4 June 2014 (UTC)Reply

What file description? Media Viewer turns finding that into a game of "guess where to click" (which incidentally is why its unusable on commons).Geni (talk) 01:04, 4 June 2014 (UTC)Reply

@Geni: Is the problem that you have not yet learned where to click (first square bottom right that when hovered says "More details on "Wikimedia Commons") or is there something else that is obstructing you in this regard ? Also remember that you can open the link in a new tab or window, by using your browser/operating system defaults (often middle click or command, shift or ctrl -click), which automatically bypasses the Multimedia viewer. TheDJ (talk) 12:35, 4 June 2014 (UTC)Reply

Clicking a project's logo takes you that project's main page. That the expected behavior. I know how to avoid activating the mediaviewer its just that it is less effort to switch it off entirely.Geni (talk) 16:12, 4 June 2014 (UTC)Reply

@Hahnchen: This was bugzilla:57460 which has just been fixed (cc MarkTraceur). Jean-Fred (talk) 20:02, 5 June 2014 (UTC)Reply

@Jean-Frédéric: Actually that was only the backend part - Media Viewer still won't use that information until we add another few bits of code. --MarkTraceur (talk) 20:08, 5 June 2014 (UTC)Reply

Well-made feature

Latest comment: 10 years ago2 comments2 people in discussion

Well, for some native inhabitants of Wikipedia-City this may look new and unfamiliar - and in fact it is new. As far as I'm concerned, this feature presents the images in an up-to-date manner, without much of that wiki-meta overhead. A Fresh & modern design, though progressive download could be a little bit faster. --Hedonil (talk) 01:43, 4 June 2014 (UTC)Reply

Glad you like it, and thanks for a pointer where it could be improved. Images will load faster and faster as they are cached for reuse as well. The more likely an image has been viewed and cached, the more likely you are to get a faster load. Thanks again. Keegan (WMF) (talk) 03:40, 4 June 2014 (UTC)Reply

Another 'improvement'??

Latest comment: 10 years ago6 comments4 people in discussion

Can we please make this feature an OPTION on English Wikipedia?? I do a lot of editing and correcting in the file summaries for given images by clicking on 'description', which ~~takes~~ took me directly to commons. That option is gone and now we have to take the long way around the block to get to commons file summaries. ALSO -- some images require a second click to see the largest view available, which came in handy for viewing maps and other images with detail that is not otherwise discernible. That feature is now gone. Last, often times there is other information about the file/subject in the description field, along with 'other versions' which 'were' readily viewable. Poof! That feature also is now gone to English Wikipedia viewers. This is an 'improvement'?? We don't need a slide show feature every time we click on one image. Please make this 'new feature' an option, not an only choice, when we click on an image. -- Gwillhickers

You can turn off Media Viewer on the English Wikipedia in your Preferences, untick the box that says "Enable Media Viewer" underneath the "Files" section. I hope that helps you to keep up with your work. Keegan (WMF) (talk) 03:28, 4 June 2014 (UTC)Reply

Hmm, session data fail. I had more there in response that didn't make it.

Re: full/high resolution - see this section above, particularly the "Update" section from Fabrice. Access to full/high resolution and a zoom feature are not as easy integration as they seem, and they will be approached again in the next cycle of Media Viewer development.

There is still work to do and it will be done, I look forward to incorporating your feedback into v.03. Keegan (WMF) (talk) 03:37, 4 June 2014 (UTC)Reply

@Keegan (WMF): -- For some reason the preferences you linked to were different than mine on English Wikipedia, as I did not have this option under Appearances on English Wikipedia. In any case, I un-ticked the Media viewer via the link you provided and it solved 'my' problem, only. Question: Do we really 'need' this feature? Was there some sort of demand or problem that prompted its arrival? This has caused nothing but problems and uncertainty for many editors. -- Gwillhickers (talk) 04:05, 4 June 2014 (UTC)Reply

@Gwillhickers: Thanks, I disabled it because I don't like it. That said, I don't like it because I care about Commons' categories, and I want to be able to go there in one click to check them out. For most people, including most newbies, the Viewer with it's sleek design may be better, and so I am actually weakly supporting it being a default option. Wikipedia interface needs to be "sexier" to attract "new kids", IMHO. --Piotrus (talk) 08:54, 4 June 2014 (UTC)Reply

@Keegan (WMF): thanks, but how to disable needs broadcast, Media View needs to be described at preferences. The link provided here is the only way to restore the Wikimedia Commons feature, which acts as footnote information to confirm proper sourcing in an article. Thanks for the link here, for me, and thanks to Gwhillickers for cluing me into the fix found only here in this string. Who knew there was something called a "Media Viewer"? At a minimum the innovation should be broadcast in a banner on all editor pages. I have tried twice to 'opt in' using cut and paste to ensure I missed nothing, and failed to open a User page here; the process is another of my disappointments at how things work from the wrong side of the digital divide. "Sexier for new kids" without proper introduction just seems like capricious wild west jerk around.

@Gwillhickers: For this new innovation, it is not intuitive how to get past the blowup enlargement. How did you achieve that? At the minimum there should be a box to click labeled "Wikimedia Commons" somewhere on each image at the English Wikipedia to reach the source data comparable to a footnote, Wikipedia is to be a sourced online encyclopedia, open to everyone. -- see "How do I turn this off?" section below for a confirmation of the problem. TheVirginiaHistorian (talk) 09:17, 4 June 2014 (UTC)Reply

@TheVirginiaHistorian: : please note that in no way, shape, or form is the Multimedia team saying that Media Viewer is supposed to be "sexier for new kids" or any language like that. Media Viewer has a utilitarian function, its purpose is not supposed to be trendy :) Now, as for broadcasting how to disable Media Viewer, sure, there could be better ways that we need to develop without discouraging use, or worse is that people may turn it off without ever really giving it a chance. I've been using it on my volunteer account for nearly six months and now it's weird to me when Media Viewer does not open. I think future developments about notifying users about Beta Features, updates and streamlining communications in general will help with this. If you have thoughts on this process you can always email me or leave me a message on my talk page. Keegan (WMF) (talk) 21:13, 4 June 2014 (UTC)Reply

Media Viewer functions as a discreet page making navigation awkward

Latest comment: 10 years ago1 comment1 person in discussion

Tracked in Phabricator
Task T68116

First, I'll be blunt: I don't care for this new media viewer and I don't see what purpose it serves on an encyclopedia. I use Wikipedia for a fair amount of image research for personal projects, as it's a great way to find things in the commons. As such I often click on images, read their description pages, and figure out if I can use them or not before continuing my research. Not only is the information that was readily available just last week now buried in the fine print, but the "application" apparently functions as a separate page, even though it in no means looks like one. If you close the "application", as you would visually similar applications on popular social and photo-sharing websites, and later hit the back button the navigate to your original search, you find that it takes you to the media viewer. If you've viewed and closed multiple images on a page this can lead to an unnecessarily large amount of clicking to navigate back to a page you thought was immediately previous to the one present.

I agree with you that this is not what a user would be expecting. I have filed a bug report about it. TheDJ (talk) 12:21, 4 June 2014 (UTC)Reply

Great work; please keep it opt-out-able

Latest comment: 10 years ago2 comments2 people in discussion

I think it looks good. The target is pretty clearly the readers as opposed to editors, which is great (they are, of course, why we are here). Since 90% of the time if I click on an image I am doing so to check copyright status, etc, I quickly disabled the viewer as it adds clicks. Please be sure to keep the opt-out option for those of us who are more on the curation than the multimedia/user side of things. Thank you! VQuakr (talk) 07:40, 4 June 2014 (UTC)Reply

It shall remain opt-out :) Keegan (WMF) (talk) 20:48, 4 June 2014 (UTC)Reply

How do I turn this off?

I don't like it. How do I turn it off? I don't have an account on Wikipedia so I can't do that whole going into Preferences thing. (And I don't intend to get one just for this.) — Preceding unsigned comment added by 68.116.85.62 (talk) 08:37, 4 June 2014‎

Requested wording change

Latest comment: 10 years ago3 comments2 people in discussion

Please could you change "Learn more on Vikipedia Commons" to "Learn more on Wikimedia Commons" in the roll up info bar at the bottom of the page. Many thanks. Philg88 (talk) 08:41, 4 June 2014 (UTC)Reply

@Philg88: , where did you see this exactly, because for me it is currently saying "Learn more on Wikimedia Commons". TheDJ (talk) 12:04, 4 June 2014 (UTC)Reply

@TheDJ: Sorry, I forget now - I see a lot of pics/maps every day. If I come across it again I will let you know. Philg88 (talk) 14:24, 5 June 2014 (UTC)Reply

Argh!

Latest comment: 10 years ago1 comment1 person in discussion

Tracked in Phabricator
Task T67576

Wanted to view an svg file in my browser so I can zoom into it. Now I only get to that stupid viewer and it's really hard to get to the original svg file. It's not a feature, it's a bug. Please fix it asap! — Preceding unsigned comment added by 2a02:2028:1f1:a231:818b:2e2c:aa5:8d4c (talk) 08:58, 4 June 2014

There is an outstanding bug report for this and some related discussion a bit higher up on the page. TheDJ (talk) 12:09, 4 June 2014 (UTC)Reply

How the media view put a donation of 100,000 high quality educational images at risk

Latest comment: 10 years ago6 comments3 people in discussion

During a meeting last week with the Digital Images Library at the Wellcome Trust, the largest and most powerful charity in the UK, we put up a draft project page and some test images as they were currently viewable on Commons (not using my account, nor my machine, but one supplied in the meeting room). The poorly rendered image in the media viewing pane (which automatically showed rather than the image page after someone clicked on a test image on the project page) caused the Head of the department to say "yuck", and as there seems to be a bug when using Windows Internet Explorer, there was no obvious link to take us to the image page as the icon that appears to the bottom right of the image pane in Firefox was not displayed on IE. We were unable to examine the image page template being used, or properly discuss the metadata we would need for the 100,000 images due to be uploaded.

At that point, I gave up on the demonstration and we talked in general terms, without referring to what could actually be seen on Wikimedia Commons.

Unimpressive. --Fæ (talk) 10:27, 4 June 2014 (UTC)Reply

@Fabrice Florin (WMF): TheDJ (talk) 11:55, 4 June 2014 (UTC)Reply

@Fæ: did you happen to make note of the OS version and IE version that was being used ? TheDJ (talk) 11:58, 4 June 2014 (UTC)Reply

Sorry, no. It looked like a bog standard implementation of IE, very vanilla. My brief look gave me the impression that the layout was the same as it looks in Firefox, just the icon/link taking you back to the image page has vanished. --Fæ (talk) 16:45, 4 June 2014 (UTC)Reply

I have had some problems with Media Viewer because I have difficulty accessing metadata which I need. I do not know how to articulate my personal problems, but I can say that I have been depending on progress in this Wellcome Trust media donation as they had a lot of content of interest to multiple WikiProjects. I would like for Fae's concerns to be addressed as I and others have already invested a lot in our relationship with this organization, and sudden changes to infrastructure increase the risk that a media donation which could be valued in tens of thousands of dollars could be lost.

If anything less than tens of thousands of dollars is being put into user experience on this project then the problems are are not worth the trouble at this time. Please stay in good communication with the Wikipedia community. Could I have someone who is paid staff working on this Media Viewer project state acknowledgement that they have received a complaint that the Media Viewer Project has potential to cause great financial losses to communities, and to please confirm that their supervisors have a system for calculating the financial impact of harms when rolling out new projects? Thank you. Blue Rasberry (talk) 14:13, 4 June 2014 (UTC)Reply

Dear Fæ: I am sorry to hear that you experienced issues with Media Viewer during your demonstration at the Wellcome Trust. Do you remember if you were logged in on that machine? Currently, the Commons icon linking to the file description page only appears if you are logged in; to address this issue, we now plan to make it available to logged out users as well ticket #429, and aim to release that fix next week.

In the meantime, note that there are two other ways to access the file description page, besides the icon described above:

1) Shift-click or cntrl-click on any thumbnail to bypass Media Viewer and go straight to the file page (see FAQ); or

2) open the meta panel in Media Viewer, scroll down and click on 'Learn more' with Wikimedia Commons icon on the right column (see FAQ).

So my hope is that one of the three solutions above will help avoid these issues in the future, as our users become more familiar with Media Viewer. If there are other issues related to IE, it would be great to get the specific browser version, so we can troubleshoot if needed, as TheDJ kindly points out above.

Thanks for responding here so promptly. The browser was being driven by someone else, it is unlikely to have been logged in, and I tend to avoid logging in on machines I do not control. I find it unintuitive that a basic display tool where most users will be readers rather than editors would behave differently when not logged in, and demonstrations at workshops would often run without being logged in, so a bug like this would tend to hit where it hurts with regard to public visibility (please assume this will be the case for many presentations at Wikimania). I am glad this is being fixed, though I think you should consider this a requirement for testing in advance of release to production, rather than afterwards. --Fæ (talk) 10:29, 5 June 2014 (UTC)Reply

Dear Blue Rasberry: Thanks for your thoughtful comment about this unfortunate incident, which we regret as much as you do. We appreciate your concerns about the possible impact of technology updates on image donations; in all of our projects, we aim to minimize any adverse effects caused by new software deployments -- and try to respond quickly to requests for improvement. As product manager for the multimedia team, I can acknowledge receipt of your complaint and confirm that we are taking steps to prevent these issues, as described above. We will also pass on to our supervisors your request that the foundation calculate the financial impact of technology changes we make; my personal view on this point is that it may not be practical to implement, due to the high frequency of such changes and the speculative nature of such estimates. But I can assure you that we take issues like these very seriously, and that we will continue to exert our best efforts to reduce their impact on our communities, as we keep upgrading our aging infrastructure. My hope is that the Wellcome Trust will accept our apologies for any inconvenience this software update may have caused, and that they will reconsider your proposal; please remind them that Wikipedia is a work in progress and that issues like these are not uncommon on the Internet, but that we all work together in good faith to address them as quickly as possible. Thanks for your patience and understanding. Fabrice Florin (WMF) (talk)

Far from happy with the change- we need non.svg files eg png jpg gif, captions for the pictures and choice of sizes to download

Latest comment: 10 years ago3 comments1 person in discussion

new design would be ok if the non svg files were available to download with the same choices of size and with picture captions — Preceding unsigned comment added by Zigzag30 (talk • contribs)

@Zigzag30: could you please try to describe your problem a bit more thoroughly ? I'm not quite sure if I fully understood what your concern was. TheDJ (talk) 12:23, 4 June 2014 (UTC)Reply

@TheDJ: the captions are still there i see them now. but before today, I was able to view or download any SVG picture file in, usually, png or maybe jpg or gif, and to choose different sizes of the pictures. this is vital to me and maybe others.

@Zigzag30: click the "use this file"-button then pick the "Download" section and select what kind of download you would prefer. TheDJ (talk) 12:49, 4 June 2014 (UTC)Reply

@TheDJ: problem solved, thank you. also, learning how to use this message forum wasn't easy. is there an easy way i'm missing how to do it? had to guess to click on edit contrib and to copy the replyto, i'm only a basic wikipedia user, not a coder

@Zigzag30: unfortunately not yet. There is a different feature under development called Flow that is working on this, but it is a long term project. TheDJ (talk) 13:16, 4 June 2014 (UTC)Reply

@TheDJ: hi, i have just noticed that when i scroll left and right and back and forth between several pictures on one article alot it eats up my browser back pages... ie if i right click my back page button in my browser there are lots and lots of the same wikipedia article page.. which is a pain, making it harder to navigate forwards and backwards through tab history

Can't zoom in on large files with hi resolution

Latest comment: 10 years ago2 comments2 people in discussion

People who come to Wikipedia just for info, often times from just clicking on search results, are now unable to view some images in their full capacity. Take for example an image of a galaxy with a resolution of 15,852 × 12,392 pixels. It has to be clicked on a second time to see the image in its full resolution, but the average viewer with no account, (and the registered editors who have to come here to set their preferences) can't see it in its full resolution. Instead they get the dumbed down media viewer version. Again, was there some sort of demand or problem that made this media viewer an only choice for most viewers??
PLEASE MAKE THE MEDIA VIEWER AN OPTION FOR ALL VIEWERS WHEN THEY CLICK ON AN IMAGE -- NOT AN ONLY CHOICE. Gwillhickers (talk) 14:38, 4 June 2014 (UTC) Gwillhickers.Reply

That 62mb full resolution image just crashed my browser, after a ~3 minute system freeze :/

I agree that Media viewer needs some sort of zoom-function, or possibly a better set of "size options" as Flickr used to have easily accessible, but in the meantime I'd rather get a fullscreen Media Viewer version of that galaxy image, than the 767 × 600 pixels we get by default.

Viewers without an account can still reach the image-page from the Media Viewer, with a single click on the Commons icon at bottom right, or the Commons "Learn more" box if they scroll. Do you have suggestions as to how they could make that clearer? Quiddity (WMF) (talk) 00:48, 7 June 2014 (UTC)Reply

Can't control with keyboard, too slow, impedes browsing, unintuitive

Latest comment: 10 years ago4 comments4 people in discussion

The keyboard cannot be used to browse. The description of an image is primary content which is confined to an internal frame that must be scrolled with the mouse and can't be scrolled with universal scrolling controls. The need to do this cannot be detected without using the mouse if the text does not happen to suggest it's been cut off, and even still one must think to hover over the block of text rather than simply scrolling as universally defined as a window-level interface/control.
- So, the page up and down keys will work as usual. The arrow keys are backwards because of the chevron icon. I have hated this change since we made it, but the product and design teams seem convinced that it's the Right Way To Go. I'll take another whack at convincing them otherwise. --MarkTraceur (talk) 18:11, 5 June 2014 (UTC)Reply
The keyboard controls are unpredictable choices - the part hidden is what would be "below-the-fold" content one could scroll down to see. Content with an unpredictable means of access is content effectively missing. See [1].
The choices of keyboard controls made forbid one from using normal navigation to see below-the-fold content besides at an arbitrary fixed size. If that were implemented it would have revealed to the designer that the controls are reversed to actual browsing direction. Dynamic content is not toggleable, because it's not an optional augmentation of website functionality.
Loading at moderate size instead of dynamically rescaling means one can reliably load images at a reasonable size for when fast page loads are needed, including when one doesn't want to look at the image so much as read the description or download the image at largest size. Javascript unnecessarily hinders this common browsing task.
The information is organized into meaningless divisions. These divisions impose a limitation of growth for all content types placed in a subordinate area - tags and categories are in fact a primary form of navigation for those who use them, and they are regularly used on Wikipedia if nowhere else. In a subordinate position they are difficult to access, and in a non-extreme position they can't be accessed per muscular impulse.
Not easy to identify significance of the divisions by eye and thus know which segments of page will contain information relevant to the reader. Those identifications are most easily done by being able to identify the separation of information types by eye (license sections had graphically identifying segmentation before) and then scan for text headings against one's browsing interests. Eye tracking research shows an F pattern is the placement in which users will try to find these scannable content identifiers and for the content it identified before having to stop browsing and think/recall what they were on that page in order to do. LokiClock (talk) 14:40, 4 June 2014 (UTC)Reply

LokiClock, thank you for taking time to give details, constructive criticism and feedback. Opportunities with categories, displaying various image sizes, and general navigation will be addressed in the next iteration of Media Viewer. It sounds like you might be interested in following the metrics dashboard to see how some of the issues you highlight are showing up. Again, I appreciate your time, and we'll see how your issues can be addressed in the future :) Keegan (WMF) (talk) 04:46, 5 June 2014 (UTC)Reply

Hi LokiClock, thanks for your helpful feedback. At MarkTraceur's recommendation, we have filed this ticket #697 to support scrolling down to access metadata in Media Viewer. This issue has been brought up a number of times before, and it seems worth reconsidering, if we can find a practical solution that could be implemented quickly. To that end, we have encouraged our designer Pau to consider a practical alternative that could enable users to use a keyboard down arrow or other scrolling method to find information with a method they are familiar with. This may require revisiting the current ‘metadata panel’ metaphor and thinking more of a ‘page section’ concept instead. The site Medium.com offers some nice design examples of that could be done: a page can show a fullscreen photo in its top section, and contain more information below that image. We will also review your other suggestions below, but the first one seems to match what we have heard from other users, so we are likely to give it higher priority. Thanks again for your comments. Fabrice Florin (WMF) (talk) 21:28, 5 June 2014 (UTC)Reply

Shift-Click

Latest comment: 10 years ago4 comments4 people in discussion

I definitely like the shift-click option to skip the Viewer. Unfortunately it opens the image in another explorer window. Could it be in the same window instead? --2.112.192.13 14:56, 4 June 2014 (UTC)Reply

That's a native browser behaviour, so while we feasibly *could* modify it, I'm squeamish about the idea.

You could also control-click on the thumbnail to open it in a new tab in most modern browsers, or right-click on the image and choose "copy link location" to put the URL wherever you'd like.

Any further modifications to click behaviour would need to be on a client basis...you could probably pull this off with a gadget, e.g., though "officially" we don't have any real framework for addons and modifications :) --MarkTraceur (talk) 16:13, 4 June 2014 (UTC)Reply

Also middle-button-click opens in a new tab in most modern browsers. --Tgr (WMF) (talk) 21:11, 4 June 2014 (UTC)Reply

Use Opera. Right-click->Open means "open in this window, regardless of what the website wants to do". It's such a handy feature, I'm amazed no other browser has copied it. --Carnildo (talk) 00:33, 5 June 2014 (UTC)Reply

I hate it, it gets in the way of what I'm actually trying to do

Latest comment: 10 years ago2 comments2 people in discussion

Like so many others above, I hate it. It conceals the actual name of the file, which is usually what I'm after, and I have to ferret around for it. :-( Bishonen (talk) 15:13, 4 June 2014 (UTC).Reply

Thanks for giving it a shot, Bish, and letting us know what didn't work for you. Media Viewer will continue development in another cycle and we'll revisit things like this. I trust you managed to turn it off? Keegan (WMF) (talk) 21:22, 4 June 2014 (UTC)Reply

A usability disaster

Latest comment: 10 years ago1 comment1 person in discussion

Whoever came up with this abomination has no idea what they are doing.

Images with white or transparent background look horrible in this. I did not even realize that those were categories below the upload date. What is it with the useless bumping, fading and sliding in of white boxes with giant fonts? And why does the "Learn more" link look like it is in a search box?

I have seen countless improvements on the web over the last 17 years (especially on Wikipedia), and this is definitely not one of them. Wikipedia is not a slideshow.

-- 79.253.58.136 16:23, 4 June 2014 (UTC)Reply

PS: The fact that the spreadsheet of the survey is hosted on Google Docs, the survey itself on Surveymonkey and the feature list on Thoughtworks speaks volumes. There is even a "Share on Twitter" feature in the foundation's Multimedia Vision 2016. Seriously, if that is your vision of where Wikipedia should be heading, then you guys are f'ing this up, and you need to stop.

PPS: Off to writing a browser extension that disables Media Viewer by default.

Terrible for teachers

Latest comment: 10 years ago1 comment1 person in discussion

Hello. I can appreciate innovation and trying new things, but only if you know when to kill it. It has actually been a topic of discussion in my school district, and the general consensus is that it takes way more time and effort to find information, and that it just doesn't add any value whatsoever. It seems like a decent option for tablets or specifically for children, but overall this feels like innovation for the sake of innovation. Very sad to see wikipedia following that trend. I hope it gets killed soon.

What information were you trying to find ? Perhaps we can make it easier to find. TheDJ (talk) 08:53, 6 June 2014 (UTC)Reply

Don't like it

Latest comment: 10 years ago2 comments2 people in discussion

It takes too long to load, lacks important information, and I often get Error messages. It may be better eye candy on some systems, but it definitely should not be on by default. Chris Fynn (talk) 17:08, 4 June 2014 (UTC)Reply

Hey Chris Fynn, could you let us know what browser/operating system you are using that might cause these error messages? Keegan (WMF) (talk) 17:32, 4 June 2014 (UTC)Reply

Hate it

Latest comment: 10 years ago2 comments2 people in discussion

I can't get to the page I really want to view. Please revert ASAP! --66.41.154.0 21:01, 4 June 2014 (UTC)Reply

Access to the File page if you do not have an account or are not logged in will be much more accessible in short order. Keegan (WMF) (talk) 21:15, 4 June 2014 (UTC)Reply

Awful

Latest comment: 10 years ago2 comments2 people in discussion

You finally convinced me to log back into my wiki account just so I could disable this awful change. Just like the search bar change of a few years ago, Wiki is going the route of Firefox, from a UX perspective. Saddening. Riffraffselbow (talk) 23:58, 4 June 2014 (UTC)Reply

I haven't logged in in years and I would like to second this. There was absolutely nothing wrong with the way that it was set up previously. Teak the Kiwi (talk) 08:25, 6 June 2014 (UTC)Reply

Unanswered questions

Latest comment: 10 years ago4 comments4 people in discussion

This will be the third time I am asking this question: -- Was there some sort of demand for this viewer, or was there some sort of wide spread "problem" that needed to be 'solved' that brought about this viewer? i.e.Why was this viewer forced on everyone?

Most importantly, is this viewer going to remain the default viewer much longer?

-- Gwillhickers (talk) 00:45, 5 June 2014 (UTC)Reply

Hey Gwillhickers, I've asked Fabrice to give you a proper response. He is the product manager for the Multimedia team, and the best to address your questions. Keegan (WMF) (talk) 04:31, 5 June 2014 (UTC)Reply

Issues with previous viewing experience

Multimedia Vision for 2016

Hello Gwillhickers: thanks for your candid questions about the rationale for the Media Viewer and long term goals for this tool. I will respond to these questions one at a time.

This new tool was developed to support these goals:

Provide a richer multimedia experience, to match user expectations
Display images in larger size, on the same page where you click
Reduce confusion when users click on thumbnails

Up until now, viewing images on Wikimedia sites was a frustrating experience for casual users: when they clicked on a thumbnail in an article, they were taken to a separate page where the image was shown in medium size and surrounded with a lot of text information that was confusing to readers. That page was a duplicate of the file description page on Wikimedia Commons and couldn't be edited: you had to click one more time to go edit file information on Commons. When users landed on Commons, they had no idea where they were or how they got there (see diagram to the right). To be frank, it was a pretty bad user experience, by modern design standards.

To address these issues, Media Viewer now displays images in larger size when you click on their thumbnails, as an overlay on the current page. To reduce visual clutter, all information is shown below the image, and can be expanded at a click of a button, with prominent links to other details. Usability studies suggest that Media Viewer provides a more immersive multimedia experience, right where people expect it. They tell us they can see the images more clearly, without having to jump to separate pages -- and that the interface is more intuitive, offering easy access to images and key data.

To answer your second question, we plan to keep Media Viewer enabled as the default viewer going forward, based on overwhelming user response. It has been tested extensively around the world, and the feedback collected from over ten thousand users suggests that this tool is useful to 70% of them, as outlined in these survey results. Moreover, the rate of favorable feedback keeps increasing across all languages over time. In the past six months, tens of thousands of beta users tested the tool extensively since it was introduced as a beta feature in November 2013 -- and their feedback was used regularly to improve the tool. Based on these findings, Media Viewer is now being enabled on all wikis, as described in this release plan.

Last but not least, Media Viewer is strategically important for implementing the three-year multimedia vision that guides our work. Besides improving the viewing experience, this tool will needed to provide a range of other contribution, curation and editing features over time (such as the 'thanks' tool shown in the thumbnail to the right). I hope this answers your questions. Thanks again for contacting us about this project. Fabrice Florin (WMF) (talk) 07:47, 5 June 2014 (UTC)Reply

Is there any evidence that supports the thus-far unsubstantiated assertion that the conventional image metadata page was indeed "a frustrating experience for casual users" or that readers often regard encountering "a lot of text information" to be a "confusing" experience? After all, the entire purpose of a wiki - and especially Wikipedia - is to convey complex information in an organized and comprehensive way, and to do that primarily via the medium of text. It'd be fairly astonishing to me to discover that people who visit Wikipedia to use it for its explicitly intended purpose would somehow be bewildered by exposure to comprehensive text-based information.

Images are typically embedded into Wikipedia articles to exemplify the information being discussed in the text, and are generally uploaded to the Commons precisely in order to be used as article content. Why, then, is this new media viewer apparently designed under the assumption that images embedded in Wikipedia articles are standalone content intended to be viewed for their own sake? This interface might be appropriate for a site like Flickr, where images are indeed standalone content, and are organized into galleries that users browse in sequence, but that clearly isn't the use case of images in this context.

When I click on a image in a Wikipedia article, I'm generally after more detailed information about the image, or seeking to re-use the image elsewhere, or looking for other related metadata. I'm certainly not interested in merely looking at the image in a more "immersive" way - whatever that means. Having to take extra steps to bypass this unnecessary UI cruft just to use the wiki for its fundamental purpose - accessing information - is the real "frustrating experience" here. (And, note, I'm a "casual" enough user that I don't even have an account - but I was annoyed enough by this usability regression to come post here.)

BTW, this is the first I've heard of the "multimedia vision" you're alluding to, but I find the existence of such a thing very concerning. There's a noticeable trend of leaders of open-source/open-content projects attempting to behave in an increasingly cathedral-like manner, and it seems to be especially prominent in projects that have large, formal institutions behind them, e.g. the Wikimedia Foundation. I hope that users will regard the attempt to shoehorn open-content, community-driven projects like Wikipedia into grand, top-down visions to be a product of organizational pathos, and aggressively prod developers to focus on work for which there's manifest bottom-up demand, rather than stand by as they yield to intra-organizational groupthink. 108.132.212.98 18:19, 5 June 2014 (UTC)Reply

No sir, I don't like it.

Latest comment: 10 years ago2 comments2 people in discussion

Like many others, I find this change to be awkward in terms of usability, not to mention that it's ultimately unnecessary. I disabled this new feature immediately. The way it was before — going straight to the image page, which contained all the necessary info as well as various options on file size and type (when available) — has worked perfectly fine in the nearly ten years I've been coming to this website. If it's not broke, don't fix it. JGoodman (talk) 02:54, 5 June 2014 (UTC)Reply

@JGoodman: The image-page wasn't "broken", but it also wasn't great. Logged-out readers were all served an off-center 800px wide image, with no easy or consistent route to obtain a "full-screen" image. Then if they clicked the image at the image-page, and it was, for example, an 18mb or 85mb or bigger original, they'd start downloading that. Whilst the new Media Viewer isn't perfect, it can improve even further if we give the team suggestions for improvements, whilst keeping in mind the diverse (planet-wide) set of users, who each have different expectations and desires. Ie. Could we change one thing to help editors, and another thing to help re-users, and another thing to help the readers who don't want to see a stack of complex templates? Users on tablets, users on widescreens, etc. Suggestions are appreciated! Quiddity (WMF) (talk) 23:39, 6 June 2014 (UTC)Reply

This is So Bad!

Latest comment: 10 years ago2 comments2 people in discussion

You can't zoom in on pictures any more. It's just useless eye candy, costing resources while delivering nothing useful. And it's impossible for people who aren't editors to avoid using this thing.

And, by the way, which idiot was reponsible for letting a private company run the survey? I might trust Wikipedia to leave a cookie or run a script on my machine, but only someone who is remarkably ill-informed would trust Survey Monkey. Are you deliberately following in Google's footsteps?

Anyway, unless someone signs up as an editor, they can't get rid of this tiresome "improvement". Please go back to how things were, as quickly as possible.

Thankyou.

The zoom feature as well as view in other sizes, including full resolution, will be an integral part of the next cycle of Media Viewer development. There were attempts to implement these features in this version, but we did not feel that they were of the quality that is deserved. Media Viewer will continue development in coming cycles and we will work to address this. As for Survey Monkey, that's not something that I can address effectively; it was also mentioned in a section above. @Fabrice Florin (WMF): ?Keegan (WMF) (talk) 04:40, 5 June 2014 (UTC)Reply

So basically what you are saying that you forced an Half-Finished Version on every body. Let me be very clear, those who designed it might be good web designers but they definitely don't know what we common Wikipedia users want. You might be associated with WMF but that doesn't mean that you know what everybody wants. This design is too loud, it's too annoying and completely hampers my Wikipedia reading experience.Also i can't zoom in the pics at full resolution, and what survey do you constantly talk about, can 7000 people who actually responded to some unknown survey decide what is better for one of the largest community on the internet, and mind you no average internet user in their right mind will reply to some private survey company. So until and unless you guys finish and fix this monstrosity, please take it back from our screens. Oh and in light of transparency, please release the results of this so called "Survey" for the community to see. 117.254.53.167 18:44, 6 June 2014 (UTC)Reply

This thing is awful

They say the Devil finds work for idle hands. I can only assume that your programmers have not had any real problems to work on. — Preceding unsigned comment added by 76.102.36.28 (talk) 04:34, 5 June 2014‎

It looks like tablets are to blame...

Latest comment: 10 years ago2 comments2 people in discussion

Originally, what really bugged me about the new Media Viewer was the fact that I had been stripped of the ability to view an image in it's entirety. This new tool would no longer allow you to view high resolution images. Arguably the main reason why a user would choose to click on an image is not to view the metadata behind it, but to view a larger version of it, allowing him to pick out more detail that would have otherwise gone unnoticed. Although this did rub me the wrong way, I did later learn that I could opt-out of it entirely (of course, I had to be logged in first). All's well that ends well, right? Well, no. There was still something else that bothered me about it, but I couldn't place my finger on what. Then it hit me: It's now apparent that even Wikipedia is not immune to optimization for tablet computing.

Although this tool would be great for a tablet, as pointless as they are, it leaves PC users to suffer. Unfortunately for most organizations that opt to reorganize their websites around this emerging market that may possibly (and hopefully) have no future, most people don't have a tablet computer. Be that as it may, these organizations are so optimistic about tablets that they're simply not willing to respond to consumer outcry that their favourite websites are becoming clunky, Metro-style disasters. I hope that those in charge of the Wikimedia Foundation will remember this simple, but elegant, truth regarding consumers: If they don't like it, they'll take their business elsewhere. Now, seeing as I don't have to use this new feature (again, I have to be logged in first), I'm not suggesting that this new Media Viewer tool will stop me from using Wikipedia entirely, but it does signal that more changes are sure to follow. The more you add such sudden changes to a site, the less people will use it. After all, does anybody really visit Myspace anymore? They were but one of many sites that chose to focus on form at the expense of function. However, in almost every other discipline on the planet, function trumps form every time. Form can be a major impediment to function. It can make something difficult or annoying to use, increase the likelihood of bugs or glitches, or this relentless pursuit of form could simply cause the developer to overlook function entirely. Yes, the old way of doing things wasn't pretty, sleek or "sexy", but it worked. If people insist that you make your website tablet-friendly, there is always the option of creating an app that is purpose built for tablets. Facebook chose to do this, and avoided the problems of having to radically change their website entirely. As more websites strive for beauty at the expense of efficiency, I would urge the Wikimedia Foundation to keep it's websites ugly, bland, and, most importantly, functional. --EbolaRocks08 (talk) 05:11, 5 June 2014 (UTC)Reply

EbolaRocks08: There is not a lot for me to say other than thank you for taking the time to write out critical, constructive feedback. Media Viewer will continue to be developed, and it is feedback like yours that will help us in the next go-around. Being able to zoom in on and image as well as viewing the file in full resolution or different sizes is a high priority for the next release. I do know that Media Viewer is not about tablets or mobile viewing. While by far the most rapidly growing platform, mobile still only makes up for about 25% of Wikipedia traffic. Desktop/laptop viewing is just as important as mobile. Do let me know of any other ways you think Media Viewer can be improved to make it a more effective and educational tool for viewing files. Keegan (WMF) (talk) 06:09, 5 June 2014 (UTC)Reply

This new media viewer reminds me of Flickr... and that's not a compliment!

Latest comment: 10 years ago1 comment1 person in discussion

I visited Wikipedia today to seek out a photo I could legally reuse and was greeted by this new "Media Viewer" interface when I click on a photo. I strongly dislike it. It took me considerable time to find where I could download the original size photo. It is not easy to access. Since Wikipedia is based on creative commons and public domain material, it should be extremely easy for people to find where they can download materials. Furthermore, the overall interface reminds me of Flickr's recent redesign which is also horrible. Less content, overly large interface graphics, lack of actual information presented to the user, and difficult to navigate. It is overly simple and appears designed for phone users. A lot of us still use old fashioned Laptop computers, and even a few of us might even use *gasp* a "Desktop Computer" and it is frustrating to see the needs of such users dismissed.

Please see my comment just above this section. Thank you for taking your time to let us know what you think. Keegan (WMF) (talk) 06:10, 5 June 2014 (UTC)Reply

STOP IT

Latest comment: 10 years ago1 comment1 person in discussion

Slow rendition, surprisingly troublesome pop-up effect, confusing and unimportant infos all around. Give it up, folks, give it up. --130.34.157.13 06:27, 5 June 2014 (UTC)Reply

Some issues

Latest comment: 10 years ago2 comments2 people in discussion

Tracked in Phabricator
Task T68247

So I go here.

It lists the file name minus the ".jpg" and then under that it says "Unknown." Unknown what? On the normal page it describes the "Author" as "Unknown". That's clear enough, but the mediaviewer page is not telling me what this "Unknown" is supposed to describe. It continues onto "Immediate source" but cuts this off with an ellipsis. Further down it says "License details / See below." But there doesn't appear to be anywhere below where these license details occur. Firefox 29.0.1 Windows 7 64-bit SP1. --Atethnekos (talk) 09:08, 5 June 2014 (UTC)Reply

This is a bit of a problem yes, we should find a way to make this a bit clearer in cases like this. TheDJ (talk) 08:50, 6 June 2014 (UTC)Reply

Meh, Was This Really Necessary?

Latest comment: 10 years ago1 comment1 person in discussion

I understand that you guys are trying to make a more streamlined and cleaner appearance with a better user interface to make the experience easier for users like me. However, I myself had absolutely NO problem with the old interface and actually saw no reason for it to change in the first place. It was simple, understandable, and gave readers all the information they needed on the file. I'm not against change in anyway but if there is so much uproar and negative feedback on this, I would give everyone an option to still use the older interface with the media viewer being just an option. I would recommend this to please people like us and avoid comments like these. I am hoping that my suggestion it taken with serious thought. Ventura19 (talk • contributions) 7:00, 5 June 2014 (UTC)

Ventura19: <nod> all suggestions, comments, concerns, criticisms, you suck, you're awesome, etc. are actually read by me, a real person, and taken into fair consideration. Thank you for sharing your feedback. Keegan (WMF) (talk) 21:35, 5 June 2014 (UTC)Reply

No usefull way to see large panoramas

Latest comment: 10 years ago1 comment1 person in discussion

Very cumbersome or even impossible to look at large panoramas in full size. Most normal users will not be able to see them properly. It would be better to enlarge it by clicking on it. Improve this viewer or delete it. --Milseburg (talk) 12:01, 5 June 2014 (UTC)Reply

Petition to revert to the original format

Latest comment: 10 years ago4 comments3 people in discussion

Sign your name here if you want to revert to the way it was before media viewer. Don't forget to add as much as possible.

Random wiki user. --109.77.184.196 12:12, 5 June 2014 (UTC)Reply

Just a note. There's nothing to stop random (IP) users from voting more than once. For this petition to have any credibility only registered editors who have been active for at least 30 days should weigh in, which it seems they already have. Appreciate the effort though. -- Gwillhickers (talk) 16:44, 5 June 2014 (UTC)Reply

Don't worry, I won't sign it more than once but I still encourage a lot of signatures. --109.77.184.196 16:59, 5 June 2014 (UTC)Reply

@Gwillhickers: Don't worry, this IP wasn't clever enough to get a new address since their last petition attempt, so I doubt it will be an issue here. :) --MarkTraceur (talk) 18:22, 5 June 2014 (UTC)Reply

Being fair to everyone

Latest comment: 10 years ago16 comments10 people in discussion

@Fabrice Florin (WMF) and Keegan (WMF): : Mr. Florin, thanks for taking the time and answering my questions above: I'm finding it a little difficult to accept this 70% approval figure, as the overwhelming response among English Wikipedia editors and others is that this thing is frivolous, frustrating and not needed, or wanted. On that note, making this viewer the default viewer is sort of like a kick in the teeth in terms of our wants and interests. I would suggest that when this viewer comes into view that a banner asking Disable? [y/n] be presented (with a check box for 'Never ask this question again?') If after a trial period it is found that most users have disabled this viewer, it should no longer be the default viewer, but rather a choice. I'm not understanding why it wasn't presented as a choice to begin with. This would be fair to everyone. As it is, the media viewer still needs a lot of work and I'm still wondering how the viewer was "tested extensively around the world" and still got 70% approval. This finding is not at all consistent with all its faults and the overwhelming disapproval its received on English Wikipedia/Commons. Are you locked in with some sort of contract and have given a large down payment to a software developer and there's no turning back now? In the face of all this disapproval and the fact that you're going ahead with this viewer, anyway, would seem to support that premise. If you can render this new viewer where we can readily view an image in its fullest resolution, with all the categories, other versions, description information, viewable and able to be edited, then you at least will not get my disapproval, and I'm sure that of most other editors. All the best. -- Gwillhickers (talk) 16:32, 5 June 2014 (UTC)Reply

@Gwillhickers: Could you please link to a supporting discussion page for your statement that "the overwhelming response among English Wikipedia editors and others is that this thing is frivolous, frustrating and not needed, or wanted"? We haven't seen that much of an issue on English Wikipedia, and I'm sure it would be helpful to see some of the responses those people are giving. --MarkTraceur (talk) 18:37, 5 June 2014 (UTC)Reply

I was referring to this discussion page, which I believe at this stage, given the many responses, supports my estimation of the Media Viewer's acceptance. Esp since its faults and shortcomings have been articulated with one example after another. I suspect any "approval" for this viewer was made without the knowledge of its many faults and shortcomings. i.e. How could any adult approve of it knowing all it's faults and shortcomings? Simply because it shows pretty pictures in a slide show fashion? -- Gwillhickers (talk) 21:14, 5 June 2014 (UTC)Reply

@Gwillhickers: There are a lot of responses here without any real content, and I'm taking into account that this is on MediaWiki.org instead of enwiki, and that there's some response bias for this talk page. I have seen exactly two threads on enwiki itself, and nothing else. This page is the feedback area for enwiki, English Commons users, developers, and Wikisourcerors as well. You can't necessarily attribute the response here to an "overwhelming response among English Wikipedia editors". If you could be a little more specific that would be helpful. --MarkTraceur (talk) 21:31, 5 June 2014 (UTC)Reply

Indeed; the English Wikipedia alone has 30,000 active editors per month. This page is serving 900+ projects. Some context, @Gwillhickers: , would be nice to have. ~~Keegan (talk) 22:56, 5 June 2014 (UTC)~~ Keegan (WMF) (talk) 22:58, 5 June 2014 (UTC)Reply

Stupid accounts :) Keegan (WMF) (talk) 22:58, 5 June 2014 (UTC)Reply

@Fabrice Florin (WMF) and Keegan (WMF): The "responses without any real content"? I wouldn't be so eager to write them off simply because they didn't reiterate the many real problems other editors have pointed out. And the problems are indeed real, regardless of any "bias" you may think exists. I hardly think editors are objecting to the viewer just because the forum exists here at MediaWiki. That almost seems like a biased claim itself. The discussion for the viewer exists here, which is why we don't see it much elsewhere, and the complaints continue to roll in, below. Easy math guys. In any event, the viewer should be offered as a choice, and as I said, if enough people disable it as the default viewer, then we should follow suit and offer it as an option when people click on an image. That would be fair to everyone. As it is, the media viewer was made the default viewer with all its faults and shortcomings. Not fair. -- Gwillhickers (talk) 01:19, 6 June 2014 (UTC)Reply

I see 74 discussion threads . Of those, FIVE threads were initiated by happy customers with praise for the product. The other 93.4% start with either a polite complaint, a problem or (frequently) a howl of outrage. I don't really like unspecified terms, but I think @Gwillhickers' "overwhelming" is appropriate here. @Keegan was right when he said this should be discussed based on solid numbers and facts on how communities feel about Media Viewer. Saying that everyone else is "broadly supportive" or "generally pleased" is no more valid than statements you dismiss out of hand as biased that claim "most people" hate it. I join with @Keegan and request that we stop relying on assumptions, innuendo and the pre-release survey in favour of the comments being made now that it is in the wild. Defenders, please provide a summary of wiki-talk comments as follows: Number of threads where originators (not respondents) praise versus criticise the tool. Include every thread on the talk page (not just those you deem significant or substantive) dated after wide release. Exclude only threads originated by participants in the project (whose bias, as @Keegan notes, is undeniable). To balance negativity-bias common to feedback sources, let's set the bar low: If you can show that just 50% of respondents praise the feature, I will consider it a smashing success. If you can show just 33% of responses do not contain a complaint, I would concede that the tool is a good addition to the WikiWorld. If the results show that the supermajority of users have objections, I respectfully submit that the time you spend defending this tool might be better used finding solutions to the problems raised. On the other hand, if you do not feel that such a review of talk pages is worth your time, please immediately cease telling us how everybody else loves this thing and that Wiki Commons & MediaWiki users are being unreasonable... or, as 130.34.157.13 so eloquently put it, STOP IT!. 159.53.78.142 16:14, 6 June 2014 (UTC) (also responsible for above comment posted 159.53.110.143 18:36, 2 June 2014)Reply

Is it possible to collect the statistics on the number of users who disable the viewer? That could provide some hard data on how people actually feel about it. DB (talk) 00:10, 7 June 2014 (UTC)Reply

It is in the plans. --Tgr (WMF) (talk) 00:52, 7 June 2014 (UTC)Reply

@DB: Looked at some large wikis, on enwiki ~500 users disabled it which is less the half percent of the editors who have been active since it was enabled. Other large wikis (de, fr, es) have similar stats - some slightly larger, but all below 1%. --Tgr (WMF) (talk) 20:46, 7 June 2014 (UTC)Reply

I do not have stats but I understand most wiki users do not have or want accounts. They don't edit; they consume. NO ONE who uses a wiki that way can turn this feature off. Those who turn it off are a subset of those who can, and therefore your statistic ignores the massive group who are denied that option. Next up, measuring how many people actively disable the feature is simply not a valid measure of approval, even amongst account-holders. It is simply a measure of how many account-holders as so horrified that they spend time to get rid of it. Those who do not use pesticides do not necessarily love cockroaches. Next, many supporters have asked that we delay discussion until the "natural course of change" takes place and the "I hate it because it's new" reaction fades. Explain, please, why the negative responses are increasing steadily over time. As people really "get used to the new feature", more of them are talking the time to register their frustration and annoyance.

Is it maybe time to at least CONSIDER that this feature should be opt-in? Is it POSSIBLE that Commons users have legitimate concerns about copyright, ease of use and lack of critical features? One last note: Yes, objections to this feature will fade over time. There is no doubt. Objections to anything, no matter how onerous or offensive, fade. Pick your historical analogy from any era where negative but non-lethal changes were foisted on a group -- there is a point where folks realise that they're shouting to the wind or that they're troubles pale in comparison to those under the rule of worse regimes. My question is, do we really want our motto to be "at least we're not as vile as Flickr"? 159.53.46.141 21:02, 9 June 2014 (UTC) (same as originator of this thread)Reply

Sure sure. Continued usability of Media Viewer on Commons is an active discussion and nothing should ever be counted out. However, there are very likely development solutions that could help make Media Viewer a more powerful tool on Commons and much more accepted there. I'd like to see what we can do to help the community with the tool before we just give up and there has been extensive feedback given from Commons contributors about what we can do to make Media Viewer much more useful for them there. More to come in the following days as opportunities to make Media Viewer a better thing are distilled and worked out :) Keegan (WMF) (talk) 22:51, 9 June 2014 (UTC)Reply

My problem is the roll-out plan, not the tool. Many folks will find it a useful alternative. Its value will increase exponentially as you take action on the feedback. One day I might love it. However, the tool was dropped on most users with no explanation. It's not unfair to call it the Windows 8 of the WikiWorld: "No one really wants a Start button any more. We proved that by asking all the folks on our dev team and surveying 17 grandmothers in Paducah. Just leave it out." That is NOT a good reference for change management. Second, the needs of folks without accounts were either never considered or dismissed as irrelevant. Otherwise we could disable the feature without an account or "Classic" and "Viewer" options would have been included. Read just the section titles on this page. Was this really the right way to introduce the world to this tool?
I want Media Viewer to succeed and thrive because anything that helps the WikiWorld grow is a good thing. But it's valid to point out that this is a nearly-unprecedented way to change a fundamental feature. In every other case I can recall -- page templates, changes to wikimarkup, Wikipedia Main Page, categorisation, InTheNews, MyLanguage and a dozen others, all drastically less intrusive than Media Viewer -- it was of paramount importance to leave an option to "use the old way", Primum non nocere. My objection is the team's choice to use what this page's contributors seem to see as a "Father Knows Best" approach. While I do not condone Gwhillhicker's increasingly aggressive tone, can you REALLY tell me with a straight face that you feel his concerns have been addressed? Would YOU accept responses that boil down to "stop whining and just turn it off" or "good point; we'll get back to you around the 32nd of Octember"? And I still don't see any constructive comment addressing non-account-holder complaints, and there are a lot of IP sigs on this page159.53.174.144 17:32, 10 June 2014 (UTC) (Kevin, same as other posts)Reply

159.53.174.144: His concerns have not been addressed. I'm not one to pretend that they haven't, and I've been pushing quite hard to get these issues fixed in some reasonable way, shape or form, and as soon as possible. Fabrice will be posting an update for the community here and on the English Wikipedia within the next hour or so that will, I hope, address his and the concerns of the many others here. I am very grateful that you have gone to lengths to temper your tone and talk about this as politely as possible. As far as the release plan goes and community members not being aware that something this major was coming, I also agree with you that there are better ways that need to be developed to let users and anons (to the extent that it is possible) know about changes. Notifications does not currently support this function and it is vitally important that a way is found, if not using Notifications, to let people know. No number of announcements on Village Pumps or mailing lists will fix this problem and I recognize that and the need for better. With 900+ Wikimedia projects, a better way must be found. Thoughts about this are more than welcome on my talk page, if you have any. Keegan (WMF) (talk) 21:07, 10 June 2014 (UTC)Reply

This small sample of opinions from the English Wikipedia may be revealing on what the community of users think of the whole thing: [2] -- Alvesgaspar (talk) 21:56, 10 June 2014 (UTC)Reply

Link to old style page

Latest comment: 10 years ago5 comments4 people in discussion

The link to the old-style image page, which seems to be essential to access certain features such as viewing upload history, commenting on talk pages, viewing particular resolutions, seems to be available only by clicking on non-obvious and inconsistently labelled links like "View licence" or "Public Domain", or in some cases appears not to be available at all. I find this quite confusing. If the old-style page is supposed to be still available for certain purposes then there should be a clear and consistently titled link to take you there. 86.151.118.43 17:34, 5 June 2014 (UTC)Reply

Hi! We have already heard this complaint a few times recently, and we're going to solve it by adding the link to the file page that logged-in users get for non-logged-in users. This decision was made Once Upon a Time with the rationale that logged-in users would be the primary users of the feature, since they would want to get to the file page to edit the file metadata, or add categories. Now we realize that logged-out folks want to see the file page too, so we're removing the check for logged-in-ed-ness. --MarkTraceur (talk) 18:32, 5 June 2014 (UTC)Reply

Cool, thanks. 86.151.118.43 19:45, 5 June 2014 (UTC)Reply

That's a good decision, thanks from me, too. - By the way, I think that survey results may be misleading: It's plausible that 70% or more of users just want to have a quick look / browse through images and aren't potential re-users, so those may be happy with a simple viewer that hides additional information and download options. But the remaining 30% (or so), those who really want to use pictures, are very important users, too - and those don't necessarily have a Wikimedia account. Gestumblindi (talk) 19:57, 5 June 2014 (UTC)Reply

Seriously. This needs to be a top priority. Having a permanent, consistent, highly-visible, explicit link to the file description page is not an optional feature, it is critical. The first time this thing was foisted on me, I was trying to find the file that an image was derived from, and I clicked about half a dozen different things and never found the right one. I ended up disabling the feature because I literally was unable to figure out how to get to the standard file page with the information I needed - a page that I'd gotten the last several thousand times I'd clicked on a Wikipedia image. I tried hovering, I tried right clicking, I tried clicking on every undecipherable icon on this monolithic black screen of death, and my only option was to find the preference that enabled me to just shut the thing down, placing my Wikipedia experience one more step removed from the default user. Vanisaac (talk) 19:59, 6 June 2014 (UTC)Reply

Resource hungry on older computers

Latest comment: 10 years ago4 comments4 people in discussion

Whilst my computer is over 10 years old, I still expect to be able to browse images quickly whereas this interface is bordering on unusably slow compared to the previous image pages. Keep it simple, there are a lot of people worldwide using older technology. — Preceding unsigned comment added by 80.189.68.163 (talk) 18:16, 5 June 2014‎

I think it would be a bad idea to design everything we do around the lowest denominator platform there is. That is a sure way to end up being no longer relevant. TheDJ (talk) 08:29, 6 June 2014 (UTC)Reply

Yes, I agree completely. Access to information should be restricted to the middle-class of first-world countries. 74.207.250.159 20:45, 6 June 2014 (UTC)Reply

I would conclude exactly the opposite; ignoring everyone who does not adhere to the latest fashions is a sure-fire way to alienate and exclude people and fade into irrelevance. Has everyone become so brainwashed by marketing that adherence to technological fashion is the only way to remain "relevant"? Whatever happened to graceful degradation? Just because a website has pictures doesn't mean it shouldn't work in an ancient text-only web browser. Just because a website has resource-hungry JavaScript doesn't mean it shouldn't work on a relatively under-resourced, older computer. --79.74.105.228 00:51, 9 June 2014 (UTC)Reply

Any details on how MediaViewer is slow on old computers would be helpful. Does the image take long to load? Is switching between images slow? Does the browser become unresponsive? Also, how old is the computer exactly (what kind of CPU/memory does it have)? What OS/browser are you using? --Tgr (WMF) (talk) 08:21, 9 June 2014 (UTC)Reply

Why should is have to be explained to developers? They should have 10 year old computers in their lab. If they still don't get it, they should be forced to develop on 10 yaar old computers, especially since Wikimedia is supposedly a nonprofit. Any moron can develop for the latest workstation, that's just trial and error. Making it work for everyone is what makes it a profession.

False. There's a lot more work that goes into development than just "trial and error," even if it's not being built to work on 10+ year old computers. If you're using Internet Explorer, it is your fault (and Microsoft's fault for building such a horrible browser!) that you don't have an as-good user experience. Also, when somebody is experiencing issues, they should probably explain it to the developers. Why? Because the developers can't fix it without knowing what the issue is (the person that said it is resource hungry gave no details). If you expect people to fix something on a service provided to you for free, you need to give them some details about the issue, the browser and OS you're using, etc. Wikimedia is a nonprofit; that doesn't mean they work for you.

The media viewer discourages users

Latest comment: 10 years ago1 comment1 person in discussion

Get rid of the media viewer because it is cumbersome to use and discourages users. I like to be able to choose the file resolution before I download a file and the media viewer does not allow users a choice. It seems that whoever thought of adding the media viewer might have a financial interest in the software or wants to limit access to free media. This person or people need to be fired ASAP because of the interest they have displayed in discouraging the use of free media. ThelmaLou (talk)

@ThelmaLou: You can download a specific resolution by clicking the 'use this file'-icon (bottom right of the view) and then selection a specific size from the "Download" drop down. TheDJ (talk) 08:25, 6 June 2014 (UTC)Reply

@TheDJ: And why aren't you offered there the SVG version as well, but only the PNGs? It's available under the Commons page (with the misleading text "Learn more about...")

Please return it to original style

Latest comment: 10 years ago4 comments3 people in discussion

In the old style of viewing image, I could select the image size and resolution. Since my vision is impaired, this allowed me to see detail in a higher resolution or a larger size image that is missing in the thumbnail. In this new viewing system, I try to increase the size of the image but a) there is no zoom feature and b) when I hit Ctrl+, the image momentarily gets larger and then snaps back to the small size it originally is. Only the footer is made larger, not the image. This prevents me from being able to read text that is included (like in diagrams or flow charts) as well as details in more intricate images.

How can I return to viewing images in the old fashion? I'm not against change all of the time but this new viewing style actually prevents me for seeing images, outside of a thumbsized or small version. You should consider the needs of those without 20/20 vision who might need the images to be larger. Liz (talk) 21:19, 5 June 2014 (UTC)Reply

Liz, you can disable Media Viewer in your preferences. If you're referring to the English Wikipedia, this is the page. Untick the "Enable Media Viewer" box in the -Files- section.

When Media Viewer is being developed again for the next version, there are plans to fully integrate a zoom feature as well as access to various resolutions/file sizes for viewing. I hope once this is nicely built in, you can turn Media Viewer back on :) Keegan (WMF) (talk) 21:41, 5 June 2014 (UTC)Reply

Sorry, but I am with the opposers to the new Media Viewer. Please don't make it the default, otherwise unexperienced users won't even know that the file information is available! -- Alvesgaspar (talk) 23:26, 5 June 2014 (UTC)Reply

Thanks, Keegan (WMF). I also discovered that there is a circle in the bottom far right hand corner of the screen which will take me to the Commons page where I can view different sizes of the image which is what I was searching for. Maybe it could be better identified because, otherwise, I couldn't get out of the new media viewing page. Liz (talk) 07:49, 7 June 2014 (UTC)Reply

Reformatting file descriptions to be more Media Viewer friendly

Latest comment: 10 years ago6 comments4 people in discussion

Due to the unstructured or semi-structured nature of information on file description pages, the Media Viewer sometimes does a poor job of conveying the information from the description page. For example, in the image of Tank Man, the Media Viewer says "No description available." underneath what appears to be the description of the image, and also doesn't inform the user that the image is under a fair use licence.

My question is, is there documentation somewhere that lets users know how to reformat the information that's on the file description page so that it's readable by Media Viewer? There'd be many such editors willing to do that (myself included), and it'd greatly improve the user experience of the Media Viewer if it could provide more meaningful information for more images.

Thanks!

--Dan Garry, Wikimedia Foundation (talk) 22:59, 5 June 2014 (UTC)Reply

Much appreciated! Basically MediaViewer looks at {{Information }}-like templates, license templates an coordinate templates, as long as they conform with commons:COM:MRD. There is some info on Multimedia/Media Viewer/Template compatibility (mostly aimed at template maintainers and not very user-friendly, though). Fair use is not handled by Media Viewer right now (unless you add mock license metadata to the fair use templates); detecting it using the category would be easy enough. What appears to be the description of the Tank Man image is actually the image caption from the article; there are some plans here on how to make that less confusing. (I guess we should not show the "no description" text if there is a caption.) --Tgr (WMF) (talk) 00:30, 6 June 2014 (UTC)Reply

Yup yup. There's a lot of work that needs to done by hand not just for Media Viewer but for getting metadata structured in general. Thanks for the links, tgr :) Keegan (WMF) (talk) 00:43, 6 June 2014 (UTC)Reply

I've given a first shot at this. That template is one of the most used and most consistent parts of the non-free media templates, so it seemed like a quick win to add some info there, as long as these templates do not have the correct info yet. But cleaning up all english wikipedia templates is going to be a GIGANTIC undertaking, since en.wp have taken a very visual and non-central approach to templating, instead of the meta-templating approach of Commons. TheDJ (talk) 09:56, 6 June 2014 (UTC)Reply

Great, thank you for starting that. Yeah, en.wp is going to be something...else :) Keegan (WMF) (talk) 17:31, 6 June 2014 (UTC)Reply

There is a sort-of meta template, {{Non-free media}}; one thing you could do is to use licensetpl_* markup with hidden fields there to set "license name" (similar to the way it is done in the PD meta-template on Commons), and use fileinfotpl_* on the fair use rationale template to get description and source. --Tgr (WMF) (talk) 19:26, 6 June 2014 (UTC)Reply

Not obvious how to find the file page

Latest comment: 10 years ago3 comments3 people in discussion

The link "Learn more on Wikimedia Commons The free media repository" is unclear and unintuitive, because it implies it takes you to the front page of Wikipedia Commons rather than the file page. A link stating something like "View this image's page on Wikipedia Commons" would be far clearer. -86.135.189.79 23:35, 5 June 2014 (UTC)Reply

I agree with this. Could we have the link text made more explicit, please. — Scott • talk 08:34, 6 June 2014 (UTC)Reply

Seems the image viewer would generate far fewer objections if bypassing it wasn't browser-specific, so have a second small icon next to the gray Enlarge logo (RHS below image) with a gray Commons logo that clicks straight through to the Commons page. Also, have clicking on the image in the viewer do the same. Problem solved? Munrogue (talk) 07:35, 7 June 2014 (UTC)Reply

Display errors in IE 10

Latest comment: 10 years ago2 comments2 people in discussion

Tracked in Phabricator
Task T68244

Images in the mediaviewer appear in the wrong aspect ratio (they’re stretched lengthwise), and the lower part of the image is completely blocked by the information bar. Scrolling, which one might expect to reveal the hidden part of the image, instead simply expands the information bar to hide more of the image. If there is a way to close the information bar, it is not evident.

Example: http://en.wikipedia.org/wiki/F/A-18C#mediaviewer/File:FA-18F-USN-RedRippers-20070406.jpg. The rocket/flare at the bottom of the image is completely obscured by the information bar in mediaviewer.

Viewed in IE 10.

Note: I would not have learned about the shift-click workaround without reading this discussion page. It might be worthwhile to note this solution more prominently until the bugs are fixed. (I do not have an account to permit me to disable mediaviewer, nor do I plan to create one. Similarly, I’d report this on the bugzilla page, but I lack an account there. I am not an editor (obviously), just a reader for whom this problem got in my way enough to take the time to report it here.)

I reported this problem in bugzilla, linked to the top right of this post. TheDJ (talk) 07:58, 6 June 2014 (UTC)Reply

Thank you, anonymous reader, for reporting this bug. And thank you, TheDJ, for filing bug 66244 and bug 66245. We have added corresponding Mingle tickets #699 and #700 on our next development cycle board -- and plan to start working on them this week. Again, many thanks for your contributions to this project, which are much, much appreciated! Fabrice Florin (WMF) (talk) 10:00, 7 June 2014 (UTC)Reply

to small

Latest comment: 10 years ago1 comment1 person in discussion

Big pictures to see?? How does it works? Is it a new mini player? It was better before to see details ! Greetings,--Benutzername eingeben (talk) 06:14, 6 June 2014 (UTC)Reply

URL? Not user friendly nor crawlable

Latest comment: 10 years ago5 comments3 people in discussion

What kind of URLs does the Media Viewer create? https://en.wikipedia.org/wiki/Zebra_Technologies#mediaviewer/File:Zebra_Technologies_Logo.png A "#" in the middle of the URL, really?

"# is used in a URL of a webpage or other resource to introduce a "fragment identifier" – an id which defines a position within that resource." (see [[3]])

Furthermore the URL ist long and strange and no user will be able to type it from hand.

And last but not least the filetype is wrong. It says ".png" at the end of the URL, but the data delieverd is a HTML Page. That is just plain wrong (just as it was before with https://commons.wikimedia.org/wiki/File:Kanadische_Truppen_landen_in_der_Normandie.jpg , but why didn't you correct the mistake?)

This will also create the same problems with crawlers (Google and others) as the previous version. Google with build a workaround for wikipedia, as they did before, but they will not for all the small MediaWiki installations, just as they did not before. And why should the fix your erroneous software? Please keep to the webstandards!

When i copy the URL and send it to a friend, it doesn't just load an image.

https://en.wikipedia.org/wiki/USA#mediaviewer/File:Flag_of_the_United_States.svg

loads the whole article about the US in the background for showing the image. 2.1MB are transferred for an image that is just 52KB. That is a real WTF.--62.153.251.26 12:03, 6 June 2014 (UTC)Reply

That said: I like the mediaviewer, the idea is good, the execution not so much. IF you fix the problems, i will love using it. — Preceding unsigned comment added by 62.153.251.26 (talk) 06:33, 6 June 2014‎

A fragment identifier ending in ".png" doesn't imply that a PNG will be delivered. This is explained in section 3.5 of RFC 3986, which defines fragment identifiers in URI syntax. Likewise, nor is it implied by a URL - you should never blindly assume that the content-type of a resource is implied by a textual identifier. Media files are uniquely identified in MediaWiki by their name, which is why it needs to be present in URLs for interacting with them in some fashion. The alternative is URLs with numeric identifiers of some sort, which is far less palatable.

However, I have to agree about the "loaded in the background" issue. It's inevitable that Media Viewer URLs will be shared around, and this needs to be given some thought. If Media Viewer URLs are to be formed via fragment identifiers, MediaWiki should check on page load whether the requested URL contains a Media Viewer call. If it does, load Media Viewer and set up an AJAX call to load the page's content when Media Viewer is closed... or something like that. Tricky. Of course, if the URLs are redesigned to not involve fragment identifiers (/media/Filename.jpg perhaps?) then it'll be a non-issue. That would presumably involve, when being invoked from wiki pages as opposed to standalone, loading Media Viewer as a separate resource and displaying it in a floating frame, or some such. — Scott • talk 09:04, 6 June 2014 (UTC)Reply

Thanks for the feedback, Scott. You say "you should never blindly assume that the content-type of a resource is implied by a textual identifier". That is true. But the reality is: When Googlebot sees a URL ending in .jpg it does not crawl it. Instead it sends the Google-Image-Bot. The Google-Image-Bot tries to crawl the url but gets a html document, which it cannot understand. You can look at any mediawiki installation, that is not wikipedia, and see that google does not crawl any pages like /wiki/File:*.jpg (and other images).

My first thought would be a URL like: https://en.wikipedia.org/wiki/mediaviewer:Flag_of_the_United_States/svg?page=USA. This way you could open the image in fullscreen view and the page would know to wich article to return after the close. It would also work the same way for just one image without "?page=USA". But thats just one early idea without looking into it further.--62.153.251.26 12:03, 6 June 2014 (UTC)Reply

What you say about Googlebot does not seem to be true even for URLs where the path part ends in an extension (and it would be fairly stupid behavior from Google - you are supposed to use the mime type to tell the resource type an URL represents, not the URL), much less when the extension is in the fragment part (which is largely ignored by search bots - although Google is more clever about that - since the same page can be referenced with different fragment ids).

As for using fragment IDs, that was a design decision to support older browsers. You have basically three options:

reload the page every time the URL changes (clearly not wanted)
use hashes to store the state
use the History API to change URLs without reloading - only supported by about 75% of browsers. (There are some other problems with it, too, like splitting caches.)

Choosing option 2 means that we need to serve the whole page, not just the image (as the fragment id does not get sent to the server). That is unfortunate, but I still think it is the least bad option. --Tgr (WMF) (talk) 19:18, 6 June 2014 (UTC)Reply

You chose wikia as an example? really? How about https://www.google.com/search?q=site:http://wikiindex.org+inurl:jpg or how about https://www.google.com/search?q=site:http://www.c64-wiki.de+inurl:jpg

Now lets see: https://www.google.com/search?q=site:http://lego.wikia.com/wiki/File:AlienconquestNEWlogo.png and compare with https://www.google.com/search?q=site:http://www.c64-wiki.de/index.php/Datei:Slinky_title_wiki.gif

Can you see the problem now? Not every site is treated equally by googlebot. If you want more examples i will post hundreds.

--62.153.251.26 06:06, 10 June 2014 (UTC)Reply

Should be Opt-in for Everyone...

Latest comment: 10 years ago3 comments3 people in discussion

... that is, for anonymous users and random browsers of Wikipedia, who are otherwise unable to enlarge images and look at image credits. Personally, I really don't like this "enhancement" - it's unhelpful in every way. There appear to be idle hands somewhere, and the devil has obviously found work for them... Sigh... RomanSpa (talk) 10:42, 6 June 2014 (UTC)Reply

Today I was confronted without warning with a new and unhelpful viewing experience. I am an occasional editor - mostly I just fix typos and bad links - so I had at least a first idea of where to go to find out what was happening. That brought me to this discussion, and I strongly agree with those who are against this change. What we had before was a very usable system that had what I might call academic rigour - something that I expect from such an important information resource as Wikipedia.

It seems to be really difficult for enthusiasts to understand that foisting an unheralded change on people who use this excellent resource is counter-productive. I am not so involved with Wikipedia that I wish to spend time researching better ways to fix something that was delivered to us unannounced, and clearly is unwanted by many in this community. The changes to privacy policy that have been announced for some months clearly show that it is possible to give a decent amount of prior notice. The same should have been done with this non-trivial change.

But that said, sometimes horrible "features" only show up once a software change is implemented. It is important to know when you have driven up the wrong road and need to turn around and go back. This seems to me to be one of those times.

I have anyway logged in and disabled Media Viewer. What is not clear from the FAQ is whether I am now going to have to log in every time I come to Wikipedia, or if the setting will be remembered via a cookie or something. I fear it will be a requirement to log in each and every time, which is going to drive me to distraction.

I very much agree with RomanSpa that Media Viewer should be an opt-in.

[Don't know what I've done wrong, but my user name doesn't seem to display ... RikardT]

Hi RikardT, I'm not sure what happened there, either. There have been problems with people coming to MediaWiki.org and and discovering that they're somehow logged out (mostly in Firefox? It doesn't seem to be clear). However, you seem to be logged in, so that's not the problem you were having.

Disabling most tools is only available to editors who are logged in. However, most of the time, people stay logged in for 30 days at a time. Whatamidoing (WMF) (talk) 22:28, 6 June 2014 (UTC)Reply

What the lad above says though: things like this, if they need to be present at all (which this doesn't), should need to be explicitly enabled, not explicitly disabled. In my case I a) do not have a Wikipedia account (by choice: ancient authors did not sign their prose--I'm of the opinion that only those greedy or vain enough need that sort of recognition. Hope that clears that up now), and b) I browse in permanent private mode, so every time the browser is closed (once or twice a day), all state is lost. Am I a minority? Yes, but by catering to my sort of profile with all its constraints, accessibility is improved for every user.

I agree that this should be opt-in. I didn't like being confronted with this completely different image viewer, and even now that I have read about it and used it a little more, I still don't like it. The old interface was just fine. This doesn't add anything for me and just gets in the way. If there are people who prefer it, that's fine, but let them opt in for it.Billposer (talk) 05:44, 13 June 2014 (UTC)Reply

Description not visible without scrolling down

Latest comment: 10 years ago2 comments2 people in discussion

Hi, for me (Win 7 laptop, IE 11), the description of pictures is not visible unless I scroll down. The filename is visible, and sometimes this suffices, but sometimes filenames are not very meaningful or lack essential information. 86.179.112.1 12:44, 6 June 2014 (UTC)Reply

Hi, thank you for your feedback. The position of the caption is not 100% set in stone, so it's always good to hear something about it. Thanks! Keegan (WMF) (talk) 17:25, 6 June 2014 (UTC)Reply

-- If this feature is adopted I will use Wikipedia less for images and instead use Google images more.

Don't like this approach

Latest comment: 10 years ago4 comments3 people in discussion

Pros: Makes copyright status more noticeable Defects: Doesn't show previous versions and how to upload a modification of the file; suppresses left-hand column of links; no access to categories Brews ohare (talk) 16:11, 6 June 2014 (UTC)Reply

My objections would be largely met if the "Learn more" link to commons were identified clearly as the same-old-same-old commons page for the file where everything I'm interested in is listed. Brews ohare (talk) 02:27, 8 June 2014 (UTC)Reply

"This is the same page that you've always gone to" isn't exactly going to be a useful label for most people, especially people who haven't made thousands of edits like you.

However, improvements to the labels and buttons is something that I'm sure the team would be happy to hear about, so if you've got a suggestion for what to say instead of "Learn more", please post it.

In the meantime, if you don't want to disable Media Viewer entirely, and you want to skip straight to the description page on a given image, then opening the image in another tab (Command-click on a Mac, probably Control-click on a Windows box) will take you straight there. Whatamidoing (WMF) (talk) 22:45, 8 June 2014 (UTC)Reply

What's wrong with an "Old-style page" link? You don't have to be an editor to have clicked through an image---I did it plenty before I got around to signing up.

About login: I was surprised to see that my Wikipedia login doesn't extend to Wikimedia. I'd just assumed (yeah, yeah) that the two were closely-enough related that one login would naturally cover both. Max Hyre (on Wikipedia) 107.200.245.17 17:23, 13 June 2014 (UTC)Reply

Please make Media Viewer a choice!!

Latest comment: 10 years ago5 comments4 people in discussion

Judging from the response here, which at this point isn't something one can simply ignore anymore, it's becoming more and more clear that most editors and others here at English Wikipedia don't like the new media viewer. We were told that this thing had "overwhelming user response...tested extensively around the world...had feedback from/useful to over ten thousand users, 70% of them" -- but we have yet been told 'how' Media Viewer is useful to them in ways the original arrangement was not. Would someone please tell us now? So far all we've heard is a claim about "confusing" file data, etc, all the while we've read about one fault and shortcoming after another from many editors. So we have to ask -- what's really going on here? Why hasn't most if not all users in this conference heard about the Media Viewer until just recently when it was forced as the default viewer on everyone?
The average reader simply clicks on and views an image once in a while as they read an article, so obviously they're not going to be making the informed analysis that's coming from editors who edit and build Wikipedia. Therefore it's unfair to base any decisions on the general and passing comments of casual readers. It was disappointing to read that the individuals who are pushing the media viewer on everyone else are more concerned with the general reader than they are with us "power users". There would be no Wikipedia content without us "power users", and in that event, there would be no readers. The back bone and life blood of Wikipedia are its editors. English Wikipedia editors need to tell other editors and users to come here and weigh in, and to also let them know about The survey
@Fabrice Florin (WMF): , it was simply wrong to "move forward" with this viewer as the default viewer when it is not wanted by so many people. Again, the casual reader only views an image in passing, so naturally most of them are going to say 'Gee...what a neat viewer', when asked. This sort of feed back is not what you should be basing your decisions on. Please be fair to everyone and make the viewer an option when someone clicks on an image. -- Gwillhickers (talk) 16:41, 6 June 2014 (UTC)Reply

Dear Gwillhickers: Thanks for your prolific feedback (I notice that you have posted over a dozen times on this page in the past couple days, more so than other users). We appreciate your concerns, which we heard the first time you posted them, and have responded to in great detail already; there is no need to repeat these concerns over and over again. I can assure you that we care as much about editors as readers, and always aim to develop solutions that can support the needs of both user groups. As shown in the full survey report, about half of survey respondents are editors, who are well represented in this study. To determine the need for this tool over the past year, we hosted a dozen IRC and roundtable discussions with community members, who confirmed that the previous user interface was confusing and needed improvement: they generally supported Media Viewer as a practical solution to those issues. The tool has also been tested for over six months by 15,000 English Wikipedia editors on an opt-in basis, as part of our Beta Features program. After improving the tool based on their helpful feedback, we confirmed that it was useful to over 70% of survey respondents around the world; on that basis, we concluded that the feature was ready for wider release. This decision process is logical, methodical and we consider it to be fair. While I understand that you personally don't like this tool, we see no evidence of wrongdoing on our part, nor do we see evidence that "most editors and others here at English Wikipedia" don't like the tool. At this time, about 450 users have disabled Media Viewer on English Wikipedia, which is a relatively small number -- about 0.37% of the users who have been active since the rollout. So it appears that a lot of folks are giving Media Viewer a try -- and we encourage you to follow their lead. While we may not be able to answer every comment you post in the future, rest assured that we have heard your position, that we respect your views and that we will be taking them into consideration as we plan our next steps for this product. Thanks for your trust and understanding. Fabrice Florin (WMF) (talk) 08:32, 7 June 2014 (UTC)Reply

@Fabrice Florin (WMF): , Yes, I have posted here a fair number of times because, one, I deal with, uploaded and edit many images, and have done so for years, and two, because I feel strongly about a few individuals taking it upon themselves to make this viewer a default, rather than a choice, knowing full well of the many problems that exist, and then try to justify it by referring to the approval of people who obviously are not aware of the many problems that media viewer brings with it. Three, I have tried this viewer, and your inference, "follow their lead", suggests I haven't and that my objections are unfounded, which is sort of an insult. In any event, if there was an option to disable the viewer, up front, with no hassels, I am confident you would see many more users disabling this viewer. -- I will try to keep my tone civil and maintain good faith, but I must say, you are certainly making this difficult with your insistence to push media viewer as the default, rather than an option, which would be fair to everyone. You should be basing your decisions on the feedback of experienced users, not those who drop in once in a while and say "gee what a neat viewer" when asked, which is in essence the basis of your approval rating. -- Gwillhickers (talk) 17:19, 7 June 2014 (UTC)Reply

It's already "a choice", Gwillhickers. "A choice" is not synonymous with "turned off by default". If you don't like it, then please go to Special:Preferences#mw-prefsection-rendering, under the "Files" section, and remove the checkmark. Unfortunately, because of a lack of a global preferences system, you will have to do this for each wiki that you use, which in your case means once for Commons and once for the English Wikipedia. Whatamidoing (WMF) (talk) 22:49, 8 June 2014 (UTC)Reply

@Fabrice Florin (WMF): , no, actually I don't think you HAVE "responded to [Gwhillhicker's points] in great detail already". (1) ~~I see nothing in Gwhillhicker's posts to justify a defensive posture. "[W]e see no evidence of wrongdoing on our part" does not seem warranted since I don't see an accusation of wrongdoing.~~ {Sentence no longer true after subsequent Gwhillhicker posts - Kevin} Also, you have consistently cited the survey in many, many responses, so I see no reason to chastise Gwhillhickers for repeating the same arguments when I don't see anything new from the proponents of the tool. As for being prolific, most of Gwhillhickers' edits are quick rewrites of his owns posts. By contrast, I see massive numbers of posts by Quiddity, Keegan and, to be blunt, you. AGF goes both ways, don't you think? (2) You note that the survey was opt-in before people saw this tool. Are you saying the survey sample could not have been weighted to those who did know -- folks likely to be friends or family of project champions? (3) I am unclear why stale data takes precedence over current feedback. Your survey was done before roll-out. After roll-out, there seems (at least to a casual observer) to be a torrent of objections. Is it at least POSSIBLE that people have changed their minds or that the original consensus was flawed? (4) A small number, 0.37% of the people with accounts, have found the feature so intrusive that they've taken pains to disable it. Can you help me understand how that translates into approval? Everyone who got food poisoning at the restaurant liked it because only 0.37% called to complain? An extreme analogy, I know, but an effective one. (5) Can you also explain why that would apply to those who use wikis without accounts? Since half the people at the restaurant who got food poisoning didn't have phones, they MUST have liked it cuz they didn't call to complain?(6) I am intrigued by the fact that you do not "see evidence" that folks don't like the tool. By casual count, I see around 75 clear objections to either the tool or the roll-out plan. Are you saying that this thread and others like it are not valid? Does everyone who objects have to create an account and disable the feature in order for you to acknowledge that people can object in good faith? Is there some other forum where folks can ask that intrusive features should be opt in for the good of the WikiWorld? (7, and coming full circle) I don't hate this tool but object to forced-adoption roll-out. Is this not the forum for asking WHY? and then rephrasing the question if someone thinks it's been ignored or dismissed out of hand? We all want the wikis to improve and we (obviously) disagree on how. Do you have a constructive recommendation for reaching consensus that does not involves challenges on talk pages and (occasionally) a bit of friction when people (perhaps like Gwhillhickers) feel they have an important issue that they truly believe has been brushed off without a hearing by others (perhaps like some of the posts above)? 159.53.46.141 22:20, 9 June 2014 (UTC) (Kevin, same as other posts above)Reply

this is simply obscene, I see no reason whatsover that this is being literally forced on everyone without an account. I browse wikipedia from multiple sources such as personal and public computers and from mobile devices. I cant stand this feature and it literally gave me a headache when I first encountered it because it was the most frustrating thing I've experienced in years. I am never ever going to create an account to disable something that should not have been jammed down my throat in the first place by you arrogant bullies.

Kill it with fire. Preferably something that you can't put out with any kind of extinguisher.

Latest comment: 10 years ago5 comments5 people in discussion

Horrible.

Horrifying.

Offensive.

When I click on an image, I expect to be taken to the file's info page. This is how it's always been done, and this is what makes sense.

1. You fucking click on something.

2. You fucking get its info.

It's not difficult. It's how a wiki, which is based on content and information, not pretty presentation, is supposed to work.

But some fucknut decided his pet project was more important than (1) convention, (2) consensus, and (3) common sense.

Instead, now the process is something more like this:

1. You click on an image.

2. You click on a really faint arrow at the bottom of the screen, or scroll upwards, or swipe upwards with your shitty touch-screen (which is what this POS seems designed for: tablets, rather than REAL computers).

3. You ask yourself, "What the fuck do I click on now?" You look around for eight minutes trying to find something that looks like "more on this image" or "image metadata" or "image page".

4. You click the link to the image source. This takes you to the image source's web page, rather than the file's wiki metadata page.

5. You go back, you try the uploader's page. No dice.

6. You find out that it can't be disabled without creating an account.

7. You find out that nobody who's in charge is planning on fixing (read: getting rid of) this pile of shit soon---as in yesterday. So you decide to try toughing it out.

8. You go back, on a whim, and then click "Learn more on Wikimedia Commons", :expecting to get an info page "on" (interpretation: about or concerning or on the subject of) Wikimedia itself, or hopefully about whoever made this dumb media viewer application.

9. Sure enough, you "learn more". You learn more about the dumbass who made this and didn't think to put the words "about this image" in the middle of that link, so you can fucking know what it is you're going to be fucking "learning more" about, rather than misinterpret the ambiguously-worded link title.

10. You get pissed off, go write an angry review of this new "feature", and fully expect it to be removed by some butthurt overly-sensitive editor who doesn't understand what this whole wiki ecosystem is about:

Organizing information, making it free, and making it accessible, not about making it fancy, and not about making it family safe.

11. And then you wonder if maybe the bastard will lock the page to prevent "vandalism", just to rub it in:

Wikimedia isn't run by common people. It's run by corporate tools masquerading as common people.

You've fucked up, whoever designed this crap, and especially whoever decided to greenlight its use on a production website instead of testing it via opt-in. Go work on Uncyclopedia or the Encyclopedia Dramatica or somewhere else that might appreciate your incompetence.

(Oh yeah, want to hear something painful? If you'd done this right, maybe I would have supported it down the road. But now that it's been done wrongly, so magnificently wrongly, I'd rather spite every new mini-project that comes out later, than see mediawiki ever try to improve itself in the future, which more than likely will result in something like this happening again.)

Shame on you, and a pox upon your careers as software developers and decision makers.

— Preceding unsigned comment added by 198.228.216.29 (talk • contribs) 17:53, 6 June 2014 (UTC)Reply

Agreed, this is horrendous.

Thank you for taking your time to leave this feedback. I'm certainly sorry that Media Viewer has caused you so much animosity- I hope that I can address some of your concerns. Your feelings are clear and I do not expect to change those. It seems like, ultimately, Media Viewer is not intuitive for you navigate around. There are things that the Multimedia team is doing right now to work on usability, based on feedback like yours. The link to Wikimedia Commons needs to be bigger, other points of navigation need more clarity, and it's important to get this right. Media Viewer has been opt-in for the past six months on the English Wikipedia through the Beta Features program, but you have to have an account to participate in Beta testing. The way IPs work there is simply no way to allow customization of Wikipedia or Wikimedia projects without an account. We will, however, be making it clearer and easier for IPs to find and access the original file page as well; IPs are humans too :)

Developing Media Viewer has not been a pet project, as you describe, but has been highly collaborative throughout its process, from conception to where we are now, getting feedback from you to make Media Viewer better. Keegan (WMF) (talk) 19:20, 6 June 2014 (UTC)Reply

You could make things "better" for a lot of people by making this thing an option when we click on an image. Why isn't this being considered? -- Gwillhickers (talk) 19:58, 6 June 2014 (UTC)Reply

I doubt that people would want to choose between new and old styles every single time they clicked on a picture. It makes more sense to have a preference setting that lets you choose the default display method for you, which is what the Media Viewer team implemented.

Personally, I think a one-click system to change preferences would be desirable. Then you could have a one-time question on the first time you viewed a picture, or you could leave a message that said "click here to opt-in", instead of click here, scroll there, find the item, check the box, and save the page. However, I've asked around, and the ability doesn't exist in MediaWiki. (Also, if you've never seen Media Viewer before, how could you make an informed choice about whether you'd like to use it? So perhaps it would have to be the second time you clicked on an image rather than the first.) Whatamidoing (WMF) (talk) 22:58, 8 June 2014 (UTC)Reply

While this comment is not written in a style I would choose myself, it represents my thoughts about the viewer very accurately. This viewer disables the capabilities of the browser on my computer to make effective use of its capabilities to render the image, and replaces it with a least common denominator. The only redeeming quality is the (however completely inadqeuately labeled) link to the original wikimedia page.

For my part, I will do whatever it takes to disable and bypass this feature whenever I conribute any multimedia file to wikipedia.

Extemely upset after trying to view a map at full browser resolution and getting thwarted by this ill-conceived piece of s...oftware instead.

Do not try to fix. Eradicate the "feature".

Tatzelbrumm (talk) 12:10, 10 June 2014 (UTC)Reply

User Keegan (WMF) says: "Developing Media Viewer has not been a pet project, as you describe, but has been highly collaborative throughout its process". Ok, where has that "highly collaborative" process been captured? Where can I access the discussions and the documentation? Most importantly: Who was the project champion and what were the reasons given for writing this "tool"?

Worse. Much worse.

Latest comment: 10 years ago1 comment1 person in discussion

Seriously. I don't like being rude after someone obviously spent a lot of effort on something, but this shouldn't exist, or should require some specific action to use. It's slow. It's ugly. It takes more clicks to do the same things. It uses icons in place of text. It duplicates functionality already provided by virtually all modern browsers. The old interface was substantially better. Click, pick which size I wanted to see, it loads. My browser provides loading status, pan and zoom functionality, etc. Two clicks to perfection. Picking the size lets me select the proper tradeoff between quality and load time. Quick, easy, functional. This crap? Not so. Separate content and presentation. Make it go away, preferably forever. If you want to actually improve the image viewing experience, spend your time tracking down and clubbing the people who upload tiny images. 74.207.250.159 20:41, 6 June 2014 (UTC)Reply

Transparent pixels

Latest comment: 10 years ago11 comments6 people in discussion

Transparent areas of images display as the checkerboard pattern, which doesn't seem right. That pattern is to identify transparent areas when working on editing graphics, not when displaying them. Those areas should probably be displayed as white instead. 86.179.112.1 20:46, 6 June 2014 (UTC)Reply

The transparent areas are also shown in that way, at standard File: pages, eg c:Category:Transparent has a few, specifically, File:Blue DualShock.png. I'm not sure what the benefits or drawbacks would be, of doing it differently in Media Viewer... Hmm, I'll ask around. :) Quiddity (WMF) (talk) 00:46, 7 June 2014 (UTC)Reply

Only when the cursor is over the image. At least, that's the way it works for me. I don't know whether it's a browser-dependent thing. 86.179.112.1 02:58, 7 June 2014 (UTC)Reply

Oh! My mistake and apologies. I've filed bugzilla:66306. Quiddity (WMF) (talk) 04:58, 7 June 2014 (UTC)Reply

Depends on the wiki. On Commons, it is always visible: commons:File:Disqus_d_icon_official_-_white_on_transparent_background.png --Tgr (WMF) (talk) 05:25, 7 June 2014 (UTC)Reply

The checkerboard pattern is used to make sure the background color does not match the image color. Imagine File:Disqus_d_icon_official_-_white_on_transparent_background.png on a white background... --Tgr (WMF) (talk) 01:02, 7 June 2014 (UTC)Reply

The checkerboard pattern is information for people editing the image. It is NOT intended to be displayed with the image in normal viewing mode. It is up to image users to ensure that white is not displayed on white, etc. 86.179.112.1 02:58, 7 June 2014 (UTC)Reply

That's not true. Consider, for example, Google Image Search: when you look at the image in detail (click on it), you will see the checkerboard background. This is fairly normal behavior for transparent images. --Tgr (WMF) (talk) 05:22, 7 June 2014 (UTC)Reply

You are wrong. Transparent should not shown as checkerboard in normal viewing mode. It should be shown as transparent. That is the whole point of transparent pixels. Google probably show it that way because they don't automatically/easily know the background against which the picture should be displayed. 86.160.85.177 11:23, 7 June 2014 (UTC)Reply

It sounds like "what the designers originally intended" and "how transparent pixels are actually used in the real world in 2014" might have diverged some.

I don't really see any perfect solution here. If the image is a black dot on transparent, and you display it on a black background, then the image is invisible. If the image is a white dot on transparent, and you display it on a white background, then the image is invisible. Unless we're prepared to ban people from using images containing whatever color is chosen for the background, then the choice is between having some images that aren't visible to the reader, or some images that show the reader that some pixels are set to transparent. Whatamidoing (WMF) (talk) 23:04, 8 June 2014 (UTC)Reply

There are some situations where I would prefer to know that an image has transparent pixels, like if I'm looking for an image to put in a presentation. Other times, the checkerboard background can be jarring for regular viewing. Personally, I like the way it's handled in the file pages. It seems to display as transparent (i.e. background color) until you mouse over it. That way, you can see the image without the checks if you just want to look at it, but if you mouse over to right click and save the image you have some warning of the transparency. Is there any reason this couldn't be implemented in the viewer too? 64.15.81.27 06:08, 11 June 2014 (UTC)Reply

Deceptive language

Latest comment: 10 years ago5 comments5 people in discussion

On the Multimedia/Media Viewer/Survey/Results - 05-05-2014 page, the language used to describe "approval" is very deceptive. It says for example "73% of readers find the tool useful". Useful in what way? They don't say. Surely when readers click on an image the media viewer presents the image, so yes, it is "useful" in that regard. -- It's like they're asking a group of swimmers if they found the water "useful". In my opinion the "approval" survey is a sham.

Questions that need answering:

How else was media viewer "useful" for readers where the prior arrangement for file viewing was not?
What does the media viewer offer readers and editors that the prior file viewing arrangement did not?

-- Gwillhickers (talk) 20:48, 6 June 2014 (UTC)Reply

One thing it offers readers, that I like, is a customized image-size to fit my viewport. Previously, we'd always get a 800px wide or 600px tall maximum (unless we'd logged-in and changed our preferences at that wiki). Now, I get large almost-full-screen images, on both my cheap small laptop and my decently sized desktop-monitor. I agree the Media Viewer could be further improved in many ways, or possibly certain decisions could be re-examined, but overall it seems to be a step (or 2) in a positive direction. Quiddity (WMF) (talk) 00:54, 7 June 2014 (UTC)Reply

Before, if I wanted to see an image bigger, I clicked on it. If it was still too small, then I clicked on it again. Ironically, the images displayed in media viewer are smaller than the old system where you could easily get an image to appear in the browser's native image viewer. --94.195.183.212 03:30, 7 June 2014 (UTC)Reply

FWIW, I'm 100% with what 94.195.183.212 says above. He describes exactly how this feature fails miserably to add any value to the user's experience.

I believe that the question being asked is, "Is this media viewer useful for viewing images and learning about them?", which allows survey respondents to make up their own minds about what they consider to be useful. Since the question is actually "Is it useful", then reporting the responses as "X% of readers find the tool useful" does not seem deceptive to me. Whatamidoing (WMF) (talk) 23:08, 8 June 2014 (UTC)Reply

Dear Lord, this is absolutely ridiculous! Of course an image viewer is "useful for viewing images and learning about them" - it would take a special kind of incompetence to make an image viewer that wasn't useful for viewing images.

It's like asking "Is this broken, rusty spoon useful for eating soup?", getting the answer "Uh, yeah, insofar that I can use it." and hence deciding that rusty, broken spoons are the next big thing in eating technology.--129.67.108.52 09:26, 10 June 2014 (UTC)Reply

Dear Lord, this is absolutely ridiculous! Indeed. A poll being done by someone with less than zero idea about survey design (a complex topic, admittedly) and now being rubbed on everyone's face ("but 75% of users are happy"... about something, apparently) while ignoring all the rich qualitative feedback being offered here and elsewhere. In properly done user research, btw, you would be very brave or very mad if you were to ignore every fourth user telling you your product sucks, but this isn't properly done research so that's neither here nor there.

How to get rid of the Media Viewer?

Latest comment: 10 years ago6 comments6 people in discussion

On Wikipedia I can't get rid of it. I've followed directions and unchecked etc. everything under "Preferences". On the Commons I've managed to get rid of it. What should I do? (It's extremely annoying and requires several extra clicks to do what I want.) Thanks, Parabolooidal (talk) 21:44, 6 June 2014 (UTC)Reply

@Parabolooidal: Hmmm...did you make sure to save your preferences after you unticked the box? Did you "hard" refresh your browser after doing so (usually accomplished by shift+Refresh or shift+ctrl+R)? If none of this works for you, what browser are you using? Keegan (WMF) (talk) 22:18, 6 June 2014 (UTC)Reply

To find out what the setting on the English Wikipedia is, be sure that you check w:en:Special:Preferences#mw-prefsection-rendering and look in the "Files" subsection. (Oh, how I wish that we had global preferences, instead of having to do things separately for each and every language edition of each project.) Whatamidoing (WMF) (talk) 22:21, 6 June 2014 (UTC)Reply

Could you please post the exact steps needed to disable this "feature"? Nwbeeson (talk) 23:13, 6 June 2014 (UTC)Reply

@Nwbeeson: To disable at English Wikipedia, click here, scroll down to the "Files" section, un-check the "Enable Media Viewer" box, and click "Save" at the bottom. Quiddity (WMF) (talk) 00:13, 7 June 2014 (UTC)Reply

Damn! So we have to do it in every WM project separately?! I supposed that that this options set in WMC preferences should control how all images from WMC are displayed. — Mikhail Ryazanov (talk) 07:09, 10 June 2014 (UTC)Reply

Destroy Media Viewer

Latest comment: 10 years ago2 comments2 people in discussion

It is one of the worst ideas I have ever run into from Wikipedia. I frequently look at pictures. When I click a picture I do so to see the largest version that will fit my screen, and to be given the option of enlarging it to the maximum size uploaded. This used to be trivial, now it is arduous. Horrible change.

I edit every day. I have been editing for eight years. Today I have found an image that is in error. Before Media Viewer I could click the image, in one step I would have access to the original file, could download it, make the changes, and reupload it. Now I do not have any idea how to do that. The original needed no explanation. This new improved media viewer does need a tutorial. How is that an improvement?Nwbeeson (talk) 23:13, 6 June 2014 (UTC)Reply

To access the standard image-page directly, you can either middle-click (if your mouse has a middle/scrollwheel button), or ctrl-click, on the image. I'm going to suggest an alternative, with my volunteer hat on, below.. Quiddity (WMF) (talk) 00:18, 7 June 2014 (UTC)Reply

talk, did you read the bit where he says "The original needed no explanation"? He's not asking for instructions, he's saying this contraption is one of the worst ideas [he's] have ever run into from Wikipedia, and asking that it be destroyed. Same request as everyone else who has bothered to post here. Given the inability to listen of those who receive it, please be assured that you won't be seeing any more of my donation money in the future.

Cool!

Latest comment: 10 years ago3 comments3 people in discussion

Hi! I just wanted to say, this is a very nice way to look at images! I am glad to be able to have the clearer visual distinction between the content and the metadata. Thank you! I have a couple of minor criticisms, but overall it is great. My thoughts on how it could be improved:

I'd like to be able to tap on the image to get the original file; right now it doesn't do anything.
It is a bit visually jarring having the down-pointing arrow, the right/left pointing arrows, and the close/full screen buttons all have different line thicknesses. They could all be the same I think.

Those are very minor issues I have with it though. Thanks again for the great work developing this tool! Goldenshimmer (talk) 00:23, 7 June 2014 (UTC)Reply

Dear Goldenshimmer: Thanks so much for your kind words, which are particularly welcome at this time :) We will take your recommendations under consideration. You make a good point that the thickness lines could be a bit more consistent and we will pass on your suggestions to our design team. Thanks again for taking the time to share your appreciation for this tool. Be well. Fabrice Florin (WMF) (talk) 02:24, 7 June 2014 (UTC)Reply

Uncool, but... I don't like the viewer one bit, but if clicking on the image took me through to the old page (static, presumably, all resolutions available, copyright, history, &c., &c.) that would take care of 70% of my complaints. Opt-out would take care another 10%, and opt-in would handle the last 20% :-) Max Hyre (on Wikipedia) 107.200.245.17 17:42, 13 June 2014 (UTC)Reply

Direct access, via the magnify icon?

Latest comment: 10 years ago3 comments3 people in discussion

Occasionally, I'd like to be able to directly access the file-page, particularly as an editor. I know I can do so via middle-click or ctrl-click, but not everyone has those options.

I was wondering if we could change the icon to link directly to the file-page? Or create a replacement for that "Magnify-clip" icon that would do the same thing?

Thanks for considering it.

(Overall, I really like getting fullscreen images now, instead of the 800px wide or 600px tall maximums we were previously getting. I hope we can get some sort of easy access to "2x fullscreen, and also original size", or a google-maps like zoom function, at some point in the near future, for better access to the Large Images. But as noted above, the multi-megabyte originals are rarely what I want.) –Quiddity (talk) 00:31, 7 June 2014 (UTC)Reply

The new viewer will not fill your screen with an image if it's not large enough to begin with. Previously when an image was large enough to fill your screen, and larger, all we had to do is click on the image a second time to get the full view. This could and can be done in an instant. While you may have no interest in large image files with high resolution, most people want to be able to view them in full, esp where it involves images of maps, flowers, insects, birds -- nature. Hello? Yes, even a stopped clock is "correct" twice a day, but I don't see how this justifies a few individuals who apparently have taken it upon themselves to make this new viewer the default viewer, esp since it has created so much dissatisfaction, (which has been articulated time and again, unlike it being "useful") for so many editors. Again, most readers were happy and would find any viewing system "useful" no matter what they use to view images with. There was no outcry for a different viewing system, so I can only wonder if this thing is being forced on everyone for other reasons, esp since they have yet to even acknowledge the idea of making this thing an option when an image is clicked. It seems they are dead set on making this the default viewer regardless of the fact that it's a buggy system with serious shortcomings and that virtually no one asked for it. -- Gwillhickers (talk) 02:11, 7 June 2014 (UTC)Reply

Dear Quiddity: Thanks for this constructive suggestion! I have added this ticket for consideration by our team: #702 Provide direct access to the file page via a small icon near the thumbnail. We'll discuss this idea on Monday and keep you posted. Thanks again for proposing practical improvements to this project :) Fabrice Florin (WMF) (talk) 02:41, 7 June 2014 (UTC)Reply

Default enabling for logged in editors

Latest comment: 10 years ago13 comments7 people in discussion

I wish there were a stronger way I could get this across. Let's try.

Please do not, ever, for any reason, automatically set a new feature to "enabled" for logged-in editors. Let them know it exists, and give them the option to try, but don't just screw with their interface.

I'm awfully tired of having new "features" that entirely break my workflow turned on and slap me across the face, and make me go to Meta or here to figure out how to get rid of them. I actually rather like this feature for the casual reader, it's more modern looking and I imagine it will be well received among the general readership. But it's very poor for an editor, especially one working with images. All new features should be opt-in for logged-in users. Seraphimblade (talk) 02:27, 7 June 2014 (UTC)Reply

_{(edit conflict)} I have several times asked that the viewer be presented as an option, not "burned" or "destroyed", when someone clicks on an image, but evidently this is not considered a "constructive suggestion" and has not even been acknowledged by the few individuals who are promoting, pushing this viewer and who of course want to be fair to everyone, esp the editors who have given much time and effort, years, into building Wikipedia from the ground up. I have submitted a couple fair questions to this effect but they continue to be ignored by our friends with smily faces. For example, how has the viewer been "useful" in ways that the prior viewing system has not? As for the "70% approval rating", the 70% figure comes from average readers who were impressed with a couple of images and obviously had no idea of all the shortcomings and faults this new viewer has presented to very many editors and users. --

-- Gwillhickers (talk) 03:15, 7 June 2014 (UTC)Reply

Dear Seraphimblade: Thanks for your proposal. I'm sorry that this new feature took you by surprise. It has been tested for over six months by 15,000 English Wikipedia editors on an opt-in basis, as part of our Beta Features program. After improving the tool based on their helpful feedback, we confirmed that it was useful to over 70% of survey respondents around the world; on that basis, we concluded that the feature was ready for wider release. We appreciate your suggestion to have new features be released on an opt-in basis for editors and on an opt-out basis for readers: as much as we'd like to provide special treatment for valued editors like you, this approach would provide an inconsistent user experience that would confuse users. For example, editors who temporarily log out might not understand why images suddenly open in the Media Viewer and would start complaining, rightly so. Instead, we recommend that you give the tool a fair try, become familiar with its features, and see if it grows on you over time. Note that you can press shift-click or control-click to bypass Media Viewer when you want direct access to the file page, as documented in the Help FAQ. Over time, we hope that you find enough value in the tool to use it for your own purposes, but fully respect your desire to disable it if it doesn't work for you: to turn it off, simply click on the 'Preference' link provided at the bottom of the Media Viewer panel, and uncheck 'Enable Media Viewer'. Thanks again for taking the time to share your perspective, which we very much appreciate. Fabrice Florin (WMF) (talk) 03:01, 7 June 2014 (UTC)Reply

Actually, what confused me was to have the thing turned on, whereas providing an "inconsistent user experience" would have left me, well, not even knowing or caring it was "inconsistent". Editors and readers don't use the same features because they aren't doing the same thing, so there's nothing wrong with differentiating the interface between the two. But it's pretty clear that this is VE round 2, and that you'll make the same attempt to blow off and discount editors with the same nonanswers and superior tone as you did with that project, while referring to a nebulous group of "readers" who, interestingly, invariably agree with what you wanted to do anyway. I'd hate to see the same result, as this actually could be a useful feature, but this smug and nonresponsive attitude will cause blowback. At the very least, on first invocation, provide a "Don't use this feature again" checkbox, prominently, instead of requiring digging to figure out how to disable the thing. Seraphimblade (talk) 03:41, 7 June 2014 (UTC)Reply

Hi Seraphimblade: Thanks for suggesting that first-time users be given the option to disable Media Viewer. We considered the idea of a first-time guider showing how to use or disable the tool -- but it didn't seem needed at the time, given that Media Viewer was so favorably received in our first pilots (e.g. French, Portuguese, Spanish Wikipedias -- where a majority of survey respondents give the tool high marks). But I agree with you that this type of guider could have been useful for the English Wikipedia release -- and we will keep it in mind for future roll-outs. I'm sorry if we come across as 'smug' and 'nonresponsive': we care deeply about our users and have engaged community members as partners on this project since its inception, through a series of discussions, beta programs and surveys. And our team has responded to most comments on this page, in good faith, with as much information as we could provide. Just like you, we aim to make Wikipedia better for our users: our goal is to modernize our aging software infrastructure, and make it more inviting to the many new users we need to grow our community. We would be grateful for your support to help reach that goal in coming years: there is much work to be done to catch up with user expectations. We may not always get it right the first time, but we're committed to improving the tools incrementally, based on community feedback. Thanks for your understanding. Fabrice Florin (WMF) (