Practical Web Design – Fundamentals of Web Design

I was sitting on the porch with my old Aunt Gracie one afternoon, sipping corn liquor and swapping tales about the old days, when the topic turned, surprisingly enough, to Web design.

"You young whippersnappers have fergot about everything that worked good back in the old days of the Internet," she snarled, fixing me with one watery blue eye. She hocked a good one in the general direction of the spit can and went on.

"All this Flish and Flash and graphics jumpin’ around every which way and picters lungin’ out of the screen at me, forty-leven different colors swirlin’ round every which way, it’s enough to make an old lady like me want to switch off my old two-banger PC and go in for a nap. I ‘member when Web pages used to make sense. I could load one up, get what I needed offen it, and go on ’bout my business. Nowadays I cain’t make head nor tail of what half the pages out there are tryin’ to get across, and I ain’t got the patience to sit and figger it all out. I’d ruther spend my evenin’s chasin’ weasels out of the tomater patch."

I usually try to keep my distance from Aunt Gracie and her spit can, but what she said that afternoon made good sense. There are some fundamentals of basic Web design that are just as applicable today as when trailblazers like Aunt Gracie were hacking their way through the electronic underbrush…

The article is broken into 2 parts:

Part 1: The Essentials

Part 2: Looking Good

Part 1: The Essentials

Definition of a good Web site: A site that delivers quality content for its intended audience and does so with elegance and style. — DevX’s Project Cool

The rule of "Keep it Simple, Stupid" is tried and true, but it’s not a be-all end-all of Web design. Gamers, for example, expect a busy page with a lot of sophisticated graphics, Flash effects, and the like. The usual understated page with the off-white background and the typical menu of links sedately trundling down the left side of the display leaves this audience cold; obviously the people who designed this Website aren’t on their wavelength — these guys like plenty of whizz-bang in the pages they visit.

On the other hand, when Aunt Gracie goes on the Web to hunt down some nice dinnerware, she isn’t going to want jazzy Flash effects, purple-on-black color styles, and a raft of animated graphics doing gymnastics in front of her rheumy old eyes. She’s been known to take a stick to the monitor to make it all stop. Corporate users expect something that might not necessarily be "buttoned-down," but certainly something solid and professional that reflects positively on their business and compares well with the competition. Personal home pages want an emphasis on the personal — the site should reflect the interests and personality of the owner.

Target Your Audience – Visually

The key here is to know who is going to be using your page, and to design with their needs and desires in mind. The KISS rule is a good one in most cases. If you don’t need something — a frame, an animated graphic, a Flash animation, a fancy DHTML effect — don’t use it. On the other hand, you don’t want a page with all the appeal of last week’s oatmeal, either; a bland, uninteresting page full of unbroken blocks of text with a drab color scheme and dreary graphics won’t attract anyone’s attention. Everything in moderation, folks… including moderation. Consider your audience first and last, and craft your site accordingly.

Every image that moves or blinks draws your visitors’ attention to itself. Be sure that it doesn’t distract them from your message. — Navarro and Khan

Whatever your site’s reason for being, you want to portray an image that conveys what your site is all about as well as the feelings you want to engender in your audience. It’s no coincidence that most financial sites use design and graphical tactics to give a feeling of rock-solid stability, calm, unworried affluence, and old-fashioned values. No matter what the stock market does, this site won’t have its feathers ruffled. In contrast, the ultra-hyper site design of the Nickelodeon and Cartoon Network sites appeal to their sugared-up audience of pre-teens and teenagers; you can’t overstimulate that crowd. A site selling luxurious lingerie isn’t going to use the same design scheme as a site selling outdoor gear for folks who want to go trekking through the outback. One will go for frothy, comforting pastels and gauzy, languid design, while the other will use a rough-hewn design scheme with logos seemingly carved of granite, and not a pastel in sight.

A good Web designer will be able to design all four sites, and others as well. Don’t forget, if you’re designing a Website for a corporation or business, that they very likely have trademarks, logos, color themes, and other elements that will need to be included in your design scheme. As Mary E. Carter reminds us, "Color communicates subtle, but important ‘information’ about your site long before people read its content." Carter also provides us with a most useful set of color palettes that evoke specific moods. Check it out!

Appealing to Multiple Audiences

If you’re trying to design a page that will appeal to both Aunt Gracie and her hyperactive, video-addicted grandson, then you’re going to have to make some compromises that could possibly alienate both audiences. You may want to consider refining your site to appeal to a narrower audience, or you may even choose to mount separate pages with different design philosophies for different audiences. In this case, you might do well to produce an introductory, or "doorway," page with links to the "whizz-bang" and the "sedate" pages — the content might essentially be the same, but the design style would be dramatically different.

Consider Connections

And don’t forget what your audience uses to access your site. Not everyone has a broadband or T1 connection; most of the world still limps along with slow dial-up connections, or must flounder around the Net through a maze of network connections. These folks appreciate your limiting your usage of big, slow-loading graphics, or at the least, providing thumbnails that automatically load and allow them to click for a bigger (and slower-loading) display. Remember, .JPG graphics are generally bigger than either .GIFs or .PNGs (Flash animations, surprisingly enough, load fairly quickly considering their complexity, but they can slow down a page, particularly one accessed over a dial-up connection). Complex table structures can take a while to load, too, especially if they’re larded with graphics. Slow servers cause slow downloads; if your provider can’t get your site up to speed, switch to someone who can.

Design for the World Wide Web is a balancing act between the graphic "wow" and the real-time "now." — Toni Will-Harris

"Elegance" is a favorite term to describe good, clean Web design, but what it actually means is up to the interpretation of the designer and the site user. To me, the term as it applies to the Web implies a certain grace and restraint of design, with well-chosen colors and graphical choices that don’t assault the eye, but instead invite the visitor to relax and enjoy the content. It’s the difference between being wooed over a candlelight dinner and being mugged in the elevator.

As the folks at Project Cool remind us, "clean design plus a good use of technology equals a good Web site." Another, equally applicable slogan: "less is more." Even the most hyperactive Playstation addict appreciates clean design, though his standards may differ from yours, mine, or Aunt Gracie’s.

What Flavour of HTML Should You Choose?

Every Web page conforms to a version of HTML (or XHTML, or even XML, though we’re not going into those here), and is determined by the DOCTYPE (document type) code. The line:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

at the top of your page (above the initial <HTML> tag) covers your bases in most cases. It supports many of the elements of the latest version of HTML, 4.01 Strict, supports style sheets for the most part, but also supports most deprecated or no longer current HTML elements, frames, link targets, and other attributes not allowed in by-the book HTML 4.01. This document type also keeps older browsers such as Netscape 4.x in the game. If you’re designing to the latest HTML standards and/or using sophisticated style sheets, then this doctype:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"    
"http://www.w3.org/TR/html4/strict.dtd">

should be used, but be aware that a lot of older browsers won’t display your page properly. Neither can you use frames unless you use the "frameset" version of this doctype. Note, too, that the "transitional" DOCTYPE I cite doesn’t include the URL of a DTD, or document type declaration. This is because using URLs in a DOCTYPE element sends some browsers, including IE, into Strict mode, defeating the purpose of the "transitional" DOCTYPE.

Of course, you could just slide bare-cheeked on the ice and use no doctype in your pages at all (just use the <HTML></HTML> tag), but that’s not a good solution. That leaves the individual’s browser to choose how to display the page, and while most browsers will cope just fine with the situation, some will gag. Besides, you need to get into the habit of using a DOCTYPE element. If you don’t know a DOCTYPE from a typewriter, use the "transitional" doctype at the beginning of this section. If you know about the various doctypes, or if you’re coding in XHTML, then make your own choice. The decision to use the "transitional" doctype is safe and conservative, but it’s certainly not an up-to-date choice. If you want to ensure that your Web page is ready for modern browsing and will be compliant with current and upcoming Web standards, you’ll need to learn about CSS (Cascading Style Sheets), HTML 4.01, and XHTML.

Note: You can visit the W3C Validator to check your document for compliance with W3C standards, or use Dave Raggett’s acclaimed HTML Tidy program, now an open-source project.

Browser Compatibility

Our developers never release code. Rather, it tends to escape, pillaging the countryside all around. — Paraphrased comment from the Enlightenment Project

A few years ago, the lazy Web designer crafted his/her pages with Netscape for Windows in mind; as that was by far the most popular browser in use, designing the site for Netscape/PC users was "good enough" to catch the majority of users, and never mind the rest. Nowadays the same lazy designers make their pages for Windows and Internet Explorer, for the same reasons. Not a good approach.

Millions of Windows users still employ Netscape (or the open-source Mozilla). Many others use Opera. Some AOL users are still trundling along with their out-of-date AOL browsers, and some hard-core folks still swear by Lynx, the text-only browser (there’s also the surprisingly large contingent of users who keep graphics switched off and read only text). Then, there’s WebTV to be reckoned with. And there are differences between the Mac browsers and the Windows browsers of the same name, not to mention the Mac browsers Cyberdog, OmniWeb, Chimera, iCab, and others. There are the browsers for Linux such as Konqueror, Opera for Linux, Mozilla for Linux, and others. According to the Browser Archive at Evolt, there are well over 100 browsers out there being used by someone (well, okay, some aren’t in use anymore). Yeesh!

Why should the burgeoning Web designer care? Because your page won’t display the same from one browser to the next. The more plugged-in designer uses one method or another, either client-side or server-side, to detect what browser his/her visitor is using, and "tailors" the code they send to that particular browser. If you can do this, then be off, this section is too easy for you (probably this whole article is too easy for you!)! But if you don’t want or can’t do something so slick, what can you do to meet the needs of your various visitors with their plethora of browsers?

Basically, the best thing to do is to be aware of the HTML tags and other features and protocols that one browser will support and others won’t, and avoid them whenever possible: the infamous "marquee" and "blink" tags come to mind, as do iFrames, layers, JavaScript, style sheets, plug-ins, DHTML, and others. Some of these, such as "blink" tags and layers, are long out-of-date; others such as DHTML and JavaScript are quite current. If you do use something that is browser-specific, choose a function that isn’t critical to your visitors’ ability to view your site: an example is the neat color schemes for the horizontal and vertical scrollbars that IE provides for. Netscape users will just get the plain-Jane grey bars, but it doesn’t hurt them to not have the colored scrollbars — it doesn’t affect the way your site presents its message and handles its content. It’s a prime example of a way to "gussy up" a page for one browser that won’t affect a different browser.

What Page Features aren’t Consistent Across Browsers?

There are plenty of page features that will cause problems for one browser or another. Forms come quickly to mind, as do text size and display size (see below for more info on these two). The way you code a link can be a problem: for example, the following link will work in most versions of IE, because the browser will process the code, but most versions of Netscape will report it as a broken link:

<A HREF="go here.html">Go Here</A>

Why? Because of the white space between "go" and "here." IE will deal with it, but Netscape won’t. If you want it to work in Netscape or anything else, you have to write it as such:

<A HREF="go%20here.html">Go Here</A>

If it’s your file, go one better by renaming the file GOHERE.HTML and avoiding the whole issue.

Another example is the site that looks good in IE, Netscape/Mozilla, and even Konqueror, except that the fonts render badly in the latter. Konqueror users should be able to fix the problem on their end easily enough by clicking "Zoom In" on their browser. Your response can be to rework your page to look as good in Konqueror as in the Windows/Mac browsers, or you can let the Konqueror users handle it themselves. If you’re working on a broad-based audience of mostly Mac and Windows users, your best bet might be to let well enough alone and let the Konqueror users handle it for themselves. If you have a large component of Linux users, you might want to fix the problem so that Konqueror users don’t have to deal with the issue. It’s your call, and your audience.

As Compatible as Possible

Browser incompatibility is a huge issue, and one that’s being grappled with at all levels of the Internet. Meanwhile, you can cope by becoming aware of the plethora of HTML tags that work in one browser but don’t work in another. You can decide whether or not to use extensions, plug-ins such as ActiveX, JavaScript, and even style sheets, which don’t work well in older browsers (and can be iffy in some current browsers) but are essential in modern HTML coding. You can decide whether or not to use more up-to-date graphics such as .PNGs, which will one day become a Web standard but for now don’t work in older browsers.

Quick and dirty fix: make sure your page looks good in Internet Explorer, Netscape 4.x, Netscape 6/Mozilla, and Opera — that means downloading these browsers to your machine and testing your site in them (find the older Netscape browsers available for download at the Netscape Archive). Use features such as style sheets, JavaScript, and DHTML sparingly; if you use these features for critical elements of your page such as a navigational scheme, provide your less up-to-date visitors with a more technologically conservative alternative. Don’t use browser-specific code and expect your visitors without that particular browser to just "get over it," and don’t skirt the issue with a craven "Works best in XXX browser" label. Try to address the needs of every member of your audience, and be aware that you can’t create a site that works for everyone everywhere.

Navigation

Everyone needs to be able to find their way around your site with ease. The choices you make in providing navigational assistance on your site will often make the difference between a site that users frequent, and frequently use, and a site that gets visited once and promptly forgotten. I can’t tell you how many sites I’ve visited that offered tons of good information but were so difficult to navigate that I refused to visit that site again, choosing instead to visit an alternative site that gave me an easier, more intuitive navigational scheme (remember, on the Internet, there’s always an alternative!).

One traditional method is to use a simple table of links that march down the left side of the page. There’s absolutely nothing wrong with this design; millions of effective, well-patronized Websites use this every day. It has the advantages of usability and familiarity: we’ve seen it before, we know how it works, it’s comfortable and workable. We don’t have to sit and ponder how to move around the site, we just glance at the structure and go. But there are plenty of other choices. If you find, or concoct, an alternative that appeals to you and your audience, by all means use it.

The Psychology of Navigation

One thing to remember: the human brain sees five or less items as a single group, but when it encounters more than five items, it breaks them down into "subgroups" to process them. What this means for Web designers is that we need to keep our navigational options simple enough for easy use. "Next step" options should be as few as possible. Although it’s not always feasible to keep your navigational choices to five or less, you can usually group the options into smaller "subcategories." Five groups of five is easier to handle than a single group of twenty-five, for example.

Another, related concept is the idea of "three clicks or less" to find the desired information. Nothing frustrates a Web surfer more than having to click and click and click again in order to find whatever specific piece of information they’re hunting for. The Project Cool folks remind us that "when people get lost, they tend to surf off somewhere else instead of fighting their way around a site." Ideally, everything a surfer wants should be no more than three clicks away from the home page. Don’t forget to make it easy for them to get back to their starting point… home should never be more than a single click away.

Top Tips for Good Navigation

There are a few things to remember in designing any navigational scheme.

Make It Clear

First, it should be apparent to the first-time visitor how to move around your site without scrolling down — everything should be obvious as soon as the page loads. The first-time visitor should be able to have your page load AND be able to grasp the essential layout of your home page within 30 seconds… much more than that and they’ll fly away to find a site that’s easier to use. For users restricted to dial-up access, this means home page sizes no larger than, say, 45K.

Consider A Site Map

A separate "site map" for a larger, more extensive site is a good idea, but shouldn’t be relied upon as the main navigational tool. Many users, particularly less experienced ones, don’t employ site maps. Many don’t even know what a site map is, nor do theycare to find out. And since it must be accessed through the main page by a click, it will always function as a supplemental method of navigation, not the main method.

You should make sure that your site map is easily accessible through a link or button labeled "Site Map" (surprise!), and that your map makes it easier, not more difficult, to navigate your site. Your site map should be much simpler in design than your regular pages, eschewing graphics and effects in favor of simple, easily used text links. The idea behind a good site map is to provide the user with a single overview of the navigational scheme and informational structure of your site. Keep these especially simple and easy to use; don’t make the user work to figure out how the map functions.

