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

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

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

Just keep the previous system as default for everyone.

• Problem:

This thing is a pain in the arm. No way to see the image at different resolutions. Too complicated for most casual users. <

• Proposed solution:

Make it optional and keep the very useful and not bugged previous system as default.--31.44.121.34 23:37, 28 August 2014 (UTC)

Make it optional for users. Thanks for recent improvement (Media Viewer was disabled by default for logged in users on Wikimedia Commons, due to interference with the specific workflows used to curate media)--NoJin (talk) 13:48, 29 August 2014 (UTC)

Discussion (Just keep the previous system as default for everyone.)

• Showing images at different resolutions is planned; not a regression compared with the old system, BTW, is it? Looks like not a blocker. --Gryllida 04:25, 29 August 2014 (UTC)
• If it's too complicated, please provide details as to what is complicated. --Gryllida 04:24, 29 August 2014 (UTC)

Agree with the poster, suggest debugging this before asking for community involvement. Sminthopsis84 (talk) 12:41, 29 August 2014 (UTC)

They have been debugging it. What specific issues do you have? The only way they are likely to get fixed is if you raise them here or on Bugzilla or Phabricator. Zellfaze (talk) 10:54, 30 August 2014 (UTC)

• What about using the "expand" image that appears beside the image caption to activate the Media Viewer? This would allow clicking on the image to go back to taking the user to the File page, which seems to me to be the most expected behavior for internet users (note that both Flickr and Tumblr expect images to click through to their source). In this case, an "expand" logo could be made much more prominent -- it may only appear once the user hovers over the image with their mouse, say. -- Gaurav (talk) 02:53, 30 August 2014 (UTC)

Just wait

• Problem:

I really do not understand why every time our programmers create some important tool Wikimedia INSIST to adopt the new tool immediately, without giving a resonable time to test, debug and improve the tool. The same thing happened to Visual Editor, and the consequence of this behaviour is that now a big part of wikipedians hate Visual Editor and Wikimedia. My point is: let's wait! I mean, let's use it as a "beta feature" and let's wait before to make it default. And most important, let the community (editors and readers) decide when it is arrived the time to make it as a default. --Daniele Pugliesi (talk) 02:21, 29 August 2014 (UTC)

• Proposed solution:

Do not rush and follow the consensus. --Daniele Pugliesi (talk) 02:21, 29 August 2014 (UTC)

Discussion (Just wait)

Hi Daniele, please notice this is not intended as a forum to discuss WMF's general behaviour, rather, "The objective of this consultation is to identify any critical issues with this new experience". More specifically, it is the best current way to communicate with the Multimedia team. I'd like to learn about your personal issues with MV, if there are any which might have been overlooked, or about room for improvements, for example. Thank you! --Elitre (WMF) (talk) 02:33, 29 August 2014 (UTC)

The most common improvement proposed to Media Viewer is one that the WMF refuses to implement: disabling Media Viewer by default because it IS NOT an improvement over the the file page. And it won't be, even with all the improvements the WMF and the community have suggested. It should have never been put forth as a substitute for the file page. As long as the WMF refuses to implement this improvement, people will bring it up. If you intended this page to be about feedback other than that, you should moot the issue by implementing this very obvious and popular improvement to shut us up. The WMF should stop ignoring feedback it wishes didn't exist. --98.207.91.246 03:35, 29 August 2014 (UTC)

Ah, 98.207.91.246, this is why we talk about things - to learn how the other is thinking. It seems there is a problem of misconception: Media Viewer is meant to be neither an improvement for a file page nor a replacement for a file page. It is a different way of viewing the image, based on a presentation that puts the image in the forefront instead of surrounding it by data. If you are thinking Media Viewer is File page 2.0, I'm not surprised at all that you don't like the experience. For a better idea of what the Multimedia team is getting at, take a moment to check out the new prototype linked on the project page here. If you're not interested, thank you for taking your time here. Keegan (WMF) (talk) 04:55, 29 August 2014 (UTC)

That's disingenuous. Before Media Viewer, clicking on an image brought you to the file page. After Media Viewer, clicking on an image brought up Media Viewer. In the UI, you're given the option of always activating Media Viewer or always the option of navigating to the file page, but never the option (without the use of a non-discoverable keyboard shortcut) to choose one or the other on a case-by-case basis. So in the UI, you replaced the file page with Media Viewer. This replacement is what people, for the most part, objected to (disregarding concerns about misused resources). This replacement is what Erik Möller has waged war on the community over. I doubt anyone was under the impression that Media Viewer could ever be an adequate replacement for the file page. And I doubt anyone would be up in arms if Media Viewer didn't hijack the UI used to trigger the file page. If Media Viewer is not intended to replace the file page, don't make it replace the file page. Come up with a new way of triggering it that doesn't interfere with access to the file page. --98.207.91.246 05:42, 29 August 2014 (UTC)

We are actually testing a selector on the thumbnail (would only work well with non-touch devices, on hover) - I'm personally not convinced yet the added complexity is worth it, but we should talk about it (perhaps in its own section). In addition, you can always skip Media Viewer by opening a file in a separate tab/window.--Erik Moeller (WMF) (talk) 05:45, 29 August 2014 (UTC)

It's incredibly bad design to have different click behavior depending on whether or not that click is opening the page in the same window or in a new window/new tab. Breaking this consistency and relying on that to send people one place or another isn't very discoverable. And I already acknowledged that you're doing this when I wrote "(without the use of a non-discoverable keyboard shortcut)." And doing a mystery-meat onhover hack is more of the same non-discoverability. The only use case where Media Viewer provides any improvement over the file page is as a slideshow viewer, so you really shouldn't be directing people there unless they're looking for a slide show. If you've seen the light and you'll let the file page be accessed as it always has been while retaining Media Viewer, make the new UI for invoking Media Viewer very clear what it is. Use a descriptive link along the lines of "View slideshow." Don't make people guess or hunt. And quit with the fancy stuff that's hard to use and breaks things. --98.207.91.246 06:03, 29 August 2014 (UTC)

98.* has a point. It would be easy to make the non-core media viewer triggered by the "expand" icon, for instance. --Nemo 06:00, 29 August 2014 (UTC)

Not a bad idea. Keegan (WMF) (talk) 06:13, 29 August 2014 (UTC)

There are some issues, though. The expand icon doesn't show up in infoboxes, for example. Plus the icon says "expand" when, even now just going to the file page, doesn't...expand. There could be a workable underlying thought behind this, but I fear it might be incredibly complex and not workable. Let us see what others think. Keegan (WMF) (talk) 06:42, 29 August 2014 (UTC)

• They are a big Team, they will do things quickly. You should share your thoughts about firing a half of the staff and moving slower over at this page; these issues do not belong here as they do not show how the readers and contributors feel worse after starting to use this tool. This is not a blocker for keeping MediaViewer available. --Gryllida 04:32, 29 August 2014 (UTC)

Prominent "Edit" word before scrolling. In both LightBox and FullScreen mode.

• Problem: The readers do not see that they can edit the file.

• Proposed solution: Rename "See more info" to "Edit and view file info" or similar. The "Edit" word should be spelled out in full in black color sized 12pt or more.

Discussion (Prominent "Edit" word before scrolling. In both LightBox and FullScreen mode.)

• I've proposed this idea. --User:Gryllida 04:42, 29 August 2014 (UTC)
• Dear Gryllida: Thank you so much for all your helpful suggestions on this consultation! We really appreciate all your help to identify important improvements for the next version of Media Viewer. Our team is reviewing all the ideas on this page and will respond in coming days.

