Talk:Community Liaisons/Media Viewer consultation/Archives/2014-09

This is not an archive in the normal sense of this gadget, but a page where a bot puts discussion topics regardless of the status of resolution or discussion, just to make the main page shorter

Please engage further in discussions here, feel free to answer. Just don't add any new topics, the bot will do so on its own by moving them from the main page over here.

Display image annotations

• Problem: Finding the annotations on an image is hard and unintuitive.

• Proposed solution: Display the annotations right in the media viewer. —Edgar Bonet (talk)

Discussion (Display image annotations)

Annotations are a very useful tool to add information right into a picture. They where always hard to find in the english Wikipedia, but that was not the case of the french Wikipedia (only 1 click away from the article). The new Media Viewer is then, in the french Wikipedia at least, a significant regression in this respect. —Edgar Bonet (talk) 13:39, 29 August 2014 (UTC)

I believe this is a known issue, but the Multimedia team can confirm. Quoting Erik M. from wikimedia-l here, "Image annotations loaded via the community-created gadget are a beautiful hack (indeed one of my favorite gadgets of all time), and if the current implementation can be rendered in MediaViewer without negative performance impact and at reasonable cost, we'll get there. If not, let's migrate these annotations to a more supportable system in the long run and treat it as a File: page feature for now." (bottom of https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/074135.html). --Elitre (WMF) (talk) 14:26, 29 August 2014 (UTC)

OK, the issue is known, but the question is: where should it be in the Improvements List? I would put it in the “Should have” list. —Edgar.bonet (talk) 16:44, 29 August 2014 (UTC)

The use of the word "hack" by Erik M. is disingenuous at best, and cruel at worst. Volunteers worked to make image annotations a reality, and nobody complained, because it is a handy feature. In that mailing list post, Moeller invokes "FUD". Speaking of FUD, now that the latest WMF product doesn't support annotations, suddenly the feature is called a "hack" by the number two at WMF... FUD indeed. Eddymason (talk) 12:28, 1 September 2014 (UTC)

I don't think the word should be seen as carrying a negative meaning, regardless of who uses it. --Elitre (WMF) (talk) 12:32, 1 September 2014 (UTC)

I see nothing positive about the use of the word in the article you linked. It does state that the phrase can be used as "ironic praise", and cites a 1982 book to support that assertion. I stand by my statement that Moeller should not describe the hard work of others as a "hack". Eddymason (talk) 12:46, 1 September 2014 (UTC)

The canonical definition is in the Jargon File here, and defines it as "An incredibly good, and perhaps very time-consuming, piece of work that produces exactly what is needed." Whatamidoing (WMF) (talk) 16:52, 1 September 2014 (UTC)

Yet it is not supported in Media Viewer. :| Eddymason (talk) 02:16, 3 September 2014 (UTC)

MV should invite users to improve description

• Problem: MV show file's page and description like it was the final, unchangeable thing. (valid for Commons too, but there is at least button "edit")
• Proposed solution: MV should invite users (experienced, time-to-time users and still-only-readers) to change description and create or translate it to another languages.
• Proposal of KuboF (talk) 17:58, 29 August 2014 (UTC)

Discussion (MV should invite users to improve description)

• +1. I opened a discussion about that (and invites to translate) a bit below. FYI, this does feel like a thing that could warrant opt-in mode to me -- this is possible to implement without clutter, and the old File:* pages provided this functionality. Thanks! --Gryllida 10:06, 31 August 2014 (UTC)
• +1. That's important. Yann (talk) 17:35, 2 September 2014 (UTC)

Forward/Back Buttons (of browser) don't work as expected when closing media viewer (X-Button)!

• Problem: Forward/Back button of browser don't work as expected after closing media viewer with X-button in the top right corner!

• Proposed solution:

• Proposal of Freddie331 (talk) 23:59, 29 August 2014 (UTC)

Discussion (Forward/Back Buttons (of browser) don't work as expected when closing media viewer (X-Button)!)

Some reading material for this: bugzilla:62266. It turns out it's not as easy as I thought as well; I'll try to get someone to summarize the very lengthy bug report discussion. Keegan (WMF) (talk) 04:33, 30 August 2014 (UTC)

I usually dislike a "me too" message, but as I just got a MediaViewerConsultation notice on top of the page I read, asking for feedback, I'll just add my feedback to this tidbit of earlier feedback: Me Too! 2001:610:767:1981:E12F:A598:1A3A:7995 19:47, 1 September 2014 (UTC) Edit: sorry, I was not logged in. This is a proper signature: MacFreek (talk) 19:48, 1 September 2014 (UTC)

After reading through the bug mentioned by Keegan, I still prefer the solution proposed in bugzilla:66217. Pictures already have URLs, their File: pages. And yes those pages really, really could use a serious and complete overhaul. --HHill (talk) 20:56, 1 September 2014 (UTC)

To be a bit more verbose: The evidence presented in bugzilla:62266#c1 combined with my browsing experiences over the years IMO points to not changing the URL (bugzilla:66217) as being the usually expected behaviour. And again, yes, current File: pages are pretty much unusable for many (or even most?) use cases. But adding yet another level of complexity (a new kind of URLs) to the already rather uber complex situtation does not help much in the medium to long term IMO. --HHill (talk) 08:51, 2 September 2014 (UTC)

Slowness in slow internet areas

• Problem: I found the original MV worked very slowly in low internet speed areas, taking ages to load up a large image that was fuzzy and unviewable for a period, as compared to the operation of the normal system which produced a clear, if smaller, image in seconds. I recall getting rather cross as a customer when I suddenly found I was waiting for much longer than before to get the information I wanted, looking at a large fuzzy blur!

• Proposed solution: I dealt with this by disabling MV, as it was slower and seemed to have less functionality than the old system from the perspective of the editing I did (I couldn't see the sources, licenses etc. if memory serves). An MV that worked efficiently in poorer parts of the world, where the internet speeds are often low, would also resolve this problem.

• Proposal of Hchc2009 (talk) 03:46, 30 August 2014 (UTC)

Discussion (Slowness in slow internet areas)

• Hchc2009, can you measure load times please? Firebug is a useful tool. (Although I might perhaps expect statistics on load time be, in theory, available server-side.) --Gryllida 09:44, 31 August 2014 (UTC)

Not really my sort of thing, Gryllida - I tend to volunteer on the content generation side of the Wikipedia, and I don't usually get involved in product testing. Hchc2009 (talk) 13:13, 31 August 2014 (UTC)

Hchc2009, Gryllida these metric boards might interest you:

• Geograph of Media Viewer performance
• Overall global network performance

It's fair to say that Media Viewer is not friendly to slow internet connections. However, neither is the file page, according to more stats. If you set the stats and the 95th and 99th percentile, Media Viewer loads more than a second faster than the file page. They both load far to slow for your experience, though.

As far as your other concerns go, I'm sorry Media Viewer didn't work out for you aside from performance, and I thank you for taking your time to leave feedback. There's ideas here on this page that is helping to improve visibility of sourcing and licensing. Keegan (WMF) (talk) 04:04, 1 September 2014 (UTC)

The text under the graphic clearly states

Note: the file page loading times measurements are experimental and might incorrect. file page loading time for file page views (using the mediaWikiLoadComplete field from NavigationTiming data, which is based on the domready event) Media Viewer time from thumbnail click to displaying the final image; only measured the first time Media Viewer is opened on a given page. Subsequent invocations are heavily preloaded so it is not clear what would be a fair comparison. 68.230.140.130 10:20, 2 September 2014 (UTC)

Average of 8 seconds here for higher resolution images, 2-3 seconds for lower resolution images, until which an uncomfortable looking blur fills the screen. There is a blue status bar underneath to indicate that it is still loading, but this is not the Commodore 64 days, this is supposed to be the modern Internet. My net speed is approximately 3.0Mbps. Orderinchaos (talk) 01:52, 3 September 2014 (UTC)

Direct link for reuse

• Problem: Reuse link syntax is way too long and forces reusers to use the media viewer rather. For example for file File:User_99of9_reflected_in_Australian_Magpie_eye.jpg it gives the link as

https://commons.wikimedia.org/wiki/File:User_99of9_reflected_in_Australian_Magpie_eye.jpg#mediaviewer/File:User_99of9_reflected_in_Australian_Magpie_eye.jpg which is way longer than necessary for reusers.

• Proposed solution: Shorten the link syntax when a user chooses "Use This File" and don't force MV. In the example above reusers should just be told to link to https://commons.wikimedia.org/wiki/File:User_99of9_reflected_in_Australian_Magpie_eye.jpg. This is logged as bug 69539.

• Proposal of 99of9 (talk) 11:26, 30 August 2014 (UTC)

Discussion (Direct link for reuse)

• +1. When MV stops ripping image out of context (i.e. by means of volunteers adding a mode such as at the screenshot provided), people should probably be given both options. Until then, I agree with you -- linking to the File: page directly appears to make more sense. --Gryllida 09:37, 31 August 2014 (UTC)
• Support this. We should be making it easier for content reusers, not harder. As time goes on a much greater share of Commons link-ins will be from non-WMF pages, and this needs to be accommodated Orderinchaos (talk) 01:48, 3 September 2014 (UTC)

Page too long

This page is over 200kb, which is known to be a problem for people on slower connections. I'm going to start archiving some of the older discussions. I'll begin with the older ones that are focused on what happened in the past months rather than on what should be done in the future. These will be moved into General discussion. Whatamidoing (WMF) (talk) 17:07, 1 September 2014 (UTC)

• You are making this page shorter by deleting things the WMF wants to ignore. Contrary to your assertion, you are hiding things THAT ARE NOT OFF TOPIC. As has been discussed on this page before you hid such discussions when Keegan did the same thing, it is inappropriate and hostile to hide on-topic feedback that you'd rather ignore. I must insist that you undo your hostile changes immediately. --98.207.91.246 17:45, 1 September 2014 (UTC)
• I just wanted to post something similar, this looks like an attempted whitewash. All fundamental questions abpout whether it should be opt-in or opt-out are edited out of sight, as the WMF doesn't want any real critic, just superficial cosmetics. It fit's with this superficial software bling-thing, that the WMF for unknown reasons declares as something important. --♫ Sänger, superputsch must go (talk) 17:57, 1 September 2014 (UTC)
  • Could you help me restore what was lost? Wiki markup is just putting me to sleep at this point. --98.207.91.246 17:59, 1 September 2014 (UTC)
    • Nothing was lost. It was w:WP:SPLIT to another page. If you click the link in bold-face type at the top of the page, or the link in the page history, you'll find the discussions. Whatamidoing (WMF) (talk) 18:01, 1 September 2014 (UTC)

We need to get these pages down to a size that people can read easily. There are three main types of information on this page:

1. Ideas for changing the software to work better for people who are using it
2. Procedural questions about when, whether and how to deploy it
3. Stuff that has no relationship at all to Media Viewer (e.g., everything about VisualEditor).

These are fundamentally three separate conversations. There is no need to have them all on the same page. There is a need to have this page short enough that people can read it on mobile devices. This means that we have three options:

1. Implicitly tell people with slower connections or on mobile devices that their participation is unwelcome;
2. Set a very tight timer on all discussions; or
3. Split the discussions onto multiple pages, and continue them there.

I'm unwilling to do the first. The second will have the net effect that fewer staff and many fewer Wikimedians will read all the comments that appeared over the holiday weekend, because most of them will be archived before they get back to work. I'm pretty confident that the third will work, especially since I've linked the main page for procedural discussions in bold-faced type in the box at the top. Of course, if you think that Wikimedians aren't capable of finding a page presented in bold-face type, then we could discuss alternative ways of drawing attention to it, but my experience is that people around here are pretty smart.

Finally, about your accusation that I'm selectively moving things, let me point out that my statement said I will "begin with" this set of discussions (precisely because I happen to find them interesting and want to make sure that they are not ignored), not that I would only be moving those. (The technical suggestions, however, are likely to just get plain archived, rather than being moved to a page for active and focused discussion.) Also, you may have noticed that multiple discussions opposing the requests for opt-in status were also moved. Whatamidoing (WMF) (talk) 18:01, 1 September 2014 (UTC)

@Whatamidoing (WMF): You are proceeding from the flawed assumption that this page was a worthwhile way to approach these issues to begin with. Trying to fix a process that was not appropriately designed to begin with may not be the best use of anybody's time. -Pete F (talk) 18:25, 1 September 2014 (UTC)

In general, I would agree with you. In the specific case, if you and I really thought that this process was fatally flawed, then neither of us would be here. Whatamidoing (WMF) (talk) 18:32, 1 September 2014 (UTC)

As I noted on your page, the concern about page load times is a red herring. The front page of meta is 642 KB already. If you care about slow loading times, a large chunk of text is not the place to start. It is unacceptable to me for the WMF to divide feedback up into things they want to hear and things they want to hide. --98.207.91.246 18:04, 1 September 2014 (UTC)

I believe that people in the WMF want to hear everything. Different staff will have different interests, of course; a dev is unlikely to be interested in discussions about votes, but I know that Rachel is very interested in those. Even the comments about VisualEditor will interest some staff (not anyone whose main assignment is Media Viewer, however). Whatamidoing (WMF) (talk) 18:10, 1 September 2014 (UTC)

(ec) Does Meta have any archiving bot that can be used? It would be much better to just set up a normal archive instead of selectively moving particular threads to a different page. Maybe use settings of a minimum of 10 threads left and 5 days of inactivity before archiving, and put into archives no bigger than 100k? Note: Archiving frequently needs to be discussed, instead of just getting into an edit war. The BRD cycle is Bold move, Revert (ONCE ONLY), then Discuss. It does not stand for Bold move, Revert, Defend with as many other reverts as necessary. And if you are the one who made the bold move, you DO NOT get to do ANY reverts before fully discussing and reaching a consensus - the status quo is maintained until a new consensus is reached. Apteva (talk) 18:19, 1 September 2014 (UTC)

As I continually have to point out in my volutneer capacity, BRD isn't a policy anywhere. Whatamidoing (WMF) (talk) 18:25, 1 September 2014 (UTC)

(withdrawn) But two reverts by the same editor is still an edit war. Apteva (talk) 21:26, 1 September 2014 (UTC)

I don't think that last comment was entirely fair, Apteva. Whatamidoing (WMF) has paused in the revert cycle, stepped back and he's engaging here on the discussion page. Calling someone a "jerk", even if you're feeling really aggrieved and a bit bruised, is quite personal, and, to me, doesn't feel called for here. Hchc2009 (talk) 19:15, 1 September 2014 (UTC)

Two edits may be an edit war—at a project that has such a policy. It does not appear that Meta has (or IMO needs) such a policy. Whatamidoing (WMF) (talk) 23:52, 1 September 2014 (UTC)

I agree with @Apteva:. The behavior of WMF staff supporting one another's controversial actions is one we would refer to as COI meatpuppetry if any other organization engaged in it. -Pete F (talk) 18:22, 1 September 2014 (UTC)

In fact, I have just set up bot-archiving for the rest of the page. Notice that I haven't set up bot-archiving on the procedural discussions, because (a) that page isn't nearly as long yet and (b) procedural questions normally require more time and thought. A technical suggestion is something that you can often understand and make a decision on in minutes (especially if it's not a new idea); a discussion about people's rights and responsibilities benefits from time to think and to see what other people are thinking. When that page gets longer, though, we'll probably want to set up a time-based archive there, too. Whatamidoing (WMF) (talk) 18:25, 1 September 2014 (UTC)

Umm... isn't it obvious what's meant to happen? We were instructed to make our suggestions here, on the promise that "WMF staff will update this list regularly", but I've only seen one thing added since I got here. So, go ahead WMF staff, add my uncontested suggestion to the primary page, and you can archive the talk section about it. --99of9 (talk) 00:31, 2 September 2014 (UTC)

It's a holiday weekend in the US. Nobody's been in the office, and therefore there have been few updates. I expect that there will be a discussion about which items are appropriate and feasible sometime tomorrow (Tuesday). Having said that, there has never been any guarantee that all ideas, or even all uncontested ideas, will be put on the list for development during the next month or two. Whatamidoing (WMF) (talk) 01:47, 2 September 2014 (UTC)

Well maybe you've just discovered the reason the page got too long for low bandwidth users - the team requested feedback just before going on holidays so that they weren't able to deal with the feedback as it arrived. Another learning opportunity for the next consultation? Happy holiday to you all! Regarding adding stuff to the list - if you want to never implement a suggestion, you should at least do us the service of discussing why not (i.e. "contest" it) - thus if anything uncontested is archived without action, it is frankly at least a little rude. --99of9 (talk) 02:23, 2 September 2014 (UTC)

Well the archiving did not work as intended - nothing got archived. But why are "General discussion" and "Other discussion" listed as "Archives"? Normally archive means "closed to discussion", but my understanding is these are just categorized discussions. How about linking them in a navbar at the top instead of putting them in the archive box?

Are there any of the above threads that are resolved and can be moved to the archive? Apteva (talk) 03:43, 2 September 2014 (UTC)

Apteva, categorizing is exactly what we would like to do: the discussion about those threads can (and should) continue. So I thought moving stuff day after day could be a solution, but categorizing broadly is probably more helpful. --Elitre (WMF) (talk) 11:33, 2 September 2014 (UTC)

It's a little odd to have them listed under "archives". My preference, though, is to have them linked to make them easier to find. Perhaps we should add a big "You can discuss here" to the top of those pages? Whatamidoing (WMF) (talk) 16:20, 2 September 2014 (UTC)

This wikilawyering by officers makes me sick. Can't we just simply nominate this occupational therapy page for deletion or is there "no official WMF policy" for that. --Sargoth (talk) 08:55, 2 September 2014 (UTC)

There's a deletion process on Meta, but I'm not sure what it is. Whatamidoing (WMF) (talk) 16:20, 2 September 2014 (UTC)

Add {{RFD}} at the top of the page, and create a subsection to Meta:Requests for deletion#Pages with the section heading with the Pagename, or for a speedy deletion, just add {{delete}} to the top of the page. Apteva (talk) 17:27, 2 September 2014 (UTC)

;-) --Sargoth (talk) 18:38, 2 September 2014 (UTC)

Löschgrund, siehe What Meta is not:

„13. Meta is not an appeals court. If a community decides something, don't come here to try to get the decision overruled.“

--Winternacht (talk) 20:32, 2 September 2014 (UTC)

Interoperabilität

Konqueror zb. geht nicht. —The preceding unsigned comment was added by 217.189.206.149 (talk • contribs) 1 September 2014, 21:05 (UTC).

Translation: It doesn't work on Konqueror (the web browser). User:Keegan (WMF), is this a known bug? Whatamidoing (WMF) (talk) 23:42, 1 September 2014 (UTC)

Discussion (Interoperabilität)

I thought that the Multimedia team wouldn't mind if I filed a bug anyway. --Elitre (WMF) (talk) 14:50, 2 September 2014 (UTC)

Make it opt-in at least.

• Problem: I suddenly found myself looking at content through the media viewer, and I was not pleased since I couldn't access the information I wanted nor did I wish to view the content in that manner.
• Proposed solution: Make it opt-in at least. I hated the media viewer, and I certainly didn't appreciate it being sprung on me by surprise. That having been said, I won't go so far as to forbid anyone from using it. If people really want it, they can opt-in to use it.

Also you really must find a better way for people to comment on it. I have no clue what I am doing... there's no feedback page or web form. I don't know how to edit wikipedia.

• Proposal of an average Wikipedia user. —The preceding unsigned comment was added by 75.119.224.120 (talk • contribs) 1 September 2014, 22:30 (UTC).

Discussion Make Media Viewer Opt-In

Currently I keep the default setting on some browsers and some languages, just to see when this thing will disappear. If it becomes optional (voluntary opt-in) for all languages I will have no further comments. As far as I am concerned, WMF can continue working on this disaster, but it will be without my money. --Michel le tigre (talk) 09:05, 2 September 2014 (UTC)

The simpler button look was better

I prefer the current arrow, though it could do with an edge around the tab part to make it obvious. But as for the new prototype, if it is to be pretty much like that, I'd take out the the three seashell-esque icon from the blue button and replace it with a circle, a square, or an arrow icon. And I actually do have a critique and experience in opposition to the three seashells, which I consider a metaphor for minimalist computer buttonry with no indicitive symbolism, i.e. the three line menu button. And it revolves around the point that utter minimalism is counter intuitive, and I believe that is what you are trying to avoid. It seemed like everyone else was making a whole section so I did too. ~ R.T.G 02:37, 2 September 2014 (UTC)

Duly noted, thank you much for your time trying out the prototype and the critique. It shall be taken into consideration. Keegan (WMF) (talk) 03:13, 3 September 2014 (UTC)

Make it easy to re-use the media

• Problem: When reusing media one has to click and to copy a number of pieces of text to make a valid reference for the reuse of the medium. Put this information directly below the picture.

• Proposed solution: Each image should include a copy & pastable text for making valid references to the image. The German Wikipedia did this, for example, in the pictures from the German Federal Archives. There is a text such as

Attribution: Bundesarchiv, B 123 Bild-F123456-0000 / Original Photographer / CC-BY-SA

This I can just copy and put in the caption of the picture I am using in a slideshow, for example. That saves much time for the user and promotes proper reuse! With the MediaViewer, all the information has gotten pushed a click further away (and I usually mis-click a few times to boot). The focus should not just be on the pictures, but on their use.

• Proposal of WiseWoman (talk) 06:35, 2 September 2014 (UTC)

Discussion of Make it easy to re-use the media

Totally agree with this suggestion. Especially: show the user explicitly and directly what the correct 'attribution line' is, so that she only has to copy it. I see wrongly attributed images from Wikimedia Commons on external websites (newspapers, blogs...) all the time, and this simple addition would make a huge difference there. Spinster (talk) 19:50, 2 September 2014 (UTC)

Did y'all notice the "Use this file" part of the current Media Viewer? If you click "Use this file" in bold it says "You need to attribute the author." It then provides text for attribution for, example, in a slideshow (as I've done myself - very handy). For example I followed the gallery link, clicked a random image, and generated ""Alfred Rapp Fernsehstudio Köln" by Brodde - This image was provided to Wikimedia Commons by the German Federal Archive (Deutsches Bundesarchiv) as part of a cooperation project. The German Federal Archive guarantees an authentic representation only using the originals (negative and/or positive), resp. the digitalization of the originals as provided by the Digital Image Archive.. Licensed under Creative Commons Attribution-Share Alike 3.0-de via Wikimedia Commons - https://commons.wikimedia.org/wiki/File:Alfred_Rapp_Fernsehstudio_K%C3%B6ln.jpg#mediaviewer/File:Alfred_Rapp_Fernsehstudio_K%C3%B6ln.jpg."

Now, in my opinion that URL needs fixed to remove the Media Viewer hash, but is that along the lines of what you're going for? Can this be accessed differently that might be more intuitive for you? Keegan (WMF) (talk) 03:19, 3 September 2014 (UTC)

"Must have" addition: quick loading of images/informations

• Problem: today, you list only 4 "must haves" in "The Media Viewer Improvements List" on Community Engagement (Product)/Media Viewer consultation. i think you missed really essential points, here is an other one:
  • the MV must load images and all information as quick as the normal wikistyle display (or even quicker!), but definitly not slower! – my personal experience is that it takes at the moment 2-4 times longer (several seconds!), so it is not an improvement as promised, but a disadvantage for users/readers (and this point has really deterrent effects for users/readers; we want to "click and see", not to "click and wait")

• Proposed solution:
  • make MV working faster before using it.
• Proposal of Holger1959 (talk) 13:57, 2 September 2014 (UTC)

Discussion ("Must have" addition: quick loading of images/informations)

Holger1959, would you mind getting Firebug (or a stopwatch) and timing a handful of images? I've done this a few times (I use recent featured articles as my testing ground, because they always have images, and Special:Random doesn't always find images). Although MediaViewer often feels slow, it's usually about 20%–40% faster for me in Safari and Firefox on my Mac. Whatamidoing (WMF) (talk) 16:35, 2 September 2014 (UTC)

