Extension talk:Media Viewer/About/Archive02

Clarity

 * I like that I can see all the most relevant information about the image in one page only and the graphic display. --Daniele Pugliesi (talk) 06:29, 9 November 2013 (UTC)
 * I like that it is possible to watch more details present on a picture, exactly text explaining what a part or a component of some graph means, so eliminates some confusion of not being sure what is on that picture. Cornel24 (talk) 17:53, 10 November 2013 (UTC)
 * Hello, it's a very good idea : now we can have a look on the picture without having to go to Commons and then click again to see it in a larger size. It is quite clear, also : we easily and quickly see the picture and the information, and all the links we need are there. Thank you for this new feature ! Best regards, --Daehan (talk) 10:06, 22 November 2013 (UTC)
 * Very good all round. Being able to just click on images to see data without having to leave the page or open another tab on my browser is very useful. It's also far smoother than most similar functions on other sites. A big thumbs-up from me. --ProtoDrake (talk) 11:52, 25 November 2013 (UTC)
 * It's very good that such an application is being updated by the Wikimedia team. It really helps to save time and in the mean time shows a clarified image. --Shalini Ghose (talk) 2:43, 3rd December 2013

Context
The Media Viewer is a good idea for viewing pictures at a larger size without having to jump away from a page with their file description content. It loads rather slowly, which could be improved, but it is nice I can enlarge thumbnails without having to go to another page to see the bigger picture. Arcane21 (talk) 06:34, 5 November 2013 (UTC)Arcane21

More intuitive

 * I think that this is a more intuitive experience for the casual reader than the current behaviour of clicking on a link which takes you to a page about the image.--NHSavage (talk) 22:40, 18 December 2013 (UTC)
 * I find this to be a much more efficient way of viewing content than leaving the main article or taking up space in my generally overcrowded tab bar. Why didn't anyone think of this earlier? --Yea55 (talk) 18:46, 19 December 2013 (UTC)

By wording

 * The smily face in front of "by X" is strange to me, especially with the word "by". Either have a upload symbol so the row can be interpreted as "Uploaded by X" or remove the "by" So it reads as "User X". --Ainali (talk) 09:07, 2 November 2013 (UTC)
 * I suggest to replace the smily face with an icon showing an arrow going in a box, similar to this one: File:Crystal Clear app ark2.png. --Daniele Pugliesi (talk) 06:29, 9 November 2013 (UTC)

Size links

 * I'm quite a fan of the links which quickly allow you to switch among image sizes. Small or full screen are not exactly my favorite formats :) --Elitre (WMF) (talk) 14:15, 4 November 2013 (UTC)

Talk page

 * TALK PAGE! - Wikipedia is all about read-write capability and when I have this option enabled it makes it LESS write and MORE read. A button that links to the existing talk page ANYWHERE would be nice, otherwise I think this is a great tool. Victorgrigas (talk) 04:00, 25 November 2013 (UTC)
 * Related to my suggestion to link to Commons more prominently. Local file talk pages are probably not needed. —Gryllida 10:05, 7 March 2014 (UTC)

No good as default (we redirect to Commons directly, in french Wiktionary)

 * Cool but don't force this to be the default setting without let the option to the user to deactivate it. I'm from the Wiktionnaire (french wiktionary) and on our project click on image redirect automatically to Commons, and it's kind of practical when we are contributors. Vive la Rosière (talk) 01:45, 22 November 2013 (UTC)
 * Thanks. —Gryllida 10:05, 7 March 2014 (UTC)

Closing the window

 * Not sure if someone said it but you guys need to leave the X visible, a user shouldn't be hovering the mouse around to close an image. That's just plain bad design --Camilo Sanchez (talk) 15:34, 10 December 2013 (UTC)
 * I agree with this, at first I was not sure how to close the window with the image in. I resorted to using the escape key, which worked, but I think that to roll it out for general use, you probably need the way to close the window to be very clear.--NHSavage (talk) 22:49, 18 December 2013 (UTC)
 * ...and if you use a touchscreen and no keyboard, you're trapped... I'm using a tablet, and had to go to this current page and conversation to understand there is a cross appearing on mouse hoover. Generally, events triggered by mouse hovering with no alternative (such as menus who can't be clicked) should be avoided, due to the generalization of touch screen devices. Epok13 (talk) 22:55, 28 December 2013 (UTC)

Licensing and attribution
I have several problems with the media viewer: --B (talk) 13:51, 22 November 2013 (UTC)
 * 1) The "Use this file on another website" has a relative link to the image description page - "/wiki/File:Donna Shalala - Knight Foundation.jpg".  That link is not going to work if you are using the image on another website.
 * 2) Many images are not suitable for reuse on every conceivable website.  For example, fair use images should definitely not have anything encouraging people to reuse them.  And even some of our licensed images - if it's not public domain and not creative commons, then we shouldn't encourage someone to use it without reading the detailed licensing information.  If you just embed a GFDL image, for instance, you are probably not in compliance with the terms of the license.
 * 3) It's not obvious which thing on the popup is the author.  Unless you already know who the author of a particular image is, you're going to think that the uploader is the author and would incorrectly attribute that person.
 * 4) We've been telling photo contributors that if someone clicks on an image, it will take them to the description page, which will show their license, attribution information, etc.  Now, that's not necessarily true any more.
 * 5) It doesn't actually do anything useful for the reader - they are already one click away from viewing an enlarged version of the image ... you've just made the click do something different.
 * This is absolutely vital. Any software hosted by Wikimedia should meet not only the legal requirements of attribution, but should provide an example that respects the spirit of the licenses by providing meaningful and easy to find attribution. The summary page does not name the author or link to their user page. The software shouldn't go out of beta until this is added. -Pete F (talk) 23:31, 30 November 2013 (UTC)
 * +1, and then some! The new viewer is very attractive, but unfortunately it optimizes the graphic display by making the attribution information less visible. We need to compensate for this by adding an image credit section along with the references on the article page. Can adding an image credit section to articles be automated somehow as a part of this project?
 * We need to be proactive about making image attribution visible because it is so important to image donors! The software should not go out of beta without consulting with our donor partners on this question. Djembayz (talk) 06:50, 1 December 2013 (UTC)

