Talk:Thumbnail style update

Love it
* Love* how MediaViewer allows me to see the actual difference between screenshots on this page. Love it. --Elitre (WMF) (talk) 09:35, 23 July 2014 (UTC)
 * is this a kind of paid editing to support the media viewer? Where can you see the difference between one picture?--Hubertl (talk) 16:37, 23 July 2014 (UTC)
 * I believe she is referring to the slideshow-functionality. I know she uses a small notepad computer, and might not use browser-tabs, hence it might not be as easy to jump back-and-forth between images (as for someone with browser tabs and mousewheel). (Also, it helps that I captured all the screenshots at the same screensize and placement, meaning things generally line up, so the small changes are easier to see). HTH. Quiddity (WMF) (talk) 18:27, 23 July 2014 (UTC)

Nice feature. I hope that the next step will be to align the files in a column outside the text. Pyb (talk) 10:42, 26 July 2014 (UTC)

white space?
Did anyone consider this effect?



Please go back to the drawing board and come again, once you understood layout. --H-stt (talk) 14:57, 23 July 2014 (UTC)


 * I'm concerned about this as well. While I have a certain affection for the "box" that surrounds thumbnails (the off-white box feels like it helps), the simplest solution might simply be to leave present the extant  border around the image itself. {&#123; Nihiltres &#124;talk&#124;edits}&#125; 16:11, 23 July 2014 (UTC)
 * But the idea of the update is to get rid of all the borders and frames, in order to get a neat clean image. Great for photos with sharp edges. Useless for diagrams or any other graphics that rely on white space. This "update" was designed by someone who has not the slightest idea about real life design. --H-stt (talk) 16:20, 23 July 2014 (UTC)
 * Not having a clue seems to be the standard mode at WMF. --Voyager (talk) 16:47, 23 July 2014 (UTC)


 * You can always add a border parameter to images, like the example on the right. The downside here is that it appears you can't have a caption as well? We could change this, of course. Steven Walling (WMF) &bull; talk   16:54, 23 July 2014 (UTC)
 * If necessary, you could draw a box by placing the image inside a table.
 * User:H-stt, I think that the lack of a border would be an advantage for diagrams. The difficulty is when the white edge is actually part of the image.  WhatamIdoing (talk) 17:12, 23 July 2014 (UTC)
 * Indeed. And I did raise the issue of diagrams, in comments at the earlier gerrit patch (pointing specifically to en:Insulin and en:Fractal); Jared replied "After looking at the example pages in mobile (with borders+boxes) and and mobile beta borderless+boxless I cannot find an instance where the boxes add to the appearance of the articles rather than detract." So, I believe it is just these edge-cases such as flags, that we need a solution for. (Using tables would not be an acceptable solution, for en:Semantic HTML reasons). Quiddity (WMF) (talk) 17:36, 23 July 2014 (UTC)
 * +1 for not using a table for this. Helder.wiki 17:48, 23 July 2014 (UTC)
 * I've filed as an enhancement request to support captions on images with the border style. Steven Walling (WMF) &bull;  talk   20:14, 23 July 2014 (UTC)
 * I'm ambivalent about that workaround. While it avoids compromise on the part of the original design, it both a) makes a significant change to one of the other image behaviours, which might have unforeseen consequences and b) requires users to actively correct the (introduced) problem. Are there problems with removing the borders but retaining the "box"? If not, that might be an interesting alternative. {&#123; Nihiltres &#124;talk&#124;edits}&#125; 15:15, 24 July 2014 (UTC)
 * I've suggested that at the bug. Other options/ideas, welcome. Quiddity (WMF) (talk) 17:47, 24 July 2014 (UTC)


 * How about the next examples? --H-stt (talk) 15:10, 24 July 2014 (UTC)
 * The example on Max Weber looks reasonable (to me at least). Some might say "better".
 * The example on München looks awkward. It would need one of the suggested solutions.
 * I've also taken screenshots of Fractal, which I think looks reasonable. Some might say "better".


 * So, I think it comes down to:
 * A) Technical angle: The unanswered question (at the bug) of what our options are technically, for dealing with edge cases. So far, the options are: (1) adding a new parameter to the "|thumb" code, that makes a border an optional addition. (That would keep the clean/unboxed look for most images, but enable an override where needed). (2) replacing a border, but just around the image itself, as mentioned above by Nihiltres. (That would eliminate the clean/unboxed look completely, but simplify it from the current double-boxed look.)
 * B) Aesthetic angle: How beneficial the clean/unboxed look is, in comparison to the (relatively small) amount of work that we'd need to do to fix these edge cases, if we used a technical solution that could be applied selectively. This is a subjective question, that we'll each have opinions on.
 * I think the (unknown to me) relative-complexity of (A1) will be pivotal for how we decide (ie. can it be coded within the next week or two). I'll continue to ask the devs to give us feedback on this, as soon as possible.
 * Does that accurately summarize the situation? (and much thanks for giving precise examples. Examples always help!) Quiddity (WMF) (talk) 17:47, 24 July 2014 (UTC)
 * The core issue is aesthetic. And I don't think we are dealing with 'edge cases' (in the sense that they are rare); any image that has a bright (white or close to white) areas near it's edges is in danger of blending into the background, and that is not a good idea. Frankly, I think this update hasn't been thought through enough. I can understand the "remove-all-borders" philosophy, but this is one case where this is counterproductive. Instead of a double-border, a single-border (retain .thumbinner) would have been a better choice.  19:33, 24 July 2014 (UTC)
 * ...small amount of work... is this a bad joke? You cannot change a default layout, that was used for more than 10 years and every editor had to trust in. If an editor don't want to have frames, he would have used the option frameless. Now millions of articles don't have the option framed, because the editors didn't have expected that somebody would ever think of changing this basic layout. What is your next magnificent idea? Putting all images to the left side? There are only a few images using the right parameter, because they are still on the right side. Maybe it should be better for an editor setting all default parameters, because he cannot be sure that someone will ever change them!--Sinuhe20 (talk) 12:35, 25 July 2014 (UTC)

25 July update
The rollout of the Thumbnail style update has been postponed whilst the engineers look at how best to enable an optional border, for the few instances that really need it. Once that has been decided and written/tested/deployed, I'll send an update to these threads, and post wider announcements at the global equivalents of [Help talk:Image markup] (Q4618557). Much thanks to everyone that gave useful feedback, here and on the other talkpages, and email threads. Have a good weekend. Quiddity (WMF) (talk) 02:48, 26 July 2014 (UTC)

Symbol as link to the file in imagemaps
The smalish symbol "enlarge" under each image in the current layout is the only way to reach the file including the license information(!) if the image uses an imagemap, with positions in the image linking to different targets. In imagemaps all links within the image link somewhere else than to the file, so the symbol in the "thumb frame" is necessary to reach to license information.

Removing this symbol (and its function) means that every single image with an imagemap becomes a copy vio, because the license information is hidden. Please be aware of this function and keep a method to reach the license information under the new layout. TIA --H-stt (talk) 14:55, 26 July 2014 (UTC)