Extension talk:Media Viewer/About

Feedback on Links to Commons






Many folks have raised concerns in our various discussions that the current link to Commons is not prominent enough to help power users go to Commons — or to make new users aware of what Commons is. Right now, that link to the Commons file info page is located below the fold, at the top of the right column in the meta-data panel; the current label is “Learn more on Wikimedia Commons."

As recommended by many in our onwiki, email and IRC discussions, we have been exploring different ways to make this link to Commons more prominent, as outlined in this Mingle card #270.

This link is trying to solve the needs of two very different user groups:
 * Advanced users need a quick link to edit the Commons description page and perform other related editorial tasks for that image.
 * New users want to know more about the image, and also need information on what Commons is and why they should go there.

To address these issues for each user group, we are considering different design solutions, prepared by our designer Pau Giner:

A. Simple 'Edit’ button: Provide an ‘Edit’ tool above the fold, so that advanced users can quickly go to the Commons description page to edit it. Restrict this to logged-in users only?
 * Pros: gives editors a much-needed edit tool, in a compact format that is easy to understand (pencil icon), making it easier for them to do their work
 * Cons: readers could get confused by this tool, which takes them to a completely different site (so we may want to not show it to them at all).

B. 'Edit’ button with tooltip: Provide the same ‘Edit’ tool above the fold, but show a tooltip on hover, to explain to new users what it does. Show the edit tool to everybody.
 * Pros: gives editors the same useful, compact tool, to help them do their editing work quickly
 * Cons: readers should like the tooltip, but it may annoy some editors (don’t show the tooltip to advanced users?)

C. 'More details on Commons’: Provide a call to action inviting new users to check more details on Commons, explaining what it is and how to get there. Shown below the fold, after key details.
 * Pros: Clarifies what Commons is and why users might want to go there: to get more details and share free media. Larger panel makes it easier to find.
 * Cons: Below the fold position means many users will not see it. Consider using it in combination with Options A or B above?

We would appreciate your advice on which of the options above would be most helpful for both new users and power users. Note that we may want to use some of these design ideas in combination (e.g.: Option B + C), to offer different solutions to meet the specific needs of each user group.

Later this week, we will ask your advice about adding a button on Commons to open an image in Media Viewer. Thanks as always for your constructive advice — and speak with you soon! Fabrice Florin (WMF) (talk) 23:46, 10 March 2014 (UTC)

Comments


 * I would perhaps prefer C, as other options expect user to be interested in editing. They are often not. Gryllida 09:21, 11 March 2014 (UTC)
 * I think that a combination of B and C is the best solution: an edit button for advanced users that leads directly to commons without scrolling needed with a small explaining tooltip (that is, imho of power user, not annoying) and a "More details on Commons" area for readers that are looking for all metadata of the file. Tpt (talk) 18:31, 11 March 2014 (UTC)
 * I'd like to vote for a combination of B and C, too. It's easier for power user to look after a link toward Common. B will give the instinct help for others. --Fantasticfears (talk) 13:27, 12 March 2014 (UTC)
 * B is important.  I agree that B and C are independent; C would also be useful. Sj (talk) 01:10, 15 March 2014 (UTC)
 * A is mysterious, B and C can both be useful (with some tweaks to the confusing wording of the text). None solves the problem of giving a link which is visible (rather than outside the screen) and actually seems a link, let alone a link to where the file actually is. I still have no idea why the file title would not be a link, as seems most obvious; the pencil icon can convey part of the meaning/satisfy part of the use cases; for the others, if for some reason we're forced to use an icon separate from the title, perhaps the clearest icon possible is a "permalink" icon, a variant of the chain kind I suppose (permalink is a concept known in most websites). --Nemo 12:15, 22 March 2014 (UTC)
 * Agree that none are ideal -- agree that this information should be more prominent. Gryllida 11:36, 16 April 2014 (UTC)

Location maps
OK, somewhat complicate to detect and work with, I'm sure, but due to the discussion about maps, I noticed that the MMV doesn't really like locator maps. Take for instance en:Template:Location_map+ and for instance the example on en:Template_talk:Geobox/test1. These are common use cases in the Wikipedia's, and the code should be able to at least do something predictable with them. (instead of showing the overlays in separate views). TheDJ (talk) 08:21, 7 March 2014 (UTC)
 * I've filed this as an enhancement bug request since it might be difficult to accommodate. Thanks, TheDJ. Keegan (WMF) (talk) 19:26, 12 March 2014 (UTC)

Remove the arrows and view of other images in the article
Quite often an article has images which are not representative of the subject, alone, and without a relevant clear label, clicking the arrows is confusing. With old system, I didn't miss this feature, and with the media viewer, I don't use it, but it occupies space and gets in the way.

It's simple: nobody requested or needs this at Wikipedia or sister projects, and it's getting in the way. —Gryllida 00:29, 9 March 2014 (UTC)
 * 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.


 * Totally agree. There's a template for climate that has some icons, those icons are shown as if they are related to the article on the viewer.--Pertile (talk) 21:54, 17 March 2014 (UTC)
 * I disagree, if I am looking on a gallery in an article on Wikipedia, the arrows are extremely helpful and save me a lot of clicks. Please keep them. --Ainali (talk) 11:29, 18 April 2014 (UTC)
 * Yes, if you're looking at a gallery in a Wikipedia article, fine. I totally support a better Media viewer for article galleries! But what is the point of clicking through to this: https://en.wikipedia.org/wiki/Walvis_Bay#mediaviewer/File:Namibia_location_map.svg ? And how do you get back to the point you were initially reading in the article?
 * Re: "nobody requested or needs this at Wikipedia or sister projects", the Media viewer risks turning Commons into a dead place. In french and german Wikipedia, now, you are directed to commons immediately when you click on a picture, this traffic will disappear. Nobody (except Wikimedians) clicks on the tiny commons symbol at Media viewer, that's just an alibi. Actually the media files in the commons category for the article should get more prominence, should become more accessible for readers, but the Media viewer will lead to the opposite: Wikipedia readers no longer visit and see Commons and commons categories. --Atlasowa (talk) 13:57, 30 April 2014 (UTC)
 * IMO creating artificial traffic on Commons by forcing the user to go there just to get a decent look of the image was a bug, not a feature. But anyway, I don't see how this is related to having the prev/next arrows. According to the statistics, on average people look at about 2.5 images per lightbox session, so the prev/next feature does get used a lot. (Note that everything down from "metadata open" on that chart is not actually measure yet so those numbers are not real.)
 * And how do you get back to the point you were initially reading in the article? -- you should be able to do that simply by exiting MediaViewer. If that does not work, could you describe what exactly happens? --Tgr (WMF) (talk) 19:14, 30 April 2014 (UTC)

Please do not go full screen
Please don't go full screen. It's confusing as the reader doesn't understand that he/she is still on the same site. I included a drawing of what I would expect instead. Gryllida 00:25, 9 March 2014 (UTC)
 * Hmm, interesting. Thanks for the mock-up. Keegan (WMF) (talk) 19:11, 12 March 2014 (UTC)
 * I agree. This is the only place in our interfaces where your screen and menu bars are overwritten, and you have to find and use a small "X" in a corner to close the screen you landed on.  I'm not particularly keen on that design, but most of all it's inconsistent.  If we start using "click X to go back" in lots of interfaces, readers may get used to it.  For now, I would suggest not creating overlays that make the standard nav stop working.  Sj (talk) 01:13, 15 March 2014 (UTC)
 * +1 the black background after the first click on the image could be "nearly fullscreen", but you should see the article page on the edges behind the media overlay. (unkess the users clicks "full screen".--Sebaso (talk) 08:35, 16 March 2014 (UTC)


 * The intent of media viewer is to give images space to be viewed, understood and enjoyed. This mock-up displays the image at the same size as the image in the article, making it a metadata pop-up, not a media viewer. I think there's something to be said for metadata pop-ups, but they're more useful as a delayed hover action rather than a click action which is an affirmative step to get a larger view. See Beta Features/Hovercards (which is inspired by the navigation popups gadget) for ideas in the direction of surfacing relevant information on hover.--Eloquence (talk) 05:51, 16 March 2014 (UTC)


 * I love the option to go full browser width (on galleries) or fullscreen --Subfader (talk) 13:24, 16 March 2014 (UTC)
 * I would perhaps consider having a "default to full-screen" tick box, and a "go full-screen" button, on a metadata pop-up. Otherwise it's really difficult to match a user's expectations: he/she expects to see something more about the image while stay on an article, and going full-screen directly doesn't meet such expectation. Gryllida 00:14, 30 March 2014 (UTC)
 * One would think that is the user expectation and experience, but it turns out that it is not :)
 * There are some fundamental problems from the user experience standpoint to make the image not go full screen in Media Viewer. The most prominent is a user figuring out the controls and how to exit the viewer. When presented with a pop-up style box for an image there is not a clear expectation of how to close the viewer. However, when we make Media Viewer full screen, users find it much more navigable and a much more pleasant media viewing experience overall. It becomes a much more immersive experience, which is what we want out of the Media Viewer. A full screen display of some sort is the standard experience on most of the other major sites as well, including Google Images, Facebook, flickr, for instance. There are more examples.
 * Overall providing a full screen for Media Viewer accomplishes the goal of a rich viewing experience as well as the clarity of control and ease of exit in functionality. Pop-ups do not provide this necessary functionality as well as the full screen. Keegan (WMF) (talk) 16:51, 1 April 2014 (UTC)