I love this but it's not for me
This is a tremendous gadget, and I honestly can see it being deployed as the default with very few changes from how it is now. I would ask, however, that if this does become the default, there is a way to turn it off. As someone that works with files, when I click on an image, I want to go directly to the local file description page (i.e. as it functions now), because the work that I'm doing with files happens on that page (and because my internet is so bad right now that the extra loading time for the large versions of images will be problematic.) So yeah, I think that for 99% of the people that use Wikipedia, this is a great thing. But for the 1% of people that spend a lot of time in the File namespace, doing the behind the scenes stuff, please make sure that there's a way to skip the lightbox. Sven Manguard (talk) 03:34, 23 November 2013 (UTC)


 * Why not add a modifier key to the click, that would bypass lightbox and take you straight to the description page. Easy to do, simple to learn for advanced users, doesn't bother the rest of the users. TheDJ (talk) 18:03, 26 November 2013 (UTC)
 * Adding an off switch also doesn't bother the rest of the users. I don't like modifier keys, because I prefer to do as much as possible with the mouse. It's also very tedious for someone that, on some days, will view 200, 300 images in rapid succession, to have to constantly use a modifier key. Sven Manguard (talk) 19:57, 26 November 2013 (UTC)


 * I also would like a possibility to turn off this option. I more often want to see full description page than to see bigger image. BartekChom (talk) 00:36, 10 January 2014 (UTC)


 * Thanks Sven, others, for thoughts on this. As we look toward a global release out of Beta Features, we'd absolutely love to get more community feedback about if/how to provide an option to disable and/or go right to the file. Tell a friend to let us know :) Keegan (WMF) (talk) 06:23, 27 February 2014 (UTC)


 * Keegan (WMF) - If I have to right click and open in a new tab, I have to right click and open in a new tab. In all honesty, the ability to disable this is purely a convenience. The interruption to my workflow is, in most situations, quite minimal. I'd like to be able to bypass it, but it's not serious. That being said, I would definitely reach out to the Commons community before any deployment there, as the people on that project have very different workflows and very different needs when it comes to working with files. Galleries on Wikipedia are mainly there for visual effect. Galleries on Commons are there either 1) so that someone can find the image that they want, then click on it to pull up the full file name, and cut/paste that into a page on another project, or 2) large collections of images that are gathered together in a non-public facing page for either a tracking or an administrate/maintenance purpose. Any change to how files are pulled up will impact the workflow on Commons much more than it will on other projects. Sven Manguard (talk) 00:59, 1 March 2014 (UTC)
 * Great, thanks for the detailed feedback about workflow for you. Important information to have. We'll definitely explore the workflows of others. Keegan (WMF) (talk) 05:25, 1 March 2014 (UTC)

Would be nice to have a bypass option or a link underneath the image to the image description page. It's especially bothersome when viewing pages like this where a lot of thumbnails are located and you want to select a photo to be included in an article on Wikipedia. I mostly use galleries to select good photos, as good shot have been pre-seelcted and I don't need to browse through a category of say 2,000 images. But anytime I click on an image, I get the viewer, and it drives me nuts. The viewer is perfect for end users and people who want to download and reuse images elsewhere but it is a nuisance to WIKIPEDIANS who work with images to improve the encyclopedia articles. Please try to develop the gadget in a way that it would be beneficial to both end users AND editors of Wikipedias. Thanks for the hard work. Teemeah (talk) 13:49, 3 March 2014 (UTC)

Problem with location maps
One thing I have just noticed is that location maps where a background image has dot added on to it to indicate locations does not work well with this feature as it only shows the background map. See for example en:List of monastic houses in Devon. This is probably tricky to fix as you have the same problem at the moment - clicking on the image only shows the background map as that is the actual image.--NHSavage (talk) 16:10, 2 January 2014 (UTC)

Regression with where clicking an image goes...
With a note that people may react negatively to change, including one of positive nature, please understand that clicking an image took me to the image page, before, with author and licensing information. Now, the behaviour suddenly changed... --Gryllida 02:58, 30 January 2014 (UTC)
 * Thank you, Gryllida. It will be a big change, and it will surprise people. Particularly the hundreds of thousands to millions of users/editors/contributors that don't subscribe to mailing lists, check local Village Pumps (or equivalent), or participate in any of the social engagement side of Wikimedia projects. We will develop a Media Viewer that will look different, but should not feel different as far as the file information that the Viewer displays. It's important to have the core functionality and your feedback below has been wonderful. I'll be working as a Community Liaison part time on this project to help ingest feedback like yours over the coming months as Media Viewer is deployed. My apologies for us not having much Wikimedia Foundation presence here over the past couple months as we were early on in Beta Features. This is a high priority product and as we enter the second half of the current development cycle Fabrice and I will be here :) Keegan (WMF) (talk) 07:17, 27 February 2014 (UTC)
 * Thanks Gryllida 11:52, 28 February 2014 (UTC)

What do you think of these new features?
We'd be grateful for your feedback on some of the new or updated features we are working on for our upcoming release of version v0.2. Please add your feedback in the third 'Feature comments' section below, as we would like keep the first two sections above as simple listings we can update regularly, rather than use them as discussion areas.

Ready for testing

 * Show Location
 * Show Categories
 * Show File usage
 * Preload the next and previous images
 * Show thumbnail while loading the image
 * Full screen update
 * Show Permissions

You can test recent features of Media Viewer v0.2 on this MediaWiki.org this test page, as outlined in these testing tips. (If you feel adventurous, you can also check the latest features on this slower beta site).

Coming soon

 * Use/Share this file
 * Embed this file
 * Download this file
 * Show Metrics Dashboard
 * Per-site configuration for enabling Media Viewer
 * Client-side configuration option to disable Media Viewer
 * User opt-out for disabling Media Viewer
 * Show shared images in Media Viewer for all users
 * Zoom feature for v0.3

We invite you to check those specifications before requesting features that may already be included in those tickets.

Feature comments
Please add your comments about the above features in this section (we would like keep the first two sections above as simple listings we can update regularly, rather than use them as discussion areas).


 * Show Location - didn't notice this Gryllida 10:13, 7 March 2014 (UTC)
 * Show Categories - didn't notice this Gryllida 10:13, 7 March 2014 (UTC)
 * Show File usage - didn't notice this Gryllida 10:13, 7 March 2014 (UTC)
 * Preload the next and previous images — I like the feature! Great addition. Gryllida 10:11, 7 March 2014 (UTC)
 * Show thumbnail while loading the image — OK, but it flickers a bit. Gryllida 10:11, 7 March 2014 (UTC)
 * Full screen update - didn't notice this Gryllida 10:13, 7 March 2014 (UTC)
 * Show Permissions — Very good. Gryllida 10:11, 7 March 2014 (UTC)


 * Use/Share this file - didn't notice this Gryllida 10:13, 7 March 2014 (UTC)
 * Embed this file - didn't notice this Gryllida 10:13, 7 March 2014 (UTC)
 * Download this file - didn't notice this Gryllida 10:13, 7 March 2014 (UTC)
 * Show Metrics Dashboard Gryllida 10:13, 7 March 2014 (UTC)
 * Per-site configuration for enabling Media Viewer — please do, but as part of beta features. Beta features should be enabled or disabled per-wiki. Gryllida 10:11, 7 March 2014 (UTC)
 * Client-side configuration option to disable Media Viewer — midly tolerable, see also meta:Discrimination against unregistered contributors (pardon my harsh word choice here (suggestions welcome)). Specifically cookie auth section. In my view it should be implemented and enabled with 'Not you? Register an account with a password' warnings as necessary, to have IP contributors access beta features and participate in feedback. Gryllida 10:11, 7 March 2014 (UTC)
 * Per-user configuration for disabling Media Viewer — I'm not sure what this is about. Registered contributors already can do this in beta features. Is this for when it's out of beta, or for unregistered contributors? Gryllida 10:11, 7 March 2014 (UTC)
 * Show shared images in Media Viewer for all users — not sure. Gryllida 10:13, 7 March 2014 (UTC)
 * Zoom feature for v0.3 — I like the idea. Gryllida 10:11, 7 March 2014 (UTC)

