Talk:Community Liaisons/Media Viewer consultation

• Procedural comments and general discussion of Media Viewer
• Other discussion about Media Viewer

Submit your suggestion for product improvements!

Archives

---

• Archive 2014-08

MV software should be permitted to return to "opt-in" on those projects where that has been clearly called for

• Media Viewer remains enabled by default on German Wikipedia, Wikimedia Commons, and English Wikipedia, in spite of local decisions to have it disabled by default.
• The Media Viewer software should be permitted to return to "opt-in" on those projects where it has been clearly called for, and not returned to "opt-out" until those communities agree that it is a sufficient improvement over the software that has worked for this top-5 web property for over a decade. 700+ people support this notion: see this open letter, here on Meta Wiki: Letter to Wikimedia Foundation: Superprotect and Media Viewer and also on change.org. -Pete F (talk) 22:47, 28 August 2014 (UTC)

Discussion (MV software should be permitted to return to "opt-in" on those projects where that has been clearly called for)

• Hey Pete, this consultation page is for talking about, for the most part, changes to Media Viewer software that are beneficial. There's a bunch of information on the page itself. I think just about everyone is aware of the petition, and this page is not about the petition, you've got some other venues going on for those conversations. Could we perhaps keep the discussion here to the topic presented? It'd be mighty who of you to afford a little conversation about this :). Perhaps you can revisit some of the issues you had back in February and we can discuss some specifics. If you have nothing more to say, that's fine. Keegan (WMF) (talk) 22:55, 28 August 2014 (UTC)
  • I consider the WMF's effort to start this discussion, while resisting a simple change strongly requested by a large body of interested parties, to be disruptive. It is worthwhile to note on this page why I, and probably many of the 700+ people signing the letter, believe it is not yet possible to have the discussion that WMF proposes. -Pete F (talk) 22:59, 28 August 2014 (UTC)
    • All righty. Keegan (WMF) (talk) 23:03, 28 August 2014 (UTC)
• Oppose this move as something that only tackles surface of the problem. More detail on some of the root issues. They have to be addressed first; don't beat head against a brick wall. --Gryllida 04:19, 29 August 2014 (UTC)
• Please do not disable it for logged out Joe Users without asking Joe Users about it! Why should the veteran editors have any say in this? They have settings they can change _for themselves_. I postulate that the viewer is already a vast improvement for casual readers and should be enabled, but this claim needs to be verified. Just make sure to exclude veteran editors from the poll! --Romanski (talk) 18:59, 31 August 2014 (UTC)
  • At least in the English RfC, every single comment from an IP said Media Viewer should be disabled by default. Furthermore, the WMF had a poll attached to Media Viewer during the initial deployment. While Media Viewer fared better with readers than editors, fewer than 50% of people who responded to the English version who don't edit Wikipedia said the Media Viewer was even useful for viewing images. Based on the evidence we have so far, readers don't prefer Media Viewer, despite the WMF using them as a justification for a "silent majority" argument. Which is nonsense—the WMF doesn't really care about editors as evidenced by not giving people like me without an account a way to turn Media Viewer off until months after the first deployment. And even now, the anonymous opt-out doesn't work and I'm opted back in periodically without my consent! Speaking for myself, I have no interest in editing Wikipedia. But Media Viewer is such a terrible unwanted regression from the previous functionality that I felt compelled to figure out the terrible MediaWiki editing experience to make sure people like me aren't ignored. And really, how could someone prefer the slower, less featureful Media Viewer to the old file page? As I've said many times before, it's faster most of the time to get the full size original image loaded in my browser's image viewer with two clicks and an intermediate HTML page load with the old file page than it is to get a lower resolution image that I can't explore with my browser's image viewer in Media Viewer. The only use case where Media Viewer makes sense is for viewing slideshows, which is something I've never felt the need to view on Wikipedia. I'm always interested in specific images and the information about those images, not a gallery. --98.207.91.246 19:18, 31 August 2014 (UTC)