Sj, if you have some time you might be interested in watching two of the design sessions where the current X/close for Media Viewer developed from in part: Design session #5 and Design session #10. Even in the early prototypes users were able to identify and execute how to close the viewer. There's some great other design tidbits in there as well (thanks, Pau!). Keegan (WMF) (talk) 21:00, 1 April 2014 (UTC)
 * Hello Keegan, thanks for the deeplinks! That's cool to see.  Though I'm not convinced that this implies 'full screen improves clarity of control', and I wouldn't describe "almost-full screen" as a "pop-up".  As for immersiveness: I'd feel less trapped by the current design if there were more & clearer interactions available... clicking on the image, showing sets of related images, clicking outside the image.
 * Re:examples of full-screening on other web sites:
 * Facebook makes the background semitransparent: you can still see the page behind it. With a large screen, you can see the full FB border-interface you are used to.  And clicking on the background outside of the image takes you back to where you were.
 * Google Images doesn't quite go fullscreen: it expands to the width of the screen but above & below you can see you're still in the screenful of image search results.
 * Flickr doesn't really have a "non-Image-viewing" core function. However, every major Flickr-page that might take you to an image-focus page is linked prominently "above the fold": a link back to the user-page of the uploader, and any album it's a part of.
 * Regards, Sj (talk) 02:54, 2 May 2014 (UTC)


 * Comment I find grabbing the full browser width on video content really annoying. Take a look at this Wikinews article from February, or this far-older example from back in October 2009. Closing the viewer for a still might-well be appropriate, but this is multimedia content a user may wish to have running whilst reading other parts of these articles. --Brian McNeil (talk) 13:08, 14 April 2014 (UTC)
 * Comment Could an option be to make the black background slightly semitransparent, so you could still view the article? And that clicking the background would close the modal? Danmichaelo (talk) 10:13, 27 April 2014 (UTC)
 * +1 (per FB as well) Sj (talk) 02:54, 2 May 2014 (UTC)

Accessibility
I was just realizing that due to the lightbox nature of this project, it's really important to do at least the minimal amount of accessibility testing with screen readers on this feature, before it is released. I'm sure screen readers don't naturally understand overlays like this and need some ARIA love. This feature is also going to be on every page, and seriously affect the experience of people with assistive technology. TheDJ (talk) 07:40, 7 March 2014 (UTC)
 * Accessibility is always an important consideration; the blurred image while loading can be controversial for those with visual impairment, for example. We'll take screen readers into account. Keegan (WMF) (talk) 19:12, 12 March 2014 (UTC)

With the latest https://www.mediawiki.org/wiki/Talk:Typography_refresh#Latest_release all hints (icons, frames) around pictures disappeared - so now its really hard to understand that you can click on pictures for a larger version/more information. --Sebaso (talk) 08:55, 16 March 2014 (UTC)

"Collection"
What is a collection? was mentioned in 5383 but only links a page now redirecting to this page, which doesn't explain the term despite using it twice. I didn't find an explanation in this talk either. --Nemo 08:07, 11 March 2014 (UTC)
 * Hi Nemo. I archived and redirected the other talk page last week so we don't have split communications. You can find the archive linked at the top of this page :)
 * The relevant section seems to be this one. It seems that a "collection" is synonymous with a "gallery" in this context. Keegan (WMF) (talk) 18:16, 12 March 2014 (UTC)
 * Thanks for your question, Nemo. In our design work for Media Viewer, we have been using the word 'collection' as a generic term to describe any group of media files which could be displayed in a sequence in the Media Viewer. For example, all images or media files in an article can be viewed as a collection; so can all images in a gallery, or a category -- or even a PDF slide show. We aim to provide a consistent user interface for interacting with such collections, regardless of their specific forms. Here are our first design slides, which illustrate how we envision this collection user interface to work. And here is a first development ticket for a collection navigation strip, one of the core components of this UI. We plan to start this development work in late spring or early summer, once we are caught up with other high priority tasks. Hope this helps. Comments welcome. :) 07:52, 13 March 2014 (UTC)
 * Was this new terminology documented somewhere? Please avoid using undocumented jargon. --Nemo 15:24, 31 March 2014 (UTC)
 * I'm still looking for a dictionary to understand the multimedia team efforts. Thanks, Nemo 11:38, 16 April 2014 (UTC)

Scrolling problems
I have noticed two problems when using Media Viewer. Screenshots can be produced if desired. I am using the latest version of Safari for Mac.


 * When scrolling up to reveal the lower portion of the image label, the label goes behind the image for a moment, before jumping to the front as it should be.
 * After using the fullscreen view and then returning to regular view, I am able to scroll the label so far down that it is not shown at all. It can also be scrolled back up onto the screen.

Very nice work overall. JamesDouch (talk) 09:24, 13 March 2014 (UTC)

Discuss this image
Firstly, lovely work on the viewer: it is a much better viewing experience, and will be simply great for browsing as well once you can see related files, like the category boxes at the top of old-style Commons pages.

A link to the Commons talk page would be useful. People often need a way to leave a comment about an image. A link in the main metadata saying "Discuss this image" or "Discuss" may do the trick.

Else readers may edit the description field for lack of a more appropriate link :-) Sj (talk) 01:18, 15 March 2014 (UTC)


 * Dear Sj: Thanks so much for your kind words about the Media Viewer, which mean a lot to us :)


 * We're already considering adding 'Discuss this file' for the next release, as outlined in this Mingle ticket #225. I'll ask Pau what he thinks about including it sooner.


 * In the meantime, we are including two features to make it easier for folks to access the Commons page:
 * Edit this file - #206 - above the fold, for power users (see mockup thumbnail)
 * Prominent link to Commons - #207 - below the fold, for new users


 * So for now, either of these tools will provide an easy way for people to join discussions on Commons. Fabrice Florin (WMF) (talk) 01:27, 18 March 2014 (UTC)

