The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Community consensus is the Media Viewer will be disabled for non-logged-in users and logged-in users.
The consensus is clear. The community wishes that the Media Viewer will be disabled for the Non-logged-in users and the logged-in users. The result of this RFC is that the Media Viewer will be disabled. The RFA has been open for at least thirty days and everyone had the change to give their input and we should respect the outcome of this RFC. Of course individual users can still enable the tool in their preferences if they wish to do so. Natuur12 (talk) 19:53, 3 August 2014 (UTC)[reply]
An editor had requested comment from other editors for this discussion.
The discussion is now closed, please do not modify it.
The Media Viewer software feature was enabled on Wikimedia Commons as the default image viewer, for all users, on May 15, 2014. This was part of a scheduled rollout of the software feature to all Wikimedia wikis. Many Wikimedians have expressed opinions, especially on the MediaWiki wiki, about the software, and whether or not it constitutes an overall improvement when compared to the traditional file view. This issue has been the subject of some discussion here on Commons, and much more discussion on the MediaWiki page, as well as other places in the wikiverse.
Sample view of the new Media Viewer software
Above all, we should consider the value of this software in relation to the Wikimedia vision statement: "Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment."
Finally, some more specific points worthy of consideration (spelled out in more detail here):
Are all copyrights and personality rights adequately documented and protected?
Are (potential) reusers of content hosted on Commons shown a clear path forward?
Does the tool appropriately expose the strengths of Wikimedia Commons to our users?
The feature results from the work of a team at the Wikimedia Foundation. The main page describing the Media Viewer, its purpose, the history of its development, and links to the various forums where input and feedback was sought from the Wikimedia community, is here: mediawikiwiki:Multimedia/About Media Viewer
With all of this in mind, let's discuss whether this feature should remain enabled by default for logged-in users, and whether it should remain enabled by default for non-logged-in users.
This RfC will stay open at least 30 days, given all its ramifications.
FDMS 4 20:35, 27 June 2014 (UTC): Because changing such essential software behaviour on signup would be very confusing to new users. (See below for general comment.)[reply]
We must agree that we are the lab rats that have to test all betas because WMF's way to report issues or give feedback is so awkward; consequently if this is going to be activated for anons, it must be for logged-in users, too. -- Rillke(q?)14:40, 1 July 2014 (UTC)[reply]
Though I agree with you in theory, as a regular editor I am unwilling to commit the extra time it takes me to test this feature. When it was first announced I was willing to undergo some temporary inconvenience, but I notice that as time passes it just annoys me more and more. Jane023 (talk) 06:04, 8 July 2014 (UTC)[reply]
Per Rillke, and my rationale below for having Media Viewer enabled by default for non-logged in users. Design changes in any product tend to be opposed by the product's existing community at first, but I think it tends to help engagement in the long run. Media Viewer makes editing slightly more complicated, but in terms of design it is an evolutionary step in the right direction. It makes sense to first improve consumption, then production, even on Commons. Emw (talk) 09:59, 2 July 2014 (UTC)[reply]
It´s no problem anymore to deactivate it individually, so I don´t see any harm in offering it as a default. There might be people who like it and who wouldn´t find it otherwise. --Rudolph Buch (talk) 09:44, 7 July 2014 (UTC)[reply]
You mean for readers like me? My vote is below, in the disable section, thank you.
no, not you; "If Wikipedia is written by occasional contributors, then growing it requires making it easier and more rewarding to contribute occasionally. Instead of trying to squeeze more work out of those who spend their life on Wikipedia, we need to broaden the base of those who contribute just a little bit. Unfortunately, precisely because such people are only occasional contributors, their opinions aren’t heard by the current Wikipedia process. They don’t get involved in policy debates, they don’t go to meetups, and they don’t hang out with Jimbo Wales. And so things that might help them get pushed on the backburner, assuming they’re even proposed. ... If Wikipedia continues down this path of focusing on the encyclopedia at the expense of the wiki, it might end up not being much of either." guess who said that? Slowking4 ♡ Farmbrough's revenge01:02, 10 July 2014 (UTC)[reply]
It's an adequate way to present photographs; our mediocre downsizing abilities don't do the trick. However the selection presentation of meta information could be better. --Seewolf (talk) 13:37, 9 July 2014 (UTC)[reply]
Having looked at it again today, I've come around to it. Much like the recent Flickr UI re-design, the original version of MW was nothing more than a desperate grab for the attention of the instagram generation, so understandably anyone interested in anything other than simply looking at the picture, absolutely hated it. However, thankfully, this isn't Flickr, and I can already see that improvements are happening based on feedback. Enough to convince me the benefits already outweigh the disadvantages, and the gap is only going to get wider. And there's simply no point in making it opt-in, or restricting it to logged out users. Having said that, simply telling people it's not going to be disabled whatever you say because 'we know best', is very Flickr like - so WMF, please take note. You may not always be the only kids on the block as far as CC crowd-sourced knowledge projects go - and all your content is, of course, freely available to any other project who wants it, and thinks they have a better way of doing things. Ultra7 (talk) 17:38, 11 July 2014 (UTC)[reply]
As Rillke above and Bawolff below in the discussion section suggested, if we are to enable Media Viewer by default for logged-out users (which I support), we should do so for logged-in users with an option to disable (which we already have at the bottom of every MV view). Not doing so confuses new contributors who has to face an inconsistent change. whym (talk) 14:00, 14 July 2014 (UTC)[reply]
enabled for logged-in and not logged-in users. This tool is what I was looking for the past few years! If you read an article (doesn't care if on Wikipedia or any other wiki), you want to click on the pictures and browse through all pictures of the article. The Media Viewer gives you the possibility to also read the captions of the pictures in the article just by scrolling with your mouse wheel. When closing the Media Viewer, you are at the same point in the article you were before. Have a try here: [1]. Would you really want to click on every pic separately? Great tool, definitely keep it! --Xfts (talk) 10:39, 22 July 2014 (UTC)[reply]
Too confusing, and the image take too long to resolve. The button to the file view is far too small and inconspicuous. Sells Commons short by cycling through a few selected images. No one is likely to battle through to the full Commons category. Should be an option, sure. Johnbod (talk) 23:44, 27 June 2014 (UTC)[reply]
Too confusing, and doesn't present the information you would want to see, unlike the file information pages which do present the information you want to see. --Stefan4 (talk) 13:18, 30 June 2014 (UTC)[reply]
This tool hinders my access to information that I need about files. I used the tool for a few weeks but turned it off when I found that too often, it decreased my access to file information that I was seeking when I clicked through. Blue Rasberry (talk)14:29, 1 July 2014 (UTC)[reply]
Definitely. As a logged-in user you probably want to work on the file (its description, categories, etc.), not have a particularly fancy view of it. I don't have an opinion on what logged-out users should see. I do find the feature useful on sister projects, because it makes it faster to see images in higher resolution, but it isn't good if your goal is to edit the description page in some way. Anyone who really wants the feature can still enable it easily. darkweasel94 21:49, 1 July 2014 (UTC) I'm striking my opinion. I've meanwhile reenabled Media Viewer myself and it turns out that it is sometimes quite handy, for quickly going through the images in a category slideshow-like or if you just quickly want to see what one image shows. I'm now neutral on the default state for anyone. darkweasel9419:27, 9 July 2014 (UTC)[reply]
Wikimedia Commons is not an encyclopedia, it is a directory. This type of presentation would work good on an encyclopedia, but here, its counter-productive. However, I would suggest a compromise of incorporating elements of that design into Commons' normal interface in a way that is better-suited to our environment. It should not be used by default for anyone. ViperSnake151 (talk) 21:33, 3 July 2014 (UTC)[reply]
MediaViewer feature is clearly detrimental from an editing standpoint as has been revealed by the survey conducted by the developers. It sacrifices clarity and usablity for a new, entirely unnecessary, and still buggy "wow" factor. Access to information is hindered, it is harder to find alternate versions, file formats, and file sizes, etc. than the old system. It should therefore not be enabled by default for logged-in users. - S201676 (talk) 17:30, 5 July 2014 (UTC)[reply]
I personally like the Media Viewer feature, but it is still a bit rough and, at least at this point, I think it should be an opt-in feature, not an opt-out one. One thing I really appreciate is that, even when Media Viewer is enabled, clicking on the title of an image when viewing that image in a category takes me to the actual file page, while clicking on the image itself utilizes the Media Viewer. This makes it very easy for me to decide when to use the Media Viewer and when to go directly to the file page, which I really, really appreciate. Michael Barera (talk) 18:19, 5 July 2014 (UTC)[reply]
There are mainly two reasons I'm opening files (and I think that's the case for many users on commons) - either I'm assessing them for a photo challenge, POTY or QIC - then I need the picture in full resolution and not just full screen (and while I found the possibility to do that, it's not intuitive) - or I want to check something. In that case I'm interested in the picture description, its use in galleries or articles, if it's QI, FP or VI and its categories. Only part of that information is currently provided in the media viewer - and making changes is impossible. Therefore it's difficult for me to imagine that the media-viewer as it is now is useful to most users on commons. --Anna reg (talk) 18:37, 5 July 2014 (UTC)[reply]
It makes those of us who wish to edit/download/view at an alternative resolution jump through an extra hoop to get to where we want to be. Annoying and tiresome. Fry1989eh?18:40, 5 July 2014 (UTC)[reply]
I literally can't think of a single time where I ever found the media viewer to be anything other than an annoyance. Typical scenario: I want to view certain information about an image, such as its file size, history, assesments tags, usage, etc. I click on the picture expecting to be taken to the file page where I know exactly where everything is like the back of my hand. Instead the screen goes black and an ugly light gray bar with rudimentary information blinks into appearance taking up the lower third of the screen. wtf. Then an extremely blurry version of the image shows up and the site freezes for a few more seconds until the actual image loads.
The visual design is horrendous and reeks of Windows 8 (and not in a good way). Gray squares angles and lines are cut or placed off awkwardly on the gray background, and delineate gray text. It seems that every line of text is a different size which makes me unconfortable. The image name is present, but is missing the file extension, which makes it difficult to copy the name and paste it into brackets for use in a wiki page. In what appear to be a row of parking spaces (or awkwardly clipped squares) there lies a gray megaphone, a gray iOS 6 style export icon, and, incomprehensibly, a gray commons logo. I hover over the icons and wait a few seconds for each one to tell me what they do. Evidently the gray megaphone is for me to leave feedback, and when I click on it, a popup explodes in my face that takes me to surveymonkey. Not an elegant text box under the icon, a new tab, or god forbid, a link to this RFC. A popup.
Then I click on the the gray export icon. An oversized flyout appears (though at least it isn't a popup). There is a green "Download" button that seems to have been lifted from an ancient version of vine. And at least vine made the two lobes of its buttons the same size, unlike media viewer. Below the green button is some gray "view in browser" text that is accompanied by a sharp gray Windows 8 style picture icon that clashes with the rounded foamy vine button.
Then I go to the gray commons logo and click it... and... literally nothing happens. Evidently the first click just makes the other flyout dissapear. When I click it again, it takes me to the file page. Apparently whoever designed the thing wasn't creative enough to think of a way to represent the file page (or maybe just, idk, replace the vague icons with text??) so they just stuck a commons logo there.
Below the parking spaces are three lines of information, the uploader, the date, and the categories accompanied by three blurry gray icons (pixel alignment??). Beneath that is the file usage, with three pages listed for commons and three listed for other wikipedias. Of course the three that are listed for the other wikis are almost always going to be from the Arabic wikipedia because they decided to alphabetize it. Not the English wikipedia, even though I specified my user language as English in my preferences. To find the english usage you have to click on the "view all uses" link.
On the left is the image description. Everything seems to be in order, except I notice a small typo in the description. I look for the edit button, but alas, the WMF, so intent on increasing reader–editor conversion and sticking "edit" links, pencil icons, and "did you know you can edit this??" footnotes wherever there is room, has somehow neglected to include an edit button in the one place it might have been useful.
Because whoever designed the thing decided to overlay the gray bar on the image I scroll on the image to see the rest, only to find that apparently it just makes the gray bar grow and shrink (coupled with extremely irritating lag & jumpiness). There is also a gray chevron at the bottom that when I click it does the same thing. Incomprehensibly the gray chevron that points down makes the gray panel go up, and the chevron that points up makes the panel go down. And the up pointing chevron that makes the panel retract doesn't actually make the panel go away or turn transparent or anything. It just makes it smaller. Please please just do what Apple does & make the chevrons more intuitive instead of the morass of contradictions you've made here.
I have also yet to figure out how to zoom in this thing.
By this point I'm actually sick of the media viewer and I just want to go to the actual image page (maybe so I can fix that typo in the image description). I am not likely to understand that equals "File page", & so I click on the image to try and get there, but apparently the whole image is a dead zone, so I instead have to search for a relatively small button that is colored a slightly lighter shade of gray then the jumpy panel that says "More details about this file". Not "File page". Because whoever designed the thing thinks that we all know that equals "File page", they stuck a there, except this time in color. Perhaps for completeness, they saw it fit to tack on a light gray "The free media repository" beneath it for good measure because wherever there is a the tagline has to accompany it.
I click on the button (or the ) but literally nothing happens. Evidently you have to click the blue link inside the button to go to the file page, where I can at last do actual work like fix that description typo or something. On the file page I also discover that the image is a featured picture, and that there is a personality rights warning on it. Somehow this was not considered important enough for the media viewer's gray panel (while I am so glad that they thought I might want preformatted HTML code to embed the image on the website I apparently run, or that they thought it might be important for me to know that the image is being used on ويكيبيديا:ترشيحات الصور المختارة/صور مرفوضة/أرشيف).
Now whoever made this contraption might say that the media viewer's only use is to provide basic information about the file, and if you really needed the other information (like idk, the copyright tags??) you should just go to the file page. I wonder then—why do we even need the media viewer???. Most of what we Commons editors do is not oogling pictures, but uploading media, categorizing it, editing descriptions, and inspecting images at various zooms (like at FPC). The media viewer just slows us down.
Even though I am a designer I don't know if I could create anything better than the current media viewer, but I expect more from the WMF design team. As a designer I can clearly see that there are many things wrong with it which means that either they have no clue what they are doing, or, they are good enough designers to see all the flaws in the media viewer, and consciously deployed what they knew was a flawed product anyway.
Wow, I am sure the MMV team will be pleased to read such a comprehensive report and create a lot of tickets about what they want to improve. Let me just give some thoughts about things I know:
File extension missing: I think the purpose of the tool is to present something to visitors and not primarily helping experienced users to re-use files.
Green download button: That's the new Agora style that is also used on the login form. However, I saw a comment in the code that the MMV-team plans to use a button styled like those by Visual-Editor.
Gray commons logo: This is to indicate where the media file is hosted because on Wikipedias, it could be also on Wikipedia. Maybe worth consideration to make that message more clear.
Disable it, per the many comments above. Since pretty much everyone with a clue is disabling it individually, let's just disable the damn thing by default. - Jmabel ! talk19:48, 5 July 2014 (UTC)[reply]
Blimey! I recognise your user name from past edit wars. I never thought there was anything I could ever agree with you on, but as it happens, I also say disable it now please.
Disable it, per my vote below about non-logged in users, which I consider much more important in terms of reaching our strategic objectives; in combination with the point @Bawolff: makes, that it's problematic to have different default behavior depending on whether or not you have an account. -Pete F (talk) 23:34, 5 July 2014 (UTC)[reply]
Disable This is not Flickr but a wiki where anyone should be able to edit conventiently without wondering how the file description can be accessed. --AFBorchert (talk) 16:40, 6 July 2014 (UTC)[reply]
This would mean that the concept the MMV team has made up was fundamentally wrong. I suspect a viewer will never ship with edit-facilities. -- Rillke(q?)20:41, 6 July 2014 (UTC)[reply]
Disable We don't need two places where it is difficult to find and access the imformation we want to see and work with; the new Flickr is bad enough and we ahve no influence there. Here we can object and I'm against it. Larger images are too slow, just like Flickr and they take up too much space on the screen. Ww2censor (talk) 17:04, 6 July 2014 (UTC)[reply]
Disable I find the media viewer too annoying to be bothered to try and comment on it without getting even more annoyed. Jane023 (talk) 17:32, 6 July 2014 (UTC)[reply]
Disable. The thing was poorly designed from the start and as a result, it creates a genuinely terrible experience. Why we couldn't have gotten a normal lightbox for logged-out viewers is beyond my comprehension. —Mono (how to reply) 17:57, 6 July 2014 (UTC)[reply]
Disable - Useless and very disturbing, also if it would be work like a charme. I would say enable for logged-out, but there are to much drawbacks, as other people say. → User: Perhelion21:16, 6 July 2014 (UTC)[reply]
Unecessary and disturbing, most especially for Commons users and editors. It is hard to understand why this feature is being forced on all users in all wikis without a consensus. -- Alvesgaspar (talk) 15:12, 7 July 2014 (UTC)[reply]
Disable - Counterproductive for most of the people who will spend their time on Commons (i.e. people editing pages), anyone who is viewing images hosted on Commons as a reader are more likely to be doing so from a Wikipedia project. As an editor, MediaViewer gets in my way most of the time: 9 times out of 10, when I click on an image, I don't want to actually look at it, but instead want to do something with it (e.g. check for licensing, tag for deletion, etc). --benlisquareTalk•Contribs16:39, 7 July 2014 (UTC)[reply]
Disable Annoying and restricts access to information people should be able to see and edit such as categories. Most of us want to get under the hood/bonnet to see what's going on and fix it if necessary, and those who don't need to learn fast. HelenOnline17:04, 7 July 2014 (UTC)[reply]
Disable I commented on this topic in de.wiki here and here. The normal description page for each file here in Commons is much more useful, because it gives you better information about what you see in the file and how you can use the file. --MSchnitzler2000 (talk) 00:32, 8 July 2014 (UTC)[reply]
Disable Makes editing images less convenient. I don't get the whole idea - why restrict access to image informations? -- Clemens12:57, 9 July 2014 (UTC)[reply]
Disable - I was very surprised to see this pop up in my browser, The previous layout was much more easier to use and alot more helpful to everyone, Anyway In short this new feature is absolutely awful If I'm honest, Since the VE & Flow didn't work well I'd of thought lessons were perhaps learnt this time round but seems not. –Davey2010 • (talk)00:23, 10 July 2014 (UTC)[reply]
I feel a bit sad adding to this disable vote. I don't mind the idea of the tool, but it is a ruddy pain for me, verging on being a "Microsoft paper-clip" sort of pest. On my Mac, using shift or other keys as I was advised to do, does not neatly avoid opening in the viewer, the only way it does this is to open in a new tab or a new window, introducing pointless extra clicks to do basic viewing. A few minor changes in user functionality and this would have been fine, there seems to have been a lack of meaningful end user testing, presumably this aspect (fundamental to true Agile software development) is being skipped for reasons that the volunteer community are unaware of. --Fæ (talk) 05:15, 10 July 2014 (UTC)[reply]
Disable - an active editor, clicking on an image page, usually wants to know details of the source and subject, maybe to add or revise this information, and to copy a complete filename to paste into another article or another Wikipedia. MediaViewer makes the job much slower. Andrew Dalby (talk) 09:00, 10 July 2014 (UTC)[reply]
Disable, as it — among other disadvantages — still does not show the content of the credit-line template, which had been created especially to make correct attribution for re-users easier, and this despite the fact that the MV-team had been notified about this fault already on May 17th[2]. In this regard the MV is a step back, as it increases for re-users the risk of incorrect attribution and resulting litigation for copyright infringement. --Túrelio (talk) 18:40, 10 July 2014 (UTC)[reply]
Disable: My apologies for being long-winded, but many have asked for specifics in the RfC statemetns. Here are mine: The feature set is robust, well-built and well-designed, but does not fit the actual use of ENwiki (or any other EN space I know of). My reasons to revert to original functionality fall into three categories: Implementation: 1. Forced-adoption with no anon disable option on original launch; 2. The sudden and dramatic shift in user experience without appropriate research on usage patterns; 3. A pre-launch survey that conflated "useful" (something that can be utilised for a particular function) with "approved of" or "preferred" (something that should replace an existing product already in use for a particular function); 4. A pre-launch survey that featured most selection biases, every non-medical sampling-bias and several reporting-biases; 5. Lack of consensus for forced-adoption. Functionality: 1. No choice on which viewer to use; 2. Copyright misses; 3. Multi-license is obscured; 4. Full attribution is obscured; 5. Large images virtually unusable; 6. Zoom features disabled; 7. W3C & accessibility, especially disablement of keyboard control; 8. Transparency replaced with black in most cases (black symbol, like calligraphy, with transparent background becomes invisible -- old "white/grey checkerboard" avoided this, even for white symbols); 9. Non-intuitive icons and (especially) placement of icons and text; 10. Divisions in segmented text areas are not obvious; 11. Labels are missing or misleading on icons and text (Ex: "Unknown" below a title means "author unknown", which is certainly not obvious); 12. Misleading URL syntax, leading to problems with accessible browsers and some crawlers; 13. Lack of quick access to categories; 14. Ignores annotations completely; 15. Scrolling required in all circumstances, so scanning a row of images is impossible; 16. Image metadata cannot be viewed at the same time as the entire image. Social Engineering: 1. Lack of AGF and courtesy from some proponents during early flood of objections; 2. Misuse of survey data by some proponents in an attempt to disguise the level of objection; 3. A quick reversion to original functionality would have given project coordinators time to pause, reflect and adapt the solution in the face of overwhelmingly-negative response, but refusing to do so has violated users' trust in WMF; 4. Retaining the functionality when EN and DE Requests for Consensus/Comment have shown that people did not "just get used to it" would irrevocably undermine any WMF claim to community-focus on the eve of Wikimania 2014, the point where we are hoping to show the world the power of community-driven projects and the viability of the WikiWorldview. 159.53.110.14022:02, 10 July 2014 (UTC) aka w:User:Kevin159.53[reply]
Disable in its poorly implemented 'all or nothing' current form. My main problem is when used as a slideshow-er on galleries and categories, it breaks the licensing on many images, and it is not yet as good as our slideshow gadget described at Help:Slideshow (from a functionality perspective, at last). Most Wikimedia projects have established a general rule that licencing info & credits isn't needed on thumbnails provided the reader can click and see the real unfiltered licensing info with credits etc. This tool shows the licensing info & credits only for the simplest cases. This part needs to be 'perfect' - i.e. very close to perfect before it can be an alternative default viewer invoked from a click on a thumbnail, or it needs to be smart enough that it knows when it doesnt fully comprehend the licensing info and refuses to present partial and thus invalid licensing information. I hope media viewer will continue to be available on image pages, but it shouldnt be shoved down peoples throats 'all or nothing'. The 'Expand view' button is great - the reader has already seen the full image page - but I would place this button above or beside the image - it should be in the initial viewport, and please let me jump directly to fullscreen without going to through the intermediary stage. The 'Expand view' shouldnt be a slide shower by default - I do not want to see a huge icon of GNU, etc. That is silly. A slide shower on the image page only makes sense if there are alternatives of the current picture, and we do have metadata which currently describes that, which the media viewer does not present nicely. John Vandenberg(chat)22:31, 10 July 2014 (UTC)[reply]
Disable: Individual license template are not visible, a click on a photo should first bring the file description page. --Tuxyso (talk) 09:25, 11 July 2014 (UTC)[reply]
Disable: The UI is confusing. It creates more usability problems than it solves. Besides: Broad changes like this should only be implented if there is a consensus amoung contributors. Yes, this means asking us in advance and take our objections seriously.---<(kmk)>- (talk) 09:12, 11 July 2014 (UTC)[reply]
Disable, because on small-scale monitors like the ones of quite popular netbooks one clicks on an image (f.e. commons POT), has to wait several seconds in front of a black screen and gets an image that isn't much larger then the orginal one. Without the media viewer the waiting time is shorter (or at least it feels so) and the displayed image is larger. Without a smooth zoom function this piece of software is a step backwards. I don't need Wikimedia projects for fancy crap that only works on the big screens of screen workers, I can find that shit everywhere else. -- 32X (talk) 00:39, 12 July 2014 (UTC)[reply]
Disable Confusing UI, not really useable on small displays, not handling user license templates correctly leading to CV. -- Smial (talk) 13:09, 16 July 2014 (UTC)[reply]
Disable I really wanted to like it because it looks nice, but in the end it is just annoying and severely disturbs the workflow :-( --El Grafo (talk) 14:57, 16 July 2014 (UTC)[reply]
Disable that crap. Am wondering wether the guys who invented this stupid feature ever ever did some editing on the Commons. If you#re trying to edit, categorize or do whatsoever with the files the feature is hindering you. It's stupid. Are they nuts? --Matthiasb (talk) 21:20, 18 July 2014 (UTC)[reply]
Disable: The viewer is poorly designed for either of the tasks a logged-in user is likely to do: curating material, or selecting material for use in other projects. --Carnildo (talk) 22:59, 23 July 2014 (UTC)[reply]
Disable: I haven't read a comprehensible description of alleged advantages. The only possible advantage I can see is it looks a little like Facebook's presentation and there a billions (or whatever) Facebook users. But much as I dislike Facebook, I think it would come up with a better format than this. At the very least make it really really easy to disable the feature!!Carolmooredc (talk) 23:15, 23 July 2014 (UTC)[reply]
Disable - MV allows less access to licensing and history information, therefore complicating the clean-up of copyright vios and other work which requires such access. — Crisco 1492 (talk) 02:05, 24 July 2014 (UTC)[reply]
Opt-In It should be opt-in for logged in users. I personally like it quite a lot, but others may not. Change bothers people. Zellfaze (talk) 02:34, 27 July 2014 (UTC)[reply]
Disable for reasons adequately explained by others. Instead, consider adding a "V" link to thumbnails to allow users a choice between viewing normal media description pages and this viewer. That might provide the best of both worlds. Furthermore, please do not make such default across the board changes without full community discussion and a lot of wasted effort could have been saved. -84user (talk) 09:56, 28 July 2014 (UTC)[reply]
Disable – Causes too many problems with few advantages to outweigh them, as detailed above. I gritted my teeth for a while and left it on to see if I would warm up to it – I didn't. Those that have are free to opt-in. CT Cooper ·talk18:46, 2 August 2014 (UTC)[reply]
I agree. On English Wikipedia, votes of this format are considered to reduce to the concept "I don't like it" and are supposed to be ignored by the closing administrator; I hope that is the case here as well. (If @Ordercrazy: is truly only concerned about his/her workflow, disabling the feature seems like a simple enough solution.) -Pete F (talk) 21:01, 6 July 2014 (UTC)[reply]
It IS selfish. After all, it is ME spending my personal sparetime here. I voted to disable the mediaviewer for both, anonymous users and editors, for different reasons. You might call the media-viewer elegant and "modern" - i simply call it an annoyance for editors and users in its present form. When i take a look at the current numbers of this RFC, i'd rather call those "selfish", who enabled the media viewer by default. Thanks for making my sometimes annoying hobby more annoying _and_ calling my opinion "selfish". But who am i to critizise or raise my mouth? - Just one of those usesless and ignorant bastards who create all this questionable content on commons and wikipedia. Feel free to ignore this selfish a***le. --Ordercrazy (talk) 05:54, 7 July 2014 (UTC)[reply]
Whoa there tiger! I'll let Rillke speak for himself, but..I certainly don't call MV elegant or modern, I think it's awful. I only wanted to draw attention to the difference between votes that talk about a personal opinion, vs. votes that engage with the idea of what the feature is like generally for the class of users it is enabled for. It's fine to vent your personal frustrations -- I have no problem with it -- but you should realize, it will probably be disregarded by the closing admin, who will be looking for more broad reasoning. -Pete F (talk) 06:00, 7 July 2014 (UTC)[reply]
Discussing on any Wikipedia-related project tend to create little use and lots of frustration. In more than ten years on this project i got really good at staying away from any discussion, but sometimes still fail. I promise to work harder on getting even better in ignoring rfcs & discussion at all. --Ordercrazy (talk) 06:20, 7 July 2014 (UTC)[reply]
I knew there was more behind. Great to see the full reasoning. It will certainly help the MMV team to better understand your disapproval. -- Rillke(q?)06:27, 7 July 2014 (UTC)[reply]
Its even more complicated. Quite lot of german editors "saw the MV coming", and as quite many of us i was partially aware of the pre-activation rfcs&discussion on meta and commons well before the global activation. I even checked it out in the beta, and i knew i wouldn't like it firsthand. Thought to give it a try for a few weeks. I did, and i'm still annoyed. So why didn't all of us "editors and photographers" speak out beforehand? I can only speak for myself: I'm tired of discussing. I try to create content or at least to organize or teach, and i heavily try to stay away from discussions, for those discussions tend to harm motivation of all participants and sometimes even derail. My time here is limited, and as most of us, i often spent too much time here. I decided years ago to focus my time here to create, to have impact, to do good, to be productive and to cut endless babble as far as possible. I didn't mean to be harsh with my initial disable+comment - but i have the illusion to work here, and the mediaviewer (and my will to really give it a try!) made my work here more complicated and occasionally annoying. --Ordercrazy (talk) 07:00, 7 July 2014 (UTC)[reply]
Just wanted to point out that i definitely appreciate your will "to listen and to ask for reasons", and i feel a bit sorry for all those developers that most of us "editoring-focussed people" seem to have no (more) motivation to talk or even participate in further development. If i look at the latest major ui-changes like Visual Editor or MV, i feel bad for the developers and all this time and personal involvement spent for moreorless complete rejection and refusal from those editors who refused to discuss beforehand. I aknowledge this problem, but don't have a silver bullet at hand or in mind to solve this problem either. --Ordercrazy (talk) 07:13, 7 July 2014 (UTC)[reply]
FDMS 4 20:35, 27 June 2014 (UTC): Because it is a much better replacement of the (unfortunately still default-enabled) slideshow gadget and one can still access the filedesc pages via the (formerly redundant) text links (in categories).[reply]
Media Viewer is a major improvement for what is probably the main use case for clicking on an image -- simple media consumption, especially viewing images at higher resolution. The UI is beautiful. Having Media Viewer enabled by default thus seems appropriate for non-logged-in users, i.e. readers, consumers.
That said, it would be nice if Media Viewer evolved to have more curation features. It currently obscures them, making it more difficult to edit media information. Having two very different UIs for viewing and editing is not ideal. Left as is, my impression is that the Media Viewer UI will increase engagement among readers, but stunt the conversion of readers to contributors.
Those improvements can come in time, though. As a Commons contributor I have learned how to maintain my familiar workflows. While I have some quibbles about Media Viewer, I think it's substantial boon to user experience overall. It should be enabled by default. Emw (talk) 14:33, 29 June 2014 (UTC)[reply]
Useful to visitors. Unfortunately the majority is really only interested in visiting and would never edit - not to even think about something complicated like re-mixing. Once our file description pages look more useful, perhaps it could be re-considered but as of now, it's the best way to appreciate our media collection. Rillke(q?)14:38, 1 July 2014 (UTC)[reply]
It's an adequate way to present photographs; our mediocre downsizing abilities don't do the trick. However the selection presentation of meta information could be better. --Seewolf (talk) 13:38, 9 July 2014 (UTC)[reply]
Very nice for visitors who are our "customers", as I see them. We should take care of them. --Karsten Meyer-Konstanz(Diskussion) 09:11, 11 July 2014 (UTC)
Since we don't allow logged-out users to contribute files, vieweing experience is a primary concern for those users. I think the current Media Viewer as a viewing feature has matured (with room for fixes to come, of course) to replace the old view. whym (talk) 13:54, 14 July 2014 (UTC)[reply]
Too confusing, and doesn't present the information you would want to see, unlike the file information pages which do present the information you want to see. --Stefan4 (talk) 13:18, 30 June 2014 (UTC)[reply]
If this tool is activated for users who are not logged in then that creates a barrier between them and the design of the file page which contains elements inviting them to remix the file or develop it in Wikimedia Commons or other Wikimedia projects. This should be deactivated by default to help new user experience. Blue Rasberry (talk)14:31, 1 July 2014 (UTC)[reply]
MediaViewer does not seem to fix supposed issues with the file pages in a way that does the least amount of harm. At the very least, a casual reader, the kind of person most likely to not have an account and not logged in, wants to see a bigger version of a picture when they click on an image. Fine - then just make the default preview display on the file page larger than 800x600 or whatever it is, and keep everything else as it was. At one level higher in sophistication, a reader might want to download and use an image. They need to have immediate access to copyright/use requirements - conveniently displayed on the regular file page - and immediate access to a variety of image types/sizes to best suit their needs. The file pages doe this, MediaViewer does not. - S201676 (talk) 17:35, 5 July 2014 (UTC)[reply]
Disabled by default. Back in February, I pointed out some criteria that, to me, seem central in designing the software, and now I think they are also good criteria for evaluating whether or not the software is suitable for being enabled by default. I'll refer to them by number here:
Copyrights and personality rights are not adequately protected. Others have rightly delved into the issues around copyright; but I think the issues around personality rights are far more troubling. We have, in COM:IDENT, a guideline that makes it important that the uploader of a photo of people in private locations clearly assert their belief in the subject's consent. That guideline does not require them to use a template, and the template that currently exists for that purpose is a very incomplete tool. So just pulling in the template, when the important information is often communicated in other ways, is inadequate. But copyright and personality rights need to be dealt with in a way that honors the rights-holders -- not merely one that complies with the letter of the law.
We have not shown reusers a clear path forward. There are many kinds of reuse; one that we care highly about is being able to place an image into a wiki page. With the standard software, with a small amount of experience, a user learns that copying the file name from the top of the image page lets them get what they need; then they can paste it into a wiki page and do any number of things (link to the file, add it to a navigation template or a gallery, create a thumbnail with a caption, etc.) by adding a little more code. Many somewhat-experienced users (like the students in my Writing Wikipedia Articles course) are used to that workflow, and have worked hard to become regular Wikipedia contributors. But with the Media Viewer, the information they need is two clicks further away: first they have to click the "share" icon (and I have no idea what would lead them to guess to click that), and then they have to click "Embed" (again, a word they don't associate with placing a photo on a page). Once they get there, they don't have the simple file name -- they have a string like this: thumb|Pre-loaded caption, who knows how suitable. Unneeded underscores in the file name, and an unjustified assumption that they are looking for the "thumbnail" function, as opposed to any number of other possible uses.
The Media Viewer does not sufficiently expose the strengths and edit-ability of Wikimedia Commons to the end user. Most importantly, the existence of the "Media Viewer" means that a huge proportion of the pages on our projects have been changed from having an "EDIT" button in a familiar location, to having no suggestion whatsoever that readers are encouraged to improve what they find. This is appalling to me, I can't even begin to imagine how this got so far. It is at odds with our top-level strategic priority of increasing participation, full stop.
There are other problems at the strategic level -- it's hard to see how this improves quality from a reader's perspective when it is such a departure from existing design, and it's hard to see how innovation is encouraged in an environment where massive changes like this are implemented without adequate vetting.
This feature needs to be disabled, lest our readers forget that we invite them to join our cause, or that we consider it important to facilitate productive communication among a wide variety of stakeholders around the sharing of content. -Pete F (talk) 23:29, 5 July 2014 (UTC)[reply]
Though I think all are lofty goals, they were never going to be fulfilled by the first phase of MMV. MMV is just a building block, not a complete house. You have to take the long view.
Copyrights and personality rights. That is only ever going to be fulfilled after building structured data for Commons (next on the roadmap after UploadWizard quickfixes, but heavily delayed due to MMV ruckus).
Yes, so one heavily broken workflow was broken for one that is also quite broken. I understand it's disruptive, but of course neither is a good path forward. The only thing that can help there is Media insertion and upload straight from the edit page. This requires significant investment in a 3rd area (WikiEditor and VE), that is now no sooner than 2015 I suppose, but the Uploadwizard fixes are probably blockers for that.
There are contributory functions planned for the 2nd phase of MMV, but that has also been heavily delayed now.
What is my observation, is that this project went from a simply 'lightbox' image viewer into a much too complex 'experience'. It should have been kept much simpler and much more 'in page'. That would have solved nothing of the above, but would have kept the surface area for critique much smaller. I have also totally giving up on beta testing features. Experience over the last year shows it simply doesn't work. People only become involved if they are confronted with it and just ignore it until that time. More iterative smaller public releases at a faster pace seems a healthier approach, that garners a lot better and a lot more feedback. TheDJ (talk) 09:24, 7 July 2014 (UTC)[reply]
@TheDJ: I do take the long view; as I have stated before, I think there is a great need for a better interface than the existing wiki page associated with images. But (A) in the short term, the Media Viewer is a very substantial step backwards; and (B) the process used for creating it tends to drive many volunteers with useful information to contribute away from the process of iterating toward success. The combination of A and B, in my view, does not paint a rosy picture of the distant future. -Pete F (talk) 20:06, 14 July 2014 (UTC)[reply]
Disable -- Major changes to Wikipedia should be introduced as an option, preceded by extensive beta testing, notification and discussion, esp when the proposed change (in this case Media Viewer) is plagued with bugs and shortcomings. -- Gwillhickers (talk) 05:06, 6 July 2014 (UTC)[reply]
Disable Everyone should get direct access to reuse information and the description. The Media Viewer currently operates as an obstacle which makes it hard for occasional anonymous users to edit a file description. --AFBorchert (talk) 16:43, 6 July 2014 (UTC)[reply]
Unecessary and disturbing, most especially for Commons users and editors. It is hard to understand why this feature is being forced on all users in all wikis without a consensus. -- Alvesgaspar (talk) 15:13, 7 July 2014 (UTC)[reply]
Disable Annoying and restricts access to information people should be able to see and edit such as categories. Most of us want to get under the hood/bonnet to see what's going on and fix it if necessary, and those who don't need to learn fast. HelenOnline17:06, 7 July 2014 (UTC)[reply]
Disable Hides things I'd like to see when using a viewer. Even as a user (in not editor mode) the information and details of the image are just as important as the image itself. MV does not offer both well. Saffron Blaze (talk) 00:14, 8 July 2014 (UTC)[reply]
Disable Not the experience an unexperienced user would expect. Most important metadata is hard to find out. Does not provide the maximum resolution of an image.--Aschmidt (talk) 16:23, 9 July 2014 (UTC)[reply]
Disable Horrible, intrusive, invasive cruft. If the object is to provide people with a larger image at first click, redesign the info pages to have a larger thumbnail. For me, a user who hasn't logged in or edited an article in years (I have started and edited articles in the past), it's a terrible piece of useless code that stands between me and what I wnt to do. —Preceding unsigned comment was added by 69.140.0.55 (talk) 23:03, 9 July 2014 (UTC)[reply]
Disable - I was very surprised to see this pop up in my browser, The previous layout was much more easier to use and alot more helpful to everyone, Anyway In short this new feature is absolutely awful If I'm honest, Since the VE & Flow didn't work well I'd of thought lessons were perhaps learnt this time round but seems not. –Davey2010 • (talk)00:23, 10 July 2014 (UTC)[reply]
Disable - I am not so certain of this as I was for "logged-in users", but I haven't noticed anything good that this Viewer offers to less-active users of Wikimedia. And some non-logged-in users, the most useful ones to thge project, want to do the same thing that logged-in users often do -- i.e. add the file to other pages where it will be useful. This Viewer makes the job slower, so, disable it. Andrew Dalby (talk) 09:06, 10 July 2014 (UTC)[reply]
Disable, as it — among other disadvantages — still does not show the content of the credit-line template, which had been created especially to make correct attribution for re-users easier, and this despite the fact that the MV-team had been notified about this fault already on May 17th[3]. In this regard the MV is a step back, as it increases for re-users the risk of incorrect attribution and resulting litigation for copyright infringement. --Túrelio (talk) 18:41, 10 July 2014 (UTC)[reply]
Disable, for the same reasons I gave for logged in users, and I think it is unwise to have this feature opt-out for IPs when they are opt-in for users. I would want this to be first opt-out for users, and I do believe that with a bit more work that is achievable, then deployed to IPs after a short period of acceptance testing by the community. John Vandenberg(chat)07:26, 11 July 2014 (UTC)[reply]
Disable see Túrelio, unclear attribution for re-users, individual licence template are hidden, file description with additional information should appear with one click. --Tuxyso (talk) 11:23, 11 July 2014 (UTC)[reply]
Disable No advantage for project work. Commons and WP are not a photo community. Therefore applies also to sole users of the project. -- Хрюша??05:27, 12 July 2014 (UTC)[reply]
Disable -- Normally I would not bother to pile on to such a lopsided SNOW vote, but since the WMF is apparently counting !votes, I will. I don't think spending Foundation donations on this should be a priority, but since the effort has already been made, perhaps a few tweaks to functionality might make it acceptable. Wbm1058 (talk) 22:40, 14 July 2014 (UTC)[reply]
Disable Confusing UI, not really useable on small displays, not handling user license templates correctly leading to CV. -- Smial (talk) 13:09, 16 July 2014 (UTC)[reply]
Disable for consistency, and see my comment for logged in users above, suggesting a "V" link for everyone as compromise. -84user (talk) 10:01, 28 July 2014 (UTC)[reply]
Disable – More debatable than disabling it for logged-in users, as Media Viewer seems to be aimed at readers and it's harder to opt-in again as an unregistered user. However, I've concluded there are still too many problems around not showing readers the full file and licensing information. CT Cooper ·talk18:53, 2 August 2014 (UTC)[reply]
It is precisely on the " specific points worthy of consideration" above that Media viewer falls short. If it is to be enabled for non-logged-in users, it is very important that it be much more capable of showing them exactly how to attribute correctly if they reuse the image. Otherwise, it is an almost sheer liability, because it hides most of the information relevant to that "below the fold". Remember, these are people already on Commons, not people looking more closely at an image in a Wikipedia article, and they are very likely to be looking for information about the image and/or planning to reuse the image. - Jmabel ! talk19:52, 5 July 2014 (UTC)[reply]
I think most visitors in Galleries are here because they followed a link on their Wikipedia offering more media for a topic or a Google search. Also note that once they are on the file description page (e.g. by clicking the Commons-Link in MMV running on their Wikipedia), MMV doesn't do anything. -- Rillke(q?)10:03, 6 July 2014 (UTC)[reply]
Is the decision if a picture is opened by the MMV or not by clicking on a picture on a wikipedia a commons or a wikipedia decision? If it isn't a commons decision, should that use still be part of the discussion here (as I think they are less likely to fully come to commons with the media viewer - which seems to be the idea)? --Anna reg (talk) 12:21, 6 July 2014 (UTC)[reply]
When a visitor visits Wikipedia and MMV is enabled by default on this wiki and the visitor does not open the image in a new tab, MMV will be shown and not our cluttered file description page, thus Commons will get less traffic. On the other hand, if a visitor follows a link to a Commons Gallery, the outcome of this RfC is relevant. -- Rillke(q?)20:45, 6 July 2014 (UTC)[reply]
I'm finding this discussion, and the specific scenarios described, difficult to follow in general. @Rillke: your last comment seems wrong, unless I'm missing something -- if the user is looking at a gallery on Commons, and then clicks on an image, isn't the resulting behavior exactly what this RfC is about? Currently, MV is enabled on my account; when I look at the gallery Bob Marley and then click on an image, the MV pops up. If MV is disabled by default, that will not be the case. Right? -Pete F (talk) 20:55, 6 July 2014 (UTC)[reply]
My apologies -- apparently I can't read. (I somehow saw "irrelavant" not "relevant".) Pete reaches for coffee cup... -Pete F (talk) 21:06, 6 July 2014 (UTC)[reply]
Hey, no point. Glad you are asking. As for hard-to-follow; we are just wondering how relevant would be a decision at Commons at all and who our visitors are, what they primarily want to do at Commons, ... I think without knowing this, it's pretty hard to make a good decision. -- Rillke(q?)21:30, 6 July 2014 (UTC)[reply]
A slide depicting WMF's view of the users this (and other) software should serveSo yes, when you put it like that -- you are discussing the most central thing that bothers me about all this. The way I see it, WMF has made a series of decisions over a number of years that make it very difficult for them to accurately assess questions like this for themselves, much less guide an international community of volunteers in developing a shared understanding. Without turning this into an essay, I will summarize this -- the WMF has made very conscious decisions to disregard social dynamics in its community, and deprioritize hiring people with relevant expertise, or creating or maintaining programs that develop that knowledge. So now, we have one of many substantial decisions that was made based on an overly simplistic and distorted view of the social system that is Wikimedia. To the right is a slide from the Multimedia team that shows the kind of thinking that informs this and other projects. There are lots of other artifacts from their process (check the parent categories), but this one seems evocative to me: it shows a very idealized version of how things might happen, which I'm sure facilitates smooth design processes, but it doesn't go very far to ensure that stakeholders' needs are met in the final product. I'm afraid this software is not the last controversial output we will see from this system.
i kinda like the fault tree diagram: better a simplistic analysis of the system than none at all. and pain points everywhere, which is realistic. if every change is controversial, and the community tunes out feedback until implementation, then they might as well "disregard social dynamics": they can't win no matter what. the community needs to give feedback, or be prepared to live with the result. although, they did disregard your advice, and got egg on their face. maybe the foundation would be interested in an wikiproject editor feedback process. and yes, we should expect all change to be as drama filled as this and VE, since there is no change in the "dialogue". Slowking4 ♡ Farmbrough's revenge20:19, 7 July 2014 (UTC)[reply]
On another note -- thank you for clarifying some technicalities of how the outcome of a decision will play out, vs. a decision on other projects. I misunderstood, and am glad to have this spelled out more clearly. -Pete F (talk) 04:47, 7 July 2014 (UTC)[reply]
Erm … before MV was introduced on Wikipedias, visitors there didn't get to Commons filedesc pages directly either, instead (by default) just to local copies. So where exactly is the difference (traffic-wise)? FDMS 4 09:10, 7 July 2014 (UTC)[reply]
@FDMS4: Under normal conditions we did directly end up at the commons page when clicking at an image in the german wikipedia. The thread "Plötzlich Standard?" on the discpage, says that function was standard since the 28th june 2012. Exeption were only those images stored locally with the de.WP - thats just a fraction. Alexpl (talk) 07:24, 10 July 2014 (UTC)[reply]
As a Wikimedia user, reader, editor, volunteer and donor, I support any decision able to reduce the money spent over this extension. --Nemo00:41, 12 July 2014 (UTC)[reply]
I'm not going to comment on this in general (at least not currently), however I am strongly opposed to having the default enabled/disabled status of the extension differ based on if the user is logged in. My past experience (mostly on en wikinews with the FlaggedRevisions extension), is that when the experience for a logged in user differs significantly from that of a logged out user, issues/bugs that come up do not get reported (as anons don't know how or don't care, and logged in users don't see it) and the entire situation is just more confusing. Please, whatever is decided, keep the default experience consistent between logged out and logged in users. Bawolff (talk) 19:23, 29 June 2014 (UTC)[reply]
I agree @Bawolff: . Hopefully the consensus on the two questions will be similar; if not, the closing admin will have a challenging job. I would imagine there are technical measures that could smooth the transition a little if necessary... -Pete F (talk) 17:50, 5 July 2014 (UTC)[reply]
I'd like to address some concerns expressed above:
Disabling is possible for anonymous users. There is a link on the very bottom of the page called Disable Media Viewer.
access to copyright/use requirements — People who care will find or do not need more explanation than CC-By-SA 3.0
and immediate access to a variety of image types/sizes to best suit their needs — offered by MMV with a single click on the use this file icon.
Generally, I believe our file description pages are too cluttered to be useful. MMV "hides" a lot of information by default but that way it is a lot more pleasing to watch files. So what's the user's primary intention? Reading information about licensing, authors, or watching images? I think the latter, most of the time. -- Rillke(q?)18:32, 5 July 2014 (UTC)[reply]
You are probably right for anonymous users. For users not browsing, but doing something on commons, it's reading the information and not watching the images - at least in my opinion.Anna reg (talk) 18:39, 5 July 2014 (UTC)[reply]
Personally I agree with Rillke. The file description page contains a lot of data; but not well organised or visually appealing to visitors/viewers. So an intermediate layer like "media viewer" between article page and file description page is a wise decision. But it was launched with a lot of bugs which attract a lot of hate, initially. Even if it was launched after fully tested and error free, I don't expect experienced users prefer it. They will still prefer a powerful interface where they have more options to edit and alter, even if the interface is not visually appealing. (This is just like programmers prefer to directly edit the database than through a front end.) So I don't expect the "regulars" here will ever accept Media Viewer as default (as I told to @Peteforsyth: when he plan such a RfC).
But I don't think "disable by default" will do any big harm to the Media Viewer project. I still hope the team will not get discouraged, work hard to fix all bugs, add new features/enhancements that slowly attracts the users.
The purpose of Media Viewer is not that much important here in Commons, compared to Wikipedia or similar projects. Commons mainly a back end project; so direct interaction with readers is less, I think. Jee06:46, 8 July 2014 (UTC)[reply]
Am I missing something? Why does there have to be a default behavior? Why can't it just ask you the first time "Would you like to try the new Media Viewer?" With possible answers being "Yes" "No" "No, and don't ask me again." Also, am I the only person having trouble keeping the Media Viewer turned off?50.59.88.4617:05, 1 August 2014 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
equals "File page", & so I click on the image to try and get there, but apparently the whole image is a dead zone, so I instead have to search for a relatively small button that is colored a slightly lighter shade of gray then the jumpy panel that says "More details about this file". Not "File page". Because whoever designed the thing thinks that we all know that 
![[1]](https://www.mediawiki.org/wiki/Lightbox_demo#mediaviewer/File:How_to_Make_Wikipedia_Better_-_Wikimania_2013_-_42.jpg){kind=link}