• I very much agree with Pete, this here is both, a) a distraction from the real problem the WMF created by acting aggressively against the community and b) a tool to finally include the communities in the development process of this gadget. As the WMF still believes the gadget is something useful in it's current set-up, a believe I can't believe anyone really can believe in, they refuse to do the simple and non-disruptive solution for the immediate time and make it opt-in for those who asked for it as long as it's as buggy as it still is. This still has to made clear here and not swept under the carpet. But the gadget may be not completely useless, so an involvement of the community in general is fine for the development. Of course it should have been made far earlier, and it's of course the duty of the paid staff (paid by the community btw) do be the active part here (if they don't go to the community, they simply refuse to do their work properly). --♫ Sänger, superputsch must go (talk) 19:49, 31 August 2014 (UTC)

Please keep this suggestion on the main page; do not archive again

This section (above) has been removed at least twice, by at least two WMF employees. However as pointed out before, it identifies clear, actionable, and easy-to-do software configuration changes, as requested in this process. More than 800 people have signed a letter that supports this option. (See Letter here on Meta and Letter on change.org) It should remain on this page, even if WMF wishes to disregard it. -Pete F (talk) 18:00, 1 September 2014 (UTC)

• I fully agree with Pete, this hostility by the WMF towards the communities, that ultimately finance them by creating the content and are as such their employers, is unbelievable. Are there really so many so utterly anti-social people, who care f*** about the community? Jimbo said: If you don't like it, fork off. I'd very much like to see a lot of those in WMF to fork off, nobody will miss the creators of superputsch. --♫ Sänger, superputsch must go (talk) 18:06, 1 September 2014 (UTC)

Pete, this section does not articulate a change to the software for the people who are using the software. It articulates a change in whether (most) people use the software, not in how the software itself works. Whatamidoing (WMF) (talk) 18:05, 1 September 2014 (UTC)

Yes, that's right. And that's a discussion the WMF wants to block and evade with might. It's like this fluffy, completely empty letter to deWP by Lila and Erik, that stated: "This is an open process, as long as the WMF gets its way" in quite a lot meaningless marketing goobledygook. I fail to see any reason, why this flimsy gadget hat to be forced with so much might and ruthless brutality against the communities. Of course the WMF wants to distract us from this deplorable behaviour of them, and let us make some useless comments about the (now especially because of this brutallity) so much hated MV. It's the fault of those who used brutal force over reasoning, i.e. Erik and his ilk, that the whole discussion is tainted. And as long as the thread of this force is not completely taken back, by completely disabeling the superputsch divice, making the MV opt-in at least in deWP and enWP until it fits the communities will, and let the WMF eat quite amounts of humble pie, this will not vanish by simply trying to edit it in some unseen back room.

Why is this damned MV so f***ing important to alienate whole communities and use brutal force instead of arguments? I completely fail to see any need for this, if it had been anothe few month opt-in, until it worked well, nothing bad would have happened. --♫ Sänger, superputsch must go (talk) 14:39, 2 September 2014 (UTC)

I'm really glad to see the community coming together like this over any issue. Consensus seems to be hard to achieve, and the letter/petition is an impressive effort that indicates it is possible. That said, I don't agree with the content of the letter, and if there were a letter stating that volunteer community members should not have the final say over something as critical to the software stack as a Javascript file served from the main domain and actually had forward-moving actions/consequences built in to the petition, I'd sign that. Then I'd move on to other things- possibly working on MV itself- because the issue of whether something like Media Viewer is opt-in or opt-out simply isn't worth stressing out over. There are far bigger fish to fry, and I hope we can get the same sort of community consensus on those issues much earlier in the process to minimize disruption to our readers and editors. Cheers! -wʃʃʍ- 07:21, 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)

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)

Make the license obvious

• Problem: currently a very dull grey

• Proposed solution: make it the colour red

Discussion (Make the license obvious)

currently the actual license is in a very dull grey colour as impossible for it to be noticed, it should be in a colour that makes it the equal most prominent piece of information provided along with proper attribution. Gnangarra (talk) 23:26, 28 August 2014 (UTC)

I agree that grey is almost always a bad colour to use anywhere on an interface, particularly a slightly lighter grey interface; it's almost invisible for me with my slight presbyopia. Red might not be the solution (it looks grey to people with certain types of colour blindness, leading to the same issue), but a more vibrant colour (with thicker letters) or a much darker shade of grey would be better. Risker (talk) 23:33, 28 August 2014 (UTC) Noting: this is also an accessibility issue, not just a preference. Risker (talk) 23:35, 28 August 2014 (UTC)

Hi Gnangarra, thank you for this. Both you and Risker raise the point well about light grey and the ability to differentiate. --Rdicerb (WMF) (talk) 00:25, 29 August 2014 (UTC)

IMHO, charcoal grey would be better suited. Bidgee (Talk) 02:57, 30 August 2014 (UTC)

Or a medium-to-dark blue, perhaps, providing reasonably high contrast and distinction from the description body, but having a more advisory/informative feel than red would, with its warning/prohibitive connotations.—Odysseus1479 (talk) 21:23, 31 August 2014 (UTC)

• Yeah, that's trivial to fix. --Gryllida 04:23, 29 August 2014 (UTC)

It is quite weird though to have the right-chevron indicating that there is another image in the sequence, and to click that out of curiosity and find a big GNU head. Sminthopsis84 (talk) 12:39, 29 August 2014 (UTC)

See the section below about excluding icons.—Odysseus1479 (talk) 21:23, 31 August 2014 (UTC)

I think that the licence should be included below the author name. It should say "Licence: CC BY-SA", but with the link text on black or dark grey. --NaBUru38 (talk) 22:33, 1 September 2014 (UTC)

Respect the german community and switch the mediaviewer to opt-in!

• Problem: The WMF does not respect the community and its decisions.

• Proposed solution: Fix bug 69292. —The preceding unsigned comment was added by DaB. (talk • contribs) 29 August 2014, 01:51 (CEST), UTC+2.

Discussion (Respect the german community and switch the mediaviewer to opt-in!)

• Agree the rolled out state of media veiwer was very disrestpectful to the projects media contributors and the WMF could have addressed the community concerns rather than whack it with a big stick but its not helpful to divert this discussion into that area. Gnangarra (talk) 00:08, 29 August 2014 (UTC)

I believe you get better feedback if you do not force people to use something. If the WMF would switch the MediaViewer to opt-in, only people who care for the MediaViewer would use it. These people are much more likely to give positive and helpful feedback.

The MediaViewer is like a school that force the students to eat in its cafeteria where only “good and healthy stuff (because we know what’s best for you!)” is available. And to take the biscuit now the students are ask how to improve that! --DaB. (talk) 00:44, 29 August 2014 (UTC)

DaB., not listening to 100% of what community says is not new; see Limits to configuration changes. This problem has long deep roots starting from 2010 and earlier (also raised at this page, below). Please calm down.

You're in a position to translate complaints from German people here. If something actionable is brought up and is not trivial to fix (and is provided by classic File pages), the feature will be made opt-in as they promised. --Gryllida 04:28, 29 August 2014 (UTC)

+1 The Feature should be opt-in, if communities want it to be. At least until the "must have"s are carried. --Don-kun (talk) 05:14, 29 August 2014 (UTC)

+1 Having this buggy thing as the default reflects poorly on the WMF in the eyes of its vast public. Sminthopsis84 (talk) 12:44, 29 August 2014 (UTC)