Suggestions from Ningauble

I am writing in response to a banner message displayed at the English Wikiquote, requesting feedback to help improve the user experience.

Before offering suggestions for improvement, let me first say that I really like the idea of a slideshow viewer for educational presentations in, e.g., an online encyclopedia. One use-case that comes to mind would be a sequence of images illustrating foetal development. Other use-cases might be suggested by Wikipedia articles that use the "gallery" feature. However, the present implementation does not really live up to this potential, and it could be improved.

Suggestion: Editable slideshow

• Problem:  The tool does not provide a mechanism for authoring and editing slideshows, i.e. to select, arrange, and annotate images for a coherent educational presentation. Rather, readers are presented with an automatically generated sequence that, if not entirely random, is a haphazard assemblage lacking any semblance of editorial judgment.
• Proposed solution:  Provide a mechanism for authoring and editing slideshows, and disable their automatic generation. (Selecting and rearranging images in an article to force some coherence on an automatically generated slideshow would be a recipe for mangled articles.)
• Proposal of Ningauble (talk) 16:51, 2 September 2014 (UTC)

Discussion (Editable slideshow)

• As proposer, I think "the slideshow that nobody can edit" is a critical issue beyond the scope of any quick fix, and calls for taking it back to opt-in, or back to the drawing board. ~ Ningauble (talk) 16:51, 2 September 2014 (UTC)

Suggestion: Launching slideshows

• Problem:  For contributors, interposing the non-editable slideshow between the editable article and the editable file descriptor page is an impediment. For readers, "click on any image to view a slideshow of some other images" strikes me as a cumbersome affordance:  most objects on which users can click lead to specific additional information about that on which they clicked, not to some collection of things that include the one on which they clicked.
• Proposed solution:  Launch the slideshow viewer when readers click a clearly identified affordance for that purpose, not whenever they click to drill down on any image.
• Proposal of Ningauble (talk) 16:51, 2 September 2014 (UTC)

Suggestion: Inapplicable contexts

• Problem:  At the English Wikiquote specifically, the only use case that has been identified for readers using this extension is "it might be very convenient for folks who want to browse just the pictures, without all those pesky quotations and bothersome citations that for some reason clutter our pages". (brief discussion at Wikiquote)
  This usage is contrary to the purpose of Wikiquote, which is all about quotable texts.
• Proposed solution:  Provide a mechanism whereby the feature may be disabled or uninstalled at projects where it is not applicable or is even detrimental.
• Proposal of Ningauble (talk) 16:51, 2 September 2014 (UTC)

Damn slow…

• Problem: The MV is so extremly slow compared to the normal file page, because it's loading a far bigger image by JS, which sometimes even leads to crashing the webbrowser on my not-so-fast PC. And the same for the description and all those fancy icons (which means I'm often not seeing the license because of some transmission/processing failure).

• Proposed solution: Just don't ;-) Or at least provide a way to permanently disable the MV for not-logged-in users without having to open MV.

• Proposal of 84.172.144.1 16:59, 2 September 2014 (UTC)

Abandon project

• Problem: Media viewer is redundant in the face of the pre-existing wikimedia content page. It attempts to wrest control of image presentation from the browser. All modern browsers have robust built-in image display abilities, often tuned to the device that the browser runs on. Media viewer adds nothing to this except another layer of interfaces that the naive user must learn on top of the browser controls that they are already familiar with. In contrast, the wikimedia page is unastonishing, works in every browser, and every user that has ever seen a webpage can understand how to navigate it.

• Proposed solution: Abandon the entire project and devote its resources elsewhere. When you discover that you are riding a dead horse, the best strategy is to dismount.

• Proposal of 128.104.68.117 19:16, 2 September 2014 (UTC)

Ask readers (not just editors) for ample feedback

• Problem: The media viewer is designed to make images more attractive to our projects' readers, but do we really know what they think and want? Are we certain that the average Wikipedia user likes and wants these types of full-screen media viewers, like other websites (such as Flickr) have also rolled out in the recent past?

• Proposed solution: Do a large-scale usability test with readers who are not active Wikipedia editors (i.e. not logged in). Typical readers whom we are interested in targeting: teachers who use Commons images in their classrooms; students who use images from Commons in their homework; students who do basic research; hobbyists and professionals of various backgrounds who use Wikipedia and sister projects It would be extra interesting if it would be combined with usability testing and users' opinions about similar media viewers by other websites (Flickr comes to mind). (Just adding my personal hypothesis here: I think that users like larger images, but don't like overlays and that they also appreciate to see more metadata. I think we need the larger images, but in a radically different design. Feel free to prove my hypothesis wrong with statistically significant data!)

• Proposal of Spinster (talk) 19:45, 2 September 2014 (UTC)

Discussion (Ask readers (not just editors) for ample feedback)

Thanks, Spinster. The Wikimedia Foundation's Lead Research Designer, Abbey Ripstra, conducted new usability tests last week with Media Viewer that should be ready for presentation to the community at the end of the week. This usability test did not involve mass numbers of people - this is a great article to read about how five people, properly tested, can tell you what you need to know about usability. Do note that I'm not an expert or an amateur at research, that's something interesting that I'm passing along :) Keegan (WMF) (talk) 03:46, 3 September 2014 (UTC)

Display thumbnail of image along with useful data, not just a bigger picture

• Problem: I rarely, if ever, click on an image to see a bigger version of an image. What I would like to see happen when I click an image deals solely with tracking down copyright violations and improper licensing.

• Proposed solution:

1. Media Viewer should reduce the image to a thumbnail to provide room for valuable information.
2. If the source image is given as an image to an image file, display a thumbnail of the source image file.
3. If the source image is given as a URL to an html file, search the html file for a reference to a corresponding image and display the resulting URL and a thumbnail of source file.
4. Automatically search TinEye for the matching images and provide a result.
5. Display the uploader's status. Is he blocked? On what projects?
6. Give me a link to deleted images the uploader has previously uploaded.
7. If the image is part of an infobox, give me the thumbnail and a link to image that this one replaced.

These are items that are useful to people attempting to create an encyclopedia. "Look at the pretty pictures" is not a function that is useful to people attempting to create an encyclopedia.

• Proposal of Kww (talk) 20:18, 2 September 2014 (UTC)

Discussion (Display thumbnail of image along with useful data, not just a bigger picture)

That sounds like an extraordinarily useful gadget, Kww. As you know, Media Viewer isn't going to work for editors that work with file pages a lot. As an editor, I hardly ever touch file pages. But your proposition sounds like quite a handy editor tool. Perhaps you and I could find someone interested in such a project? Keegan (WMF) (talk) 03:37, 3 September 2014 (UTC)

I don't see it as a gadget: I see it as what MediaViewer should actually do, since there isn't any reason to display a series of big pictures out of context. While a gadget isn't necessarily a bad idea, I was quite serious when I proposed this as the MediaViewer functionality.Kww (talk) 05:29, 3 September 2014 (UTC)

More user-friendly, and more information

• Problem: Twofold really:

1. The current design is anything but user-friendly. It's taken me some time to figure out that that little icon at the bottom right (which even at my screen resolution does not stand out) takes me to the Commons page for the image, which contains the data, but until then, the data is completely obscured. Most people wouldn't know that is the symbol for Commons, either - we should avoid "mystery meat" as a fundamental web design principle. (Kudos to whoever changed the colour scheme btw - I had a point in here about not being able to even see the image on weaker monitors, but it's changed from white on dark grey to black on light grey in the last day or so).
2. The description and, in fact, any useful information to the average person about the photograph such as the date etc is not visible, and one now has to go to two clicks to get that information. Inside Commons itself there is a bypass accessible by clicking the filename below as opposed to the image, but this is not possible on Wikipedia. The date can be important - it took me a while to figure out when the image at w:Holy Trinity Avonside was taken, and given the church was damaged twice, this wasn't a triviality.

• Proposed solution:

1. More clearly identify a way of getting to the relevant data page.
2. Design a consistent method within Wikipedia for bypassing the viewer for those who wish to (even if it's just a little icon in the corner).

• Proposal of Orderinchaos (talk) 01:35, 3 September 2014 (UTC)

Discussion (More user friendly, and more information)

Does the propsed prototype resolve most of the issues you outline? It has a more clearly-defined link to find more details, and the option to disable is in the gear icon right there in the image box. Keegan (WMF) (talk) 03:34, 3 September 2014 (UTC)

Definitely a significant improvement (Sorry for long delay in replying, I've been unwell). Orderinchaos (talk) 13:15, 14 September 2014 (UTC)

Big button that makes media viewer go away forever.

• Problem: how to get rid of Media viewer?

• Proposed solution: big button on the side that always shows up, that says "get rid of the new media viewer." Then add a big box in the middle of the screen pointing to the button on the first start of Media Viewer.

Also respect local consensus on Wikis by making the button auto push.

• Proposal of 123chess456 (talk) 03:42, 3 September 2014 (UTC)

Disable right-click

• Problem: encourages downloading without following licensing requirements

• Proposed solution: Disable right-click.

Discussion (Disable right-click)

as Media viewer no longer send the user to Commons right click should be disabled to ensure users are sent to the image source where full licensing details are available. Gnangarra (talk) 23:19, 28 August 2014 (UTC)

• The next prototype is far far more clear about the license already as far as I could see. I wouldn't like to disable right click, it may be useful for other things such as viewing current page info. --Gryllida 04:20, 29 August 2014 (UTC)
  • As much as I would support that right click be disabled, the issue would be that it would need to be coded in a way that it doesn't disable it for the whole site. Bidgee (Talk) 02:28, 30 August 2014 (UTC)

• What? Right click is very useful. Of course I do not use javascript (I use Tor, which disables Javascript), so Media Viewer does not exist for me anyway. Disabling right click is a very annoying "web trick". What you can do though, is make make media viewer available as a right click option, and use a left click to go to the image, just like it always did. Apteva (talk) 13:42, 31 August 2014 (UTC)
  • I agree that disabling right click is a very annoying web trick. --NaBUru38 (talk) 22:29, 1 September 2014 (UTC)
• Right click is definitely should not be disabled. But it could call a popup menu. --UniCollab (talk) 10:50, 2 September 2014 (UTC)
• Definitely do not disable right click. I actually have an extension on my browser specifically designed to prevent sites from doing this and other annoying javascript tricks.Phatom87 (talk) 00:57, 4 September 2014 (UTC)

Should be a way to automatically exclude icon images from Media Viewer

• Problem: Icon images, eg those found next to portal links on English Wikipedia, are shown as a small image (in the order of 100x100-or-so pixels) in the center of a huge black screen - that's not particularly appealing or useful for readers or editors, is it? (Example: File:Nuvola apps kalzium.svg is used for the Science Portal)

• Proposed solution: There should be some wikitext markup to stop images being loaded into Media Viewer, that can be added to the templates (typically) that generate these icons. - Evad37 (talk) 03:54, 29 August 2014 (UTC) (struck as already implemented - Evad37 (talk) 00:15, 2 September 2014 (UTC))
  • 1) Media viewer should automatically exclude small images below a certain size (eg. maybe 50x50px, or 100x100px, or whatever) on the displayed page
  • 2) Additional proposal by Odysseus1479 to have an option to toggle between Media Viewer excluding these very small images plus ones specifically marked for exclusion (as the default state), and including all images in the Media Viewer – via an icon or button in an unused corner of the interface - Evad37 (talk) 00:15, 2 September 2014 (UTC)

Discussion (Should be a way to automatically exclude icon images from Media Viewer)

Hi. I believe that there is already a way to do so when circumstances require it? --Elitre (WMF) (talk) 03:58, 29 August 2014 (UTC)

Evad37, please let me know if what Elitre (WMF) means is the answer you're looking for so we will know if it's an additional feature request. -Rdicerb (WMF) (talk) 17:52, 29 August 2014 (UTC)

Where has that to be placed? Take a look at this page, where I's done some editing. All f***ing flags are shown several times in the MV, that's absolutely ridiculous. If the MV can't differentiate between content and just icons, it's useless. And I will definitely never put those spanclass hacking in my texts, or will they have to be put in the templates like {{CHN|#}}? And who's gonna change all of them? --Sänger S.G (talk) 18:10, 29 August 2014 (UTC)

This edit is an example of how to disable Media Viewer for a flag template (seems to be done for most of the flags already). --Tgr (WMF) (talk) 23:55, 30 August 2014 (UTC)

So I expectall the fan-boys of this bling-thing to go to all this templates and do the work that needs to be done to make their pet toy workable. --♫ Sänger, superputsch must go (talk) 11:08, 31 August 2014 (UTC)

@Rdicerb (WMF): While Elitre (WMF) did answer my initial query (which I did later find in the FAQ), I wonder if it might also be possible for media viewer to automatically exclude very small images? Anything an editor has set to be so small is obviously not intended to be viewed as anything other than an icon. It would save adding code to the many templates that exist across the wikis or to any icons added manually. - Evad37 (talk) 23:44, 29 August 2014 (UTC)

That's a no-brainer, but that piece of software is obviously too dumb to to such easy decisions. --♫ Sänger, superputsch must go (talk) 11:06, 31 August 2014 (UTC)

Sänger S.G, I'd really like to talk through many of your points as you've raised them, but it's replies like this that make discussing your issues very difficult. Can this be a little less snark? If you want to continue talking this way that's fine, but I'm going to have difficulty addressing your issues if not. Keegan (WMF) (talk) 21:39, 31 August 2014 (UTC)

It's ruthless actions like superputsch by the WMF that makes it really difficult to discuss anything with people from over there. As long as this declaration of war against the deWP hasn't been removed completely (including excuses by the main perpetrators for their brutal actions), and the decisions of the communities in enWP and deWP are still ignored "because they can", it's quite a long way for the WMF to regain any trust. It has been utterly destroyed by the superputschists, and this small (and very late) thing here is by far not enough. I'm sorry, if you personally don't belong to the Junta, but Eric and Lila made it clear it was a decision of "the WMF" not some lonely warrior, so you are in there as well. --♫ Sänger, superputsch must go (talk) 22:05, 31 August 2014 (UTC)

Edith says: But this doesn't belong in this item, it's just the general frustration with the whole bptched process (botched by the WMF because they didn't care about community input before). Feel free to remove our last two posts somewhere else. --♫ Sänger, superputsch must go (talk) 22:16, 31 August 2014 (UTC)

Evad37, I made sure that the Multimedia team evaluates your suggestion of automatically excluding very small images. Thank you, --Elitre (WMF) (talk) 12:53, 31 August 2014 (UTC)

i agree that seeing icons amidst the ‘proper’ images can be disconcerting, and would rather have them omitted by default. I also think that requiring the templates containing them to be modified, or their context on every page, is unreasonable as a general solution. OTOH I wonder if this could be made an option, toggling between ‘illustrations only‘ (the default) and ‘all images’, with an icon or button in an unused corner of the interface.—Odysseus1479 (talk) 21:06, 31 August 2014 (UTC)

I don't know how you would define 'illlustrations only' (in software terms). For example, "show only things set as thumbnails" or "show only images that aren't part of a template" would both exclude infobox images, which are often the most important images in an article. As suggested above, perhaps something size-based would work for most cases. Whatamidoing (WMF) (talk) 00:17, 1 September 2014 (UTC)

I wasn’t thinking of the “icon”–“illustration” distinction as being based on anything other than the displayed size (or an ‘exempting’ class as mentioned above, where such may already exist on the page).—Odysseus1479 (talk) 01:25, 1 September 2014 (UTC)

@Elitre (WMF), Whatamidoing (WMF), Rdicerb (WMF), others: Could someone comment on the feasibility of the proposal (excluding images under a certain size)? - Evad37 (talk) 00:23, 3 September 2014 (UTC)

Evad37, at this point the Multimedia team is reviewing suggestions against the available time they have to finish up work on Media Viewer, so it isn't a certainty at this point. That being said, your idea is seen as a good one (though not a "must have"), and the Multimedia team will see if there's time to implement it. If not within the next 1-1.5 months, it will certainly be held as an idea for future iterations. Because they're focusing on "must have" critical fixes right now, I'm not able to give you a definitive response until next week when the consultation is finished and the team has an opportunity to prioritize suggestions, but I'll post an answer here when that decision has been arrived at. --Rdicerb (WMF) (talk) 22:34, 3 September 2014 (UTC)

Hi Evad37, I wanted to follow up with you. The team considered this but due to the amount of time left available to improve Media Viewer before moving on the Structured Data project with WikiData, they will not be able to fulfill this request. This being said, there is a manual means of disabling Media Viewer for very small photos which I hope is helpful. We will also refer to your suggestion on Mediawiki so that an automated means of disabling Media Viewer for small files can be considered in the future when the Multimedia team revisits feature development. I hope that this workaround method works for you for now; thank you for this idea. --Rdicerb (WMF) (talk) 03:26, 13 September 2014 (UTC)

So basically, you're going to keep on forcing broken and conceptually flawed software on us and give up on trying to resolve the issues if you run out of time. This is ridiculous. Abide by community consensus and disable it until you've completed it to the point where you can get community buy-in through the RfC process. If your teams don't have enough time to get the software to that point, they should make the time or abandon it. --98.207.91.246 23:04, 3 September 2014 (UTC)

Why is there such a hurry, and why are you refusing to make it just opt-in given the many problems described here? I fail to see any urgency to make it opt-out, besides some completely irrelevant ego-driven "reasons" but e few higher up persons at WMF. They don't want to lose face, that's all, and that's no valid reason. There's nothing really important with this gadget to make it default, it's just eye-candy, but you handle it as if it is something more, which is nonsense. --♫ Sänger, superputsch must go (talk) 04:17, 4 September 2014 (UTC)

Explain thinking behind the viewer

Glancing through much of the above it appears that there is still a deal of friction between the community and WMF regarding deployment of the proposed new image viewer. The WMF have opened this discussion in a spirit of getting feedback on how best to implement the new software, while the community feel that the discussion should be more about should we have it at all, rather than how it could be improved.

It may be helpful to explain the rationale behind the creation of the new image viewer, so that the community can buy into the proposal. Once the community is on board with the idea, then a more productive consultation can take place. There is also the notion that the community can assist with the thinking behind the image viewer; with a clearer understanding of the Foundation's aims, the community may be able to offer new ideas and suggestions from the perspective of active and experienced end users. There may be profound and long reaching ideas which have not yet occurred to the developers at the Foundation because the various discussion which have taken place so far have not fully engaged with the community, and now we have entered a state of distrust and frustration on both sides which is not making best use of the experience, skills, insight and intelligence of those at WMF and the community at large. SilkTork (talk) 09:34, 2 September 2014 (UTC)

Sorry, I just noticed that there is a format for this page that I didn't follow.

• Problem: Community not engaging with Media Viewer
• Proposed solution: Explain rationale behind deployment of the new software
• Proposal of: SilkTork (talk)

Discussion of the thinking behind the viewer

Hi, there are several documentation pages at mediawiki.org, among them mw:Multimedia/Media Viewer and mw:Multimedia/About_Media_Viewer (several others are linked from these ones). Would you please tell me if and how such pages are failing to provide the information you are looking for? Thanks, --Elitre (WMF) (talk) 11:56, 2 September 2014 (UTC)

Thank you for that. Hopefully, some people might notice your links and follow them. Meanwhile, has there been some consideration regarding if those pages have been advertised as well as they might have been? Seems like there's a bunch of people who are unhappy about this situation. A Vogon response that the plans have been on display at the planning department in Alpha Centauri may be a clue as to why there is continued frustration on both sides. SilkTork (talk) 13:00, 2 September 2014 (UTC)

Among the first things I can think of, there is a page about the product in the Wikipedia namespace at at least 5 big Wikipedias, featuring similar contents + links to mediawiki.org. Ditto for every Tech News issue with related updates. When MV was a Beta Feature, the Information link pointed to existing documentation. We'd love to hear ideas as to how to improve this and other processes: we're collecting them here and would welcome yours there as well! --Elitre (WMF) (talk) 13:11, 2 September 2014 (UTC)

I've just looked at the links you provided. I have seen those pages before. Essentially they say what the tool does, but they do not provide the thinking behind why the Foundation regards the tool as significant. There is a suggestion that the tool is designed to match user expectation, though no guidance as to how such user expectation has been assessed. A little more information as to the strategic thinking behind the creation of the software might be helpful in getting more users on board. There are hints in some of the discussions on Lila Tretikov's talkpage, such as this one, initiated by Jan-Bart de Vreede, that the strategic thinking behind the development of the software was to keep Wikipedia's public interface competitive with other multimedia websites and Wikipedia competitors such as WikiWand. If this is the case, then it might be helpful for that to said openly so it can be discussed, and the community brought on board as to why this is considered an imperative. SilkTork (talk) 13:45, 2 September 2014 (UTC)

WikiWand is not a WMF competitor: they are a target audience and customer of the WMF. The goal of the WMF is to help us create content which other users, both free and commercial, can then reuse and redisplay as they want. WMF should be working with us to create better content for WikiWand, not trying to compete with WikiWand. Kww (talk) 20:22, 2 September 2014 (UTC)

For the record, I didn't know until yesterday that the thing which hides the data in pictures I want to look at was called MediaViewer. It doesn't say the name anywhere on it or provide a link to more information or even a "Help" link. It was ironically enough this comment process at the top of regular Wikipedia that alerted me to it. I'm not a daily Wikipedia editor any more although I have almost 9 years and over 90,000 edits on the project, so it's hard to keep up. Orderinchaos (talk) 01:44, 3 September 2014 (UTC)

Thanks, this just reminded me of more information I should have added to my post above! There are 4 links at the bottom of the fold (when you're viewing a picture in MV, look for the arrow at the bottom of the screen). One explains what the product is, one leads to the feedback page, one links the help page, the other switches it off. --Elitre (WMF) (talk) 09:06, 3 September 2014 (UTC)

User Tour

• Problem: Having done my share of releases, I've found that user education is indispensable to achieve full adoption and acceptance of the new release. With no educations, users often get frustrated when they can't find old features in a new UX and may be entirely unaware of new features.

• Proposed solution: Add a user tour similar to tours that many services have created for web and mobile apps. Indeed, some of these services find user education so important, they leave no option to bypass the tour. Considering the users in this case, it may be more appropriate to display a prominent "skip tour" button/link.

• Proposal of -wʃʃʍ- 21:30, 2 September 2014 (UTC)

Discussion for User Tour

Hi Wllm, I'm going to add this over to the Community Engagement Process brainstorm as this is a more-encompassing idea. --Rdicerb (WMF) (talk) 00:22, 3 September 2014 (UTC)

Where is that discussion happening? I'd like to tune in. -wʃʃʍ- 06:56, 3 September 2014 (UTC)

This is an overall experience already being worked on by the Growth team, the GuidedTour extension. It has a lot of promising applications, such as the one suggested by Wllm. Keegan (WMF) (talk) 03:30, 3 September 2014 (UTC)

I think you meant to point to this page. Is there any chance we can use this for Media Viewer? Is there anything that I can do to help make this happen, given that I'm familiar with the technologies at play? -wʃʃʍ- 06:56, 3 September 2014 (UTC)

I'd say bring it up on the talk page for the extension and let's see what those familiar with the code think. Keegan (WMF) (talk) 19:44, 3 September 2014 (UTC)

Thanks to both of you for keeping it constructive, even when faced with some of the provocations on this page. There are many people who appreciate your efforts, including me. Let me know if there is anything I can do to help move this project forward. -wʃʃʍ- 06:56, 3 September 2014 (UTC)

Allow customizing of Media Viewer within user space.

• Problem: no customization of Media viewer possible.

• Proposed solution: allow users to customize. Also allow wikis to form consensus on whether to customize.

• Proposal of 123chess456 (talk) 03:46, 3 September 2014 (UTC)

Discussion (Allow customizing of Media Viewer within user space. )

Hm, how do you envision customizing Media Viewer in your user space? What would you use it for? Keegan (WMF) (talk) 19:50, 3 September 2014 (UTC)

All useful info supposed to be on Commons. Let readers show it and let's keep it updated by us editors

• Problem: We always were used to go and if needed edit info about pictures, AV-files and what else we have there on Commons. It seems that now we need to do some extra for it by using an external application. Why not keep everything internal like we did for more than a decade?

• Proposed solution: Don't change what worked and is still working well.

• Proposal of Klaas `Z4us`V 12:51, 3 September 2014 (UTC)

Discussion (useful info supposed to be on Commons)

Klass, long time no see :) Media Viewer is not meant to replace nor imitate the file page. It is to provide a different viewing experience, one meant to highlight the media itself over the information about the media. The objective of getting to more information has not changed. Keegan (WMF) (talk) 20:31, 3 September 2014 (UTC)

English Wikipedia files do not capture "Author" field from NFUR template

• Problem: English Wikipedia contains many files under a non-free use rationale, most of which use a standard template, which contains author information. Media Viewer does not capture that field, and consequently lists no author. Example: w:en:File:Mickey_Mouse.png

Discussion (English Wikipedia files do not capture "Author" field from NFUR template)

The author field only exists in w:Template:Non-free use rationale 2, which would also be exposed by adding the MRD tags per commons:COM:MRD specification, see above.--Erik Moeller (WMF) (talk) 17:54, 3 September 2014 (UTC)

MV should be opt-in

• Problem: MV should be disabled by default to all users, with or without an account, at least while it is being developped.

• Proposed solution: disbale MV and make it opt-in. When the product is ready, start a RfC to determine whether it should be accepted or not.

• Proposal of Alvesgaspar (talk) 18:07, 3 September 2014 (UTC)

Please describe how to find the Media Viewer

Before you can discuss the Media Viewer you have have to find it. If any new feature is implemented to Wikipedia, at least the basic usage should be described before. Thus please describe how to find it, i.e. here: https://www.mediawiki.org/wiki/Help:Multimedia/Media_Viewer#How_can_I_find_the_Media_Viewer.3F -- Tirkon (talk) 21:30, 3 September 2014 (UTC)

So submitted, thank you for pointing that out. Keegan (WMF) (talk) 02:20, 4 September 2014 (UTC)

Make sure readers can click through to the largest sizes

• Media Viewer doesn't give readers access to the largest image sizes. Since it became the default, I've twice had to add links – to Marshalsea and Female genital mutilation (see caption under map of Africa) – to the largest size in image captions, to make sure readers can find them. In each case it was either important (a map) or desirable (a work of art) that readers could see the largest size.

• Proposal of SlimVirgin ^(talk) 02:45, 4 September 2014 (UTC)

Discussion

@SlimVirgin: Media Viewer, like the file page, has one-click access to the file in its original size. Currently in Media Viewer that is achieved by clicking the expand icon in the bottom right of the pane, but we're likely going to make clicking on the image do the same, just as the file page functions. Does this satisfy your concern? Keegan (WMF) (talk) 03:48, 4 September 2014 (UTC)

Hi Keegan, thanks for the reply. I'm glad to hear Media Viewer will offer that, though I'm a bit worried about "likely," because I think it's something that really is needed.

For example, looking at this image through Media Viewer, a wonderful painting by William Hogarth of British MPs inspecting the Fleet prison in 1729. The inspection took place because there were complaints that prisoners were dying of starvation in the Fleet and the Marshalsea (both debtors' prisons), and it was such a scandal that (happily for us) the MPs took an artist with them to capture one of the visits. So we're able to see the actual MPs, the warden of the Fleet, and one of the prisoners.

It's a painting that needs to be seen at the largest size to begin to appreciate it, but with Media Viewer there's no obvious way to get to it, and nothing to tell the reader that there's another size for them to look at.

Even now that you've told me I need to click on the bottom-right expand icon, it's still not obvious. There are three icons at bottom right: "Use this file," and when I hover over the other two: "View original file" and "More details about this file on Wikimedia Commons." Clicking either of the latter two takes me to Commons, where with two and three clicks respectively I can see the largest size.

What we need is for the reader to be able to click to the largest sizes using Media Viewer, or at the very least an icon that says "click here for larger sizes," so that no one can miss it. SlimVirgin ^(talk) 04:50, 4 September 2014 (UTC)

Wonderful, thanks for the detail on how it didn't work for you. Very helpful. Keegan (WMF) (talk) 06:07, 4 September 2014 (UTC)

"Must have" addition: correct and full author, source, licensing information

• Problem: today, you list only 4 "must haves" in "The Media Viewer Improvements List" on Community Engagement (Product)/Media Viewer consultation. i think you missed really essential points, here is one:
  • even if the MV may omit other parts of information which are present on image description pages, it must show at least correct and full author, source and licensing information, and i think it has to do this in 99,9% of cases ideally (it's obvious that no solution can do this in cases of maybe vandalism or broken templates, so i count 0,1% for those cases) – but my personal experience is that at the moment it fails in ca. 20–30% of cases, and one or more of the three parts are given incomplete or wrong in MV (which is really not acceptable)
  • to me this looks like technical problems and i think the reasons are mainly information templates and license tags which probably need some imprvements (standardizations or restrictions of customisation options, sometimes missing "microformats" etc)
  • the huge amount of images which don't use any information template yet is also a problem, and i didn't see any proposed solution (or offered help) by the foundation for this aspect
  • the exact technical preconditions (for image templates for MV display) are not really specified or not clear for the communities yet; at the moment voluntary users are confronted with a unmanageable amount of work to fix things for correct MV display (millions! of individual images), and often the users don't even know what is exactly expected from MV how something should be arranged or changed (on Commons we also don't have many users working on such "meta" things, so progress is slow)

• Proposed solution:
  • as long as not all these informations can be fetched fully and correct, MV should not be used; instead you should
    • first develop and specify all needed changes to information templates and license tags (really think about all posibilities in the wide variety of options!, eg. please name the expected positions for certain informations within templates eg. permission vs. license sections, name allowed and disallowed formatting options, name further template inclusion options eg. for arts-related images with lots of specific "template magic", specify how to deal best with images which were already transferred from another project to Commons including sometimes not-obvious attribution eg. from old Wikitravel, name the allowed and disallowed templates for languages/translations/internationalisation, name allowed and disallowed values for "other fields" in information templates which are often used for "attribution" specification, name how external attribution/license links should be handled etc – there are really many tiny but important things to consider)

    more precise: i would like to see dedicated pages with a full in-detail list of MV preconditions for functioning information/license templates and with realizable solutions; this page should be posted open and prominent on all affected projects (=not hidden maybe on some meta or developer site), so that the voluntry communities are really enabled to understand and solve existing problems, to improve their image descriptions eg. by making lists of affected images, to call for help etc.

    • secondly (=only afterwards) force the full and proper use of improved templates on all projects (= wait until all image description pages are updated accordingly before using MV, or actively help the voluntary communities with this critical issue: conversion of millions! of image descriptions)
• Proposal of Holger1959 (talk) 13:57, 2 September 2014 (UTC)

Discussion ("Must have" addition: correct and full author, source, licensing information)

• I'd agree that this is a "must have". Having a product that abides by the conditions of the licence should have been a minimum starting point. Orderinchaos (talk) 01:45, 3 September 2014 (UTC)

• Okay, I'd like to hear some thoughts of development feasibility for this must-have request. It is the position of the Wikimedia Foundation that Media Viewer does meet at least the legal minimum starting point for attribution. Others have a different opinion about this, but the product would not have been released without legal review. So this moves the issue into the realm making Media Viewer work for clearly for all and all possible use cases. That's a technical challenge considering the variety of templates across hundreds of wikis. Thoughts? Keegan (WMF) (talk) 03:27, 3 September 2014 (UTC)

Well, we've already lost (at least) two really good photographers from the project over this one issue, so clearly this is something where the WMF has failed to anticipate content creators' needs. It doesn't bother me as much as all my work basically amounts to an interesting way to spend leisure time and is taken with a point-and-shoot camera, and the new prototype at wmflabs meets my needs, but we have people who are professional photographers who rely on the attributions on photos they spend a long time curating, and having the attribution right is essential to keeping them continue to contribute, otherwise they feel that their hard work is being abused. Without them, you just have 1280x1024 shots from point-and-shoots, not the featured-picture-quality stuff that makes this project truly great. Perhaps a consultation specifically with a selection of those would aid in identifying what their biggest issues are and the technical steps that could be taken to rectify them. Orderinchaos (talk) 13:27, 14 September 2014 (UTC)

@Holger1959: Can you give some concrete examples? There is discussion of concrete examples further up, and most relate at this point to the use of licensetpl_attr and fileinfotpl_credit (see bugzilla:65445 for lengthy discussion of the problem with these particular metadata fields and how they are used today). Now, Media Viewer already displays the author and the source by default, so even in cases affected by this issue, it typically displays the correct information already. In my own tests, in 10 out of 10 random files on Commons, it displays correct attribution and licensing information. If you're seeing 20-30% errors, you're either interpreting things as errors that we are not, or you're looking at something else, or maybe it's not a real world estimate at all?--Erik Moeller (WMF) (talk) 05:59, 3 September 2014 (UTC)

Many of the older images (years 2004/2005).--Kogo01 (talk) 19:37, 3 September 2014 (UTC)

• 
  no author (author not equal uploader)
• 
  no author
• 
  no author
• 
  no author
• 
  no author
• 
  and so on and so forth

Thanks, Kogo01. These very old image decription pages do not contain standard machine-readable information (fixed most easily by just using the {{Information}} template, in use on ~20M files on Commons), which will impact every form of automated re-use, not just the media viewer. There are a few potential changes that I think could be reasonable:

1) Call out the uploader (currently below-the-fold) above-the-fold, labeled as uploader. This would have caught 6 out of 7, and not have been misleading in the other case.

2) Have a "view license" link next to the license when author cannot be detected (it currently shows this when no license can be detected, but not when the author is missing).

3) More explicitly have a "cleanup required" link on those files that points to a central page explaining how missing metadata can be cleaned up.

I don't think other solutions that have been proposed (such as disabling the viewer in those cases) are reasonable or desirable, though I understand this is a contentious issue.--Erik Moeller (WMF) (talk) 21:52, 3 September 2014 (UTC)

Since it's not very many files, and since (as @Erik Moeller (WMF): points out) it impacts all machine-readability, how about this:

4) Hire somebody to update the metadata on these very old files.

This would be a win for everybody; but it doesn't feel right for volunteers to solve a problem that only became an emergency due to the deployment of new software (which is what #3 does). -Pete F (talk) 22:05, 3 September 2014 (UTC)

Hey Pete, I could get behind that. It could be a hybrid model -- driven by paid staff, but anyone's welcome to join in. We (Wikimedia as a whole) need to do that work anyway, so we might as well get started to do it more systematically. Let me kick it around a bit.--Erik Moeller (WMF) (talk) 00:37, 4 September 2014 (UTC)

yep, there has been no metadata curation, improvement. it's give me a deep links source or delete. i've fixed a couple, but it's ad hoc. it will require a team to curate, research image, and improve metadata in the proper template. this will require a culture change at commons. let a thousand teahouses bloom. it could be an IEG or idealab. Slowking4 (talk) 23:33, 4 September 2014 (UTC)

Orderinchaos, Keegan (WMF), Kogo01, Pete F, Slowking4: thank you all for the comments and suggestions. sorry for not reacting earlier. i am not regularly on Meta.

Erik Moeller: i agree, that the amount of errors might differ depending on what you are looking at. if you see 10 out of 10 random Commons images correct it is not very surprising, but i see defenitly more errors, mabye because the images i look at with MV are often still located on Wikipedias (where the information template is styled imperfect, used differently, or not used at all), or are on Commons in a "clean up" list or a maintenance category. I usually see these errors when i check various Wikipedia pages which i connect through or sort on Wikidata, or when i sort uncategorized Commons images and look for background infos for new categories (at the moment many old and new images of nature reserves/protected areas and cultural heritage monuments). usually i am able to fix such "missing or wrong infos" for MV on my own (by changing the positioning of infos in the information template, or by adding the template if missing). But sometimes i don't know what the problem is or how i could solve it. I have to admit, that i also often feel lost in the "magic template" area and usually leave it to more experienced users (if i find someone), or more often do nothing because reading/writing English is not this easy for me, and i can not handle every MV error i see (takes too much time, and for me it also feels like very frustrating work because of the huge unmanagable amount).

Maybe the following example could illustrate why proper "adaption for MV" is so unclear to me and many others:

1. please look – without MV – at c:File:Duisburg, Ruhrort, Amtsgerichtsstraße, Trinkhalle, 2014-09 CN-01.jpg, uploaded only yesterday – looks perfect and clear
2. then see https://de.wikipedia.org/wiki/Liste_der_Baudenkmäler_in_Duisburg-Homberg/Ruhrort/Baerl#mediaviewer/File:Duisburg,_Ruhrort,_Amtsgerichtsstraße,_Trinkhalle,_2014-09_CN-01.jpg and notice the missing extended license information (usually displayed at the bottom) and the missing required attribution part with the author's name "© Steffen Schmitz (Carschten) / Wikimedia Commons / CC-BY-SA-3.0 (DE), Free Art License"
3. then go back to the Commons file page and you probably find c:User:Carschten/Licence (permanent link, see also in edit modus) where the attribution/license part come from; it is used for more than 1000 images at the moment

Now can you please tell us – maybe directly on c:User talk:Carschten/Licence – what exactly (in detail) has to be changed there so that the MV displays all correct? – I think the problem is connected to missing microformats(?) and "includeonly", but don't know. But i know that really many relevant templates on Commons (not only user templates) make use of includeonly and alike, and that many especially very active Commons photographers use such individual templates (which are legitimate and do not show up as having any errors on Commons). Please also notice that you cannot only remove includeonly because then the subpage itself would be categorized wrong (because of autocategorizing templates, maybe this is an other restriction?).

This is only one example why i think it is really needed that you offer the communities "dedicated pages with a full in-detail list of MV preconditions for functioning information/license templates and with realizable solutions" (see "proposed solution" section above). Holger1959 (talk) 14:07, 10 September 2014 (UTC)

No obvious path to "flag" a file, nominate for deletion, make a complaint

• Problem: If a reader encounters a file that is objectionable (for instance: violation of one's own copyright, or a photo of oneself published without consent) there is no clear path to resolve the issue. Sites like Flickr have a button called "flag this file"; the traditional Commons file description page has two links, "contact us" and "nominate for deletion." With the Media Viewer, the reader must first find the "more details" button before finding those links.

Discussion (No obvious path to "flag" a file, nominate for deletion, make a complaint)

I think the much more clear and prominent more details link would take care of this issue. Keegan (WMF) (talk) 19:26, 4 September 2014 (UTC)

• I absolutely disagree that that is a solution, but neither your opinion nor mine is especially important. What is important is whether or not those whose rights are violated by a file manage to find an acceptable way to voice their objection. This is a testable question, and one that should be tested before the software (was/is) (made/kept) active by default. We should also consider whether or not the path we offer to such people reflects our collective desire to treat people in a way that is fair and humane. That one is not so easily testable, but it should be considered by a broader group than you and me. -Pete F (talk) 21:41, 4 September 2014 (UTC)

No way to see if a file has been nominated for deletion

• Problem: When looking at a file that has been nominated for deletion (or similar), there is no indication on the Media Viewer page. Those who might have a stake in the outcome miss an important opportunity to be notified.

Discussion (No way to see if a file has been nominated for deletion)

Same as above, a clear and easy path to find out more information helps solve this. Keegan (WMF) (talk) 19:27, 4 September 2014 (UTC)

I absolutely disagree that that is a solution, but neither your opinion nor mine is especially important. What is important is whether or not those who have a stake in knowing that a file is up for deletion manage to learn that it is. This is a testable question, and one that should be tested before the software (was/is) (made/kept) active by default. -Pete F (talk) 21:38, 4 September 2014 (UTC)

That is neither a solution, nor the beginning of a solution.

The problem is that the user does not know that the file is nominated for deletion or has some other issues. Therefore the is no rational for the user to view the details. A nomination for deletion becomes an unknown known: Unknown to the user, known by everyone else.

This problem is at the core of the issues with the media viewer. Do users expect to see a larger version of the image by clicking on it or do they expect to have more information on the image? When you gathered your requirements for this project did users( especially readers) complain or voice concern that clicking on an image did not enlarge the image but gave further, very detailed and poorly presented, information? Why are images within wikipedia treated in a different manner to wikilinks? If I click on a link in a wikipedia article I don't expect an dictionary entry in a black floating window but a wikipedia article. But since the Media Viewer itself is not up for discussion here is further reading on this subject.--Arcudaki (talk) 07:53, 5 September 2014 (UTC)

No indication of multiple language descriptions

• Problem: One of the great strengths of Commons is that it permits multiple languages to exist side by side, and permits users to easily switch from one language to another. The Media Viewer provides no indication that this capability exists. example; a more important use case would be where one language contains much more detail than others, but is invisible to the reader, unless they happen to click into the "more details" page.

Discussion (No indication of multiple language descriptions)

I think that the current prototype that is being developed solves this issue by removing the description entirely to just present the image as what it is, with a clear way to find more details e.g. the descriptions on the file page. This also would remove the appeared preference for English first. Thoughts? Keegan (WMF) (talk) 19:48, 3 September 2014 (UTC)

I absolutely disagree that that is a solution, but neither your opinion nor mine is especially important. What is important is whether there is a general belief in the editorial communities of the various projects that this is an acceptable way to present the relevant content. -Pete F (talk) 21:36, 4 September 2014 (UTC)

Non-free Commons files should not have a "view license" link

• Problem: Very few files on Commons are non-free, but of those that are, many are significant, and reflect strongly on Wikimedia and the Wikimedia Foundation: the various logos of Wikimedia and its projects. See here: commons:Category:Copyright by Wikimedia These files should not have a "view license" link in MV, since no general license (free or otherwise) is offered.

Discussion (Non-free Commons files should not have a "view license" link)

I'm not so sure, there are still licenses involved (which could make this reflect back to the issue with multiple licensing) and accessing it is important. For example, there are elements of this file that are free, only the Wikipedia globe is marked, so it's important to get to the licensing details, IMO. Using that file as an example, it has seven different license templates on the file page. Keegan (WMF) (talk) 19:40, 3 September 2014 (UTC)

This could be greatly simplified if WMF would simply CC0 license its logos (without giving up control of the trademark). There are countless examples of organizations whose logos are in the public domain (either because they were designed many decades ago, or because the logo doesn't exceed the threshold of originality) and have not had problems protecting their brand. I realize this is beyond the scope of this discussion, but it does seem like the simplest and best path forward for this issue (and many others). -Pete F (talk) 21:33, 4 September 2014 (UTC)

well, why would you want to take away the pseudo-NC fun? the foundation are not the only ones gaming licenses; also need to think about the hybrid licenses such as CC-BY-NC & GFDL 1.2 only. Slowking4 (talk) 00:09, 5 September 2014 (UTC)

Slowking4 I think you are talking about a different issue -- I don't think this has anything to do with gaming licenses, or choosing one license over another. -Pete F (talk) 18:55, 8 September 2014 (UTC)

Peteforsyth perhaps i'm conflating. i see lot's of institutions who want to control images using NC, trademark and TOU to restrict re-use. and i see some commercial photographers using GFDL 1.2 to restrict reuse. they both stem from control issues. i agree i would prefer CC0, but they'll eventually get there, after all the deputy legal counsel said at wikimania that the restrictions on scans was a failed model. Slowking4 (talk) 02:46, 9 September 2014 (UTC)

do not place mediaview screen in browsing history

• Problem: having mediaview screen in history is counterintuitive and undesired: i pressed the "X" on mediaviewer, and then hit "Back" on the borwser. i was not expecting to be taken to the mediaviewer screen - i was expecting to return to the page from which i opened the article. the problem is much worse if i view several images.

• Proposed solution:

do not assign different page addresses to mediaviewer screen, and do not add them to viewing history. this is somewhat schizophrenic: the whole point of MW is that you view the images "in-page", which also implies "without changing URL".

• Peace.

• Proposal of קיפודנחש (talk) 19:36, 3 September 2014 (UTC)

Discussion (do not place mediaview screen in browsing history)

Also, viewing the "original image" using the (MV button) makes my browsers forget where the embedding article was scrolled to. --77.177.113.47 09:42, 4 September 2014 (UTC)

There is a bug open for this with extensive discussion, it's here on bugzilla. It's pretty detailed in the technical reasons why the browser history behaves this way, and there are some proposed workarounds. Keegan (WMF) (talk) 19:43, 3 September 2014 (UTC)

I've commented on this issue further up on this page. --HHill (talk) 20:00, 3 September 2014 (UTC)

Minor issue in RTL languages

• Problem: Way to reproduce: 1- Go to w:fa:چکش‌آرواره#mediaviewer/پرونده:Omosudis_noaa.jpg 2- Click on more details button 3- See "در سایت‌های دیگر" section ("In other websites") 4- You see this:

Issue on MediaViewer in RTL wikis

...ikipedia.org
it should be something like this:
ceb.wikipedia...

• Proposed solution: Mark these lines LTR instead of RTL

• Proposal of Amir (talk) 14:33, 4 September 2014 (UTC)

Discussion (Minor issue in RTL languages)

Bug filed - 70434. Thanks! Keegan (WMF) (talk) 06:22, 5 September 2014 (UTC)

Update This patch should fix it. Keegan (WMF) (talk) 06:41, 5 September 2014 (UTC)

attribution as per authors requirement

• Problem: Attribution is as per the authors requirement

• Proposed solution: Fix attribution as per authors requirement

Discussion (attribution as per authors requirement)

If WMF wont follow the authors attribution requirements why should anyone continue to provide media to the projects, and how can it be expected for any reuser to comply when the source doesnt even give authors that respect Gnangarra (talk) 23:23, 28 August 2014 (UTC)

Gnangarra, speaking as someone who doesn't use any media from Commons if it has any out-of-the-ordinary author attribution expectations - I am always worried I'll mess up somehow or other, completely unintentionally - perhaps it might be an idea for Commons to consider whether its current practices of permitting a wide range of attribution expectations is a net positive, particularly for potential re-users. For those amongst us who are comfortable with the mass of templates that are often seen on Commons file pages, it's become normalized; but the more templates there are on those file pages, the less likely that anyone considering re-use will fully understand them and act accordingly. This might be a useful opportunity to do some simplification at Commons, too, as well as on other projects that host images. Risker (talk) 23:41, 28 August 2014 (UTC)

Risker attribution is part of the CC-by license conditions... it should not even be here as a request post roll out. Gnangarra (talk) 00:02, 29 August 2014 (UTC)

I think you're missing my point, Gnangarra. There are some pretty wacky attribution expectations created by uploaders, which Commons accepts without thinking twice, but which are highly confusing and almost impossible for re-users (often including the WMF projects themselves) to fulfill; in fact, Wikipedia projects generally don't fulfill some of the more common and straightforward expectations. Commons has, as a primary goal, the facilitation of re-use of the media it curates. I'm encouraging Commons to look at simplifying things. We don't allow images that the uploader licenses as CC-NC, why should we allow uploaders to impose complex attribution requirements? They have the same chilling effect on reuse. I'm not disagreeing that there should be an attribution line in MMV. I'm disagreeing that anything more than basic attribution should be required. No linking to personal websites (often commercial), no linking to personal biographical pages, or so on. Risker (talk) 00:16, 29 August 2014 (UTC)

So we shouldn't allow those who donate their time and work (at a cost to them)? Remember, the creator can state the way they want the attribution (which is stated within the legal code of the CC license). Bidgee (Talk) 02:37, 30 August 2014 (UTC)

at the moment it doesnt even say who the author is, it just gives a user name. every cc-by license has a field for the attribution requirement its a no bainer to place that field on the image, its even easier than extracting the information from two field in the info template. Its is also something at the WMF could have then proactive about using by running a bot to ensure all cc-by licenses had the field filled in. as it stands right now media viewer violates the Australian Copyright act licensing requirements, and therefore this needs an immediate fix. Gnangarra (talk) 00:28, 29 August 2014 (UTC)

@Gnangarra: This is an issue I've raised with the mobile version, I've yet to see the "fix" on a live project. Bidgee (Talk) 02:37, 30 August 2014 (UTC)

@Bidgee: You can see it on Commons, now (example), and it'll go to the remaining wikis on Thursday. I'd like to bring the attribution further in line with the desktop version, but it's a start.--Erik Moeller (WMF) (talk) 05:34, 3 September 2014 (UTC)

Ten days and still no fix, why should we believe in the WMF anymore. I've ceased uploading while this hasn't been addressed and looks like the whole Wikimedia movement will lose me due to WMF ignorance towards content contributors. Bidgee (Talk) 03:54, 2 September 2014 (UTC)

Hi Gnangarra, can you give some examples of files where you consider the attribution to be problematic? Media Viewer does show the author name right below the image, if specified (example).--Erik Moeller (WMF) (talk) 00:30, 29 August 2014 (UTC)

File:(Boletus_edulis).jpg. MediaViewer is still not respecting the attribution-template. The sad thing is that the german community raised that problem many times already. --DaB. (talk) 00:55, 29 August 2014 (UTC)

Thanks for the concrete example, Daniel. This isn't just due recalcitrance on our part. The problem right now is that the machine-readable licensetpl_attr output is very unpredictable -- sometimes it includes the license (set by the {{Credit line}} template), sometimes with a link to the deed, sometimes without (e.g. there are examples like this where the licensetpl_attr attribution links to the Wikipedia article for the GFDL, which is .. unhelpful). This violates the "Don't Repeat Yourself" pattern and is very error-prone.

We'll need to fix this together with the Commons community. I've posted a suggestion here: bugzilla:65445#c12. Once we've solved the issue with {{Credit line}}, this would be very easy to implement.

Pinging Gergo since he's very aware of these issues.--Erik Moeller (WMF) (talk) 01:12, 29 August 2014 (UTC)

• What are we speaking of here? The "embed in wiki page" code? That's trivial to fix once someone is ready to clutter that window with "please pick your project, I agreed on names of Template:Image source-like template across all projects so here it is" or ends up providing attribution in plain text. --Gryllida 04:22, 29 August 2014 (UTC)

<edit conflict>Erik Moeller (WMF) this https://en.wikipedia.org/wiki/Diplopeltis#mediaviewer/File:Diplopeltis_huegelii_gnangarra.JPG its doesnt say author or photographer it just has a name, on the file page the licensing has the attribution requirement included in the actual license tag, this function is available for every cc-by license entered as {{Cc-by-3.0-au|Photographs by Gnangarra...commons.wikimedia.org}} its this field that should be being extracted and displayed in media viewer. Gnangarra (talk) 04:33, 29 August 2014 (UTC)

Hi Gnangarra, yes, it doesn't currently say "Author", but it does show the author much more prominently (with no scrolling required) than the File: page. The new prototype has a little icon next to the name to indicate that it represents a person; we're currently user-testing whether that's clear enough.

The attribution text "Photographs by Gnangarra...commons.wikimedia.org" is actually problematic, because it can't be localized by the software - attribution really ideally should just specify the author. (Media Viewer also always adds the source, if specified.) With that said, if the above issue (bugzilla:65445#c12) is solvable, we could render this text in place of the current author/source information.--Erik Moeller (WMF) (talk) 05:36, 29 August 2014 (UTC)

Hi all. I agree; there are still problems. But the examples above are not very good.

File:(Boletus_edulis).jpg: It seems the author wishes to license it with GDFL and CC BY-SA. But "Attribution" is also a license and the use here as "credit line" is confusing. Both GDFL and CC BY-SA requires attribution and ShareAlike whereas "attribution" requires only credits. I think MV still failes to read multi license tags. If true, it need to be fixed.

I edited the author filed and now MV properly displaying the attribution as expected.

File:Diplopeltis_huegelii_gnangarra.JPG: Our basic field where people look for credits is "author" field. The new field like "credit line" is a mess; some people use it, many not. MV can be programmed to read it too. But I don't expect external sites like gbif.org, eol.org follow it. So IMHO, providing proper attribution on the author field is the best practice. (Earlier I used "creator" template and removed it only because gbif.org failed to read it.)

I edited the author filed and now MV properly displaying the attribution as expected.

I think https://en.wikipedia.org/wiki/St._Mary%27s_Basilica,_Bangalore#mediaviewer/File:Mass,_St_Mary%27s_Basilica_Bangalore.jpg is a good example how MV properly pick the attribution.

Hope commons:Commons:Structured data will solve many of these issues. Jee 06:11, 29 August 2014 (UTC)

sturctured data is a long way off and when it comes to clear attribution we shouldnt be told to wait for something to hopefully happen in the future.. We(Commons) are very strict on ensuring the right licensing, author and source details are there but that effort is being wasted by the way MV has been rolled out this should have been fixed for it went live, WMF wants free material then it needs to be beyond reproach on how it treats those content creators and their rights. Gnangarra (talk) 09:32, 29 August 2014 (UTC)

The gist from this is imho: There are millions of files, especially older ones, that our dumb bling-thing MV is incapable to read, while every decent human can. We programmed our pet program only to deal proper with new stuff, but we make it obligatory nevertheless. Shall those people, who delivered the content (that's the core of this here, content, not bling-bling), care about changing their contribution, so that our dumb piece of software can read them properly, we don't give a f*** about our contend providers.
No, it was from the beginning the duty of those, who wanted this piece of software to make a comprehensive initial take-up of all existing file and template syntax, and either take care that the software can work with all of them, or actively (that's leaving the ivory tower of SF and go to the swamps of editing yourself) engage in making all those files/templates readable for the restricted possibilities of the software.
For now: make it opt-in, for those who like bling, only use it on files that are completely understood by the MV, and do you basic work: make it understand all content. --Sänger S.G (talk) 08:48, 30 August 2014 (UTC)

well, high time to clean up metadata. how many have you done? they don't give a f*** just like the average commons admin dosen't give a f*** about content donators. it's delete rather than collaborate; it's delete rather than fix source; it's delete the recent contribution rather than curate the old legacy images in need of human intervention. the incivility spiral is not helped by your comments; they are counterproductive, since you undermine your credibility. Slowking4 (talk) 04:07, 5 September 2014 (UTC)

Three months later, this image still will not show the license's attribution line. If you click "Use this file", the attribution it provides is wrong, Wikimedia makes up its own attribution despite being explicitly told what to do.

• Move this up the priority chain - I requested this back in June. No movement since. licensetpl_attr support is in the 2014-15 Q3 cycle, 6 months away. This is ridiculous, photographers already hate the way that Wikipedia denies them on-page attribution, and now Media Viewer denies them off-page attribution as well. Creative Commons licenses include an attribution/credit line, if you use that content following the terms of the license, you must attribute the creator in the manner they have defined. Moller's suggests that "attribution should just specify the author" removes functionality that is built into the CC-license itself. - hahnchen (talk) 13:38, 6 September 2014 (UTC)

Violates Reader Expectations

• Problem: Readers have come to expect a certain User Experience when viewing a serious website such as a dictionary or encyclopedia. Readers have come to expect a simple clean presentation of information. Readers have come to expect an experience that strongly contrasts with entertainment websites. Entertainment websites feature bright colors, fancy JavaScript/CSS sliding panels, visual bling, and follow the latest trends and fads. Readers expect a lean tasteful professional style on serious websites, free from bright colors, free from fancy JavaScript/CSS sliding panels, free from visual bling, and free from the latest trends and fads. This serious style is well exemplified by the #1 website in the world, Google.com. The style and presentation of content can be almost as important as the content itself. Good style and presentation are integral to the editorial process in any media.

Importance: Can this suggestion significantly improve the experience for target users: readers and casual editors? Show Stopper. Many readers would find it jarring to encounter a lean black-and-white page on an entertainment site such as Facebook. Many readers find it equally jarring to encounter "bling" on an encyclopedia. The presence of bling on a serious website is both distracting and undermines the perception of the website as serious or reliable. It is unencyclopedic. It damages Wikipedia's brand.

Feasibility: Can this suggestion be practically implemented with available resources in the short term? (or does it require an extraordinary or long-term investment?) Highly feasible - both WMF and the Wikipedia community already have the javascript code on hand to set Media Viewer to default off.

Validation: Is this suggestion confirmed by research data or frequent requests from target users? (e.g. validated through user studies, surveys or talk pages) Highly validated both by research and expert consultation. WMF preformed a survey collecting user feedback. Independent analysis of the text-field responses revealed that the #1 response category was that the Media Viewer experience was worse than Wikipedia's baseline image view. The high frequency of words such as "awful" and "horrible" demonstrate how strongly many viewers reacted to the style clash. The number of outright hostile or even profane responses show just how strongly jarring the experience can be. The editors who produced Wikipedia are the preeminent experts in the world on reader expectations for an on-line encyclopedia. Community Governance on both English Wikipedia and German Wikipedia convened official consultations and both determined that Media Viewer should be default off.

Support: Is this suggestion supported by many community members? (e.g. editors on talk pages) This feature primarily targets readers, but we recognize that issues many contributors care about should be taken into account. Highly Supported. There are few issues in the history of the community that have drawn as much widespread attention. Not only is there vast support for this expressed by the community, the fact that English and German Community Governance have issued a position on the subject means those communities officially are 100% in support of it. Just as 100% of the WMF staff are officially in support of any policy that has been established by WMF's governance structure.

• Proposed solution:

Set Media Viewer to Default Off on (at minimum) English and German Wikipedias. Engage in OFFICIAL consultation with the community. This means engaging with the existing community governance structure. This means creating (or requesting the creation of) an RfC on issues where WMF desires a community position or community input. It means respecting the outcome of that community governance process the same way you would respect the single-voice authority of an elected president.

• Proposal of Alsee (talk) 10:33, 30 August 2014 (UTC)

Discussion (Violates Reader Expectations)

• This may be resolved by adding a new display mode such as one pictured in this thread (which also suggests adding such mode in addition to the builtin ones). --Gryllida 09:40, 31 August 2014 (UTC)

Does not violate this user's expectations

"...This serious style is well exemplified by the #1 website in the world, Google.com."

You're joking, right? The Google logo and Google doodles are iconic precisely because of their use of color and increasingly whimsical interactions. (They embed playable, score-keeping games onto the home page sometimes, for heaven's sake.) Even the Google "Sign in" button and stroke on the search box are blue. Absent any references to research documenting this preference for colorless information by "Readers", I would not take this "serious" concern very seriously at all.

I am delighted to explore the new media viewer and anxious to start using it. (It is way overdue.)

And by way of comparison, the sites for Britannica Encyclopedia, World Book Online, and the Oxford English Dictionary, just to name a couple of familiar and respected reference destinations, all make bold use of color. The OED site prominently features an interactive panel. ChristineBushMV (talk) 01:04, 1 September 2014 (UTC)

The Google logo is Trademark, a static piece of artwork on a pedestal in a barren sea of white. No extraneous Cool Web2.0 gizmos. Clean functional, it's where you go to find information. Alsee (talk) 05:52, 1 September 2014 (UTC)

You might wish to read about w:en:Google doodles. Whatamidoing (WMF) (talk) 17:25, 1 September 2014 (UTC)

ChristineBushMV, regarding " Absent any references to research documenting this preference", I did in fact include that. Look again. Alsee (talk) 18:41, 3 September 2014 (UTC)

Sorry, I just don't see any hyperlinks or URIs in this proposal. Apologies if they are there and my browser is failing to display them correctly. I would like to see the survey results and come to my own conclusions, though. Thanks. ChristineBushMV (talk) 20:05, 3 September 2014 (UTC)

Good idea,Whatamidoing (WMF). Specifically: Google_logo#Interactive_and_video_doodles. Also, if one looks at the source code for the Google home page one might be surprised. Firefox reveals 219 lines of code. The body tag shows up at line 211. That's 210 lines of script that enable (among other things) the "I'm Feeling Lucky" button to also be the "I'm Feeling Stellar," "I'm Feeling Wonderful," "I'm Feeling Doodley," and "I'm Feeling Artistic" button. And the little grid of squares in the upper right hand corner? That's one of those new-fangled interactive icons that discloses a whole bunch of other icons. Poke around a little more using an Element Inspector and you'll find the Google home page has about 288 CSS rules. ChristineBushMV (talk) 19:45, 3 September 2014 (UTC)

ChristineBushMV, My apologies. I didn't realize you were asking for the raw data. When I wrote the submission I was "talking to" WMF. I assumed they had their own data and could check it, so I merely made statements about the data. Here's the | Survey Data. Look in the section labeled "You What do you think of this new viewing experience? How could it be improved?". Alsee (talk) 00:06, 4 September 2014 (UTC)

Now, if one wants to make an argument about information design, Edward Tufte is a much better source. There is value in making reference material clear and easy to scan. This is precisely why the media viewer is a good idea: it aggregates multiple pieces of visual information and presents them in a single and/or separate space dedicated to this function rather than cluttering up whatever context in which it might be used.

There is another important distinction to be made here: Google is not "where you go to find information." Google is where you go to search for information sources. (WP, by contrast, is one place you can go to and find information.) This is more than semantics. Novelist Dan Brown puts it well: "Google is not a synonym for research." He is correct, quite literally: "search" is not "research." Google self-references as a "search appliance" and among the many things it returns are links to i)advertisers, ii)other Google apps, iii)the Google-ranked web, and iv)more meta-sources, like Google Books, Google Scholar, and Google News. Browsing all this stuff is certainly diverting, but it isn't research. These search results do not a Bibliography, Citations or References page make. That's why there is ~2,700+ article queue waiting for review: most of them are hodgepodge aggregations of unverified search results to be rejected instead of research results to be created. This is not the source you want for an article on Jules Verne. This is. ChristineBushMV (talk) 19:45, 3 September 2014 (UTC)