Include Site Search

Another good idea is to make your site searchable within itself. Search functions allow the user to find what they’re looking for outside of your navigational framework, as well as giving them an "out" when they get turned around. Most users know to look for "the little box that they can type in," so give them just that, preferably labeled "Search This Site" or something similar.

Keep the search parameters simple, as many users refuse to learn advanced search query techniques. "Scoped" search techniques (limiting searches to specific areas of your site) and other "advanced" search functions are useful for some users and confusing for others. Most users want to be able to find what they’re looking for with a simple onoe- or two-word query; let them do just that.

Navigational No-Nos

Some common navigational "no-nos" have been floating around the Web for as long as people have been designing Web pages. Many of them are still valid, while others have become outdated and less applicable. Here are a few, based largely on the observations of Web design guru and curmudgeon Jakob Nielsen:

Frames

This used to be the great "bugbear" of Web navigation. I hate frames, you hate frames, we won’t visit sites that use frames. Well, that’s not true any longer. The old versions of Netscape and MSIE both handled frames quite poorly, but the problems in these browsers’ frame handling have long since been fixed, so frames aren’t the no-no they used to be. Still, frames can be a bit clumsy to work with, so while it isn’t necessarily a design faux pas to use frames, it’s a good idea not to use them unless you absolutely have to. Usually a well-thought out table structure works better for most sites than frames. Note I said "usually," not "always." There are times when frames work very well, particularly if you want to keep a header or navigational structure always visible.

Other sites that use frames are sometimes badly behaved enough to "trap" your page within their frames. To keep this from happening, use this simple META tag:

<META HTTP-EQUIV="Window-target" CONTENT="_top">

For more about using META tags, see the first installment of this column, Top 15 META Tag Tricks.

Make sure every page on your site has this tag in its <HEAD> section. And don’t let your page "trap" other folks’ pages. It’s bad design and downright rude

Unusable Back Buttons

The Back button on the browser is the second most used navigational tool after the hyperlink. Nielsen calls it "the lifeline of the Web user" and points out, correctly enough, that "users happily know that they can try anything on the Web and always be saved by a click or two on Back to return them to familiar territory." However, some Web designers yank the Back button away from us. Either they have all of their pages open in new windows, they employ an "immediate redirect" that effectively cripples the Back button by sending the surfer back to a page that bounces them forward again (very, very annoying), or they prevent caching so that using the Back button forces a new download from the server.

Nielsen really doesn’t like links that force a page to open in a new window; I’m not so adamant on the issue. There are times when it’s appropriate and desirable for a link to open a page in a new window, though personally, I prefer to make my own choice by right-clicking a link and choosing the "Open in New Window" option when I want it in a new display. It is true that littering a surfer’s machine with one new browser window after another can confuse and annoy a surfer, especially a novice, and can make it difficult for the inexperienced surfer to navigate their way back along their trail, especially one who is viewing your site in Full Screen mode. Multiple browser windows also eat up system resources, and can even crash a surfer’s machine. And don’t forget that folks who use Mozilla, Opera, and any number of Internet Explorer add-ons have their own "tabbed" navigation bars that let them view multiple pages in a single window.

The best advice I can offer is to think long and hard about why you’re having your links open in new windows. If you can’t come up with a good reason, then stick to having your links come up in the same window, and let the surfer decide how they want to view your linked pages.

Long Download Times

Still a tremendous problem on many sites. Originally the cause was large graphics, or large numbers of smaller graphics, that prevented a page from displaying. Later on the problem manifested itself in complex table structures (particularly the page that is contained completely within a single huge table, requiring the whole thing to load before anything displays), sound files, Java applets, and other Web features that slowed a page’s loading time. Slow servers are also a common culprit.

Whatever the reason, most surfers won’t wait more than a few seconds for something to come up. They don’t care to wait for that cool Java effect or for your host’s slow server to do its thing; if something doesn’t come up almost immediately, they’re clicking out to find something that does come up. This is doubly true for the legion of Web users that are stuck using dial-up connections.

Fancy Menu Options

The DHTML and JavaScript menus that "extrude" or pop-up from a single link when mouseovered can be very striking and effective, but if they block the view of your page’s content, then they become as much of a hindrance as a purposeful addition. Be careful where you position them, and test them thoroughly on different browsers (and remember, older browsers may not render these properly, so don’t rely on these as your only navigational choice).

Complex URLs

This used to be a problem in the wild and woolly days of the Web. Today many users hardly pay any attention to URLs, letting their browser handle the task of remembering a bookmarked site and relying on features such as IE’s AutoComplete to deal with long URLs. Most sites also have some kind of navigation support as well, so remembering a long URL isn’t the chore it used to be. Still, shorter is better.

Orphaned Pages

These are pages that don’t have navigational links in their content — once you’re there, you can’t get out without using your "Back" button, assuming the page didn’t open up in a fresh window, or worse, you’re forced to type a fresh URL. Again, not nearly the problem it used to be, as most experienced surfers know how to lop off the end of a problem URL to get back to the home page. But again, it annoys experienced users and absolutely befuddles novices. Remember how dependent the less experienced user is on the "Back" button (see above) as well as on big, friendly buttons that take them back to your home page with a single click. Besides, "orphaned" pages are just bad design.

Non-Standard Link Colors

Okay, sometimes we get sick of the usual color scheme of blue-red-purple for hyperlinks. The thing to remember is that it’s a standard that everyone recognizes. If you’re going to change your site’s link color scheme, go ahead, but remember, your scheme should be as easily recognizable and usable as the standard. Most Web designers aren’t enamored of the traditional underlining of links, and understandably so — it looks untidy, it can be disruptive while reading through large blocks of text, and, well, we just don’t like ‘em. It is, however, worth remembering that color-blind surfers often like underlined links, as do surfers who prefer text-only displays. It’s also notable that underlining words that aren’t links confuses many surfers. But get rid of the underlining if you like (it’s the first CSS effect most of us learn).

Do remember, though, that links need to stand out somehow, and having them in a different color is usually the best bet. Few surfers set their browsers to ignore your link color choices in favor of their own, so most of us are at the mercy of your color choices. Be kind. Give us something distinctive that doesn’t intrude. Also keep in mind that for the vast majority of surfers, a text block in blue means that it’s a hyperlink; don’t fool us by coloring non-linked text blue.

A few personal observations: I don’t particularly like "mouseover" links that go to boldface (for example) when I hover my cursor over them. They make the text jump. However, when they’re carefully designed, they can work very well. I really don’t like links that are the same color as the rest of the text; I want to know a link is a link by looking at it. And I’ve grown tired of the links that are highlighted with a yellow (or red, or green, or whatever) box. Maybe it’s just me, but I get tired of reading a page that looks like one of my college texts after I’ve taken the highlighter pen to it.

Non-Standard use of GUI Features

This includes the "radio" buttons that don’t require the clicking of an OK button to take effect, the dropdown menus that sometimes require a Go button to function and sometimes don’t, and so forth. There’s no hard-and-fast rule to follow here, but keep in mind that consistency equals ease of use. In most cases, people like things to work in the fashion that they’ve grown to expect. Don’t have your GUI features work differently than the accepted standards just because you can; make sure that your features work in an easily understandable fashion.

Sites that are Unclear as to their Purpose

What’s your site about? Is it trying to sell me a car, giving me advice on fixing my computer, promoting your political viewpoint, or showing off your cats? Whatever it is, let the site visitor know immediately what your site is there to do. If they have to wonder what they’re doing on your site and what your site is there to offer, chances are they won’t stick around long enough to hunt down the answer. For commercial sites in particular, a one-sentence "tagline" that catches the first-time viewer’s attention off the bat is an essential.

"Splash" Pages

These are the initial pages that typically load a single graphic or text block that require the visitor to "click through" to get to the main page. Personally, I can deal with splash screens if they’re used in moderation and with style and grace, but the effect can become tiresome very quickly. Repeat visitors don’t want to click through the splash screen time and time again; while some (not all) first-time visitors may not want to click through the doorway page to get to the content. And many visitors who come to your site through a search engine may miss the splash page altogether.

Nielsen calls splash pages "a sure sign of bad Web design;" I don’t take such an absolute view, but they are usually an example of "too much sizzle and not enough steak." Probably the best caveat from my experience is the fact that when I visit a site that uses a splash page, I don’t bookmark that page, but the "main" page behind the splash screen. And splash pages that use big, often slow-loading Flash displays are doubly troublesome. Navarro and Khan remind us that for a business, the splash page should act as "the storefront to your Website." It should invite the visitor inside, not chase them off.

Pages with No URL

Script-driven sites make it difficult to bookmark specific pages, instead requiring the repeat user to go to the home page and "start from scratch" every time they want to drill into the site’s subpages. While there are instances where this is a necessity, it can put surfers off of returning to your site.

Misleading or Badly-Titled Bookmarks or Favorites

The standard for bookmarking is for a page to use the title from the META "Title" tag as the bookmark description. If a title is tremendously long and crammed with buzzwords and sales chatter, then the person who bookmarks the page won’t recognize the page from the title and will have to rename it to something they find useful. And sometimes other pages "hijack" linked pages with their own titles when bookmarked — a no-no in every sense of the word. If your title begins with "The" or "Welcome to…," then your page gets bookmarked under "T" or "W" with all the other pages that begin the same way. Your title should be short, descriptive, and useful in someone’s bookmark listing.

Linking to Non-HTML Pages Without Warning

It’s fine to link to a .TXT, .DOC, or .PDF file, but please let me know what I’m about to link into. If I don’t have Acrobat Reader or a .DOC-friendly word processor installed, then I can’t use the document to which you’re sending me. And such a document loading into my browser may cause unlooked-for behaviors that can be confusing or even scary for a novice user. There’s no problem linking to these documents, but warnings should always be provided. It’s also courteous to offer links to the software that users may need, particularly in the case of Acrobat Reader.

Making it Hard to Contact the Site Owner

This is especially important for commercial sites. Every single page should have whatever contact information is appropriate: email addresses, names and postal addresses, telephone numbers, fax numbers, whatever. Don’t just have a clickable graphic that says "email me!;" have the contact information plainly written in text. Someone who saves your page to disk or prints your page may not be able to click the graphic to find out the email address. The site’s main URL should also be readily available on every page.

Background Colours

The operative word here is "background:" something nice and unobtrusive for your text and graphics to sit upon without drawing attention to itself or getting in the way. If you choose a background color, remember that your text has to be readable atop it — some color choices not only strain the eyes, but challenge the monitor’s ability to display colors properly. Black text on a red background sends me for the aspirin bottle (and Aunt Gracie for her stick). Orange text on a pink background works well if you’re designing a site for Barbie fans, but not too many others. Psychedelic backgrounds are okay if you think the world revolves around the Grateful Dead, but although I like the band, I don’t like the background choice, and neither do most surfers.

If you’re using a bordered background (i.e. a relatively thin left-hand column of color that repeats all the way down), that’s fine in and of itself, but remember that you don’t want your main body of text or your graphics overlapping into the border; furthermore, whatever you put in that border should not only refrain from overlapping itself, it should alos be the proper color to stand out from whatever color choice you’ve made. If you do decide to use bordered backgrounds, some easy ways to keep things tidy include the use of the <UL> tag to indent your text (don’t use the <LI> tag and you won’t get bullets or numbers) or the <BLOCKQUOTE> tag, which indents both left and right sides of the text blocks and therefore may not be what you want. Tables are another good way to keep text from creeping over into a border. And, of course, style sheets lets you set the precise amount of indentation — probably the best way to go.

Do I even need to mention animated backgrounds?

White or light-colored text on black or dark backgrounds can look "sexy" or dramatic, and I’ve seen some wonderfully done Websites with this scheme, but some surfers have trouble focusing on them. And don’t forget that a significant minority of your audience is color-blind (8% of the men and 0.4% of the women who visit your site suffer from one form or another of color-blindness). Safe Web Colours for Colour-Deficient Vision is an excellent source of information, and includes color palettes that simulate several varieties of color-blindness. A related issue is black text on a white background; while this is eminently readable, it can cause eyestrain because of the stark contrast. A dark (but not necessarily black) text on an off-white background can often ease the strain on the visitor’s eyes while keeping readability to a maximum even for color-blind or visually limited users.

Part 2: Looking Good

Part 1 of this article discussed the essentials of Web design, the different choices of HTML types, browser compatibility, site navigation, and background colors. Part 2 discusses color schemes, display sizes, text and font choices, margination, and lots more.

Color Schemes

It’s not just the surfers that suffer from headaches when they encounter certain color schemes, it’s the monitors themselves. Dark text on darker backgrounds is an example of a color scheme that can strain a monitor. If the monitor is only slightly out of calibration, the colors can "separate" and look awful.

Remember, too, that the variations between the designs and configurations of monitors and display controllers will cause colors and graphics to appear differently from one display to the next. Even the same monitor connected to different video cards will display colors and graphics differently. And the difference between Windows and Macintosh displays can cause the Web designer to develop ulcers.

What’s a Web designer to do? Well, there are some remedies, though none are perfect. First, it’s usually a safe, if outmoded, bet to stick to the traditional 216 "Web-safe" colors that display properly when viewed across different platforms. This is advice that many consider outdated, and rightly so.

From the Guru of Color Design

To quote Lynda Weinman, one of the original gurus of Web design:

"The only reason to use the browser-safe palette is if you have a concern that your Web design work will be viewed from a 256 color (8-bit) computer system. …[B]ack in 1996, the [majority] of computer users had 8-bit video cards. Today, the minority have them, so the justification for using the browser-safe palette has diminished greatly if you are developing your site for users who have current computer systems.

"There may be [a] resurgence in the need for the browser-safe palette when designing for alternative online publishing devices, such as cell phones and PDAs. Those systems are still in 1-bit (black and white) or 8-bit color. Right now, very few people are designing their Web sites to work on those systems, so the need for the browser-safe color palette is definitely downgraded to a mere shadow of its former glory."

"Browser-Safe" Doesn’t Mean What It Used to Mean

So again, the advice to stick to the old palette of 216 browser-safe colors is more to keep users with older systems happy, at the possible risk of limiting yourself unnecessarily to a very limited (and artistically unsatisfying) set of color choices. Again, know your audience. If your site is going to be used by folks who are likely to have more current systems, there’s no reason to limit your color choices — "Today, any consumer with a Gateway or iMac is going to see all the colors you can throw their way," says Weinman.

Conversely, if your site will be used primarily by people with older or more limited systems, you shouldn’t challenge them with a blaze of colors that their computers won’t handle properly. Weinman provides us with a useful Web page that shows the 216 colors sorted by value, including the hex numbers and RGB values, on her Non-Dithering Colors by Value page.

It’s also worth noting that flat-color illustrations, logos with flat colors, or displays with large single-color areas profit the most from being created in browser-safe colors, as the dithering is much more visible and annoying in these displays than, say, in photographs.

Why 216 instead of 256 colors? Depending on which source you check, it’s because the remaining 40 colors vary too much between old Mac and PC displays to be included, or because some colors are reserved for the needs of specific operating systems. And if you really want to get picky, because of the color shifts caused by some video hardware, there are really only 22 truly safe Web colors. 22 just aren’t enough, by gosh!

About half of the computer users out there use 16-bit color displays, while only 3% are stuck with the old 8-bit displays. So the need to stick to the 216 supposedly safe colors (or the 22 truly safe colors) isn’t relevant any longer. But there’s still the issue of what looks good on what displays. Here are some options, based on your decisions about who comprises your audience, and how you want to deal with the issue.