+1 I fail to see a single valid reason why MV has to be enforced asap. If it's opt-in in deWP and enWP just as at commons for some months, nothing bad could possibly happen (besides to the egos of some people at WMF, but I don't care about that). It's a pure power game by the WMF to show the unwashed masses who's in charge. --Sänger S.G (talk) 13:33, 29 August 2014 (UTC)

+1 --Gruß Tom (talk) 16:01, 29 August 2014 (UTC)

Comment: There is a discussion of this going on elsewhere, I don't know about anyone else, but I'd like to not see that same discussion also come to this page as it will make the other discussions here more difficult to follow. Zellfaze (talk) 10:56, 30 August 2014 (UTC)

-1 the communities are people who can go and change their settings. What you're forgetting about are vast troves of logged out users who are not part of "the community" that has a consensus on this. Think about all the people affected by the change who have never participated in your community! Have they been asked about what they prefer? --Romanski (talk) 19:13, 31 August 2014 (UTC)

What about the English poll carried out by the WMF where fewer than 50% of users who responded said Media Viewer was useful for viewing images? What of the readers like me who chimed in on the English RfC and were unanimous that Media Viewer should be disabled by default? There's no evidence to suggest that the WMF has a better finger on the pulse of what readers want than the communities that have taken up this issue and much to suggest they have a view biased in favor of their failed product. --98.207.91.246 20:08, 31 August 2014 (UTC)

+1 Just roll it back to beta, and then start from the beginning with the communication about it and about the reasons, why users don’t want to have it, then this request will be fulfilled. It’s not hard, it’s very easy to do. The WMF just have to have the will to do so, that’s all. Otherwise, there will be no good communication with the communities in the future anymore and no trust will get back neither, if the WMF just does, whatever they want, and ignores the will of hundreds of users in the normal voting processes. I don’t see no other way get out of this whole mess anymore. Communication about something that is constantly pushed upon the users against their will is nothing that will lead anywhere, because it changes nothing. This thing MV is still there, so why communicate about it anymore? I don’t see no sense in that, if the WMF just wants to ignore the will of the users and, by the way, also of the majority of the readers in their own poll. It’s ridiculous seeing this happen here. Do you really want to build up your own encyclopedia by yourself without those users which you prefer to ignore? Is this, what you want? Each day, this goes on, is a lost day. Each day is going to make things worse. I really don’t understand it. --Winternacht (talk) 22:16, 1 September 2014 (UTC)

Just a Bump because if the overeager archive bot here, thyt even removes unsolves issues out of sight. ;) --♫ Sänger, superputsch must go (talk) 06:56, 4 September 2014 (UTC)

Stop.

• Problem: The new media viewer is very obstructive to my use of Wikipedia.

• Proposed solution: Disable by default the new media viewer. —The preceding unsigned comment was added by Mysterytrey (talk • contribs) 29. Aug. 2014, 02:27 (UTC).

Please see the answer I gave Daniele above? :) Thank you! --Elitre (WMF) (talk) 02:35, 29 August 2014 (UTC)

Discussion (Stop.)

True. Stop it by default. Enabling by default may be appropriate for smartphones because of their small screens.--RöntgenTechniker (talk) 13:12, 1 September 2014 (UTC)

I do not see what is missing in the normal Firefox behavior. If you want extend the browser extend _the_browser_. If the browser should behave somehow better then people will use that feature even on other sites.--Jankratochvil (talk) 18:29, 1 September 2014 (UTC)

get rid of it

• Problem: Annoying and takes a long time to load, the new Wikimedia Media Viewer is another failed attempt to modernized the outdated Wikipedia.

• Proposed solution: Do away with it. It's much easier to go directly to the photo's page. 99% of the time when someone clicks a picture they simply want to see the full sized photo. —The preceding unsigned comment was added by Airplanespotter15 (talk • contribs) 29. Aug. 2014, 02:56 (UTC).

Discussion (get rid of it)

• Please use Firebug to track the load time. I could only suggest to load image last and show metadata first, here. This is a real issue. (Whether classic file pages have it or not, I dunno.) --Gryllida 04:34, 29 August 2014 (UTC)
• I do like the Media Viewer, please keep it. But of course it can be improved. --NaBUru38 (talk) 22:36, 1 September 2014 (UTC)
  • So make it opt-in for the what, 1%, who like having it. Apteva (talk) 03:25, 2 September 2014 (UTC)

"More Details" should include project icon

• Problem: "More details" is a huge button (which is great!) but with a totally vacuous "paper scroll" icon.

• Proposed solution: Include the project icon (colorized version!) that the file is hosted on as icon for the "More details" button. This has a multitude of advantages:
  • Readers know what will happen (e.g. "OK, Commons Icon -> I'll be taken to Commons")
  • It will help make the button even more prominent, actually contrasting it from a simple ellipsis one could take the current button for.
  • Project icons will be memorable for the reader (contrary to the "paper scroll") which is the key feature an icon should offer.
  • It's the best we can do in regards to recognizability for readers and it will allow us to convey some sort of "corporate identity" (whatever this is called in case of a free encyclopedia).

--Patrick87 (talk) 03:12, 29 August 2014 (UTC)

Discussion ("More Details" should include project icon)