Zoom
Hi guys, Based on your requests below, we’ve started design work for the upcoming Zoom feature in Media Viewer.

Here’s a first prototype for your review.

A more detailed [https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/167 specification is outlined here.

What you think? These first designs were prepared by Pau Giner and and Kaity Hammerstein and they’d love to hear your feedback.

Once we hear from you, we’ll start development in a few weeks, and hope this feature can make a lot of users happy! Fabrice Florin (WMF) (talk) 17:07, 28 February 2014 (UTC)


 * Zooming would be useful. --FocalPoint (talk) 16:26, 6 November 2013 (UTC)
 * +1 --Daniele Pugliesi (talk) 06:34, 9 November 2013 (UTC)
 * +1--Saehrimnir (talk) 19:05, 23 November 2013 (UTC)
 * +1 --Stu Phillips (talk) 18:03, 28 November 2013 (UTC)
 * Links to several resolution versions, as exists on the current media page, might be preferable -- see my comments below at . -Pete F (talk) 18:33, 26 December 2013 (UTC)


 * Thanks, guys. Based on your feedback, we are starting work on this Zoom feature, which we hope to include in v0.2, if time allows. Fabrice Florin (WMF) (talk) 09:11, 19 February 2014 (UTC)
 * FocalPoint, Daniele Pugliesi, Saehrimnir, Stu Phillips, Peteforsyth: I filed this bug a while back. You can follow the mingle card or the bug for updates. It'll be out soon :) Keegan (WMF) (talk) 07:37, 27 February 2014 (UTC)

Pre-loading

 * Pre-loading the next image(s) would facilitate the navigation. Currenttly, loading the next image is only done when the next arrow is pressed. Pre-loading is invisible to the user and greately increase the loading perception time. --Pannini (talk) 13:43, 22 January 2014 (UTC)


 * Thanks for this suggestion. We are now working on this feature to preload the next and previous images. Fabrice Florin (WMF) (talk) 09:11, 19 February 2014 (UTC)

Slideshows

 * It could be nice a function to see a slideshow of the images in the same Commons category or in the same Wikipedia page, showing the next image after few seconds. It could be great a tool to create a personalized list of pictures, then see the slideshow and to save it as a .ppt file, so it can be used to create easily and quickly some presentation to use offline (for example by the teacher in a school during a lesson). --Daniele Pugliesi (talk) 06:45, 9 November 2013 (UTC)
 * -1 129.94.239.191 05:54, 10 February 2014 (UTC)


 * Thanks for this recommendation. We have included View files in slideshow mode for the next version v0.3, tentatively scheduled for next quarter. Fabrice Florin (WMF) (talk) 09:11, 19 February 2014 (UTC)


 * -1. Too confusing. It's simple: nobody requested or needs this at Wikipedia or sister projects, and it's getting in the way.
 * When I'm viewing a file at Wikipedia or another sister project, have no arrows.
 * When I click a file from a Commons gallery, it's ok to have arrows or do a slideshow.
 * —Gryllida 00:29, 9 March 2014 (UTC)

Annotations

 * Annotations, for images like File:1911 Solvay conference.jpg. See Commons:Help:Gadget-ImageAnnotator --Jarekt (talk) 19:33, 8 November 2013 (UTC)
 * Is it possible to display the image notes like on commons? --Hans Haase (talk) 01:07, 22 November 2013 (UTC)
 * You probably mean annotations? If so, we have a bug open for that: 56666 --MarkTraceur (talk) 01:19, 22 November 2013 (UTC)

Other features

 * When paging with the arrows trough images on a page, use short css transformations to go from one image to the next. That would give the change less of a 'pop' effect when there are Aspect Ratio changes. TheDJ (talk) 13:47, 14 December 2013 (UTC)
 * -1, annoying 129.94.239.191 05:54, 10 February 2014 (UTC)
 * -1. Adds a wait, as I understand? Gryllida 00:32, 9 March 2014 (UTC)
 * Support for multiple page documents (Djvu, PDF, PPT, etc). For some inspiration you can take a look to the IA Book reader.--Micru (talk) 01:19, 5 November 2013 (UTC)
 * +1, the reader should have as consistent an experience as possible, and having a Media Viewer for some kinds of image files but not others would be confusing. I also agree that the Internet Archive/Open Library people would be great to consult with on this, they have been doing great stuff in this arena with free software. -Pete F (talk) 18:33, 26 December 2013 (UTC)
 * +1, 129.94.239.191 05:54, 10 February 2014 (UTC)
 * Yes please. Gryllida 00:32, 9 March 2014 (UTC)

Some more feedback

 * 1) It takes much longer (10 seconds or more) than normally to load/view an image. Normally i open files in a new tab which is quicker.
 * 2) The date given is wrong. For example "Erstellt am -2147483629. Dezember 1969" (=photo taken december 1969) when you view the photo commons:File:Hattingen - Rathausplatz - Rathaus 03 ies.jpg on Ennepe-Ruhr-Kreis. I don't know from where the media viewer could have taken this information. The photo was made in 2010 see its information template and the exif informations. Holger1959 (talk) 21:32, 7 November 2013 (UTC)
 * This date shown (in December 1969) is in fact 2010 seconds before 1 January 1970 00:00 UTC, which seens to be used like the base date for Unix timestamps (or the  and   API's and similar in standard C language libraries).
 * "2010" alone is not interpreted as a year, but as an Unix timestamp (Unix timestamps are not used in image description page for the date field, dates containing only digits, possibly without any separators as in this case where there's only a year) should be interpreted using ISO parsing rules). Additionally the display format used to render it should not add any unspecified precision (here we just have a year, but NO month, NO day of month, NO day of week, and NOo time of day in hours, minutes, seconds). Parsing should be done like date properties in Wikidata.
 * Verdy p (talk) 20:10, 5 January 2014 (UTC)

Jiggle when resizing the window
Resizing the window (e.g. by going to fullscreen mode) makes the UI jiggle around a bit (Firefox). Skalman (talk) 07:21, 22 November 2013 (UTC)

Hangs my Internet Explorer Browser
I've given up on the Media Viewer, every time I tried to use it, it hangs my browser. Using Windows Explorer 9. Wee Curry Monster (talk) 10:30, 1 February 2014 (UTC)

Scrolling broken in Monobook
In Monobook, the information scrolls up beyond the bottom of the screen (see screenshot). Monobook, Firefox 26, Windows 7 Jay8g (talk) 20:14, 9 February 2014 (UTC)

Link
Hi, the link on images says "Learn more on Wikipedia", but links to Commons. Thanks, Matty.007 (talk) 20:25, 4 February 2014 (UTC)
 * Seems to be fixed, but in ruwiki it requires grammar:prepositional while seems to be grammar:genitive. Ignatus (talk) 19:12, 7 February 2014 (UTC)

Media Viewer bug
Hello, When Media Viewer is activated we can't play a diaporama. I tested it here. 92.89.123.3 12:10, 12 December 2013 (UTC)
 * Thank you for the feedback, I filed a bug for this enhancement here. Keegan (WMF) (talk) 22:56, 21 December 2013 (UTC)

Image resolution, downloads, and license
The media viewer currently does not indicate to the viewer that other (specifically higher) resolutions may exist, or how to download them. Since reuse is an important value of the Wikimedia movement, some useful information about downloads should be available on the main screen. As it currently stands, clicking on "use this file" also does not indicate that there are higher resolutions available; one has to know to click "Learn more on Wikimedia Commons" in order to find them.

To somebody not familiar, "Learn more on Wikimedia Commons" is not a very appealing link -- this is the kind of language that many sites use to link to a very generic "about us" or "about this site" page, not specific information tailored to a specific image (as is the case here). I am concerned that an Internet savvy (but not Wikimedia savvy) audience will completely overlook this highly useful link.

The "CC BY-SA" (or other) license abbreviation looks like a Martian language to most readers. It should be introduced with text like "You are free to reuse this image in accordance with this license" (which should automatically detect when the file is Public Domain, and say something more like "You are free to reuse this image, to which nobody has ownership rights.") Also, this text should probably be next to the "Use this file" link -- the license is currently in a different part of the UI.
 * Some parts of this, but not all, are addressed in v2, available on mediawiki.org. -Pete F (talk) 23:41, 4 January 2014 (UTC)

Personality rights are currently not addressed in the UI. The WMF board and many community members have expressed that it's important for files to indicate clearly, where needed, that the subject has consented to its broad publication. This tool should reflect that desire.

Longtime readers of Commons and other MediaWiki-based sites may be very used to the idea that clicking the image itself brings you all the information available about the file. In this case, once one is in the Media Viewer, clicking on the photo itself does nothing. In order to respect the principle of least astonishment (as an idea, not a policy), this should be altered so that the second click on the photo (i.e., the first click within the Media Viewer) takes one to the expected place, i.e. the full Commons description page.

''The following issue is addressed in v2, visible on Mediawiki.org. -Pete F (talk) 23:41, 4 January 2014 (UTC)'' Finally, a small detail: the "X" used to close the box is in a slightly different place than on sites like Flickr and Facebook. Conforming to evolving design consensus seems like a good idea. On those sites, the "X" is in the upper right corner of the window, not the upper right corner of the image. (Nice to see that the escape key works as expected, though.) -Pete F (talk) 18:13, 26 December 2013 (UTC)
 * addendum This last one might not seem significant depending on what file you're looking at -- I suggest a narrow, portrait-oriented photo like File:Washington County Fair drop ride 3 - Hillsboro, Oregon.JPG. (The dark background also contributes to the difficulty finding the X.) -Pete F (talk) 18:54, 26 December 2013 (UTC)


 * Hi Pete F, we are now developing a brand new version of 'Use this file', which will address many of the issues you raise above. The key specifications for this improved feature are included in these three Mingle tickets:
 * Share this file
 * Download this file
 * Embed this file


 * We appreciate all your detailed suggestions above, and are taking them into consideration. This doesn't mean, however, that we will implement them all. I would be happy to discuss them with you in greater detail in our upcoming IRC 'office hours' chat on Fri. Feb. 21 at 10am PT -- or set up a separate call to go over this, since you have so many ideas that would take too long to respond to individually in this discussion. Cheers. Fabrice Florin (WMF) (talk) 09:11, 19 February 2014 (UTC)

Attribution in a little more depth
It seems like some improvement has been made around attribution since this discussion was started (but it's hard to tell what has changed, I haven't seen any response on this from the dev team?)

As it currently stands, the name of the "author" appears below the file name. This is a good place for it, but in many cases it is not apparent that this is attribution to the author/photographer etc. Many of these will be Wikimedia usernames, which at first glance might not appear to represent a person. We also have readers and authors from many different cultures, so a name is not always recognizable as such.

I'm not sure what the best way to resolve this is, because in some cases "photographer" might be the best title, in others "producer," etc. But it seems to me we have used "Author" pretty consistently on Commons, and it works OK. So I think unless somebody has a better idea, the name should be preceded by "Author: "

-Pete F (talk) 19:20, 31 December 2013 (UTC)


 * Thanks, Pete F. Our current plan is to add a 'By' label in front of the author name, which should clarify that this person is responsible for creating that image, without taking up any more space than needed. This is also consistent with the attribution practices of Creative Commons, and therefore with other parts of our user experience. Fabrice Florin (WMF) (talk) 09:11, 19 February 2014 (UTC)

Transparency
The lightbox doesn't really work that well with transparent images. Might I suggest: or or


 * Thanks for the feedback. I'll pass it along to development and we'll see if it helps. Keegan (WMF) (talk) 20:47, 17 February 2014 (UTC)

Android 4.0.3 and the stock browser
It does not work for me. I use Android 4.0.3 on Asus Eee Transformer tablet (TF101) with the sock browser. The only thing I get is a black and white screen with 2 links - to the about and bugs pages. There's something like the close button (unusable) as well. Kpjas (talk) 10:48, 23 February 2014 (UTC)

Click 'full screen' icon reduces image size
The image is then downsized to a small thumbnail and stays that way even after clicking same icon again to leave full screen mode. I use Windows 7, Chrome 33.0.1750.117, screen resolution 2560x1600 Erik Zachte (talk) 09:38, 28 February 2014 (UTC)
 * +1 (Mac OS 10.9, Chrome Version 33.0.1750.117, Retina Display --Sebaso (talk) 10:50, 1 March 2014 (UTC)
 * I put this into Bugzilla. That's not expected behavior :) Keegan (WMF) (talk) 21:57, 3 March 2014 (UTC)

"more info" drawer
The drawer concept is really nice. But it could be better used: The "more info" drawer should work on mouseover, not on click. "tags" aka categories should be visible without any further action. The link to the commons image should be under title, the link under CCBYSA should link to some kind of "yes, you can use this"-explanation, not to the commons page. --Sebaso (talk) 10:57, 1 March 2014 (UTC)
 * Great feedback. Sebaso. To clarify your last point: As I see it the CC-BY link goes to the .png commons file. You're suggesting it should go to a page like reuse, correct? That would be a good thing to incorporate in some way to the licensing. Keegan (WMF) (talk) 07:41, 4 March 2014 (UTC)
 * yes. but it should be a new page with a claar "invitation to reuse". --Sebaso (talk) 08:28, 16 March 2014 (UTC)

Breaks back button
I like a lot of things about this new viewer. The appearance is better, the ability to click to the next or previous image is great, the quick access to the meta data works well. I'm having a problem though with my back button. After viewing some pictures, the back button in my browser will take me back through the pictures then to the original page, but won't take me back to where I was before I got to that page. Right clicking on the back button and picking from the list still works. I'm using Firefox 27.0.1 on a Windows 8.1 machine. SchreiberBike (talk) 17:20, 2 March 2014 (UTC)
 * Thanks for the report. I filed a bug to see if we can fix that :) Keegan (WMF) (talk) 21:52, 3 March 2014 (UTC)

Thanks for your great feedback!
Thank you all for your wonderful feedback, everyone! Especially Daniele Pugliesi, Cornel24, MarkJurgens, Ainali, Elitre, Micru, Ragesoss, Jarekt, Holger1959, Barcex, Raymond and Julian Herzog, to name but a few. Your detailed feedback is absolutely invaluable to us -- and much, much appreciated :) We are passing on to our development team recommendations to address the issues you raised. Some of these issues were already on our to-do list, but your comments are helping us give these tasks a higher priority. We are now fixing the most urgent bugs, and will be rolling out more tweaks and new features in coming weeks, with our next release due on 21 November, and more updates in December. If you have any more suggestions or questions, you are welcome to post them here, and/or on this Media Viewer discussion page. I am out of office until 19 November, but you can contact our community liaison Keegan (WMF) or lead developer Mark Homquist with any urgent requests. Thanks again for your amazing suggestions, and for all that you are doing to help improve this tool as a collaboration between the community and the foundation! Fabrice Florin (WMF) (talk) 03:11, 12 November 2013 (UTC)


 * Fabrice, can you clarify when you are planning on making the new beta live on Commons and other sites? I think the version there is still "v1"-- it looks very different from the "v2" on this site. Was there ever an update in November / December? Has it been pushed back? -Pete F (talk) 23:33, 4 January 2014 (UTC)


 * Hi Pete F, we push new versions of Media Viewer every Thursday, so all wikis should now have version v0.2. However, the latest version takes a couple weeks to reach all wikis, because we use the 'platform train' that works roughly like this: we test new features on beta for about a week, then new accepted code merged on a Wednesday gets deployed to MediaWiki.org and test sites on the next Thursday, then to Commons and 'sister projects' the following Monday, then to all wikis the following Thursday. So if you want to see the most recent features, check them out on this beta test site (with slow performance) or this test page on MediaWiki.org (faster, but several days later). Hope this helps. Fabrice Florin (WMF) (talk) 09:11, 19 February 2014 (UTC)

Update on Version v0.2
Thank you all for your thoughtful comments about the Media Viewer v0.1! Your suggestions are really helpful to our multimedia team, and we have been acting on many of them already in the new version v0.2 which we are now developing.

Some of your key recommendations have been outlined in this feedback section of our main product page, then turned into concrete action items for version v0.2 and v0.3 on our Mingle project management system.

For example, requests for a larger image size (by MarkJurgens, Daniele Pugliesi, Frank Schulenburg) and a darker background (Ragesoss, Another Believer, equazcion, Daniele Pugliesi, Cornel24, Kelvinsong) have already been addressed in the current version. Concerns about slow image load (by (Mono, Arcane21, Ragesoss, Another Believer, Daniele Pugliesi, Cornel24, Holger1959) have been the focus of a couple development sprints devoted to improving performance in a variety of ways (see #154, #155, #126 or #146, to name but a few possible solutions). We're also taking to heart the many recommendations that we improve the 'Use this file' panel to attribute files correctly, with a quick summary of author, source and license (Amada44, Elitre, Church of emacs, Rsocol): these are being addressed in this new 'Use this file' panel which includes attribution-friendly Embed, Download and other functions. Requests for a Zoom feature are now being designed on this card. Other requests for a pop-up explaining the license terms are now under development (see cards #118 and #197); and we're preparing a whole new batch of features to support slideshows and other file formats, as described in this updated 'Next Version' section of our overview page for Media Viewer.

These are just some examples of how your insights are being incorporated in our release plans. We're also reviewing your longer-term recommendations, which will take more time to implement, but are under consideration nonetheless. Our focus this quarter is on completing the current version v0.2 and starting work on the next version v0.3 of the Media Viewer, to provide a better viewing experience for all users.

Sorry if we haven't been more responsive on this page in recent weeks: we have all been busy improving the product, based on your earlier feedback. In a few days, we will invite your comments on an updated beta version v0.2, which we are about to release shortly. As that date approaches, we will start archiving many of the comments above which have been addressed, to reduce clutter and to invite us all to focus on the new features and improvements. To keep up with our work and participate in our conversations, we also invite you to subscribe to our multimedia mailing list. And if you're feeling adventurous, you can test the latest features before they are released, on this beta site, but performance will be much slower on that site (you will also need to create an account, then enable Media Viewer in your Beta preferences).

Thanks again to everyone who has already contributed so productively on this page: keep your great insights coming! Keegan, MarkTraceur, other team members and I will do our best to answer your questions (for a faster response, you are welcome to mention our user name in your comments, so we are notified and can get back to you more quickly). But even if don't always respond right away, rest assured that we are reading your comments and considering every suggestion carefully. :) Fabrice Florin (WMF) (talk) 21:35, 9 February 2014 (UTC)


 * Thanks! A half of my suggestions weren't there. I've added them in. --Gryllida 05:55, 10 February 2014 (UTC)
 * I'm particularly surprised that 'make preview bigger' and others are on the list, while I didn't expect it to occupy the whole page. Previously the preview shown on image click (without media viewer) was rather small. Having a small preview benefits the reader as he sees that he did not leave the article and didn't enter a weird new full-screen app. Some might think was "was I hacked?" or "where did I come?". --Gryllida 06:04, 10 February 2014 (UTC)


 * Thanks, Gryllida. We're reviewing your suggestions and will respond to them once we've heard from team members. As a rule of thumb, we tend to implement features which are requested by large number of users, rather than individual requests by a single community member. For example, I understand you are a big proponent of a proposed 'Preview' function, though I'm not hearing this as being a priority feature from other team or community members. I should also point out that this proposal doesn't match best practices on other top multimedia sites we've been studying for this upgrade. So I am not optimistic that this particular feature would be implemented in the near-term, though we will give it careful consideration for future releases. On the other hand, I'm happy to let you know that we plan to implement other features you are advocating, such as making the link to the file repository more prominent, as well as support for multiple page documents. Thanks again for your interest in this project. Fabrice Florin (WMF) (talk) 01:03, 11 February 2014 (UTC)


 * It'd be interesting to learn that websites have a best practice of ... occupying a whole page with a preview, with black non-transparent background. I'll watch the presentation, expect it to be interesting. :-) Again thanks for the detail. Gryllida 05:45, 11 February 2014 (UTC)

Towards enabling the Media Viewer by default
It appears likely to me that, whenever the time comes, enabling the Media Viewer by default will be rejected by the Wikimedia community, for reasons deriving from our shared vision for all people to freely share in the sum of all knowledge. I think that would be unfortunate, considering all the good work that has gone into it, so I'd like to point out the high-level issues I see. I hope Fabrice and the engineering team will take a step back as well, and consider adjusting feature priorities accordingly. (Maybe this is already part of the plan; but recent communications make it appear that it's getting missed.)

According to the engineering team, the Media Viewer aims for three goals:
 * Provide a richer multimedia experience
 * Display images in larger size
 * Reduce confusion

These are worthy goals, and I'm sure all serious Wikimedians would support them. When the question gets raised, though, of whether to replace the current default view with the MV, less lofty considerations will come into play: does this new feature sufficiently meet the basic requirements already, more or less, met by the current default view? I think the answer is a decisive "no," and am skeptical about whether the apparent plan for refining the Media Viewer will change that.

What requirements am I talking about? I would summarize them as follows:
 * 1) Are all copyrights and personality rights adequately protected?
 * 2) Have we met the minimum legal standard?
 * 3) Have we met the expectations of rights-holders sufficiently that they will feel good about contributing to Wikimedia projects?
 * 4) Are (potential) reusers shown a clear path forward?
 * 5) Are they given sufficient guidance in overcoming practical obstacles to reusing materials presented by the Media Viewer?
 * 6) Are they given sufficient guidance in meeting relevant legal obligations?
 * 7) Are they given sufficiently convenient access to the right links, including a file download link?
 * 8) Have we appropriately exposed the strengths of Wikimedia Commons to our users? For instance:
 * 9) Commons provides strong assurances that all its content is freely reusable, with minimal requirements, unlike Flickr and other repositories. Is that expressed clearly?
 * 10) Commons is more organized than media repositories like Flickr (eg, category system).
 * 11) Commons invites anybody to contribute materials that serve its educational mission.