For now, we are planning to make this improvement to address your suggestion above: 'More Details' Button: A more prominent link to the File: page.

We considered using the word 'Edit', but concluded that 'Details' would be a more appealing and descriptive term, since the file page contains a lot of information that can be useful to people who are not interested in editing. However, you will note that we plan to include the word 'Edit' in the tooltip, to make it clear that this is where you can edit the file information -- and invite more user contributions. We hope this will work for you.

We have also credited you for your contribution to this feature in the Media Viewer improvements list, as a small token of our appreciation. Thanks again for being such a great collaborator! Fabrice Florin (WMF) (talk) 21:30, 30 August 2014 (UTC)

Make text more readable in the metadata pane

• Problem: The Metadata pane contains text that is hard to read. It's small and grey.

• Proposed solution: Make all text black and sized at least 12pt.

Discussion (Make text more readable in the metadata pane)

• I propose this idea. --Gryllida 03:13, 29 August 2014 (UTC)

Hi Gryllida, thanks for joining this consultation. Would you please sign your other suggestion above? ;) Thanks! --Elitre (WMF) (talk) 03:43, 29 August 2014 (UTC)

(PS, I'm just noting how this suggestion echoes another one made above.)

Elitre, no, it's different. That one is about where you put things and how you organise the layout. This one is about accessibility. (Yes, I'm trying to sign future suggestions.) --Gryllida 04:15, 29 August 2014 (UTC)

That one looks like a suggestion to change colors, to me? Risker even mentions the word accessibility. (No prob for that!) --Elitre (WMF) (talk) 04:18, 29 August 2014 (UTC)

Support and advertise free software philosophy

• Problem: Media Viewer is free software. Free software is encouraged to actively advertise it to its users that they're free to study, modify, and redistribute its source code. In particular they're encouraged to spell out "This is free software licensed under GNU GPL License" on user-facing interface.

Quoting GPL-howto:

For a one-file program, the statement (for the GPL) should look like this:

   This program is free software: you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation, either version 3 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program.  If not, see <http://www.gnu.org/licenses/>.

For interactive programs, it is usually a good idea to make the program print out a brief
notice about copyright and copying permission when it starts up. See the end of the GNU 
GPL for more information about this.

Quoting the end of the GNU GPL manual:

If the program does terminal interaction, make it output a short notice like this
when it starts in an interactive mode:

   <program>  Copyright (C) <year>  <name of author>
   This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
   This is free software, and you are welcome to redistribute it
   under certain conditions; type `show c' for details.

The hypothetical commands `show w' and `show c' should show the appropriate parts of the General 
Public License. Of course, your program's commands might be different; for a GUI interface, 
you would use an “about box”.

Quoting GNU Octave startup message:

GNU Octave, version 3.6.4
Copyright (C) 2013 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type `warranty'.

Octave was configured for "x86_64-suse-linux-gnu".

Additional information about Octave is available at http://www.octave.org.

Please contribute if you find this software useful.
For more information, visit http://www.octave.org/get-involved.html

Read http://www.octave.org/bugs.html to learn how to submit bug reports.

For information about changes from previous versions, type `news'.

octave:1>

Quoting GNU Emacs startup message:

Welcome to GNU Emacs, one component of the GNU/Linux operating system.

Get help           C-h  (Hold down CTRL and press h)
Emacs manual       C-h r        Browse manuals     C-h i
Emacs tutorial     C-h t        Undo changes       C-x u
Buy manuals        C-h C-m      Exit Emacs         C-x C-c
Activate menubar   F10  or  ESC `  or   M-`
(`C-' means use the CTRL key.  `M-' means use the Meta (or Alt) key.
If you have no Meta key, you may instead type ESC followed by the character.)
Useful tasks:
Visit New File                  Open Home Directory
Customize Startup               Open *scratch* buffer

GNU Emacs 22.3.1 (x86_64-suse-linux-gnu, GTK+ Version 2.18.9)
 of 2011-09-20 on chopin
Copyright (C) 2008 Free Software Foundation, Inc.

GNU Emacs comes with ABSOLUTELY NO WARRANTY; type C-h C-w for full details.
Emacs is Free Software--Free as in Freedom--so you can redistribute copies
of Emacs and modify it; type C-h C-c to see the conditions.
Type C-h C-d for information on getting the latest version.

If an Emacs session crashed recently, type Meta-x recover-session RET
to recover the files you were editing.

• Proposed solution:

1. Add a notice to the top of the About box of MediaViewer. (This has to do with the software itself.)

   MediaViewer program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

   MediaViewer is an extension to MediaWiki. MediaWiki also is free software.

   Please contribute if you find this software useful. For details, see:

   * How to become a MediaWiki hacker

   * Extension:MediaViewer

2. Add a prominent 'About' or '?' text, spelled out in full, on the lightbox mode before the user scrolls, as well as in fullscreen mode (since it could be an entry point where someone linked a slideshow). Clicking it should open the About box. (THis again has to do with the software itself.)

OT:

1. Track bugs in the open. Anyone should be able to add a bug without being linked to an external system. That is, stop doing everything, drop all things, postpone any current tasks, and work on completing Phabricator migration as soon as possible. (Qgil should be interested in this point.)
2. Collaborate and make decisions in the open. Document all plans that you have.
3. Maintain a list of good first bugs. Support that volunteers tackle them gradually and get involved in the development process.

Discussion (Support and advertise free software philosophy)

• I proposed this idea. --Gryllida 04:11, 29 August 2014 (UTC)
• Related discussion 1, related discussion 2. --Gryllida 04:38, 29 August 2014 (UTC)
• I split the suggestion to indicate which improvements are for the software itself and which ones are for its development process. --Gryllida 04:39, 29 August 2014 (UTC)

Clarify/improve link to the file description page

• Problem: The Wikipedia and Commons buttons in the interface are rather opaque, and it's not really clear what clicking on them will do until you've done it. Anywhere else on the site clicking on the Wikipedia or Commons logos takes you to the main page, and that's half what I expected to happen in MediaViewer. The only way for the user to understand what the button does is to hover over it and read the tooltip, and by then it's too late, really. Worse, the interaction is even more confusing for new users; clicking the unknown icon on the button takes the new user to a fairly similar but totally different looking page (i.e. the file description page), with little explanation of what happened other than the tooltip. I find this interaction problematic from the angle of a new user, and also an experienced one.

• Proposed solution: Consider adding succinct text to the interface? This isn't always possible (e.g. on mobile interfaces where the screen is small), and it's often really tricky to find succinct text that captures the interaction, but it's definitely worth it when you manage.

--Deskana (talk) 05:12, 29 August 2014 (UTC)

Discussion (Clarify/improve link to the file description page)

• I think, as a general rule, every user of a piece of software should be able to figure out roughly what each button does by looking at it. This goal is in most cases totally impossible to actually achieve, but I believe that by trying to achieve it you make your software better. So, if users have to hover over button to summon a tooltip to explain to them what a button does, then regardless of what the tooltip says, you've already failed; the context of the button should make it clear what it does on its own. --Deskana (talk) 04:53, 29 August 2014 (UTC)
  • Deskana, I believe this is fixed in the latest prototype. See screenshot on the content page. Although I'd like the button text to contain the 'edit' word - see my suggestion above and feel free to share your thoughts. --Gryllida 04:20, 30 August 2014 (UTC)

• Dear Deskana: Thank you so much for this helpful suggestion!