• I agree that the Commons icon, in its normal colorized version, would be best (although I'd like the words to be present too, not just as a tooltip). It's the official symbol of the project, it's used all over the place on WMF projects, and it will build reader recognition. (In the absence of the image being on Commons, it can be replaced by the symbol of the relevant project.) Risker (talk) 03:50, 29 August 2014 (UTC)

Just 2c here, I have in the past read design experts arguing that a logo should never be used for actions different from "take me to the Home page". Also, if this is my first time on Wikipedia, that logo means nothing to me. --Elitre (WMF) (talk) 10:05, 29 August 2014 (UTC)

That arguing might only be valid as long as we do not switch projects by following the link, right? What you put there is pretty much an external link "in disguise" and I'm pretty sure "design experts" would not at all approve of this either!
Regarding your second point: If a user is new to Wikipedia the (e.g. Commons) icon might mean nothing to him (so it's exactly as worse as the current "paper scroll" icon). However the new user might wonder what this icon is and realize that it represents a free media collection named "Wikimedia Commons" and that Wikipedia actually stores its images there. And at that point we would have taught the user what Wkimedia Commons is, and I think that would be great, wouldn't it? --Patrick87 (talk) 15:45, 29 August 2014 (UTC)

I'm all for discoverability of Commons (hey, I'm a sysop there...), I'm just arguing, and am not the one (see Deskana on this very page for instance), that using the logo might just not be the best solution. I don't click on random logos on website I'm not familiar with, but that might be just me, of course :) --Elitre (WMF) (talk) 15:51, 29 August 2014 (UTC)

I agree completly with Patrick87. Keep the Commons icon, use the scroll icon (or W) for local files. This was one of the few smart things in the MediaViewer design, that you could see immediately where this image comes from, commons or local WP. Why on earth is the WMF Multimedia team determined to make commons as hard to find from Wikipedia as possible? That must be the worst longterm strategy for a multimedia team that i know, making the media repository a dead place that nobody knows and nobody visits and nobody finds. And nobody curates, consequently. WTF? [1][2][3] But hey, if some "design expert" makes some generic comment about icons, that is of course far more important.... --Atlasowa (talk) 13:29, 29 August 2014 (UTC)

Maybe Deskana manages to explain it better than I can. --Elitre (WMF) (talk) 14:43, 29 August 2014 (UTC)

As an idea and maybe workable compromise: What do you think about including the project "icon" as part of the button background? Something along the lines of the following:

More Details

This would probably account for the concerns of all parties in a reasonable way? --Patrick87 (talk) 11:54, 30 August 2014 (UTC)

I like where this is headed, Patrick87. Others? Keegan (WMF) (talk) 21:34, 31 August 2014 (UTC)

I would like the button to have a colorized Commons icon and a label "More details" (except if the screen is narrow). --NaBUru38 (talk) 22:37, 1 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)

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)

Provide selectable full title. Load metadata first.

• Problem: I frequently visit file pages to select file name. My operating system copies ("yanks") it then and I can paste later by middle-click. I don't need any extra clicks or right-clicks: it's just 'select to copy', plain as that.

MediaViewer, on the other hand, doesn't provide me with a full file name. The currently visible metadata load after the image finished loading, or nearly so.

• Proposed solution:

1. Load metadata before loading the image.
2. Provide with a full file name which is easy to select ("copy-by-select") for pasting (middle click) elsewhere.

Discussion (Provide selectable full title. Load metadata first.)

• I opened this suggestion. --Gryllida 04:36, 29 August 2014 (UTC)

Selectable full title / reusing file

MediaViewer reuse pane.
- A spacey big pale interface, hard to read on the eyes.
- Apparent lack of clarity in styling;
- Too many things to click, indicating that, with the current layout, the interface is cluttered.
- While all of this is here, the contributor is somehow encouraged to copy over the entire "[[File:bla bla..." bit from here, even though the wiki markup editor already has a button for adding this bit.
--Gryllida 05:51, 31 August 2014 (UTC)

I'm guessing copy/pasting it from the final part of the URL doesn't work for you? --Elitre (WMF) (talk) 10:19, 29 August 2014 (UTC)

Copying from URL does not work in all browsers and it is not elegant (there are "_" en the place of spaces). --KuboF (talk) 17:47, 29 August 2014 (UTC)

It isn't elegant, but the "_"s do still work and are only noticeable in the wikitext when copied/implemented. You can get the file name from the Embed section of "Use this file", and directly from the URL (in browsers in which it does work). KuboF, which browser are you using? Does this help? -Rdicerb (WMF) (talk) 01:07, 30 August 2014 (UTC)

@Rdicerb (WMF): For me copying from URL works (newest Firefox on Linux) but I think about another users too. As I remember it didn't worked in Internet Explorer (now?). Using "Use this file" is nightmare for me because it is impossible for me to select only part of the text (the system force me to select WHOLE text).

In all cases - there are users which prefer (or even can only) copying filename from website, not it's URL. Without showing full filename would be for me more productive to disable MV. --KuboF (talk) 12:42, 30 August 2014 (UTC)

Elitre, by default, when I click the URL bar, the entire URL gets selected. I need extra clicks to focus on the last part of the URL specifically. I could reconfigure this, but for all other websites, this default behaviour is more comfortable. --Gryllida 04:18, 30 August 2014 (UTC)

IMO this sort of thing should be done as a gadget. It is extremely useful for a small set of users but only clutters up the interface for everyone else. --Tgr (WMF) (talk) 00:00, 31 August 2014 (UTC)

FYI: I would consider redesigning the 'embed' button, anyway. It's pretty hard to use right now, especially for people with a small screen. Added a screenshot. --Gryllida 05:51, 31 August 2014 (UTC)

"it's useful to a small set of users" ... yes, the mission-critical kind: people who ( (we) want to) contribute to the project. Making it deliberately hard to discover how to perform common contributor actions would be a bit problematic to our joint mission of attracting and keeping new contributors/ reducing net outflow. --Kim Bruning (talk) 13:02, 1 September 2014 (UTC) inadvertantly making it harder to add images to articles is probably a bad idea. :-P

Load metadata first