+1 you make a fundamental point, the humans need to curate the information, not fight among themselves about the touch and feel of the information presentation software. the AfC backlog is proof of the incompetent process design by the community. if we waited on the community to "improve" the design, it would never arrive: they would fight to the death over the right to maintain the "AOL message board". it's one thing to give constructive feedback to fix the cruft; it's another to have perpetual temper tantrums, and keep trying to take the ball, and go home. i am perpetually waiting for the community to grow up. Slowking4 (talk) 04:18, 5 September 2014 (UTC)

I would like to note that there was no fight until the WMF started one. We had a no-problem RfC, the community reached an easy and solid consensus that Wikipedia was BETTER with Media Viewer defaulted off. The community would have openly welcomed the WMF's participation, and many of us did note the MWF's data and reasoning on the issue. Many reasons were given for deciding it was better for Media Viewer to default off. The WMF decided to ignore those reasons, the WMF decided it had no interest in participating as a member of the Wiki community, the WMF had no interest in participating in consensus-seeking, the WMF deployed Superprotect try to win a reasonable-disagreement by force. The WMF changed it from a disagreement into conflict-by force. The community is having a "temper tantrum" because the WMF forgot (or doesn't understand) that we're all supposed to be collaborating. Trying to impose force to win a disagreement is extremely destructive to collaboration. Over at Wikipedia we manage to get opposing sides to work together well enough to collaborate on articles on politics, abortion, evolution, gay marriage, even war in the Mid East, and you're saying we need to grow up? We want to collaborate. We want the WMF be part of the Wiki community. Alsee (talk) 09:23, 6 September 2014 (UTC)

Return control over how images are displayed to editor

• Problem:
  

No reader with a stable mindset will click on the first image of this page with the intention of viewing it in the media viewer. The intention of a sane user will be to obtain more information on the image rather than viewing the image in a larger version surronded by loads of shiny black space with no meaning other than being the darkening shadows of things to come.

• Proposed solution:

Provide a option in the [[File:An example|thumbnail|default|an example]] tag to disable the media viewer for this file. Editors can then decide for which images on a page the media viewer is applicable and for which images the media viewer is just a showcase for a badly designed and implemented UI.

• Proposal of Arcudaki (talk) 11:40, 3 September 2014 (UTC)

Discussion (Return control over how images are displayed to editor)

Interesting point. Icons and such can be tagged so that Media Viewer skips them, I'm not sure if this capability extends to actual images. I'm not sure why not. Keegan (WMF) (talk) 19:15, 4 September 2014 (UTC)

Excellent idea. I'd also suggest a similar ability for people uploading images to Commons, so uploaders concerned about the way Media Viewer hides some licensing information could disable its use for a particular image across Wikimedia projects. Of course, there should be a convention that the preference of the original uploader should be respected. 86.179.194.211 16:29, 5 September 2014 (UTC)

Many of the best-described images on Commons appear messed up

• Problem: One of the strengths of Commons is the possibility of creating rich and meaningful descriptions for files. In many cases where that has been most effectively, the Media Viewer is incapable of rendering the detailed descriptions. If it's outside the "Description" field it is ignored entirely, with nothing beyond the (apparently invisible) "more details" button to guide the reader towards it. In other cases, templates (including the highly used Legend template) are rendered incorrectly. See the following examples:
• File:Columbiawdams.png
• File:Secession Map of the United States, 1861.png
• File:Circus macrourus dis.PNG

Discussion (Many of the best-described images on Commons appear messed up)

The new prototype removes the description field altogether, eliminating the problem and pointing people more clearly to the file page where they can find all the description information. Keegan (WMF) (talk) 20:26, 3 September 2014 (UTC)

I absolutely disagree that that is a solution, but neither your opinion nor mine is especially important. What is important is whether there is a general belief in the editorial communities of the various projects that this is an acceptable way to present the relevant content. -Pete F (talk) 21:36, 4 September 2014 (UTC)

The new iteration would show the caption right below the image, which I (Wikipedian hat on as well) think provides much better context than file descriptions below the fold, since the description is often out of context of how the image is being presented as opposed to the caption. I can see how this isn't sensible for Commons, but I think it's a better presentation for a Wikipedia at least. I'm not sure in the context of other projects. But as you say, let others decide on the merits of the new Viewer :) Keegan (WMF) (talk) 21:20, 5 September 2014 (UTC)

Click on the picture...

• Problem: clicking on the picture --> nothing happens

• Proposed solution: Beim Klicken auf das Bild im MV, muss etwas passieren, vorzugsweise eine (+)-Lupe, die das Bild vergrößert, damit ich mir Details anschauen kann (wichtig vor allem auch an kleinen Bildschirmen).
• Optional solution1: oder dass Reinzoomen (und Rauszoomen) wird durch Scrollen ermöglicht, dann wäre folgende optionale Lösung eine wertvolle Ergänzung.
• Optional solution2: Beim Klick auf das Bild Weiterleiten auf die File-Beschreibungsseite, die mehr Infos zum Bild selbst enthält und von der ich das Bild auch vergrößern kann. (ergänzend zum Commons-Symbol, nicht stattdessen)

• Proposal of Anika (talk) 05:54, 4 September 2014 (UTC)

Discussion (YourTitle)

The current plan for Media Viewer development will have the image expand when you click on it. This should solve this. Keegan (WMF) (talk) 21:27, 4 September 2014 (UTC)

How about the image starts out expanded (since that's why people click on images anyway - to make them larger), and clicking on the image takes you to the non-MV standard presentation? 0x0077BE (talk) 00:03, 7 September 2014 (UTC)

Why are items without a solution moved out of sight by this over-eager bot?

• Problem:

The bot removes everything out of sight to the archive after two days of inertia in the topic, even if it's not remotely solved. That's very bad behaviour.

• Proposed solution:

Either set the time frame to something better, like 10 days, or move only solved problems.

• Proposal of ♫ Sänger, superputsch must go (talk) 08:45, 4 September 2014 (UTC)

Discussion (Over-eager bots)

There will be probably some goobledygook that an archive is not really an archive, and that it's only because the page gets too long, but that's just bull***. It's taken from sight on the front page, so it's away, and that's imho the major reason for this. This discussion is anyway just a distraction from the real issues about the dealing with communities who dare to dissent with the beloved leaders in the Politbüro. This moving of unsolved topics in dark back rooms ist just one more proof. --♫ Sänger, superputsch must go (talk) 08:45, 4 September 2014 (UTC)

No, the bot sends things to a regular archive. The basic problem is page size. When the page gets too long (100K and 200K are commonly given as the upper limits, and archiving on this page started when it was up at 200K), people with limited internet access or mobile devices cannot participate. If and when the page stays under 100K for a day or two, then we can think about slowing down archiving accordingly.

IMO the preferable alternative would be to split it sensibly according to topic (two active pages = twice as much in active discussion without either page being too large), but you and several other people opposed that. If you've changed your mind, then feel free to split the page again, and if that brings us under the 100K target, then we can slow down the archiving speed now.

On your other concern, "resolved" and "had a message posted about its resolution on wiki" are separate concepts. The PM is tracking discussions in a spreadsheet offwiki so that nothing gets lost, no matter when it gets archived or moved to another page. Whatamidoing (WMF) (talk) 23:03, 4 September 2014 (UTC)

And Sänger, on this page or any other page where we Community Liaisons are working, do keep in mind that we are deeply entrenched community members. I celebrated my 8th anniversary as an English Wikipedia admin a few days ago and next month is my account's ninth birthday :) We do not hide and we do not promote or endorse censorship. If anything at all, when talking to community liaisons, just forget about the (WMF) after our usernames. We don't become different people because of that. Keegan (WMF) (talk) 07:21, 5 September 2014 (UTC)

OK, you as a person seem to be quite OK, but you as an enforcer of this deletion spree by the bot into shady back rooms (and no, that's not just archiving, that's removing out of sight). It may not be your intent to be rude, but this archiving is rude. Look here for another user being miffed by this rude behavior of xxx (WMF)ers. Please take this in context of pure contempt by the WMF delivered to the deWP by Erik with his super-putsch. Every action by someone from the WMF can only be seen in the context of such actions against the community. As long as the WMF doesn't show respect to the communities and makes this flimsy gadget we're talking about here opt-in in enWP and deWP, they (and implicitly you) are still hostile without remorse. --♫ Sänger - Talk - superputsch must go 15:50, 5 September 2014 (UTC)

I just corrected the titles of those pages, as if they are just created to make the page shorter, and not really archives, the discussion there cannot be restricted. If the topics there should not be discussed any further over there, then my initial assumption of being a dark back room for hiding them seems to be correct. It's impossible to be both: just some still active swap file because of loading restrictions for single pages, or not to edit. --♫ Sänger - Talk - superputsch must go 16:59, 5 September 2014 (UTC)

Thank you for doing that. Please note that if conversation stalls on those pages over the weekend, from my end at least, it is because I am traveling. Everyone is free to discuss away. Again, I appreciate it. Keegan (WMF) (talk) 21:11, 5 September 2014 (UTC)

Then: Why is this over-eager bot hacked in here with just 2 days, your average weekend, and not something suitable, like a week? Why has everything hushed out of plain sight so quickly? It may be officially still for discussion, but I think you will agree, that it's comparatively hidden from here, and in every case from the main page. --♫ Sänger - Talk - superputsch must go 21:16, 5 September 2014 (UTC)

Well I certainly hope it wasn't just going to be you, Pete F. and me chatting over the weekend on here. I like you guys just fine but I hope there's further input from fresh faces that others can think about over the last couple of days. I, myself, will be traveling for the most part but I don't think we're shutting the page down over it :) Keegan (WMF) (talk) 22:35, 5 September 2014 (UTC)

Show author and licence in Media Viewer

• Problem: The new Prototype of the Media Viewer shows neither author nor license. [1]

• Proposed solution:

Show author and license of images.

• Proposal of 193.254.155.48 11:47, 4 September 2014 (UTC)

Discussion (Show author and licence in MV)

Hmm, I am seeing the information and I can't reproduce the bug. I'll keep checking to see if it pops up again. Keegan (WMF) (talk) 21:29, 4 September 2014 (UTC)

The problem might be related to the length of the description / authors'name if either is longer than the line they are displayed in the text is not wrapped but an elipsis (...) is displayed. Clicking on it reveals the mandatory information. This is not compliant to the license however.--192.166.53.202 08:33, 5 September 2014 (UTC)

Flawed prototype introduction practice

• Problem: I fear the reception of this (really cool) prototype has been unnecessarily rocky because of a simple misstep in how it was rolled out. There should have been two versions of the Rapa Nui page presented: one showing how the media viewer button (as included on this "Community Engagement (Product)/Media Viewer consultation" page) would appear in situ with the Rapa Nui content; and then the traditional version of the Rapa Nui page with the various assets placed throughout the page. By not providing the first version, the new feature was not given a chance to be seen in context and appreciated for one of its most important properties: streamlining information presentation. I think this has confused many people.

• Proposed solution: Instead of putting the button which launches the prototype on this page, provide links to two different versions of the Rapa Nui page. Then this page could have shown (should show) side-by-side screen shots of the Rapa Nui page, instead of launching the media viewer itself. This would allow people go to the two different pages and experience how the media viewer affects content flow. Regrettably, it seems too late for this now.

• Proposal of ChristineBushMV (talk) 19:20, 4 September 2014 (UTC)

Discussion (Flawed prototype introduction practice)

Yeah, this consultation happened quickly and it is short. Would anyone with better page design talents like to add this? Keegan (WMF) (talk) 07:13, 5 September 2014 (UTC)

I would be glad to do so, but: it hardly seems worth the effort for 1-2 days of exposure. Would others appreciate seeing something as described? Reply here. If there is sufficient interest, I'll implement something for use starting tomorrow, 2014/09/06. ChristineBushMV (talk) 19:45, 5 September 2014 (UTC)

Suggestion: Easier suggestions

In an irony of recursion, one of my suggestions is to improve the interface for making suggestions. I typed my suggestion into the teeny little box, then clicked the "Make a new suggestion" button. This threw me into a window with some pre-formatted wikicode, containing nothing of the suggestion that I had just typed in. Very frustrating!

Anyway, the reason I came back to WP after a year or so break was to fix incorrect copyright info on some images from our website. But when I click an image it just makes an enlarged view of the image instead of taking me to the page that lists permissions and so forth, not like it was a year or so ago. I assume this is the "Media Viewer" that you are talking about. It took forever to figure out how to find the permissions statement so I could fix it. And this from someone who has been on WP since 2006, and thus knew the info had to be there somewhere. How many others trying to do the same but less experienced in the ways of WP simply gave up? I haven't kept up with the inside baseball on this so maybe you're already considering a fix, but anything that makes it harder for WP to comply with the law regarding images seems like a bad idea. Short Brigade Harvester Boris (talk) 23:51, 4 September 2014 (UTC)

Hello Short Brigade Harvester Boris, I agree that the present state of Media Viewer is pretty cluttered and confusing, particularly the disable being down at the bottom of the panel that you have to find out can be pulled up. There is a new prototype that is being tested out that eliminates most of that clutter and makes Media Viewer much more usable, IMO. Thoughts are welcome. Keegan (WMF) (talk) 19:13, 5 September 2014 (UTC)

My concern wasn't about visible clutter, but instead about finding (and correcting) info on permissions. Anyway the big blue "More details" button is a definite improvement. Thanks. Short Brigade Harvester Boris (talk) 01:34, 6 September 2014 (UTC)

Here is what you wanted

• Importance: Can this extension to the software significantly improve the experience for target users: readers and casual editors?

My opinion: No, it can't.

• Feasibility: Can this extension to the software be practically implemented with available resources in the short term? (or does it require an extraordinary or long-term investment?)

In my opinion it has already required too much of resources.

• Validation: Is this extension to the software confirmed by research data or frequent requests from target users? (e.g. validated through user studies, surveys or talk pages)

I don't think so, while it may be that some users have already set up evaluations.

• Support: Is this extension to the software supported by many community members? (e.g. editors on talk pages) This feature primarily targets readers, but we recognize that issues many contributors care about should be taken into account.

Yes, it is widely discussed. Opinion is as of yet twicefold: some like it, some do not. So this is not really a criteria.

Quote: Members of the Wikimedia Foundation’s Multimedia and Community Engagement (Product) teams will be commenting on the discussion page (recognizable by the “(WMF)” in their usernames). Ultimately, decisions on which improvements to prioritize will be made by the multimedia team, based on the above criteria. While there is no perfect formula for determining which features to build first, we will carefully consider the trade-offs between impact and cost, as well as aim to validate each decision based on user data or feedback.

Better consider what serves Wikipedia best than to consider cost or things. All (or most) of us are working voluntarily. so it doesn't cost a single cent to improve our tools, but it will cost sums of stakeholders if you see us as subjects and not as owners of this project, which we in fact are, giving our donations to the Foundation. Most sincerely yours, Altkatholik62 (talk) 00:58, 5 September 2014 (UTC)

Valid thoughts and opinions, thank you for sharing them. Keegan (WMF) (talk) 19:09, 5 September 2014 (UTC)

icons gone, ...

1. After increasing the picture the icons on the right and left side are gone and they don´t come back after decreasing. And it is not possible to decrease the first picture (Easter_Island_map-en.svg) at all.
2. The button "more details" says: "View and edit details about this file". Could you change that to "View and edit this file in Wikimedia Commons"
3. If I´m not logged in, what is the icon "preferences" for?

--Goldzahn (talk) 06:07, 5 September 2014 (UTC)

Hello Goldzahn. Let's see what we have here...

1. I believe this is a known bug, but would you mind sharing your browser/operating system combination so I can be sure?
2. Others have suggested including an indication things can be edited on the file page as well. I'll add this as another support for that :)
3. Logged-out users can still disable Media Viewer using the preferences icon in Media Viewer because logged-out users do not have a way to access preferences in general. It's not an elegant solution, but it's the most practical way at the moment.

Let me know about 1 and I'll see if I can dig up the bug I'm thinking of. Keegan (WMF) (talk) 19:07, 5 September 2014 (UTC)

My System is Windows 7 Service Pack 1, Firefox 32 --Goldzahn (talk) 10:46, 6 September 2014 (UTC)

Thank you, Goldzahn. There's a bug that causes similar behavior using Firefox on Mac OS, I'm pretty sure it's a Firefox specific bug. If not the same, I'll file a new one. Keegan (WMF) (talk) 06:35, 8 September 2014 (UTC)

HTML 4 page viewer should be there

• Problem:

• Proposed solution:

• Proposal of Ashesh.bhusal (talk) 12:29, 5 September 2014 (UTC)

Discussion is about the browser.

As we all know that we all do not use computer to use internet.
Especially in nepal we all do not use computer .
so wikipedia should make that types of files which can be easily play by simple browser also.

Thanks, it is always important to keep in mind that nearly 40% of views now come from mobile devices. The Mobile team developed its image viewer separate from Media Viewer, I'll pass this along. Keegan (WMF) (talk) 19:15, 5 September 2014 (UTC)

Thanks for the constructive engagement

I would like to thank the Community Engagement team and the Product and Engineering departments for their thoughtful consideration of my suggested improvements. The clear assessments of the identified problems and suggested improvements, and the informative explanations of how and whether these align with the Foundation's plans and objectives, are a shining example demonstrating that this is how community engagement is supposed to work.

Thanks for nothing. ~ Ningauble (talk) 15:14, 5 September 2014 (UTC)

@Ningauble: I'll take responsibility for missing your feedback since it looks like I answered most of the discussions around it. I remember reading it and composing some replies in my head at least but no matter, what's done is done and I'm sorry about that.

As for your feedback itself: I understand that Media Viewer isn't working for you since you cannot edit through the interface or set up slideshows. However, Media Viewer is not meant to do either one of those things. The File page is still the point of contact for curating images. Media Viewer is for a quick look at in image in context of what you may be reading. Its functionality is not supposed to mirror that of an image-hosting site like Flickr or Photobucket.

If the community of the English Wikiquote collectively feel that Media Viewer's function as a simple way to view an image is appropriate for Wikiquote, you can file a bugzilla request to disable Media Viewer. Do note that it's a request, and I cannot make any guarantees over the outcome of the request. I have no power over that at all. As a reminder, you can turn off Media Viewer in your local preferences or you can turn it off on all wikis in your global.js here on Meta by adding mw.config.set("wgMediaViewerOnClick", false);

Again, I'm sorry for missing replying to your comments. Keegan (WMF) (talk) 19:02, 5 September 2014 (UTC)

Link-clic to The Commons

• Problem: It is gotten varry more compliquated to go how to the Commons page of les images, really this is completement difficulte & invisible now! :((

• Proposed solution: 1. must comes the link to the Commons were all the informations ares.

• Proposal of 92.229.95.23 19:21, 5 September 2014 (UTC)

Discussion (YourTitle)

Does the clear "More Details" in the prototype help you? Keegan (WMF) (talk) 21:09, 5 September 2014 (UTC)

Image rights and deleted images

• Problem: my images were deleted from the site due to copyright within few minutes.. those are my own creations and logos which I created, and I have all rights on them. I saw many organizations has introduced there own copyright protected logos and images has posted in Wikimedia.

disappointed

• Proposed solution:

Replace them and let me know

• Proposal of Scriptfolder (talk) 20:54, 5 September 2014 (UTC)

Discussion (Image rights and deleted images)

Hi Scriptfolder, this is not the place for you to request a review of deletion. This page is discussing software that displays images. I can point you where to go, however. Were your images deleted from the English Wikipedia, Wikimedia Commons, or where? Keegan (WMF) (talk) 21:08, 5 September 2014 (UTC)

The MV only displays existing images. It will never be able to show deleted images therefore. Normally, images which are not licesed correctly, are tagged for deletion for 7 days, and the the uploader notified. There can be problems with IP users with dynamic IP however, because the notification is not shown to the uploader as soon as a new IP is used. If you know the file names, you can unlock them by delivering the needed license information via en:WP:OTRS or the adequate page at the project where you uploaded the files at any later time too. Andy king50 (talk) 13:33, 6 September 2014 (UTC)

Make a Preferences option to disable MV globally

• Problem: MV must be disabled on every project separately (or maybe a hack can be used?)

• Proposed solution:

Make an Option in Preferences/Appearance to disable MV everywhere, or create a generic mechanism to make (some) preferences global.

• Proposal of S8w4 (talk) 21:55, 5 September 2014 (UTC)

Discussion (Make a Preferences option to disable MV globally)

@S8w4: global preferences are not yet available (but we're working on SUL finalisation so that it can be). You can disable Media Viewer globally, though! Visit this page, your global.js, and place this in the page and save: mw.config.set("wgMediaViewerOnClick", false);. Refresh your browser, and Media Viewer will not show up anywhere you go. If you want to randomly use Media Viewer, you can click the "Expand view" icon on any file page. Hope this helps. Keegan (WMF) (talk) 22:40, 5 September 2014 (UTC)

Could Have- Integrate Commons Material into the viewer

A "see more" button which then feeds images into the viewer from Commons which are the result of a search on Commons for the article title . Often an article only displays a small portion of the images related to a subject that we hold. This feature would enable better use of the material we hold on Commons and give it a higher profile to the general user.Lumos3 (talk) 22:19, 5 September 2014 (UTC)

Discussion (Could Have- Integrate Commons Material into the viewer)

I believe that a "See similar images" button is a new idea. Thanks for sharing it, Lumos3.

How would you find similar images? Perhaps based on the categories, or searching for similar file names? Whatamidoing (WMF) (talk) 00:13, 7 September 2014 (UTC)

Usability with audio and video

• Problem: AFAICT this extension only views images, not videos, audio or PDFs.

• Proposed solution: I'd like to see the ability to play video and audio in MediaViewer.
• Proposal of RockerballAustralia (talk) 01:56, 6 September 2014 (UTC)

Discussion (Usability with audio and video)

Thanks for posting this note, Rockerball. I believe that this is already being considered. Whatamidoing (WMF) (talk) 00:14, 7 September 2014 (UTC)

Visibility of file storage location (locally or commons)

• Problem: It is not visible, if the file is stored at Commons or locally. If one looks for files available globally for other projects, one need to call the description page separately. This does not encourage the reuse in other language versions or exports to commons.

• Proposed solution: Somehow flag the MV pages to show if the content is stored locally eg. at de: Wikipedia or globally (eg. show some small globe icon or not)
• Proposal of Andy king50 (talk) 13:25, 6 September 2014 (UTC)

Discussion (Visibility of file storage location (locally or commons))

This is currently done, but in a subtle way. If you look at the first couple of images in w:en:List of top-selling candy brands, then you should be able to see the difference. The first (a pile of M&Ms) opens in MediaViewer with a small Commons logo in the lower right corner. The second (an orange candy bar wrapper) opens with a small "W" (for Wikipedia) logo in the lower right corner. The first is a free file at Commons, and the second is a fair-use-only file at the English Wikipedia. Whatamidoing (WMF) (talk) 00:17, 7 September 2014 (UTC)

Make re-use of MV easier if deactivated

• Problem: Existing "workarounds" to disable MV are based on individual java scripts. This does not encourage to return to MV now or at a later time. Some time, the MV is (hopefully) improved so it will be acceptet by the majority. But, if I once disabled it via java script it will be not easy to find the script to reactivate it. I cannot delete de page anyway a non admin. This makes it difficult to check the MV for changes/improvements, discourages participation in improvement process therefore.

There might be a tendency, that users who switched it off, never will switch it on again and this might perpetuate the parallel existence of two viewers.

• Proposed solution: Create easy possibility for switching between viewer modes (e.g. button at description page, entry in user preferences)
• Proposal of Andy king50 (talk) 13:47, 6 September 2014 (UTC)

Discussion (Make re-use of MV easier if deactivated)

You don't need to delete a user script to disable it; just blank it (or the relevant portion of it).

It has always been possible to opt-out of MediaViewer via a single click in Special:Preferences. (This, by the way, is partly thanks to Keegan's insistence that personal opt-outs must be simple, easy, and available to anyone who wants them for any reason at all.) Go to Special:Preferences#mw-prefsection-rendering, scroll halfway down to the "Files" subsection (it's the same section for changing the default size of images on pages), and tick the box "Enable Media Viewer" to turn it on, or un-tick the box to turn it off. The save your changes. You can change your preferences as often as you want.

There is additionally a button within MediaViewer for turning it off; it has exactly the same effect. The only reason someone might need a script to turn off MediaViewer is to change other people's access to MediaViewer without their individual consent. Whatamidoing (WMF) (talk) 00:26, 7 September 2014 (UTC)

My understanding is that a script is currently the only way to opt out of mediaviewer across all wikis rather than doing it individually. I've been thinking about using a script myself whenever I end up on a wikimedia site where I haven't opted out yet.

Also, your little dig about the implementation of MV disabling through a global script is somewhat unfair, since no other option was given to implement the near-unanimous consensus on English and German Wikipedias for disabling MV by default. It's somewhat rich to be bringing up the issue of consent in this matter, given the WMF's actions to date. 0x0077BE (talk) 00:46, 7 September 2014 (UTC)

Collapsible bottom bar

• Problem:

With today's 16:9 standard aspect ratio, the bottom description bar eats up quite a lot of vertical space.

• Proposed solution:

Make the bottom bar collapsible.

• Proposal of Benstown (talk) 02:11, 7 September 2014 (UTC)

Discussion (Collapsible bottom bar)

Hi Benstown, this is an early prototype of how the Multimedia team is looking at iterating the bottom bar. Does this look like it would solve this issue? -Rdicerb (WMF) (talk) 20:30, 7 September 2014 (UTC)

No it doesn't solve it. (BTW, it's not really an issue, but a suggested improvement). Here is an example of what i'm referring to. They display the description as a collapsible, semi-transparent overlay. --Benstown (talk) 05:16, 8 September 2014 (UTC)

May I translate the main page in Traditional Chinese?

I want to translate the main page into Traditional Chinese. The system says "Translate in zh please.", but it has already been done. The Chinese version is written in Simplified Chinese, users in Taiwan would be troubled to read and understand it.--Reke (talk) 02:41, 7 September 2014 (UTC)

Yes. Questions like this do not even need to be asked. Additional translations are always welcome. Apteva (talk) 19:23, 7 September 2014 (UTC)

The issue is that the system doesn't allow Reke to proceed, AFAICS. I'll try to find out what happened there and will let you know. Thanks, --Elitre (WMF) (talk) 20:05, 7 September 2014 (UTC)

We don't translate MediaWiki or Wikimedia projects' pages in zh variants normally handled automatically by the language converter. Yes, it's a deficiency of the system that the language converter doesn't work on multilingual wikis like this as it does on zh.wiki. See bugzilla:37338 where Liangent explained it. --Nemo 21:00, 7 September 2014 (UTC) P.s.: I think all sections which were not reporting specific bugs or enhancement requests are being removed from this pages and moved to a related one; remember to check the history if this disappears.

21:00, 7 September 2014 (UTC)

Consultation over?

The project page says that today is the last day of this consultation. Perhaps the WMF should reflect on how they are doing on "regular updates" to the list (I have adjusted that phrase to ensure that user expectations are not raised beyond the reality)? As a few others have mentioned, it is quite discouraging to have unopposed threads about trivially simple technical improvements getting archived without comment from the WMF even a week after using a holiday weekend excuse. Please do what you committed to do before you close this consultation. An off-wiki spreadsheet assurance does not count as a sufficient reply/consultation for those who have engaged on your terms in good faith. It's not about "nothing getting lost", it's about... (see the title of this page) ... "Community Engagement".--99of9 (talk) 03:56, 7 September 2014 (UTC)

Ensure people can read what they copying onto their clipboard

• Problem: Plain and HTML author attribution text cannot be read in full before copying and pasting somewhere else.

• Proposed solution: When we click on the text of the author attribution, the software should allow scrolling right and left via the arrow keys.

• Proposal of 99of9 (talk) 04:04, 7 September 2014 (UTC)

Discussion (Ensure people can read what they copying onto their clipboard )

Hi, thank you for your proposal. I am not sure if the Share option I see in the prototype will work differently in this regard from the current version, so I took note of your request anyway. Best, --Elitre (WMF) (talk) 20:17, 7 September 2014 (UTC)

The arrow

• Problem: Minor problem: IMO the arrow for the "context box" is the wrong way around. Its specialy irritating when you want to hide the box.

While the box is "hidden" the arrow shows "down". but actually I would like to get the box "up" not down. but okay the idea of getting "down" to the content so one could state that it is okay

But when the box is shown and you want to hide it again the arrow is at the bottom of the page but shows "up". So what? For me it clearly show that I can get more iformations while pressing it but not that I can get the box "down". ... That the image is popping "up" cant be as the arrow is clearly on the box not the image and the image is, as one can still see it partly.

I checked with lightroom - they have it the other way around.

• Proposed solution:

1. Turn both arrows around
2. IMO the arrow should be on top of the white box (but checked with lightroom; they don't have it. So maybe check with other programs or make same tests with readers where they look for it)

• Proposal of ...217.255.21.13 20:03, 7 September 2014 (UTC)

Discussion (The arrow)

Hi, I can't see the arrow anymore in the prototype version. You might want to comment that instead? Thank you, --Elitre (WMF) (talk) 20:21, 7 September 2014 (UTC)

Breaks previous/next page naviagtion

After going through the images on a page each image counts as a visited page for the browser. I would expect to be able to close the media-viewer and use the back and forward buttons on my broweser asa if I hadn't opened it. RF 21:19 7 September 2014 (UTC)

Breaks browser

Displays a black screen as if the browser has crashed. RF 21:19 7 September 2014 (UTC)

RF, are you using IE8? Quoting Erik Moeller (WMF), The relevant bug is bugzilla:70553 and the fix will be deployed tomorrow - which would be today, since this message was posted yesterday on en.wiki. Best, --Elitre (WMF) (talk) 11:00, 19 September 2014 (UTC)

Script is too slow

This script http://multimedia-alpha.wmflabs.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140806T104811Z:12 is too slow and the browser complains. RF 21:19 7 September 2014 (UTC)

Progressive loading is poor

We get a nice big screen full of fuzz. Then about 20 seconds later the proper image. 21:19 7 September 2014 (UTC)

Example page copyvio

The example page breaks copyright. Several of the images are not attributed in the MV, breaking a clause 4 of CCBYSA 3.0, for example http://multimedia-alpha.wmflabs.org/wiki/Rapa_Nui_National_Park#mediaviewer/File:Ahu_Tahai.jpg .

The mediaviewer is distributing or publishing a collection of images, there for under section 4 Clause c

The credit required by this Section 4(c) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors.

The Wikipedia communities take copyright very seriously. I beleive the Foundation should do likewise.

Rich Farmbrough 21:19 7 September 2014 (GMT).

Thank you for participating

Thanks a lot for your ideas and suggestions. The consultation is now over; see notice at the top of this page. Keep watching these spaces for updates about the proposals and the next steps. Again, thank you for your time. --Elitre (WMF) (talk) 07:46, 8 September 2014 (UTC)

Was just a bit biased of a consultation, wasn't it? It would appear that much of the feedback that you received was encouraging you to either switch it off or return it to opt-in status, but the feedback that you listened to was feedback that said you had produced a useful tool that only required some tweaking. Kww (talk) 05:06, 11 September 2014 (UTC)

But wasn't that waht this whole was about: pretend interest in feedback, divert disussion from basics to superficial tidbits and choke real dissent. Ímho there never was any real interest in the community by WMF from the beginning, this was all just for distraction. --♫ Sänger - Talk - superputsch must go 10:49, 11 September 2014 (UTC)

As the most common suggestion as well as the conclusion of three RfCs on as many wikis, returning Media Viewer to opt-in must be on the "Must have" list. This has gone far beyond ridiculous. Why won't the WMF listen to the "users" that Lila says they work for? This whole process was a sham. --98.207.91.246 14:54, 11 September 2014 (UTC)

And what a waste of time it has been.--Arcudaki (talk) 07:33, 12 September 2014 (UTC)