While my list above may or may not be complete, I am pretty sure it more or less reflects what most Wikimedians will have in mind, when considering whether or not the Media Viewer should be enabled by default. Whether the Media Viewer has exciting and worthwhile new features is certainly important, but it is subordinate to meeting the minimum standard of reflecting our shared values, at least as adequately as the current default media view does.

Current efforts to refine the Media Viewer seem (to me) to be missing the significance of these basic considerations. I would expect that, unless the engineering team prioritizes feedback relating to basic adequacy (reflected, more or less, by my numbered list above) more highly than feedback about improving functionality, the Media Viewer will not (and should not) be approved as a default feature by the Wikimedia community. -Pete F (talk) 04:36, 16 February 2014 (UTC)


 * I'm not a developer of this project, but do know quite a bit about it where it's coming from and I can tell you that at least the first consideration is high on the visibility list of the team. HOWEVER. it is also the most difficult problem to solve and requires a lot of technical work. This work is taking place, but it is not directly visible to most users. This frontend is using a new API to get the information that you are pointing out, and that will be developed specifically to meet these goals. BUT there is still a lot of work to do there and in the way we register licenses and copyrights of files. This project is being used as the driving force to develop this new API. I too would suggest not to enable this for ALL anonymous users until that goal is met, but having it as beta will help garner the feedback that is required to develop the backend systems for license/copyrights/authors.


 * I have recently met this team and I have great confidence in them. But I too support your statement that the team needs to watch out for the above concerns. Especially the Commons and top 5 wikipedia projects are sticklers for correctness when it comes to legal requirements and EDUCATING users regarding licensing. These aspects need to be extremely well thought out and balanced, so any development would at some point have to be validated against these basic community principals. TheDJ (talk) 11:40, 17 February 2014 (UTC)


 * Hi Pete F, thanks again for your thoughtful recommendations above, which we are reviewing. We are now hard at work on addressing the first two points you raise above about copyright protection and appropriate tools for re-users. Regarding your third point, Media Viewer already links to Commons in many places, and we will consider making those links even more prominent, while still aiming to reduce confusion for users. We would be happy to discuss your advice in greater detail in our upcoming IRC 'office hours' chat this Fri. Feb. 21 at 10am PT -- and am also open to a separate call to go over this 1:1, if you like. Thanks again, and regards as ever. Fabrice Florin (WMF) (talk) 09:11, 19 February 2014 (UTC)


 * Thank you both for your thoughts on this. @Fabrice, I appreciate your offer to chat and am happy to if the opportunity presents itself -- but it seems to me at the moment that there's a need for public consideration about the high level goals and impacts of this feature. So for the moment let me add a few thoughts here:
 * On copyright, I think there is room for improvement beyond the minimum legal requirement, to ease the process of Wikimedia volunteers advocating to content owners for CC licensing. My bigger concern, though, isn't copyright, but personality rights. There has been a great deal of discussion lately about the way we (don't) deal with personality rights, and related software features. For instance, @Sj, a WMF board member, recently suggested adding a feature to the upload wizard to gather information relevant to personality rights. If this Media Viewer were to get presented as a complete feature to the community without any regard to personality rights, I think that repeat a mistake that was made in 2010 when the Upload Wizard was released. Hopefully it's possible to do better this time.
 * As for reusers, I think a good number of suggestions have been made above, but it's not clear to me that they have been given strong consideration. (Perhaps they have, it's hard to tell for sure what you consider high priority and what you don't.) But to me the most glaring is that when one clicks "use this file" there is no link to even get the file -- that is, no download link. (Also, "use this file on another web site" provides a pretty specific HTML link, which is not what's needed on many modern web sites like Facebook or Wordpress -- a simple link to the file is much easier to use in those cases, but is not made prominent in the beta Media Viewer.)
 * As to showcasing the strengths of Wikimedia and Commons, this is a much more nuanced issue than simply the number of links. Again, I think good suggestions have been made above; I'm not looking to rehash them all here. But I don't think you're likely to get to the right solution if your main criterion is how many votes each suggestion gets. -Pete F (talk) 17:17, 22 February 2014 (UTC)