• To my knowledge, this point wasn't discussed at all, above. --Gryllida 05:51, 31 August 2014 (UTC)

Give some love to non-JS users

• Problem: Non-JS users get no improved experience.
• Proposed solution: Write a non-JS version of MediaViewer which provides people with the big image, left/right buttons, and other lovely things.

Discussion (non-JS version)

• I proposed this idea. --Gryllida 05:34, 31 August 2014 (UTC)

Better not. It’s not necessary, and it won’t be tested anyway, so I suppose it will end up in more rubbish than it is now. Just like Flow which obviously hasn’t been tested, before using it on talk pages at MediaWiki wiki, and now has severe bugs. --Winternacht (talk) 22:28, 1 September 2014 (UTC)

Spin-off outside Wikimedia

• Problem: Duplication of effort, resources spent. Erik said «As a footnote, it shouldn't come as much of a surprise that WikiWand includes a lightbox image viewer. I think it's better in some ways than ours [...] They recently raised about $600K in funding, which means that at least some people believe there's a real demand for a nicer, more modern default reader experience».

• Proposed solution: Rejoice! Someone is already developing a dumbed-down version of Wikipedia, including a lightbox image viewer, and has the funding to do so. Less work for WMF and Wikimedia in general, we can switch to work on something else. — The preceding unsigned comment was added by Nemo bis (talk)

"Expand view" is not an appropriate label

• Problem: If a user is trying to zoom in on the image, and starts with the media viewer disabled, they are likely to think that "Expand view" is the way to zoom in. No, that gets them a version of the image from which they have to go back to where they started ("View original file") before any way of zooming is available. Probably, they'll just assume that it is impossible to zoom.

• Proposed solution: "Go to media viewer" would be more helpful. Sminthopsis84 (talk) 12:31, 29 August 2014 (UTC)

Discussion ("Expand view" is not an appropriate label)

Definitely right. It's the completely wrong wording, as it has nothing to do with expanding the pic, thus making it bigger, but starting some new software gadget. Just looked at the German pages, it's the same error here: "Erweiterte Ansicht" instead of "Starte MediaViewer" (or "Starte Bildbetrachter") --Sänger S.G (talk) 13:37, 29 August 2014 (UTC)

How about "File information"? --NaBUru38 (talk) 22:41, 1 September 2014 (UTC)

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)

Display all categories, not just three first categories

• Problem: Media Viewer currently displays only three first categories in the alphabetic order. These three categories in many cases are not the most meaningful ones, and in some cases none of three is meaningful at all (e.g. if the image is licensed under GFDL and CC and is a Featured picture and illustrates an object starting with H-Z, this category describing the object will not be displayed).

• Proposed solution: Display all visible categories in a prominent place, display hidden categories as well but in a less prominent location.

• Optional solution: Display all available categories if it is impossible to split categories into hidden and visible ones.

• Proposal of NickK (talk) 20:30, 29 August 2014 (UTC)

Discussion (Display all categories, not just three first categories)

I would like the field to be labelled as categories. For example: "<Icon> Categories: Wild animals, Scotland". --NaBUru38 (talk) 22:43, 1 September 2014 (UTC)

Also, hidden categories should be hidden. --NaBUru38 (talk) 22:44, 1 September 2014 (UTC)

Don't rip illustrations out of context

A mock-up by Gryllida. 9 March 2014.

• Problem: The viewer rips all images out of the context of the article. But Wikipedia is not Flickr. Images are in an article to illustrate a point. The viewer teaches editors and readers the wrong things. Editors learn they wasted their time when they carefully picked and placed images in an article. Readers get confused because they do not understand where they are (it's neither Wikipedia nor Commons) and what they see (everything is out of context). Sure, the Commons pages aren't better. Neither is the current viewer.
• Proposed solution: Simply use something close to the original Lightbox. Don't go fullscreen. Don't interfere with the browsers zoom and other features (scrolling etc.). Leave the article visible in the background. Let the user click the background to go back to the article, just as it is in pretty much every Lightbox implementation. You said that was your goal, to give readers something they are used to. Why don't you just do this?
• Proposal of TMg 22:20, 29 August 2014 (UTC)

Discussion (Don't rip illustrations out of context)

Excellent point TMg. Some sort of floating viewer would definitely improve matters. Maury Markowitz (talk) 00:56, 30 August 2014 (UTC)

The prototype on the main page would include a caption, if relevant, taken from the article in which it was presented. The mockup. Is this a useful first step in the direction that either of you would like for context? Keegan (WMF) (talk) 04:24, 30 August 2014 (UTC)

• Related discussions:

• Please do not go full screen
• full screen

--Gryllida 06:14, 30 August 2014 (UTC)

• I would ideally like this to be solved by providing easy means of defining a new mode for Media Viewer on-wiki. People have to give it a name, icon, and layout in XML markup, using some form of templates convenction (ie [4]). In my view this is a blocking issue that warrants this feature to remain in beta as an opt-in; contributors came up with the creative layout of the File:* pages for years, and adding this layout customization feature to Media Viewer would empower them. Thanks! --Gryllida 06:21, 30 August 2014 (UTC)
• By the way, I'd like to retain the left/right arrows buttons only where an image is a part of a gallery (indicated by a gallery tag, or when you're browsing a category), as encyclopedic articles often have different sections (i.e., early childhood, education, et al) where looking at a picture out of context is undesirable). I believe this should also be fixed as soon as possible to avoid confusion (see also "let's use it as slideshow viewer!" suggestion below).

Please consider working on this smaller easier bug first, and then on the above, with some sort of layout control on-wiki to add more modes in addition to the built-in ones (currently lightbox and fullscreen). Thanks! --Gryllida 06:00, 31 August 2014 (UTC)