Upload a new version
This is a useful link on current Commons pages. Please include that in this design. This can be shown to both logged-in and logged-out users; the logged-out users simply need to sign in first. (Compare how the mobile site encourages edits even if you're not logged in, but gets you to log in en route to making the edit). Sj (talk) 01:18, 15 March 2014 (UTC)
 * hmm, i don't think we should just slap a button/link in there. Contribution workflow is important, but mobile also started with reading before taking on more complicated problems. TheDJ (talk) 15:11, 15 March 2014 (UTC)


 * Yeah, this needs to be thought through in the context of the overall contribs flow.--Eloquence (talk) 05:56, 16 March 2014 (UTC)

See full resolution / multiple resolution links
Large images are thumbnailed. On the old description page, clicking on the image or on a "full resolution" link would take you to it. In addition, a number of thumbnail resolutions are offered.

These are important options for reusers. Sj (talk) 01:19, 15 March 2014 (UTC)
 * Fullscreen is in the works. I'm not sure at the moment if this includes full resolution. Fabrice? Keegan (WMF) (talk) 04:49, 16 March 2014 (UTC)

We have a fullscreen feature (I don't think there are any pending parts), but the only thing it does is give you a screen-sized thumbnail (instead of a browser-window-sized one). Forcing the user to view the image just to be able to download it is poor UX (Commons has lots of huge images which will probably crash your browser if you try viewing them); we have plans to offer downloads in a more user-friendly way. --Tgr (WMF) (talk) 02:04, 17 March 2014 (UTC)
 * Absolutelly agree on that. Now I do feel like I am obliged to downlod the image, to see any details on it. (crap!)
 * If viewing some map (for example), You need to go in much higher resolution then the height of your screen allows!!
 * --Reo On (talk) 15:15, 4 April 2014 (UTC)


 * Plans... You shouldn't implement this kind of change before it has essential features like that ready.

More visible "Close" button, or close on click outside of the viewer
The X in the upper-right hand corner is not obviously a hotspot for closing the media viewer. Something much more visible would be appropriate, particularly for an initial rollout. "Close (X)" or a much larger button would help.

Even better and clearer: a version of the viewer like Gryllida proposed above, which doesn't take over the entire screen, leaves the top and side menus and the article title visible, and closes when you click anywhere outside of it. Sj (talk) 01:26, 15 March 2014 (UTC)
 * Hello Sj. This is a complicated issue from the user experience standpoint for a couple of reasons.
 * In general we avoid the word "Close" because it's another point to be translated; specifically, the English word "close" and its connotations and denotations are widely diverse for translation options. In other words, the word "close" is not as easy to translate as it would be expected. X, thanks to operating systems and browsers, is pretty universal as a symbol for what you want to do.
 * The issue with the X in the upper right corner has to do with a split in operating systems/browsers. Unix/Linux/Mac OS and Safari browser users look for an X in the left corner. Windows OS and IE, Chrome, and Firefox browser users look for an X in the right corner. It's not easy to solve, and it gets more complicated when we consider RTL language browser conversions.
 * As for Gryllida's design, it will be up to the design team and Fabrice to look at that option for a smaller window. Personally, I quite like it :) Keegan (WMF) (talk) 04:14, 16 March 2014 (UTC)
 * Thanks Keegan. I think having space 'outside' of the viewing area to click on, as in Gryll's design, would be extra clear.   Or having a larger X-area, or coloring its foreground and background differently so it is highlighted.  No problem with "upper right" as a region, from my perspective. Sj (talk)


 * Sj: The purpose of the media viewer is to give images the space they need to be understood, viewed and enjoyed. Confining them again into a tiny pop-up would defeat that intent entirely. It's a media viewer, not a metadata pop-up. That is not to say there isn't a place for better metadata tools.


 * Pau just announced the latest round of user tests; so far I'm not seeing any evidence that users are confused by the lightbox view. I do notice that user is trying to close by clicking on the backdrop (in part because the close button is hidden by the usability testing widget). Gilles said in https://gerrit.wikimedia.org/r/#/c/118667/ that there are accessibility issues with a close that's triggered by clicking on the backdrop, but it might be worth testing that a bit more if that's not been done already.--Eloquence (talk) 05:47, 16 March 2014 (UTC)
 * I would never propose confining the glory of media to a tiny pop-up. But an overlay that covers 90% of the screen instead of 100%, yes that I might.   An overlay that is sensitive to people clicking on images, or backdrops, to provide zoom or close interactions: could be interesting too.  :-)   Sj (talk) 16:48, 23 March 2014 (UTC)


 * We talked about this a bit in the recent quarterly review. I asked Fabrice (who is currently on a much-deserved vacation) and Pau to see if we can user test the close behavior a bit more. If users are confused by the close behavior, or just intuitively attempt to click on the backdrop, we can experiment more to see if we can introduce that action without diminishing accessibility. Re: size of the lightbox, I think it's ideal to be close to full-screen for images that warrant it to really enable the user to see all the detail of the image without distraction; it might be worth optimizing the behavior in the case of images that are tiny (lots of fair use examples), but it might be more confusing than useful.--Eloquence (talk) 20:51, 25 March 2014 (UTC)

Preview of the previous / next items
I just tested Lightbox_demo and I missed a preview for the items. A row with the previous and next items would be nice so you can skip items etc.

[prev] [prev] [prev] [prev] [prev] [current] [next] [next] [next] [next] [next]

It seems the "collection" has such a feature.

--Subfader (talk) 13:21, 16 March 2014 (UTC)


 * This is a great suggestion and it's one that we're looking at (Mingle #172) in the collections feature, as you mentioned. This is still in the idea phase for design, but it's something we think Media Viewer should have as well. Keegan (WMF) (talk) 22:54, 17 March 2014 (UTC)

Bigger image when you get the mouse over the image
Great job! In my opinion if you get the mouse over the image the image should get bigger without hiding all of the article, and with a legend saying "click me to get bigger". It could be annoying for some people specially if the image is big on the article, but more people would know about this functionality, and will be easier to convince editors they use "thumb" option in size.--Pertile (talk) 21:54, 17 March 2014 (UTC)
 * Thanks for the feedback, Pertile. While we do not have plans to make the image get bigger when you mouse over, we do have plans in the works with the upcoming zoom feature that integrates a similar concept to the "click me to get bigger" idea that you mentioned. Specifically, "the overview thumbnail allows the user to zoom-in ( + ), zoom-out ( - ) and reset the zoom level (an expand button that appears on a corner of the thumbnail when the user hovers it)." You can find out more with mockup illustrations at the link I provided above to zoom feature. Keegan (WMF) (talk) 22:59, 17 March 2014 (UTC)

Link to Media Viewer on Commons


Greetings everyone!

As the Multimedia team finishes up this cycle of Media Viewer development, we’d appreciate your feedback on some of its final features, such as the proposed link to Media Viewer from Commons file description pages.

Currently, viewing media on Commons either shows an image standardized on the file description page, or you can click on the image to view it in full resolution. Offering a link to open the file using Media Viewer will allow for a richer media experience, as the viewing size is increased, while still providing useful information, as well as prominent tools for file sharing and reuse.

We propose a "View expanded" link below the image on Commons pages (see mockup thumbnail to the right). This will enable users to open the image in Media Viewer, without making it the standard viewer for file pages. Additionally, if the user clicks "share this file" and it opens in Media Viewer and then the user exits out, they cannot return to Media Viewer without such a link.

You can find more information and comments from the designers on the Mingle card #199 and you can view this mockup of what the button will look like below the file.

Thank you for your time and feedback! Keegan (WMF) (talk) 22:26, 17 March 2014 (UTC)


 * As usual, the button is hard to notice, and it's hard to understand that it's a button doing something, because it's light grey over white.
 * Other than that, it seems quite cluttering, easy to click by mistake instead of "original file" (or vice versa), confusing when opposed to the stockphoto gadget bar at top (or right).
 * It should be one of the buttons above the image, or not be on the file description at all. If that requires integrating stockphoto into the extension, all the better: satisfying the needs of communities shown by default gadgets, and reducing the workload of volunteer gadget authors who have to compensate the inadequacy of MediaWiki, is always a good endeavour.
 * --Nemo 12:23, 22 March 2014 (UTC)
 * Thanks for the thoughts as always, Nemo. Comments from others are still more than welcome :) Keegan (WMF) (talk) 23:01, 27 March 2014 (UTC)


 * Curious, why not just improve the top bar (Download, Use this file, Email, etc.) and add it to that? I think that'd be more intuitive and could have a lot more potential than the inevitable addition of buttons with no obvious place for their inclusion. Remove the "X", combine "Use this file" into a dropdown with three choices (Use on web, use on wiki, Email), make "Information" less vague. You could also replace the icons with new ones that match the style of the rest of the new Media features and move the "Add a note" button into the bar. Perhaps change the "Other resolutions" into a simple dropdown and put it in the bar as well? I realize this is kind of "Hiding features behind more clicks", but I think it's highly beneficial to lower the text heaviness (which is very heavy on image pages right now), especially since these pages are very confusing to new users and contributors.
 * Holy tangent, Batman! Sorry, I got a bit carried away I suppose. I just hate the current File pages, they're ugly and unintuitive! Point is, I think the problem isn't where you're placing the "View expanded" button, but the current organization of pages in the "File" namespace being a horrible mess that needs to be more modular. --Nicereddy (talk) 04:12, 30 March 2014 (UTC)


 * Yeah, the button as it is currently implemented seems rather "bolted on". I'm not sure we need another layer of zoomed image on the file description page. We already have the click on the preview image to bring up full size (and we also have the ZoomViewer gadget for super large images). Having yet another function to view the image at a larger size seems like a bad UI move to me (interface clutter, user confusion). --Dschwen (talk) 20:31, 15 April 2014 (UTC)
 * In my eyes it does make sense to have a link to the more beautiful (black background, no toolbars, …) fullscreen view Media Viewer offers, but it should be a direct link as the Media Viewer itself is clearly not meant to be accesed from a file description page (strangely, by clicking on Expand view you get to a copy of the page you are on and there are even two links to the file description which is already there in the background (unnecessary reloading)). Also, I don't like the fact it's a button, a link in the File  File history   File usage on Commons   Metadata bar Tools section of the sidebar would definitely be a better solution. FDMS4 (talk) 22:16, 15 April 2014 (UTC)

I like the button (and Media Viewer) but I don't like the position of the link. Maybe it would be possible to put it into one line with "add a note" so that it doesn't take so much space and makes the file page longer? At the moment you just have to scroll more to see description and categories. --Indeedous (talk) 22:14, 15 April 2014 (UTC)


 * Hi Nemo, Nicereddy, Dschwen, FDMS4 and Indeedous: Thanks for your thoughtful comments about the Media Viewer button on Commons. We will pass them on to our designer Pau Giner when he flies in from Europe tomorrow, and will get back to you with some possible improvements based on your feedback. We are not married to this particular implementation, and I am sure we can find a good solution together. In the meantime, you can read more about the rationale for this feature on our development ticket. Stay tuned ... Fabrice Florin (WMF) (talk) 01:05, 16 April 2014 (UTC)
 * This is not a design question. You're adding technical debt to Commons. Stop immediately. --Nemo 11:28, 16 April 2014 (UTC)
 * I don't think this is a fair statement Nemo, the multimedia team is trying to do the exact oposite of that. They are trying to play catchup to improve the user experience for our re-users. I think nobody had any illusions that this would not mean stepping on the toes of hardcore powerusers at some point. It is up to us to find a reasonable way to please both ends of the spectrum. And a simple "Stop immediately" doesn't seem like a productive way forward. --Dschwen (talk) 15:48, 16 April 2014 (UTC)


 * Update: Hello again, everyone! Since the last post on this thread, we have had a number of discussions on this topic, including this office hours chat on IRC. Dschwen has proposed a very reasonable solution, which is supported by our designer Pau Giner and other team members, and which we've outlined on this ticket: #463 - Click on Commons Files to open Media Viewer.


 * This new solution would be to simply open up the Media Viewer when you click the preview thumbnail on the Commons file page (like it pops up when clicking article thumbnails). This design approach is more consistent with current behavior in articles, galleries and category pages -- and matches user expectations more closely, as well as best practices on the web. To make this even clearer, a tooltip could say 'Open this image in Media Viewer' when you hover over the image preview. To address the needs of power users, a special icon would appear over the image to let you access the original size, as illustrated in this mockup (see thumbnail to the right). Anyone can open that link, even if they are logged out or do not have Beta Features turned on - except if the user has disabled Media Viewer in their preferences (so users could disable this feature if they really hate it).


 * What do you guys think? This seems like a more elegant solution than adding a button to an already cluttered interface on the Commons file pages. We'd love to reach a consensus for this simpler solution, so we can implement it next week, before we wrap up feature development on Media Viewer. Otherwise, we would need to keep the current ‘View expanded’ button, as described in this ticket #199, for two reasons: 1) if a user wants to see an image in Media Viewer from a Commons file page, they need a practical way to open it with Media Viewer; 2) if a user views an image in Media Viewer over a Commons file page, then closes it, they need an easy way to re-open Media Viewer (all our shared/embed links go to the Commons file page, where they open the image in Media Viewer, so this could happen to a lot of users).


 * Thanks in advance for your constructive feedback, so we can reach a prompt resolution on this issue :) Fabrice Florin (WMF) (talk) 00:41, 24 April 2014 (UTC)


 * Oppose: This would make it much harder to get to lager images, as images in Media Viewer are pretty much the same size as on the Commons description page (often smaller, actually), and clicking on the image is the standard/obvious way to get to a larger (full-size) image. Really, I don't get the point of getting to the Media Viewer from Commons pages anyway, as they already have the description/info and large images, and the whole point of Media Viewer is getting to large images and the description/info. Jay8g (talk) 03:44, 24 April 2014 (UTC)


 * I like that solution. It is consistent and intuitive. I wonder why you even need the button to open a file in its original size on the image. After all, there already is an easily accessible "original size" link directly below the image. Putting an extra button on the image adds a bit of extra clutter and people could misclick it by accident. The link below is easier to hit in any case. --Srittau (talk) 10:52, 24 April 2014 (UTC)

Add the extension to my wiki
How can I add the Extension:Media Viewer to my wiki under Beta-preference?