A Variety of Choices

To play it extremely safe, stick to the 22-color "really safe palette" and prepare for a challenge — how in the world do you design an attractive Web page with this selection of colors? I’m sure it can be done; I’m not so sure I could do it myself.

Play it fairly safe and stick to the traditional Web-safe palette of 216 colors. Your 8-bit users, all thirty of them, will be happy, your 16-bit users won’t notice too much color shifting if you design carefully, and most people will be fairly happy with your displays. You will find that your artistic choices are extremely limited, though.

Or you can choose not to worry about it at all. Splash colors around at will and let the devil take the hindmost. Of course, on some visitors’ displays, your site will look truly awful, but you’re not worrying about that, remember? A variant of this approach is to ignore the needs of your 8-bit users and design with the majority in mind.

A number of color resolution problems can be avoided:

  • make your .GIFs using transparent backgrounds whenever possible
  • keep your .GIFs separate from your HTML colors whenever possible
  • minimize "seams" by making .GIFs that are adjacent to HTML background colors partially transparent
  • stick to Web-safe colors for the backgrounds of pages and tables whenever possible

Keep in mind that separating .GIFs with background colors from their HTML background equivalents avoids the possibility of noticeable color shifting. Note also that .GIFs are limited to 256 colors, or an 8-bit display. .JPG graphics can use up to 16.7 million colors, or a 24-bit display.

And just to add to the confusion, users of LCD displays such as those found on notebooks and laptops (and some desktops) have contrast issues that render light colors such as silver, beige, and cream indistinguishable from white. If you think a large portion of your audience uses LCD displays, be sure to test your pages on such a display.

Whatever you decide, keep your audience in mind and test, test, test.

Remember that if people are going to print out any part of your page, they’re going to most likely print it on white paper. A large number of them are not going to bother with printing in grayscale or turn off background image printing, so keep their needs in mind, especially with pages that are largely text.

Elaborate or "busy" background images can be appealing, but they can also make it tough on the poor slob who clicks the "Print" button in their toolbar only to have their printer use up half its ink to print your background image along with your text. And white text on a dark background might not print at all on some printer settings. You might consider providing a "printable" page that eschews most of the graphics and fancy fonts in favor of an easily-read typeface on a plain white background.

Display Size

Most Web surfers out there have long since graduated from the pedestrian 640×480 resolution (display size) on their monitors. 800×600 is considered the current "default" size by many Webmasters, and plenty of folks out there view their Web pages in bigger displays — 1024×768 or even larger.

According to one source, the ‘net community is pretty evenly divided between viewing at 800×600 and 1024×768, with only 2% still working with 640×480. I’m not so sure about this figure. I can’t back this with research, but I have the gut feeling that a lot of folks — at least more than 2% — are still using a 640×480 display. Most of these people aren’t the kind of folks who post on design forums or answer ‘net surveys; they’re using older computers in their schools and local libraries, in the basements of their churches, or just don’t bother (or can’t afford) to try to keep up with the new trends in computing.

Again, it’s a matter of knowing who your audience is. Is your site likely to be used by a lot of "old-time" or less technologically aware surfers? If so, you might consider sticking with a design that works on the old 640×480 display. The majority of us, though, should design our pages for the 800×600 user. With this decision made, we can stick to some fairly simple parameters.

As a rule of thumb, your page shouldn’t be any wider than 744 pixels (759 if you’re not going to have a vertical scrollbar displayed). The initial length of a displayed page is around 410 pixels; any longer and you’ll get the scrollbar. Most surfers don’t think twice about a vertical scrollbar, but I don’t know many who appreciate a horizontal scrollbar requiring them to go back and forth along the page to see the text. It’s easy to use a simple table structure to constrain your page to fit on a display.

Be aware that using graphics that are wider than 748 pixels is going to require your viewers to scroll horizontally to see the entire graphic, as well as letting the text march off the screen, and that’s annoying. Aunt Gracie absolutely detests horizontal scrollbars. And for some reason, far too many sites are optimized for an 805-pixel width, which makes absolutely no sense to me. It’s just wide enough to force a horizontal scrollbar in an 800×600 display, but there’s no content hidden to the right. Strange, and useless.

Note: the 744 pixel width goes along with Internet Explorer 4.5 and 5 for the Macintosh. IE 5 and 6 for Windows accepts a width of 780 pixels. Netscape for Windows shows a display between 776 and 780. The recommendation of a width of 744 is the safest and most conservative choice. The initial height of 410 is a similar "safe" choice; many browsers display at a height up to 446 pixels. Additionally, users who turn off some of their topside browser toolbars have a bit more height to work with. There are other caveats, such as:

  • whether or not a particular surfer has double or outsized Windows taskbars,
  • whether or not they’re using XP (which sports a slightly larger taskbar),
  • if they have the Microsoft Office toolbar displayed,
  • if they’ve chosen to dock their toolbars along the side of their display,
  • if they’ve set their browser margins to something unusual, and
  • whether or not you’re using CSS absolute positioning.

You can’t please everyone, nor should you try, but you should err on the safe side so that almost all of your viewers can have your page displayed comfortably. An excellent source of information on browser sizing is Webmonkey’s "Sizing Up the Browsers" page; go here for lots more detailed info, including height and width recommendations for other monitor resolutions.

Another source recommends designing your page for an 800×600 display, but keeping the text portion of your site between 640×480. That makes sense.

Text Sizing and Font Choices

While it’s a design ideal for a site’s text to display in the same size no matter who views it, in the real world this just isn’t going to happen. Different browsers display text in different sizes, and more knowledgeable users commonly adjust their font display to suit themselves.

It’s unfair to use an absolute font size in your Website’s text. What looks just right to you is too big for the fellow with 20/20 eyesight and too small for Aunt Gracie and her cokebottle glasses. Let the individual control the size of the font display. If you want to make a particular block of text larger or smaller, use relative font sizes that increase or decrease the block size in relation to the user’s default font sizing. The simplest way to illustrate this is with a basic FONT SIZE command:

<FONT SIZE="+2">This line is bigger than the rest.</FONT>

This particular text block between the FONT tags will be bigger than the rest of the displayed text, but will still base itself on the user’s font size preferences. Naturally, there are other, more sophisticated ways to control font sizing.

Modern CSS protocols allow the Web designer to control the size of the text display down to the pixel. All well and good, but what if the chosen text size doesn’t suit a particular visitor’s viewing needs? The surfer has a couple of options at his/her command to change the font display, but on IE’s default toolbar, the "Size" button isn’t displayed until the user goes through the View, Customize option to get it there. How many of your site visitors know about that button?

The same surfers don’t know that they can force their browsers to display your page in a selected size. There’s also the option to let your visitors choose their own style sheet, giving them several options of font style and size, but a lot of Web designers don’t know how to do this, and a lot of site visitors don’t know how to use the option.

Font Sizing Options

There’s a few things you can do to help your visitors avoid squinting.

  1. Avoid absolute font sizes in your style sheets; instead, go with relative terms such as 120% for outsized headlines and 90% for deliberately smaller text blocks.
  2. Make sure your initial font size is reasonably large, say 10 point (12 if you’ve got a large number of senior citizens or visually limited users).
  3. Remember that text embedded within graphics isn’t affect by style sheets or font size buttons, so the user is stuck viewing the text at whatever it’s originally displayed as; if you use pictures of text, ensure that the text is big enough to be read with ease.
  4. Make sure the color contrast between the text and the background is strong enough to ensure high visibility.
  5. If you’re designing a site for older or visually limited users, consider providing them with an alternate style sheet that gives them a nice, big display.

Multiple Font Choices

Don’t forget to allow for multiple font selections; giving a single font choice is okay for those visitors with that particular font on their machine, but for those who lack it, it means that your carefully chosen font displays in whatever the default font is on that computer (usually Times New Roman on PCs and Times on Macs). And remember that the font choices on PCs and Macs are often quite different. My Windows machine lacks Helvetica, a common choice for Macs; your Macintosh might not have Arial. A good quick-and-dirty methodology is to do something like this:

For sans-serif fonts:

<FONT FACE="Verdana, Arial, Helvetica, sans-serif">

For serif fonts:

<FONT FACE="Georgia, Times New Roman, Times, serif">

Serif fonts have the little "tags," or embellishments, on the individual letters; these assist the eye in achieving "text flow," where the eye naturally glides from one letter to the next. Sans-serif fonts lack these little embellishments, and have a "cleaner" display. You choose which group of fonts you wish your text to appear in.

Using a font choice similar to the above ensures that no matter what fonts are on the user’s machine, at least your text will display in something approximating your chosen font, and you’re covered with both PC and Mac users. Again, this applies mainly to older computers; the newer ones come loaded with dozens of fonts, including the ones we’re most likely to use. Do be aware that if you choose an unusual font in which to have your text display, most users won’t have that font; their browsers will display your text in whatever default text is selected on the individual users’ machines.

One font expert, Daniel Will-Harris, recommends that Windows users choose the Georgia font over Times New Roman, as it is more optimized for the screen (Times and Times New Roman were designed for the print medium). He also recommends avoiding Arial because of its narrowness and difficulty to read on certain displays, and avoiding the Times font for the Macintosh because of its lack of italicization. He suggests using Verdana (the font used by SitePoint), Tahoma, or Trebuchet instead of Arial.

Designing for the Dyslexic Surfer

Another consideration is making your site easily usable for dyslexic visitors. There are more Netizens than you think who suffer from one form or another of dyslexia, and their needs should be taken into account. Here are a few tips to make your site more friendly for these users (note that many of these tips contribute to a cleaner, more usable Web design for everyone, and are echoed elsewhere in this article).

Like other visually limited users, many dyslexics use computer speech output technology to read the pages to them. Ensuring that your page is speech reader-friendly is essential. Make sure that all of your important information is contained within text and not in graphics, as speech readers can’t read or interpret graphic imagery.

Dyslexic users who read your page on their own don’t like confusing or "busy" navigational schemes. Flashing graphics, distracting animations, wildly varying font styles, and textured or patterned backgrounds make it tough for them to use your site. Small icons that aid in navigation are useful, as long as each icon has a text alternative and/or an ALT tag. Use a consistent and easily-grasped navigational scheme. If you use frames, provide a no-frames alternative.

Whenever possible, keep paragraphs short and focused. Limit the amount of text on each page. If this isn’t possible, provide a topic index at the top of the text so that the dyslexic reader can home in on the parts that interest him or her.

Don’t specify a particular font. Most dyslexic readers prefer a particular font and stick to that one; let their choice take precedence.

Keep all text left-justified. Text that is centered or right-justified is tough to read. Stay away from flashing or animated text. Also avoid using background images behind text, and make sure there’s a strong contrast between background color and text color.

Links within the general text are hard to use. Provide a table of links below the text block.

If you must use background music or sound effects, provide an alternative for turning it off.

Abigail Marshall from Davis Dyslexia Association International reminds us:

"Sites that are designed to be easy for dyslexics are also easy for others to use and navigate. Market research shows that most people find it harder to read on a computer screen than from printed sources, so many non-dyslexic people will appreciate the dyslexic-friendly format."

Page Margins

You wouldn’t think that setting the margins for your Web page would be any more difficult than setting the background color or the font face, but it is. Why? It’s mainly because Netscape and Internet Explorer use two different sets of commands.

Without going into detail about the various tag commands, here’s a simple way to deal with the issue. In your <BODY> tag, use the following:

<BODY marginwidth="0" marginheight="0" topmargin="0"           
leftmargin="0" rightmargin="0" bottommargin="0" ...>

The ellipsis at the end of the tag will include the rest of your BODY commands. If you want to add margins, change the zeros to a digit (remember, the first two commands control Netscape, and the last four control IE, so change accordingly).

Again, this isn’t the most sophisticated way to handle margins (CSS provides a much better way to handle margin delineation), but it works. If you know CSS, then of course you should ignore this tip and use your style sheets to handle your margins. As always, the problem with using CSS is that older browsers don’t always display style sheets correctly.

JavaScript

Remember, around 10% of Web surfers keep JavaScript disabled. Some do it for security reasons, others do it because they’ve become aggravated with bad scripting that slows their browser functions. It’s a simple matter to supply non-JavaScript users with a non-JS page; you can do it either through a redirect script in your page or by providing a "doorway" page that gives non-JS users an alternative on which to click. If you don’t choose to do this, then limit your JavaScript usage to non-essential page functions.

Easy Bookmarking

Bookmarking your page is simple enough for any visitor, but you might want to encourage the practice. Here’s a nice, simple chunk of JavaScript that you can paste into your site’s home page to allow visitors to bookmark your site, modified from a script provided as a freebie by The JavaScript Source:

<SCRIPT LANGUAGE="JavaScript">          
function addbookmark()          
{          
bookmarkurl="http://www.myhomepage.com/"          
bookmark title="My Home Page"          
if (document. all)          
window.external.AddFavorite(bookmarkurl,bookmarktitle)          
}          
</script>

Add this chunk of script to your <HEAD></HEAD> section, and add the following piece of code wherever in the body of your page you want the bookmark link to appear:

<a href="javascript:addbookmark()"><b>Bookmark           
This Page</b></a>

