Extension talk:Media Viewer/About

 Leave your feedback for Media Viewer

You can see a list of open bugs for Media Viewer on Bugzila.

You can see what we're working on now on Mingle

And you can see what we're working on next.

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.

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

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

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

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

Mention partnership

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

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

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

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

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

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

Share to Social Media

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

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

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

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

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

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

To that end, we are considering these different options:

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

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

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


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

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


 * Comments:


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


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


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

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)

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.

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)

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)

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

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)

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)

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)

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)