• Interesting. Classier, less obtrusive. The mockup looks like it definitely reduces the "cool web2.0 experience" problem, although I'm not sure it eliminates it. Maybe I'm missing something, but the only purpose for this Media Viewer gizmo seems to be to make an Encyclopedia look more like MySpace. I was going to say it's trying to make the Encyclopedia look more like Facebook, but MySpace makes the point that today's Facebook is tomorrow's MySpace. As Gryllida indicated, it shouldn't be a slideshow viewer unless the editor or context clearly ask for a slideshow viewer. I'm still concerned that I see no way this could replicate all of the essential content and functionality of the original image view web page. It still leaves a useless(?) gizmo shoved in between the reader and the content, which seems to be negative value. Alsee (talk) 17:24, 31 August 2014 (UTC)

Alsee, that's something I'd ideally like to address when people are given the power to write their own layouts/modes in addition to lightbox and fullscreen. I'd perhaps do it like shown on the screenshot, with all information visible. (There is some merit in showing such information without leaving an article, as would be showing a page history and whatnot - a redesign of this software is long overdue.) --Gryllida 22:23, 31 August 2014 (UTC)

There's no way to have "all information visible". The more I think about it, the mock up here only "works" because it's a small image with a small file description, and because the mockup sacrifices information and functionality to get a clean look. Lets look at an example. The very first thing that popped to my mind was to grab a picture of a "bug". This led to disambiguation and I went to "insect". Here's the first image from the Insect article. That's the very first random image I tried. There's no way you can fit that into the mockup format, at all. In baseline view I get an image a page and a half tall. Media View squashes it down 50%. There's no way to put that description onto the mockup. Baseline gives me a beautiful description. Media View gives me garbled description (Yeay another please-don't-fix-this type "bug report", pardon the bug pun.) Alsee (talk) 05:37, 1 September 2014 (UTC)

Alsee, as a long contributor, I still relatively often just want to see a specific image in big scale (when trying to identify a bird species for example), where there's no merit in visiting Commons in my specific case. Perhaps it'd benefit from my visit, were I to read full file details and possibly add more missing categories. Yes.

I can see merit in concerns that MediaViewer is a white spot a pot of coal. A weird move on an otherwise seemingly dead front, design-wise (although it is not in fact dead, it's slowly getting there - things are going to get pretty and people will be able to do a lot more stuff without leaving an article soon). This topic is raised here. --Gryllida 05:48, 1 September 2014 (UTC)

BTW, in addition to the screenshot provided, I might suggest a "corner" icon which would flap the image to show "its back" -- the full file info with all necessary edit buttons. (This would have some disadvantages though, as taking the user straight to Commons would let him view its site notice and forum buttons. There is some merit in integrating the two projects more, not less. Although ability to edit a Commons image from another sister project would improve the quality of its descriptions.) --Gryllida 22:31, 31 August 2014 (UTC)

I am not very technical, but look at auction sites like this, then the pictures gets expanded just by putting the arrow above it: you don´t even have to click it. For the casual reader, this is often enough (and it is very, very fast). And it keeps the context. Why cannot Wikipedia do something like that? Huldra (talk) 11:59, 1 September 2014 (UTC)

I like that direction. No black background, no slideviewer (the latter could be an optional gadget, perhaps default only on mobile). --HHill (talk) 14:55, 1 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)

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)

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)

There HAS TO BE an MV version for Commons editors

I don't know how or why the apparent prevailing idea that nobody on Commons needs or uses MV, they only use the File page - because it's frankly not true. I guarantee there's nobody on Commons who does any serious work (i.e. editing 100+ images a day) using the bog standard File/Category interface. If they're not using MV, then they're using some other tools (CatScan, Visual Change etc). Whatever their task, if it requires looking at lots of images in large size and then making edits based on the image/data they see, I guarantee they're doing anything and everything they can to avoid having to actually manually open and edit the File page, because doing that more than 20 times a day soon becomes tedious as hell, especially if you're doing the same thing to each file. For that reason, for seriously active Commons editors like me, the MV has been invaluable. As soon as the bizarre decision was taken to disable it for logged in users, I immediately re-enabled it. If the present plan to dumb down the MV is to happen, then can someone on the dev team please ensure the current version is retained as an option - and preferably is developed so that it shows even more data (above or below the fold, it really doesn't matter). Ultra7 (talk) 14:12, 30 August 2014 (UTC)

Ultra7: Hi! I'm an occasional contributor on Commons. Could you please describe how MediaViewer eases your routine editing work? Thanks. :-) --Gryllida 06:05, 31 August 2014 (UTC)

I have MV enabled on Commons, as it’s sometimes a nice way to browse the contents of a category. Most often, though, I want to see all the categories &c. for a particular image, so I bypass MV by clicking the filename instead of the thumbnail. I certainly don’t consider it much of an aid to editing, but I don’t mind having the option. Were it necessary to go through MV to get to a description page I’d be rather resentful, and inclined to opt out, but it didn’t take long for me to get used to choosing where to click as part of my workflow.—Odysseus1479 (talk) 20:23, 31 August 2014 (UTC)

I've re-enabled at Commons, too, because it's so easy to bypass. (My work there is mostly diffusing categories via HotCat.) It's nice when you want to just look at images, though, to find one that you'd like to use elsewhere, or to get an overview of the Commons:Photo challenge candidates. WhatamIdoing (talk) 01:11, 1 September 2014 (UTC)

Odysseus1479, WhatamIdoing, This thread and that thread are dedicated to discussion of usefullness of the left/right arrows buttons outside of galleries or categories. Please consider sharing your thoughts there. --Gryllida 05:38, 1 September 2014 (UTC)