--Suriyaa Kudo (talk) 17:02, 18 March 2014 (UTC)
 * Glad you want to try it out, Suriyaa Kudo. On any Wikimedia wiki that you are logged into you can either click on the "Beta" label at the top of your screen, where you have links to your userpage, talk, preferences. The other option is to go to  on any wiki when logged in. Let me know if you need any further details or explanation. Be sure to let us know what you think! Keegan (WMF) (talk) 17:31, 18 March 2014 (UTC)
 * It's ok. :-)
 * Suriyaa Kudo (talk) 15:37, 19 March 2014 (UTC)


 * Suriyaa Kudo, I might have misunderstood. Were you asking how to install the extension on your own wiki? Keegan (WMF) (talk) 17:34, 18 March 2014 (UTC)
 * Suriyaa Kudo, if the question is, "After I have installed the MultimediaViewer extension on my local wiki, how do I add it to my local BetaFeatures extension?" Then the answer can be found here, Using new hooks in your extension. Hope that helps. Keegan (WMF) (talk) 17:41, 18 March 2014 (UTC)
 * Is this right:

// MultimediaViewer.php $wgAutoloadClasses['MultimediaViewerHooks'] = __DIR__. '/MultimediaViewerHooks.php'; $wgHooks['GetBetaFeaturePreferences'][] = 'MultimediaViewerHooks::getPreferences'; // MultimediaViewerHooks.php class MultimediaViewerHooks { static function getPreferences( $user, &$prefs ) { global $wgExtensionAssetsPath; $prefs['my-awesome-feature'] = array(           // The first two are message keys            'label-message' => 'beta-feature-message',            'desc-message' => 'beta-feature-description',            // Path to an image that represents the feature            'screenshot' => $wgExtensionAssetsPath . '/MultimediaViewer/images/screenshot.png',            // Link to information on the feature - use subpages on mw.org, maybe?            'info-link' => 'https://mediawiki.org/wiki/Extension:MultimediaViewer',            // Link to discussion about the feature - talk pages might work            'discussion-link' => 'https://mediawiki.org/wiki/Extension_talk:MultimediaViewer',        ); } } ?
 * Suriyaa Kudo (talk) 15:37, 19 March 2014 (UTC)

MultimediaViewer does include those hooks though, so if you have installed both it and BetaFeatures, things will just work. (This also means that if both MediaViewer and BetaFeatures are installed, there is no way to make MediaViewer work outside of beta. This is not ideal, and will change soon, so for forwards compatibility, you should set  in , although it has no effect at the moment (you are in beta whatever you set as long as BetaFeatures is installed). --Tgr (WMF) (talk) 19:57, 18 March 2014 (UTC)
 * Thanks.
 * Suriyaa Kudo (talk) 15:37, 19 March 2014 (UTC)
 * Great, Tgr (WMF), thank you for the explanation. I'll look into clarifying the documentation. Keegan (WMF) (talk) 16:33, 19 March 2014 (UTC)
 * Just tried it. Installed BetaFeatures and MultimediaViewer. The MultimediaViewer didnt show up on the beta preference page before I changed "$wgMediaViewerIsInBeta" from false to true in MultimediaViwer.php. (version wmf17) Christian75 (talk) 20:34, 22 March 2014 (UTC)

Comment (shortcut, and use on en wiki, and ...)

 * It would be nice if f switched full screen (on/off).
 * It shouldt say "use this file"; when the file is non-free
 * The box which opens when pressing "use this fil" doesnt use the full screen (I can only see part of the file title to use) - ask for screen shut...
 * As said before, its not easy to find the description page. I do not expect to learn about the file, when I see a wikipedia logo and "learn more" - then I expect to learn more about wikipedia...
 * The "Used in xx pages" doesnt work when the file is local (it counts different images, from other wikis)
 * When I see "CC BY-SA 3.0" I expect to come to the licens page when I click, not to the description of the file.
 * External links should be marked as external links, like link
 * Maybe right click should open a box which say where to copy the image from

My two cent, but I like the viewer :-) Christian75 (talk) 11:05, 21 March 2014 (UTC)
 * And we appreciate your two cents, Christian75. Thanks for detailing  in the section above as well. Most (if not all of) what your comments above are about are still being finalized before the global release. Always good feedback to have. Keegan (WMF) (talk) 18:06, 24 March 2014 (UTC)

Please consider the various users
Hello,

What is "modern" is not always useful.

The needs of those who write are not the same than for simple readers.

Maybe a simple click opens the picture for a better seeing, a double click opens directly the Commons page for working.

Best regards,

Jean-Jacques MILAN (talk) 13:49, 23 March 2014 (UTC)


 * I really like the new media viewer, and I will certainly not turn it off and I will use it as my default view. But when editing articles the media viewer slows down my progress considerably. Now, instead of just clicking on an image to go to the image details page, I have to 1. click the image, wait for the overlay to open, wait for the Commons link icon to appear, navigate my mouse to the icon and click. One easy solution is to have a commons icon appear overlaid over an image when you hover the image. This would provide a direct link to the commons description page. --Srittau (talk) 02:05, 19 April 2014 (UTC)
 * You should be able to right click and "open in new tab" on any file that's embedded in the page, if that's faster for you. --GeorgeBarnick (talk) 02:21, 19 April 2014 (UTC)


 * That's actually a very good hint. Mid-click also does work. My workflow won't suffer. :) Now the only concern I have is that this feature is not very discoverable. --Srittau (talk) 03:19, 19 April 2014 (UTC)

How do you find Categories, galleries etc.?
Am I just not seeing something? Usually I want to see what else is in the category, what other categories it's in and such. Is there a way to do this, or is ditching the Media Viewer a necessary step to get this info? Otherwise, it's great for looking at pictures, but not so good for researching, imo. Parabolooidal (talk) 22:31, 24 March 2014 (UTC)
 * Thanks for the feedback, Parabolooidal. Categories are not currently shown as the Multimedia team was working out how to best display them. There is a plan now to show categories as tags. Galleries will be supported in the near future as well. Keegan (WMF) (talk) 17:32, 30 March 2014 (UTC)

Don't show hidden categories
The category section of Media Viewer is often polluted with irrelevant categories, typically hidden categories (ie Category:Uploaded with UploadWizard). These are rarely, if ever, relevant to the picture, and should not be displayed so as to not confuse inexperienced editors/readers, the people who Media Viewer will be most important for, and so as to make the real categories be emphasized. Jay8g (talk) 03:01, 25 March 2014 (UTC)
 * Indeed ; this is tracked at 62277. Jean-Fred (talk) 20:06, 25 March 2014 (UTC)

"Public domainPublic domainfalsefalse" bug
The license template has the garbage text "Public domainPublic domainfalsefalse" in it. Please see File:Annotated screenshot of bug in Media Viewer's license display.png for an annotated screenshot of the bug. Sven Manguard (talk) 06:59, 26 March 2014 (UTC)
 * Thanks, Sven Manguard, really appreciate your bug report and helpful screenshot. I believe this bug is fixed now, though it may not yet be deployed on your home wiki yet. But you should be able to test it on this beta test page, if you don't mind slow performance - or try it on this MediaWiki.org test page, where we deploy every Thursday. Either way, please let us know if the issue has been addressed to your satisfaction, and thanks again for your thoughtful feedback! Fabrice Florin (WMF) (talk) 00:47, 24 April 2014 (UTC)

Show progress bar while an image is loading
I would like to suggest showing a progress bar instead of a blurry image. Otherwise it gets difficult on eyes and I (on a slow internet) don't know when to expect it to finish. Gryllida 00:11, 30 March 2014 (UTC)

There is a progress bar, at the bottom of the image. --Tgr (WMF) (talk) 06:08, 30 March 2014 (UTC)

HTML code for embedding: add a link to the license
For example, for this picture, the HTML code for embedding is:

In my opinion, cc-by-2.0 should be a link to the license text as required by the license. (Vice versa for the other licenses that require a link to the license text.) Regards, --Ireas (talk) 08:42, 2 April 2014 (UTC)

This was omitted due to technical problems and should work in the version deployed today. (Wikimedia Commons will also become a link.) --Tgr (WMF) (talk) 22:03, 3 April 2014 (UTC)


 * Thanks for dealing with this. Yet I stil don’t get a link; neither on dewiki nor on Commons.  Regards, --Ireas (talk) 22:36, 5 April 2014 (UTC)

