[logo]

Website Provider: Outflux.net
URL: http://jnocook.net/web/pages.htm

[logo]

[Tags overview] (Page design) [File organization] [Tools]

[logo]

Universal Web Page Design

(Up 14 Feb 97, last modified Feb 03, Jan 04) This page lists details about speed, downward compatibility, and writing web pages which will look good on any browser and any screen.

"We have no reason to be grateful to those who juggle the thresholds in the name of haphazardous innovation." -- McLuhan

Setting up webpages replete with nifty layout and cool graphics, which are presentable when viewed with Netscape or Explorer, and at the same time makes sense when seen with any other browser, especially a text browser, takes a little thought. The remainder of this page is divided into a few sections, as follows; you can jump to any of them.

Page Design Guidelines

The information below was compiled with three requirements in mind: (1) speed (2) readable page design (3) compatibility.

Use the defaults...

Use default colors for texts and backgrounds, default fonts (set by the user), default page width (set by the user), default link colors (set by the user), default type sizes (set by the user), default scroll bars. This generally means use of HTML-3.2 standard. (Which did not include frames!)

Use the most basic tags...

Not much else is required besides the H, P, and BR tags. Anything special which fancies up the text will increase the size of the files (slow things down), make the files more difficulty to edit (your problem), and is likely to be misrepresented by other browsers (which becomes the viewer's problem).

Let the viewer's browser do the work...

That was the idea behind web browsers, and still is: Don't specify widths, fonts, font sizes and colors, or any of the details of layout. Let the user pick a readable font, and then let the user's browser fit the page locally to a screen.

Find out how the page looks with different browsers and on different screens. Count on slow modems, dialup connections, 286's and even 088's, Hercules screens (or worse yet, MDA monitors).

There are advantages to typing all the tags by hand: knowing the basic tags, you can get a new webpage up in five minutes; you can find logical errors with ease; you can practice your typing. Knowing in addition the reductiveness of web page specifications since HTML 3.2, you will also realize that pages can be reduced to no tags at all.

Some strongly held opinions: CSS should never be used on public sites; JavaScript is more cute that effective; Java is still a genuine security risk; Frames are difficult; Image Maps are death to a text browser; and Flash sucks.

Test the Page

Get copies of Explorer, Netscape, Opera, Mozilla, and Lynx for Windows. Get copies of the KDE, Gnome, Mozilla, Lynx, and Netscape browsers for Linux. Get Arachna and Bobcat for DOS.

Use Opera to reduce screen size to exact dimensions and view pages in your preferences with a single click. Opera will also render separate page separately, will save a page with all the images, and allows switching to your own defaults with a single click. It will also save frame sources, something the other browsers neglect.

Use Explorer as the fastest (for graphics) and most reasonable (in terms of rendering) Windows browser. Use Netscape to check against Explorer. It will not render images in the same manner as Explorer.

Use Lynx (there is a Windows binary available) for absolutely lightning speed, for an instant flip-over to source, for reading http header information, for stopping at all refresh directives, and for getting and saving files without even placing them on screen. In fact, you can set it to robot accross a site (but there are Unix applications which are much better). Lynx probably has more built-in self correcting code for sloppy html pages than any of the others. Under Unix it is also a primo directory browser.

Netscape and Opera are also available for Unix. But they are nowhere near the same. And don't think you can somehow get people to "upgrade." Most people hate to change browsers. Once they have a version set up, most users will not upgrade unless they absolutely have to.

Be aware of some serious design flaws with the Explorer versions, which allow break-ins to your computer. In terms of adhering strictly to standards, as of 2004 Mozilla seems to be the most correct in rendering, followed by Opera.

Checking out the page locally

That is, in fact, what most web page writers do, and this is exactly what causes most design problems, for if everything looks great to you, all that can be said is that the page looks great on your screen, using your browser.

But few people seem to be aware of this. With over 200 web browsers available, and thousands of different ways of setting up the viewing screen, there ain't no telling what the end user is gonna see.

So get two or more browsers, like Netscape and Explorer. Both will run local files. For any of the browsers click on "open local file" and then select this file as the default start-up screen. See "setting up a browser", somewhere else in these files.

You will be surprised at how different things look; not only between a graphical and a text browser, but between graphical browsers, even though Netscape and Explorer are seriously trying to imitate each other. Then try changing the Windows default screen to 600x480 with 256 colors. Try setting it at 1280x1024 with millions of colors, which is what Mac users think the whole world uses -- or should use, just as the whole rest of the world should buy Toasters. Try also to set your browser to arbitrary sizes. Some TABLE constructions (and many FRAME sets) will suffer complete destruction under those conditions.

Additional specific guidlines

Here are a few additional ways to achieve speed and downward compatibility ..

Start each page with a large block of text.

This will in almost all cases (that is, with almost all browsers) make the viewer think things are moving with speed. Having to wait for a set of graphics to download can be aggravating, and impatient viewers are likely to disconnect after a few seconds. Avoid fancy titles, welcome mats, detailed anchor lists to everything else, ads for browsers, stats, etc. These should be at the bottom, not at the top, of your page.

Keep all the initial graphics small -- very small.

So small that they can be transmitted over the net in one piece, and will wink into existence on the page. By "small" I mean sizes like 100 to 800 bytes. That's right: under 1K! Details further below.

Reduce graphics sizes, resolution, and number of colors.

Anything which will speed things up marginally, or seems to, will reduce the overall delay time before the viewer can read or see information. All of the following will help incrementally...

  • Repeat the same icon type graphics from page to page, so that caching browsers will already have the graphics on hand for the additional pages.

  • DO NOT specify the dimensions of the graphics files, especially if they come early in the page and are small. If this seems like a contradiction to whatever else you have read, see the information further below under "Graphics at 400 MPH."

  • Reduce the colors of GIFs if you can get away with it. It will make them much smaller, even smaller than Jpegs. Jpeg files can be color reduced also, which frequently makes a 50 percent difference in the file size. But it may be best to limit the color depth resolution of Jpegs to 8 bits (256 colors).

  • Reduce Gif file resolution to screen resolution: 72, 96, 125 dpi. But don't do that for Jpegs -- these are almost immune to resolution changes, and you will need a higher resolution (like 300 dpi) in most cases to do justice to the details within the image.

Compose pages on a large screen, design for a small screen.

If you set your page to 1024x768 (for example), you can figure images will be readable for smaller screens (in terms of detail, not, of course, in terms of size). But design for a 640x480 screen. That is what most people will either have, or will put up -- even if they have a larger screen. That means, after accounting for borders and scroll bars, that you have about 600 pixels left to place images.

The oddball screen and browser size used by Macs is only used by about 4 percent of the computers in the world; don't worry about them.

Avoid moving GIFS

Moving gifs will rob the viewer's browser of the time to do other things (like getting the rest of your page), and can screw up printing and following links. Explorer now allows the viewer to disable moving gifs -- what a relief.

Avoid server cgi scripts, server side image maps.

All of these will tie up the server, slowing down other requests for pages.

We are not alone.

There are people all over Europe, Asia, and Africa who wait minutes for a web page to be received. They are very likely to set their browsers up to neglect images.

General Gripes and comments

If you browse around, you will find lots of stuff on Web Page design, half of which I disagree with. Let me start with one of these, as follows..

Click Here

I think those various directions on "good style" are all cribbed from each other, sort of how history text-books are written. You will repeatedly find comments to the effect that the phrase "click here" should not be used on a web page.

This is idiotic. If there is any one clear method of indicating a link and guiding your readers in the navigation of a web site, this is certainly one of them. So, do use "click here," whenever it isn't otherwise obvious. Text browser users know they don't have a mouse, and will click with an Enter or Arrow key.

Indicate the Links

Note that the underlining of links can be turned off with most browsers, at which point only the color of the text will indicate a link. And of late browsers have muted the default link colors. Set the link colors as attributes of the BODY tag.

Take a look at some [Yahoo] pages as a model - they are constructed for clarity and speedy loading: a white background color, default link and visit colors, and no clickable images -- until recently. Or check out [www.w3.org] instead. This is the consortium who writes the HTML standards.

I think you can do better than default link colors and indicate the links in the text by setting the anchored words off with square brackets, like in the following, where the word "me" represents a link.

Be sure to contact [me]

This would derive from tags as,

Be sure to contact <a href="mailto:me at foo.bar">[me]</a>

Without the square brackets, when a viewer prints out the document, the "me" will disappear (that is, may not be highlighted) in the printed document. In fact, you may want to indicate links by repeating the URL information within the anchor, so that a printed or mailed document will retain the information. Something to the effect of..

Find other information at <A href="URL">[URL]</a>

And lastly, give some indication of internal links (hash links), like using the word "below" or "jump" in conjunction with the links.

Expand the URLs, or don't

General recommendations are to give the complete paths for the URLs, meaning, as an example, to use ...
<A Href="http://www.somewhere/directory/something.html">
Rather than ...
<A Href="something.html">

It is true that different browsers and servers will do different things to a request for a file. Some will actually append your abbreviated URL to a base address listed in the HEAD section, or guess at what should be appended to what. Some will correct errors like double forward slashes which result when you screw up, or insert them where they are left out, but some will not. Some Netscape versions screw up on this if your entry onto a web site is from a referred file. Explorer versions used to render a recieved "html" file extension of a URL as "htm" on screen. What a mess that caused with Unix servers.

The most cogent argument for not using fully qualified URLs is that it is easier to move a set of files from one domain to another without having to rewrite the links of all the files. This is true also if you move whole directories around on a file tree. And it simplifies the local testing of files (viewing them at home), and will simplify uploads.

I have stopped using fully qualified URLs except in refreshing html files. In this last instance the URL is like a forwarding address.

Let Them Have Text

Open every page with a paragraph of text, maybe directly after the opening H1 tags.

This allows the reader to do something while the graphical browser downloads images. Think of it as an abstract for the webpage which follows. Even being a visual artist is no excuse for opening up a web page with some (yawn) gigantic image. This opening paragraph (100 to 200 words will do) also provides the capsule description which will be used by some of the web search engines to index your web page.

But most importantly, it will look to the reader as if something is actually happening. The index file at Spaces.org uses some 50 image files, but since the index file starts with two paragraphs of text, the page is up in under a second, and the download of image files will usually stay ahead of mousing down the page.

Local Links, Banners, and TOC

It used to be the common habit in web pages to have local links and indications everywhere of how to get back to the top of a document, or jump ahead.

It is hardly needed when most of web access is made with graphical browsers, and a right mouse button click, or a few pg-ups or pg-dns, will do the job. The same is true of Lynx also. I have moved through 60 page documents in under two seconds. So why clutter pages with intermediate sign posts?

Finally, I really hate those "always at the top" banners: you never know if you have really gotten away from the first page. And they waste screen space. Web browser people are even more impatient than book readers, and a repeating page header will drive them nuts.

There is, additionally, nothing as confusing as making every page look like every other page. The reader (who hasn't turned any sheets of paper to know otherwise) generally won't have a clue as to where she is.

Present a Table Of Contents once at the top or as the opening paragraph. Don't repeat it at the bottom of the page, and certainly not on every page.

If you must use repeated sets of links to everywhere else on your web site, then at least void the anchors which points back to the same page they are placed on. I know - you ask, How stupid can a viewer be to link back to the same page? Well, expect the worst: How stupid can a web page designer be to leave active links back to the same page?

For a series of consecutive pages a good plan involves using two links centered at the top and bottom of every page, which -- for a linear text -- simply point one page back and one page forward. This allows the page (if the links are at the top) to be printed without having to run through every page from top to bottom.

Your best design is to provide as few links to other pages as possible, but to always allow getting back to the index page.

List the URL of the Page

List the URL for any page at the bottom or top of each webpage. This could just indicate the Domain or the Index file, or you could use the fully qualified URL for the actual page. All except complete idiots will then be able to find their way back to a particular web page from a hard copy.

You may also want to add a note on the revision date of the document.

Bookmarks

You think people bookmark? Yes, for a few days, and then the bookmarks file gets unmanageable and unintelligible, and they clear out the bookmarks of all those items which read "Welcome to my page" or "Untitled Document."

Bookmarks get saved under the text included between the TITLE tags of the HEAD section. The problem most often is that all the pages on a web site have the same stupid title, "The Widget Company" which doesn't make things very clear.

It is unfortunate that "TITLE" is used for this tag, since it seldom is a title, the "title" doesn't show up as part of the regular text, and the information is generally only used to bookmark a file. What you really need to do for the TITLE tags is clearly indicate both the website and the particular page.

Empty Space Sucks

Empty Space sucks on a computer screen. Avoid the use of BR and P as space fillers just to have some paragraph start in the right place on your screen and with your browser. For one thing, some browsers ignore repeated BR codes, some browsers ignore P tags after Headers, etc. Same goes for all those empty spaces created at the left of every document by Netscape's Kompzer -- as if you are going to punch the page and save it in a 3-ring binder.

This media is not a printed page which can be taken in at a single glance. This is mostly half page collections of ugly and unpredictable typefaces scrolling up a CRT screen, difficult to read at best, and straining on the eye. Allow your viewers the luxury of compactness, at least.

It is especially of little use to insert P code after a HR (horizontal rule), before or after a H (header) block, or any LI, DT, and DD list tag. These will make their own space with most browsers. Some browser honor some of the P tags when placed between list elements, some do not. With Netscape it seems to depend on where they are placed in relationship to the LI, DD, DT tags. And get in a habit of starting paragraphs with a P code, rather than ending with them.

I must admit, however, that I often add an unneeded P tags here and there anyway, mostly to equal things up between MS Explorer and Netscape.

Header Text

Some browsers will turn H1 headers into ALL CAPITALS, wether you like it or not. Set them up with Initial Capitals, and hope for the best. Additionally, if you want a consistent look to sub-headers, use Initial Caps for any header tags.

Text browsers give very little distinction to lower level Headers. And how far do you carry H tags? The H4 through H6 headers are about as noxious as flying cockroaches would be in your house. And confusing, especially to speed readers. Netscape used to render the higher numbered H tags smaller than the body text.

Emphasis or Not

The EM (Emphasis) code doesn't work well in Netscape, so avoid it. On a 800x600 screen it disappears entirely (unless the user has set the video driver up with Big Ugly Windows Arial). Try B (Bold) instead, it stands out much better. Text browser have no problem with bolded text.

Missing Fonts

Specification of font sizes has no effect in Lynx, and often looks like crap in Netscape and Explorer. If you are not someone who designs advertising copy don't even try it. The need for specific sizes and fonts has a place within a corporate network -- where every machine has the same font set and the same preconfigured browser.

Netscape and Explorer now allow setting the name of the font too, but if the font doesn't exist on the computer that's looking at your webpage, you're out of luck with your carefully designed page. Calling for a never heard of before font ("Chicago") is a frequent MAC user misguess. And who knows what the default will turn out to be. Browsers will attempt substitution, but it is guesswork, and might turn into some available "Rounded Modern" or "Something Cyrillic."

The latest versions of Netscape and Explorer also allow viewers to disable all the font, font size, font color, and page background colors. Cheers! This allows sight impaired viewers access to web pages which would otherwise be incomprehensible. And (whoo!) Explorer allows turning off moving Gifs. Find my only moving gif somewhere below.

Table Constructions

Tables can be capable of very elegant presentations, but can also reduce tabular data to pure garbage. Often tables get in the way of efficient page space, especially on commercial sites. Tables were meant for data, but they serve mostly to present texts column-wise as in newspapers.

There is a problem with the Lynx browser in presentation. Lynx will show all of a first column (actually all of the first TD entry) before displaying the content of the second TD cell. What happens in these cases is that Lynx honors all the imbedded BR, H, and P tags in total disregard of the structure of the table. It does not do what graphical browsers do, which is to wait till all of a Table has been received before attempting to fit the information to a screen.

The advantage is that Lynx renders at a much higher speed than any graphical browser, all of which wait for the complete Table to be received before rendering to the screen. And if the table layout encompasses the complete page or images, this might take a while.

Let me recommend to use only small tables, and repeat them as needed. If you have a series of images with adjacent text, set each image and corresponding text into a separate table. It will be rendered quicker than the reader can scroll down a screen.

Considerations for Access

The following is partially copied from the Spaces.org website [design] page. The aim at Spaces.org was to provide model web pages: fast, browser independent, and accessable.

The concern here is navigational access for visually impaired viewers. Navigational access is related to downward compatibility. This section deals with both of these. This section does not offer definitive solutions, but only suggests common sense.

"Common sense" is entirely contary to what the giants of the browser industry are attempting to accomplish for impaired viewers. Their thinking is that whatever is needed should under no circumstances impede the progress the companies have made in increasing their control over the presentation the viewer experiences.

Thus whatever has to be done about accomodating blind and near blind viewers is expected to be accomplished by piling up more specifications, code, and browser version numbers. And these same industry folks might then write and sell the programs which will accomplish the translation of web pages through the use of CSS (Cascading Style Sheets).

But the "programs" have been around since the 70's. We dont need anything more complicated, we need things less complicated. It is easy to do if web designers would let go of their Kompozers.

So what we offer here is a minimal but workable immediate implimentation of direct methods of access. The viewer (any viewer) is in complete control over font sizes, link colors, and the display format of the pages. No text is dropped into unreadable gif files. The foreground and background colors are selected for contrast. Etc.

Keep Text Browsers in mind

Why would anyone use a text-only browser? Actually, when I need information I want to be able to connect with speed and get what I want in a hurry. There is nothing like a text browser, such as Lynx or Bobcat, because it skips all the graphics, and with very few exceptions, information is text, not graphics.

A Lynx connection is also an order of magnitude faster than a graphical browser like Netscape. That's right, 10 to 100 times faster. And Lynx is still the 2nd or 3rd most used browser in the world.

Conservative Design

A reasonable course for page design for access -- access by people who are visually impaired, who will set up bigger font sizes to read the text, who will disable background colors, who are color blind, and even completely blind and will be using a Braille screen or a sound-out reader -- is to remain conservative, that is, to use tags which will be understood by as many browsers as possible.

Forcing web pages to be easily readable by a text browser represents the dead level of downward compatibility. Blind readers have no problem with plain text, but find it nearly impossible to use text which shows as images. Visually impaired viewers have immense problems with texts controlled through external CSS, Image Maps, and headings spun into gif files.

Three Design Elements

This is a media where you try to reach out to many people, all using different equiment, operating systems, and web browsers. At the present there are some 200 versions of the two popular browsers in active use - and they all act different. Worldwide there are in all probably 50 popular browsers all with their own various versions. And people do not upgrade. So the question will be, how do you allow as many of these variables to play out successfully?

The answer is, by implementing the following three design tenets, which all point in the same direction: letting the viewer fit your page to their screen. To wit, and to repeat the three items from the top of this page:

[moving horse gif]
Web pages at 400 MPH

Let this serve as an introduction. Most of this text is about images. Images are the bane of web pages, they can delay them endlessly -- where endless is anything over two seconds -- and drive readers away. If you pay some attention to images, you will be able to speed up your page display immensely. This will involve a strategy for placement of images, and their sizes.

Images Strategies

The usual directives for images (which you will read about in all the other handy-dandy HowTo's) is to supply the dimensions for each IMG tag with the attributes Height and Width. This recommendation is based on the fact that a browser cannot place text on the screen until it knows the placement of the images.

Thus (supposedly) the text scrolling onto a screen is delayed at each location of an images until the image is fetched and inspected for size. Explorer fills the page with text and reorganizes everything as each image is received. Mosaic delays everything until all the images are received. Netscape 2 will interrupt placing text to the screen until at least the dimensions of image files are read from the incoming files. Netscape 3 does not. Some later Netscape 3 and 4 versions wait also.

The peculiar behavior of individual versions of Browsers varies immensly. Do not expect Netscape 3 for the Mac to be equivalent to Netscape 3 for Windows. It is not. Netscape 4 for Unix behaves like Mosaic 1 for Windows. And on and on. And remember that people generally will not upgrade a browser if they are even mildly satisfied with the one they have.

The strategy below is mostly based on Netscape Windows version 3.04 and 4.72 and Unix version 4.61, MS Internet Explorer 4.72, Opera Windows version 3.67 and 6.0, and Lynx Windows and Unix versions 2.8.2, and might have to be adjusted with other versions. I suggest you play around (read "test") with some browsers (of the kind and flavor which you expect your readers to use). Let the notes below be a guide on how to approach your test design.

Delays in getting a web page

So here is what happens when you attempt to get a webpage (I should note that images included in TABLE constructions get delayed even further for internal reasons):

When a browser gets the image file dimensions as part of a html file, it will get all the rest of the html (text) file before getting any of the images, but makes room for the images in the formatted page. This might leave the viewer stranded at the first screen of a large html file, with the boxes neatly marked off where the images will go, but no images.

The delays are more likely to happen if your files are anywhere over 5K. That is, they are likely to be interrupted in transfer, and there will be apparent delays - less for those of you with a T1 line, but certainly with most people's PPP connections.

Delays in receiving all the data of a file or an images is almost always the diversion of network resources to other traffic. It is not the amount of memory your machine has, not the processor or modem speed -- although better or more for any of these help things along. It is simple network traffic, along with poor page layout, and hopelessly inept page designers.

First, get this straight:

The delays are due to the reshufling of traffic at the connections you have made to a web site. Connecting to a site usually involves a half dozen machines: yours -- which might be trying to handle incoming and outgoing mail while you are connected, the box in the machine room of your ISP where the telephone PPP connection has been made -- which will be trying to satisfy other simultaneous demands for moving the data of other customers, your ISP's central headquarters boxes, which are negotiating connections with hundreds of customers, the gateway machine at the domain where the web site is located, which is under the same pressure to satisfy hundreds or perhaps thousands of customer demands, and the actual box which can access the web files you are looking for -- and which in turn might fetch the files from some other box locally. That describes a typical local connection.

Oh, I forgot to mention the DNS machines. The first thing your browser does when you type in a name, or click on some link, is to ask your ISP's DNS machine what the "ip address" of a human-readable website name is.

If the ISP's DNS machine doesn't know (it only stashes data like that for about 20 minutes), the ISP has to ask a root server DNS machine, which will supply the ip address of another DNS machine on the web which might know -- or further redirect the request. This could go to a half dozen levels.

A very few years ago, if you made a connection from Chicago to the West Coast, it would go via a half dozen hops to the East Coast, where you got connected to the main trunk connecting to California, and from there through a half dozen locations to reach, for example, San Fransisco.

As an other example, some of my packets (ping, bind, etc) go out with the built-in proviso that they will not cross more than 17 machines. That is a stretch, but it can happen.

And none of these machines handle requests simultaneously. What they do is to switch over to something else to do -- another request or another interruption -- as soon as a microsecond of free time becomes available to the CPU. This, in fact, is the whole basis of the modern computer. In between your keystrokes your computer interrupts what it is doing to do thousands of other things, including updating the "time" 17 times per second.

Reading web pages is not a matter of a singular connection, where everything your browser requests get sent to you in one piece. Instead, files are broken up and sent in chunks -- called packets. If your browser requests some large image files, chances are good that there will be delays between the packets. After all, you are not the only person on the internet. Small files have a much better chance of arriving quickly if they are less than the internet "chunk" size -- which might be 1K to 5K (and might be reset by any of the intermediate machines).

Any file which can be delivered as a single packet is "done" once it is received, whereas large files and large images are going to be delayed because they are being delivered in chunks (as packets), and at any time between chucks any of the many machines involved in the routing might decide to handle someone else's requests for routing.

Only when the file arrives at your machine can your browser show you anything. What you are then looking at are copies of the files which exist at the remote web site. The files are stored on your machine, in memory and on the hard drive, and are being formatted to your screen by your browser. It looks like you are somewhere else, but actually you never left home.

Back to the browser

Now, if the browser does not get the image dimensions from the html text file, it will send a request for the image files -- while it is still receiving chunks of the text file -- so that the headers of the image files can be inspected to determine the sizes. Different browsers version, even of the same browser, operate somewhat differently. Some will suspend scrolling of text to the screen while the image files are being fetched, some will place psuedo icons, and reformat the page as soon as the image size becomes available (the image size can be, and is, read from the first few lines of an image file).

So an opening screen which uses text and only small images is likely to display quickly to the screen. Design the opening sections of web pages with this in mind.

What happens with the following screenloads doesn't matter as much.. And in fact, you could even set the dimensions of any image file which is located a screen or two down from the top of the html file. It generally doesn't matter at this point, for by the time the viewer scrolled down a few screens, all the other files will have been received.

Speed Strategies Restated

To restate the above in capsule format:

Once past the first few screens (assuming that the reader actually has something to read) it mostly doesn't matter if you supply the dimensions or not. My practice is to never supply them. This seems to have become commercial practice too.

I should point out that some browsers (at least, Netscape) are content with a single dimension, and will calculate and adjust the other dimension properly. This is of great use where you want a series of images all of the same height or width. But better check it against Explorer.

Image Dimensions

Probably more than half the viewers of your web page will be using a screen size of 640 by 480 pixels, not because all these people are locked into old 14 inch monitors, but because even Windows users will start up Netscape or Explorer in a box smaller than the full screen, in order to stay in touch with the "desktop" and because a wide page is often difficult to scan -- that is, difficult to read quickly. And some Mac boxes will not allow use of the full screen, it seems.

A webpage presented at full screen size on a 1024x768 monitor looks weird -- doesn't have that "magazine page" look to it. Text is harder to scan as it expand beyond 60 letter spaces, and a 1024 screen may easily hold 90 to 120 letter spaces or more.

Thus presenting images wider than 640 pixels is a waste of time. If it is all a matter of looks to you, present your (smaller) images as centered. In fact, limit your images to about 600 pixels, to allow for browser borders and scroll bars.

When is an image file too big? There are problems in processsing large files (fitting them to the viewer's screen) in addition to the transportation time. With 486 equipment, a 10K file might be considered as large, and although it will likely be delivered in only a few packets, it may take some time to display to the screen. With 586 equipment, even image files over 30K display quickly, once they have been received. I usually draw the limit at 30K to 40K. Files larger than that are just too big.

There are four factors involved in file size: (a) the dimensions, (b) the file type, (c) the resolution, and (d) the number of colors used.

You will have some idea of the size of an image from the dimension you use. But the height and width dimensions don't add up, they multiply. An image which has twice the dimensions of another, is four times the size; that means it takes four times as long to get from the remote site, and takes four times as long to scroll to the user's screen, and is probably four times as likely to be interrupted during fetching.

At busy times on the internet it is the first of these -- the time to fetch the file -- which will cause the greatest delays, not in terms of the actual time spent in transport (which remains very small for anything except very large files) but because interruptions during large file fetches will last longer. Don't ask me why you don't get preferential treatment.

I suggest you make most images something like 350 x 300 pixels, which will fit comfortable on any likely screen without being broken by a monitor boundary, and can be used left or right aligned with text flowing past the images. For large images try widths to 600 pixels, and center them.

For icons of high acutance (such as line drawings) you can easily reduce sizes to 30x30 pixels. These will be a hell of a lot smaller than big images, and easy to read if you use the GIF file format.

Image File types

Most browsers will read GIF and JPG file formats. Both of these are compressed formats, but vary considerably in quality and in compressibility. Gif files are generally rendered quicker to a screen than are Jpegs, but are also generally larger than Jpegs.

There is a push on to replace GIFs with PNG files (which are not covered by copyrights, and are in fact smaller than GIFs). But even some of the latest browsers do not read PNG file format as yet. At this time (early 2003) I would still avoid using them.

The general rule which will determine which file type to use is to use GIF files for images with graphic detail such as drawings, and reserve the use of JPG files for images of photographic quality.

Note that JPG can be compressed (at a resultant "loss" of quality) to different degrees. And the quality at the other end will suffer if you compress too much. If you put image files through a program like Paint Shop Pro, you can select the percent reduction. The following are file sizes for three 300x200 identical images set to three different levels of compression.

Filename DIMS Colors Filesize -- compression
sample.jpg 300x200 24bit 9488 -- compressed 80 percent
sample.jpg 300x200 24bit 17099 -- compressed 40 percent
sample.jpg 300x200 24bit 30650 -- compressed 10 percent

Most people select 40 to 60 percent compression. This actually makes the JPG file format about the same size as an interlaced GIF file.

But Interlaced GIF files are ugly when they scroll onto the screen, and at times make unexpected images (as do LJpegs). Non-interlaced GIF files, on the other hand, are smaller, and if reduced in color might be smaller than the corresponding JPG files.

Below is a comparison of a 300x200 file, saved as interlaced and as non-interlaced (for type 87a, type 89a is similar).

Filename Format DIMS Colors Filesize -- compression
87I256.gif GIF87aI 300x200 256 18249 -- interlaced
87-256.gif GIF87a 300x200 256 14848 -- not interlaced

Interlaced files are larger than non-interlaced.

A 300x200 pixel image cannot be stolen and used if you also keep the density down to 72 or 96 dpi (which are the screen resolution at 640x480 and 800x600). And it sure keeps GIf file size down. You can set the dpi in Photoshop, or in the Paint Shop Pro's preferences. If you are stuck with a program where this cannot be done, then use screen captures to create the files. To accommodate users with fancy giant monitors, who will open up the browser at 1240x1024, you may elect to use 125 or 150 dpi.

If the files are scanned from slides, set the initial DPI at 250. That will reduce to about 125 dpi if the file is resized to 300x200 pixels.

Jpegs size is not effected by the dpi, although you still may want to use a screen-value dpi to keep the files from being of some use to a graphic designer who is stealing images off the web for his own use.

If you need to manipulate files for contrast or sizing, start with the highest quality images, like 300 dpi or better, and with larger dimensions, and as Tiff (which are easily transportable between Mac and Win boxes) or Window's native BMP, or you will be stuck not being able to make any changes. This is especially true of Jpegs, since every compression (and every re-saving) looses information which cannot be restored. When you manipulate Jpegs, you only loose.

Number of colors

Color reduced GIFs of files which originate as large JPEGs can be half to 1/10th the size of the original JPEG. GIFs will also look crisper than JPEGs, but don't bother using them for what is supposed to be a photographic image. Use Paint Shop Pro for color reduction.

Filename Format DIMS Colors --Filesize
87-256.gif GIF87a 300x200 256 --14848
87-16.gif GIF87a 300x200 16 --13306
87-2.gif GIF87a 300x200 2 --3351

Reducing the number of colors will reduce the size of the file - and thus load faster. Although the above example does not demonstrate a great reduction in file size, I have often seen very large reductions, and also at times noted no further difference between 16 color and 2 color. It depends on the number of colors initially used.

Paint Shop Pro allows you to remove colors which occur only infrequently in an image. If the file is already reduced to 16 colors, this is a rather straight forward process.

Even for icons derived from photographic image sources there is no reason not to also attempt to reduce them to 4-bit sizes.

Jpegs can be color reduced also. In Paint Shop Pro that manipulation happens while it is rendered on screen as a native BMP file. When subsequently saved as a Jpeg, the program will demand that the color depth be increased - as it has to do to be a Jpeg, but the new size will generally be much smaller than the original file. What has been lost are the infrequent colors. Test the file on-screen at a few different levels and make a compromise between what looks good still and the file size you desire. I generally settle for 256 colors (8 bit).

Other Considerations

Disappearing Images:

It is possible that a GIF will disappear from view entirely, that is, it will be a blank screen area when the browser displays it. Or perhaps parts will disappear. This has happened to me a number of times using Netscape -- mainly due to the fact that Netscape automatically makes the first color of the palette transparent. Open up the palette for a disappearing or damaged gif and check what the first color is and change it if you can.

My disappearing gif images would show with a viewer or paint program, would at times even show on local viewing with Netscape, but not when downloaded off the web. The solution, at any rate, was to either change the first color, or add one pixel somewhere in the image, and then replace it at the website. Or follow the more foolproof directions below.

Later versions of PSP (version 6) will do this for you. Otherwise look for a shareware version of Gif Construction Set, and remove the Control Block (See below).

Missing Colors:

Another problem is that Netscape swallows quite a few colors values. Of the set of 256 values (shades) of the three primaries, you get to safely use only every third value (see further below). The rest are remapped to higher or lower values by the browser. This applies to font colors and background colors also.

There is a source which has taken the trouble to figure out what colors you can use or not -- for which see [http://www.lynda.com/]. There is a better site in Brazil (the URL escapes me), which simply states that any hex color value in hexadecimal doublets composed of 0, 3, 6, 9, C, and F should work, Where FF is 256. I saved their image file, here it is..

[Netscape color cube]

Of course this only show the doubled values (00, 33, 66, etc) for brevity. But you can also use values like 03, 06, 09 0C, 0F, and then 30, 33, 36.. etc.

Transparent Colors:

Most of my 1-bit (black and white) images disappear when constructed in Paint Shop Pro, because the first color is, of course, black. I use Alchemy's "Gif Construction Set" to make corrections. Open the file, and remove the "image block." "Gif Construction Set" is still available as shareware in 16 bit mildly crippled form at UIArchive or Garbo. The shareware version will add an nasty note to the file about what a bad person you are (which make the file larger), but no-one reads the innards of Gif files except me.

Icons

Make icons from screen captures of anything interesting, especially line graphics, and save them as type 87a GIF files -- the "not interlaced" specification, or 98a which is a little larger.

I use 34x34 and 54x54 sizes exclusively as visual pointers and markers. These are on the order of 200 to 300 bytes for 34x34, and 1500 to 3000 bytes for the 54x54 icons. Size depends a lot on the number of colors and the detail of the image.

The 34x34 size was picked to match Windows icon sizes (a good source of small images, although many are just stupid). Somewhere out there on the web you will find Moe and Curly, and just about anything else, as small Windows icons. Find a utility which converts icons (*.ico) to gif (*.gif). Screen captures with PSP will do the job also.

Give any systemically used icons coded names so you will know what size they are in your collection of files. These can then be used to start blocks of text as if it were initial letters of an illuminated medieval text.

Icons used repeatedly with a set of files are only downloaded once by most browsers, so using them over and over does not slow down the browser with connection time on subsequent files.

Clickable Icons: Yuk

Don't use clickable icons; they are really lame, and difficult to use by impaired viewers. They can be confusing, and if you also have clickable text, doubly confusing, and some browsers just ends up drawing blue lines around the icons (void that with the attribute border="0" within the IMG tag).

ALT attributes

If you use the ALT tags for images to list what the real content is, then be aware that some browsers will overwrite plain text with the content of the tags, often making both unreadable.

To keep unimportant icons from showing up, set the ALT parameter as "" or (better) use "[]" or "*". This goes against what most web editors recommend, but I strongly recommend that you not clutter text browsers with the Netscape window dressings. The use of ALT tags has become especially noxious since the introduction of "mouse-over" events. As if I care that some icon is known as a "click here icon."

Note that the use of ALT="" will cause some text browsers to insert an indication that an image lurks in the background by supplying [IMAGE] or [IN-LINE] to the screen (including some versions of Lynx and Bobcat). This is fine for images which are actually images -- rather than icons. You could as well leave the ALT tag off altogether.

For icons with denoted meanings (take a look at "chicago.htm" page at spaces.org) include the full meaning in the ALT tags. The "Chicago page" uses ALT tags like [WOW], [FAST], [YUK], [SLOW], [BARF], etc, to indicate the responses. Here you would want to make sure that the image information shows up on a text browser.

[Tags overview] (Page design) [File organization] [Tools]