Gryllida - the MV greatly enhances routine editing because it allows me to review long lists of images in full screen size at a fast pace - which is invaluable if you're looking for some detail that isn't visible/clear at thumb size, or reading the description or date taken (i.e. not date uploaded). A lot of routine editing on Commons involves making changes based on this sort of information (as opposed to the sort of information you can find via automated means). In this respect, the true value of the MV is not in isolation, it's how you can integrate it as part of a workflow that also involves other tools (which you can use to generate the lists of files, and then perform the changes). The MV enhances this workflow because I have neither the time or the computing power to be able to review such lists the 'traditional' way - i.e. manually opening each individual file page. There were other ways to do it before the MV, but they were clunky at best. Ultra7 (talk) 14:37, 1 September 2014 (UTC)

Performance of loading images

• Problem: When clicking on an image, the image is displayed before it has been completely loaded. Therefore, the user sees an image with an extremely low quality in the first moments.

• Proposed solution: Maybe optimizing rendering process.

• Proposal of Chewbacca2205 (talk) 20:37, 30 August 2014 (UTC)

Yes, immediately seeing the entire image, blurry, before it has all loaded is irritating. This is the aspect of the viewer that bothers me the most. I would much rather have the omage load in full focus from the top down, or stay black until fully loaded. AmateurEditor (talk) 02:24, 31 August 2014 (UTC)

Discussion (Performance of loading images)

• I support the notion that more work is needed on the performance and that showing blurry image is not easy on the eyes. I feel it's not a blocking feature, but a nice area for improvement. (People are being conservative about from-top-to-bottom image load somewhat, but blurry image being hard on the eyes and distracting from proper focus is a valid concern.) --Gryllida 09:32, 31 August 2014 (UTC)

• It's also worth noting that the image generation time does depend on whether the image is cached or not. When an image is viewed for the first time with Media Viewer, it is placed in storage to be recalled again much faster. The end result of this is an image view that loads much faster than a file page on average. However, there is a consequence at the beginning: as images are being first viewed and moved to storage, those view loads are slower than Media Viewer is capable of. The issue isn't with Media Viewer itself, comparably, it's with image rendering times on the back end. When Media Viewer was released on the image-heavy English Wikipedia and Commons/German page automatic redirect to Commons, the cache - storage space - had to build as images were clicked on. Consequently, Media Viewer gets faster literally every day. As the cache builds, low-bandwidth areas and/or connections will benefit and see a faster load than the file page.

As for the blurring of the image, that was a particular design decision that was discussed extensively before implementation. I'll get someone better capable at summarizing it to comment on it as soon as I can. Keegan (WMF) (talk) 03:42, 1 September 2014 (UTC)

Also, we're currently working on making the thumbnails pregenerate at upload time: https://gerrit.wikimedia.org/r/#/c/157157/ in order to get rid of the primed cache issue described above that people currently experience when they happen to be the first person to access a given image at a given screen resolution in media viewer. We've had several rounds of improving Media Viewer's performance during its development and this is pretty much the only thing left to improve.

Regarding the matter of visual speed perception, it can be counter-intuitive. For example people tend to be "blind" to the blank white page they experience when loading a file page, while it hands on loading the <head> of the document. As for what happens while Media Viewer is loading the image, the alternatives have been tested during development and they all felt slower than the current strategy. Displaying a black screen makes MV feels slower, because people aren't "blind" to a black screen the same way they are to the blank white page <head> effect. Displaying the unblurred placeholder (the thumbnail from the page, blown up) looks very ugly on a large screen, the blur is just there to mitigate the ugliness. You can give it a try by overriding Media Viewer's CSS to remove the blur effect. Lastly, waiting to open Media Viewer when the image is ready feels the slowest of all, because one would click on a thumbnail and potentially nothing would happen for seconds, which feels broken. Out of these possible options, the blur effect was considered the lesser evil, which is why we went for it. The only other alternative idea I can think of that we didn't give a try, for lack of good design, was to display a spinner/progress display on the thumbnail itself, in order to provide click feedback, and to then open media viewer when the image is ready. But that doesn't solve the issue of what happens when going prev/next inside Media Viewer, for which you still have to decide between black screen/ugly blown up image/blurred ugly blown up image. That being said we didn't run user tests to determine that the current version felt universally faster than the alternatives and/or that the unblurred version felt better or worse the blurred one. Whether it's a good use of WMF resources to determine that point of detail is debatable, in my opinion.--GDubuc (WMF) (talk) 08:35, 1 September 2014 (UTC)

If people are 'blind' to time spent staring at a white screen, but not to time spent staring at a black screen, did you you consider first blanking the page (white screen) and then adding the black background when the image was ready? Whatamidoing (WMF) (talk) 17:01, 1 September 2014 (UTC)

• I suggest to reword the title of this proposal. It's about the blurry preview image. I find this very distracting, just as the reporter, and proposed a few possible solutions at bugzilla:69609. --TMg 18:26, 1 September 2014 (UTC)

Inconsistency with the rest of wiki interface

• Problem: History pages, recent changes, and others appear to still be implemented as separate pages navigating which and browsing which requires a page reload. Want to view more results in the recent changes view? — Click a button, the page would reload.

Media Viewer stands out as an inconsistent feature.

• Proposed solution: Get on pace with reworking the rest of the wiki interface, introducing proper skin engine, using ajax calls all over the place, design work, mw-ui-* classes all over the place, making it more smooth and modern. Re-add Media Viewer then.

Discussion (Inconsistency with the rest of wiki interface)