Now your page has a nice clickable link to allow for easy bookmarking (you’ll need to replace the http://www.myhomepage.com/ bit with the URL of your own site, of course). If you want to have your visitors click on a graphic, simply delete the <b>Bookmark This Page</b> snippet and replace it witoo

I was sitting on the porch with my old Aunt Gracie one afternoon, sipping corn liquor and swapping tales about the old days, when the topic turned, surprisingly enough, to Web design.

"You young whippersnappers have fergot about everything that worked good back in the old days of the Internet," she snarled, fixing me with one watery blue eye. She hocked a good one in the general direction of the spit can and went on.

"All this Flish and Flash and graphics jumpin’ around every which way and picters lungin’ out of the screen at me, forty-leven different colors swirlin’ round every which way, it’s enough to make an old lady like me want to switch off my old two-banger PC and go in for a nap. I ‘member when Web pages used to make sense. I could load one up, get what I needed offen it, and go on ’bout my business. Nowadays I cain’t make head nor tail of what half the pages out there are tryin’ to get across, and I ain’t got the patience to sit and figger it all out. I’d ruther spend my evenin’s chasin’ weasels out of the tomater patch."

I usually try to keep my distance from Aunt Gracie and her spit can, but what she said that afternoon made good sense. There are some fundamentals of basic Web design that are just as applicable today as when trailblazers like Aunt Gracie were hacking their way through the electronic underbrush…

The article is broken into 2 parts:

Part 1: The Essentials

Part 2: Looking Good

Part 1: The Essentials

Definition of a good Web site: A site that delivers quality content for its intended audience and does so with elegance and style. — DevX’s Project Cool

The rule of "Keep it Simple, Stupid" is tried and true, but it’s not a be-all end-all of Web design. Gamers, for example, expect a busy page with a lot of sophisticated graphics, Flash effects, and the like. The usual understated page with the off-white background and the typical menu of links sedately trundling down the left side of the display leaves this audience cold; obviously the people who designed this Website aren’t on their wavelength — these guys like plenty of whizz-bang in the pages they visit.

On the other hand, when Aunt Gracie goes on the Web to hunt down some nice dinnerware, she isn’t going to want jazzy Flash effects, purple-on-black color styles, and a raft of animated graphics doing gymnastics in front of her rheumy old eyes. She’s been known to take a stick to the monitor to make it all stop. Corporate users expect something that might not necessarily be "buttoned-down," but certainly something solid and professional that reflects positively on their business and compares well with the competition. Personal home pages want an emphasis on the personal — the site should reflect the interests and personality of the owner.

Target Your Audience – Visually

The key here is to know who is going to be using your page, and to design with their needs and desires in mind. The KISS rule is a good one in most cases. If you don’t need something — a frame, an animated graphic, a Flash animation, a fancy DHTML effect — don’t use it. On the other hand, you don’t want a page with all the appeal of last week’s oatmeal, either; a bland, uninteresting page full of unbroken blocks of text with a drab color scheme and dreary graphics won’t attract anyone’s attention. Everything in moderation, folks… including moderation. Consider your audience first and last, and craft your site accordingly.

Every image that moves or blinks draws your visitors’ attention to itself. Be sure that it doesn’t distract them from your message. — Navarro and Khan

Whatever your site’s reason for being, you want to portray an image that conveys what your site is all about as well as the feelings you want to engender in your audience. It’s no coincidence that most financial sites use design and graphical tactics to give a feeling of rock-solid stability, calm, unworried affluence, and old-fashioned values. No matter what the stock market does, this site won’t have its feathers ruffled. In contrast, the ultra-hyper site design of the Nickelodeon and Cartoon Network sites appeal to their sugared-up audience of pre-teens and teenagers; you can’t overstimulate that crowd. A site selling luxurious lingerie isn’t going to use the same design scheme as a site selling outdoor gear for folks who want to go trekking through the outback. One will go for frothy, comforting pastels and gauzy, languid design, while the other will use a rough-hewn design scheme with logos seemingly carved of granite, and not a pastel in sight.

A good Web designer will be able to design all four sites, and others as well. Don’t forget, if you’re designing a Website for a corporation or business, that they very likely have trademarks, logos, color themes, and other elements that will need to be included in your design scheme. As Mary E. Carter reminds us, "Color communicates subtle, but important ‘information’ about your site long before people read its content." Carter also provides us with a most useful set of color palettes that evoke specific moods. Check it out!

Appealing to Multiple Audiences

If you’re trying to design a page that will appeal to both Aunt Gracie and her hyperactive, video-addicted grandson, then you’re going to have to make some compromises that could possibly alienate both audiences. You may want to consider refining your site to appeal to a narrower audience, or you may even choose to mount separate pages with different design philosophies for different audiences. In this case, you might do well to produce an introductory, or "doorway," page with links to the "whizz-bang" and the "sedate" pages — the content might essentially be the same, but the design style would be dramatically different.

Consider Connections

And don’t forget what your audience uses to access your site. Not everyone has a broadband or T1 connection; most of the world still limps along with slow dial-up connections, or must flounder around the Net through a maze of network connections. These folks appreciate your limiting your usage of big, slow-loading graphics, or at the least, providing thumbnails that automatically load and allow them to click for a bigger (and slower-loading) display. Remember, .JPG graphics are generally bigger than either .GIFs or .PNGs (Flash animations, surprisingly enough, load fairly quickly considering their complexity, but they can slow down a page, particularly one accessed over a dial-up connection). Complex table structures can take a while to load, too, especially if they’re larded with graphics. Slow servers cause slow downloads; if your provider can’t get your site up to speed, switch to someone who can.

Design for the World Wide Web is a balancing act between the graphic "wow" and the real-time "now." — Toni Will-Harris

"Elegance" is a favorite term to describe good, clean Web design, but what it actually means is up to the interpretation of the designer and the site user. To me, the term as it applies to the Web implies a certain grace and restraint of design, with well-chosen colors and graphical choices that don’t assault the eye, but instead invite the visitor to relax and enjoy the content. It’s the difference between being wooed over a candlelight dinner and being mugged in the elevator.

As the folks at Project Cool remind us, "clean design plus a good use of technology equals a good Web site." Another, equally applicable slogan: "less is more." Even the most hyperactive Playstation addict appreciates clean design, though his standards may differ from yours, mine, or Aunt Gracie’s.

What Flavour of HTML Should You Choose?

Every Web page conforms to a version of HTML (or XHTML, or even XML, though we’re not going into those here), and is determined by the DOCTYPE (document type) code. The line:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

at the top of your page (above the initial <HTML> tag) covers your bases in most cases. It supports many of the elements of the latest version of HTML, 4.01 Strict, supports style sheets for the most part, but also supports most deprecated or no longer current HTML elements, frames, link targets, and other attributes not allowed in by-the book HTML 4.01. This document type also keeps older browsers such as Netscape 4.x in the game. If you’re designing to the latest HTML standards and/or using sophisticated style sheets, then this doctype:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"    
"http://www.w3.org/TR/html4/strict.dtd">

should be used, but be aware that a lot of older browsers won’t display your page properly. Neither can you use frames unless you use the "frameset" version of this doctype. Note, too, that the "transitional" DOCTYPE I cite doesn’t include the URL of a DTD, or document type declaration. This is because using URLs in a DOCTYPE element sends some browsers, including IE, into Strict mode, defeating the purpose of the "transitional" DOCTYPE.

Of course, you could just slide bare-cheeked on the ice and use no doctype in your pages at all (just use the <HTML></HTML> tag), but that’s not a good solution. That leaves the individual’s browser to choose how to display the page, and while most browsers will cope just fine with the situation, some will gag. Besides, you need to get into the habit of using a DOCTYPE element. If you don’t know a DOCTYPE from a typewriter, use the "transitional" doctype at the beginning of this section. If you know about the various doctypes, or if you’re coding in XHTML, then make your own choice. The decision to use the "transitional" doctype is safe and conservative, but it’s certainly not an up-to-date choice. If you want to ensure that your Web page is ready for modern browsing and will be compliant with current and upcoming Web standards, you’ll need to learn about CSS (Cascading Style Sheets), HTML 4.01, and XHTML.

Note: You can visit the W3C Validator to check your document for compliance with W3C standards, or use Dave Raggett’s acclaimed HTML Tidy program, now an open-source project.

Browser Compatibility

Our developers never release code. Rather, it tends to escape, pillaging the countryside all around. — Paraphrased comment from the Enlightenment Project

A few years ago, the lazy Web designer crafted his/her pages with Netscape for Windows in mind; as that was by far the most popular browser in use, designing the site for Netscape/PC users was "good enough" to catch the majority of users, and never mind the rest. Nowadays the same lazy designers make their pages for Windows and Internet Explorer, for the same reasons. Not a good approach.

Millions of Windows users still employ Netscape (or the open-source Mozilla). Many others use Opera. Some AOL users are still trundling along with their out-of-date AOL browsers, and some hard-core folks still swear by Lynx, the text-only browser (there’s also the surprisingly large contingent of users who keep graphics switched off and read only text). Then, there’s WebTV to be reckoned with. And there are differences between the Mac browsers and the Windows browsers of the same name, not to mention the Mac browsers Cyberdog, OmniWeb, Chimera, iCab, and others. There are the browsers for Linux such as Konqueror, Opera for Linux, Mozilla for Linux, and others. According to the Browser Archive at Evolt, there are well over 100 browsers out there being used by someone (well, okay, some aren’t in use anymore). Yeesh!

Why should the burgeoning Web designer care? Because your page won’t display the same from one browser to the next. The more plugged-in designer uses one method or another, either client-side or server-side, to detect what browser his/her visitor is using, and "tailors" the code they send to that particular browser. If you can do this, then be off, this section is too easy for you (probably this whole article is too easy for you!)! But if you don’t want or can’t do something so slick, what can you do to meet the needs of your various visitors with their plethora of browsers?

Basically, the best thing to do is to be aware of the HTML tags and other features and protocols that one browser will support and others won’t, and avoid them whenever possible: the infamous "marquee" and "blink" tags come to mind, as do iFrames, layers, JavaScript, style sheets, plug-ins, DHTML, and others. Some of these, such as "blink" tags and layers, are long out-of-date; others such as DHTML and JavaScript are quite current. If you do use something that is browser-specific, choose a function that isn’t critical to your visitors’ ability to view your site: an example is the neat color schemes for the horizontal and vertical scrollbars that IE provides for. Netscape users will just get the plain-Jane grey bars, but it doesn’t hurt them to not have the colored scrollbars — it doesn’t affect the way your site presents its message and handles its content. It’s a prime example of a way to "gussy up" a page for one browser that won’t affect a different browser.

What Page Features aren’t Consistent Across Browsers?

There are plenty of page features that will cause problems for one browser or another. Forms come quickly to mind, as do text size and display size (see below for more info on these two). The way you code a link can be a problem: for example, the following link will work in most versions of IE, because the browser will process the code, but most versions of Netscape will report it as a broken link:

<A HREF="go here.html">Go Here</A>

Why? Because of the white space between "go" and "here." IE will deal with it, but Netscape won’t. If you want it to work in Netscape or anything else, you have to write it as such:

<A HREF="go%20here.html">Go Here</A>

If it’s your file, go one better by renaming the file GOHERE.HTML and avoiding the whole issue.

Another example is the site that looks good in IE, Netscape/Mozilla, and even Konqueror, except that the fonts render badly in the latter. Konqueror users should be able to fix the problem on their end easily enough by clicking "Zoom In" on their browser. Your response can be to rework your page to look as good in Konqueror as in the Windows/Mac browsers, or you can let the Konqueror users handle it themselves. If you’re working on a broad-based audience of mostly Mac and Windows users, your best bet might be to let well enough alone and let the Konqueror users handle it for themselves. If you have a large component of Linux users, you might want to fix the problem so that Konqueror users don’t have to deal with the issue. It’s your call, and your audience.

As Compatible as Possible

Browser incompatibility is a huge issue, and one that’s being grappled with at all levels of the Internet. Meanwhile, you can cope by becoming aware of the plethora of HTML tags that work in one browser but don’t work in another. You can decide whether or not to use extensions, plug-ins such as ActiveX, JavaScript, and even style sheets, which don’t work well in older browsers (and can be iffy in some current browsers) but are essential in modern HTML coding. You can decide whether or not to use more up-to-date graphics such as .PNGs, which will one day become a Web standard but for now don’t work in older browsers.

Quick and dirty fix: make sure your page looks good in Internet Explorer, Netscape 4.x, Netscape 6/Mozilla, and Opera — that means downloading these browsers to your machine and testing your site in them (find the older Netscape browsers available for download at the Netscape Archive). Use features such as style sheets, JavaScript, and DHTML sparingly; if you use these features for critical elements of your page such as a navigational scheme, provide your less up-to-date visitors with a more technologically conservative alternative. Don’t use browser-specific code and expect your visitors without that particular browser to just "get over it," and don’t skirt the issue with a craven "Works best in XXX browser" label. Try to address the needs of every member of your audience, and be aware that you can’t create a site that works for everyone everywhere.

Navigation

Everyone needs to be able to find their way around your site with ease. The choices you make in providing navigational assistance on your site will often make the difference between a site that users frequent, and frequently use, and a site that gets visited once and promptly forgotten. I can’t tell you how many sites I’ve visited that offered tons of good information but were so difficult to navigate that I refused to visit that site again, choosing instead to visit an alternative site that gave me an easier, more intuitive navigational scheme (remember, on the Internet, there’s always an alternative!).

One traditional method is to use a simple table of links that march down the left side of the page. There’s absolutely nothing wrong with this design; millions of effective, well-patronized Websites use this every day. It has the advantages of usability and familiarity: we’ve seen it before, we know how it works, it’s comfortable and workable. We don’t have to sit and ponder how to move around the site, we just glance at the structure and go. But there are plenty of other choices. If you find, or concoct, an alternative that appeals to you and your audience, by all means use it.

The Psychology of Navigation

One thing to remember: the human brain sees five or less items as a single group, but when it encounters more than five items, it breaks them down into "subgroups" to process them. What this means for Web designers is that we need to keep our navigational options simple enough for easy use. "Next step" options should be as few as possible. Although it’s not always feasible to keep your navigational choices to five or less, you can usually group the options into smaller "subcategories." Five groups of five is easier to handle than a single group of twenty-five, for example.

Another, related concept is the idea of "three clicks or less" to find the desired information. Nothing frustrates a Web surfer more than having to click and click and click again in order to find whatever specific piece of information they’re hunting for. The Project Cool folks remind us that "when people get lost, they tend to surf off somewhere else instead of fighting their way around a site." Ideally, everything a surfer wants should be no more than three clicks away from the home page. Don’t forget to make it easy for them to get back to their starting point… home should never be more than a single click away.

Top Tips for Good Navigation

There are a few things to remember in designing any navigational scheme.

Make It Clear

First, it should be apparent to the first-time visitor how to move around your site without scrolling down — everything should be obvious as soon as the page loads. The first-time visitor should be able to have your page load AND be able to grasp the essential layout of your home page within 30 seconds… much more than that and they’ll fly away to find a site that’s easier to use. For users restricted to dial-up access, this means home page sizes no larger than, say, 45K.

Consider A Site Map

A separate "site map" for a larger, more extensive site is a good idea, but shouldn’t be relied upon as the main navigational tool. Many users, particularly less experienced ones, don’t employ site maps. Many don’t even know what a site map is, nor do theycare to find out. And since it must be accessed through the main page by a click, it will always function as a supplemental method of navigation, not the main method.

You should make sure that your site map is easily accessible through a link or button labeled "Site Map" (surprise!), and that your map makes it easier, not more difficult, to navigate your site. Your site map should be much simpler in design than your regular pages, eschewing graphics and effects in favor of simple, easily used text links. The idea behind a good site map is to provide the user with a single overview of the navigational scheme and informational structure of your site. Keep these especially simple and easy to use; don’t make the user work to figure out how the map functions.

Include Site Search

Another good idea is to make your site searchable within itself. Search functions allow the user to find what they’re looking for outside of your navigational framework, as well as giving them an "out" when they get turned around. Most users know to look for "the little box that they can type in," so give them just that, preferably labeled "Search This Site" or something similar.

Keep the search parameters simple, as many users refuse to learn advanced search query techniques. "Scoped" search techniques (limiting searches to specific areas of your site) and other "advanced" search functions are useful for some users and confusing for others. Most users want to be able to find what they’re looking for with a simple onoe- or two-word query; let them do just that.

Navigational No-Nos

Some common navigational "no-nos" have been floating around the Web for as long as people have been designing Web pages. Many of them are still valid, while others have become outdated and less applicable. Here are a few, based largely on the observations of Web design guru and curmudgeon Jakob Nielsen:

Frames

This used to be the great "bugbear" of Web navigation. I hate frames, you hate frames, we won’t visit sites that use frames. Well, that’s not true any longer. The old versions of Netscape and MSIE both handled frames quite poorly, but the problems in these browsers’ frame handling have long since been fixed, so frames aren’t the no-no they used to be. Still, frames can be a bit clumsy to work with, so while it isn’t necessarily a design faux pas to use frames, it’s a good idea not to use them unless you absolutely have to. Usually a well-thought out table structure works better for most sites than frames. Note I said "usually," not "always." There are times when frames work very well, particularly if you want to keep a header or navigational structure always visible.

Other sites that use frames are sometimes badly behaved enough to "trap" your page within their frames. To keep this from happening, use this simple META tag:

<META HTTP-EQUIV="Window-target" CONTENT="_top">

For more about using META tags, see the first installment of this column, Top 15 META Tag Tricks.

Make sure every page on your site has this tag in its <HEAD> section. And don’t let your page "trap" other folks’ pages. It’s bad design and downright rude

Unusable Back Buttons

The Back button on the browser is the second most used navigational tool after the hyperlink. Nielsen calls it "the lifeline of the Web user" and points out, correctly enough, that "users happily know that they can try anything on the Web and always be saved by a click or two on Back to return them to familiar territory." However, some Web designers yank the Back button away from us. Either they have all of their pages open in new windows, they employ an "immediate redirect" that effectively cripples the Back button by sending the surfer back to a page that bounces them forward again (very, very annoying), or they prevent caching so that using the Back button forces a new download from the server.

Nielsen really doesn’t like links that force a page to open in a new window; I’m not so adamant on the issue. There are times when it’s appropriate and desirable for a link to open a page in a new window, though personally, I prefer to make my own choice by right-clicking a link and choosing the "Open in New Window" option when I want it in a new display. It is true that littering a surfer’s machine with one new browser window after another can confuse and annoy a surfer, especially a novice, and can make it difficult for the inexperienced surfer to navigate their way back along their trail, especially one who is viewing your site in Full Screen mode. Multiple browser windows also eat up system resources, and can even crash a surfer’s machine. And don’t forget that folks who use Mozilla, Opera, and any number of Internet Explorer add-ons have their own "tabbed" navigation bars that let them view multiple pages in a single window.

The best advice I can offer is to think long and hard about why you’re having your links open in new windows. If you can’t come up with a good reason, then stick to having your links come up in the same window, and let the surfer decide how they want to view your linked pages.

Long Download Times

Still a tremendous problem on many sites. Originally the cause was large graphics, or large numbers of smaller graphics, that prevented a page from displaying. Later on the problem manifested itself in complex table structures (particularly the page that is contained completely within a single huge table, requiring the whole thing to load before anything displays), sound files, Java applets, and other Web features that slowed a page’s loading time. Slow servers are also a common culprit.

Whatever the reason, most surfers won’t wait more than a few seconds for something to come up. They don’t care to wait for that cool Java effect or for your host’s slow server to do its thing; if something doesn’t come up almost immediately, they’re clicking out to find something that does come up. This is doubly true for the legion of Web users that are stuck using dial-up connections.

Fancy Menu Options

The DHTML and JavaScript menus that "extrude" or pop-up from a single link when mouseovered can be very striking and effective, but if they block the view of your page’s content, then they become as much of a hindrance as a purposeful addition. Be careful where you position them, and test them thoroughly on different browsers (and remember, older browsers may not render these properly, so don’t rely on these as your only navigational choice).

Complex URLs

This used to be a problem in the wild and woolly days of the Web. Today many users hardly pay any attention to URLs, letting their browser handle the task of remembering a bookmarked site and relying on features such as IE’s AutoComplete to deal with long URLs. Most sites also have some kind of navigation support as well, so remembering a long URL isn’t the chore it used to be. Still, shorter is better.

Orphaned Pages

These are pages that don’t have navigational links in their content — once you’re there, you can’t get out without using your "Back" button, assuming the page didn’t open up in a fresh window, or worse, you’re forced to type a fresh URL. Again, not nearly the problem it used to be, as most experienced surfers know how to lop off the end of a problem URL to get back to the home page. But again, it annoys experienced users and absolutely befuddles novices. Remember how dependent the less experienced user is on the "Back" button (see above) as well as on big, friendly buttons that take them back to your home page with a single click. Besides, "orphaned" pages are just bad design.

Non-Standard Link Colors

Okay, sometimes we get sick of the usual color scheme of blue-red-purple for hyperlinks. The thing to remember is that it’s a standard that everyone recognizes. If you’re going to change your site’s link color scheme, go ahead, but remember, your scheme should be as easily recognizable and usable as the standard. Most Web designers aren’t enamored of the traditional underlining of links, and understandably so — it looks untidy, it can be disruptive while reading through large blocks of text, and, well, we just don’t like ‘em. It is, however, worth remembering that color-blind surfers often like underlined links, as do surfers who prefer text-only displays. It’s also notable that underlining words that aren’t links confuses many surfers. But get rid of the underlining if you like (it’s the first CSS effect most of us learn).

Do remember, though, that links need to stand out somehow, and having them in a different color is usually the best bet. Few surfers set their browsers to ignore your link color choices in favor of their own, so most of us are at the mercy of your color choices. Be kind. Give us something distinctive that doesn’t intrude. Also keep in mind that for the vast majority of surfers, a text block in blue means that it’s a hyperlink; don’t fool us by coloring non-linked text blue.

A few personal observations: I don’t particularly like "mouseover" links that go to boldface (for example) when I hover my cursor over them. They make the text jump. However, when they’re carefully designed, they can work very well. I really don’t like links that are the same color as the rest of the text; I want to know a link is a link by looking at it. And I’ve grown tired of the links that are highlighted with a yellow (or red, or green, or whatever) box. Maybe it’s just me, but I get tired of reading a page that looks like one of my college texts after I’ve taken the highlighter pen to it.

Non-Standard use of GUI Features

This includes the "radio" buttons that don’t require the clicking of an OK button to take effect, the dropdown menus that sometimes require a Go button to function and sometimes don’t, and so forth. There’s no hard-and-fast rule to follow here, but keep in mind that consistency equals ease of use. In most cases, people like things to work in the fashion that they’ve grown to expect. Don’t have your GUI features work differently than the accepted standards just because you can; make sure that your features work in an easily understandable fashion.

Sites that are Unclear as to their Purpose

What’s your site about? Is it trying to sell me a car, giving me advice on fixing my computer, promoting your political viewpoint, or showing off your cats? Whatever it is, let the site visitor know immediately what your site is there to do. If they have to wonder what they’re doing on your site and what your site is there to offer, chances are they won’t stick around long enough to hunt down the answer. For commercial sites in particular, a one-sentence "tagline" that catches the first-time viewer’s attention off the bat is an essential.

"Splash" Pages

These are the initial pages that typically load a single graphic or text block that require the visitor to "click through" to get to the main page. Personally, I can deal with splash screens if they’re used in moderation and with style and grace, but the effect can become tiresome very quickly. Repeat visitors don’t want to click through the splash screen time and time again; while some (not all) first-time visitors may not want to click through the doorway page to get to the content. And many visitors who come to your site through a search engine may miss the splash page altogether.

Nielsen calls splash pages "a sure sign of bad Web design;" I don’t take such an absolute view, but they are usually an example of "too much sizzle and not enough steak." Probably the best caveat from my experience is the fact that when I visit a site that uses a splash page, I don’t bookmark that page, but the "main" page behind the splash screen. And splash pages that use big, often slow-loading Flash displays are doubly troublesome. Navarro and Khan remind us that for a business, the splash page should act as "the storefront to your Website." It should invite the visitor inside, not chase them off.

Pages with No URL

Script-driven sites make it difficult to bookmark specific pages, instead requiring the repeat user to go to the home page and "start from scratch" every time they want to drill into the site’s subpages. While there are instances where this is a necessity, it can put surfers off of returning to your site.

Misleading or Badly-Titled Bookmarks or Favorites

The standard for bookmarking is for a page to use the title from the META "Title" tag as the bookmark description. If a title is tremendously long and crammed with buzzwords and sales chatter, then the person who bookmarks the page won’t recognize the page from the title and will have to rename it to something they find useful. And sometimes other pages "hijack" linked pages with their own titles when bookmarked — a no-no in every sense of the word. If your title begins with "The" or "Welcome to…," then your page gets bookmarked under "T" or "W" with all the other pages that begin the same way. Your title should be short, descriptive, and useful in someone’s bookmark listing.

Linking to Non-HTML Pages Without Warning

It’s fine to link to a .TXT, .DOC, or .PDF file, but please let me know what I’m about to link into. If I don’t have Acrobat Reader or a .DOC-friendly word processor installed, then I can’t use the document to which you’re sending me. And such a document loading into my browser may cause unlooked-for behaviors that can be confusing or even scary for a novice user. There’s no problem linking to these documents, but warnings should always be provided. It’s also courteous to offer links to the software that users may need, particularly in the case of Acrobat Reader.

Making it Hard to Contact the Site Owner

This is especially important for commercial sites. Every single page should have whatever contact information is appropriate: email addresses, names and postal addresses, telephone numbers, fax numbers, whatever. Don’t just have a clickable graphic that says "email me!;" have the contact information plainly written in text. Someone who saves your page to disk or prints your page may not be able to click the graphic to find out the email address. The site’s main URL should also be readily available on every page.

Background Colours

The operative word here is "background:" something nice and unobtrusive for your text and graphics to sit upon without drawing attention to itself or getting in the way. If you choose a background color, remember that your text has to be readable atop it — some color choices not only strain the eyes, but challenge the monitor’s ability to display colors properly. Black text on a red background sends me for the aspirin bottle (and Aunt Gracie for her stick). Orange text on a pink background works well if you’re designing a site for Barbie fans, but not too many others. Psychedelic backgrounds are okay if you think the world revolves around the Grateful Dead, but although I like the band, I don’t like the background choice, and neither do most surfers.

If you’re using a bordered background (i.e. a relatively thin left-hand column of color that repeats all the way down), that’s fine in and of itself, but remember that you don’t want your main body of text or your graphics overlapping into the border; furthermore, whatever you put in that border should not only refrain from overlapping itself, it should alos be the proper color to stand out from whatever color choice you’ve made. If you do decide to use bordered backgrounds, some easy ways to keep things tidy include the use of the <UL> tag to indent your text (don’t use the <LI> tag and you won’t get bullets or numbers) or the <BLOCKQUOTE> tag, which indents both left and right sides of the text blocks and therefore may not be what you want. Tables are another good way to keep text from creeping over into a border. And, of course, style sheets lets you set the precise amount of indentation — probably the best way to go.

Do I even need to mention animated backgrounds?

White or light-colored text on black or dark backgrounds can look "sexy" or dramatic, and I’ve seen some wonderfully done Websites with this scheme, but some surfers have trouble focusing on them. And don’t forget that a significant minority of your audience is color-blind (8% of the men and 0.4% of the women who visit your site suffer from one form or another of color-blindness). Safe Web Colours for Colour-Deficient Vision is an excellent source of information, and includes color palettes that simulate several varieties of color-blindness. A related issue is black text on a white background; while this is eminently readable, it can cause eyestrain because of the stark contrast. A dark (but not necessarily black) text on an off-white background can often ease the strain on the visitor’s eyes while keeping readability to a maximum even for color-blind or visually limited users.

Part 2: Looking Good

Part 1 of this article discussed the essentials of Web design, the different choices of HTML types, browser compatibility, site navigation, and background colors. Part 2 discusses color schemes, display sizes, text and font choices, margination, and lots more.

Color Schemes

It’s not just the surfers that suffer from headaches when they encounter certain color schemes, it’s the monitors themselves. Dark text on darker backgrounds is an example of a color scheme that can strain a monitor. If the monitor is only slightly out of calibration, the colors can "separate" and look awful.

Remember, too, that the variations between the designs and configurations of monitors and display controllers will cause colors and graphics to appear differently from one display to the next. Even the same monitor connected to different video cards will display colors and graphics differently. And the difference between Windows and Macintosh displays can cause the Web designer to develop ulcers.

What’s a Web designer to do? Well, there are some remedies, though none are perfect. First, it’s usually a safe, if outmoded, bet to stick to the traditional 216 "Web-safe" colors that display properly when viewed across different platforms. This is advice that many consider outdated, and rightly so.

From the Guru of Color Design

To quote Lynda Weinman, one of the original gurus of Web design:

"The only reason to use the browser-safe palette is if you have a concern that your Web design work will be viewed from a 256 color (8-bit) computer system. …[B]ack in 1996, the [majority] of computer users had 8-bit video cards. Today, the minority have them, so the justification for using the browser-safe palette has diminished greatly if you are developing your site for users who have current computer systems.

"There may be [a] resurgence in the need for the browser-safe palette when designing for alternative online publishing devices, such as cell phones and PDAs. Those systems are still in 1-bit (black and white) or 8-bit color. Right now, very few people are designing their Web sites to work on those systems, so the need for the browser-safe color palette is definitely downgraded to a mere shadow of its former glory."

"Browser-Safe" Doesn’t Mean What It Used to Mean

So again, the advice to stick to the old palette of 216 browser-safe colors is more to keep users with older systems happy, at the possible risk of limiting yourself unnecessarily to a very limited (and artistically unsatisfying) set of color choices. Again, know your audience. If your site is going to be used by folks who are likely to have more current systems, there’s no reason to limit your color choices — "Today, any consumer with a Gateway or iMac is going to see all the colors you can throw their way," says Weinman.

Conversely, if your site will be used primarily by people with older or more limited systems, you shouldn’t challenge them with a blaze of colors that their computers won’t handle properly. Weinman provides us with a useful Web page that shows the 216 colors sorted by value, including the hex numbers and RGB values, on her Non-Dithering Colors by Value page.

It’s also worth noting that flat-color illustrations, logos with flat colors, or displays with large single-color areas profit the most from being created in browser-safe colors, as the dithering is much more visible and annoying in these displays than, say, in photographs.

Why 216 instead of 256 colors? Depending on which source you check, it’s because the remaining 40 colors vary too much between old Mac and PC displays to be included, or because some colors are reserved for the needs of specific operating systems. And if you really want to get picky, because of the color shifts caused by some video hardware, there are really only 22 truly safe Web colors. 22 just aren’t enough, by gosh!

About half of the computer users out there use 16-bit color displays, while only 3% are stuck with the old 8-bit displays. So the need to stick to the 216 supposedly safe colors (or the 22 truly safe colors) isn’t relevant any longer. But there’s still the issue of what looks good on what displays. Here are some options, based on your decisions about who comprises your audience, and how you want to deal with the issue.

A Variety of Choices

To play it extremely safe, stick to the 22-color "really safe palette" and prepare for a challenge — how in the world do you design an attractive Web page with this selection of colors? I’m sure it can be done; I’m not so sure I could do it myself.

Play it fairly safe and stick to the traditional Web-safe palette of 216 colors. Your 8-bit users, all thirty of them, will be happy, your 16-bit users won’t notice too much color shifting if you design carefully, and most people will be fairly happy with your displays. You will find that your artistic choices are extremely limited, though.

Or you can choose not to worry about it at all. Splash colors around at will and let the devil take the hindmost. Of course, on some visitors’ displays, your site will look truly awful, but you’re not worrying about that, remember? A variant of this approach is to ignore the needs of your 8-bit users and design with the majority in mind.

A number of color resolution problems can be avoided:

  • make your .GIFs using transparent backgrounds whenever possible
  • keep your .GIFs separate from your HTML colors whenever possible
  • minimize "seams" by making .GIFs that are adjacent to HTML background colors partially transparent
  • stick to Web-safe colors for the backgrounds of pages and tables whenever possible

Keep in mind that separating .GIFs with background colors from their HTML background equivalents avoids the possibility of noticeable color shifting. Note also that .GIFs are limited to 256 colors, or an 8-bit display. .JPG graphics can use up to 16.7 million colors, or a 24-bit display.

And just to add to the confusion, users of LCD displays such as those found on notebooks and laptops (and some desktops) have contrast issues that render light colors such as silver, beige, and cream indistinguishable from white. If you think a large portion of your audience uses LCD displays, be sure to test your pages on such a display.

Whatever you decide, keep your audience in mind and test, test, test.

Remember that if people are going to print out any part of your page, they’re going to most likely print it on white paper. A large number of them are not going to bother with printing in grayscale or turn off background image printing, so keep their needs in mind, especially with pages that are largely text.

Elaborate or "busy" background images can be appealing, but they can also make it tough on the poor slob who clicks the "Print" button in their toolbar only to have their printer use up half its ink to print your background image along with your text. And white text on a dark background might not print at all on some printer settings. You might consider providing a "printable" page that eschews most of the graphics and fancy fonts in favor of an easily-read typeface on a plain white background.

Display Size

Most Web surfers out there have long since graduated from the pedestrian 640×480 resolution (display size) on their monitors. 800×600 is considered the current "default" size by many Webmasters, and plenty of folks out there view their Web pages in bigger displays — 1024×768 or even larger.

According to one source, the ‘net community is pretty evenly divided between viewing at 800×600 and 1024×768, with only 2% still working with 640×480. I’m not so sure about this figure. I can’t back this with research, but I have the gut feeling that a lot of folks — at least more than 2% — are still using a 640×480 display. Most of these people aren’t the kind of folks who post on design forums or answer ‘net surveys; they’re using older computers in their schools and local libraries, in the basements of their churches, or just don’t bother (or can’t afford) to try to keep up with the new trends in computing.

Again, it’s a matter of knowing who your audience is. Is your site likely to be used by a lot of "old-time" or less technologically aware surfers? If so, you might consider sticking with a design that works on the old 640×480 display. The majority of us, though, should design our pages for the 800×600 user. With this decision made, we can stick to some fairly simple parameters.

As a rule of thumb, your page shouldn’t be any wider than 744 pixels (759 if you’re not going to have a vertical scrollbar displayed). The initial length of a displayed page is around 410 pixels; any longer and you’ll get the scrollbar. Most surfers don’t think twice about a vertical scrollbar, but I don’t know many who appreciate a horizontal scrollbar requiring them to go back and forth along the page to see the text. It’s easy to use a simple table structure to constrain your page to fit on a display.

Be aware that using graphics that are wider than 748 pixels is going to require your viewers to scroll horizontally to see the entire graphic, as well as letting the text march off the screen, and that’s annoying. Aunt Gracie absolutely detests horizontal scrollbars. And for some reason, far too many sites are optimized for an 805-pixel width, which makes absolutely no sense to me. It’s just wide enough to force a horizontal scrollbar in an 800×600 display, but there’s no content hidden to the right. Strange, and useless.

Note: the 744 pixel width goes along with Internet Explorer 4.5 and 5 for the Macintosh. IE 5 and 6 for Windows accepts a width of 780 pixels. Netscape for Windows shows a display between 776 and 780. The recommendation of a width of 744 is the safest and most conservative choice. The initial height of 410 is a similar "safe" choice; many browsers display at a height up to 446 pixels. Additionally, users who turn off some of their topside browser toolbars have a bit more height to work with. There are other caveats, such as:

  • whether or not a particular surfer has double or outsized Windows taskbars,
  • whether or not they’re using XP (which sports a slightly larger taskbar),
  • if they have the Microsoft Office toolbar displayed,
  • if they’ve chosen to dock their toolbars along the side of their display,
  • if they’ve set their browser margins to something unusual, and
  • whether or not you’re using CSS absolute positioning.

You can’t please everyone, nor should you try, but you should err on the safe side so that almost all of your viewers can have your page displayed comfortably. An excellent source of information on browser sizing is Webmonkey’s "Sizing Up the Browsers" page; go here for lots more detailed info, including height and width recommendations for other monitor resolutions.

Another source recommends designing your page for an 800×600 display, but keeping the text portion of your site between 640×480. That makes sense.

Text Sizing and Font Choices

While it’s a design ideal for a site’s text to display in the same size no matter who views it, in the real world this just isn’t going to happen. Different browsers display text in different sizes, and more knowledgeable users commonly adjust their font display to suit themselves.

It’s unfair to use an absolute font size in your Website’s text. What looks just right to you is too big for the fellow with 20/20 eyesight and too small for Aunt Gracie and her cokebottle glasses. Let the individual control the size of the font display. If you want to make a particular block of text larger or smaller, use relative font sizes that increase or decrease the block size in relation to the user’s default font sizing. The simplest way to illustrate this is with a basic FONT SIZE command:

<FONT SIZE="+2">This line is bigger than the rest.</FONT>

This particular text block between the FONT tags will be bigger than the rest of the displayed text, but will still base itself on the user’s font size preferences. Naturally, there are other, more sophisticated ways to control font sizing.

Modern CSS protocols allow the Web designer to control the size of the text display down to the pixel. All well and good, but what if the chosen text size doesn’t suit a particular visitor’s viewing needs? The surfer has a couple of options at his/her command to change the font display, but on IE’s default toolbar, the "Size" button isn’t displayed until the user goes through the View, Customize option to get it there. How many of your site visitors know about that button?

The same surfers don’t know that they can force their browsers to display your page in a selected size. There’s also the option to let your visitors choose their own style sheet, giving them several options of font style and size, but a lot of Web designers don’t know how to do this, and a lot of site visitors don’t know how to use the option.

Font Sizing Options

There’s a few things you can do to help your visitors avoid squinting.

  1. Avoid absolute font sizes in your style sheets; instead, go with relative terms such as 120% for outsized headlines and 90% for deliberately smaller text blocks.
  2. Make sure your initial font size is reasonably large, say 10 point (12 if you’ve got a large number of senior citizens or visually limited users).
  3. Remember that text embedded within graphics isn’t affect by style sheets or font size buttons, so the user is stuck viewing the text at whatever it’s originally displayed as; if you use pictures of text, ensure that the text is big enough to be read with ease.
  4. Make sure the color contrast between the text and the background is strong enough to ensure high visibility.
  5. If you’re designing a site for older or visually limited users, consider providing them with an alternate style sheet that gives them a nice, big display.

Multiple Font Choices

Don’t forget to allow for multiple font selections; giving a single font choice is okay for those visitors with that particular font on their machine, but for those who lack it, it means that your carefully chosen font displays in whatever the default font is on that computer (usually Times New Roman on PCs and Times on Macs). And remember that the font choices on PCs and Macs are often quite different. My Windows machine lacks Helvetica, a common choice for Macs; your Macintosh might not have Arial. A good quick-and-dirty methodology is to do something like this:

For sans-serif fonts:

<FONT FACE="Verdana, Arial, Helvetica, sans-serif">

For serif fonts:

<FONT FACE="Georgia, Times New Roman, Times, serif">

Serif fonts have the little "tags," or embellishments, on the individual letters; these assist the eye in achieving "text flow," where the eye naturally glides from one letter to the next. Sans-serif fonts lack these little embellishments, and have a "cleaner" display. You choose which group of fonts you wish your text to appear in.

Using a font choice similar to the above ensures that no matter what fonts are on the user’s machine, at least your text will display in something approximating your chosen font, and you’re covered with both PC and Mac users. Again, this applies mainly to older computers; the newer ones come loaded with dozens of fonts, including the ones we’re most likely to use. Do be aware that if you choose an unusual font in which to have your text display, most users won’t have that font; their browsers will display your text in whatever default text is selected on the individual users’ machines.

One font expert, Daniel Will-Harris, recommends that Windows users choose the Georgia font over Times New Roman, as it is more optimized for the screen (Times and Times New Roman were designed for the print medium). He also recommends avoiding Arial because of its narrowness and difficulty to read on certain displays, and avoiding the Times font for the Macintosh because of its lack of italicization. He suggests using Verdana (the font used by SitePoint), Tahoma, or Trebuchet instead of Arial.

Designing for the Dyslexic Surfer

Another consideration is making your site easily usable for dyslexic visitors. There are more Netizens than you think who suffer from one form or another of dyslexia, and their needs should be taken into account. Here are a few tips to make your site more friendly for these users (note that many of these tips contribute to a cleaner, more usable Web design for everyone, and are echoed elsewhere in this article).

Like other visually limited users, many dyslexics use computer speech output technology to read the pages to them. Ensuring that your page is speech reader-friendly is essential. Make sure that all of your important information is contained within text and not in graphics, as speech readers can’t read or interpret graphic imagery.

Dyslexic users who read your page on their own don’t like confusing or "busy" navigational schemes. Flashing graphics, distracting animations, wildly varying font styles, and textured or patterned backgrounds make it tough for them to use your site. Small icons that aid in navigation are useful, as long as each icon has a text alternative and/or an ALT tag. Use a consistent and easily-grasped navigational scheme. If you use frames, provide a no-frames alternative.

Whenever possible, keep paragraphs short and focused. Limit the amount of text on each page. If this isn’t possible, provide a topic index at the top of the text so that the dyslexic reader can home in on the parts that interest him or her.

Don’t specify a particular font. Most dyslexic readers prefer a particular font and stick to that one; let their choice take precedence.

Keep all text left-justified. Text that is centered or right-justified is tough to read. Stay away from flashing or animated text. Also avoid using background images behind text, and make sure there’s a strong contrast between background color and text color.

Links within the general text are hard to use. Provide a table of links below the text block.

If you must use background music or sound effects, provide an alternative for turning it off.

Abigail Marshall from Davis Dyslexia Association International reminds us:

"Sites that are designed to be easy for dyslexics are also easy for others to use and navigate. Market research shows that most people find it harder to read on a computer screen than from printed sources, so many non-dyslexic people will appreciate the dyslexic-friendly format."

Page Margins

You wouldn’t think that setting the margins for your Web page would be any more difficult than setting the background color or the font face, but it is. Why? It’s mainly because Netscape and Internet Explorer use two different sets of commands.

Without going into detail about the various tag commands, here’s a simple way to deal with the issue. In your <BODY> tag, use the following:

<BODY marginwidth="0" marginheight="0" topmargin="0"           
leftmargin="0" rightmargin="0" bottommargin="0" ...>

The ellipsis at the end of the tag will include the rest of your BODY commands. If you want to add margins, change the zeros to a digit (remember, the first two commands control Netscape, and the last four control IE, so change accordingly).

Again, this isn’t the most sophisticated way to handle margins (CSS provides a much better way to handle margin delineation), but it works. If you know CSS, then of course you should ignore this tip and use your style sheets to handle your margins. As always, the problem with using CSS is that older browsers don’t always display style sheets correctly.

JavaScript

Remember, around 10% of Web surfers keep JavaScript disabled. Some do it for security reasons, others do it because they’ve become aggravated with bad scripting that slows their browser functions. It’s a simple matter to supply non-JavaScript users with a non-JS page; you can do it either through a redirect script in your page or by providing a "doorway" page that gives non-JS users an alternative on which to click. If you don’t choose to do this, then limit your JavaScript usage to non-essential page functions.

Easy Bookmarking

Bookmarking your page is simple enough for any visitor, but you might want to encourage the practice. Here’s a nice, simple chunk of JavaScript that you can paste into your site’s home page to allow visitors to bookmark your site, modified from a script provided as a freebie by The JavaScript Source:

<SCRIPT LANGUAGE="JavaScript">          
function addbookmark()          
{          
bookmarkurl="http://www.myhomepage.com/"          
bookmark title="My Home Page"          
if (document. all)          
window.external.AddFavorite(bookmarkurl,bookmarktitle)          
}          
</script>

Add this chunk of script to your <HEAD></HEAD> section, and add the following piece of code wherever in the body of your page you want the bookmark link to appear:

<a href="javascript:addbookmark()"><b>Bookmark           
This Page</b></a>

Now your page has a nice clickable link to allow for easy bookmarking (you’ll need to replace the http://www.myhomepage.com/ bit with the URL of your own site, of course). If you want to have your visitors click on a graphic, simply delete the <b>Bookmark This Page</b> snippet and replace it with a graphic using the <IMG SRC> tag.

Note: this is probably the simplest way to provide a clickable means to add your page to their Favorites, but it only works in Internet Explorer. There are more complicated scripts out there that will work in both Netscape and IE.

I strongly suggest that you not use some of the available methods to force visitors to change their home page to your site; if they want to change their home page, they’ll do so. SitePoint’s Matt Mickiewicz provides a neat bit of code to give them a clickable link to allow users to change their home page, reprinted below from his Innovative Marketing Ideas article:

<a class="chlnk" style="cursor:hand" HREF onClick="this.style.          
behavior='url(#default#homepage)';this.setHomePage(          
'http://www.sitepoint.com');">Click          
here to make SitePoint your default homepage</a>

Note that this provides a simple link that gives the visitor the option to reset their homepage, but doesn’t make the decision for them. And, as in the Favorites example above, you can replace the Click here to make SitePoint your default homepage text string with a graphic if you like. Other sites simply reset the home page without your permission, or use annoying popups that you have to click out of the way to proceed with your viewing. Definitely not something that Aunt Gracie appreciates.

Outdated Content

This may not be a design topic per se, but it’s still a great way to run off your audience. Keep your content updated. For some of us, that means an update every few weeks or even months. For others, it means updating a page three or four times a day, or more. Remember, too, that there’s a difference between archival content and outdated content. You want repeat visitors, so give them something new to come back for.

Copyrighting Your Site

I won’t get into the topic here (I’ve covered some aspects of Web copyrighting in an article for Sitepoint called Daylight Robbery), but you should know that anything you create for the Web can and should be noted as being copyrighted. U.S. law copyrights whatever you create as soon as you save it to a disk or upload it to a server, but it’s a very good idea to mark your materials with a copyright statement something like the following, which should ideally go at the bottom of every page you author:

Copyright 2003 Michael Tuck. All Rights Reserved.

Naturally you’ll use your name, not mine, and the appropriate year of copyright. Copyright law varies from country to country, so bone up on what the laws are in your particular part of the world.

And for the JavaScript users out there, here’s a nice snippet gleaned from SitePoint’s own Tech Times newsletter. This automatically updates the copyright notice whenever the year changes. If the given date of first copyright isn’t 1998, just change it to suit your needs.

<SCRIPT LANGUAGE="JavaScript">          
document.write('Copyright &copy; 1998-' +(new Date()).getFullYear());          
</SCRIPT>

Thinking Twice

There are plenty of options to think about before you employ them on your page.

Music and Sound Effects

Music/audio effects are something to consider carefully before adding. HTML Goodies‘ Joe Burns tells us flatly, "There is no such thing as too little sound" on a Website, and I tend to agree with him. A lot of surfers don’t appreciate music or sound effects suddenly blaring at them from a newly loaded page, nor do they want to sit for minutes on end while a fat sound file loads. Other surfers, including yours truly, often listen to music from Internet radio or their own sources while surfing, and don’t want sound from your page intruding on their listening. And there’s always the poor cubicle rat who has to lunge for his volume control before his co-workers, or his boss, hears the sounds thundering from your page.

If you provide music and/or sound effects, let the surfer know that a sound file is coming up, and let them decide whether or not to activate it. At the very least, make it easy for them to turn it off once they’re on your page by ensuring that a control panel shows. And make the sound file load last by placing it at the bottom of your page; that way, while it’s loading, your visitors are perusing your page instead of waiting for a sound file to load.

You can go to About.com’s Background Audio Tool page to easily create a simple JavaScript code snippet for an audio file that will play automatically on your page. The advantage of this page is that the code it generates is fairly generic, which means it will work in both Netscape and IE, and you don’t have to know JavaScript to generate your own code.

The easy way to deal with the issue of sound is not to deal with it at all; i.e. don’t include it. Unless you’re running a music, gaming, or humor page, sound is usually not a necessity and almost always an intrusion. Never subject your visitors to unexpected sounds. Says Burns:

"One of the joys of Web surfing is the ability to absorb yourself with following an information thread around the global net without disturbing anyone around you. As soon as you hit unexpected sound, that joy is abruptly shattered. The page that offends in this way is not likely to be revisited!"

Fancy Techniques

Fancy techniques such as moving windows, dynamic and hierarchical menus, and other goodies have the potential to become annoying very, very quickly. And repeat visitors don’t want to see the same tricks over and over again. What seems cool or grabs someone’s attention the first time often wears thin over (a short) time. One of my pet annoyances is the navigational menu (or advertisement, or graphic) that follows me down the page no matter how I scroll. It’s effective the first time, but it wears out its welcome rather quickly. The same thing applies to the DHTML effects of snow falling over your page, hearts trailing behind your cursors, butterflies flitting around the display, etc.

Decide whether these are appropriate for your page before plugging them in, and think about how many times a visitor is going to want to deal with them before they lose their appeal. Yeah, the Flash animations and the DHTML and JavaScript menus and effects usually look great. But they can also try the patience of visitors, especially repeat visitors, and a single mistake or glitch in your JavaScript or DHTML code can cause your page to load improperly, impelling your visitors to go elsewhere. If there’s one characteristic endemic to Web surfers, it’s impatience with page problems. Whether the problem lies within the site’s code or the old, clunky browser your patron is using to visit your site, the end result is the same — they leave.

On the other hand, one fancy effect to consider is the use of "aural style sheets" and/or "Braille style sheets" to present your text to users with visual and/or hearing limitations. As of now, considering it is all you can do, as no browser I’m aware of is implementing ACSS or BCSS. But it’s such a good idea that I can’t believe it won’t appear in a forthcoming browser upgrade. It’s definitely something of which to keep abreast.

A Commercial Appearance

Your site may be frankly and unabashedly commercial. Still, if it looks like an ad site, people are going to bail out. Banner ads, pop-up windows, flashing or intrusive graphics, scrolling text, "busy’ or "loud" design, and other staples of Web advertising can turn off the average Web user faster than just about anything else you can use.

Even if you use them with restraint, most surfers routinely ignore information presented in a typical Web banner, they click out (or block) pop-ups without looking at them, and block, disable, scroll past, or otherwise get rid of annoying animations. I know Aunt Gracie gets a headache whenever a graphic flashes at her. You may not have an audience of Aunt Gracies, but you most likely have an audience that’s savvy enough to flee if you overload them with "typical" advertising behaviors. It’s worth the time and effort it will take to find an alternative (and does anyone appreciate pop-up displays that extend well past the right margin?).

Poor Spelling and Language Usage

Bad grammar and spelling is a perennial problem for even the most sophisticated sites. If you can’t spell a word or parse a sentence correctly, draft someone who can and have them go over your page with a fine-toothed comb. Don’t trust any spell-checker to do the job for you; this is one area that requires the human touch.

Again, considering your audience is paramount. Some audiences like heavy use of slang and deliberately misspelled words. Other audiences are receptive to more casual use of the language. If you’re going to deliberately use "bad" grammar and spelling, then know what level of language you’re aiming for, and use it properly. The most egregrious example I can think of is for, say, a professor of medieval literature to try to whip out a site for fans of gangsta rap music. The rap mavens will know the prof isn’t down wid dat, and go elsewhere to find a site that rings true.

If you can’t walk the walk, then don’t talk the talk. Stick to what you know, and err on the side of proper grammar.

The "Wall of Text"

If your site features a lot of copy, don’t intimidate your visitors with the notorious "wall of text." Half the reason I don’t read Dostoevsky is because I don’t want to deal with page after page of text unbroken by even a single indent. Break up those blocks with line spaces, bulleted lists, subheadings — anything that gives the reader’s eye a rest.

Remember, you’re writing for the Web, not print. Most of your visitors won’t sit in their chairs and read through every word on your page; rather, they scan what’s there, looking for something that interests them. Your text should be "scannable," which means breaking up the text blocks with some of the above features, as well as other tips such as keeping paragraphs short and based around one single idea, using the "inverted pyramid" style of information presentation (i.e. starting the paragraph with the conclusion), keeping word counts short, and avoiding "marketese" whenever possible.

Meaningful File Names

Use meaningful file names. "Page2.html" means nothing to the site visitor, while "web_fundamentals.html" means a great deal.

ALT Tags for Graphics

Use descriptive ALT tags for every graphic you employ. These tags not only keep those with graphics turned off involved, they also can display before the graphic loads, letting the visitor know what the graphic is that they’re waiting for.

Turning off IE 6′s Automatic Graphics Toolbar

Internet Explorer 6.0 for Windows displays a little toolbar at the top of any large image when you hover your mouse over it. The toolbar gives options to save, email, and print the image, along with quick access to the user’s "My Pictures" folder. A lot of surfers and Web designers don’t like this toolbar. Lucky for us it’s easy to disable by the use of a simple META tag. Just add the following META tag inside the <HEAD> tag of the page to turn off the image toolbar, like so:

<meta http-equiv="imagetoolbar" content="no" />

This tag disables the toolbar for every image on the page. If you’d rather disable it for a specific graphic image, use the galleryimg attribute for the IMG tag instead, like so:

<img src="myPic.gif" galleryimg="no" />

Quite a few savvy IE users disable this feature in their Preferences, so don’t plan on it being available to them. And the rest of us don’t have it at all, so don’t make any design choices with this toolbar’s availability in mind.

Custom Error Pages

A nifty trick that is under-utilized is to provide the visitor with a custom "Error 404" page. If they click on a link to a part of your site that is down, or mistype the URL, or make any of a hundred possible errors, then instead of getting the generic "error" page as generated by their browser, they get a personalized error page. Often these customized "404" pages provide the user with:

  • possible reasons why they got the error (i.e. typing .html at the end of the URL when your pages all end with .htm),
  • a search field for the user to find the content he or she was hunting for,
  • a link to email the Webmaster or a form to report the broken link, and most importantly,
  • a link back to the main page to give the visitor something to do besides click the Back button or simply bail out.

Customized error pages are good places to soothe your errant visitor with a little humor or reassurance as well.

All in all, customized error pages are a nice touch, and provide your visitor with an often-unexpected bit of customer service. You’ll probably need to talk to your Web host about letting you host a customized error page, unless you have access to the server. Visit Area 404 for information on customized error pages, along with some entertaining examples from other sites.

Keep Learning and Growing

And finally, keep learning. This article is by no means a comprehensive source of information; it’s just a beginning. Visit pages like Project Cool’s Sightings for some good examples of Web design, and look under the hood by going through View Source to see just how the savants worked their magic. No fair copying other people’s code, of course; this is strictly for seeing how other people pull their rabbits out of a hat, not to steal their tricks.

Want to be plunged headlong into examples of how not to design Web pages? Visit the (in)famous Web Pages That Suck, and SitePoint’s own 10 Sites That Bite. Remember, the whole reason for us to peruse these sites is to show us how not to do it!

Now that I’ve written this, I’m thinking of all the ways that my own Website fails to meet the recommendations I’ve laid out. Looks like a redesign is in order…!

Bibliography and Further Reading

10 Deadly Web Site Sins

http://www.webmasterbase.com/article/66

10 Sites That Bite

http://www.webmasterbase.com/article/160

ACSS: Aural Style Sheets

http://www.htmlgoodies.com/beyond/acss.html

Advanced Web Design: A Primer

http://www.webmasterbase.com/article/265

Area 404

http://www.plinko.net/404/area404.asp

Background Audio Tool

http://javascript.about.com/library/tools/blbgaudio.htm

Basic Color Theory

http://www.coa.edu/campuslife/work/courseprojects/polcom/colort.html

Behind the Scenes of a Website Makeover, Part I

http://www.webmasterbase.com/article/323

Behind the Scenes of a Website Makeover, Part II

http://www.webmasterbase.com/article/324

Browser Archive

http://browsers.evolt.org/

Browser Compatibility: Intro and Display Size

http://www.johngaltstools.com/learn/web/browser001.asp

Cascading Style Sheets, Level 1

http://www.w3.org/TR/REC-CSS1

CGSD – Gamma Correction Home Page

http://www.cgsd.com/papers/gamma.html

Coloring Outside the Lines

http://www.efuse.com/Design/colorful1.html

Death of the Websafe Color Palette?

http://hotwired.lycos.com/webmonkey/00/37/index2a.html

Displaying Style Sheets Dynamically

http://html.about.com/library/weekly/aa123101a.htm

Effective Web Design, Navarro and Kuhn, Sybek 1998

Getting Started

http://www.gettingstarted.net/

Home Page Design Guidelines

http://www.useit.com/alertbox/20020512.html

How to Choose the Right Fonts for Your Web Pages

http://webdesign.about.com/c/ht/00/07/How_Choose_Right_Fonts0962932995.htm

HTML Goodies to Go #216

http://www.htmlgoodies.com/letters/216.html

HTML Validation: Choosing a DOCTYPE

http://www.htmlhelp.com/tools/validator/doctype.html

HTML Web Tips: A Quick Guide to Great Web Design

http://archive.devx.com/projectcool/developer/tips/design01_tips/index.html

The JavaScript Source

http://javascript.internet.com/

Improving the 404 Error Message

http://www.useit.com/alertbox/404_improvement.html

Innovative Marketing Ideas

http://www.promotionbase.com/article/22

Let Users Control Font Size

http://www.useit.com/alertbox/20020819.html

Links That Work, Sometimes

http://www.netmechanic.com/news/vol4/html_no18.htm

Monitor Calibration and Web Color Consistency

http://tiemdesign.com/features/Oct99/web_color.htm

New Top-10 Mistakes: Reader Comments

http://www.useit.com/alertbox/990530_comments.html

Non-Dithering Colors in Browsers

http://www.lynda.com/hex.html

Page Margins

http://www.johngaltstools.com/learn/web/browser002.asp

Pick a Peck of Palettes

http://www.efuse.com/Design/palettes.html

Reading on the Web

http://www.useit.com/alertbox/9710a.html

Safe Web Colours for Colour-Deficient Vision

http://more.btexact.com/people/rigdence/colours/

Search: Visible and Simple

http://www.useit.com/alertbox/20010513.html

SitePoint: Site Design

http://www.sitepoint.com/faqs/design.php

Sizing Up the Browsers

http://hotwired.lycos.com/webmonkey/99/41/index3a.html

Site Map Usability

http://www.useit.com/alertbox/20020106.html

SitePoint Tech Times #56, 1-8-03

http://www.sitepoint.com/newsletter/viewissue.php?id=3&issue=56

SitePoint Tech Times #57, 1-22-03

http://www.sitepoint.com/newsletter/viewissue.php?id=3&issue=57

Style Sheets in HTML Documents

http://www.w3.org/TR/REC-html40/present/styles.html

Top 10 Do’s and Don’ts for Web Site Building

http://www.efuse.com/Design/top_10_do_s_and_don_ts.html

Top 10 Mistakes Revisited (originally from 1996)

http://www.useit.com/alertbox/990502.html

Top 10 New Mistakes of Web Design (1999)

http://www.useit.com/alertbox/990530.html

Top Ten Web Design Mistakes of 2002

http://www.useit.com/alertbox/20021223.html

Tough Luck: Dealing with Browser Bugs Part I

http://www.designharbor.org/Design/opentut.php3?mn=&pn=t&id=1&page=1&

Tough Luck: What To Do About Browser Incompatibility Part II

http://www.designharbor.org/Design/opentut.php3?mn=&pn=t&id=65&page=1&

The W3C MarkUp Validation Service

http://validator.w3.org/

Web Design for Dyslexia

http://www.dyslexia.com/qaweb.htm

Web Graphics for Non-Designers, Roselli, Gibbons, Forman, and Boyce, Glasshaus, 2002

Cited on http://www.webreference.com/authoring/graphics/color/nondesigners/chap2/3/

Web Type 101, A Primer

http://www.efuse.com/Design/palettes.html

Webmaster@AOL

http://webmaster.info.aol.com/

Webmonkey | Reference Chart: Browsers

http://hotwired.lycos.com/webmonkey/reference/browser_chart/

Writing for the Web

http://www.sun.com/980713/webwriting/

Working with HTML: DOCTYPE

http://developer.apple.com/internet/html/doctype.html

XHTML

http://www.w3.org/TR/1999/PR-xhtml1-19991210/

lt;br>";      
echo "<b>Responsibilities</b>: <br>$responsibilities<p>";      
}      
}      
?>      
<?      
     