ːThere was no deployment this week, for reasons unrelated to MediaViewer, so add one more week. (Even if there was one, it wouldn't effect Commons or dewiki yet; there is half a week and one week delay, respectively, in deployments to those sites. mediawiki.org is always the best place to check for new things.) --Tgr (WMF) (talk) 23:58, 6 April 2014 (UTC)


 * ✅. Works for me; thanks! --Ireas (talk) 22:22, 18 April 2014 (UTC)

Translation
Hello,

Where can I change the Hebrew translation? There are couple mistakes in it. Neukoln (talk) 16:28, 8 April 2014 (UTC)
 * Translations for Media Viewer (and all of MediaWiki) are done on translatewiki. If you do not have an account there - it's not a Wikimedia wiki - then you need to register one through the simple three step process. After you have your account, you can help with the translation for Media Viewer here. Let me know if you have any further questions about translating, Neukoln. Keegan (WMF) (talk) 18:27, 8 April 2014 (UTC)
 * Thanks, I have an account in translatewiki, but I didn't find the messages, so I ended up here :) (I've searched for the translation without taking into account the possibilty of $1). Is there a way to view all pages that use one of the messages? specifically "More details on $1". The translation of this one depends on the context. it can be either "פרטים נוספים על" (the current translation) or "פרטים נוספים ב" (the right translation if $1 = wikicommons, and the meaning is more info about the file. If the meaning is more info about wikicommon the project, than the first translation is fine after all). Neukoln (talk) 07:43, 9 April 2014 (UTC)
 * Add  to the url of the page (before the # if already in the lightbox) to see the names of the displayed messages. This makes it easier to then find it in translatewiki. /31.211.223.187 20:33, 10 April 2014 (UTC)

Exit lightbox, goes to top of page
I'm fine with the lightbox ... but every time I hit 'X' and exit the lightbox, I end up at the top of the page. This is annoying when I'm going through e.g. the test page and trying lots of different images and image types. "As a user, I would like exiting the lightbox not to change my position in the page, so that I do not find the experience unduly annoying." - David Gerard (talk) 21:37, 10 April 2014 (UTC)
 * BTW, the video at the bottom of the test page doesn't do this - David Gerard (talk) 21:38, 10 April 2014 (UTC)
 * Right, I see what you mean. Good catch, David Gerard. I think at this point I've opened it up so much I don't even notice that inconvenience. We'll pass this along to see if it can be rectified reasonably. Keegan (WMF) (talk) 22:19, 10 April 2014 (UTC)
 * This is a regression. Created card 439. --Tgr (WMF) (talk) 22:42, 10 April 2014 (UTC)
 * ...so that's why it wasn't a problem that I noticed before. Thanks, Tgr. Keegan (WMF) (talk) 23:13, 10 April 2014 (UTC)

Statistics on image viewing
Are any logs kept when images are viewed through Media Viewer? It would be useful to be able to look at viewing statistics, especially since Media Viewer will probably replace many views of file description pages. Data on the referring page (if any), the date/time, and the resolution viewed would be useful IMO. (The last two might need to grouped before any public release.) --Avenue (talk) 05:25, 11 April 2014 (UTC)


 * Hi Avenue. Thanks for your good suggestion. We hadn't planned to provide detailed viewing statistics for every image served in Media Viewer; but if enough people want this feature, we'd be happy to put it in the backlog for future releases. In the meantime, you may be interested in these metrics dashboards for Media Viewer, which show how this tool is being used in the aggregate. Please let us know if you have any questions. All the best. Fabrice Florin (WMF) (talk) 23:19, 14 April 2014 (UTC)


 * Thanks Fabrice, the aggregate stats are interesting. I do think detailed image viewing stats would be even more useful, especially if we can enable people to easily access and compare viewing stats for all images in a particular article. For now, my main concern is whether the necessary data is being collected. How exactly it would be made accessible can be sorted out in due course. --Avenue (talk) 00:43, 20 April 2014 (UTC)


 * You're very welcome, Avenue. Your suggestion makes really good sense to us, and we will consider it for future releases. For now, I have filed this ticket so we don't forget. Thanks for this good idea :) Fabrice Florin (WMF) (talk) 00:59, 24 April 2014 (UTC)

my comments
the tool is nice. but i have few comments: tnx, Dalilonim (talk) 14:03, 11 April 2014 (UTC)
 * there should be a way to access the source page, for editors and readers. and i mean in Wikipedia (for me its he.wiki) not only in Commons.
 * an option to turn it off would be nice - people have their habits and preferences so would be nice to have control, and for editors that's important - so at list for editors.
 * the background color (black) is too contrastic (in reference to the white BG it opens from) so i suggest a lighter color or preservation of white.
 * Thank you for the comments, Dalilonim. We'll see what can be addressed about your first comments. As for the second comment, there is an option to disable Media Viewer by unchecking the "Enable new media viewing experience" box in your preferences: . Your third point is a good suggestion, but all usability studies and industry best practices use a black background to reduce eye strain and enhance color and detail in photos. Let us know if you think of anything more and thanks again. Keegan (WMF) (talk) 22:14, 12 April 2014 (UTC)
 * Could you at least make that background translucent, like all the other sites following industry best practices do? The current solid black background loses all context of the page at which it's embedded. Diego Moya (talk) 16:24, 17 April 2014 (UTC)

File usage links
A list of pages on which the image is used is displayed, but it appears to ignore namespaces when displaying the title of those pages. So "Talk:Philadelphia" shows up as just "Philadelphia". The link goes to correct namespace; it's just the display that's misleading. LtPowers (talk) 17:36, 14 April 2014 (UTC)
 * Great find, LtPowers. I filed a bug to fix that. Keegan (WMF) (talk) 18:41, 14 April 2014 (UTC)

Off switch
I don't mind the implementation of this new tool if there's the option to not use it. Even if Media Viewer is the new default, will "switch Media Viewer off" be an option? If not, why not? DragonflySixtyseven (talk) 19:48, 14 April 2014 (UTC)


 * Hey DragonflySixtyseven, we agree with you. You can easily turn off this feature in the 'Appearances' tab of your preferences, then uncheck 'Enable media viewing experience'. Try it out here on MediaWiki.org and let us know how it works for you. Cheers :) Fabrice Florin (WMF) (talk) 23:14, 14 April 2014 (UTC)

Media Viewer Launching Soon


Greetings! We would be grateful for your help to prepare for the upcoming release of Media Viewer, a new tool for browsing multimedia content on Wikipedia, Commons and other Wikimedia sites.

We now plan to gradually release this tool in coming weeks -- starting with a few pilot tests this month, followed by wider deployments next month, as described in this release plan.

As we approach release, we would like to know what you think of this tool, so we can address any critical issues, based on your feedback. If you haven't already, we invite you to try the tool in beta as described here, then share your comments here.

We are particularly interested in comments on these features:
 * Use/share this file (screenshot)
 * Embed this file (screenshot)
 * Download this file (screenshot)
 * License Info
 * Permissions
 * Edit this file link to Commons
 * Prominent link to Commons
 * Media Viewer Link on file pages

To learn more about this release, please join our next IRC chat, on Wed. Apr. 16 at 18:00 UTC at Wikimedia's Office IRC Channel. Hope to see you there! Fabrice Florin (WMF) (talk) 01:05, 16 April 2014 (UTC)
 * The first three look like you're re-making Stockphoto. How do you plan to integrate the two on Commons? --Nemo 11:19, 16 April 2014 (UTC)
 * is a dead link. I still don't see the gain in making links so obscure, see . --Nemo 11:27, 16 April 2014 (UTC)
 * is a lot of work for no gain that I can think of. What's the purpose of transcluding and reformatting all that information, when it's invisible anyway (outside the screen when you load the image, see also or the community rebellion for the similar decision Flickr made recently)? Why can't you just trasclude the file description as we've always done? Or, if you want to people to actually see select information, put it somewhere visible in the screen. --Nemo 11:27, 16 April 2014 (UTC)
 * Yes, please, include file author, license, and description in the viewer. Gryllida 11:34, 16 April 2014 (UTC)

Fabrice Florin (WMF), can we please have a feature freeze for a couple weeks at least and ask for community feedback on the existing version? Gryllida 11:37, 16 April 2014 (UTC)

Fabrice Florin (WMF), there are some issues, such as not going full screen, showing metadata more prominently, which are requested by community but not addressed. Please don't deploy yet. Gryllida 11:39, 16 April 2014 (UTC)

