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?

Flag of Japan

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 1px solid #ddd border around the image itself. {{Nihiltres|talk|edits}} 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)

Flag of Japan

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) • 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#Synthesis and en:Fractal#In creative works); 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 bug 68468 as an enhancement request to support captions on images with the border style. Steven Walling (WMF) • 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. {{Nihiltres|talk|edits}} 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)

typoscript of Max Weber's Rechtssoziologie with changes in the margins and on notes

A photo with overexposed sky

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. -- [[User:Edokter]] {{talk}} 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] (d: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)

How common is use of imagemaps in page content? Why are they used? Steven Walling (WMF) • talk 21:27, 26 July 2014 (UTC)

here is a category of them from de:wp w:de:Kategorie:Vorlage:Verweissensitive Grafik. its often used for maps. --Wetterwolke (talk) 22:38, 26 July 2014 (UTC)

At enwiki, there seems to be ~1000 raw imagemaps (eg. en:Pluto#Classification or en:List of tallest buildings in Jersey City), plus a bunch of (~450?) templates in en:Category:Wikipedia image maps (eg. en:Sirloin steak or en:Phylum) (I'm not sure how to accurately count/guess their usage scope? Some are unused, some are used on a few pages.).

(Tangentially, I wonder if anyone has investigated the various pros/cons of: Imagemap vs c:Help:Gadget-ImageAnnotator vs the custom templates such as en:Template:Chloroplast DNA? I don't know enough about any of them, myself. They're all intriguing/overwhelming, though!)

HTH. Quiddity (WMF) (talk) 23:56, 26 July 2014 (UTC)

I'm wondering that you want to change a very central feature and don't have any idea what serious consequences this change has. How can WMF employ such incompetent people?--Sinuhe20 (talk) 07:06, 27 July 2014 (UTC)

Why would it be relevant, how often a feature is used? It's a valid feature and has a purpose. We use imagemaps in (schematic) maps, in charts and even a few times in photographs. We also use them on functional pages for icons that can be clicked. Imagemaps are a reality and you have to deal with them.

Now I really wonder who designed that update and how much he or she thought about the status quo. Did you really believe that the current layout was designed as it is because we all lover cluttered layouts? That we added the little symbol because readers are too stupid to click on the image, when they want to know more about it? Didn't anyone assume first and foremost, that every feature has a function and if one wants to update the layout you first have to understand what the current layout does and why? --H-stt (talk) 07:37, 28 July 2014 (UTC)

The prevalence is relevant because something that is used a million times needs an automated fix, and something that is used a dozen times can have a manual fix.

Steven, image maps are used so that you can click on part of an image and get taken to a relevant article/linked page.

Nick, en:Pluto#Classification may be a good model for addressing this. Not only does the caption provide links to the template (where a /doc page could provide all the attribution one might want), but the image itself is accessible by clicking on the black background of the image (in between the trans-Neptune objects). This contrasts with the less well-implemented image map about British beef, which not only has no direct access to the template or the image, but which also has two links reversed (topside and silverside). WhatamIdoing (talk) 16:55, 28 July 2014 (UTC)

Very simple solution

.thumbimage {
    border: 1px solid #ddd;
}

This will have the same effect as specifying border. The color is light enough to be virtually undetectable with the majority of images, while solving the main complaint when used with bright images and images with white or blending backgrounds.

I know this goes against "kill-all-borders-with-extreme-prejudice" philosophy, but it is clear that that philosophy simply does not work. The above solution does, while maintaining the clean look the design team is persueing. -- [[User:Edokter]] {{talk}} 11:16, 29 July 2014 (UTC)

I endorse this. It's not aesthetically perfect, but it's good enough to be rolled out widely without concern. Elsewhere it's been suggested that there could be added a "bordered-thumb" image display setting or some similar solution for the "edge cases" that are truly in need of borders. I think that we could add to the above the reverse of that suggestion: add a "borderless-thumb" setting. That has the advantage that the extra work of changing extant images would not only be optional, but would constitute enhancements from a new feature, rather than corrections to fix a new problem. {{Nihiltres|talk|edits}} 14:33, 5 August 2014 (UTC)

That would make image syntax too convulted. I prefer we maintain backward compatibility. -- [[User:Edokter]] {{talk}} 22:05, 5 August 2014 (UTC)

I was speaking in general terms. We could call it "diagram" mode and style it like "thumb" on old-style skins; there aren't necessarily backwards compatibility problems. The key point I was making was about the approach: one creating a problem but allowing a manual fix, and the other not creating a problem (using compromise) and allowing manual enhancement to avoid the worst of that compromise. {{Nihiltres|talk|edits}} 16:10, 6 August 2014 (UTC)