// get skills      
$query = "SELECT skill, experience from r_skill WHERE      
rid = ‘$rid’ ORDER BY experience";      
$result = mysql_db_query($database, $query, $connection) or die      
("Error in query: $query. " . mysql_error());      
if(mysql_num_rows($result) > 0)      
{      
echo "<img src=images/sk.gif><br>";      
while (list($skill, $experience) = mysql_fetch_row($result))      
{      
echo "<b>$skill</b><br>";      
echo "$experience years experience<p>";      
}      
}      
?>      
<?      
     
// get references      
$query = "SELECT name, phone, email from r_reference WHERE rid = ‘$rid’";      
$result = mysql_db_query($database, $query, $connection) or die      
("Error in query: $query. " . mysql_error());      
if(mysql_num_rows($result) > 0)      
{      
echo "<img src=images/ref.gif><br>";      
while (list($name, $phone, $ref_email) = mysql_fetch_row($result))      
{      
echo "<b>Name:</b> $name<br>";      
echo "<b>Phone:</b> $phone<br>";      
if ($ref_email) { echo "<b>Email address:</b>      
<a href=mailto:$ref_email>$ref_email</a><p>"; } else { echo "<p>"; }      
}      
}      
mysql_close($connection);      
?>      
<img src="images/misc.gif">      
<br>      
<b>Willing to relocate:</b> <? if($relo == 1) { echo "Yes"; }      
else { echo "No"; } ?>      
<p>      
Resume posted on <b><? echo fixDate($posted); ?></b>      
<p>      
<a href="javascript:history.back()">Go back to applicant list</a>, or      
<a href="search.php">search again</a>      
<? include("footer.inc.php"); ?>      
</body>      
</html>      
<?      
}      
?>

