Wikipedia talk:Image use policy

Archives
August 2002 – March 2003 April 2003 – April 2003 (1) April 2003 – April 2003 (2) April 2003 – April 2003 (3) May 2003 – December 2003 January 2004 – July 2004 July 2004 – August 2006 September 2006 – December 2006 January 2007 – September 2007 October 2007 – December 2007 January 2008 – January 2009 February 2009 –
Noncommercial-use Discussion of image sizes Specific image-related copyright issues
Sound help Image markup

Proposal to increase the default thumbnail dimensions

current suggested lead/infobox size, per MOS: 300px

current default thumbnail size (180px)

proposed default thumbnail image @ 220px

proposed default thumbnail image @ 250px

A perennial proposal, this, one that nonetheless gets more pertinent, the higher the "typical" resolution of our computer screens becomes. I'm posting it here as an RfC because it's more than just a style issue, it affects the substance and usability of the entire project. In brief, it's pretty clear from recent discussions that image display sizes are becoming a big issue, as the number of people using >1250px monitors increases; on the other hand, there may be a substantial, non-vocal majority still using 1024px or less*, who may prefer the status quo. This is the time to speak up, if so.

While there may be a growing consensus for increasing the default thumb size, there's no clear indication as to what, exactly, that size should be. To the right are some reference thumbs, "forced" to their respective sizes. The 300px size at the top is the current guideline default for infoboxes and lead images, included here to put the thumb sizes in perspective. It may be, if we decide that (say) 250px thumbs are the way to go, that this guideline may need to be revised, if only to keep an article's main image suitably prominent on the page. The main contenders, as I see it, are 220px and 250px, examples of which appear here, below the current default of 180px.

I'm sure I'll chip in my 2¢ at some point; for now, it's going to be very useful if people at least skim a couple of archived discussions here and here, to get up to speed with the historical objections and save some time. The recent one over at MOS, and the one immediately above here, are the ones which have resurrected the question of default thumb sizes and consequently this proposal.

A common, unanswered, question in these debates is the viability of implementing any change at all. This has been put to Tim Starling who will hopefully be able to clarify in due course.

mikaul^talk 07:23, 30 September 2009 (UTC)

• *In the course of answering a point in the discussion below I've located a table of current estimated viewer resolution sizes. It broadly supports the assumption that sVGA (800x600) – the "lowest common denominator" on which our 180px thumbnail default is based – is no longer used by a significant number of visitors. While a majority are reported to be using sometihng "higher than 1024×768" and it shouldn't be assumed that this means everyone is upgrading to hi-def 1080p stuff, it's likely that the proliferation of the 720p format is behind the shift. This might be just another assumption, but it's a better benchmark to work to, I think. --mikaul^talk 21:19, 2 October 2009 (UTC)

• "The 300px size at the top is the current guideline default for infoboxes and lead images" - no it isn't - where does it say that in the guideline? Very few infobox images are that large, though many lead images are. It is also of course the largest default size that can be set in user preferences. Johnbod (talk) 16:14, 30 September 2009 (UTC)
  • About halfway down the list of Examples where adjusting the size may be appropriate it says:

    Lead images, which should usually be no wider than "upright=1.7" ("300px")

    I think most infoboxes default at 250; some (like wine ones) default at 300. As you say, 300 is currently the default maximum in a lot of places. My point was related to the proposal to increase thumb defaults to 250, which could leave many infoboxes (especially those defaulting at 250) looking relatively undersized. --mikaul^talk 22:19, 30 September 2009 (UTC)

Discussion

South Ossetia map is a bad example

180px. Yamato-Asakura Station

200px. Yamato-Asakura Station

220px. Yamato-Asakura Station

250px. Yamato-Asakura Station

While I favor increasing the default size, the example image used above (File:2008 South Ossetia war en.svg) is a bad example to base this discussion on, as it's unreadable at all the sizes shown. It's an unrealistic example as well, as its only use in English Wikipedia specifies a fixed pixel width and thus the image would be unaffected by this proposal. Discussion should be based on a realistic example that would be affected by the proposal.

I pressed Special:Random several times, until I found an article (Yamato-Asakura Station) that contained a thumb image that did not specify a size, and include this somewhat-randomly-chosen image at right, to serve as a better example. Eubulides (talk) 08:06, 30 September 2009 (UTC)

Ok, whatever rings your bell, although I don't see how actual current use of specific images has any bearing on things. Having spent a frustrating hour or more trawling our featured content for the perfect example, it occurred to me that (a) there's no such thing as a perfect example, nor a realistic one for that matter, as the increase potentially affects every image we use, and (b) a good example might be one which demonstrated that while a modest increase in thumb size has a dramatic aesthetic effect, it has a marginal effect on legibility. Circumstances will be as varied as the content we display, so the best we can hope for is as big a default as possible without inconveniencing users or offending the eye, for want of a better expression. So yeah, random is good. Hopefully without too many examples we will demonstrate that 180px is just too small and anything bigger would be an improvement. mikaul^talk 11:54, 30 September 2009 (UTC)

I'd be choosing 250px for the railway station. But 220px has a better chance of succeeding in an RfC. No response yet from Tim Starling. Perhaps John Vandenberg might be the next port of call? Tony (talk) 15:27, 30 September 2009 (UTC)

User_talk:Jarry1250#Increasing_the_default_thumbnail_size. Tony (talk) 15:34, 30 September 2009 (UTC)

I'll get round to deciding my own views later, but for the moment I can comment on the technical feasibility regarding such a change. $wgDefaultUserOptions makes it easy (as far as I can tell) to change the truly default size, and this is what anonymous users and accounts created after the change will see. (Actually, I should interject here that 220px might prove very slighty more difficult than 250px, because 250px is already on the list. But it should be as easy as changing $wgThumbLimits i.e. no bother at all. [Edit: Actually, maybe some bother if the value is stored as a ref number e.g. 3. Then if you hanged the values it would go out of sync, but this could be fixed.]) Then you're left with existing users at 180px (who could just change it themselves if they wanted to), but you are, of course, welcome to remind them that that option exists. It has also just occurred to me that it might not be too hard to force-convert everyone from 180 to the new size, but this may well evoke bad feeling from those who quite like it at 180. - Jarry1250 ^{[ In the UK? Sign the petition! ]} 16:45, 30 September 2009 (UTC)

Interesting. Are you saying a change in $wgDefaultUserOptions would not affect currently-registered users who hadn't set a thumb size preference other than 180px? From what I can gather based on earlier discussions, the only disgruntled unregistered users might be those who, for reasons of impaired vision, prefer text to be displayed at a relatively large size, making the images look very large. It's this sort of issue that has me tending to prefer a smaller increase to 220px. Having said that, these same hypothetical users viewing our pages on a 720p (HD) monitor have so much screen real estate as to make this irrelevant; they'd barely notice the difference. --mikaul^talk 22:46, 30 September 2009 (UTC)

Indeed, the system has no way of distinguishing between "180px (didn't know I could change it)" and "180px (I extensively test the other sizes and, on balance, much prefered this setting)". So all existing user's preferences would probably remain static throughout. - Jarry1250 ^{[ In the UK? Sign the petition! ]} 20:36, 1 October 2009 (UTC)

300px A typical Jan Steen picture (c. 1663); while the housewife sleeps, the household play.

• The railway station photo, essentially of a wire fence, is surely a pretty terrible shot at any size! Here is a complicated painting (from Dutch Golden Age painting) in rather dark colours & a rather typically low quality source which I think is pretty unreadable at 180, & much better at 220/250, though much better at 300 of course. Also note the effect on the caption. Johnbod (talk) 16:26, 30 September 2009 (UTC)

180px. A typical Jan Steen picture (c. 1663); while the housewife sleeps, the household play.

200px. A typical Jan Steen picture (c. 1663); while the housewife sleeps, the household play.

220px. A typical Jan Steen picture (c. 1663); while the housewife sleeps, the household play.

250px. A typical Jan Steen picture (c. 1663); while the housewife sleeps, the household play.

Percentage scaling