We now plan to make this improvement, which should address your suggestion: 'More Details' Button: A more prominent link to the File: page. We hope this will work for you.

We have also credited you for your contribution to this feature in the Media Viewer improvements list, as a small token of our appreciation. Thanks again for helping us improve Media Viewer! —The preceding unsigned comment was added by Fabrice Florin (WMF) (talk • contribs) 21:37, 30 August 2014 (UTC)

Make MediaViewer text larger in Monobook

• Problem: A lot of the text in MediaViewer is too small if you're using Monobook. Take a look for yourself.

• Proposed solution: Make the text in MediaViewer larger if the user is using Monobook.

--Deskana (talk) 05:15, 29 August 2014 (UTC)

Discussion (Make MediaViewer text larger in Monobook)

Hi there, I couldn't find anything about this, so I added it on Bugzilla for the time being. Thanks, --Elitre (WMF) (talk) 11:15, 29 August 2014 (UTC)

Don't reinvent the wheel

• Problem: reinvents the wheel in too many places.

• Proposed solution: remove features in media viewer which are already handled by other pieces of software; when it's not certain that media viewer does better than core, default to core. For instance: if you're not sure you got perfect metadata, just transclude the file page HTML below/next to the image. — The preceding unsigned comment was added by Nemo bis (talk)

