Unless we're living in a world of 56K internet still, I think 32K could become at least 50K. Even articles on albums by Eminem and so forth are getting above 32K - Giving that limit is slowly even limiting the growth of good articles. If an article grows above that it should be allowed to grow, unless it is obviously repeating itself. ----- Original Message ----- From: "JAY JG" <jayjg(a)hotmail.com> To: <wikien-l(a)Wikipedia.org> Sent: Friday, May 20, 2005 9:06 PM Subject: Re: [WikiEN-l] Article size consistency 32k

The issue is always download speed when we serve a diverse international audience and at least make noises about serving the poor and the third world. Serving up articles over 100kb long with several images each over 200kb will basically stop a slower computer with limited memory operating with a modem in its tracks, sometimes even requiring a reboot. Essentially the site becomes unusable. Fred

Geoff Burling (llywrch(a)agora.rdrop.com) [050522 07:28]: Then you need to get MediaWiki 1.5 installed locally and write the user preference code to switch all images off ;-) - d.

Geoff Burling wrote: What browser are you using?? Firefox (and IIRC Opera) doesn't wait for all the images to load before it displays the text.

This is the typical type of problem you run into with folks using old equipment and obsolete software. Like, for example, folks in Mexico who use castoff US equipment. Given our geek editor base, most of whom have reasonably good equipment, it is hard to put ourselves in the position of those who are are trying to access the internet under less than optimal conditions, but is is good if we could to the extent we are able and accomodate them to the extent we can. Fred

On Sun, 22 May 2005, Fred Bauder wrote: If anyone out there is interested in the issues around this problem, let me suggest checking the links in the RULE project. These people are working at the coal face of making ancient hardware work with current Linux distros, & last time I looked in on the list, they had a fair number of questions from folks working with old 486s & low-end Pentiums in third-world villages many miles from where the asphalt ends. Geoff

This has been a problem on Wikinfo. We have set a limit of 200kb for images (Wikipedia has a 2mb limit). Some images simply can't be used but reducing the size and generally using thumbs produces difficulties in formatting which have to be corrected by hand which is quite laborious. A Wikipedia solution would have to be expressed as policy and have general support among editors. Fred

This discussion is about how to improve the usability of the website. Looking forward to a print edition the 2mb limit makes sense, but these very large images ought not to make it difficult for the less advantaged to use the website. Some way needs to be found to not impose them on users whose equipment is unable to handle them. Fred

John R. Owens wrote: This is absolutely brilliant. I love and support this idea. Not because I have a slow connection (which I do, but I don't mind), but rather because I'm getting annoyed when people make images so huge because they have a 1280x1024 resolution and they think everyone else must have that too. (I even had one replying back to me saying "Not everyone has a resolution as low as yours, so please leave the image this big!") Yes, you do want it applied to Image:-namespace pages. The actual image above it is not part of the page. :) People should learn that formatting is more than just looking at what it looks like on *your* screen. Pages must be formatted in such a way that they are readable on any resolution (OK, I guess we can assume a minimum resolution of 800x600, but not more!). Resizing your window is all it takes to check. Once this is done properly, varying sizes of images shouldn't have any adverse effect on the formatting. Of course, if it was entirely up to me, all images and taxo-/infoboxes would be one big right-floating element and at the top of the article source text. They would form a neat column on the right, with the text entirely unaffected. This would solve pretty much all layout issues instantly, especially the one with the section edit links. There are a few special cases where this doesn't do, and in some circumstances you really do want left-floating images, but they can always be handled on a case-by-case basis. Timwi

Stephen Bain wrote: OK, so if I give you the $0 you need to download and install the newest Mozilla, Firefox, Konqueror, or Opera-with-Ads, whichever you prefer, then will you give me the money I need for a new computer? Please think about these things before you make insinuations like that. Of all the people I know I have the slowest connection and yet it doesn't take me more than half an hour to download and install the newest Firefox. I'm afraid a computer with a better resolution takes a bit more than just patience. Timwi

David Gerard wrote: I *am* talking about thumbnails. The person I was referring to made the thumbnail so big that it was more than 70% the width of the article text area on my screen.

