Extension talk:Media Viewer/About

Archive: Earlier comments about Version v0.1 were archived on this page, as most are addressed in the current version v0.2. This will enable us to focus on that version in this discussion page. Other comments that have not yet been addressed but are on our roadmap were kept here for now. As new solutions are introduced, more comments will be archived in coming weeks.

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)

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)

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 don't 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)

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)

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)

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)

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)

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)

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)