I'm testing the Media Viewer, and I've found several critical errors that are showstoppers. The thing doesn't look ready for mass deployiment. Shouldn't you first fix critical errors, then decide a release schedule? Sorry but your release plan seems backwards. Diego Moya (talk) 16:22, 17 April 2014 (UTC)
 * When clicking on an image a very blurry version of the thumbnail is shown maximized, and it can be there for up to ten or twenty seconds. As there isn't any spinning wheel animation indicating that the actual high resolution image is being loaded, it simply looks like the image is broken. In some cases there is a (very difficult to see) progress bar below the image, but it doesn't show always, and it doesn't display progress while it's stalled and waiting to load on a slow connection; a continuous animated .gif would work much better to indicate the "loading" status.
 * If the background loading process breaks, there is no indicator that this happened, and the blurry version does remain in place as the only broken version ever displayed, with no obvious way to access the file page to see the original. I've found this happening with File:Clementine_0.6_in_Windows.png in Amarok (software). Clicking on the image should go to the File page for it - it works much more reliably.
 * When closing an image, I lose my reading point an the page is scrolled to the top, forcing me to scroll down again to the place where the image is located. This is unacceptable for a supposedly "easy to use" tool.
 * There's also no way to pan&zoom into the image with the browser's zoom feature, not even in full screen mode. This one is not a showstopper for most the common cases, but it's quite inconvenient, and prevents users from watching details in the image. All these problems should have been not too hard to catch, by testing how users recover from errors (you are testing users under harsh conditions of unreliable connections and slow computers, and not just in lab rooms in California, right? ;-) That's Wikipedia's target audience). Diego Moya (talk) 16:52, 17 April 2014 (UTC)
 * Someone else from the team will speak to your first two points, but as for the third: losing your place in the page when closing an image will be fixed in today's deployment. It was an unfortunate regression that happened after last week's update. We now have a test going out to prevent this regression from reoccurring.
 * As for the zoom feature, it is in the works for v0.3. Hope this helps. Keegan (WMF) (talk) 17:58, 17 April 2014 (UTC)
 * From the usage videos you linked to above, it seems like you're testing how the media viewer works as a tool for slideshows; but I've seen no use cases to test how it interacts with the encyclopedia - maybe you should also create some cases for these (including more variety of the images - not merely landscapes but diagrams, application screenshots, old newspapers...), with some cases of images whose detail is coordinated with the text around it. The Media Viewer does not even show the image's caption text above the fold, for heaven's sake.
 * As for the Zoom Feature; I'm looking at the design you link. I don't want to use a zoom's button, I want to use the standard zoom features in my browser over which I have more control than with page scripts. Will that work with the mouse wheel and Ctrl +/-, pinching on mobile, and showing vertical/horizontal scroll bars for panning? It's OK if it works by dragging and pressing on visible controls too, but the basic browser functions should not be broken. (I.e. I already have a very good zoom feature that I like and know how to use, why won't you just let me use it?). Diego Moya (talk) 18:08, 17 April 2014 (UTC)
 * Same problem here: it takes too much time (many seconds) until the non-blurry image appears. This is a lot worse than going to the traditional description page (see screencast on 64135). And I confirm it is loosing the scroll position when the viewer is closed. Helder.wiki 13:21, 19 April 2014 (UTC)

Some more data in case it helps. I've been testing a bit more the two first errors. I've noticed that not seeing the progress bar is because, in the first image I click on any page, the entire float bar does not show at all. I'm testing this on Firefox and Chrome, on the English and Spanish Wikipedias and with two different user accounts (the English one has many gadgets and widgets; I think that's why :File:Clementine_0.6_in_Windows.png didn't finish to load. The Spanish account has most default configurations). I reiterate that, even when I can see it, the progress bar is often too subtle to notice. 2.136.173.188 19:03, 17 April 2014 (UTC)

Hi Diego,

--Tgr (WMF) (talk) 20:57, 17 April 2014 (UTC)
 * we are aware of the loading bar issues and looking for a better way to make it clear the image is loading.
 * we do have an error page for when loading the image breaks. We had a bug where, if you stopped the image loading by closing the lightbox, and the reopened it, it did not reload, and you got the blurry image. Maybe you ran into that one? It should be fixed by today's release. Otherwise, it is not inconceivable that both the image loading and the error page display break in some specific situation, but we would need reproduction steps, or at least an error message from the browser console, to be able to fix such a bug. The example you cited works fine for me.
 * as Keegan said, we now have multiple tests to make sure restoring the scroll position does not break again.
 * I haven't followed the user tests, but for internal testing, we use this suite. If you have suggestions about different kinds of images to include, we would be happy to hear them.
 * I'm missing images of the following kinds, where the detail is important and they're placed within an article section explaining their content. It would be good to have a representative sample of the following (most of these are from computing-related articles, it would be good to have them from several other fields of knowledge):


 * File:DATAR trackball.jpg
 * The tabbed ribbon as introduced in Microsoft Office 2007
 * HyperTIES authoring tool under NeWS window system
 * Sketchpad
 * Screenshot of a typical RISC OS 3.7 session

Diego Moya (talk) 10:41, 18 April 2014 (UTC)


 * Update: Hi Nemo, Gryllida and Diego Moya: Thanks for your detailed feedback and thoughtful suggestions. Many of your recommendations have already been solved or are being addressed, as other team members have pointed out in this thread. Overall, the feedback we are getting from the many other voices in our worldwide community suggests that this product is getting ready for wider release, even if it is not perfect. The key remaining issues are being addressed, such as the image load times, which now seem to be on par with the current file page load times, as shown in this metrics graph. Our gradual release plan seems like an effective way to incrementally test this tool in more and more pilot sites, and we carefully review pilot results each week before proceeding with the next step. So it appears that we are proceeding on the right track, and do not see a need to stop everything as has been suggested by some. Thanks again for your continuing feedback, which is invaluable to us: even if we can't act on every suggestion we get, we read everything, and prioritize tasks to match their overall urgency and team capacity. Onward! Fabrice Florin (WMF) (talk) 02:36, 24 April 2014 (UTC)

Extremely annoying issue with embedded video in news reports
Since my remarks in the "please don't go fullscreen" discussion thread seem to have been overlooked, I've created screenshots to show where there is a most-annoying, and reader-unfriendly, aspect to how video is being displayed.

First, we have a news article &mdash; with video clips included &mdash; where no clip is playing. Second, and below it, with the clip playing. Where is the point in even bothering to arrange the video within the text? I can't keep reading once I press play; all I can do is abandon watching the video, or sit back and and nitpick over the player controls cutting off the bottom of the actual uploaded video. When I created this article, I'd estimate that I spent at least couple of hours looking for an option on to leave the damn video playing embedded, where I wanted it. Still haven't found one.

Video can be more than a supplement to an encyclopedia article, sat in a gallery at the foot of the text, which seems the primary purpose of handling it in this manner. I've looked, and can't find a single news source which has video take control away from the user in this manner; nowhere that other text in a report is treated as second-class the second you press play. Sure, I can hit escape and it goes away &mdash; that's not the point! This turns "multimedia" into "monomedia". That's fine if you want to take a closer look at a still or diagram, not where text and video are meant to complement each-other.

I assume this is the "Lightbox view", but I did not click on the 'thumbnail'; I clicked on the video's 'play' button. Like every other site on the Internet, I'd expect to then click a fullscreen or 'larger player' button to get this view. The image on the right illustrates the same issue on Wikipedia, where the embedded video is the exact same size as the 'thumbnail' displayed in the static version of the article. It, too, seriously detracts from the experience of reading the article when the media player takes over the browser window. --Brian McNeil (talk) 12:01, 16 April 2014 (UTC)


 * Fair point, but this is completely unrelated to MediaViewer. Is this a recent change in behavior? --Tgr (WMF) (talk) 18:00, 16 April 2014 (UTC)


 * Hey Brianmc - This was caused by 91342. Previously the pop up thing only happened if the video thumbnail was really small (<200px wide). After that change it happened for any video < 800px wide. The setting can be changed on a per wiki basis, so to change it back on Wikinews, just needs some show of consensus on the WC. To change it on all wikis would require some sort of wide discussion probably. Bawolff (talk) 18:52, 16 April 2014 (UTC)


 * Hi Brianmc, thanks for reporting this issue, even though it's not related to Media Viewer. As a long-time TV producer and documentarian, I feel much as you do about the importance of video and its lack of support on our sites. We were hoping to address some of these video issues this quarter, but are running out of time before our next assignments. So unfortunately we had to push video further out on our roadmap, until we are caught up with more urgent tasks like Upload Wizard and Structured Data on Commons. It breaks my heart to tell you this, but sometimes we have to make tough decisions. :( However, rest assured that we really want to address the issues you brought up, as soon as we can. For now, here's a sneak peak at the new user interface designs we're considering to integrate video and audio in Media Viewer, sometime in the next fiscal year. Be well ... Fabrice Florin (WMF) (talk) 01:24, 24 April 2014 (UTC)

Navigation issue
If you are scrolled down on a long page and open the media viewer to look on a file and then close it, I expect to be on the same spot on the page. But instead I am taken to the top of the page. This is very frustrating and unexpected. Closing the media viewer should put you in the same spot as you were when entering it. --Ainali (talk) 07:13, 18 April 2014 (UTC)
 * This was fixed with yesterday's deployment. I just checked and could not reproduce the issue. Is anyone else still encountering this issue? Keegan (WMF) (talk) 16:10, 18 April 2014 (UTC)

Categories
It seems that only three categories are being shown (not even dots to indicate more); and the category order is being scrambled by putting the cats into alphabetical order. Both of these choices would appear to be undesirable. Jheald (talk) 07:55, 18 April 2014 (UTC)
 * Agree ; I reported a connex bug some time ago under 62277. Jean-Fred (talk) 10:22, 18 April 2014 (UTC)
 * Thanks, Jheald and Jean-Fred. We had initially intended to show a 'More' link after the first three categories and this requirement fell through the cracks: I just filed this ticket #499 to fix that problem. I also agree with Jean-Fred's proposal to ignore hidden categories, and have filed this separate ticket #498 to address that issue. I can't promise we can fit all these fixes right away, but they are now high on our list. Thanks again for these good suggestions :) Fabrice Florin (WMF) (talk) 01:40, 24 April 2014 (UTC)

"Created on 1828"
Should be "Created in" if no day of the month is specified


 * eg if only year is specified
 * or if otherdate is being used

Jheald (talk) 07:58, 18 April 2014 (UTC)

For creator, Artist field should be preferred to Author field if both are present

 * eg:  Jheald (talk) 08:01, 18 April 2014 (UTC)

CC0 (CC-zero) should be recognised as a public domain license
Just showing the CC icon for all CC licenses is somewhat unhelpful. A CC icon specific to the relevant license should be displayed. Jheald (talk) 08:10, 18 April 2014 (UTC)


 * Agree. Another instance of Media Viewer removing important info from view in a confusing manner.--Paracel63 (talk) 12:39, 26 April 2014 (UTC)

Multiple creators
The viewer doesn't appear to be handling cases where there are multiple creator: templates being used for "Artist", only showing the first -- eg cases of Engraver after Original Artist, Jheald (talk) 08:28, 18 April 2014 (UTC)

Images being picked up from templates on Commons file description pages
eg:

The images of the artist (John Leech) and the current location of the work (British Library) make little sense outside their original templates, so probably should not be shown in any slideshow. Indeed it's not clear why any other image should be shown in such a slideshow, for a file from a Commons image description page. But particularly when there is no explanation of where these other images may have come from, nor what may be their relationship to the original image. Jheald (talk) 08:35, 18 April 2014 (UTC)

Make clearer what has to be done for re-use
Hello, I enjoyed seeing the new media viewer very much. A major problem of Commons is, in my opinion, a lack of clarity for the non Wikimedia user how to re-use a file. The media viewer could be still a little bit clearer on what someone has to do if he wants to reuse the image on his own website. I see now the title of the image together with the name of the license on one line, and the name of the creator on the second one. Why not putting name creator name and license on one line, maybe even in quotation marks, and the title on the other? By the way, I would leave away the CC-logo, it is only adding confusion (except for those who already know about the difference between the copyright-sign and the CC-logo, and about the pun intended). Kind regards Ziko (talk) 11:54, 18 April 2014 (UTC)


 * Agree. A one-line solution presenting a correct (the simplest variant) attribution would be most welcomed. Many thanks in advance.--Paracel63 (talk) 12:41, 26 April 2014 (UTC)

Page jumps to top after closing the media viewer
If I scroll down a page, open the media viewer and then close it, the page scrolls back to the top. --Ireas (talk) 22:20, 18 April 2014 (UTC)
 * This should be fixed on mediawiki.org. We'll backport on Monday. --Tgr (WMF) (talk) 22:44, 18 April 2014 (UTC)

Mark icons for gallery exclusion
It should be possible to mark utility files and images as "icons". These are excluded from the gallery view and clicking on them opens the description page directly. It doesn't make sense to have a gallery view for those kinds of icons. If you really want to view them this way, you can always go to the description page and use the enlarge button there. --Srittau (talk) 02:07, 19 April 2014 (UTC)

Adding a  class to some ancestor of the image does that. --Tgr (WMF) (talk) 06:04, 19 April 2014 (UTC)


 * I would really prefer Wiki syntax to achieve this, for example foo.png (where meta could probably be replaced by a better word). Using CSS classes is a power-user feature. Also writing foo.png to achieve this in one-of situations is hard to write, hard to read, and hard to understand for ordinary editors. --Srittau (talk) 16:14, 19 April 2014 (UTC)
 * Tgr Also, metadata should exclusively be used for elements that are not considered part of the 'content proper'. This flag IS part of the content. Let's start with a more fundamental question. Why Srittau, do you think it should NOT be visible in the viewer, can you think of other images that should not be visible (but are part of the content and can you think of similar images that you would want to see, but are otherwise a lot like this flag. Let's see what is needed, before we start adapting the code. TheDJ (talk) 16:38, 19 April 2014 (UTC)
 * I think, images with "icon" character should not be displayed. Also, there are some special cases, where viewing an image using the media viewer doesn't make sense. Let's have a look at the Namibia article on en.wikipedia. In my opinion the following images should not be displayed in the media viewer: (Please note that some of the examples I am listing are already missing from the media viewer. I am listing them for completeness sake.)
 * The earth icon next to the location in the country box. (Already suppressed.)
 * Same for the "up" arrow icon next to the population number. (Already suppressed.)
 * In the "Administrative division" section is a map that uses CSS tricks to add labels. The map without lables is not very useful and should be suppressed. Also, even if the labels were part of the image, viewing it out of context would arguably not make much sense, because it is already shown at full size. (This would be different if it was a detailed SVG or higher resolution map, like the shaded relief map further up in the article.)
 * In the "Religion" section there is a diagram. This particular diagram is made up using HTML & CSS, but for other simple SVG or raster diagrams having them in the gallery list would not make much sense.
 * The "See also" section has three icons for portal. These should not be included. This particular case could be solved with "class=metadata" or something similar, but this is not very intuitive as mentioned above.
 * The "External Links" section also has various icons and flags that do not belong in the viewer (and are already suppressed).
 * --Srittau (talk) 17:44, 19 April 2014 (UTC)


 * Oh, another example from this very page: The "archive box" icon from the top of the page. --Srittau (talk) 17:45, 19 April 2014 (UTC)

We can add another class besides  that disables MediaViewer for the contained images (there are some things like mixed HTML/image maps which are not going to work with MediaViewer but are not really metadata). Any suggestions about the name?

Srittau: changing the parser just so CSS classes can be set via wikisyntax would be the wrong approach, pretty sure we are not going to that. (You can use  right now as a horrible hack to achieve the same effect, but no guarantees about that working in the future.) You can use templates to make the syntax somewhat more user-friendly, but really people should not mess with which images are displayed, unless they are authoring templates, in which case they probably won't be scared off by a CSS class. "Meta" images should not be included in the article's source code directly. --Tgr (WMF) (talk) 02:03, 25 April 2014 (UTC)


 * Most icons, flags, etc are distinguished by being small - it's rare to see a non-content image which is >100px and equally rare to see a content image which is <100px. Would a simple size-based cutoff work for deciding what to put in the gallery view? Andrew Gray (talk) 11:51, 2 May 2014 (UTC)
 * This was suggested at . As I mentioned there, this might work most of the time, but there will always be exceptions, while marking up non-content images would be useful outside of MediaViewer as well. (Also, define non-content. Is the main image of Template:Evolutionary_biology (200px) content or not? Those type of >100px images, which belong to an article group but not a specific article, are not so uncommon.) --Tgr (WMF) (talk) 18:29, 2 May 2014 (UTC)

Goes back to the top of the page...
First off: this is a great feature, way easier than hitting "back" and waiting for it to load. But: when I'm about halfway down the page...and click on a picture...and look at it in media viewer...and close media viewer...it leaves me at the top of the page...so then I have to scroll all the way down again. This gets on my nerves. A lot. I'm no techie though, so don't ask me to help.

Thank you! Eman235 (talk) 07:19, 19 April 2014 (UTC)
 * eh, ignore this...just noticed someone else saw it. Glad to know someone share my sentiments. Eman235 (talk) 07:20, 19 April 2014 (UTC)

changes - hate 'em
im afraid from changes, is there anyway for easy disable? thnx Yoav Nachtailer (talk)


 * Hi Yoav Nachtailer, we feel your pain. Change is scary -- for all of us. I personally think that becoming comfortable with change is our greatest challenge as a species -- now that everything is changing faster and faster. Fortunately, we have a great solution for you in this case: you can simply turn off this feature in the 'Appearances' tab of your preferences, then uncheck 'Enable media viewing experience'. Try it out and let us know if it makes you happier :) Fabrice Florin (WMF) (talk) 01:06, 24 April 2014 (UTC)
 * Thanks from me too. I am indeed happier without Media Viewer. Change only for the sake of change is a not a reason, so please spare us the sarcasm. Many thanks.--Paracel63 (talk) 21:09, 27 April 2014 (UTC)
 * Then why make changes to articles ? TheDJ (talk) 10:52, 28 April 2014 (UTC)
 * thank you very much! Yoav Nachtailer (talk) 13:06, 24 April 2014 (UTC)

