Extension talk:MultimediaViewer/About/Archive/Talk:Media Viewer

"Details"

It seems to me that this section is missing the point. For instance, the main shortcoming of all this will proably be the inability to show the description in the correct language, for a number of reasons; Commons (and only Commons) has the tools to solve this via language select. Avoid adding more complexity for dubious gains, just link the description page for more details. Primary and secondary info already look like a huge challenge to extract, probably not properly feasible. --Nemo 12:37, 21 August 2013 (UTC)

Thanks, Nemo. You make a good point that details may be overkill in this view. We got similar feedback from our team and other community members, and will pass it on to our designers. Thanks so much for this suggestion. Fabrice Florin (WMF) (talk) 17:25, 27 August 2013 (UTC)

From irc chat

Putting here so I don't forget:

• Was suggested in irc chat that annotations be shown in media viewer.

Bawolff (talk) 00:23, 23 August 2013 (UTC)

Thanks, Bawolff, good point. This annotation request could possibly be addressed by an opt-in variation of the Article Feedback tool, as proposed in this RfC on Commons. Fabrice Florin (WMF) (talk) 17:25, 27 August 2013 (UTC)

Another suggestion from Rillke was to make it easier to give proper credits to authors and sources, which could possibly be addressed with an Embed tool. Fabrice Florin (WMF) (talk) 17:25, 27 August 2013 (UTC)

With useful recent details from the gadget's developer at w:Help_talk:Gadget-ImageAnnotator#Is_this_still_working.3F (particularly the penultimate comment). :) Quiddity (talk) 18:39, 23 August 2013 (UTC)

Thanks, Quiddity! Good suggestion about possible requirements for an annotation tool. It would be great if we could re-use the AFT code for this, when the time comes, so we don't have to reinvent the wheel regarding comments. Fabrice Florin (WMF) (talk) 17:25, 27 August 2013 (UTC)

I think you misunderstand which type of annotations I meant. I mean commons:Commons:Image_annotations - which is not usually used for the type of thing AFT is used for, but closer to facebook's tagging feature (For example, tagging somebody's face in a picture, or a specific feature of the image). For example, hover over the faces in commons:File:Henley_2009_women.jpg Bawolff (talk) 00:20, 28 August 2013 (UTC)

Use cases of image annotations: Associating people on a photo with their names, labeling details, which is useful for technical devices, anatomy, photos that consist of many details like panoramas and aereal photos, for example, instead of producing series like that and having the user to upload each single file and without distorting the original image [which may be seen as disrespectful by certain users/cultures]. It is also useful for presenting detailed shots of attractions in overviews. -- Rillke (talk) 13:02, 28 August 2013 (UTC)

From Roundtables

Here are some of the recommendations made in recent roundtable discussions -- from their respective Etherpad notes:

• August 8 Multimedia Roundtable:
  • https://nl.wikipedia.org/wiki/MediaWiki:Gadget-Direct-link-to-Commons.js
  • Improve visibility of Featured pictures, or medias uploaded during a pertnership (GLAM...) or a campaign (WLM...)
  • Mockups with this idea (and personal feedback) : http://www.mediawiki.org/wiki/Talk:Multimedia/Feature_ideas#Media_viewer
  • Image zooming with progressive loading (ZoomViewer: http://toolserver.org/~dschwen/iip/wip.php?f=Chicago.jpg )
  • Also needed to view large maps (related to Wikimaps)
  • Would it be wise to disable this somehow for fair-use images? Obviously they're likely to be low-res anyway...
  • Likewise work out how to handle the crappy 100px images we still have - don't automatically expand! +1!
  • Let’s not forget Daniel’s ZoomViewer ! https://commons.wikimedia.org/wiki/Help:Gadget-ZoomViewer
  • Media viewer must provide a easy way to explain readers how to credit file's author.

• July 10 Multimedia Roundtable:
  • This would be a small enhancement to the Wikipedia experience of a *huge* number of people. I wouldn't put it high on my personal wishlist, but it would be nice. (Sage)
  • The subsection of the policy that was mentioned, is w:Wikipedia:Image use policy#Image galleries - The other related policy is w:Wikipedia:NOTGALLERY - I think the "spirit" of these policies, (the reason they were written and are enforced), is (1) to prevent editors adding massive galleries to the bottom of articles (page-size load problems) and (2) to prevent disputes over which images are worth including (Extreme example: Imagine all of commons:Category:Bananas and its subcategories in the article w:Banana) All are Curation-solvable. (Quiddity)

These roundtable comments were cited by Fabrice Florin (WMF) (talk) 17:26, 27 August 2013 (UTC)

Re-use this File

Reuse the file mockup

Also noteworthy are Trizek's recommendations on re-using a file from the Media Viewer, cited below (be sure to check his First mockup at the end):

Hello Multimedia team!

After the IRC meeting hour yesterday (many thanks to the team for this moment!), I have developed ideas for the media viewer, based on user experience and feedbacks collected on French Wikipedia.

"Show images in larger, media viewer panel when you click on them" is the first feature proposed, and an expected one! Image should be displayed bigger as possible, with (of course) a responsive system. The contributive options (buttons on the mock-up) are not a priority, I think: most people just want to see the image. Image description or "see more files" link should be put forward instead.

"Option to go to next image if it is part of a category or collection" should not be an option. People really want to see more files. You can see the files on an article, or, by a direct link, all images on the category. At the end of the presentation, we should add a "contribute" link. On Wikipedia, a link "see more files related to $page_title" will provide a great satisfaction to the reader. On Commons, we may have a link like this, but related to the adjacent or parent categories.

"Include a description and credit below the image, link to file page" is a good idea, which may be magnified: on Wikipedia, add the caption (the reader have the information linked to article, the context, the answer to "why this image has been chosen"). On Wikipedia or Commons, display information about the file (for example, copyrighted file because no-FOP, or POTY). On Commons, you mustn't forget the powerful system of annotations, which increase image quality.

A very important point is how to credit authors of free licensed files: I have collected many experiences about bad (or no) crediting during wiki-trainings or with my colleagues. This must be explained on the viewer, with a link or a button "reuse this file". Clicking on this link will display a how-to, ideally on three steps: image analysis, download choices (size, format) and how to credit.

All these ideas can be more easily understood with mock-ups. If you need it, I can join some images.

This viewer feature will also require substantial changes on Commons Files pages, in order to change the very bad interface. What do you think about it ?

I have asked the French community about testing this feature.
Keep in touch! Trizek (talk) 13:15, 19 July 2013 (UTC)

First mockup and Reuse the file mockup - Trizek (talk) 13:53, 24 July 2013 (UTC)

Cited by Fabrice Florin (WMF) (talk) 17:25, 27 August 2013 (UTC)

That looks clear and tidy. However, a link to the full text of the license is often required. This is what photographers are currently criticizing about our stockphoto gadget. It would be great if there would be a "credit API" so other tools and third parties can fetch it without having to compile everything themselves. Work that is already done in this regard listed at commons:Commons:Machine-readable_data#Usage (JavaScript, python, PHP (example) -- Rillke (talk) 13:20, 28 August 2013 (UTC)

@Rillke: Do you have an example of a license you're thinking of with a link to full text? Most that I can think of require a link to the license somewhere, but I'm not sure if you had something different in mind, and I'm curious. I'm hoping to get more involved in this project as time permits - I think our re-use story is something that would be great to improve for a whole bunch of reasons... -LVilla (WMF) (talk) 00:15, 5 October 2013 (UTC)

When re-using a work under CC-By-SA, for example, users are obliged to "include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform". Most sites that re-use files link, if they do at all, to the deed-version although this is not really "the License" but a short version. I am however not a lawyer (see you are :), though I believe it is the safest if one interprets URI as link and this License as the full-text-version, especially when taking the ported versions into account: vollständige Internetadresse in Form des Uniform-Resource-Identifier (URI) beifügen is explicit that URI is a full "internet address". Was this the answer to your question? Best -- Rillke (talk) 14:21, 7 October 2013 (UTC)

For CC licenses, I always read this as: "When you use the image, you should make the license as accessible to the viewer of the image as possible". So on the internet, a link to the original license text, in print a good description and where possible a full copy of the license (less feasible for posters, but very feasible in a book for instance). HOWEVER, I think that as a community we sometimes put a bit too much emphasize on this. It is our moral responsibility to educate and help the user, but it is not OUR responsibility for the user to actual fulfill the license of course. I think that we should emphasize the most important workflows and tool for that, pointing the user at his own responsibility to actually READ the license before using the image. We cannot tool for someone 3d printing an image on a speck of moon dust...

In CC, the biggest problem has been the credit statement I think, which should be copied 'verbatim'. With other licenses, the biggest problem is that we often default our information to things that might apply for CC, but not for some other situations. In those cases it might be better to default back to the full license text rather than make potentially incorrect assumptions based on the more common CC. TheDJ (talk) 22:46, 26 November 2013 (UTC)

SVG->PNG rendering

Currently commons allows for rendering of SVG to raster png at different sizes, in lieu of downloading the svg directly. This feature could be part of the Share/Use workflow (feedback during DivCon in Berlin) Jaredzimmerman (WMF) (talk) 08:35, 10 November 2013 (UTC)

+1. This feature is being used in many other wikis as an external gadget. If we can implement this feature to Media Viewer then when it goes global, all other wikis will be able to use it. — T. 08:58, 10 November 2013 (UTC)

As much as I like that feature, i think we should not mix up the technology implementation with the functionality. As a user, I want to download images in various sizes. For SVG, that might use the mentioned technology (or not). That's the user story I think and that is probably a better starting point than stating that we need to integrate the technology into the beta viewer. TheDJ (talk) 22:31, 26 November 2013 (UTC)

Issues reported by TMg

Issues 2 and 3

Here are my main and a few nitpicking ;-) issues I found while playing around with the viewer in the German Wikipedia today. Should I move this to Talk:Multimedia/About Media Viewer? Should I create Bugzilla reports for all this?