Discussion (Don't reinvent the wheel)

Note that removal of the below-the-fold metadata panel is under discussion for this reason (and it is indeed not part of the current prototype).--Erik Moeller (WMF) (talk) 05:42, 29 August 2014 (UTC)

Keeping it hidden is not a solution. Of course the file description needs a bit more space. Perhaps 50 % and 50 % of the screen? But really, it's so late. --Nemo 05:45, 29 August 2014 (UTC)

+1 to removal of the below-the-fold metadata panel. (I would also like to see the 'edit' word on the 'more details' button -- my proposal above.) --Gryllida 04:23, 30 August 2014 (UTC)

Use the feedback you already have

• Problem: the CentralNotice pointing to this page. [1] counts 2132 edits by 600 unique editors, but most messages I saw were ignored. (Additionally, about 2000 editors have expressed their views in various venues this month. But I understand WMF prefers to ignore that side.)

• Proposed solution: If you now have time/staff to address feedback, why not go through what you already received? — The preceding unsigned comment was added by Nemo bis (talk)

Discussion (Stop this circus)

• Who is the "we" you are referring to? --Deskana (talk) 05:58, 29 August 2014 (UTC)

I'm here, among the "we". I believe the poster is referring to users of wikipedia and commons.wikimedia, i.e., people who want to look at the interesting media that have been uploaded, and perhaps read the descriptions of those media. Sminthopsis84 (talk) 12:48, 29 August 2014 (UTC)

This suggestion is off-topic for this RfC, but +1 to focusing more on the editing team activities. Patrolling activities and administrative activities should also be all centered the edit box (and be semi-automated). --Gryllida 04:26, 30 August 2014 (UTC)

I am included in the "we": in fact I agree with Nemo at 100%. We are talking about one tool that has very little impact, instead there is so much work to do to improve Wikipedia and related project. Who minds what the programmers want to do? Wikimedia is made for readers, not for programmers! --Daniele Pugliesi (talk) 06:59, 31 August 2014 (UTC)

Discussion (Use the feedback you already have)

Actually, the listed planned improvements on this page are based both on user feedback, survey data and user testing. This consultation is more about "If we do these things, what's left that is really important to you?"--Erik Moeller (WMF) (talk) 05:48, 29 August 2014 (UTC)

Flawed Consultation Process

I put the "Flawed Consultation Process" section on the main page. Let's consider the simple position "The old image view page was better", and lets use their stated criteria for evaluating it:

Importance: Can this suggestion significantly improve the experience for target users: readers and casual editors?

During the RfC rejecting Media Viewer a large number of comments clearly said they thought Wikipedia was better for readers without it, although the RfC question and closing did not distinguish "get rid of it" votes from "turn it off until it's fixed" votes.

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.

During the RfC rejecting Media Viewer a large number of comments clearly said they thought Wikipedia was better without it, although the RfC question and closing did not distinguish "get rid of it" votes from "turn it off until it's fixed" votes.

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

Yes, removing Media Viewer is easily implemented.

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

Yes. Overwhelming evidence. I don't have the link handy but somewhere on the Mediawiki site I found a link that let me copy-paste a list of over 500 of the text-field from the survey they did on Media Viewer. The text field of the survey asked, and I'm paraphrasing from memory, "What can we do to improve Media Viewer". The nature of the question itself excluded any sort of survey response saying that Media Viewer itself was worse than the regular image view page. I believe this was a good-faith flaw in the survey design - I think the nature of the question simply reveals the overly focused thought process when they wrote it. Even though the nature of the question implicitly prohibited it, the number one answer they got took some form of "Media Viewer is worse". My most conservative count found more than one third of responses to their own survey compared Media Viewer to our normal image view page and said Media Viewer was worse. And let me clarify my my conservative count method. I did count "Remove it" because it carries an almost unavoidable implication the person knows there is a better alternative to return to. I did NOT count "It sucks" because, in theory, the writer may never have seen the normal image view. A more reasonable standard an easy MAJORITY of responses to the survey pretty clearly said they didn't want Media Viewer at all. Then there was a large group of ambiguous comments such as "Don't like it. Can not easily see history, metadata, or discussion." That could be read as a general rejection, or interpreted as a sweeping bug list. If we count those as rejections we get a sweeping supermajority against Media Viewer itself. Any reasonable RfC closer looking at the survey responses would have no trouble taking it as a flat out rejection of Media Viewer itself.

I also found a link (sorry don't have it handy) showing how they processed the free-form text replies into more usable data. They examined each reply looking for anything that could be interpreted as a bug report. The final result was a list of bugs to fix, which a count of how many times each bug was reported. I had no way to see how any individual text response was coded into bug reports, but one thing was pretty clear. When they got a response such as "I hate it. I miss the ability to zoom. Please go back to the old method of viewing images!", they would code it as "Wants zoom fixed". The rest of the comment didn't fit into the coding system, so the rest of the comment got filtered out by the process. This filtered information is what got passed up the chain to guide management. The institutional process itself was deaf to any feedback that didn't serve to drive the project forwards.Alsee (talk) 06:10, 29 August 2014 (UTC)

Zoom suggestion is in the plans, Alsee. They added a bigger button to view file info, now ready in the prototype (visible in screenshot on the content page whose talk page you're using here) to address feedback about missing metadata.

They're asking whether we've lost something when we switched to media viewer by default — something significant warranting a decision to switch the feature off, back to beta (opt-in). You're welcome to add your suggestion of firing 90% of the staff so that the Multimedia Team work is slow enough to account for all 100% of community feedback at this page. --Gryllida 04:34, 30 August 2014 (UTC)

It's a slideshow viewer, so lets use it as a slideshow viewer!

We should go back to our original image view page, but this image viewer is a great slideshow viewer. So let's re-purpose it as an object that we can embed in a page. That way when a subject has far too many good images to fit into an article we can put a reasonable number of images on the page and attach a list of 100 additional images to an embedded Media Viewer object. Alsee (talk) 06:19, 29 August 2014 (UTC)

• I don't need or want a slideshow viewer, so it's hard for me to evaluate it in that regard. I typically select one or two pictures from a gallery to insert into Wiktionary entries. MV just makes the process a bit more cumbersome. DCDuring (talk) 14:14, 29 August 2014 (UTC)
• +1. I agree that the left/right arrows shouldn't be there, unless an image is inside of a gallery, or you're browsing a category. Please see the 'don't rip images out of context!" suggestion above, which I personally interpreted as a thing worth urgent attention before adding new features (and perhaps worth making the feature opt-in before it's resolved). Thanks! --Gryllida 06:02, 31 August 2014 (UTC)

Link title to the "file" page in Commons

• Problem:

Need for a more prominent link to the File: page

• Proposed solution:

Link title to the "file" page in Commons

Discussion (Link title to the "file" page in Commons)

I had made such a suggestion earlier; but neglected. I think title is the most prominent part in the MV other than the photo itself. So it will attract the viewer and chances that the file page is more accessible if it will be turned to a link. Jee 07:00, 29 August 2014 (UTC)

Right now A more prominent link to the File: page is precisely the first item on the must-have list of features the WMF already committed to do. --Elitre (WMF) (talk) 08:41, 29 August 2014 (UTC)

• Dear Jee: Thank you so much for your helpful suggestion!

We now plan to make this improvement, which should address your request: 'More Details' Button: A more prominent link to the File: page. We hope this will work for you.

We have also credited you for your contribution to this feature in the Media Viewer improvements list, as a small token of our appreciation. Thanks again for helping us improve Media Viewer! Fabrice Florin (WMF) (talk)

Show the category of the pictures which are currently viewed

• Problem: User does not know to what list the picture belongs to. So if go to the next file (right arrow) you are not sure what you see. For example the current main page in the german wikipedia shows a picture of the turkey prime minister. If you click on the right arrow you got the picture "Sondhi Limthongkul - Angkana Radabpanyawut funeral cropped" which completely confuses the user, because it have nothing to do with the turkey prime minister. It looks like the media viewer chooses a category of a meeting, but that is not visible for the user.

• Proposed solution: Add all categories in the default view of the media viewer to which the picture belongs to and made it clear which picture category are shown. Provide functionality to choose the category. —The preceding unsigned comment was added by Rjh (talk • contribs) 07:22, 29 August 2014‎ (UTC).

Discussion (Show the category of the pictures which are currently viewed)

I think MV is showing the pictures on that page (here the de wiki main page); not from any category/gallery. Jee 07:33, 29 August 2014 (UTC)

This is correct. About pictures and galleries/categories, there's a slightly related bug: 69583. --Elitre (WMF) (talk) 09:39, 29 August 2014 (UTC)

But this make no sense on such pages like the wiki main page. And still a link to the categories of the pictures are missing. Rjh (talk) 15:40, 29 August 2014 (UTC)

The categories should be there: scroll down and look for a grey tag icon on the right column of the page? --Elitre (WMF) (talk) 15:43, 29 August 2014 (UTC)

The categories are next to the icon in the details. Also, the categories from Commons itself are shown, when the image is from there. Quiddity (WMF) (talk) 00:02, 30 August 2014 (UTC)

Please show a proper URL

Hoi, I blogged about the URL that is used in MediaViewer it is obviously inferior to what Commons offers.. Thanks, GerardM (talk) 07:53, 29 August 2014 (UTC)

To clarify for everyone else reading (and to add searchable keywords :) this is regarding bugzilla:68372, hex encoding of the URLs after the "#", and it seems to be a browser-specific difference. I.e. it works as desired in Firefox, but not in Chrome. Creating a work-around was discussed in the bug, but any attempts would lead to additional problems. Filing an upstream feature-request with Chrome has been done, and doing the same for IE/Safari is encouraged if anyone wants to. Quiddity (WMF) (talk) 00:21, 30 August 2014 (UTC)

Wenig gelungen

• Problem:

Ich empfinde den Medienbetrachter häufig als störend. Ich habe einen alten PC und bei mir baut sich das Bild sehr langsam auf. Häufig bin ich an einem Bilddetail interessiert und da reicht mir eine Vergrößerung. Man kann in dem Tool das Bild nicht zoomen. Das ist sehr störend. Negativ ist auch, dass man den Weg zu den Bilddaten nur findet, wenn man weiß, dass es sie gibt und dann danach sucht. --Luha (talk) 08:07, 29 August 2014 (UTC)

Translation: I perceive the MV often as annoying. I've got an old PC and the picture builds rather slow on it. I'm usually interested in a detail, and a simple enlargement would be sufficient. In the tool the picture can't be zoomed. That's really annoying. What#s as well negative is, that you have to know of the existence of more data about the picture, to search for them and find them. [translation by --Sänger S.G (talk) 13:18, 29 August 2014 (UTC)]

• Proposed solution:

Discussion (Wenig gelungen)

Es ist moeglich, zu zommen, indem du das Icon "Originaldatei ansehen" unten rechts anklickst. Wir testen in der aktuellen Version, dies durch direktes Anklicken des Bildes zu ersetzen (wie auf der Datei-Beschreibungsseite). Der Weg zu den Bilddaten sollte mit den umseitig beschriebenen Verbesserungen ebenfalls deutlicher sein.--Erik Moeller (WMF) (talk) 17:15, 29 August 2014 (UTC)

Ein Zoom ist nicht dasselbe wie eine "Originaldatei" ansehen. Man denke zum Beispiel an die beliebten Panorama-Bilder mit vielen Tausend Pixeln Auflösung. So ein Megabild will man normalerweise nicht mit der 1:1 Lupe angezeigt bekommen. Und auch eine Anpassung der Breite an den Bildschirm führt zu unbefriedigenden Ergebnissen. Meine persönliche Meinung: Ein Viewer, der keine echte Zoom-Funktion mitbringt, ist unfertig. Bitte nachbessern. Bonuspunkte gibt es für den Gebrauch des Mausrads.---<(kmk)>- (talk) 21:01, 29 August 2014 (UTC)

• Dear Luha: Thank you for sharing your concerns about the need for a zoom function in Media Viewer!

We now plan to make this improvement, which we think partly addresses your request: Enlarge images by clicking on them .

We hope this new feature will work for you. Our user tests so far confirm that people intuitively click on the image to zoom, and that the browser zoom solution works for them (this is the same solution now offered on Commons when you click on images on the file page). In future releases, we would like to develop a full-featured zoom function, but this is likely to take at least a month to implement at the level of quality we aim to deliver.

We have also credited you for your contribution to this feature in the Media Viewer improvements list, as a small token of our appreciation. Thanks again for helping us improve Media Viewer! Fabrice Florin (WMF) (talk)

Make the viewer content better

• Problem: The best viewer in the world is useless if you don't have enough good media to feed it with.

• Proposed solution: Work on UploadWizard now. Redirect the WMF staffers currently reading and editing this page to commons:Commons:Upload Wizard feedback; there are years of backlog to work on. — The preceding unsigned comment was added by Nemo bis (talk)

Discussion (Make the viewer content better)

The team is already working on UploadWizard, please see the timeline at mw:UploadWizard#Timeline. --Elitre (WMF) (talk) 09:25, 29 August 2014 (UTC)

Add an optional description panel side-by-side for images like technical drawings or maps

• Problem:

For technical drawings or maps it is most times needed to have a description of the elements in the image. This description should be readable while looking at the image. This is not the case neither in the old nor in the new viewer. As an example for the problem. old: http://de.wikipedia.org/wiki/Datei:4-Stroke-Engine.gif new: http://de.wikipedia.org/wiki/Datei:4-Stroke-Engine.gif#mediaviewer/Datei:4-Stroke-Engine.gif

• Proposed solution:

Add a box which shows the description of the image side by side to the image. This should be optional for each image, since it is not really necessary for most pictures. — The preceding unsigned comment was added by 164.40.202.144 (talk)

Discussion (Add an optional description panel side-by-side for images like technical drawings or maps)

• Hello 164.40.202.144: Thank you so much for your helpful suggestion!

We now plan to make this improvement, which should partially address your request: A caption or description right below the image .

We hope this feature will work for you. We are planning to show a caption or description right below the image, as long as one exists. This caption or description can be easily expanded, and user tests confirm that people appreciate that feature, and are able to access the full description. While it is not exactly what you were proposing, we believe that it will serve your objectives in most cases, without requiring other special features which are harder to build and maintain.

We have also credited you for your contribution to this feature in the Media Viewer improvements list, as a small token of our appreciation. Thanks again for helping us improve Media Viewer! Fabrice Florin (WMF) (talk)

Actually, you can scroll up the description panel and see the image and the description at the same time in Media Viewer. (You won't see the numbers in the description though - that's an unrelated bug about being too aggressive in sanitizing HTML.) --Tgr (WMF) (talk) 00:59, 31 August 2014 (UTC)

Reliability

• Problem:

There seems to be a problem with reliability as the film / video often freezes. — The preceding unsigned comment was added by Walkingtalkingmammal (talk)

• Proposed solution:

Discussion (Reliability)

• Hi, I believe this doesn't have to do with MediaViewer, as video isn't supported yet. --Elitre (WMF) (talk) 12:58, 29 August 2014 (UTC)

Integration of the slideshow feature into Media Viewer

• Problem: Media Viewer offers a wonderful manual "browser" feature that allows a user to click through all the images on a single page or gallery (on Wikimedia Commons), which is a very nice feature. However, I believe it can be improved by integrating some kind of an automatic slideshow feature (similar to the "GallerySlideshow" feature that already exists) into Media Viewer itself. While the current GallerySlideshow feature works, it doesn't display the images in the gallery/category as large as Media Viewer does, and I (personally) don't think it is as elegant or efficient in its use of space as Media Viewer. Obviously, this is not a critical issue, but I believe that it would be a significant improvement that would substantially increase the value of Media Viewer, maybe even to the point of making GallerySlideshow superfluous.

• Proposed solution: The integration of a slideshow feature into Media Viewer would be wonderful. It could work exactly the same way mechanically as the current GallerySlideshow feature, but with the improved size of the image and (I believe) superior design and aesthetics of Media Viewer, it would be a real improvement over current functionality. Perhaps this slideshow feature could be integrated into the interface with a simple "slideshow" icon (like the one used by GallerySlideshow or the slideshow function on Flickr) that is visible in Media Viewer next to or near the "full screen" icon. Michael Barera (talk) 15:02, 29 August 2014 (UTC)

Discussion (Integration of the slideshow feature into Media Viewer)

I would vote against that. Slide shows are nice for enjoying pretty pictures for the sake of it: lean back, relax, and let the images come at the preset pace of the slide show. In Wikipedia, the images are supposed to convey information, and thus the reader/viewer needs some time to digest this information. The time needed is highly dependent on the content of the picture, and the willing of the viewer to spend time analyzing the image. Having the images automatically switch at a preset pace makes no sense in this context. —Edgar.bonet (talk) 16:38, 29 August 2014 (UTC)

You might be right about (English) Wikipedia, but I still thinks this makes a lot of sense on Wikimedia Commons. It would be very useful in the contexts of both categories and galleries, in the same vein as the (clearly useful) GallerySlideshow feature. Michael Barera (talk) 01:55, 30 August 2014 (UTC)

Show filename extension in first view

• Problem: When using image from another wiki to enrich my home wiki I use to click on the image and copy it's full filename to put it in new article. Using Media Viewer I need to find link to Commons page and copy filename from it, what cost me time and concentration.

• Proposed solution: Show the full filename with extension directly in Media Viewer.

• Proposal of KuboF (talk) 17:43, 29 August 2014 (UTC)

Discussion (Show filename extension in first view)

OK, seems to be duplicate of #Discussion .28Provide selectable full title. Load metadata first..29 --KuboF (talk) 17:48, 29 August 2014 (UTC)

I can't zoom on my iPhone

• Problem: I view the wiki on my iPhone. With the new viewer, you cannot pinch-to-zoom.

• Proposed solution: Make it work?

• Proposal of Maury Markowitz (talk) 00:55, 30 August 2014 (UTC)

Discussion (I can't zoom on my iPhone)

Please note that the picture viewer on our mobile website is actually a totally separate product from the desktop MediaViewer. For starters, the mobile web product was designed and implemented by the Mobile Web team. It'd be great if you could contact Maryana, the product manager for the Mobile Web team, to talk about this. I'm sure she'd be happy to hear your feedback. --Dan Garry, Wikimedia Foundation (talk) 04:21, 30 August 2014 (UTC)

Fix for the zoom issue is awaiting code review and should go out soon. [2] --Erik Moeller (WMF) (talk) 04:38, 30 August 2014 (UTC)

Link to license informations in used language

Please link the license informations from the MV to the information in the language, which is used. Example for CC-SA-3.0. --J. Patrick Fischer (talk) 08:08, 30 August 2014 (UTC)

Hi J. Patrick Fischer, do you mean that the link to the CC page from, say, de.wp for a BY-SA picture should point to this? Thank you! --Elitre (WMF) (talk) 11:15, 30 August 2014 (UTC) PS. It might be worth considering that this should probably depend on the language the user chose, not the site's one.

In addition to this: imho the license information should have a more prominent place, so that people won't just copy paste the file onto their own website. It should be clear to everyone under which conditions a file can be used, and how (c:COM:REUSE) - and right now that's not visible enough imho. Trijnstel_talk 10:57, 30 August 2014 (UTC)

Also: is it possible to make the media viewer load quicker on the mobile site... Right now it's pretty slow for me. Trijnstel_talk 10:57, 30 August 2014 (UTC)

Please notice Dan Garry's answer to a related concern. Thank you! --Elitre (WMF) (talk) 11:30, 30 August 2014 (UTC)

Edit icon and translation interface

• Problem: People can expand image description, but if they see a typo, it's not apparent where to edit it. They may also want to translate the image description to their language, as many many images have English image captions at Commons while being added to non-English wikis.

• Proposed solution: Add an edit icon next to the image description, which makes it editable (through a dialog or a textbox below the image). The said textbox should have a "add translation" button, too.

The same "add translation" button should also be added to the File:* pages for consistency.

Discussion (Edit icon and translation interface)

• I opened this proposal. It is a non-blocker, however I believe should be better done early. --Gryllida 06:22, 31 August 2014 (UTC)

Obscures almost all of the important information

• Problem: MediaViewer makes it harder to find the actual image name (for using the image on a page), harder to get the full-resolution image (you have to know to click the button at bottom right, since it's not labelled), harder to find the actual description and the categories, and harder to reach the "edit" button. It makes it harder for almost everyone: without leaving MediaViewer, users of wikis won't be able to get the filename, offwiki users won't be able to get the full resolution, and file-interested wiki editors won't be able to edit the description pages.

• Proposed solution: Make it opt-in, since the people who just want to look at lower-resolution pretty pictures ought to be able to. Give strong instructions to the developers not to force things on communities that don't want them.

Discussion (Obscures almost all of the important information)

I was confused by the instructions at Community Engagement (Product)/Media Viewer consultation. Was I actually supposed to be adding this as a comment to someone else's request? Nyttend (talk) 00:32, 29 August 2014 (UTC)

You did it correctly. How can we clarify the instructions? Philippe Beaudette, Wikimedia Foundation (talk) 01:10, 29 August 2014 (UTC)

Hi Nyttend,

Let's check these claims one by one:

View of the municipal government building in Hyllestad

1) Using a file: The "Use this file" dialog has an Embed function which gives you direct access to wikitext that you can copy and paste into an article. Unlike copying and pasting a filename manually, it already provides the markup and pre-populates the caption (the image to the right was added in a second). The dialog remembers its previous state, so if you do lots of copying of files, it's very fast. It also gives you thumbnail size selection, so that less technical users can choose the preferred size easily.

Is this perfect? I'm sure it isn't - but just because it's different and you can't apply the same cognitive pattern that you've applied before (copy and paste the filename from the title, put it in the right markup form) doesn't mean it's not useful. How could it be improved?

2) Getting to the original file by clicking the image: This is already in the improvements list and is currently being user-tested in our prototype.

3) Getting to advanced metadata and editing: This will be addressed in the new release. The current prototype has a very prominent "More details" button which also has a tooltip that says "View and edit details" (example). Please note that editing File: pages is currently very advanced work due to the use of templates; the joint effort to overhaul structured data on Commons together with the Wikidata team will address this (and potentially make it feasible to expose editable information in the viewer directly if we think that's a good idea); see mw:Multimedia/Structured Data.

--Erik Moeller (WMF) (talk) 01:36, 29 August 2014 (UTC)

A possible improvement for the Use This File would be for it to not revert to just an icon when you scroll down. On my machine at least, when I have not yet scrolled there is the use icon along with text that says Use This File, but once I have begun to scroll to see further information on the file the text vanishes, just leaving the icon. It may just be that I'm not yet used to the meaning of the icon, but I suspect it would be more useful to have the text stay. Though if opinion differs on this, I'd love to hear the drawbacks to keeping the text displayed. Zellfaze (talk) 11:01, 30 August 2014 (UTC)

• Dear Nyttend: Thank you for sharing your constructive feedback about Media Viewer!

As Erik Moeller (WMF) points out, we are planning to make several improvements to address your concerns. Here are two specific features which we are now ready for development, and address your suggestions:

1. 'More Details' Button: A more prominent link to the File: page

2. Enlarge images by clicking on them

We hope these new features will work for you. Our usability research so far confirms that they work well for our test users. In coming days, we hope to confirm more features to address your concerns.

For now, we have also credited you for your contribution to both features in the Media Viewer improvements list, as a small token of our appreciation. We hope that's all right with you. Thanks again for helping us improve Media Viewer! Fabrice Florin (WMF) (talk) 21:57, 30 August 2014 (UTC)

• (Not sure if this is the best section for this comment: feel free to move it elsewhere if it doesn’t belong.) At a Commons category page, I can exercise the choice between MV and a file-description page by clicking either the thumbnail picture or the filename hypertext, respectively. But gallery pages and articles don’t usually display the latter. (I can still get directly to the description with Navigation Popups, or by opening the link in a new browser window, but I think of these methods as workarounds.) It would be convenient if a similar choice could be made with captioned images, by clicking either the thumbnail (for MV) or the file icon in the upper-right corner of the caption area (for the description page): as it is, both these links invoke MV. Would that be feasible to implement? It would leave only ‘bare’ images without a means of direct access to the File page.—Odysseus1479 (talk) 20:51, 31 August 2014 (UTC)

Only use it on full machine readable media files

• Problem:

MV is incapable to read all media templates correct by now, so just disable it for those files.

• Proposed solution:

Simply disable the MV for files, where the licence can not be read in a proper way, and show only media with up to date licence templates in the MV. Sounds quite simple to me: Is there a machine readable licence? Use MV. Is there no such thing? Go to ordinary media page.
Same could be applied for long and elaborated descriptions, like legends for maps etc. If it could be shown in an appropriate way, use MV, if not, don't use it.
Maps without the legend are usually useless, pics without the proper licence are perhaps against some laws. —The preceding unsigned comment was added by Sänger S.G (talk • contribs) .

Discussion (Only use it on full machine readable media files)

It was implemented under the (imho quite absurd) assumption, that the metadata and templates for the files are all in a good machine-readable condition. That's not the case, and nobody at WMF seems to have given a lot of thought about this, despite it being mentioned by editors since at least last November. In the deWP Erik came just some 10 days after the Superprotect disaster to some relevant pages to propose to change a template, something that should have been done by the proponents of this piece of software at least since November 13. --Sänger S.G (talk) 05:52, 29 August 2014 (UTC)

Hi Sänger S.G, I agree we should have made more efforts earlier to help with the template conversion. We did announce the process through the wikitech-ambassadors and multimedia lists and provided instructions, but that was clearly not enough.

With that said, for the remaining cases (which includes e.g. images that don't even use any template for the authorship info), I'm not convinced randomly and unpredictably skipping the viewer (which, BTW, would require an initial API call to determine whether metadata exists or not) is desirable. Right now we already provide an additional link to the File: page with the label "view license" in those cases. One thing that might be worth trying is to have a little metadata cleanup call-to-action in those cases. That would be more in line with the wiki spirit, IMO -- highlighting issues and asking people to help fix them (again, which includes cases like attribution only being provided in free text).--Erik Moeller (WMF) (talk) 06:22, 29 August 2014 (UTC)

The same problem with files that do have a description, but don't use the {{Information}} template. Allready suggested here. Answer was: Put in the Information template to the file. I don't know how many files don't have the Information template but MV should be able to handle these files in a proper way, i.e. showing a file description, even if it's not in the Information template, or go directly to the commons page. Other issue related to this: if the MV thinks that there is no description and tells the user so, why doesn't it give a link to add the missing information. Isn't it a feature that should help user participation? --84.61er (talk) 08:03, 29 August 2014 (UTC)

To make one thing clear: MV is some bling-thing that's the brain child and pet project of WMF, and so it's their duty to do the necessary editing to the files, or program the MV in a proper way to either read all stuff that's human readable, or don't use the MV if it's incapable of doing so.

It's not the job of the community to clean after messy programming (hacking) of paid staff, that they (the community) didn't even asked for.

There should be thousands and thousands of links for examples of editing by WMFers in this area, dating at least from last November, could you please show some of them here?

You wanted this stuff so desperately that you even created superputsch, so it was foremost your duty to make all files machine-readable.

Edith says: Posting in some obscure mailing lists, where normal editers will never look in, is no communication at all.

--Sänger S.G (talk) 08:56, 29 August 2014 (UTC)

-1 for this suggestion. There is no ways to differentiate right now, and the big 'more information' (or 'edit and see more information', if my suggestion above is heard) button is sufficient. --Gryllida 04:29, 30 August 2014 (UTC)

But those information are an integral part of the picture in an encyclopedia, as an encyclopedia is not a picture browser, but an information tool. If the MV can't handle the information as they are, it's broken, plain and simple. those of you, who so desperately want this, should work on either making the MV do it's tasks on the existing files, or engage yourself in correcting those files/templates in a way, the MV is capable of dealing with. I expect you to have done some thorough evaluation of all existing types of files/templates before you even began the first line of coding for the MV. More and more it becomes clear, that it's apparently only working on a certain batch of files, that falls smack in place with the cuckoo-land assumptions simply declared to be valid, and not the RL out there. --Sänger S.G (talk) 08:31, 30 August 2014 (UTC)

Sänger S.G: The premise is that structured file info pages (with aid of Wikidata) will address this concern; at least the media viewer itself would display the information it shows properly. Information such as 'this is from government, so this is public domain' would only be shown as a public domain icon in the viewer, I believe; it'd remain available on the file info page. --Gryllida 05:57, 31 August 2014 (UTC)

I still fail to see the massive and active involvement of the fan-boys of this bling-thing in changing the files to make them readable for their lovely but dumb piece of software. If it's not in the 6-digit area of edits, it's nothing at all. You get paid for doing this, so do it. Don't shove not ready stuff down the throats of the communities that don't want this. --♫ Sänger, superputsch must go (talk) 11:03, 31 August 2014 (UTC)

Sänger, how would you determine whether the license was machine readable? You could determine that it's probably machine-readable if it contains template X, but you could never know that the machine-readable information in the template is both correct and complete. Whatamidoing (WMF) (talk) 00:28, 1 September 2014 (UTC)

To be frank: That's not my problem, this eye-candy is nothing important, there's no need to implement it as opt-out in the next few months. It's just a nice gadget, that doesn't reward any urgency. You (WMF) knew since quite some time that this is a problem, but you decided to define it away instead of dealing with it at the base, i.e. the file: pages. You used brutal force to implement this bling-thing against the communities, without any reason other than "We want it this way, obey!" --♫ Sänger, superputsch must go (talk) 04:24, 4 September 2014 (UTC)

Edith asks: Why are non-solved items moved out of sight to the archives, the place for solved problems? Another sign, that you don't want discussion but obedience.

Display all licensing options

• Problem: currently Media Viewer displays only one licensing option if file is multi-licensed. This make our readers less informed about multi-licensing, reduces public awareness about free licenses and does not show that files may actually be used under different terms. It is unclear how the licence to be displayed is selected among those available.

• Proposed solution: display alternative licensing options (e.g. GFDL, CC-BY-SA and FAL), where applicable, as several icons with descriptions in a row.

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

Discussion (Display all licensing options)

• Agree that this is a serious issue. --Gryllida 10:19, 31 August 2014 (UTC)

Where are the picture notes from the captions?

• Problem: I try to provide lots of information in the captions when I upload. Why bother if this doesn't show up?

• Proposed solution: Both the in-page and commons descriptions should be available in the browser.

• Proposal of Maury Markowitz (talk) 00:58, 30 August 2014 (UTC)

Discussion (Where are the picture notes from the captions?)

Here is an article with captions: en:Course Setting Bomb Sight.

Why don't I see captions?

And why does the transclude from the commons only show a little bit of the page, when there's a whole bunch of whitespace? Maury Markowitz (talk) 02:20, 30 August 2014 (UTC)

As I posted just above, the prototype on the main page would include a caption, if relevant, taken from the article in which it was presented. Additionally, the prototype removes the "fold" or slide panel that contains all this mostly empty space. The mockup. Does this help? Keegan (WMF) (talk) 04:28, 30 August 2014 (UTC)

• I agree, I think this is fixed in the prototype and you can try it out using the link at the 'content page' tab above. If you'd like to alter the LightBox mode layout, please provide details as to where you want things to go. (Flexibility about adding new layouts is discussed in this thread.) --Gryllida 09:47, 31 August 2014 (UTC)

MV default on cell phones, disabled on desktop

• Problem: EXIF of photos is not visible on click on desktop, but image is streched to full screen which looks ridiculous if photo is low res and your desktop resolutions is above 1920x1080, e.g. 1920x1200 or 2560x1600.
• Proposed solution: MediaViewer should be on by default only on mobile phones, but not on desktop. At least not in current severely lacking version (stretching low res images to high resolutions, no EXIF info when there is more then enough place to show it. MV must be reworked to appreciate screen estate of user, or disabled by default.
• Proposal of SpeedyGonsales (talk) 15:42, 30 August 2014 (UTC)

Discussion (MV default on cell phones, disabled on desktop)

+1 Guter Vorschlag, denn für die mobile Nutzung mag der MV wirklich schon jetzt deutlich besser sein. Für Nutzung am PC aber ist er noch nicht reif genug. (Fast) Alle Widerstände beziehen sich meines Empfindens auch auf die Desktop-Nutzung. Also für diese erstmal den Standard aus, wo das gewünscht ist. Und wenn der MV fertig entwickelt ist kann man nochmal drüber entscheiden. Für die mobilen Nutzer aber jetzt schon als Standard an. --Don-kun (talk) 20:31, 30 August 2014 (UTC)

translation:

Good proposal, as the MV may be really better now for mobile usage. For usage on a PC it's not mature enough yet. (Nearly) All resistance seem to relate to the usage on a desktop. So make it opt-in for those for now, if that#s wanted anywhere. Once the MV is completely developed the decision can be changed. For mobile users it can be default now.

-1. I would like us to see a responsive CSS website which has same functionality for both desktop and mobile. Iconifying some things should suffice; there is no need to remove, to my knowledge. --Gryllida 09:34, 31 August 2014 (UTC)

+1 That seems like a reasonable compromise for now. --Tobias talk · contrib 15:45, 31 August 2014 (UTC)

See [3]: For the record, I would like to clarify a misunderstanding: the Media Viewer tool is not implemented on mobile platforms at all. Our mobile team has built a much simpler mobile viewing feature, but it doesn’t have any of the code or functionality of the desktop Media Viewer. All it does now is show a license below the image and a ‘Details’ button that links to the file page. This gives users the option to simply preview the image, before going to the more cumbersome file page -- which was never designed for mobile use and is hard to parse on small screens. In any case, these are two completely different projects right now: in coming months, the mobile and multimedia teams plan to integrate these features more closely, based on user feedback. I hope this clarification is helpful. Be well. Fabrice Florin (WMF) (talk) 22:45, 29 August 2014 (UTC) Andreas JN466 22:17, 31 August 2014 (UTC)

Der Erlebnischarakter des Medienbetrachters

• Problem:

Der Erlebnischarakter des Medienbetrachters steht dem Ziel der neutralen und hinterfragbaren Information entgegen und ist eine zusätzliche Schwelle für potentielle Mitarbeiter. Es ist mir wichtig, daß Wikimediaprojekte keine glatte, polierte, nach außen abgeschlossene Oberfläche hat, sondern die Art des "Herstellungsprozesses" muß immer sichtbar und durchschaubar sein, damit der Leser weiß, worauf er sich einläßt und wie er möglicherweise beitragen kann.

Eine Berieselung mit Bildern wie im Kino oder bei Tumblr spricht dazu hauptsächlich die Emotion an und vermag leicht das Bedürfnis nach intellektueller Auseinandersetzung zu überlagern. Die Anmutung des Medienbetrachters vermittelt dem Leser die Autorität eines Fertigproduktes, das er nur nehmen oder ablehnen, aber nicht selbst beeinflussen kann. Die großen Bilder und vor allem die Möglichkeit, sich nach Art einer Bildstrecke losgelöst vom Text -- ich rede nun von der Wikipedia als größtem Wikimedia-Projekt -- nur auf der dekontextualisierten Ebene der Bilder zu bewegen, verführen zum Fallenlassen, zum unkritischen Bejahen. Der abstrakte und konfuse Eindruck steht dann über der verstandesmäßigen Durchdringung; das Verständnis bleibt an der Oberfläche des Sichtbaren. Der Eindruck unantastbarer Schönheit, den gerade die Beispielbilder zeigen, verstärkt diese Effekte noch.

Es handelt sich beim Medienbetrachter um eine rhetorische, keine instruktive Verwendung von Bildern. Das paßt in einen Katalog oder in einen Unterhaltungsfilm, wohl auch zu einer Präsentation von Kunstwerken in einer (Online-)Ausstellung (Tumblr!), ist aber einem Enzyklopädieprojekt wie der Wikipedia meiner Ansicht nach nicht angemessen.

Translation by Saenger:

The event quality of the MV is opposed to the goal of neutral and scrutinizable information, and is another barrier for potential editors. It is crucial for me, that Wikimedia projects don't have a polished, closed surface, but that the "manufactoring process" is always apparent and transparent, to show the reader, what he's dealing with and how to possibly involve.

With this only consumable experience, like in a cinema or with Tumblr, it's mainly about emotions and it may superpose the need for intellectual examination. The look and feel of the MV conveys the reader the authority of some finished product, that he can accept or refuse, but can't influence. The big pictures, and the possibility to browse them detached from the text -- I'm only speaking about the Wikipedia as the biggest project -- in a kind of de-contextualized image gallery, may lead to just letting go, to uncritical affirmation. The abstract and confused impression stands above the intellectual penetration; the understanding stays at the surface of the viewable. The impression of sacrosanct beauty, that especially the picture examples give, amplify this effect.

The MV uses pictures in a rhetorical, not instructive manner. That fits for a catalog or some entertainment film, probably as well for a presentation of pieces of art in an (online-) gallery (Tumblr!), but imho doesn't suite an encyclopedic project like Wikipedia.

• Proposed solution:

Bitte den Medienbetrachter standardmäßig nur für Mobilgerätenutzer einschalten -- hier kann er möglicherweise von Vorteil sein, und die oben angesprochenen Gefahren sind bei kleinen Bildschirmgrößen vielleicht weniger gegeben.

Translation by Saenger:

Please make the MV only default an mobile devices -- here it may have some advantage, and the mentioned dangers are not that apparent on the small screens.

• Proposal of 93.219.27.253 07:24, 31 August 2014 (UTC)

Discussion (Der Erlebnischarakter des Medienbetrachters)

• Duplicate? --Gryllida 10:44, 31 August 2014 (UTC)

Not really a duplicate, just the same conclusion. And I agree with the IPs statement. This ain't even remotely Flickr or other entertainment stuff, this is about knowledge and information. The MV is a distraction from the core reason for WP, it's just futile bling. --♫ Sänger, superputsch must go (talk) 18:30, 31 August 2014 (UTC)

Progressive loading (display image as it loads)

• Problem: it feels like it takes a lot longer before I see a full resolution image than it did before. Moreover, the progress bar is absolutely useless in Firefox, giving no real indication of how long before I will be able to see the full res image.

• Proposed solution: make the high-resolution image show as it loads, slowly replacing the low-res preview (usually from top to bottom). The funny thing is that browsers already do this perfectly well; you just need to overlay an img tag sourcing the high-res image on top of the low-res thumbnail. The yet-unloaded portion remains transparent, showing the stretched thumbnail underneath. The loaded portion can be viewed in high resolution to decide whether to wait for the rest of the image.

• Proposal of Romanski (talk) 18:48, 31 August 2014 (UTC)

Discussion (Progressive loading)

I believe it's currently loading the thumbnail as a placeholder, and then waiting until the full-screen-size image is completely loaded before showing that image. cf. [4]

If I understand correctly, you are suggesting this should be changed, so that the full image is added on top of the thumbnail using standard loading (also known as baseline or sequential), as the File: page uses. [See here for examples of baseline vs progressive. All of which I had to check for myself, as those terms are often used inconsistently and incorrectly!]. I'll ask the developers if it's possible, and if there would be any drawbacks.

Regarding actual progressive images (also known as interlaced or interleaved particularly in regards to GIF and PNG): I mentioned progressive loading in bugzilla:56441, but I believe that was ultimately decided against, because of:

A) user-confusion when viewing a progressively loading image ("Is it done yet? it still looks kind of fuzzy... oh, here comes another pass... Is it done now? ..." etc)

B) unclear answers as to whether progressive images actually load faster, or satisfy users, or add to the file-size. (I found some notes at stackoverflow)

Lastly: I'm not sure how the progress bar works; I'll ask a developer to add an explanation to the extension's documentation.

Thanks! Quiddity (WMF) (talk) 03:06, 1 September 2014 (UTC)

Make the bottom section either a panel, or part of the page, but not both

• Problem: the UI feels confusing and weird. My very first impression was that I scrolled down and thought the page was broken, because pages don't normally behave like that. The info panel tries to be both an actual panel and also "pretends" to be part of a scrollable page. It's a truly horrible Frankenstein's monster concoction of two unrelated UIs.

• Proposed solution: make the info panel a proper panel, ui-wise. The arrow image that expands the panel should be moved to the top of the panel and its direction changed. Make it clear that this image raises the panel. Having it point down is totally backwards. Second, disable the scroll wheel. It being enabled leaves a bad impression that the page is somehow misbehaving.

• Alternative proposal: make the info panel properly part of the page. Leave the image arrow where it is. Scrolling down must scroll the whole lot, not just the panel. Make the arrow keys work like they work on a normal scrollable page. Just don't mix these two paradigms! (for the record, I prefer my proposal #1).

• Proposal of Romanski (talk) 19:08, 31 August 2014 (UTC)

Discussion (Make the bottom section either a panel, or part of the page, but not both)

• This is partly addressed by the prototype linked at the page. It has a big 'more information' button.

Flexibility about layouts is discussed in this thread. A new all information mode could actually be useful - for JavaScript users, not having to leave article just to view file info may have some merit. --Gryllida 22:28, 31 August 2014 (UTC)

The category link tool from commons could be on the player.

• Problem:

• Proposed solution:

• Proposal of One more edit (talk) 20:14, 31 August 2014 (UTC)

Discussion (The category link tool from commons could be on the player.)

I believe you're suggesting that c:Help:Gadget-HotCat should be added to the Media Viewer. Is that accurate? Quiddity (WMF) (talk) 03:26, 1 September 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)

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? [5][6][7] 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)

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)

"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 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 [8]). 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)

• Beside the above approach, it occurs to me that the navigation controls themselves could help prevent readers’ being surprised by a change of context. Assuming it’s possible to identify the section or gallery where each image is found in the source page, I propose that while displaying the last (or first) image in a section, the ‘guillemet’ icon linking to the next (or previous) image disappears, as suggested above, but only to be replaced by a next- (or previous-) section control. This might be a double guillemet, or just one of a different colour or in a different position, anything that will convey to users that they’re ‘taking a bigger step’. At the end (or beginning) of an article, it would be useful to be able to cycle back to the beginning (or end); again this could be indicated with a change to the control’s appearance or position. (It can be tedious having to step all the way back through a large gallery or image-heavy article, so even if this sectioning approach won’t fly, I’d like to be able to cycle past the end or beginning.) Alternatively, the next- & previous-section controls could be shown always, above or below the next- & previous-image ones, allowing readers to skip forwards, backwards, or around regardless of where in the sequence the current image falls.—Odysseus1479 (talk) 21:41, 6 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: I have just posted a suggestion to the topic that’s now immediately above this one.—Odysseus1479 (talk) 21:50, 6 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)

There is another thread about this : Talk:Community_Engagement_(Product)/Media_Viewer_consultation/Archives/2014-09#Display_image_annotations

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)

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)