(Proposal for dynamic image sizing moved to Wikipedia:Village pump (technical)/Archive 65#Percentage scaling. Cacycle (talk) 02:33, 2 October 2009 (UTC))

Supports and opposes

Since the aim of the RfC is to gauge support or otherwise for the proposal to increase the default thumbnail size upward from 180px (probably to 220px, but MIckStephenson, please correct me if I'm wrong), it would be helpful if people put their cards on the table in an orderly fashion below. Please consider giving a range of the pixel widths that would be acceptable to you, if not a single favoured width.

• Support. 220–250px (clarifying what I meant by "220px+). The 180px size was probably established in dial-up days. We need to move on. WP is regarded as being weak on images (mostly because of our copyright rules), so let's not make people squint when we actually have the right to use an image. Probably 220px+, although some images still need to be manually adjusted to a larger size, depending on detail, importance, quality, and visual context on the page. Tony (talk) 07:35, 1 October 2009 (UTC)
• Support 180px is damn near unreadable and I end up specifying a higher size (I guess contra the MOS, gasp!) when I want the reader to understand an image without clicking on it (which not everyone knows you can do). Protonk (talk) 07:46, 1 October 2009 (UTC)
• Support. 180px is ridiculously small on modern displays, and I usually find myself specifying 250px these days. 220px would be a reasonable new default. --Malleus Fatuorum 07:52, 1 October 2009 (UTC)
• Support up to about 220 My primary concern is mobile browsers. The default size should look right on a 320*240 screen without client side resizing. I am aware that Wikipedia sends a different layout to mobile browsers that it can identify, if that is differentiated with image thumbnails (a technical detail I do not know) then higher than 220px might also be a good idea. Miami33139 (talk) 08:08, 1 October 2009 (UTC)

• As a technical note, mobile browsers (such as Blackberries) typically ignore image sizes, because specified sizes are so often wrong for mobiles. Mobiles are therefore unaffected by the proposed change. Eubulides (talk) 16:24, 1 October 2009 (UTC)

• Support 250px, or 220px at a minimum. The vast majority of displays are capable of 1024x768 resolution, and most can also do 1280x1024. Either of these resolutions can handle 250px thumbnails. I wouldn't want to remove the option to use smaller thumbnails, but it makes it hard to design a layout when the default thumbnailis so small, but you know that many people have (or would if they knew how) set 250px as their default size. In other words, you have to consider two very different sizes. If the default was also the same size as was appropriate for the majority of displays, it would make page layout much easier for editors, and it wouldn't adversely impact users who chose to use smaller thumbnails as they would simply take up less space proportional to text. Diliff | (Talk) (Contribs) 09:09, 1 October 2009 (UTC)

• Support 220px+ Personally I use 300px as my default. I'd really like the MOS to specify a uniform image size for infoboxes etc too. Noodle snacks (talk) 09:20, 1 October 2009 (UTC)
• Support 250px or at least 220+. I also have a 300 default set, and am more often aware of pics forced too small than being too large. Apparently the mobiles do things differently, so that should not be an issue. Those with vision issues, or very small screens, should still be able to set defaults down to 120px as at present. Johnbod (talk) 11:51, 1 October 2009 (UTC)
• Support 220px, and although I wouldn't oppose 250, I'm not sure we're fully appreciating the impact this might have on the relative size of current infobox image defaults and forced-size lead images. If the consensus was for 250, I'd be looking to not only increase the lead image maximum guideline, but attempt a bot-driven upsizing of existing lead and infobox images. At very least a review of those settings would be required as a separate proposal. --mikaul^talk 12:26, 1 October 2009 (UTC)

• Support 220px+ I haven't set my preferences because I like to see what the majority of our readers see, but I agree that 180 is inadequate in many cases. Dabomb87 (talk) 12:40, 1 October 2009 (UTC)
• Support 300px as lead and 250px as default. I like the idea of being able to see images...Modernist (talk) 13:03, 1 October 2009 (UTC)
• Support 200px only In many occasions, I've seen this specific forced size set up for images on articles, so I'm choosing the practically used size. 220px is okay. However, 250px is overwhelmingly too big for editors using smaller screens and resolutions.Caspian blue--13:08, 1 October 2009 (UTC)

  After testing the listed image sizes with my sandbox that had a duplicate content of Dutch Golden Age painting, I have to oppose any size greater than 200px. The changed layouts do not look good to me. We should not draw the conclusion with just "one single example per one size at glance.--Caspian blue 17:46, 4 October 2009 (UTC)

• Oppose 220px I think that 180px is fine, but I would also be okay with 200px. The user can click if they want a larger size, or we can make the size of an individual image larger in an article if it needs to be. But, for most situations, anything over 200px is overkill, and takes over the page. hmwith☮ 15:10, 1 October 2009 (UTC)
• Support 220px, probably not 250 though. 180 is just too damn small. I'm surprised it's been kept at that size for so long. Kaldari (talk) 15:14, 1 October 2009 (UTC)
• Oppose until further study is done. I previously voted "Support 220px but no larger." but (as described below) trying a 250px default hurt the appearance of some high-quality articles, so I would favor making it easy for people to set a 220px default for a while, to see how well it works in practice, before changing the default for everybody. Increasing it to 250px would be too drastic a change, and would affect too many existing layouts adversely. Eubulides (talk) 16:24, 1 October 2009 (UTC) updated 19:34, 1 October 2009 (UTC)
• Support up to 250px. 180px is too small almost all of the time. -Atmoz (talk) 18:48, 1 October 2009 (UTC)
• Support 220px took me forever to figure out how to make it lkarger in my preferences anyhow. Martin Raybourne (talk) 18:50, 1 October 2009 (UTC)
• Support 250px+ IMO, even 220px is sometimes too small especially when scale bars are involved. --Muhammad(talk) 19:03, 1 October 2009 (UTC)
• Complete and total support, per nom. --King Öomie 21:05, 1 October 2009 (UTC)
• Support I am really glad this has been proposed with larger screen resolutions this has always seemed to small... RP459 (talk) 23:03, 1 October 2009 (UTC)
• Support - A month or two ago, I read that I could set the size in my preferences. I set mine to 300, and I've loved it ever since. I use a notebook with a semi hi resolution, so 220 or 250 is probably good for the default. - Peregrine Fisher (talk) (contribs) 23:59, 1 October 2009 (UTC)
• Support 220 through 250 Full disclosure, I have a 1920x1080 monitor. Chillum 01:44, 2 October 2009 (UTC)
• Support at least 220px - 180px is useless most of the time. –Juliancolton | ^Talk 02:44, 2 October 2009 (UTC)
• Indifferent oppose I use 150px on screens with 1280 and 1600 px horizontal res and it's just fine (except for pics with very lengthy captions that shouldn't so long anyway). 250px may be convenient on small screens but on higher resolutions bunching of images and edit buttons will be almost unavoidable. For a test, choose a random dozen of FAs. NVO (talk) 08:32, 2 October 2009 (UTC)
• Oppose anything bigger than 220, no opinion on 200-220 on my 1280x1024 monitor. Thumbs wider than infoboxen (which tend to be in the 220-250 range) make for strange-looking pages. Nifboy (talk) 08:37, 2 October 2009 (UTC)
• Support about 220 Prefer 220, as that is larger, but unlikely to cause trouble on present layouts. Would also be ok with 200 or 250. LK (talk) 10:22, 2 October 2009 (UTC)
• Oppose I don't see any mention of netbooks above and so the screen-size trend is not proven. Also, thumbnails are supposed to be small - hence the name - and the reader has the option to click on them to see the full size image. Colonel Warden (talk) 10:48, 2 October 2009 (UTC)

• If I'm in the middle of reading an article, it would seem a bit of an inconvenience to have to click on every illustration to see what it says. –Juliancolton | ^Talk 13:49, 2 October 2009 (UTC)

• Very weak oppose. Changing the default has site-wide impact, and where images actually should be bigger, we can and should specify pixel sizes case-by-case as appropriate. (If MoS still suggests that's bad, that should be addressed.) That said 180->220 is probably OK. Rd232 ^talk 14:14, 2 October 2009 (UTC)
• Oppose 220+ The Swedish wiki uses 250 and it's too big, I think 220 should be an upper limit. The images shouldn't be wider than infobox pictures. Hekerui (talk) 16:18, 2 October 2009 (UTC)
• Oppose anything larger than 220px - While I recognise that 180px is probably on the small side, anything larger than 220px (absent special circumstances justfifying forced sizing) is just excessive. --Skeezix1000 (talk) 16:22, 2 October 2009 (UTC)
• Support 220 Looks great on both my machines (23" and 13") and will make the images far more readable and generally appealing to look at. There's very little more annoying than reading a dense article with small images that fail to break it up, and 180 is small. I have no problem with 250 either, but that's because I tend to use the large-screened monitor - 220 is a good starting point. ~ Amory (user • talk • contribs) 16:57, 2 October 2009 (UTC)
• Oppose anything greater than 200px. I'm not sure I agree with the underlying premise. Devices with small screens (netbooks and smartphones) are becoming increasing popular and people are generally shifting from desktops to notebooks, which typically have lower resolutions than the former. What is the factual basis for claiming our readership is using higher resolutions? There may also be a systematic bias in that regular editors (i.e. those participating here) generally tend to be more interested in technology than the population taken as a whole and, therefore, more likely to have higher end equipment. This is a solution looking for a problem; if a detail in a given image is difficult to discern at the default size, force the size. Эlcobbola _talk 17:17, 2 October 2009 (UTC)
  • In previous discussions over the last 4 years or so, the "typical user" debate has been very prominent and, it has to be said, still more uninformed. We still don't really know what the lowest common denominator really is, but I think now, with display technology shifts of the last 3 years or so, it's fair to say that (almost) no-one is viewing wikipedia with an sVGA (800x600) display, the assumption upon which the original 180px thumb was based. We have nothing scientific to support this, but current estimates can be found in this article. I'm also fairly confident in saying the new generation of netbooks and notebooks, despite having a smaller screen, have a greater horizontal resolution than my 2005 Apple Powerbook, on which I view WP with 250px thumb prefs. Using my larger 1080p monitor with 250 set is wonderful but I'm prepared to accept this as "higher end"; the majority are probably using something nearer 720p, and that this makes 220px more viable and eminently viewable. It also makes 180 (or 200) tiny and obsolete. There's a discussion on forced sizes further down the page. --mikaul^talk 20:45, 2 October 2009 (UTC)
• Oppose anything greater than 220px, and weakly oppose anything above 200px, principally agreeing with the reasons mentioned by elcobbola, above. I'd understand a push to go a bit higher than the present default, but think that any more would be in breach of our accessibility aims, and this compromise should be the limit for a good while to come. We'll obviously revisit this every time portable device screen technology takes a leap. But at the end of the day, how hard is it to click on an image and see a much bigger, much better version? Not very. – Kieran T ^(talk) 18:08, 2 October 2009 (UTC)
• Support up to 220px.—NMajdan•talk 20:54, 2 October 2009 (UTC)
• Support up to and including 250px. That's definitely the limit with current technology prevalence, but the days of needing such tiny images are long gone. We have some truly awesome images in our collection; it's almost criminal not to show them off to a better degree. Happy‑melon 21:40, 2 October 2009 (UTC)
• Support 220px — neuro 22:42, 2 October 2009 (UTC)
• Support 200px, neutral on 220px, oppose 250px. 180 pixels may be too small, but that's not a good reason to over-react. By their own name, thumbnails are supposed to be small; and this is only about the default; pictures containing text etc. which cannot be easily read at 200px can be shown at a larger size (or tweaked to have a larger font for the text). Another reason to avoid very large thumbnails is that the size of an image, and hence the time to download it, is roughly proportional to the area and hence scales quadratically with the length; if they are enlarged from 180px to 250px, that'd translate to a 93% increase in their download time, and Wikipedia articles already take excruciatingly long to load on 56 kbps connections, which are far from being extinct (for example, more than 30% of Italians don't have access to any faster connection, including me as recently as three months ago.) --___A. di M. 15:57, 3 October 2009 (UTC)
• Support 250px, because even phones have higher resolutions these days, and internet connection is good. My only concern is if the Wikipedia foundation can afford the increase in traffic. --HappyInGeneral (talk) 17:08, 3 October 2009 (UTC)
• Support 250px The en.-version of Wikipedia needs to begin better supporting modern hardware platforms. The standard window width that webmasters design for is 1024 pixels across before a scroll bar appears at the bottom of the window. Along with these new standard practices comes pictures that are bigger than a default 180 pixels for our regular I.P. viewers. CNN’s main page has main picture measuring 265 pixels wide. It’s long been time for an upward tweak to catch up with the rest of the world. Greg L (talk) 18:37, 3 October 2009 (UTC)
• Support 200px, weak support 220px – With my widescreen monitor and network connection, I love the look of the larger photos, especially where 180px cuts a lot of detail out. However, we musn't forget our readers who own less powerful equipment. I just read in Consumer Reports that the rate of broadband use in the U.S. in 2008 was 55 percent; that leaves a large percentage of people who still only have dial-up connections. When I was on dial-up, I remember articles with numerous images having long load times, and that would be exacerbated with a large increase. Add in the increasing use of mobile Internet devices, and I feel an increase should be measured. Giants2008 (17–14) 19:55, 3 October 2009 (UTC)
• Support 220-250 px. Anything else is too small. --Patar knight - ^chat/_{contributions} 23:58, 3 October 2009 (UTC)
• Support 250px+. Honestly, even mobile devices have 320px displays now. And even on netbooks and laptops, 250px is not particularly big. Thumbnails are unfortunately named, because they're not just a placeholder for someone to recognize and click through, as with other web image galleries; they tend to be the primary (or only!) version of an image many people see. --MCB (talk) 01:50, 4 October 2009 (UTC)
• Support 250px+ The 180px is too small even on my Windoze monitor at work - default-sized images look pathetic on my 23" screen. I always prefer 250px-350px, depending on the article and disposition of text, but would settle for 250px. Ohconfucius (talk) 05:13, 4 October 2009 (UTC)
• Support 250px+ The 180px is pretty ludicrous for any articles discussing art or architecture, where you might actually need to refer to the content of an image whilst reading. --Joopercoopers (talk) 08:22, 4 October 2009 (UTC)
• Oppose 220px+ I would rather an image be slightly too small than too big, because at 220px+ images have a tendancy to affect the text around them and reduce its readability and aesthetic. MasterOfHisOwnDomain (talk) 09:19, 4 October 2009 (UTC)

Does this mean that 180–220px is your range of acceptability? Tony (talk) 05:29, 5 October 2009 (UTC)

• Preference for keeping 180px, though will accept up to 220px. Users can select a personal preference for larger images, so consideration needs to be given on the impact for the unlogged in viewer (which is our main readership). Larger images can distort text and the layout of articles, and there will need to be a period of tidying up articles impacted by an image size change. Also, large images can distract from the text. While some images are vital to an understanding of the topic, most images are aesthetic. I would prefer that we keep our priority on delivering and presenting good readable text content. On those occasions where an image is vital, and it needs to be forced, we accept and allow that, but I don't think we should be generally encouraging pictures to be dominating the content of an encyclopedia. SilkTork *^YES! 17:24, 5 October 2009 (UTC)
• Support up to 250px. -- SWTPC6800 (talk) 01:26, 7 October 2009 (UTC)
• Support 200–220px The current default 180px is barely visible in some cases. However, anything larger than 220px would cause the images to mess up the layout in too many articles. —tktktk 02:06, 7 October 2009 (UTC)
• Support 180220 or percentage scaling system as another viable option.陣内_Jinnai 06:34, 7 October 2009 (UTC)
• Support 250 px, also 220–250px. I made my own test with my 12 inches notebook (never use anything else). Result: Excellent if more portraits would be "upright", I only now understand the sense of upright (with 180px upright is just annoyingly small, even on such a small screen). A default of 200px would change nothing, it's still too small, not worth the trouble. Buchraeumer (talk) 17:54, 7 October 2009 (UTC)
• Support 220-250px. I just went to Dell's site, and their 10 inch Mini they're selling has a resolution of 1024x600. 150 pixels are eaten by the sidebar. The Worst Case is two images on each side... 1024-(250*2+150) = 326 pixels left for text, which isn't so small as to create the weird "tiny canyon of text" effect. 220 would give 386 pixels. So I think this is fine even for netbooks. Also: Strongly agree that the "upright" trend is evil and pixel sizes should be used instead when defaults are overruled. SnowFire (talk) 23:38, 7 October 2009 (UTC)
• Support. My personal preference is 250+, but just about any increase in the default size would be an improvement. It would also be very welcome if people would stop removing intentionally specified widths just because they don't like them. I can't even begin to count the number of times I've had to argue over the fact that 180 makes many maps and graphics illegible, but people fight for the "default" just because they don't want their preferences overridden. Make them larger in the interest of the silent majority of readers. Dragons flight (talk) 21:46, 8 October 2009 (UTC)
• Support 220 And if there are problems, try reducing it to 200. If there are no problems, consider running a more rigorous study on whether 240, 250, 260, or other, would be an appropriate second step. -- Quiddity (talk) 04:47, 9 October 2009 (UTC)
• Support any increase. Even the new netbooks w/ their small screens usually support at least XGA. If we assume that XGA is the lowest common denominator instead of sVGA, we get accordingly that the image sizes should be increased to ~230px from 180px. Rami R 11:01, 9 October 2009 (UTC)
• Oppose. If I want to see the detail of an image, I'll click on it. These images are supposed to be thumbnails: that's what it says on the tin. If it really is essential, on a page I'm editing, to be able to read the details of an image - eg a diagram - to understand the text, then I'll force a minimum size. That includes the Jan Steen pic above, which I wouldn't force an increased size for. But on the other hand we have a fair number of pages with a lot of images on them, designed for 180px. A 50% linear increase in the image size (i.e. an area increase in screen real-estate x 2.25) I see as likely leading to a lot of over-congested pages. Jheald (talk) 17:32, 13 October 2009 (UTC)

The Steen image appears in an article where you read the text to understand the images, not the other way round. Johnbod (talk) 17:35, 13 October 2009 (UTC)

Quite so, and that's probably why I'm happy with it the size it is. The images where I have forced size have most often been in maths articles, where with luck reading the image maybe can help you understand the text. Jheald (talk) 17:44, 13 October 2009 (UTC)

(ec)Not sure I see your logic there, but whatever. There is no need to speculate as to what a change to 200, 250 or 300 is "likely" to 'lead to' - all you have to do is reset your preferences, as many editors above have done. They already see default thumbs at 250 or 300px; some pages are indeed congested but most are fine even at these sizes. Johnbod (talk) 17:46, 13 October 2009 (UTC)

Please also note the overwhelming consensus so far is for 220px, which is considerably less obtrusive a change than the 250px you appear to be basing your assumptions on. --mikaul^talk 19:15, 13 October 2009 (UTC)

• Support increasing to at least 200px and Oppose anything higher then 220px. Clearly 180px is too small and 250px is too large. For me, 200px is a good compromise. Vegaswikian (talk) 20:45, 15 October 2009 (UTC)
• Support - 220px to 300px would be the range I'd like to be able to select from a personal point of view. As we are actually making a decision on the default for those who can't or don't set preferences, I'd have to settle for 220px for the default. --RexxS (talk) 16:15, 31 October 2009 (UTC)

Further discussion

• Comment I'd have more confidence in this if all of the "support" folks had actually tried this for a week. Changing your personal default is trivially easy: Go to Special:Preferences, click "Appearances", find the pop-up labeled "Thumbnail size" (under "Files") and change it to something bigger. Then come back in a week and let us know whether it made any real difference (and also whether you tried it out on the small laptops that a lot of our readers use). One of the questions I have is whether the proposed 18% increase in width will actually make any real difference. WhatamIdoing (talk) 19:10, 1 October 2009 (UTC)

Haven't you read them? Several have mentioned that they have larger sizes (usually 300 in fact) set as preferences. 180 to 220 is a 22.2% increase in width (not 18%), and a 49.3% increase in area, which is a better way to look at it. People will of course still be free to set smaller preferences. Johnbod (talk) 19:24, 1 October 2009 (UTC)

Yes, I saw those notes. However, "three editors" is not the same as "all", and I think that feedback from rather more than a couple of editors, and especially from people that use small screens, would be valuable information. What looks nice on my 1680x1050 Apple cinema display tells me next to nothing about what's functional on a small screen. WhatamIdoing (talk) 03:29, 2 October 2009 (UTC)

You have a cute way with numbers - now 3=a couple; in fact it is now many more. But I certainly agree that anyone who has not tried out different settings should do so, if possible on different screens. And whatever happens we should make the options for settings better publicised. Johnbod (talk) 15:24, 2 October 2009 (UTC)

Most users do not log in, and most who log in don't set preferences, so the issue is relevant. I just now set my preferences to 250px and visited some featured articles, and 250px is definitely too large, as it messes up the relative layout of images whose sizes are set compared to images whose sizes are not set. I would like to try 220px for a while, but obviously cannot. The experience has caused me to revise my opinion (as noted above). Eubulides (talk) 19:34, 1 October 2009 (UTC)

Which is exactly why factor-scaling (e.g., 1.5 times the size of "the default") should be binned, and pixel width used exclusively. Sorry, I have little sympathy for the tampering with the display by WPian editors so they see something different from what our readers see. Tony (talk) 00:40, 6 October 2009 (UTC)

Had you never tried it before? Having had my preferences at 300 for some years, the only real issues I have had on FAs have been the few recently reset using the "scaling" option. Many FAs in the past have had sizes de-forced at FAC because of the widespread interpretation that the MoS required this. I think it is beginning to sink in that that this is not the case, but until recently drive-by de-forcers were extremely common on all articles. The "relative layout of images whose sizes are set compared to images whose sizes are not set" will be "messed up" with any default setting, just in a different way. If you have a large font set, your 250 will I think not equate to the usual one. Johnbod (talk) 21:01, 1 October 2009 (UTC)

All I did was change my Wikipedia settings for default image size to 250px. I continued to use the default browser settings for fonts etc. This is the way most users would see the site, if the image default were changed to 250px. And the change to 250px made the two featured articles that I visited noticeably worse: the default-size images became bigger while the fixed-size images stayed the same size, and the relative balance that the articles had went out of whack. Here are the details:

• Autism with default=250px. The portrait of Kanner in Autism # Classification became way too large. Kanner was the co-discoverer of autism, but he doesn't dominate the field the way that such a large portrait would imply. The diagram in Autism #Causes also became too large: it's just a simple schematic and shouldn't dominate the section. By and large none of the image size increases were improvements, and since the infobox image doesn't change in size it seems to become less important even though it's by far the most important image in the article.
• Daylight saving time with default=250px. This makes the images of the water clock and of Franklin too large in Daylight saving time #Origin. The Franklin image size is particularly objectionable, since it raises the apparent importance of Franklin compared to the (unchanged-size) images of Willett and of Hudson, even though Franklin did not invent daylight saving time and Hudson and (independently) Willett did. The image of the sundial in Daylight saving time #Complexity is way too large at 250px, and likewise for the "You can't stop time" poster in Daylight saving time #Computing. The victory poster in Daylight saving time #Politics was fine at 180px, though I suppose some might prefer 250px. The increase in image widths does help the BRZ-US example in Daylight saving time #How it works but merely wastes space in Daylight saving time #References.

I initially favored increasing the default size, until I actually tried it. Going to 250px is clearly too much, for these two articles, as it makes both articles worse, mostly by conveying a misleading impression to the reader about the relative importance of the illustrated concepts. I think going to 220px will help overall (it will have problems too, but they'll be less of a problem and I hope the advantages of the larger size outweighs disadvantages such as those noted above), but I'd like to try it first before installing this for every Wikipedia user. I don't think that's too much to ask. Eubulides (talk) 01:51, 2 October 2009 (UTC)

I looked at these with my usual 300. Autism, which has hardly any images, looked fine, but one bit of DST could do with some fiddling. If you think a minute, I expect you will see that "way too large" etc are wholly subjective judgements. I expect after a day or two you would get used to the new look. People being too attatched to the image being exactly right next to the related text is one issue. I then reset all the Autism images except the infobox to 220px in this diff before reverting myself. It looks less good than at 300px, but far better than 180, to which I also reset my preferences. That looked terrible to me, as they always do - six four word lines of caption, come on! Do you ever see professionally designed material looking like that? Johnbod (talk) 02:51, 2 October 2009 (UTC)

One point to make is that article image decisions were made with the default image size in mind. It is one thing to say that a change in the default image size will impact articles negatively, it is another to expect that they would do so, even if the images were rearranged. I don't expect our image layouts to be scale invariant. I will, however, agree w/ the general comment that 250 is too big as a default size. Protonk (talk) 01:59, 2 October 2009 (UTC)

I agree with the previous comment. If the default were changed to 220px (thanks for doing that test, Johnbod) I'd edit Autism to downsize the Kanner image and the chromosome diagram. Also, File:Powell2004Fig1A.jpeg has no business being 220px (even 180px is arguably too much for what is in reality an image with about 100px resolution). Once I did that, 220px would be fine for Autism; but of course now we're talking about doing quite a bit of hand-work after changing the default size, which is a negative. The sizing issue has nothing to do with the images being "exactly right next" to text; it has to do with image sizes conveying inaccurate information to the casual reader about the relative importance of the illustrated topics. I'm not sure what caption size has to do with this, but I have seen professionally designed material with captions much larger than what's in Autism; for example, Figure 1 of Geschwind 2009 (PMID 19630577) has a tall thin caption containing 36 lines. Eubulides (talk) 07:36, 2 October 2009 (UTC)

I can't access that but it sounds wierd. I think you will agree that is not something you'd see in a general interest publication. Do they in fact credit a designer for the journal? Being "exactly right next" to the relevant text is indeed an issue - the EDS article is an excellent example, where about half the pictures in the article are crammed into one small stretch, because that is where the most relevant text is. If you had more experience viewing at higher settings you'd know how common this is. To Protonk: I have always (perhaps foolishly) always designed my articles to look right at my pref of 300; I'm always horrified when I forget to log on & see them at default. I used to think that most registered users had set the prefs that suited their screen, which clearly is not the case. I don't like forcing images, a) because someone will only come along & unforce them, & b) for the sake of people with really small (or wide) screens. Johnbod (talk) 14:02, 2 October 2009 (UTC)

My preferences are set to 300px and I wish a larger option were available. I've never had a problem with layout issues. But if there are layout issues, there is still the option to resize the images smaller. My display is 1280x800. -Atmoz (talk) 20:48, 1 October 2009 (UTC)

• Eubulides, I think it will end up being 220px, not 250px. Tony (talk) 02:24, 2 October 2009 (UTC)

Try 250px for awhile - it does take getting used to. Clearly for those articles and imagery that call for tighter smaller fit - then use |upright or simply use 180px or less whichever works better, my take is that once editors get used to a 250px default and it sets in, it will maintain its appeal...Modernist (talk) 02:53, 2 October 2009 (UTC)

• I've been using 300px for several days, and I'm quite pleased with it. I wouldn't object to a default above 250px, actually. –Juliancolton | ^Talk 03:56, 2 October 2009 (UTC)
• I have a good connection and a large monitor: I would be very happy with 250px. However, it would require a lot more image auditing, since editors have sometimes ignored the MoS rule against the sandwiching of text between left- and right-side images. sandwiching probably need to be fixed anyway, even at the current squint-sized 180px, but 250px would bring it all to a head more rapidly. (Maybe that's a good thing?) Tony (talk) 04:03, 2 October 2009 (UTC)

• I think so, like everything adjustments to imagery in articles will need to be made, however it is as Julian and others say - a step up from postage stamp size defaults, 300px is tempting...Modernist (talk) 04:10, 2 October 2009 (UTC)

• Let's look at the practicalities: at the moment, many articles need most of their images upsized; going to 250px appears to me to provide a better default solution than 220px, and may require a few images to be downsized, like the Autism pic Eubulides found (see his entry above). That's fine—fact is, we need to audit a lot of our articles for image placement, text sandwiching, image sizing anyway, whatever the default. Tony (talk) 04:23, 2 October 2009 (UTC)

• I've had my prefs set to 250 for about a month and it's only really been a glaring problem when editors have used factor scaling, which can generate massive, format-wrecking images not far short of image preview size, never mind thumbs. This page was referenced in a previous discussion as means of making a map more prominent by using upright=2.0 markup; however for me, on my old 1024x768 powerbook, it looks absurdly large. Forced sizing is similarly unattractive, even 220px stuff looks diminutive, as if illustrating a point of lesser importance. It's also very obvious when editors have omitted to use the upright markup, making portrait-oriented images appear rather too large. Overall it seems clear from this experience (and further to the excellent points raised here) that image markup is, generally speaking, a complete mess on this wiki – and I include many FAs in that criticism – almost always for want of a bigger default thumb size. We do need to work on delivering a lot more diligence in image auditing, as well as more thoughtful, ad hoc markup for emphasis and legibility when writing and editing, rather than deal constantly with the shortcomings of an inadequate default situation, and this shakeup is possibly the best way to kickstart precisely such a drive. --mikaul^talk 09:57, 2 October 2009 (UTC)

• One thing that came to mind here, while I support the effort and agree that there will need to be tweaks on existing articles, is the effect on the printed article, presumably considering printing to standard letter-size, portrait layout. I cannot recall if the print layout obeys the user pref that is printing it, whether it defaults to specific sizes, or not, but we should make sure that with default thumbs at 220 or 250 (the two most likely options proposed) doesn't screw up printing. --MASEM (t) 10:57, 2 October 2009 (UTC)

• Mick, yes, the "upright=" factor-scaling system of resizing (e.g., 1.5 times the WPian's default setting) is a significant problem. It's a great pity that we've started with a ridiculously small default size for all of our readers and felt the need to give WPians the ability to upsize it for their own display. Now when we upsize the default for our readers (the 99.999% who really count), WPians will need to dump their privileged setting. And a good thing too, because we as editors and the managers of image placement and size should be seeing what our readers see. If I had a magic wand, I'd bin the preference settings for WPians and along with it the factor-scaling system. Apologies to Eubulides, who I know like 'em big. Tony (talk) 13:30, 2 October 2009 (UTC)

I agree with some of this, and Mikaul above. Yes there will need to be a great deal of adjusting, but imo a change in this direction is inevitable at some point, and the sooner we get it over with the easier it will be. I like them big too, but I also like them to fit on the screen. With scaled images on a 300px setting they often don't, but thankfully few images are set that way yet. The scaling systems should be binned, but there is no reason to abandon preference settings for people with different size screens, who use larger font settings etc. With sensible default size, far fewer images will need forcing or scaling. But having 2 ways of increasing default size that have unintended multiplicatory effects when both come together makes no sense. Johnbod (talk) 14:02, 2 October 2009 (UTC)

I think the images fit better into articles at a small size. I use a very large monitor, and I've tried various sizes,and always gone back to 180. I don;t think it affects usability of the images--Everyone who uses the internet knows to click on a picture to see it larger. I don't like wording like "the 99.99% who really count"--the readers using slow connections or obsolete equipment count just as much as anyone. the readers whop have fast connections and are knowledgeable are served very well already--they can just modify their settings. any image that needs large display can be specified. DGG ( talk ) 06:15, 3 October 2009 (UTC)

There are reasons for larger sizes though and it shouldn't require a person to click on the thumbnail if the information is lost due to downcoversion for the article.陣内_Jinnai 20:50, 3 October 2009 (UTC)

I'm fairly sure the 99% comment referred to all non-editing visitors, the point being that we are careful to cater for them, not ourselves. Incidentally it's from this perspective that we should recognize the futility of expecting any visitor to intuit that clicking on our barely-visible placeholder images will reveal amore readable size. I'm also completely unconvinced by objections on the basis of slow connections. While we should certainly avoid being a particularly slow-loading site, upsizing to 220px won't suddenly make it so. Compared to many sites, particularly those that carry advertising, our dialup visitors would still find us relatively fast-loading. A typical 450px web page illustration is the equivalent of four 220px wikipedia images. If the average article has this many images, the propsed change would add a very small percentage change in load times, like the New York Times running a 450px image in place of a 400px one. At least — at last! — dialuppers would actally end up with something worth waiting for. Or are these the same visitors we expect to click a thumb to view an even bigger pic? Doesn't add up, I'm afraid. mikaul^talk 03:06, 4 October 2009 (UTC)

DGG, if it is not a general principle, it should be: editors should not assume that readers will click on an image to see it at a reasonable size (many readers will not even know they can do that); and the assumption that readers will have to click on an image to make sense of it should be minimised. The latter involves a minority of maps (all too many at the moment, IMO), and I can see some that can't possibly be meaningful without clicking to see full size displayed—this should be regarded only as a contingency where the font-size of the text on a map is tiny and can't be boosted by us, for example. Tony (talk) 04:19, 4 October 2009 (UTC)

On the subject of assumptions about readers: I find it is VERY instructive to talk to non-computer savvy family members about wikipedia. You discover interesting things--namely that a lot of processes which seem natural to us are fairly obtuse to many newcomers (obviously the usability survey confirms this, but I am only speaking from personal experience). Protonk (talk) 06:14, 5 October 2009 (UTC)

Interim data. It's a data-rich RfC, so I've graphed the results thus far (down to User:DCB) hoping that it might help users to see the way it's going (clearly this is an interim result only). This captures the range of pixel widths that appear to be acceptable to each participant. Thus, 18% of participants would be OK with no change (180px, although some of them are OK with a range, say, up to 200 or 220, which has been counted); 80% find 220px (among other sizes) acceptable; and 50% find 250px (among other sizes) acceptable. I've made a few assumptions, such as when someone says "Support, up to 220", I added one point to each of 200, 210 and 220px, assuming their support for enlargement wasn't just for an increase from 180 to 190.Tony (talk) 04:50, 4 October 2009 (UTC)

• I have inserted this update here and on Tim Starling's talk page (he has been away and I hope to engage him, as one of the two paid WM developers, in a technical solution). Please note the following points:
  • There has been little change in community preference for an increase in the default size as the RfC has progressed.
  • This is only one way of expressing the results of the RfC: it emphasises the total range of acceptability to each participant, weighting the points in 10px increments equally through each person's range. A more complicated display might weight a single preference, say for 250px alone, more than each point throughout their range, or might register the average of each person's expressed range of acceptability as a single data-point, or might give weight to the few instances where there's an expressed preference (say for 220px) within an expressed range of acceptability (say, 180–200px). I have a feeling these methods would not make much difference to the overall interpretation of the data.
  • I've made a few assumptions where participants have been a little vague, in which the intention was to be NPOV.
  • Question: is it reasonable to end this RfC two weeks after it started? We're on Day 9 now? Anyone object? Tony (talk) 02:51, 9 October 2009 (UTC)
• Neutral, leaning toward oppose. Although the idea of a larger default feels attractive to a media editor, it's so simple to change one's default setting manually that this isn't an important issue for most of us in the first world. Handheld devices and third world readers are pertinent concerns--especially the latter. Wikipedia suffers from too much systemic bias already; any significant increase in bandwidth is going to have real impact. I know one editor from a developing country who copes with power outages that sometimes last five hours a day, and another from a different country whose village got electric power only within the last couple of decades. A single villager signing onto a voice service such as Skype can crash Internet connections for that neighborhood. These are realities for many people on the planet who bring cultural, regional, and geographic knowledge few of us in North America or Europe could replace. Let's keep a global outlook. Durova³²¹ 03:28, 5 October 2009 (UTC)

However easy it is to change default preferences manually, User talk:Werdna (my enquiry Sept 30th, about to be archived) says only 10,478 users have done so - a figure I find astonishingly low. More signposts to the preferences tab should be set up, whatever happens here. Johnbod (talk) 11:34, 5 October 2009 (UTC)

But but but ... the actualy number of active WPians with the preference setting would be only a fraction of this 10 thousand users. Werdna has surely provided the numbers of all registered accounts (almost all of them inactive, and some of them alt accounts). I want to know how many active WPs have set prefs: my guess is 10–20% of the thousand most active users. Tony (talk) 00:44, 6 October 2009 (UTC)

I've asked for more details, but no response yet. Are active readers, as opposed to editors, recorded logging in? It can't be assumed they are the same. If only 100-200 "active" editors have set preferences it is odd that such a high proportion of them have already mentioned the fact on this page. You said the same about date prefs, & the actual number was into 6 figures whichever way it was looked at. But I agree that prefs are set by a small minority, & are a poor argument for keeping the 180 default. Johnbod (talk) 01:01, 6 October 2009 (UTC)

Durova, what most of this has to do with the price of fish in Poland is beyond me. Increases in bandwidth are a fact of life all over the world. Most of the world doesn't even have telephony. Is it a third of humans who have no electricity in their house? Sorry, we can't do the impossible; and it is the English WP, not the Tibetan WP. The project needs to look forwards, not backwards, or it simply won't compete well on the Internet. We need to be dynamic and adaptable, not stuck in a lowest-common-factor mindset. Reasonable bandwidth is a reasonable assumption for an online encyclopedia. Restricting ourselves to what downloads in a few seconds via the slowest connections is not. If this were a really significant increase, such as would be required by the large-scale introduction of videos, we might need to think carefully. But it's not. Durova, what is your window of acceptability? 180px alone? 180–200px? Tony (talk) 05:29, 5 October 2009 (UTC)

• "Most of the world doesn't even have telephony." Not true. Currently there are more than 4 billion mobile handsets in use around the world, with about 3 billion of these in developing countries. Some people have more than one mobile phone, of course, but the actual number of people with mobile phones is about 3.6 billion. Current predictions are for 6 billion mobile phones by 2013. Almost every adult who wants a mobile phone will have one by then. (My source is the 2009-09-24 Economist special section on telecoms in emerging markets.) (This analysis omits fixed-line phones, which are now in the minority.)
• "Reasonable bandwidth is a reasonable assumption for an online encyclopedia." Currently about 30% of Internet users worldwide are on fixed-line broadband. About half that are mobile broadband. The rest (i.e., the majority) are on slow connections. There is a particular problem in Africa, not only because of the infrastructure within the continent, but because of lack of connectivity to the rest of the world (this is being worked on, but it's still a problem). (Same source as before.)
• Here's one data point. The current featured article is Virus. It is not particularly image heavy but has a lot of fancy text. It currently takes 686,899 bytes to download, including images (more than half of the bytes are text). Changing the default to 250px would increase the total to 833,925 bytes, a 21% increase. Even the smaller size is waaaayy too large for a slow connection; the larger size would make it even worse. If we look only at the affected images (which would be appropriate for the worst case of a page with a lot of default-size thumbs), the number of bytes grows from 194,281 to 333,634, a 72% increase.

Eubulides (talk) 07:14, 5 October 2009 (UTC)

• A lot of these are matters of degree. Site bloat is not uncommon, but wikipedia is notably much less bloated than most of the other top 1 websites (save google). How much less bloated is an open question. I can certainly see a good argument as to why wikipedia should use the minimum thumbnail size possible, but we need to acknowledge that technical arguments and "the kid in Africa" comprise only part of the discussion. The other part is given that tradeoff, can we justify increasing the default image size? Protonk (talk) 07:24, 5 October 2009 (UTC)

• Striking part of my earlier statement and overwriting a previous reply. Perhaps the boldface formatting generated confusion; please accept my apologies for that. Shortly after I posted another editor moved it (in good faith) out of the comments section to the poll section. Mainly I intended to raise a new angle for discussion. People who know the background should be aware how disinterested this is. Best regards, Durova³²¹ 17:19, 5 October 2009 (UTC)

• Protonk's summary sounds right to me. If we take the consensus as 180px is inadequate what remains is a decision on exactly what the minimum tolerable thumb size is, and going with that. The tradeoff for 220px is considerably smaller than that for 250px. Perhaps we should be weighing that up, rather than wringing hands over unlikely scenarios. Really, I think a serious drive to audit articles and remove forced thumbs (given a new default off 220) would be a net bloat-reduction, as a great many articles are currently either over-illustrated or have 250px+ forced upon them. mikaul^talk 23:19, 5 October 2009 (UTC)

• Then it appears we lack enough common ground for discussion. Your analysis appears to begin by presuming the very point I question, and "wringing hands over unlikely scenarios" is hard to even parse. It is common knowledge that most people in third world countries don't have high speed Internet access, and equally well agreed that Wikipedia does not cover the developing world as well as it should. Indonesia has about three-quarters the population of the United States, yet we seem to have only one Indonesian FP. Durova³²¹ 13:37, 6 October 2009 (UTC)

I think your point was addressed well enough by Tony upthread and second his asessment. My "hand wringing" comment was aimed not at your remarks but at Eubuildes' stat analysis, based on a hypothetical 250px default, which looks unlikely to be adopted as things stand. mikaul^talk 23:58, 6 October 2009 (UTC)

If the default is changed from 180px to 220px, then the number of bytes in the affected images in the current featured article (Catherine de' Medici) will grow from 153,784 to 234,878, a 53% increase. I don't think it's hand-wringing to point out the increase in sizes, or to mention that the poorer half of the world's Internet users lack broadband connections. Eubulides (talk) 05:29, 7 October 2009 (UTC)

Eubulides, this sudden enthusiasm for advocating the interests of the world's poor is perplexing. Why is it you've never said anything about the profligate use of many images some articles? For example, London Heathrow Airport has more squinty thumbnails than you could poke a stick at (some of them of marginal usefulness/interest). This bumps up the byte-size of an article much more than the proposed increase from 180 to 220px. Is that article a denial of human rights? How many dial-up users can't make out what on earth a 180px image is, and need to double-click on it? That uses much more bandwidth than more reasonably sized thumbnails in the first place. Tony (talk) 06:27, 7 October 2009 (UTC)

Is this really the place to be commenting on another editor's "sudden enthusiasm"? or to make comments about "human rights"? I've never once mentioned human rights. And I haven't changed my enthusiasm for making Wikipedia available to a wide audience, an audience that includes a large number of people who don't enjoy broadband. It's true that some articles have too many images, but that doesn't alter the point that going from 180px to 220px will make access to Wikipedia noticeably worse (in terms of delay) for about half of the world's Internet users. Surely it's not too much to ask to try this change out first, before installing it as the default for everybody. Eubulides (talk) 07:37, 7 October 2009 (UTC)

A lot of contributors here have tried 250px and liked it because it is much, much easier to "read" an image without clicking it. 220px would obviously not be quite so readable but it represents a considerable improvement over 180px. This much can be gleaned from the discussion above; a few test edits are all that's required to demonstrate the relative pointlessness of 180px thumbs, ie you want to read them, you have to click them. While it remains for one of our paid developers to comment on exactly how this will impact the usability of the site (no offence, but I'd like to have a more "official" reading of the relative download burdens involved – 180 to 220 is patently not a 50+% increase, for example) are we really going to reject this site-wide improvement on the basis that some image-heavy articles will take a few seconds (roughly 15 in the example you cite) longer to download for a handful of visitors? And does the reduced need to click on an illustration in order to read it really represent a raw deal for dialup users? Surely enhanced one-click viewing of articles mitigates a slightly longer load time. If this is what it's come down to, let's start thinking in terms of realistic viewer scenarios, not whizz-bang statistics. mikaul^talk 09:34, 7 October 2009 (UTC)

"180 to 220 is patently not a 50+% increase, for example)" Yes it can be a 50+% increase, because the amount of data goes up as the square of the image size, and (220/180)² is 1.494, or a 49.4% increase; due to the vagaries of compression the value can go above 50%. The "lot of contributors" mentioned above are most likely broadband users. I'm worried about the half of Internet users that are not broadband users. Half of all Internet users is not a "handful" of users. I don't know where that "15 seconds" came from, but adding a 15-second wait per page would certainly discourage me from visiting a web site. Eubulides (talk) 09:43, 7 October 2009 (UTC)

Yes, like I said, not a 50%+ increase... the devil is in the details here. Correct me if I'm wrong, but I estimated fifteen seconds to be the time it would take to download the extra 80k you estimate 220px thumbs would add to Catherine de' Medici over a 56k dialup connection. You're surely right in correcting me about worldwide broadband penetration, although I'd like to question that statistic as regards actual visitors to en.wikipedia. But enough about statistics. The point I was making is that these numerical factoids are not experiential values. You betray this point in your last sentence; fifteen seconds to a dialup user is a blink of an eye in the pedestrian experience that is dialup surfing. It might put you off with your near-instant high-speed experience but then you're not properly empathising with the dialup user in saying that. And the point remains unanswered: does the reduced need to click on an illustration in order to read it really represent such a raw deal for dialup users? mikaul^talk 11:02, 7 October 2009 (UTC)

Yes, it does represent a raw deal. I've been a dialup user, and I know what it's like. For Wikipedia it can be quite bad. To some extent I expect it's so bad that these users are deterred from visiting Wikipedia's articles, or at least the articles with several images. And now you're quibbling about 49.4% versus 50%? I looked into that, and it happened because going from 180px to 220px increases the sizes of images marked with plain "upright" from 140px to 180px, which (if you take the square of 180/140, and ignore compression) is a 65% increase in bytes. That article had multiple "upright" images, so it went over 50%. I expect other articles would be similar. Eubulides (talk) 16:15, 7 October 2009 (UTC)

Actually "upright" settings are pretty rare in my experience, though becoming more common. They were very obscure until recently, & I doubt most editors have heard of them. I'm always adding them in (but never scaled). Johnbod (talk) 16:34, 7 October 2009 (UTC)

<outdent<- If you leave out the scale factoring, upright markup is one of the good things to have evolved recently, preventing vertical image thumb sizes from running the same width as horizontal ones, effectively keeping them to the same size (pixel count) so I don't quite understand the fine distinction being made there. Look, it's probably worth stating outright that I'm fully AGF here and I do appreciate this valid concern over page sizes. My concern is that statistical analysis might distort our perception of end user experience.
Speaking for myself, I used dialup for 10 years and took an active interest in website optimisation from the start, as part of my work. I do understand how a page of 220px images behaves relative to a page of 180px ones at <56kbs. I've also experienced Wikipedia at this connection speed. In all honesty, it never once put me off visiting because it was no different to other websites in terms of usability. Since then, I would argue that, with the proliferation of media-rich sites and especially banners, ads etc that we don't carry, the rest of the web has in fact become much less dialup-friendly than Wikipedia. Significantly, back then I did avoid viewing images at preview size unless it was absolutely essential; on an sVGA monitor it was rarely necessary; on an HD display, clicking on 180px thumbs is almost obligatory if they are to function as illustrative content. As pointed out above, HD viewing is fast becoming the default reality for the vast majority of visitors. In summary, we can not only afford this increase, we can't afford not to implement it.
I've bolded the main points here that seem to me to be unavoidable facts of web-based life. Upthread are a number of good suggestions for reducing bloat and streamlining our articles that would go a long way towards mitigating a nominal increase in thumb default size. We're long overdue an image overhaul and it seems obvious to me that workable default positions that editors don't (therefore) just ignore – including cohesive, consistent style and usage policy – is an eminently sensible foundation to base it on. mikaul^talk 00:36, 8 October 2009 (UTC)

Some of the editors who have already commented at this thread are already well aware that default thumbnailing produces differently sized images. That's not necessarily an argument to increase the default sizing, though. Durova³²² 22:07, 8 October 2009 (UTC)

• Ongoing image auditing is necessary whatever the new thumbnail size. Thumbnails differ in their size, even at the same default or the same forced px width. See, for example, the yellow monster in the second section down here, which is at default 180px size. But the obvious fact is that the majority of pics, which are at thumbnail size, are ridiculously tiny. Raising the default to 220px will be a good start. Tony (talk) 00:34, 6 October 2009 (UTC)

The arguments made on slow connections i have to say is a farce. I use both a broadband connection (normally) and occiasionally at other people's houses my DS browser (when I can't access their computers directly). The connection speed on the latter is rather slow and while I do turn off image loading sometimes (usually on image-heavy pages), it is the walls of text more than the images that keep my browsing then to a minimum.陣内_Jinnai 20:58, 8 October 2009 (UTC)

Durova, yes, my point was that editors will still need to manage the size of a minority of images, even when the default size is made more reasonable. Tony (talk) 00:38, 9 October 2009 (UTC)

Actually a new type of scrolling template was created for that featured picture. You certainly seem to be sincere in this effort, but really in response to your query at FPC talk what I'd much rather see is a bot to check and give notification when a featured picture gets removed from an article. With over 2000 featured pictures, many of which appear at multiple articles, it's impossible to keep track of that by hand. Perhaps also a featured content star for the caption box so that readers could tell at a glance which images would hold up at higher resolution scrutiny. Proportionately, the featured media is outnumbered by low quality images that really aren't worth the trouble of resizing. Durova³²² 02:13, 9 October 2009 (UTC)

• It has been quite a while since this discussion was started, and we have a fairly strong consensus for changing the default size to 220px. What next? –Juliancolton | ^Talk 02:14, 11 October 2009 (UTC)

• 11 days now. I've posted and posted on Tim Starling's talk page, and sent him a ping email. He hasn't edited since 15 September, so perhaps he's on a month's leave. Tony (talk) 02:51, 11 October 2009 (UTC)

• Be good to get some feedback from a buro before too long. We do have some encouraging can do techie notes from Jarry above and I'd suggest we concentrate for now on nailing a definitive size. Tony's graph is interesting in that it shows a range of preferences, ie a majority clearly supported 220px but this might have been swayed by my suggesting it in the first place. There are some well-reasoned agruments for at least 220px and the graph does show an average (mean? I must have been off school the day we did all that..) preference for maybe 230px, or 235... maybe someone good at maths could work out what it is. Point being that (per Jarry's explanation) there are kind of preset options to reset the default to either 200 or 250, but anything between these would have to be specifically coded for. mikaul^talk 06:07, 11 October 2009 (UTC)

• Support 220-300 range Anything short of 300 is fine with me. Based on the recent issue with a certain jellyfish, I support a larger thumb. Too large, however, will crimp loading time etc.   Nezzadar ☎   16:05, 22 October 2009 (UTC)

• Oppose. I realise I'm massively late to the party, and apologies if I've missed things (WP:TLDR), but I don't think this has been adequately thought out. Many lists (especially FLs) have columns of images down the side of tables and may use a column big enough to "fill" the section. Increasing default image size may cause unneccessary overflow into other secitions and ugly indentation of section headers and the like in articles. Also there are WP:ACCESS concerns about squashing text, especially if images are along side tables. Finally some image templates like {{Double image stack}} have the size (currently 180) entered manually and without the thumb option I feel would display strangely (it's okay for people who have made their preference a different size, but for all our readers to see this, is rather messy.) Rambo's Revenge (talk) 19:24, 28 October 2009 (UTC)

"Fill the section" on whose screen exactly? That will depend totally on the user's kit. If for any reason the current situation is considered the best for any particular images, the old effect can be achieved by "upright=0.8", which turns 220 back into 180. I don't understand the second point at all - by the sound of it these images will be unaltered, for good or bad. Johnbod (talk) 19:45, 28 October 2009 (UTC)

Okay I'll give an example: the column of images alongside the table at Premier League Manager of the Month fill the section, and I believe it would take a very narrow screen to make the table wrap and the images to not fill the section. My second point was that the template wouldn't change but any images around it would, making it appear strange when in a column as it will be a different size. Rambo's Revenge (talk) 22:13, 28 October 2009 (UTC)

You needn't worry about the first one; it looks ok, and fits, with my 300px preferences, though some are too big (plain "upright" might be advisable). On the second, yes, but this is hardly a major issue in the context of all the default pics on WP. The change (which is now going ahead btw) will certainly mean many things should be readjusted, as people have said several times above. Johnbod (talk) 23:10, 28 October 2009 (UTC)

I was aware this is going ahead, and actually I'm okay with this; however I do think this is a more major change than people are making out, and there will be a lot of things that need readjusting. Rambo's Revenge (talk) 23:37, 28 October 2009 (UTC)

So is it to be 230px?

• Since the range of acceptable widths is well weighted on the greater than 220 side rather than the smaller than 220 side, I suggest that 230px would be a truer reflection of community opinion. I believe the Swedish WP has 250px. Tony (talk) 07:34, 11 October 2009 (UTC)
  • I think it might not be since if we take into consideration all those above and below that range (220 for those below that and 250 for those above that) then i'm not so sure.陣内_Jinnai 07:56, 11 October 2009 (UTC)
  • Is there any way of gauging a statistical average with the data you collated into the graph? It might end up being little more than academic interest, but it would probably help define that assessment as a pixel dimension. mikaul^talk 08:10, 11 October 2009 (UTC)

I don't think 230px is the consensus. Arguably the consensus is 220px. --Skeezix1000 (talk) 16:44, 11 October 2009 (UTC)

• About time I got myself an informed opinion on the results, so I checked over the support-opposes and it seems clear that:

1. roughly 10% would prefer no change at all, or for increases to be <220
2. about 35% support 220px (including "per nom" supports assumed to be 220px) or are agreeable to anything ≤220
3. the remainder (≈55%) see 220px as a bare minimum, preferring a range of sizes greater than this

I'm no statistician but I think this clearly points to election of an increase somewhere beyond 220px. A couple of thoughts on this: the temptation to pick a statistical average should be tempered by awareness of this being a mere 50-odd opinions out of our entire editor base. Discretion may be the better part of valour here, and selecting 220px may be just plain good diplomacy. It might well be less troublesome to implement 220px and review it in a year (or so) rather than plough in with something that's going to upset applecarts. The point that sways it for me is that, looking at the %s I've posted here, with 220px we have a resounding consensus for change. --mikaul^talk 21:00, 11 October 2009 (UTC)

If they see 220 as the "bare minimum" it is still a minimum they would be willing to accept.陣内_Jinnai 20:12, 12 October 2009 (UTC)

Exactly. Tony's already put in a formal request to that effect, see below. mikaul^talk 20:28, 12 October 2009 (UTC)

As long as there is consistency

I am not to set on any particular value. 200 - 230 seems good. As long as we have consistency between all pages and can thus set almost all images ( 98% ) to the default size.Doc James (talk · contribs · email) 23:37, 4 November 2009 (UTC)

Important debate on the "multiplier" method of sizing images

It's probably easiest to retain it at the MoS at this stage. Please contribute. Wikipedia_talk:Manual_of_Style#The_multiplier_method Tony (talk) 04:48, 25 October 2009 (UTC)

The default thumb size saga

I've raised the recent postponement of the site-wide increase at Jarry's page. Tony (talk) 04:15, 7 November 2009 (UTC)

Filename extensions

Sorry if this has been brought up many times before, but I feel that we ought to deprecate including a filename extension in the name by which an image is published. I presume MediaWiki allows this?

Case in point: File:PetSocietylogo.jpg was once a JPEG as its name implies, but this was the wrong choice of format; now a PNG has been put in its place, but it's stuck with this relic in its name (as long as the concept of moving pages doesn't seem to apply to files). If it had been named as simply File:Pet Society logo, then nobody would be misled about the format of the file. While in this case the fault lies in the fact that somebody uploaded a JPEG in the first place, there are some more legitimate cases in which an image may change format:

• The question of whether a given image should be a JPEG or a PNG is a grey area, and successive versions may vary in format.
• Sometimes only a JPEG version is available, e.g. of a company logo copied from the company's website, but the company may later mend its ways by putting up a PNG or SVG version (or somebody here may fix the image). (Alternatively, a company may redesign its logo such that the best format for it changes - but then there's the question of whether the new logo should be uploaded to WP under a new name so that an article can show how the logo has changed over time.)
• An image is created as a PNG pending finding someone with the time/expertise to redo it as an SVG.
• Some new or long-forgotten format becomes massively supported in browsers, and it turns out to be a good one into which to change a file. (This may apply to video/animated formats and even audio formats and other media, not just images.)

What do people think? -- Smjg (talk) 09:43, 12 November 2009 (UTC)

The software doesn't allow renaming images at present. You already uploaded File:Pet soc halloween.png after you re-made it. What I think you should have done is change the article to use 'File:Pet soc halloween.png' and request deletion of the jpg version. I ought to add that your new image only has 879 colours, so can very easily have its colour depth reduced to 256. The resulting 8-bit palleted PNG is half the filesize and looks identical (to me). As it is used only in an infobox at 200px wide, it is best to shrink it to that size first and then reduce it to an 8-bit PNG. The resultant file (even with transparency) is less than 7 kB, rather than the present version that the wikimedia software renders which is 17 kB. It possibly isn't a big deal for that article, but does add up when articles have multiple images.

There may be multiple versions of an image uploaded: as a vector image (like filename.svg) and an optimised paletted PNG (which would be filename.png). Deprecating the extension would require us to differentiate between those two files in the name (e.g. filename_svg and filename_png), which really defeats the intention of deprecating the extension. --RexxS (talk) 20:43, 12 November 2009 (UTC)

Wait, is Smjg saying that somehow a PNG image was uploaded with a JPG filename? Powers ^T 14:38, 13 November 2009 (UTC)

Yes, File:PetSocietylogo.jpg is now a PNG. There's nothing in the software to stop anybody replacing a JPG with an updated version which is not a JPG. *Shrug* --RexxS (talk) 19:19, 13 November 2009 (UTC)

RexxSS - Firstly, I didn't upload any such image. What are you talking about? Secondly, I'm somewhat confused by your second point. What would be the point of having both the SVG version and the PNG version side by side? -- Smjg (talk) 01:36, 14 November 2009 (UTC)

1. File moves are allowed, so I moved this to File:PetSocietylogo.png
2. File redirects are allowed, so all existing uses of File:PetSocietylogo.jpg now render from File:PetSocietylogo.png.
3. The developers plan to make file extensions optional in the future, but this isn't available right now.
4. For the present, I would encourage people to make sure images live at a location with an extension that makes sense for their file type, otherwise some users may experience bad behavior.

Dragons flight (talk) 19:50, 13 November 2009 (UTC)

Two downsides to this: The image description page now shows no articles linking to the file, and it's a non-free image, so I expect a bot to be marking it for deletion anytime soon; The wikimedia software now delivers a 200px png that is 25.7 kB in size - see Pet Society. --RexxS (talk) 22:50, 13 November 2009 (UTC)

Seems odd - why does MediaWiki go out of its way to require an extension if it doesn't check it against the MIME type? Moreover, moving the Halloween logo to File:PetSocietylogo.png seems wrong. That should, if anything, be the regular Pet Society logo, and any special festive logos should have specific names, such as File:Pet soc halloween.png as somebody has taken the liberty to create. -- Smjg (talk) 01:36, 14 November 2009 (UTC)

As far as I can see, the images are stored with a file extension because the originals are directly accessible from the internet (as far as I know, it is conventional that file servers will do this) - for example, the image for the file uploaded at File:Pet soc halloween.png is accessible at http://upload.wikimedia.org/wikipedia/en/b/bf/Pet_soc_halloween.png. I assume that the MIME type is set at the file page when the image is uploaded (rather than checking it every time it is accessed) for performance reasons. So it is possible to upload a PNG to replace a JPG and it will have the .jpg file extension although its MIME type will be correctly set on the page to "image/png".

A further complication is that when the article page is viewed, if a different size is required, the software will resize the image and serve your client with a different image - http://upload.wikimedia.org/wikipedia/en/thumb/b/bc/PetSocietylogo.png/200px-PetSocietylogo.png in the case of the Pet Society. Unfortunately, this is an unoptimised non-paletted PNG and the smaller image served actually has a larger filesize than the original in this case. It's much worse when the original is an SVG, by the way.

As for the Halloween version of File:Pet soc halloween.png, it was uploaded on 5 November 2009 by Jackdyson (talk · contribs). You'd need to ask him/her why he/she replaced the regular logo. He also uploaded File:Pet soc halloween.png on the same day. Hope that helps --RexxS (talk) 18:18, 14 November 2009 (UTC)

Your first sentence is bogus - filename extensions are irrelevant under WWW protocols, where MIME type is used instead. Look at Wikipedia article URLs for instance. Why can't names of uploaded files work in the same way? As such, the reaon for setting the MIME type at upload is probably a matter of keeping with the spirit of the protocols. ISTM likely that it uses the MIME type sent by the browser when the file is uploaded, possibly with a few Microsoftism fixes thrown in. Even if it did use filename extensions, I think it would probably use the source rather than target filename. -- Smjg (talk) 09:47, 16 November 2009 (UTC)

Isn't 'bogus' a bit harsh? I never said anything about wwww (you mean http) protocols. In the general case, if I access a file using ftp protocol, then the MIME type doesn't come into it. Remember MIME types were actually designed as an extension for emails. In the case of Wikimedia webservers, you're right, they take no notice of the name of the file (or its extension), so we could stop using extensions. But there are downsides. Under your scheme, if I were to download "YourImage" to work on it, I'd have to work out and supply an extension myself, as my OS handles files by their extension. Additionally, at present I can upload "MyImage.svg" (MIME=image/svg+xml) and "MyImage.png" (MIME=image/png). What filename would you use for each of these versions of the image? What do I gain by dropping extensions from filenames? --RexxS (talk) 22:26, 16 November 2009 (UTC)

To address each of your "downsides" in turn:

1. But for SVG to PNG conversion at least, MediaWiki automatically appends an appropriate extension to form the actual URL of the image. For example, File:Square root of 2 triangle.svg generates the URL "http://upload.wikimedia.org/wikipedia/commons/thumb/a/a6/Square_root_of_2_triangle.svg/500px-Square_root_of_2_triangle.svg.png". Now that the one I mentioned has been renamed I can't test it now, but have you checked whether it does the same with images that just have the wrong extension? (And even if it doesn't, browsers should set the right extension on save in any case.)
2. You still haven't answered me: Why do you want SVG and PNG versions of an image side by side on Wikipedia? Especially given that SVGs are automatically converted to PNGs for display anyway. If somebody uploads a PNG image, and later somebody improves the work by creating an SVG version, the natural thing to do is make the SVG file replace the PNG file.
   Actually, I can think of one example: comparisons of graphic formats. For these, you will likely want versions of the same image in different formats. But these are the exception, and it's easy to deal with by making one. Once the technical restriction is dealt with, how about this general rule: If the choice of format is the whole point of a particular uploaded file, then include a filename extension, otherwise don't.

We probably don't really need to go through renaming existing images. But when/if this change is implemented, the upload UI will want adjusting to it, though going into this topic here probably constitutes getting OT.... -- Smjg (talk) 19:20, 17 November 2009 (UTC)

Please don't take this the wrong way, but you're missing some points I made earlier. Sorry if I wasn't clear enough. The file you upload retains its name and extension. When the software serves a page that contains an SVG, it renders an appropriately-sized image as PNG and saves it with an added .png extension. The original is still there at http://upload.wikimedia.org/wikipedia/commons/a/a6/Square_root_of_2_triangle.svg as you can see. But your system would prevent me from having both a PNG and an SVG with the same base name - I couldn't have File:Square root of 2 triangle.png without extensions. How would you solve that?

The real point is that we need both an SVG and a PNG, because the wikimedia software renders SVG into PNG rather dumbly. Take a look at Oxygen toxicity. There's an image there called File:Clark1974.svg which is rendered and served as an unoptimised, full-colour PNG at 700x252 px with a file size of 30 kB (http://upload.wikimedia.org/wikipedia/en/thumb/1/1d/Clark1974.svg/700px-Clark1974.svg.png). Now look at File:Clark1974.png - it's 700x252 px and less than 9 kB. That's a saving of 20 kB or 70% in just one image. It is usually easy to optimise an image to reduce its filesize without any noticeable effect on the page viewed. In a big article with many images, that can be a substantial improvement in accessibility for users with limited download speed - and that's a significant number of our viewers.

Until wikimedia software becomes 'cleverer' at rendering the images it serves, we degrade the experience for many readers by slavishly following the advice to use an svg when a well-crafted png is far superior. Until then, I still need SVG and PNG versions. --RexxS (talk) 23:38, 17 November 2009 (UTC)

So the point is to use a paletted PNG in the article, and place a link on the file page to the SVG version so that people can view it if they so desire. I see now. On this basis, I wonder how many of the images tagged with {{Should be SVG}} should actually be or remain PNGs in a colour depth below 24-bit.

Maybe there's a policy out there that would achieve the best of both worlds. The best I can come up with is to keep .svg but do away with .gif/.jp(e)g/.png. But this seems somewhat ad hoc.... -- Smjg (talk) 19:25, 18 November 2009 (UTC)

Yes - also having an SVG version allows others to modify it or resize it, etc. and then create an optimised PNG for their use. Clearly it only gives a big advantage for larger images that don't require full 24/32-bit colouring, but it's something I wish more editors understood. Thanks for the discussion anyway, it's forced me to clarify my thoughts on the issue. I hope that somewhere it could be mentioned in policy as an example of best practice. Happy editing --RexxS (talk) 19:47, 18 November 2009 (UTC)

Rule of thumb 9

"Below this brief checklist of image use rules is the detailed reasoning behind them.

...

9. In general, there is no need to specify thumbnail size. Users can select their ideal size in preferences."

The detailed reasoning for not specifying thumbnail size consists entirely of the observation that less than 10% of viewers can set a different default. I'd suggest it's time to either get rid of that rule of thumb or find a better reasoning. (ref: 47,569,862 registered users vs 166 million unique viewers per month). --RexxS (talk) 02:21, 16 November 2009 (UTC)

There was a lengthy conversation that went from WP:FAC (I think ) though one of the MOS: Long story short: images do not need to be set to "thumb" size, but at the same time, specifying an image outside of "thumb" size should be undertaken when editors think necessary to display more information. That is, for most editors dealing with images, there's really no reason to mess about with image size, so "thumb" is reasonable, but it is not meant to be hard and fast. (Also as a result of the above, we're trying to get the default image size up to 220px instead of 180px).

Thus, I would argue that wording can be changed to :

• In general, there is no need to specify thumbnail size, as the "thumb" parameter will ensure that all images appear at the same size to the reader. However, as necessary, thumbnail sizes can be specified via the "width" or "upright" parameters to help to show images with more detail or fit images with atypical aspect ratios.

or something like that. --MASEM (t) 02:48, 16 November 2009 (UTC)

The previous comment is right, but the proposed rewording is pretty long for a rule of thumb. How about the following rewording instead?

'Often one can omit thumbnail size, or merely specify "|upright|" if the image is tall. See the manual of style for guidance on other image sizes.'

Eubulides (talk) 02:50, 16 November 2009 (UTC)

Hmm, maybe for sake of brevity: If unsure, use "thumb" for default image sizes, but this is not required. --MASEM (t) 03:03, 16 November 2009 (UTC)

That goes a bit too far the other way, surely. Also, it's not quite technically right, as "|thumb|" does several things; it doesn't merely select an image size. Eubulides (talk) 03:16, 16 November 2009 (UTC)

Thanks for the feedback. I actually followed those debates—and their conclusions—with interest, so I was rather astonished to see us still giving that rule of thumb here. I'm a strong supporter of the view that editors should have the ability to make a decision on image size for legibility and aesthetic reasons (see some of Giano's views on the effort he takes to ensure a good balance in the images he adds to architectural articles). Over-simplified 'rules-of-thumb' lead to Randy in Boise going through articles removing the carefully considered image sizing, on the grounds that 'our policy says so'. I'd also add that a rule-of-thumb containing a "detailed reasoning" is a bit of an oxymoron, in my very humble opinion :) --RexxS (talk) 03:26, 16 November 2009 (UTC)

The problem is that for every editor that carefully and thoughtfully considers image sizing, there are many more that force image sizing without a lot of thought. And at the end of the day, it's more often than not a subjective preference - what is a good aesthetic choice for some people is completely unnecessary to others.

As for the proposed wording, we should keep it simple and refer people to the MoS. I'd stick with something simple, such as: "In general, there is no need to specify thumbnail size. See the manual of style for more information." --Skeezix1000 (talk) 23:32, 16 November 2009 (UTC)

I completely agree with removing "policy level" advice that says "use thumb size always". However, as I argued there, the last thing we should be doing on WP is pixel-perfect placement because of the numerous possible output devices a page should go for. If you don't know or don't care, thumb works great. If you do know and/or care, set a size. (I'd argue that there's a step here that this is general true for certain images classes like maps and figures and rarely true for most others, but that's not appropriate on this page) But key is no one should be on your back for moving away from "thumb".-

As for wording, then, You may specify an image size per WP:MOSIMAGES, but best left at default if you are unsure. ? --MASEM (t) 23:52, 16 November 2009 (UTC)

Wording along the lines of "you may specify an image size" is too permissive, even with the reference to MoS. --Skeezix1000 (talk) 00:14, 17 November 2009 (UTC)

I hope you can accept that I'd disagree. The phrase "you may specify an image size" is exactly what I'd like to see, as I want to see editors empowered, not circumscribed, when making editing decisions. I accept that guidance should be given in making those decisions and Masem's last suggestion hits just the right note for me. --RexxS (talk) 00:35, 17 November 2009 (UTC)

To turn it upside-down: why are editors being at all encouraged not to determine size on the basis of local conditions, for every pic? Tony (talk) 02:24, 17 November 2009 (UTC)

Because editors' local conditions so often differ from readers', and editors are notoriously bad at guessing what readers' conditions will be like. And because messing with trivia like pixel counts (should it be 300px? or 310px?) is so often a waste of editors' time. By the way, Skeezix1000's proposed wording is all right with me (though of course I prefer mine...). Eubulides (talk) 03:38, 17 November 2009 (UTC)

(ec)Agree with that. On the whole I'd prefer a positive recommendation to use thumb except for lead pics or if there is a good reason not to, which I think is what the MOS said last time I looked. Johnbod (talk) 04:02, 17 November 2009 (UTC)

• Response to first part: yes, and we need to spell out the "window" of standard differences likely to occur, without stooping to ten-year-old computers on bad dial-up connections. Needs negotiation. Response to second part: It's not trivial, or perhaps we're on different planets. I'd say "should it be 220 (impending default) or 260?"; and sometimes I have fiddled by 10 pixels. Are you saying that tweaking grammar is a waste of time? Tony (talk) 03:44, 17 November 2009 (UTC)

(ec)With grammar it is (more or less) either right or wrong for everybody; you can never say that with pictures, with a whole range of different tastes on a whole range of different kit. I can't personally understand those who are really attached to 150 or 180 pics on "normal" modern machines, but I respect their pov. Johnbod (talk) 04:02, 17 November 2009 (UTC)

Images at default should be kept small to avoid cluttering of images made by inexperienced editors that do not yet know about thumbnail size parameters. There are some cases in which the image can go much bigger without cluttering the article, thus can be made as big as the editor's convenience. But I'd argue to keep default size with the exception of diagrams, because readers use different monitors and hence different screen sizes, which can result in negative results in article display that contain inconsistent image thumbs. ZooFari 04:00, 17 November 2009 (UTC)

There's certainly no single right answer: I'm happy with large images on my 1600x1200 Apple Cinema Display, but I want small ones on my 12" laptop. Short of changing my preferences every time I walk from one room to the next, there's no method of getting what I want.

IMO, editors with a good reason for a non-default size should follow their good reason, and without a good reason, they should follow the default-oriented rule of thumb. WhatamIdoing (talk) 06:12, 17 November 2009 (UTC)

That's a good way of looking at it. An if in doubt, use defaults approach deters consideration of appropriate forced-sizing, while a policy that suggests sizing merely be defensible, if challenged, is far preferable and pretty much how I read the consensus here. mikaul^talk 06:33, 17 November 2009 (UTC)

So to summarize:

• We want to make sure its clear that default image size is by no means required (we should not be edit warring over it), and probably would fall under "first editor's pick" ala choice of US/Brit English and US/Int'l date format as other MOSes.
• We want to make sure its clear that there's more exacting advice at MOSIMAGES that talk about maximum size, other parameters, etc. to help with images placement
• We want to make sure editors are aware they don't have to mess about with the extra parameters if they don't want to
• We want to make sure editors are aware they can mess about with extra parameters to adjust image size to better resolve the image.

Obviously too much to say for a short line, but trying to make this a positive case towards allowing resizing:

Images should be adjusted in their display size to clearly show their content under a variety of display resolutions within the article context. For many common images, Wikipedia's default image thumbnail size is sufficient for this. More guidance can be found at WP:MOSIMAGES.

This is a bit different from the above suggestions but I think captures the subtle points being made here - thumb is not required but often best, and moving from thumb is a completely allowable adjustment in order to Any more specifics we can toss at MOSIMAGES, but this is the quick and dirty rule of thumb that hopefully prevents the concerns of thumb-size edit warring. --MASEM (t) 19:51, 18 November 2009 (UTC)

Thank you Masem. I think anything along those lines would be a much-welcome improvement on the current rule of thumb. If anyone thinks it's too long, it could be pared down a bit at the expense of losing a little precision:

Images should be adjusted in their display size to clearly show their content under a variety of display resolutions within the article context. For many common images, Wikipedia's default image thumbnail size is sufficient for this. More guidance can be found [is] at WP:MOSIMAGES.

I'd really like to see the present text amended, do others now agree? --RexxS (talk) 20:13, 18 November 2009 (UTC)

Well, the idea that we can second-guess readers' display res doesn't gel with the above discussion at all. I'd suggest Image display size may be adjusted according to their content and page layout, however WIkipedia's default size is sufficient in many cases. Or even most cases. mikaul^talk 22:59, 18 November 2009 (UTC)