Media Viewer Launches on More Pilot Sites
Greetings!

I’m happy to announce that we just enabled Media Viewer by default on nine more pilot sites: Czech, Estonian, Finnish, Hebrew, Polish, Romanian, Thai, Slovak, and Vietnamese Wikipedias.

1. Overview We’re releasing Media Viewer gradually, a few wikis at a time, to test it carefully before deploying to the next batch of sites. So far, the tool has been well received on our first pilot sites: Catalan, Hungarian and Korean Wikipedias, as well as on English Wikivoyage, as outlined below. Next Thursday, we plan to deploy to some of our first large wikis, including: Dutch, French, Japanese and Spanish Wikipedias. Learn more about this release.

2. Metrics We’re now logging about 336,000 image views per day on a global basis, as shown on this graph. About half of these views are coming from the Hungarian Wikipedia, and the rest from Wikimedia Commons, English Wikipedia and other pilots. More metrics dashboards are available for selected sites on this page.

3. Performance We are now tracking image load performance globally, and first results suggest that images take over a second to load on average (50th percentile), but can take up to 5 seconds when looking at worst case for most users (90th percentile), as shown in this graph. We’re also encouraged by early comparisons of the time it takes to open an image with Media Viewer versus on a Commons File, the current default: the mean load times for these two methods seem to be very close, on the order of 2-3 seconds on a cold cache, as shown in this preliminary graph.

4. Surveys We are now running surveys in multiple languages, to validate whether or not this feature is useful to readers and editors alike. Overall response so far is generally favorable. Here are the current results:
 * English Survey: 64% find the tool useful, 12% don’t find it useful, 24% are not sure (50)
 * Hungarian Survey: 48% find the tool useful, 46% don’t find it useful, 5% are not sure (271)
 * Catalan Survey: 62% find the tool useful, 15% don’t find it useful, 23% are not sure (13)

We’re also starting new surveys in French, German and Portuguese. Here are links to live results and comments from these surveys.

5. Usability For the past few months, we have been running a series of usability studies, with positive results. Testers are typically able to complete most common tasks successfully, and they have helped us find new ways to improve the user experience for features they found confusing. Here are the updated results of our usability tests.

6. Your feedback How can we improve Media Viewer? Are there any critical issues that should be addressed for this first release? Please let us know what you think of this tool here on this discussion page. We’d also be grateful if you could take this quick survey, to let us know how Media Viewer works for you. It only takes a minute and means a lot to us :)

Many thanks to all the team and community members who are making this launch possible! Enjoy ... Fabrice Florin (WMF) (talk) 23:22, 24 April 2014 (UTC)

Why the captions are omitted?
Well, I'll try to be constructive this time. I don't understand why the cutlines/captions are omitted. I mean, without them, the most of the images from an encyclopedia are meaningless, since they are used for improve the explications and not just for decoration. Besides, many of them are diagrams or pictures with numbered parts like this that must have a caption. ¿Why not to include them? Thanks. Albertojuanse (talk) 00:26, 26 April 2014 (UTC)
 * +1. I noticed the same big problem. Most of all a serious lack into comparative galleries. --Salix (talk) 16:30, 27 April 2014 (UTC)
 * They are only omitted on galleries (that bug has been fixed, but the fix has not been rolled out yet). If you do not see the caption for any image that is not inside a gallery, could you provide a link? --Tgr (WMF) (talk) 06:59, 28 April 2014 (UTC)

No, I mean, this is not a bug report, Tgr. What I mean is that I tried the "beta" on esWiki and, when I clicked on an image, there was not the caption of the picture, the explanation of it. Of course, there was the file description and copyright mark, etc; but no the explication which is under the image in the "normal" MediaWiki view.

My point is that without these captions, the explanation of that image, this software is "useless" for a project like Wikipedia, in which the explanations/captations of the image are needed for understand it (maybe not for other proyects, of course, talking about Wikipedia). Thanks. Albertojuanse (talk) 15:20, 28 April 2014 (UTC)
 * Albertojuanse: I think Tgr point was that the no-caption in galleries was a bug which has been fixed since.
 * Unless you feel (like Salix) that the caption should be displayed without scrolling down to the hidden metadata panel, which is tracked on 64132. Does the bug report accurately describes what you are expecting? Jean-Fred (talk) 16:46, 28 April 2014 (UTC)
 * ¿Is it scrollable!!!!!? Then, sorry, Jean-Fred and Tgr, the captions are shown properly when you scroll it.
 * Then, you have to find a way for making people know that the page is scrollable!!! I have no even notice that, so I guess other people won't either. Thanks. Albertojuanse (talk) 11:32, 29 April 2014 (UTC)

