![[Support DNS LOC - add your site!]](http://www.ckdhr.com/dns-loc/dns-loc.gif)
The first principle, of course, is to have content in mind for the page. The most wonderfully executed page will be meaningless without something for it to communicate; the worst possible page may still be worth fighting through the design if the content is sufficiently interesting.
The following principles are given as ways to make the content available more widely, more efficiently, more quickly, and more usefully.
Many people say things like "well, Netscape and Internet Explorer have some arbitrarily high percentage of the market between them, so why not design for them?" This doesn't wash, for several reasons.
First, why are you so quick to write off 10% (or more) of your potential audience? The more tightly bound to one browser configuration your pages are, the more fragile they become. Eventually you wind up with a page that only works on Netscape 4.03 on Windows 95, with a maximized browser window on an 800x600x16 bit screen, with the default font settings, with Java and JavaScript enabled--and all portability is gone.
It may help to think of it as "browser environment independence". Users can turn off image-loading (I do, for example), or change their font size, or shrink their window; they may have a laptop with a 640x480 screen, or only a grayscale display, or even a one-bit display; they may have Netscape 2.02 or 3.01 or 4.04, or MSIE 2.0 or 3.1 or 4.01; they may use a PC, or a Mac, or a Unix workstation. That "high percentage of Netscape/MSIE users" is a fragmented agglomeration of situations, not an army marching in lockstep. MSIE for the Mac lets me turn off not only image loading, but also GIF animation, background music, and frames. (So "get a frames-capable browser, loser" is not going to get me to "upgrade"; it's going to get me to go elsewhere. I hope you're not trying to sell me something...)
There are also other browsers. If people can't read your page at all because all they see is "[IMAGE][IMAGE][IMAGE]" or a notice saying "your browser sucks, get Netscape", you're losing your chance to reach those people. Yes, sometimes you can't avoid making the page less useful for Lynx users (for example, if you've got a photo gallery that uses small thumbnails) but it should still be as usable as possible (use ALT attributes on the thumbnails to say things like "[24K JPEG]"). Pretty "front page" imagemaps should also include a textual list of options at the bottom, a client-side imagemap (which will help newer versions of Lynx, but won't help Netscape with images off), or at the very least a link to a text-only home page.
Pocket-size systems like the Nokia 9000 Communicator incorporate Internet access, including a Web browser, in a portable phone; if your business might want to attract people with lots of money, "on-the-go" executives and the like, locking out people with Nokia 9000s is probably not your first choice.
Possibly the most important other browser is the search engine robot. With people asking for tips on how to move up in search engines, here's a tip on how not to move down: write for text browsers, because that's what search engines most resemble. Don't believe me? Ask your favorite search engine about "frames-capable browser" and watch the hit count climb.
Second, most pages don't need Netscape's, or Microsoft's, proprietary extensions. The most useful of them have made it into HTML 4.0 Transitional, and when used judiciously won't harm the page's usability with older browsers. (For example, using <body bgcolor> to set the background color of a page won't make the page unreadable on browsers that don't support it.) The <font> tag is not necessarily safe, however; Warren Steel has written an explanation of why FONT can be harmful as well as the excellent Hints for Web Authors
Third, they're often used so egregiously that the page just looks ugly. Use of <blink> was the first major offense in this category, followed later by backgrounds (often with bizarre color combinations) and of late by sheer overuse of frames.
Finally, and most importantly, overuse of the layout possibilities (especially frames) offered by some browsers distracts from the content. The content which is, hopefully, the whole reason for the page (or site) to exist in the first place. There are already plenty of low- to no-content "billboard" sites; we hardly need more of them.
Don't forget that a web page, or a web site, is meant to be a way to communicate; don't forget that text (that's right, those archaic "words") is still the primary medium of the Internet. Don't let graphics, tables, frames, applets, or animation distract you (or your reader) from the text. Don't use header tags to create small text for disclaimers. Don't design a page so it only looks good with a particular browser, or window width, or font choice. Don't override the user's choice of font face or size for the body text; they are in a position to set it for the best readability in their environment, and you aren't.
Good use of language (either English or any other human language) is also a must. If you have trouble with spelling and/or grammar, use a spell-checker and have someone else proofread your pages. A good book or three on writing style (such as Strunk & White's The Elements of Style) is also a good thing to keep handy.
The real-estate maxim that "the three most important things are location, location, location" also applies, in a different form, to the Web. As I mentioned above, a page (or site) really needs to be driven by its content. Graphics are nice, lists of links to other places are a form of content in some cases, but when it comes right down to it people visit a page to get information.
This means that specific information should be easy to find (large infostructures may require some form of search engine, ranging from WN's built-in search features to something like WebGlimpse). A nice hierarchical breakdown helps "browsers" (not the programs, the users) find their way. (Don't forget to include "up" and/or "top" links!)
Some of the most useful work on navigability and usability for the Web has been done by Jakob Neilsen. His Alertbox columns give succinct but useful guidelines on various Web usability topics.
Don't let implementation of flashy features get in the way of writing (or HTML-formatting or delivering) content. Get your site together before you implement a "hit counter". Better yet, don't bother with the hit counter; it makes your page harder to cache, and for efficiency reasons, caching should be encouraged, not discouraged.
When you do add a spiffy presentation to your pages, consider using stylesheets. Not only are they more likely to work on different browsers and in different environments, they're easier for you to work with as well. With a linked stylesheet, you can control multiple pages from one place; if you decide to change your "look", you don't need to search-and-replace through hundreds of HTML files to change things.
Not everyone using the WWW has a fast machine, a large color display, and a T1. Some people have only a VT100 emulator (or a VT100!) and a 2400bps modem. Some people may have a reasonable speed machine with a small color display, but only a 14.4kbps modem connection to an overloaded ISP. Some people may be blind; some "people" may be search engine robots. Good web designs will work for all of these people simultaneously.
Even those with fast machines and fast connections may have to deal with network congestion, long round-trip times, or server overloads; a little work in making your pages more efficient can save time and resources for everyone--including you.
Some authors point to cable modems, 56K modems, ISDN, and ADSL and claim that the bandwidth problem is no more. I find that the bottleneck simply moves upstream; while the number of users on the Internet is still doubling roughly every 12 months, server and backbone capacity is holding fairly close to the Moore's Law doubling time of 18 months. This means that congestion is likely to get worse before it gets better, and that tuning your pages for efficient delivery may save you big money on web hosting charges (often charged by the megabyte of content delivered) or server upgrades.
Some strategies for keeping pages efficient:
When using JPEGs, select a high compression setting (low quality); when using GIFs, cut the bit depth down as much as possible. The Bandwidth Conservation Society has some very useful tips on how to cut down graphic file sizes.
HEIGHT and WIDTH don't actually make the page load any faster, but they make the page appear more quickly with browsers that support them. ALT attributes make the page load quite a bit faster by allowing users to turn off image loading; don't make it impossible to use your page without waiting to pull over all the images. Alan Flavell has written a set of documents on "text-friendly" authoring, which can help you make a page more usable by people using text-only browsers, graphical browsers with image-loading off, or speaking browsers (such as the blind, or people driving to work and using an in-car audio browser). As a bonus, text-friendly sites are easily indexed by search engines, which are one of the best ways for people to find your site.
Reuse graphics (like backgrounds, or navigation images) where possible. Every graphic that's still in the user's cache, or available from their caching proxy, is one less that has to be sent across the link. Avoid counters and other uncachable items where possible. Don't gratuitously "cache bust" just so that you can get better "hit tracking"; even the best statistics available aren't very good.
Also, reuse pages by making your links consistent; either use "index.html" (or your site's default "index file") consistently, or use links ending with just the slash consistently. This not only enhances caching (since the browser can't tell that they're the same document, using both can wind up causing the browser to pull the page over twice) but also helps the user navigate, since the browser's history "bread crumbs" will show the link in the "visited" color.
Speaking of those trailing slashes, don't forget them when giving out a URL or writing a link! While it appears to work, what is actually happening is that the browser requests the page without the slash, is given a response from the server redirecting it to the proper page, and only then does it request the proper page. This results in a full round-trip time being completely wasted--because of a single missing character.
Another useful way to minimize round trips is the client-side imagemap. That eliminates at least one (and usually two) round trips between the client and server; the first one sends the coordinates (and usually gets an HTTP redirect), the second one requests the actual document. Of course, it's a good idea to also have a server-side imagemap for older browsers. Another way to minimize round trips is to make caching work better (see the previous item for more on this). Unfortunately, some browsers don't implement the client-side imagemap specification very well, forcing you to deliver the same imagemap in every file instead of referring to it once and letting it be cached. I consider this a fairly annoying bug, but apparently fixing it's not as important as adding JavaScript Style Sheets.
Break topics into their own directories if you think they have even the smallest possible chance of growing. It's a pain in the neck to restructure a document into smaller documents because you let it grow too long and too bloated; both my web design musings and DNS LOC pages outgrew their "single file" origins and needed breaking apart.
However, there is a silver lining in this cloud; I think both documents are better structured now because I waited to let the content lead me to a good structure, and they're better written and more cohesive because I had to do a full pass through them while reorganizing them. (It's also convenient that WN lets me redirect links to the "old" locations easily to the new ones.)
Or, at least, try not to tickle the bugs too aggressively. In particular, despite the fact that closing tags for table cells and table rows are optional, Netscape is known to get badly confused if you leave them out when nesting tables. Style sheet support also seems to be a particularly fertile area for various gotchas.
In most cases, sticking with standard, validated HTML will work on every browser without causing any problems; in some cases, the browsers will be pickier than the validators.
Christopher Davis
Last modified: Mon Nov 28 14:06:14 EST 2005