Last modified: 2011-03-13 18:05:59 UTC
The above link in the URL field on this form refers to the article on my blog where I mention my thoughts regarding this proposal; you don't need to read it, it simply gives more background on why I am proposing this. I would like to recommend the following change to allow a page during a macro call or on the page to be advised the user is on a low-bandwidth connection. I recommend a checkbox be added either to 'files' or to 'misc' of the form 'Allow pages to be aware I am on a slow connection' and when checking this box it turns on a value that can be read as one of the parameters which can be read by {{#if}} or is a variable that is non-blank if the checkbox is set, and thus can be tested for blank/nonblank. An alternative would be a checkbox with an option 'don't show many images or maps' and returning a similar variable but this sort of question may be unclear as to why it is necessary. Another alternative would be to have a selector with multiple values, e.g. "1 to 10" or "1 to 4" (neither of which might be clear) or "Dialup under 56K / 56K dialup / ISDN / DSL or Cable Modem " or something, that tells level of bandwidth they normally have available, and the page could check for that, however, again, that may not be completely clear, and if it isn't easy to parse for someone writing markup might not use the feature. The reason for this is with reference to pages such as http://en.wikipedia.org/wiki/List_of_counties_in_Virginia the page contains a series of macro calls, one for each county in the commonwealth, in which it refers to a map showing that county's location in the state. This is also being done for several other states, and is also done in other areas where there are several detail pictures or maps being shown that, if the person can warn the page that their connection really isn't that fast, the page could, if it detects the slow connection flag, skip rendering the images and thus reduce the amount of time needed to render the page. (I shudder to think what would happen if someone loads the page for Texas and it has to make 250 database dips because that page has been rendered with a map for every county in the state! The user may still be waiting 1/2 an hour later for the page to finish rendering!) This is why I am recommending creation of a checkbox option on the user's preferences page and a conversion of that checkbox into something that can be tested by wiki markup to allow it to render a still functional but less bandwidth-intensive page.
Another example is on the page for the African country of http://en.wikipedia.org/wiki/Kenya in which it uses an SVG image to draw where the country is on the continent. I decided to borrow that image for use on my blog (which is permissible under the license) for an article referencing that country and looked it up. Now, since I'm on a DSL connection, I didn't notice it until I uploaded the image and discovered the SVG the image is based upon is over 2 megabytes in size! Now, considering this article is about a part of Africa, it is conceivable someone from there might decide to look it up. Well, when images are shown, if I'm not mistaken it's the browser that renders the image after it has been sent, which means the whole image has to be sent for it to be drawn, it can't simply be sent as just the part the user sees. A 2 meg image is a big download on a slow connection. When I did a screen capture of the image and cropped it, the image as a PNG is only 15K. This is a clear example where offering the page designer the option to use something of lower resolution might not be a bad idea. Now, I know there is an option to tell the system to reduce the size of images being sent, but that doesn't help if there is a possibility of having a reduced size image is there if those who are designing pages have the capacity to trigger a less-capable but still satisfactory image based on the person's available bandwidth.
Not easy to do. It would mean changing the image contents for each user. Difficult for caching. Plus, if you are a low-bandwidth guy, which images wikipedia decides you don't need? -The users viewing the article are not sent the full image, but a thumb done at the Wikimedia servers, at the requested size. Thus, on Kenya article, instead of sending 2Mb LocationKenya.svg, you get a 18.43 KB png. You need to explicetly download the full size. -If you're on a slow connection, you already have a button to "disable images". It's on your browser. -Big SVGs usually mean they have an embedded bitmap file. (Doesn't seem the case here). -Content can be compressed. The server doesn't seem to be doing it, but if the SVG were gzipped, its size would drop from 2,75MB to 807 KB. Your concern about too many images on a page is right, but there's little more to do from server side. It's more an editorial point. When does an article have too many images?
Long pages should be broken down in general for bandwidth-friendliness and reader-friendliness and edit-friendliness. Large source images are not sent to clients; smaller thumbnails are. Large SVG images are not sent to clients at all; rendered raster thumbnails are. Text content is gzipped. Generally recommendations apply everywhere; a separate "low-bandwidth" mode is unnecessary and would not be sufficiently reported (eg having to opt in makes it nearly useless as few people would find a hidden option).