Nothing too complex here - there are five main sections, and this script queries the corresponding five tables to build a data sheet containing the candidate's personal information, employment history, educational qualifications, references and skills - in effect, doing the reverse of the "apply_rslt.php" script. This data sheet has all the information an HR manager needs to get in touch with a candidate and begin the recruitment process.

Copyright Melonfire, 2000. All rights reserved.

Handling The Gray Areas

The last script - and the simplest - is the error handler, "error.php". If you look at the source code, you'll notice many links to this script; very simply, "error.php" intercepts the error and converts it to a human-readable error message, which is then displayed to the user.

<html>       
<head>      
<basefont face="Verdana" size="2">      
</head>      
<body bgcolor=white>      
<? $image="error.jpg"; ?>      
<? include("header.inc.php"); ?>      
     
There was an error accessing the page you requested. Please        
<a href="job_list.php">return to the main page</a> and try again.      
<? include("footer.inc.php"); ?>      
</body>      
</html>
Endgame

And that just about concludes this case study. Throughout this development effort, I have made widespread use of database normalization techniques, PHP's built-in functions, HTTP headers, and mySQL database queries. If you are new to PHP, I hope that the effort has been instructive, and that it has helped you gain a greater understanding of these powerful open-source tools.

If you'd like to learn more about some of the issues described throughout the course of this article, here are a few links:

Protecting Web pages with HTTP authentication: <IMG SRC> tag.

Note: this is probably the simplest way to provide a clickable means to add your page to their Favorites, but it only works in Internet Explorer. There are more complicated scripts out there that will work in both Netscape and IE.

I strongly suggest that you not use some of the available methods to force visitors to change their home page to your site; if they want to change their home page, they'll do so. SitePoint's Matt Mickiewicz provides a neat bit of code to give them a clickable link to allow users to change their home page, reprinted below from his Innovative Marketing Ideas article:

<a class="chlnk" style="cursor:hand" HREF onClick="this.style.          
behavior='url(#default#homepage)';this.setHomePage(          
'http://www.sitepoint.com');">Click          
here to make SitePoint your default homepage</a>

Note that this provides a simple link that gives the visitor the option to reset their homepage, but doesn't make the decision for them. And, as in the Favorites example above, you can replace the Click here to make SitePoint your default homepage text string with a graphic if you like. Other sites simply reset the home page without your permission, or use annoying popups that you have to click out of the way to proceed with your viewing. Definitely not something that Aunt Gracie appreciates.

Outdated Content

This may not be a design topic per se, but it's still a great way to run off your audience. Keep your content updated. For some of us, that means an update every few weeks or even months. For others, it means updating a page three or four times a day, or more. Remember, too, that there's a difference between archival content and outdated content. You want repeat visitors, so give them something new to come back for.