Hard to scroll for the more detail (i'm missin a queue)

 * With the newer layout, where you need to scroll below the 'fold' to read the more information, i'm missing a queue that this is an action I should take. My mac doesn't draw scrollbars, unless I'm scrolling, so i'm not being visually informed of the presence of this information, and even if i put scrollbars to render always, it's still not very visible. Suggest downward facing arrows somewhere in the bar above the fold to indicate that there is more content, i need a queue to be made aware of this 'pagination' action that is expected of me. TheDJ (talk) 18:11, 26 November 2013 (UTC)
 * I think adding a "View more" button on the bottom right of the bottom toolbar, which would automatically scroll you down, would work well. I agree that this isn't very obvious right now. --Nicereddy (talk) 01:39, 3 December 2013 (UTC)
 * What queue? —Gryllida 10:05, 7 March 2014 (UTC)
 * I meant cue. TheDJ (talk) 20:56, 7 March 2014 (UTC)
 * OK, I support this idea. The additional details should be more prominent in some way. Gryllida 00:34, 9 March 2014 (UTC)
 * Noted, thanks for the input. We'll see if there's a different design for that. Keegan (WMF) (talk) 01:29, 12 March 2014 (UTC)
 * I like it...though as The DJ said if you don't have a scrollbar it's not really obvious. Though it's not a problem for me.

Title of image should link to information page (and license should link to license details)

 * Title of image should link to information page, Copyright title ("CC BY-SA 3.0" for example) should link to information on what that specific license entails. Even better would be if, when clicking the copyright license title, a simple dialog appeared describing what the license permitted. Currently, the license links to the image's dedicated wiki page and the title of the image does nothing. Personally, I think this is confusing for the common user. Image showing what part I'm referring to (imgur link because I didn't want to go through the trouble of uploading to Wikimedia, apologies): http://i.imgur.com/4RTPayo.png --Nicereddy (talk) 02:28, 3 December 2013 (UTC)
 * Agree with the title idea. —Gryllida 10:05, 7 March 2014 (UTC)
 * +1--Sebaso (talk) 08:29, 16 March 2014 (UTC)

Mention partnership

 * On the Media Viewer, images uploaded by partners (GLAM for example) or during a partnership do not have a visible mention of the partnership. The uploader may not be the partner (upload by a bot) And nobody will click on the "Learn more on Wikimedia Commons" link to see if a partner uploaded it or released it. Trizek (talk) 13:42, 18 December 2013 (UTC)
 * An ok idea. Gryllida 10:05, 7 March 2014 (UTC)
 * Thanks. This has been brought up recently by email as well. We're exploring ways to denote partnership contributions. Keegan (WMF) (talk) 01:31, 12 March 2014 (UTC)

Touch screen image swipe
Also, the 'x' seems a little too small to touch on a phone. It takes me a few attempts to close the window. MarkJurgens
 * Touch screen image swipe would be a great feature on mobile devices! The < > arrows are small on a phone. (Until Apple makes a bigger screen for me)
 * +1 Gryllida 10:05, 7 March 2014 (UTC)

Caption or title at the bottom?
I would have thought that the title of the image is less useful than the caption that was there before the image was enlarged. Particularly for a scientific article, the cation often annotates features of the image. This would be a genuine improvement over the old system whereby you could either look at the caption or the enlarged image but never both at once. Evolution and evolvability (talk) 11:42, 9 December 2013 (UTC)
 * This could be a nice enhancement, Evolution and evolvability. I've filed a Bugzilla enhancement request. You're welcome to create a Bugzilla account and track it! Keegan (WMF) (talk) 07:29, 27 February 2014 (UTC)

Nice first steps, but needs a lot of work
My initial thoughts after using this for a little while: --Rotane (talk) 00:03, 28 February 2014 (UTC)
 * Desperate need for a throbber. When i click on an image i get a black window with a small white area below it, for quite a while. Not even the browser's favicon does its loading-animation!
 * The 100% black could be toned down a bit, made a bit transparent, so you get to see the underlying page (look at the facebook viewer). This gives people the feeling that they are still on the same page, not taken to some other place.
 * Added to that, give the images a bit of breathing space, and if it's only 10px on either side. Right now there is no sense of style to the viewer.
 * The clickable area of next/previous is far too small. Again, look at facebook: pretty much the entire image-area brings you to the next one. Granted, it's not as important here, but at least you could make the entire right/left edges of the screen clickable. Likewise, clicking on the transparent black background closes the viewer. All of this is very convenient.
 * Great feedback, Rotane, thank you. Most of these enhancement notes are in the works. Keep an eye out for updates! Keegan (WMF) (talk) 05:25, 5 March 2014 (UTC)

Details format
Some comments about the details section of the viewer:

-- NaBUru38 (talk) 03:46, 28 February 2014 (UTC)
 * I like the overall style: white background, grey boxes, black text, blue links. A small change could be to link the author name only, not the whole like.
 * The grey icons are way too small to be readable. It's like the recent Gmail and Yahoo interfaces, those icons are completely useless. They would be easier to recognize if they were coloured (like the 1990s MS Office) or huge. Both things would ruin the interface. Anyway, each line has a decent description, so there's no confusion at all about what each line means - except with "tags".
 * I don't think that the "used in X pages" section is useful for readers.
 * NaBUru38, we appreciate your time to look over Media Viewer. It's good to hear you like the style. How you would suggest to stylize the icons is quite helpful. And as always, the content to contain in the viewer is something we're constantly evaluating with each design to make sure we're displaying what's succinct and important for media use and reuse. With input like this we can work toward community satisfaction. Stay tuned. Keegan (WMF) (talk) 05:29, 5 March 2014 (UTC)

Share to Social Media

 * I would love if I have the buttons to click and share the media easily to twitter or Facebook. Moreover it took a little time to load for the first time. --Jayabharat (talk) 04:12, 28 February 2014 (UTC)
 * That has proven to be controversial on English Wikipedia. Several proposals to add share buttons have been made, but the community falls roughly 60/40 against such an addition. If social media integration was a built in feature with Media Viewer, there are segments of the Wikipedia community that would view it as the Foundation bypassing the consensus process and ignoring the wishes of the English Wikipedia community. Of course other projects feel differently, but it's certainly not a change I'd make without having a conversation about it with the projects that haven't adopted social media integration. Sven Manguard (talk) 01:21, 1 March 2014 (UTC)

I heard that social media integration is problematic because of the way share and like buttons work, namely because of privacy issues that might be against the Wikimedia privacy policy. I'm not a legal or technical expert though, just have rad this several times, also when the topic came up on huwiki, this was the reasoning against it. Teemeah (talk) 14:09, 3 March 2014 (UTC)
 * Yeah, it's a common argument, but also somewhat flawed. They can be implemented in a way that would avoid the privacy problems, it's just that most websites don't care about your privacy. The problem is usually more that people think it is a form of 'sponsoring' commercial platforms. (I don't really get it, since we do the same for maps, but whatever). TheDJ (talk) 19:51, 3 March 2014 (UTC)

Better Font or bigger size for description
For images with large description, the scroll-bar gets enabled. I don't know why, but it doesn't feel great to scroll and read in that box. For example, you may try :. --Jayabharat (talk) 04:12, 28 February 2014 (UTC)

I agree I might find the text too small. My operating system has a high "DPI" setting with 16px font in all menus, which does not reflect on the media viewer. It's also not exactly black. It seems quite difficult to read. —Gryllida 09:59, 7 March 2014 (UTC)
 * Seconded. Please stick to the standard font size.  I noticed this with Flow designs recently as well: please don't make any fonts smaller than the current default, unless the goal is to hide that text. (Such as user-selected superscripts or subscripts or hidden divs noting an ignorable aside.) Sj (talk) 01:15, 15 March 2014 (UTC)

Orientation (or lack thereof): Needs more user awareness of Commons (and what a sister project is)
It is really really hard to understand where the file is. Keep an equivalent of "This is a file from the Wikimedia Commons. The description on its description page there is copied below." somewhere below the image please, before I scroll. —Gryllida 10:01, 7 March 2014 (UTC)
 * I really don't agree with this. I think the average person really couldn't care less about 'organizational' details like that. The difference between wikipedia's and Commons communities is our problem. A problem that we created ourselves. We shouldn't bother others with it too much. Once they get into the community they will notice soon enough. (i'm sure one of our communities will give them a scolding one way or another). TheDJ (talk) 20:54, 7 March 2014 (UTC)
 * TheDJ, What worries me is that in my view the architecture of the Wikimedia movement should be as clear to end users as possible. It took me 2 years to learn what sister projects exist, and to fully understand their role (and role of the WMF). I wouldn't actively promote such idea, but I do dislike when steps are taken which are a regression, removing some information which was available before. Gryllida 00:37, 9 March 2014 (UTC)
 * Right, I get what you're saying. Our end goal is to provide an accessible and positive way to lead someone to the original file hosting on Commons. Once on the Commons file page, it's up to Commons to make it clear what the site is for. I don't think that's something we can promote with Media Viewer to the level that actually fixes a problem that might exist due to other problems in movement communication. Keegan (WMF) (talk) 01:17, 12 March 2014 (UTC)

Feedback on Opt-out Feature
Our goal is to enable Media Viewer by default on all wikis when it the tool is ready. But as recommended by many in this discussion, we would also like to provide a way for users to disable Media Viewer on a given site, so they can opt-out from this feature if they don't want it (see Mingle card #264).

To that end, we are considering these different options:

Provide a preference checkbox with Media Viewer enabled by default (e.g.: 'Show images in Media Viewer'). To disable MV, users can uncheck this preference.
 * A. 'Enabled' user preference:
 * Pros: preferable from a UX point of view, indicates this is our recommended option, more user-friendy than JS gadget option below
 * Cons: this approach has caused problems before, users may not want this option to be selected for them, adds to preference bloat issue

Provide a preference checkbox where Media Viewer can be disabled (e.g.: 'Disable Media Viewer'). To re-enable MV, users can uncheck that preference.
 * B. 'Disable' user preference:
 * Pros: addresses user concerns about pre-selection, more user-friendy than JS gadget option below
 * Cons: unclear what Media Viewer is, confusing because you have to uncheck the preference to re-enable Media Viewer, adds to preference bloat issue

Provide a site-wide gadget (or personal JS script) that would let users disable Media Viewer.
 * C. Javascript gadget or script:
 * Pros: no preference bloat, no cache fragmentation, can simply ride on #263 and provide example JS code.
 * Cons: not user-friendly (the gadget has to be installed manually), the bootstrap script would still get loaded.


 * Notes:
 * If we implement a user preference, the recommended location would be in the 'Appearances' section, under 'Files'.
 * We should also let power users know that they can easily use Ctrl-click or Shift-click to bypass Media Viewer and access images the same way they used to before this feature was introduced. So even with Media Viewer enabled, there are shortcuts you can use to go directly to Commons if you like.

We would appreciate your advice on which of the options above would be most helpful for the majority of our users. Please add and sign your comments below. Thank you! Fabrice Florin (WMF) (talk) 00:07, 8 March 2014 (UTC)


 * Comments:


 * I hope you go for A. Just unchecking a box if you don't want the feature is very small trouble and only need to be done once. --Ainali (talk) 07:04, 8 March 2014 (UTC)
 * A or B. Gryllida 00:20, 9 March 2014 (UTC)
 * A or B. Gryllida 00:20, 9 March 2014 (UTC)


 * Suggestion 1 (from Gryllida)
 * Move the 'About' and 'Feedback' links up for them to be visible before scrolling; add pretty icons; create a local About page.
 * Provide a 'About' link on the media viewer itself, in one of the corners, before scrolling. Should open a dialog or a page which explains where files are hosted, what media viewer is, and how to toggle it in favour of what exactly (i.e. going to file page at Commons directly)
 * Pros: Easy to locate; no confusing additional 'Media Viewer' term initially (users don't need to care of names directly (although mw:Multimedia/Media Viewer may be linked to from the dialog)).
 * Cons: ?
 * —Gryllida 00:20, 9 March 2014 (UTC)


 * Suggestion 2 (from Gryllida)
 * Wherever suitable, take user to a relevant highlighted pref in special:preferences with a 'back to article' link next to it.
 * Example: A web search engine preferences interface:
 * [[File:DDG_Pref_link.png]]
 * —Gryllida 00:20, 9 March 2014 (UTC)