• I opened this proposal. It looks to me like Media Viewer is the first piece of software that breaks this consistency in a prominent way. --Gryllida 10:26, 31 August 2014 (UTC)
• Media Viewer should be opt in only for all logged in users. For new accounts it should be disabled by default. It is basically very annoying. Apteva (talk) 13:35, 31 August 2014 (UTC)
  • Apteva: Why? And what are your thoughts on the above? Thanks. --Gryllida 05:52, 1 September 2014 (UTC)
    • I agree that it breaks the wiki interface. When I click on an image, it is almost always for one of two reasons. I want to see it bigger, or I want to go to commons to get to the image itself. With the old interface I could always do that just by clicking on the image to see it bigger, and if that was not big enough, click again to see the actual image all by itself. If I wanted to go to commons I click on the image and look for the commons link and click on that. As an aside, for images that are on commons it would be better to have that first click take you directly to commons, as it is not particularly useful to have a local mirror, with a local talk page - what good is it to have a hundred separate talk pages for the same image? That system was something that I had gotten used to and no one likes change just for the sake of change. It was a system that works well. With the media viewer I am simply lost, looking at something that I did not want. It is particularly bad on Commons, when the only reason I ever click on an image is to go to the image, and that is robbed from me by having the media viewer pop up instead. I am glad that has been removed for logged in users, but I am not always logged in, and it serves absolutely no purpose and just makes it super hard for me to get to the file. But most of the time I am using Tor, without javascript, so media viewer does not exist at all. Apteva (talk) 17:31, 1 September 2014 (UTC)

Consider Browser History

• Problem:

Definitely could have: I don't know whether this has already been considered but I find it annoying that the view of an image is part of my browser history: If I take a look at a picture and close it again and afterwards and press "backward" in my browser I get back to the image instead of the previous Site. (because of Blue Links this is quite a regular "workflow" when using Wikipedia). I did not have the time to go through this whole page so delete this request if you don't think it is important or if it has already been discussed.

• Proposal of Macuser10 (talk) 21:04, 31 August 2014 (UTC)

Discussion (Consider Browser History)

It's been mentioned before. I looks like a new layer on top of the original page, but that's just camouflage, it's a proper new page, just a totally unconnected layout to WP. And that's mentioned in another item here as well. --♫ Sänger, superputsch must go (talk) 21:20, 31 August 2014 (UTC)

OK; thanks for the answer. --Macuser10 (talk) 14:25, 1 September 2014 (UTC)

Viewing notes frames and notes in MediaViewer

• Problem: Notes frames that can be created and viewen on mikimedia commons aren't displayed on Media Viewer.

• Proposed solution: Just display the frames when the cursor move on picture in standard mode or by another mean (to be decided) in fullscreen mode, and pop-up the note after few seconds or by a click into the frame.

• Proposal of Popolon (talk) 08:53, 1 September 2014 (UTC)

Discussion (Viewing notes frames and notes in MediaViewer)

Hi, if you mean annotations, this is a known limitation - although thanks for reporting it, of course. --Elitre (WMF) (talk) 09:08, 1 September 2014 (UTC)

(e/c) Though this would be nice, i don't think this should really be a priority now. The notes gadget is only active on Commons and not in many other wiki's. I have some notes that I got from the MMV developers on how this could be done (I should probably just share those). But this seems like a long term requirement and not a short term requirement. —TheDJ (Not WMF) (talk • contribs) 09:17, 1 September 2014 (UTC)

It doesn't really matter: we need to add stuff to the "could-have" section anyway, don't we :) --Elitre (WMF) (talk) 09:21, 1 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)

como devo fazer

• Problem:

• Proposed solution:

• Proposal of Leonardo Da Silva II (talk) 22:52, 1 September 2014 (UTC)

translation (pt)

How have I got to do?

Discussion (como devo fazer)

What do you mean with that? Do you mean the MediaViewer and how to use it or how to make a new proposal about it or what? --Winternacht (talk) 23:06, 1 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)

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)

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

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

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

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)

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)

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)

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)

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)

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)

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.

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.

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)

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)

Files under fair use, hosted on English Wikipedia, mention a "license" where no license exists

• Problem: English Wikipedia permits the use of non-free files under fair use. These files, when seen through the Media Viewer, contain a "view license" link -- but there is no license to view. The Media Viewer is presenting the media in a way that misleads the reader about copyright, free licenses, etc.
• Example: w:en:File:Mickey_Mouse.png

Discussion (Files under fair use, hosted on English Wikipedia, mention a "license" where no license exists)

The template w:Template:Non-free use rationale, used on >370000 files, includes the required metadata (thanks to an edit by User:TheDJ back in June). This file uses a variant of that template, w:Template:Non-free use rationale 2, which hasn't been updated yet. It's used on a smaller number of files, around 60000. I'll take a look unless TheDJ beats me to it.--Erik Moeller (WMF) (talk)

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)

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)

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)

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)

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)

Your suggestion title here

• Problem:

• Proposed solution:

• Proposal of Sukhmangal 01:19, 4 September 2014 (UTC)

Your suggestion title here

• Problem:

• Proposed solution:

• Proposal of Sukhmangal 01:25, 4 September 2014 (UTC)

Your suggestion title here:

• Problem: Meu nome é Renato Correia Lacerda estou tentando editar textos sobre astrofísica e administração e psicologia tenho ideias inovadoras que iram serem uteis em diversas áreas do conhecimento humano mas não consigo porque me tacharam de louco e mesmo apresentando referencias teóricos não consigo editar nada eu me formei a pouco tempo na faculdade e tenho um conteúdo grande de inovações talvez seja por isto, são assuntos muito inovadores e vocês estão atrelados ao conhecimento comum e não se abrem para o novo , aguardo uma resposta atenciosamente.

• Proposed solution:

• Proposal of Renato Correia Lacerda (talk) 02:02, 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)

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)