Media Viewer problems
Hi! My experience with Media Viewer has so far been mostly negative. Here are some points:
 * It presents a cleaner interface, but at the same time it hides a lot of valuable information from view.
 * It seems to have a very different interface compared to the normal Commons experience, which may be confusing.
 * I've witnessed at least two instances, where another user could not escape out of Media Viewer in an easy and straightforward manner (no menus etc visible).
 * It seems Media Viewer has gone default on some Wikipedias – including plwp. My preferred browser (Mozilla Camino 2.1.2) doesn't seem to be compatible with Media Viewer, and I'm not proficient enough in Polish to be able to deactivate Media Viewer in my plwp account. This is not good.

If any or all of these things could be addressed, I'd might be more positive to its implementation. But as for now it's a big no-no for me.--Paracel63 (talk) 12:28, 26 April 2014 (UTC)


 * I now found the deactivation command info in the discussion above. Thanks for that.--Paracel63 (talk) 12:48, 26 April 2014 (UTC)


 * BTW, there doesn't seem to be a way of deactivating Media Viewer "in advance"? Next week, I still want to be able to reach Commons, with my preferred brower, through any of these Wikipedias "Dutch, French, Japanese and Spanish". Best of wishes. :-)--Paracel63 (talk) 12:56, 26 April 2014 (UTC)

"Normal Commons experience" is a bit of an oxymoron. Commons file description pages are disorientating jumbles of random information, looking at a cleaner interface after getting used to them might be a bit like taking off the reversing glasses in the perceptual adaptation experiments :-) Yes, change is always confusing, but there is no way to avoid that if we want to transition to a saner user interface.

I've witnessed at least two instances, where another user could not escape out of Media Viewer in an easy and straightforward manner (no menus etc visible) - do you mean that they could not figure out how to exit, or that the normal methods of exiting (X mark, Esc key) did not work? If the latter, can you reproduce that?

Do you have any specifics of how MediaViewer breaks on Camino? Do you get a javascript error, or does it work but look ugly?

--Tgr (WMF) (talk) 07:18, 28 April 2014 (UTC)


 * Hi! Thanks for getting back to me. Yes, Commons of today is a mixed experience, which clearly could need an overhaul, bringing the composition of the content a lot clearer (like an easily accessible standard attribution line for each license and a lot less bulky license presentation).


 * However, what I've seen of Media Viewer does not seem guided towards (active) users of Wikipedia but as a standalone image viewing environment. It's a media viewer per se, but getting important info out of view has its cons. The lack of visible navigation aids is not for me.
 * Those two instances of failed escaping out of lightroom were with the same user, who used MSIE (a later version) on Win7 (or Win8), itself a menu-less experience that is far from my idea of an easy-to-use computer working environment. The whole setup may have been unstable in at least one of the instances, where we resorted to having to restart the whole computer. In the other, earlier instance we were not prepared nor instructed of how to navigate in lightroom.
 * Yes, on Camino I get a JS error: "Error loading Media Viewer: Module oojs has failed dependencies".
 * Sorry if I'm misunderstanding some things with Media Viewer. As I spend my Wikipedia days 99.9 percent of the time through Camino, I may have missed some good points. Now looking at it through Firefox and plwp, I can appreciate the clean interface. But the cons are the same: lots of valuable info hidden out of view. As a contributor to Commons and Wikipedia this thing just isn't for me, and I'm wondering why the current Commons interface couldn't have found a – somewhat less radical – design change instead? MV looks too much like a gadget, and IMHO it should have stayed that way. The oft-repeated explanation around Media Viewer that "change is always confusing" is sounding like a political statement, so I'm not going to comment on this further. Best of wishes--Paracel63 (talk) 13:52, 28 April 2014 (UTC)

--Tgr (WMF) (talk) 18:45, 28 April 2014 (UTC)
 * Tracking the Camino issue as 64562.
 * If by "not guided towards active users" you mean it does not have editing features, it would be very hard to present an interface to change data with the way currently things are stored, in big blobs of wikitext; and it would be a waste of time, sine that is planned to change soon, at least for images hosted on Commons, with the introduction of Wikidata. After that happens, it is possible that MediaViewer will get some editing features.
 * That said, we did make some changes based on the needs of power users (the image page link in the bottom right corner that's accessible without scrolling, for example), so if you have more suggestions, please share them.
 * Commons file pages have just way too much information for their own good. We might be showing less then ideal for a power user (mostly because extracting them from the file page is a lot of effort), but any user-friendly redesign of how readers access file metadata has to start with hiding a lot of it.
 * There were several reasons why not to redesign the file page itself: it would break established workflows (if you don't like MediaViewer, you can just skip it and go to the file page; if the file page itself would be changed, you would be probably much more unhappy); it is a based on a wiki page so it has a lot of baggage from step 0; it is on a different wiki, and that presents a lot of usability problems (lack of cross-wiki preferences, notification, identities...); loading a new HTML page per image is a horribly ineffective way of navigating images.

It takes my time, I hate it
New viewer may have some positive features for viewers, but I found it irritating. As editor I switch to Commons to use the file, edit page or find information on usage of my photo on other wiki. This new viewer is ugly, uploads slowly and needs another click to find what I am looking for. I want to disable it, but did not found how (it is a default feature on cz:wiki)--NoJin (talk) 10:11, 27 April 2014 (UTC)
 * + 1. Many files take more than 5 seconds to focus, and I have a very good fiber Internet connection ! --Salix (talk) 16:35, 27 April 2014 (UTC)

As a fellow editor, can I ask something ? Are both of you aware of shift/command/middle/right clicking an image to open in a new window ? For me clicking links like that is 2nd nature, but I know many users are not used to that. I have warned before about how many editors we have who might not be used to accessing images that way and predicted friction regarding this with the mediaviewer. I think that makes it a good case to give people an easier opt out (ask auto confirmed users on first click, and disable the feature with JS, if the user thinks it is undesirable). TheDJ (talk) 10:50, 28 April 2014 (UTC)

Description is not very understandable
MediaWiki:Multimediaviewer-pref-desc currently says (my comments in brackets): "Improve your multimedia viewing experience with this new tool [So far, so good, but what does it do?]. It displays images in larger size on pages that have thumbnails [Hm, so it expands the thumbnails, making them a little larger?]. Images are shown in a nicer [nicer than?] fullscreen [full-window?] interface overlay, and can also be viewed in full-size [full-screen? full-size being 100 % (with scrollbars if necessary)]."

What about "Improve your multimedia viewing experience with this new tool. When thumbnails are clicked, a larger version will be shown in a nice-looking overlay, which can be expanded to full screen if desirable. Media on the same page can easily be navigated." ? Danmichaelo (talk) 09:54, 27 April 2014 (UTC)

Error loading MediaViewer: localStorage is null
When clicking on image, error "Error loading MediaViewer: localStorage is null" is displayed. --Ragimiri (talk) 13:46, 27 April 2014 (UTC)

Hi Ragimiri, what browser/OS are you using? Could you try adding  to the URL before opening MediaViewer, then opening the browser's error console (F12) and copying the error message here? --Tgr (WMF) (talk) 18:12, 27 April 2014 (UTC)

I am using Firefox 28 on Windows 7. I hope, this is it:

"Use of "mwCustomEditButtons" is deprecated. Use mw.toolbar instead." load.php:10015 Výpis zásobníku z load.php, funkce mw</<.log</log.warn, řádek 10017. load.php:10017 "Use of "addOnloadHook" is deprecated. Use jQuery instead." load.php:10015 Výpis zásobníku z load.php, funkce mw</<.log</log.warn, řádek 10017. load.php:10017 "User clicked on thumbnail to open lightbox." load.php:11931 "localStorage is null" load.php:10015 Výpis zásobníku z load.php, funkce mw</<.log</log.warn, řádek 10017. load.php:10017

--Ragimiri (talk) 18:24, 27 April 2014 (UTC)

Might be 64525 --Tgr (WMF) (talk) 07:35, 28 April 2014 (UTC)

Of course I have DOM storage disabled. But there is no reason to use DOM storage to viewing images on wiki. --Ragimiri (talk) 08:37, 28 April 2014 (UTC)

The reason is to avoid annoying users with the same notification endlessly. There is no reason a disabled localStorage should cause a JS error, of course - we are feature-detecting it the wrong way. --Tgr (WMF) (talk) 18:13, 28 April 2014 (UTC)

Superfluous
The Media Viewer is a superfluous, unnecessary and harmful tool, which makes work harder. Commons is not a gallery but tool for work. When we go to the commons, we don't want watch and delight pictures, but obtain information necessary for writing of articles. --Matrek (talk) 04:22, 28 April 2014 (UTC)
 * Media Viewer is meant to work differently on Commons than the other wikis since viewing file pages on Commons is part of the work flow and is much more important than the visual experience we are trying to provide. If you feel that there are ways that Media Viewer can be better integrated into Commons so that it does not interfere with workflow by all means toss out your ideas here. There is always room for improvement for integrating with Commons. Keegan (WMF) (talk) 21:47, 29 April 2014 (UTC)

How this off
I dont know, how it function off.--Toma646 (talk) 17:48, 28 April 2014 (UTC)
 * If Media Viewer is already enabled for all, like it is here, you can disable it in your appearance section of your preferences. If Media Viewer is not enabled for all and is still in Beta Features on your wiki, you can disable it in Beta Features. Keegan (WMF) (talk) 18:48, 29 April 2014 (UTC)

Alternative
I've had this script enabled for some time now, and I feel like it's a much better alternative than Media Viewer. I'd much rather stay on the same page and just click again when I'm done with the picture, video, etc, rather than having to go to a new page then hitting the Back button and waiting for the page to load again. Supernerd11 (talk) 14:32, 2 May 2014 (UTC)