Wikipedia talk:Media Viewer: Difference between revisions

Content deleted Content added

Inline

Revision as of 08:08, 7 June 2014

Welcome to the Media Viewer discussion on English Wikipedia!

Media Viewer is a new tool under development that aims to improve the multimedia viewing experience on Wikipedia and its sister sites. This multimedia browser displays images in larger size and with less clutter, providing a more immersive user experience, as described here. It was developed in collaboration with many community members around the world -- including over 12,000 beta users here on English Wikipedia, who have been testing it since November 2013. The current plan is to release this tool gradually in coming weeks: it is already enabled by default on a dozen pilot sites, and will be deployed more widely throughout May, as described in this release plan.

Can you share your feedback about this tool, to help address any critical issues before its release on the English Wikipedia? To try it out, please log in and click on the small 'Beta' link next to 'Preferences' in your personal menu. Then check the box next to 'Media Viewer' in the Beta Features section of your user preferences — and click 'Save'. You can now click on any thumbnail image on this site to see it in larger size in the Media Viewer. For more info, check out these testing tips or this Help page.

Once you've tried the tool, please share your feedback here, to help improve this feature. You're also welcome to take this quick survey -- or join this wider discussion on MediaWiki.org, if you prefer. Thanks for sharing your insights!

Test images

Here are some sample images for you to test Media Viewer with. To use this tool, check out these testing tips. Fabrice Florin (WMF) (talk) 01:28, 25 April 2014 (UTC)[reply]

Extended content

Pictures of the year 2013

Note that it takes about two weeks for new improvements to be deployed on English Wikipedia. To test the latest features, you can also use this test page on MediaWiki.org -- or if you are feeling adventurous, try this beta site, which is the most current, but slower and less stable.

Comments

Zoom feature, Use this File issues

There is no way to zoom in. This is a major, huge problem, which makes the Media Viewer less useful than simply using the article page the image is transcluded onto.

Using the image in a different website is also much, much harder than before.

Old workflow:

Click on image (move to image's page on en.wiki)
Click on image (move to upload.wikimedia.org's page)
Copy URL
Paste into other usage

New workflow:

Click on image (open's MediaViewer)
Find the "use this file" icon, hidden in the corner
Click on it
Click "Embed"
Click "HTML"
Copy the highlighted text (no way to copy only part of it)
Paste into other usage
Remove most of the copied text, which includes way more info than needed for copyright reasons.

Aside from these two major issues, and that there's no way to go the file page on en.wiki (the page that used to be reached by click on an image), it's very nice (although I'm still not sure what the point of it is). -- Ypnypn (talk) 02:30, 2 May 2014 (UTC)[reply]

Dear Ypnypn, thanks so much for your clear and detailed feedback, which is very helpful to us.

You make a very good point about the need to zoom in: we're now working on a basic zoom feature to address this request in coming weeks.

Your workflow analysis for 'Use this file' is also very useful. We are considering adding a direct file link in the Share panel, which would reduce the number of steps required to match the old workflow. We could also remove an extra step in the Embed workflow (e.g. select HTML by default), to save time. However, the HTML links were carefully discussed with our legal team, as well as other community members, who made a strong case for the need to provide credits and HTML links for the file page, author, license and file repository , to comply with the terms of Creative Commons and other licenses. In the past, people have very lax about giving proper credits and required links, which this HTML code addresses effectively.

In consultation with other community members, we chose to link directly to the file page on Commons or the actual file repository where people need to go to make file edits (instead of the duplicate enwiki page which cannot be edited anyway). The local file page on enwiki remains accessible, but it is not clear to us what purpose it serves at this time.

Thanks again for your good insights, and we look forward to improving this product based on your feedback. :) Fabrice Florin (WMF) (talk) 19:12, 2 May 2014 (UTC)[reply]

We measured the time it takes to load a file description page, and it takes over 3 seconds on average. The image itself might take a while to load, either. So while the old workflow might have less clicks, that does not make it faster, as it involves waiting for the browser to load.

You can get a direct URL to the file in the Share this file/Download menu, via the preview link (admittedly this is hard to find).

Also worth noting that using the code from the Share panel will protect you from mistakes such as using a raw SVG file (which might work in your browser but fail completely for your visitors).

Fabrice: the HTML option is selected by default if you are not logged in. --Tgr (WMF) (talk) 23:41, 2 May 2014 (UTC)[reply]

Intuitive trial

TheDJ suggested we try media viewer.

Knowing little about it,

used beta >
pref >
went to an article, e.g. Inferior temporal gyrus >
clicked [image size widget] under a thumbnail in that article >
entered image viewer >
clicked the viewer's [> widget] to successively browse the images of that article.
my navigation keys, (the < and > keys) work like the widgets. nice.

I immediately missed being able to read the text of the article while browsing. It's a whole new way to step thru the article. Is there a way to see the captions, at least?

my up / down navigation keys open/close up the provenance for the image.
is there a way to read the captions of my article this way?

Figured out a way

open up a 2nd browser
size them so that they can both fit side by side on the screen
article on the left, viewer on the right, use the navigation keys to step thru the images, as I read the article
when I use the expand widget on a small image, full screen takes over, instead of expanding to the size of the viewer's browser (not my full screen) and I have to rebuild the setup I described above.

Thank you for your work so far. --Ancheta Wis (talk | contribs) 13:01, 13 May 2014 (UTC)[reply]

Dear Ancheta Wis, thanks so much for your helpful feedback :). To respond to some points you raised, we have a few tickets under consideration in our development pipeline, which I think could address a few of your issues:

#589: Show caption above the fold in Media Viewer - What do you think of this proposal? (note this is a pretty major change)
#501: Don't move the metadata panel when going next/prev if it is not needed - What do you think of this proposal? (note this pretty easy to implement)

Which of these two solutions do you prefer? Either of these proposed changes could take a few weeks to develop and release on English Wikipedia, if they are selected. In the meantime, I am glad that you found a creative solution to address your immediate needs :). Thanks again for your good insights! Fabrice Florin (WMF) (talk) 19:24, 14 May 2014 (UTC)[reply]

Fabrice, I am replying about #589, as it looked the most promising for my problem. I am trying to follow content which I know about from my reading. But I have a problem: when I read Insular cortex using the method described above, I follow File:Human_brain_frontal_(coronal)_section_description_2.JPG ‎which has a nice description page from Wikimedia Commons: with numbered items 1. Medulla spinalis 2. Decussatio pyramidum etc. These are not part of the caption on the Media viewer as I try to read Insular cortex. Currently I disable Media viewer on the text browser, so that I can read the Commons description page on File:Human_brain_frontal_(coronal)_section_description_2.JPG . Then I can re-enable it after reading the article.

#501 does not help my problem. Regards, --Ancheta Wis (talk | contribs) 19:02, 20 May 2014 (UTC)[reply]

Looks like we should make sanitizing the description more permissive. --Tgr (WMF) (talk) 21:45, 20 May 2014 (UTC)[reply]

Background Color

Thank you for this new feature! I was wondering if the background color could be white instead of black, it currently looks very similar to the newly designed Flickr pages and I found it very confusing. I think the white would be easier to tell I am using a different program but also a more tasteful design. Jooojay (talk) 06:30, 6 June 2014 (UTC)[reply]

There seems to be a range of options on what would be best (white, black, transparent, semitransparent...), there is no way to make everyone happy. You can change it for yourself by setting

.mw-mmv-overlay { background-color: white; }

in your user CSS if you want. --Tgr (WMF) (talk) 19:39, 6 June 2014 (UTC)[reply]

esc to exit full screen probably shouldn't collapse the media viewer

In full-screen mode, Firefox advises me to use Esc to get back to non-fullscreen (windowed). However, after a stutter, this also causes the media viewer itself. Thus effectively you jump back two "levels" in one go (page->media viewer->fullscreen---->page), which took me by surprise. - Jarry1250 ^{[Vacation needed]} 22:14, 14 May 2014 (UTC)[reply]

This is Template:Bug. --Tgr (WMF) (talk) 22:23, 14 May 2014 (UTC)[reply]

Completely unnecessary

Considering the present ability to choose resolution on the image page, including native resolution, image zoom in/out and the full-screen function in most browsers. 76.113.29.108 (talk) 14:01, 27 May 2014 (UTC)[reply]

No big deal

Minor nuisance. Almost always my aim is to see the metadata. Captions, geocoords, etc. So, it needs an extra click. Probably the majority of readers, not editors, will differ. Jim.henderson (talk) 23:23, 3 June 2014 (UTC)[reply]

<nod> Thanks, Jim.henderson. Keegan (WMF) (talk) 23:43, 3 June 2014 (UTC)[reply]

How is this not a big deal if the loading time of this "Media Viewer" is horribly long and the file page link is not obvious? 192.12.184.7 (talk) 05:18, 4 June 2014 (UTC)[reply]

The loading time of the Media Viewer is actually substantially shorter than loading a File page. Here's the data. There is a perception difference because the File page remains a blank, white space while the entire page loads, whilst Media Viewer loads immediately and calls for the image. The more images are viewed, the more are cached, and even faster it gets. There will be tweaks to make links more prominent/accessible as we get feedback like yours. I appreciate it! Keegan (WMF) (talk) 06:07, 4 June 2014 (UTC)[reply]

Get rid of it!

The Media Viewer is utterly needless and makes a mess of big images containing lots of detail. It makes all the detail small and hard to discern. There was absolutely nothing wrong with the way things worked before. Abandon this project as a waste of time, an annoyance and anything but an improvement. Kelisi (talk) 04:16, 4 June 2014 (UTC)[reply]

Agreed. I know the need for Wikipedia to evolve, but why mess with a fundamental feature that worked perfectly beforehand? Peter Greenwell (talk) 05:11, 4 June 2014 (UTC)[reply]

But in the articles, media viewer activates only on a click. As I understand it, you can still read articles in the way we have been used to. I was coming to this talk page to provide feedback, to state that https://en.wikipedia.org/wiki/Marginal_sulcus#mediaviewer/File:Cingulate_sulcus_of_Vervet_Monkey.png has a very nice caption, as distinguished from some other images. For me, what the editor of this image set up was helpful to my search (I was searching for 'ascending ramus'). To the media viewer team, this might serve as a guide to use the media viewer. --Ancheta Wis (talk | contribs) 19:58, 4 June 2014 (UTC)[reply]

I believe it displays whatever description is on the description page at Commons. WhatamIdoing (talk) 17:30, 5 June 2014 (UTC)[reply]

Based on Tgr(WMF)'s response, there is a layer of filtering between the Commons description page and the Media Viewer description page. --Ancheta Wis (talk | contribs) 18:34, 5 June 2014 (UTC)[reply]

Yes, we remove all formatting except links. --Tgr (WMF) (talk) 20:08, 5 June 2014 (UTC)[reply]

+1 Agree, get rid of this please. If you want to make this the default for mobile platforms perhaps that's something worth investigating, but for the desktop please get rid of it. Let's make this a petition (or if there already is one, please link to it). Crazycasta (talk) 19:02, 5 June 2014 (UTC)[reply]

You can get rid of it for yourself. Untick the box that says "Enable Media Viewer." Petitions are not generally helpful on the English Wikipedia, since it is driven by consensus and not vote. If you have useful, fruitful comments and criticisms for Media Viewer other than that you do not like it, those would be great to hear so we can make a better product for you to use and enjoy as well. Keegan (WMF) (talk) 23:27, 5 June 2014 (UTC)[reply]

In the viewer, at the top right, there are little arrows to expand or contract the image.

Keegan, I followed the sequence and discovered that old UI cursor changes shape when hovering. The cursor has the little magnifying glass with (+) or (-) to expand or contract thumbnail images. How about using this in media viewer as additional functionality for thumbnail images ?

In media viewer, for [1] at the lower right corner, there are three widgets. Click on the middle one | preview in browser | cursor now displays the little magnifying glass with (+) or (-) to expand or contract fullscreen image.

--Ancheta Wis (talk | contribs) 12:00, 6 June 2014 (UTC)[reply]

I am only seeing two widgets, but whatever. That is completely unintuitive and seems to be unnecessary extra clicking. Why can't zooming be done right from where you are? Spinning Spark 13:17, 6 June 2014 (UTC)[reply]

Spinningspark, just based on my experience with one high magnification file it appears that the little magnifying glass with (+) or (-) needs to have an array of sizes of image to display. So MediaWiki will have to pre-generate the array of differently sized images before the zoom feature can respond quickly enough. Otherwise, special grahics hardware might be required? Also, MediaWiki will have to decide on the array of sizes to be displayed, so that they can use standard processing.

The arrow cursor morphs into a magnifying glass when it hovers over the image. But in Media Viewer, the arrow cursor appears to be insensitive to its location, whether it is hovering over image or just the black background.

I see that the image display software from Google search appears to be using a similar software base with the same inability to zoom that Media Viewer suffers. The image sizes appear to be hard-coded from the image sources there. The Google images are not uniformly sized, either. Just like MWF. --Ancheta Wis (talk | contribs) 18:51, 6 June 2014 (UTC)[reply]

Okay, fine, let me be more clear. There is absolutely nothing that I find acceptable about the new system. It does not work. It does not allow me to zoom (the quality just goes down but the picture doesn't get any bigger). The link for "More details on Wikimedia Commons" needs to be renamed because it took me about 3-5 minutes of clicking on this link and that link to figure out how to get to the old page. The pictures seem to load slower. Overall, when I want to see a larger version of a picture or zoom in on a picture the old system was extremely quick and useful for that. Click on the picture in the article, click on the picture on the next page, which was generally large enough to be very fast to move the mouse to and then use my browser to zoom in/pan as necessary. To conclude, I can not see any benefit of the new system and I see a lot of down sides.

As for how to get to the old page, something like "No media-viewer" or something would make more sense. However, most of all, I am appalled that this new system seems to have been pushed out against the wishes of the community. You talk about consensus, but I don't think there is any consensus whatsoever that this is a good tool for wikipedia. The only consensus I see is that this is bad and that there was nothing particularly wrong with the old system. As to your comment for disabling it, I regularly use computers other then my own, sometimes other people's computers (as opposed to just public computers). I don't want to have to log into my account on every computer I use just to disable this "feature". The only way I would accept this is as an opt-in feature. If you want to run banners or whatever at the top of the page suggesting that we might like to opt in to this new media viewer thing, fine, but please don't make it the default for what seems to be the majority of us. Crazycasta (talk) 08:30, 6 June 2014 (UTC)[reply]

I think you are looking at this too much from the point of view of an editor. The first priority must always be the experience of the reader. The encyclopaedia is here for the readers, not for the benefit of the editors, and what the reader primarily needs on clicking on an image is an enlarged version and not a lot of guff about copyright, history and the creator of the page. In that respect MediaViewer is a good thing. That's not to say that editor experience is not important, it is, but it is secondary. For one, I am happy to have an extra click in exchange for a vastly improved reader experience.

I think you are right about the zoom issue though. We can presume in the majority of cases that the reader clicked on the image because they want to zoom in on it. For some images even filling the window is not sufficient to be able to get all the detail. Example: File:All_palaeotemps.png which looks like this in MediaViewer with no way to be able to zoom in and read the small text legends. Even my browser's (Firefox) Ctrl+ zoom function does not work in MediaViewer. Of course, that would only make the image more pixelated if it did work, but it is strange that MediaViewer finds a need to suppress this. Spinning Spark 11:08, 6 June 2014 (UTC)[reply]

Crazycasta, I know it seems like Media Viewer is slower than the old system, but it's actually faster than the old system. It seems slow because it doesn't just hang there for a couple of seconds with a blank white page, but shows you all the steps that it's doing. Measuring from when you first click on the image to when the full image is finally displayed on your screen, it's saving you time.

I understand that an enhanced zoom feature is likely to be on the program for the WMF's next fiscal year (which starts on July 1).

As for the allegedly non-existent consensus, the survey results are showing so much support that Media Viewer might be able to pass an WP:RFA soon.

It's always important in these discussions to remember that people who dislike it are likely to complain, while people who do like it don't say much. After all, the person who has a problem usually has something specific and very informative to say (e.g., it urgently needs a zoom feature!), whereas the person who likes it can't usually say much more than "I like it" or "It works for me". "I like it" may be pleasant to hear, but it's not necessarily practical information, so most people don't bother posting it. The net result is that the team should be getting useful feedback, but you need to be very cautious about assuming that "people who had something they thought was worth posting here" is the same as "everyone". WhatamIdoing (talk) 19:46, 6 June 2014 (UTC)[reply]

@Crazycasta:: do you have any suggestions instead of "more details"? We want to avoid anything like "file page" or "description page" which is incomprehensible for the average reader.

As Keegan mentioned some sections earlier, we measure image load performance, and MediaViewer loads significantly faster than the file page. It is always possible we made a mistake or aren't aware of some special conditions which affect this for some users, so we are very interested in details (browser/OS type, screen size, time to load image in MediaViewer, time to open file page) if you perceive otherwise. See mw:Multimedia/Media_Viewer/Speed_reports.

@Spinningspark:: disabling Ctrl-plus/minus is kind of a side-effect. The way browsers handle zoom varies and is usually opaque to the application, so MediaViewer resizes the image immediately to fit the screen. We plan to fix that eventually, there was just easier and more useful stuff to do (and will be for a while, probably). --Tgr (WMF) (talk) 19:50, 6 June 2014 (UTC)[reply]

Copyright information

Media viewer seems to take the licence details from the information template. This frequently has only "see below" entered, expecting the user to be on the file page and see the licence templates immediately below. But this is meaningless and unhelpful in the media viewer. I noticed this after responding to an editor on the help desk. The "old hands" will soon learn the ropes here, but user's who are not editors and who just wnat to reuse the image are going to have a hard time figuring it out. Spinning Spark 23:47, 4 June 2014 (UTC)[reply]

Hey Spinning Spark: the licensing is taken from the HTML markup in templates, so even if {{Information}} template is missing or says something like "See below" the licensing has to be somewhere on the page and it picks that up and displays it. Media Viewer will display licensing and link to information about that license as long as there is some sort of license template anywhere on the File page. HTH. Keegan (WMF) (talk) 03:13, 5 June 2014 (UTC)[reply]

More (technical) information: Commons:Machine-readable_data. Keegan (WMF) (talk) 03:28, 5 June 2014 (UTC)[reply]

That is not correct, the licence template is not displayed by Media Viewer, it just displays "see below" with nothing underneath it. See for instance this example. One has to click through to the file page before the licence templates are displayed. How can you not think that is confusing, especially when the link the reader needs to click is above, not below that statement? Spinning Spark 10:48, 5 June 2014 (UTC)[reply]

I see what you mean. But all Media Viewer aside, I can't figure out why you, as the contributor, would put "See below" in the permission field. Why would you not just put {{CC-by-sa}} or however you choose to release it in the information box? How you are releasing your content is vital information for you to fill out. Why would you not have the permission parameter properly filled out and leave it to chance that your contribution gets separated from the licensing field? That in-of-itself is not Media Viewer's problem, it's the lack of structured metadata for files both on-wiki here and on Commons. Fortunately the Multimedia team will be taking up this work in the coming months with the Wikidata team to work on getting these licensing field inconsistencies in check. Keegan (WMF) (talk) 19:43, 5 June 2014 (UTC)[reply]

Bawolff has informed me that "See below" is the default for a ~~lot of upload tools~~ at least the {{Information}} template here on English. This is ungood; we'll work to find a solution here. Keegan (WMF) (talk) 19:46, 5 June 2014 (UTC)[reply]

Its also the default for the same template on commons. Bawolff (talk) 19:51, 5 June 2014 (UTC)[reply]

I suppose it might make sense to replace the id="fileinfotpl_perm" part of template:information/commons:template:information with {{#if:{{{Permission|{{{permission|}}}}}}|id="fileinfotpl_perm"|}} in order to make it more consistent with the intent of Commons:Machine-readable_data. Bawolff (talk) 19:54, 5 June 2014 (UTC)[reply]

@Spinningspark: In my volunteer capacity I added the above code to {{Information}}. Now when I open up your example in Media Viewer, it says "View license" that is clearly clickable and takes me straight to the file page. While this isn't the most elegant solution, it sure looks a heck of a lot better than an empty "See below" field. This will continue to get work, and thank you very much for noticing this. Keegan (talk) 01:54, 6 June 2014 (UTC)[reply]

Well thanks for the thanks! Spinning Spark 07:48, 6 June 2014 (UTC)[reply]

Request for Comment about Media Viewer

Request for Comment at Wikipedia:Media Viewer/June 2014 RfC. I am not voting but I see that a number of editors have expressed opinions, especially here on MediaWiki, and I think it would be beneficial for the English Wikipedia community to have a consensus about this issue. --Pine^✉ 07:57, 7 June 2014 (UTC)[reply]

@@ Line 187: / Line 187: @@
 ::{{ping|Spinningspark}} In my volunteer capacity I added [https://en.wikipedia.org/w/index.php?title=Template:Information&diff=prev&oldid=611742021 the above code] to {{tl|Information}}. Now when I open up your example in Media Viewer, it says "View license" that is clearly clickable and takes me straight to the file page. While this isn't the most elegant solution, it sure looks a heck of a lot better than an empty "See below" field. This will continue to get work, and thank you ''very much'' for noticing this. [[User:Keegan|Keegan]] ([[User talk:Keegan|talk]]) 01:54, 6 June 2014 (UTC)
 :::Well thanks for the thanks! '''[[User:Spinningspark|<font style="background:#fafad2;color:#C08000">Spinning</font>]][[User talk:Spinningspark|<font style="color:#4840a0">Spark</font>]]''' 07:48, 6 June 2014 (UTC)
+== Request for Comment about Media Viewer ==
+Request for Comment at [[Wikipedia:Media Viewer/June 2014 RfC]]. I am not voting but I see that a number of editors have expressed opinions, especially [[:mw:Talk:Multimedia/About_Media_Viewer|here on MediaWiki]], and I think it would be beneficial for the English Wikipedia community to have a consensus about this issue. --<font style="white-space:nowrap;text-shadow:#008C3A 0.1em 0.1em 1.5em,#01796F -0.1em -0.1em 1.5em;color:#000000">[[User:Pine|<font color="#01796F"><b>Pine</b></font>]][[User talk:Pine|<font color="#01796F"><sup>✉</sup></font>]]</font> 07:57, 7 June 2014 (UTC)