Copyrighting Your Site

I won't get into the topic here (I've covered some aspects of Web copyrighting in an article for Sitepoint called Daylight Robbery), but you should know that anything you create for the Web can and should be noted as being copyrighted. U.S. law copyrights whatever you create as soon as you save it to a disk or upload it to a server, but it's a very good idea to mark your materials with a copyright statement something like the following, which should ideally go at the bottom of every page you author:

Copyright 2003 Michael Tuck. All Rights Reserved.

Naturally you'll use your name, not mine, and the appropriate year of copyright. Copyright law varies from country to country, so bone up on what the laws are in your particular part of the world.

And for the JavaScript users out there, here's a nice snippet gleaned from SitePoint's own Tech Times newsletter. This automatically updates the copyright notice whenever the year changes. If the given date of first copyright isn't 1998, just change it to suit your needs.

<SCRIPT LANGUAGE="JavaScript">          
document.write('Copyright &copy; 1998-' +(new Date()).getFullYear());          
</SCRIPT>

Thinking Twice

There are plenty of options to think about before you employ them on your page.

Music and Sound Effects

Music/audio effects are something to consider carefully before adding. HTML Goodies' Joe Burns tells us flatly, "There is no such thing as too little sound" on a Website, and I tend to agree with him. A lot of surfers don't appreciate music or sound effects suddenly blaring at them from a newly loaded page, nor do they want to sit for minutes on end while a fat sound file loads. Other surfers, including yours truly, often listen to music from Internet radio or their own sources while surfing, and don't want sound from your page intruding on their listening. And there's always the poor cubicle rat who has to lunge for his volume control before his co-workers, or his boss, hears the sounds thundering from your page.

If you provide music and/or sound effects, let the surfer know that a sound file is coming up, and let them decide whether or not to activate it. At the very least, make it easy for them to turn it off once they're on your page by ensuring that a control panel shows. And make the sound file load last by placing it at the bottom of your page; that way, while it's loading, your visitors are perusing your page instead of waiting for a sound file to load.

You can go to About.com's Background Audio Tool page to easily create a simple JavaScript code snippet for an audio file that will play automatically on your page. The advantage of this page is that the code it generates is fairly generic, which means it will work in both Netscape and IE, and you don't have to know JavaScript to generate your own code.

The easy way to deal with the issue of sound is not to deal with it at all; i.e. don't include it. Unless you're running a music, gaming, or humor page, sound is usually not a necessity and almost always an intrusion. Never subject your visitors to unexpected sounds. Says Burns:

"One of the joys of Web surfing is the ability to absorb yourself with following an information thread around the global net without disturbing anyone around you. As soon as you hit unexpected sound, that joy is abruptly shattered. The page that offends in this way is not likely to be revisited!"

Fancy Techniques

Fancy techniques such as moving windows, dynamic and hierarchical menus, and other goodies have the potential to become annoying very, very quickly. And repeat visitors don't want to see the same tricks over and over again. What seems cool or grabs someone's attention the first time often wears thin over (a short) time. One of my pet annoyances is the navigational menu (or advertisement, or graphic) that follows me down the page no matter how I scroll. It's effective the first time, but it wears out its welcome rather quickly. The same thing applies to the DHTML effects of snow falling over your page, hearts trailing behind your cursors, butterflies flitting around the display, etc.

Decide whether these are appropriate for your page before plugging them in, and think about how many times a visitor is going to want to deal with them before they lose their appeal. Yeah, the Flash animations and the DHTML and JavaScript menus and effects usually look great. But they can also try the patience of visitors, especially repeat visitors, and a single mistake or glitch in your JavaScript or DHTML code can cause your page to load improperly, impelling your visitors to go elsewhere. If there's one characteristic endemic to Web surfers, it's impatience with page problems. Whether the problem lies within the site's code or the old, clunky browser your patron is using to visit your site, the end result is the same -- they leave.

On the other hand, one fancy effect to consider is the use of "aural style sheets" and/or "Braille style sheets" to present your text to users with visual and/or hearing limitations. As of now, considering it is all you can do, as no browser I'm aware of is implementing ACSS or BCSS. But it's such a good idea that I can't believe it won't appear in a forthcoming browser upgrade. It's definitely something of which to keep abreast.

A Commercial Appearance

Your site may be frankly and unabashedly commercial. Still, if it looks like an ad site, people are going to bail out. Banner ads, pop-up windows, flashing or intrusive graphics, scrolling text, "busy' or "loud" design, and other staples of Web advertising can turn off the average Web user faster than just about anything else you can use.

Even if you use them with restraint, most surfers routinely ignore information presented in a typical Web banner, they click out (or block) pop-ups without looking at them, and block, disable, scroll past, or otherwise get rid of annoying animations. I know Aunt Gracie gets a headache whenever a graphic flashes at her. You may not have an audience of Aunt Gracies, but you most likely have an audience that's savvy enough to flee if you overload them with "typical" advertising behaviors. It's worth the time and effort it will take to find an alternative (and does anyone appreciate pop-up displays that extend well past the right margin?).

Poor Spelling and Language Usage

Bad grammar and spelling is a perennial problem for even the most sophisticated sites. If you can't spell a word or parse a sentence correctly, draft someone who can and have them go over your page with a fine-toothed comb. Don't trust any spell-checker to do the job for you; this is one area that requires the human touch.

Again, considering your audience is paramount. Some audiences like heavy use of slang and deliberately misspelled words. Other audiences are receptive to more casual use of the language. If you're going to deliberately use "bad" grammar and spelling, then know what level of language you're aiming for, and use it properly. The most egregrious example I can think of is for, say, a professor of medieval literature to try to whip out a site for fans of gangsta rap music. The rap mavens will know the prof isn't down wid dat, and go elsewhere to find a site that rings true.

If you can't walk the walk, then don't talk the talk. Stick to what you know, and err on the side of proper grammar.

The "Wall of Text"

If your site features a lot of copy, don't intimidate your visitors with the notorious "wall of text." Half the reason I don't read Dostoevsky is because I don't want to deal with page after page of text unbroken by even a single indent. Break up those blocks with line spaces, bulleted lists, subheadings -- anything that gives the reader's eye a rest.

Remember, you're writing for the Web, not print. Most of your visitors won't sit in their chairs and read through every word on your page; rather, they scan what's there, looking for something that interests them. Your text should be "scannable," which means breaking up the text blocks with some of the above features, as well as other tips such as keeping paragraphs short and based around one single idea, using the "inverted pyramid" style of information presentation (i.e. starting the paragraph with the conclusion), keeping word counts short, and avoiding "marketese" whenever possible.

Meaningful File Names

Use meaningful file names. "Page2.html" means nothing to the site visitor, while "web_fundamentals.html" means a great deal.

ALT Tags for Graphics

Use descriptive ALT tags for every graphic you employ. These tags not only keep those with graphics turned off involved, they also can display before the graphic loads, letting the visitor know what the graphic is that they're waiting for.

Turning off IE 6's Automatic Graphics Toolbar

Internet Explorer 6.0 for Windows displays a little toolbar at the top of any large image when you hover your mouse over it. The toolbar gives options to save, email, and print the image, along with quick access to the user's "My Pictures" folder. A lot of surfers and Web designers don't like this toolbar. Lucky for us it's easy to disable by the use of a simple META tag. Just add the following META tag inside the <HEAD> tag of the page to turn off the image toolbar, like so:

<meta http-equiv="imagetoolbar" content="no" />

This tag disables the toolbar for every image on the page. If you'd rather disable it for a specific graphic image, use the galleryimg attribute for the IMG tag instead, like so:

<img src="myPic.gif" galleryimg="no" />

Quite a few savvy IE users disable this feature in their Preferences, so don't plan on it being available to them. And the rest of us don't have it at all, so don't make any design choices with this toolbar's availability in mind.

Custom Error Pages

A nifty trick that is under-utilized is to provide the visitor with a custom "Error 404" page. If they click on a link to a part of your site that is down, or mistype the URL, or make any of a hundred possible errors, then instead of getting the generic "error" page as generated by their browser, they get a personalized error page. Often these customized "404" pages provide the user with:

  • possible reasons why they got the error (i.e. typing .html at the end of the URL when your pages all end with .htm),
  • a search field for the user to find the content he or she was hunting for,
  • a link to email the Webmaster or a form to report the broken link, and most importantly,
  • a link back to the main page to give the visitor something to do besides click the Back button or simply bail out.

Customized error pages are good places to soothe your errant visitor with a little humor or reassurance as well.

All in all, customized error pages are a nice touch, and provide your visitor with an often-unexpected bit of customer service. You'll probably need to talk to your Web host about letting you host a customized error page, unless you have access to the server. Visit Area 404 for information on customized error pages, along with some entertaining examples from other sites.

Keep Learning and Growing

And finally, keep learning. This article is by no means a comprehensive source of information; it's just a beginning. Visit pages like Project Cool's Sightings for some good examples of Web design, and look under the hood by going through View Source to see just how the savants worked their magic. No fair copying other people's code, of course; this is strictly for seeing how other people pull their rabbits out of a hat, not to steal their tricks.

Want to be plunged headlong into examples of how not to design Web pages? Visit the (in)famous Web Pages That Suck, and SitePoint's own 10 Sites That Bite. Remember, the whole reason for us to peruse these sites is to show us how not to do it!

Now that I've written this, I'm thinking of all the ways that my own Website fails to meet the recommendations I've laid out. Looks like a redesign is in order...!

Bibliography and Further Reading

10 Deadly Web Site Sins

http://www.webmasterbase.com/article/66

10 Sites That Bite

http://www.webmasterbase.com/article/160

ACSS: Aural Style Sheets

http://www.htmlgoodies.com/beyond/acss.html

Advanced Web Design: A Primer

http://www.webmasterbase.com/article/265

Area 404

http://www.plinko.net/404/area404.asp

Background Audio Tool

http://javascript.about.com/library/tools/blbgaudio.htm

Basic Color Theory

http://www.coa.edu/campuslife/work/courseprojects/polcom/colort.html

Behind the Scenes of a Website Makeover, Part I

http://www.webmasterbase.com/article/323

Behind the Scenes of a Website Makeover, Part II

http://www.webmasterbase.com/article/324

Browser Archive

http://browsers.evolt.org/

Browser Compatibility: Intro and Display Size

http://www.johngaltstools.com/learn/web/browser001.asp

Cascading Style Sheets, Level 1

http://www.w3.org/TR/REC-CSS1

CGSD - Gamma Correction Home Page

http://www.cgsd.com/papers/gamma.html

Coloring Outside the Lines

http://www.efuse.com/Design/colorful1.html

Death of the Websafe Color Palette?

http://hotwired.lycos.com/webmonkey/00/37/index2a.html

Displaying Style Sheets Dynamically

http://html.about.com/library/weekly/aa123101a.htm

Effective Web Design, Navarro and Kuhn, Sybek 1998

Getting Started

http://www.gettingstarted.net/

Home Page Design Guidelines

http://www.useit.com/alertbox/20020512.html

How to Choose the Right Fonts for Your Web Pages

http://webdesign.about.com/c/ht/00/07/How_Choose_Right_Fonts0962932995.htm

HTML Goodies to Go #216

http://www.htmlgoodies.com/letters/216.html

HTML Validation: Choosing a DOCTYPE

http://www.htmlhelp.com/tools/validator/doctype.html

HTML Web Tips: A Quick Guide to Great Web Design

http://archive.devx.com/projectcool/developer/tips/design01_tips/index.html

The JavaScript Source

http://javascript.internet.com/

Improving the 404 Error Message

http://www.useit.com/alertbox/404_improvement.html

Innovative Marketing Ideas

http://www.promotionbase.com/article/22

Let Users Control Font Size

http://www.useit.com/alertbox/20020819.html

Links That Work, Sometimes

http://www.netmechanic.com/news/vol4/html_no18.htm

Monitor Calibration and Web Color Consistency

http://tiemdesign.com/features/Oct99/web_color.htm

New Top-10 Mistakes: Reader Comments

http://www.useit.com/alertbox/990530_comments.html

Non-Dithering Colors in Browsers

http://www.lynda.com/hex.html

Page Margins

http://www.johngaltstools.com/learn/web/browser002.asp

Pick a Peck of Palettes

http://www.efuse.com/Design/palettes.html

Reading on the Web

http://www.useit.com/alertbox/9710a.html

Safe Web Colours for Colour-Deficient Vision

http://more.btexact.com/people/rigdence/colours/

Search: Visible and Simple

http://www.useit.com/alertbox/20010513.html

SitePoint: Site Design

http://www.sitepoint.com/faqs/design.php

Sizing Up the Browsers

http://hotwired.lycos.com/webmonkey/99/41/index3a.html

Site Map Usability

http://www.useit.com/alertbox/20020106.html

SitePoint Tech Times #56, 1-8-03

http://www.sitepoint.com/newsletter/viewissue.php?id=3&issue=56

SitePoint Tech Times #57, 1-22-03

http://www.sitepoint.com/newsletter/viewissue.php?id=3&issue=57

Style Sheets in HTML Documents

http://www.w3.org/TR/REC-html40/present/styles.html

Top 10 Do's and Don'ts for Web Site Building

http://www.efuse.com/Design/top_10_do_s_and_don_ts.html

Top 10 Mistakes Revisited (originally from 1996)

http://www.useit.com/alertbox/990502.html

Top 10 New Mistakes of Web Design (1999)

http://www.useit.com/alertbox/990530.html

Top Ten Web Design Mistakes of 2002

http://www.useit.com/alertbox/20021223.html

Tough Luck: Dealing with Browser Bugs Part I

http://www.designharbor.org/Design/opentut.php3?mn=&pn=t&id=1&page=1&

Tough Luck: What To Do About Browser Incompatibility Part II

http://www.designharbor.org/Design/opentut.php3?mn=&pn=t&id=65&page=1&

The W3C MarkUp Validation Service

http://validator.w3.org/

Web Design for Dyslexia

http://www.dyslexia.com/qaweb.htm

Web Graphics for Non-Designers, Roselli, Gibbons, Forman, and Boyce, Glasshaus, 2002

Cited on http://www.webreference.com/authoring/graphics/color/nondesigners/chap2/3/

Web Type 101, A Primer

http://www.efuse.com/Design/palettes.html

Webmaster@AOL

http://webmaster.info.aol.com/

Webmonkey | Reference Chart: Browsers

http://hotwired.lycos.com/webmonkey/reference/browser_chart/

Writing for the Web

http://www.sun.com/980713/webwriting/

Working with HTML: DOCTYPE

http://developer.apple.com/internet/html/doctype.html

XHTML

http://www.w3.org/TR/1999/PR-xhtml1-19991210/

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

No Reader comments

Comments on this post are closed.