1. (Obsolete?) The "×" to close the window is on the wrong side. Simple as that. It's on the right everywhere (Mac OS, Windows, Lightbox, Lightbox 2 and every alternative). This is especially confusing since other beta features have it on the right too.
2. On typical netbooks with 1024×768 or 1024×600 screens the current implementation of the media viewer is pretty much pointless. The main feature is to enlarge images. Currently the image sometimes becomes smaller instead of bigger (see the screenshot). At least limit the image size to the thumb size the user clicked and never make it smaller. My proposed solution is to limit the image size to the inverse of the "upright" factor (1 / 0.75 ≈ 1.33). This also saves bandwidth and server power since it avoids creating pointless 219px sizes for 220px thumbnails.
3. The CSS fails on smaller screens (see the screenshot).
4. (Bug 56454) Clicking the "fullscreen" button in the upper right never makes the image bigger. Why not?
5. (Bug 56471) All symbols are missing helpful title attributes.
6. (Bug 56588) The "Use this file" part lacks every license information. This is bad. The proper attribution must be included similar to the current "Use this file on the web" implementation on Commons.
7. (Bug 56787, maybe 56497) The "Use this file on another website" part doesn't work on external websites. The <img src="https://...> works but the <a href="/wiki/...> does not because it's relative.
8. The UI elements are barely visible through the white background like they are "disabled" and faded out. But a click in the faded region does not reactivate the "disabled" UI elements. Please add this feature.
9. I find the faded white background very irritating (again, click the thumbnail on the right to see what I'm talking about). The wiki page is white. Clicking the thumbnail opens a "popup" that has the same color. It's not clear that this is a "popup". It feels like it's an other page and leads me to think I have to click the back button in my browser. Possible solutions:
   • Make the background opaque white. This helps a bit but is not ideal in my opinion.
   • Add a shadow to the image to make it look like it's hovering over the page. This will make it a lot more clear that the image is a "popup" that can be closed with the "×" in the corner and not by going back in the browsers history. I'm aware that this approach will fail for non-opaque PNG and GIF files. I'm sure this is solvable, e.g. by adding a white background and small padding to all PNG and GIF files in addition to the shadow.
   • Make the background black or dark gray instead of white. Similar to the shadow this will make it a lot more clear that the image is "hovering" over the white page. A slightly transparent black would be perfect.

--TMg 17:30, 27 November 2013 (UTC)

Some issues

• The "X" button is very difficult to find. It's very annoying to have to look around all over for it just to get back to the article.
• Before the image has finished loading, the X button isn't even there. If the image is taking forever to load, there's no real going back until it's done. Seems like a serious problem.
• Clicking on the image causes the X to disappear. I have no idea what that's supposed to accomplish, but it is very confusing when there is no visible way to escape image viewing mode.
• Ordinarily, browsers show images as they are being loaded. (That is to say, during the loading, the upper parts of the image that have finished loading are displayed, even though the full image isn't.) With the Media Viewer, this feature is gone, and the only thing shown is the "loading" symbol until the image is completely finished.
• The Media Viewer does not work for PDF files.
• I'm getting an odd stripe of white background across the gray area at the bottom that doesn't look intentional. Looks like a CSS bug.
• (This is probably an unusual kind of complaint, but...) Being unable to scroll outside a small range, with the outside article not scrolling at all, kind of results in a "trapped" feeling regarding mouse movement, at least for me. Anyone else get that kind of "stuck" vibe coming from this? (Scroll wheel claustrophobia, what's next... :P )

--Yair rand (talk) 05:33, 5 December 2013 (UTC)

• Also, the arrow key navigation is very annoying. In cases where the arrow keys are being used for something else, images popping up and covering the screen should not happen. --Yair rand (talk) 02:34, 10 December 2013 (UTC)
• The page mentions that "For future releases in 2014, we are considering these features: [...] Share (share this file on FB, TW and other networks)". IIRC, some of the projects, including Wikipedia, have pretty thoroughly rejected any social media integration. --Yair rand (talk) 02:59, 10 December 2013 (UTC)

Transparency

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

.mlb-image img { /* or using :hover */
 background: url("//upload.wikimedia.org/wikipedia/commons/5/5d/Checker-16x16.png") repeat;
}

or

.mlb-image img {
 background-color: white;
}

or

.mlb-image img {
	background-color: white;
}
.mlb-image img:hover {
	background: url("//upload.wikimedia.org/wikipedia/commons/5/5d/Checker-16x16.png") repeat;
}