John R. Owens wrote: Unfortunately I don't think this would be a workable solution, unless a thumbnail duplicate of every image was created at the time of uploading. That would be fairly straightforward to do, although it would be very resource intensive on the image server(s). (Is there more than one yet?) To shrink each image after every request before sending to the browser would literally kill the servers. A better way would be to allow for a user preference to have images either on or off by default, but have a link on the page to view a version with images. So if a user browsing with images off wanted to see an image, they could then re-load the page with images included. (If it's good enough for Outlook, then it's good enough for Wikipedia.) -- Stephen Bain stephen.bain(a)gmail.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Bain wrote: | John R. Owens wrote: | |>I don't know if this might have ever been suggested before already, but |>perhaps a change in software could allow us to set a maximum image size |>in our user preferences? Either in width/height, e.g. "always shrink |>images to less than 200 pixels wide or 150 pixels high, whichever is |>smaller", or in kB, e.g. "always shrink images to less than 10 kB". | | Unfortunately I don't think this would be a workable solution, unless | a thumbnail duplicate of every image was created at the time of | uploading. That would be fairly straightforward to do, although it | would be very resource intensive on the image server(s). (Is there | more than one yet?) To shrink each image after every request before | sending to the browser would literally kill the servers. | | A better way would be to allow for a user preference to have images | either on or off by default, but have a link on the page to view a | version with images. So if a user browsing with images off wanted to | see an image, they could then re-load the page with images included. | (If it's good enough for Outlook, then it's good enough for | Wikipedia.) That's why I was suggesting it would probably be desirable to have a limited number of options for maximum width/height/filesize. If that were the case, then a limited number of different sized copies could be cached, the same way, if I understand correctly, that the thumbnail images are cached after the first time they're viewd in the page. So, for instance, you might have four width/height category choices, e.g. 100x75, 200x150, 400x300, and 600x400, and then you "just" need disk space for four or less copies of each image (obviously, any images that are, say, 250x200 would only need two extra copies, and those rather small ones). I suppose that since this would be applied to pretty much all images, instead of only those formatted to use thumbnails. So what you might end up with, for the hypothetical picture and choices given above (call the picture example.jpg), would be something like creating files corresponding to the following URLs (I haven't figured just which name hash directory it should actually belong in, especially since I notice it does take the "XXXpx-" part into account): http://upload.wikimedia.org/wikipedia/en/thumb/a/ab/Example.jpg http://upload.wikimedia.org/wikipedia/en/thumb/c/cd/200px-Example.jpg http://upload.wikimedia.org/wikipedia/en/thumb/e/ef/100px-Example.jpg and perhaps something like http://upload.wikimedia.org/wikipedia/en/thumb/1/12/5kb-Example.jpg http://upload.wikimedia.org/wikipedia/en/thumb/3/34/10kb-Example.jpg And then, if you've set your preferences accordingly, you get the 200px or 100px version, and if not, you get Example.jpg itself in the viewed page (assuming it hasn't been thumbnailed, either). If this were to be done, I'd expect there should be a script to create these thumbnails, run at a low priority, before the option were enabled, so that the servers wouldn't bog down if many people using the option started browsing image-laden pages. But I'd definitely want to see what kind of demands it would make on disk space first. And mind me, I'm not really pushing for the idea myself, just trying to present an optimal solution to a problem that was brought up. I'm on broadband, so it doesn't affect me much personally. I just thought I'd throw the idea out there. - -- John R. Owens ProofReading Markup Language : http://prml.sourceforge.net/

On Mon, 23 May 2005, Timwi wrote: Did I say that *was* the grounds for my original complaint? You asked, I answered. [snip] For the record, I don't use the Monobook skin. Did I say you had? So how I am to selectively view images? Last time this question was raised (for reasons other than viewing convenience), the conclusion was that this was an all or nothing situation: either every image linked in a page gets downloaded -- or none do. Should I start removing images from pages where I feel there are too many? Or would this be an example of disrupting Wikipedia to prove a point? Timwi, I'm not clear where this exchange between us is going. My original complaint is with contributors who want to insert more images than I believe are necessary; at the moment I feel this is an issue best solved by education, rather than policy or programming. You seem to hear my generalized complaints about Web design philosophy as attacks on how Wikipedia is designed; if I had specific complaints about Wikipedia, I'd be filing detailed bug reports in the proper manner. If you think I'm picking a fight with you, I'm not; I'm just trying to express my belief that the average contributor to Wikipedia sometimes lacks a clear idea what constraints many end users endure when they view Wikipedia. And this erroneous impression is related to a number of other issues I have with Web design -- & with the assumptions software designers far too often make about their intended audience. I could expound a little about those, too, but it's probably better to concede the floor to someone else at this point. Geoff Geoff

On Mon, 23 May 2005, Timwi wrote: Which has never been my problem: I am not aware of any browser that requires all of the images to be downloaded before it shows the page. I have no idea how you concluded that was my point; I was talking about HOW MUCH TIME THE PAGE TOOK TO DOWNLOAD IN TOTAL. And because images sometimes do not download in a predictable order, a user must then DOWNLOAD ALL OF THEM to determine which ones are useful, & which ones are useless. Even the ones that a contributor insists ought to be displayed in Wikipedia at 1280x1024 -- I assume that is an example of the kind of image you have said you object to? Or would complaining about it be an attempt to "re-educate everyone in the Wikipedia community on what *you* think is ... right"? I'll make this easy on both of us: I'll stop reading or answering any more of your posts to this list. Obviously, that will make us both much happier. Geoff

That is kind of a Borg answer. It just doesn't comport with the reality on the receiving end. When I did use a modem and an older computer long articles were troublesome. It is difficult to tell now as almost everything loads. Fred