Here I set forth a personal "top-10" list of tips for producing quality, usable HTML web pages. (This presentation assumes you have at least some idea of what HTML is and how to prepare a web page.)
The 10 Tips:
o Keep Page Sizes Moderate
o Keep Graphics To The Irreducible Minimum
--- Avoid Unneeded Images
--- Present Needed Images Effectively
--- Avoid Java
o Use Standard HTML
o Avoid Frames
o Be Generous With Links
o Use Intra-Page Links
o Organize Logically
o Enhance The Text
o Write Well
o Validate All Your Pages
Research repeatedly shows that web users have short attention spans. If a page takes more than 10 or 15 seconds to download, a substantial majority of site visitors will abort the download and go somewhere else. Net transit and servers alone can cause several seconds of delay, so if you want visitors to read your pages, keep them short.
How short is short? A good rule of thumb is a maximum of about 40K bytes, with 60K as an absolute upper limit save in very special instances. Keep in mind that the byte total comprises both your actual HTML text and all graphics. Your text editor or HTML editor should be able to tell you the byte length of your actual HTML text (or just look at the file size in a directory listing); add to that the sizes in bytes of all images on the page to get the total.
Manifestly, what you need to do is to separate the content of your site into as many pages as reason allows. After all, the essence of HTML is that it is HyperText: you can jump your reader from place to place. Content separation and page division is simple and obvious if you design your pages logically.
As noted above, nothing loses potential site visitors faster than pages that are slow to load, and few things slow page loading so much as graphics. Now there are, on occasion, images or pictures that your page simply must show--a picture of the house on a real-estate for-sale page, for example. But the vast majority of image files sent across the internet from web sites are simply and merely decorative gewgaws that add nothing to the content of the site. For any image that you might place on a web page, absolutely, positively ask yourself "Is there any less information on this page without the image?" Not looks or pizzazz but content--real information.
Keep in mind the reason or reasons you are creating this web page: is it mainly to show off how much you think you know about HTML, or is it to convey some information? Again and again and again references and authorities point out that you will not get repeat visitors or good word of mouth reportage if you don't have solid, meaningful content, no matter how jazzy your otherwise content-short pages may be. Nor will jazz much augment the appeal of pages that do have good content (which is not to say that bad presentation cannot diminish the appeal--but "bad presentation" and "jazzy" are not antonyms; the opposite of "jazzy" is "simple").
If the content value of a web page is essentially the same without some image as it is with that image, leave it out.
If there are images that simply must be present on a web page, there are good and bad ways to present them. The two key points are these: use thumbnails and be sure to provide good ALT text.
A "thumbnail" is a very small copy of a larger image. A thumbnail is typically about the size on screen of an icon, or perhaps just a little bigger. Where an image is needed--for example, a photo of a house for sale--supply on the web page a thumbnail of that image, using that thumbnail as a click-on link to a separate page consisting wholly or mostly of the full-sized image. That way, your visitors can see at least approximately what it is that you want to show them and make up their own minds (instead of you doing it for them) whether they want to invest the needed time in downloading the full image.
It is a conventional courtesy to give--usually in the "click on the thumbnail to see the full image" instruction--a size in kilobytes for the full-sized image; if that size is large, it is also polite (since not all users can mentally translate file sizes to download times) to point out that the full-image download could take some time.
To create thumbnails, use a graphics program to make a shrunken copy of the full image. But keep in mind that a large, complex image may not be comprehensible when thumbnailed; in such instances, it is wise to first extract some smaller section of the full image, then thumbnail just that portion. The idea is for the thumbnail to give the visitor an idea of what the full image depicts, not to simply show it only smaller.
For any image you show, thumbnailed or not, always include ALT text. Such text is inserted as part of the HTML that displays the image, and instructs a browser what to display if that browser is not capable of showing images. Do not make the mistake of thinking that all browsers are graphical. Quite aside from the many web users--and they tend to be the most sophisticated web users--who really do use text-mode browsers (for the very purpose of avoiding all the useless timewasters I am discussing here), a substantial percentage of web surfers with "standard" browsers do their surfing with automatic image loading disabled. One survey, not too old, indicated that at any given moment about one in five web users were operating in a text-only mode. So be sure that if your visitors are in text-only mode, they will see something meaningful where others would see the image. Note the word "meaningful"; far too many of the page designers who do deign to use ALT text use it for really helpful stuff like image07.gif--now that really tells the visitor a lot, huh? Instead insert something like (thumbnail of property) for your ALT text, so a text-mode visitor knows what goes there (especially if the image is a click-on link!).
To repeat: never, ever include links that are click-on images without providing meaningful ALT text for the link image.
What applies to images applies in spades to Java in all its various manifestations. While there probably are actual useful ways to use Java (I say "probably" because I myself have yet to see any on a web site), assuredly 98% or more of the Java code flitting across the web has zero content value. Consider all the spinning globes, winking eyes, nodding heads, exploding words, and similar childishness you have wasted the seconds and minutes and hours of your life downloading. How did you feel about those pages' authors? There are actually software tools nowadays designed solely to block Java from web-page downloads, so widespread yet useless are such timewasters.
There is another Java issue. At least on Netscape browsers, the Java-enabling click boxes are under the submenu Security Preferences. Think about that. It is well known that there are numerous ways in which rogue hackers can do mischief and worse to a computer through web-sent Java code. Hence, many users disable all Java recognition, and many more disable at least Java Script and Java Compiler. Why try to insist that your visitors compromise their system security just so they can see a nodding head?
If you visit a web site and see a statement along the lines of This site optimized for viewing by X Browser, you know without any shred of doubt that the page creator is one of only two possible kinds of animal: a pig or a jackass. Pigs are "webmasters" for whom there is some incentive, financial or otherwise, to artificially favor one brand of browser over another; jackasses are "webmasters" who--as the modern saying goes--"just don't get it."
There exists an organization, the World Wide Web Consortium (or just W3C), comprising most or all of the leading figures in the web universe; the primary function of the W3C is to create standard specifications for HTML. At present, the standard is version 3.2 (nicknamed, for some reason, "Wilbur") but version 4.0 is already in existence. All web browsers, from any source, are supposed to be able to reliably and consistently parse HTML to a W3C standard; the more recent the browser's issue date, the higher the version level of standard HTML it will likely support (but all browsers are also supposed to be 100% backward compatible on HTML). I myself use HTML 3.2 for now because not everyone updates their browser whenever a newer version comes out. But very soon I, and all honest web-site operators, will be upgrading to HTML version 4.0 .
A chronic problem with HTML standards is that the two main browser makers--Netscape and Microsoft--are, as every child knows, engaged in a vicious struggle for market supremacy. So, what those charming folks do is build into their browsers the ability to recognize and act on certain non-standard HTML, the exact nature of which is, of course, proprietary to their brand of browser. They then alert web makers to those wonderful new "extensions" of standard HTML with the fond hope that enough "webmasters" will be foolish or venal enough to code their web pages with those "extensions" so that general users will be motivated to obtain and use the proprietary browser needed to properly see the effects of those "extensions."
Let's keep first and foremost in mind the basic truth that web pages exist to communicate information. For all the foofaraw over "multimedia" and related fads, it remains the truth that human beings beyond early childhood absorb information most readily, and far and away most commonly, by reading text. Save the occasional graphic, if really needed, a web page does not need to look like anything much different than what a portable typewriter could produce. Manifestly, the ability to enhance your text can make that text easier to read. But considering the already quite substantial range of effects, textual and otherwise, available in standard HTML, it is sheerest folly to think that any of the proprietary "extensions" are necessary or even nontrivial in presenting content on a web site.
All that use of such extensions does is precisely what their developers intended: divide the universe of web users into two opposed classes, Netscape users and Microsoft users. That is simply obscene. Design all your web pages in conformity with whatever is the prevailing W3C standard version of HTML. That way, everybody can reliably and successfully visit your site and see it as it was meant to be seen. Don't be a shill for a company unless you're literally on their payroll (and even then, be ashamed).
Don't let the numbering or order of these tips deceive you into thinking that they are in a descending rank of importance: they are all important, and this one at least as much so as any other.
Frames began as a nonstandard "extension" of standard HTML. Frames, like much of newer HTML, are scarcely necessary to well-designed web sites. But the reason to avoid them is that they can confuse site visitors more than just about anything else you can do to web pages. Use of a browser's Back button is often utterly nonintuitive when frames are used. What navigation tool to select--that is, in which frame to click--is often far from obvious; frequently, there are click-on links in two or three frames, with no very clear reason for a user to use one lot rather than another. And, perhaps above even those things, try to routinely Bookmark a framed page: it does not work. No one can Bookmark a frames page to come back to it and no one can readily provide a link to it. Nuff said?
(Providing links and setting bookmarks is not actually impossible, but it is tricksy and difficult and will be beyond the abilities of the average site visitor.)
Frames appear to get their main use by page designers who are too lazy or incompetent to build good menus or other link patterns onto their pages. By putting a "menu" frame on the side or top of the screen, they think to avoid the labor (minor, in actuality) of organizing the site logically and of thinking about how to set up intra-page links in such a way as to make life easy for their visitors. As I dearly hope this page and this site demonstrate, with even a little thought you can make it easy for your visitors to one- or two-click their way to almost anywhere on your site from just about anywhere. (For instance, on this site you are rarely if ever more than one screen length away from a [return to the page top] link, and at every page top you can [Return to the Main page], which in turn brings you to the main topic headings on that main page.)
Don't be lazy. Don't use frames.
Links are hypertext; without them, a web page is simply a screen substitute for a printed page. Whenever you know of another web site that materially augments what you have to say about something, or even that just defines terminology you presume that most (which is never all) of your readers know, drop in a link to it. That doesn't mean you should litter all your pages with links just to demonstrate that you know of them or could find them; it means make relevant use of other sites' content.
And don't hesitate to repeat links. If you at one point mention The Society To Paint Blue Cats Red and provide a link to their web site, then mention them again two or three paragraphs later, link to them again. Your readers may have reconsidered their desire to know more about the STPBCR while reading those paragraphs: don't make them go hunt up your one link to something you are mentioning several times. On the other hand, if the repeat mention is one or two sentences later, don't bother. That is, as always, use a rule of reason.
What goes for links to other sites goes all the more so for links within your own site. You should be splitting your site into a number of pages so as to keep page sizes moderate, assorting your content onto the various pages by sound logical organization of your material; when you refer to a topic you cover at length on another page, link to that coverage.
What your users will find especially helpful when following your links to other parts of your site is intra-page links; that is, don't just link to the page where you cover a topic, link to the exact spot on that page where the discussion lies.
You should be aware that a hypertext link can point not just to a given web page, but to a specific spot on that page. Such pointing requires that the page maker have embedded an HTML "named anchor" at the spot to be referenced (I am not here going to attempt to teach HTML--I am just making you aware of an important capability that exists).
(All those return to the page top links that you see throughout this site are examples of intra-page links, as are the per-page topics lists atop each page.)
Even web pages kept to a moderate page size (another intra-page link!) can be many screenfuls in length. It is a courtesy to your visitors to give them frequent chances to dodge out of their current location on the page back to some "jumping-off point" on the page or elsewhere on the site. Keep in mind that uses of intra-page links look to a browser just like a jump to another page in the sense that if users keep clicking the Back button, they will get jumped through every link they have visited--page or intra-page--in succession. That is why you want to provide them with one-click access to that jumping-off place (I prefer that to be a page-topic list at the head of the page, so--as with this page--they can either go to another topic on the page or go back to the site's main page all with just a couple of clicks).
Logic is, I suppose, comparable to musical ability in this sense: you can augment it with study and training, but at least some germ of it has to be in you to start with. I do not propose to here try to inculcate logical thinking into anyone. I do say, however, that for web sites logical organization is even more critical than it is for written documents: written documents are, as we say today, "linear" whereas web sites are hypertextual. It is essential--for holding page lengths down if nothing else--that you organize your material into distinct blocks, subdivide those blocks as required, and keep firmly in mind whatever cross-relations exist between them (for linking).
It is old-fashioned but nevertheless effective to begin as once pupils were instructed in how to compose a paper. Set down on paper (in pencil!) an outline. Follow the well-known principles of outlining which any high-school composition text can give you; above all, be sure parallel levels are topics of parallel importance.
When you go to turn your outline into a web site, be sure to make proper use of the Heading commands in HTML. Many "net robots," which visit and scan sites for search engines, use your Headings structure to generate an outline of the site--sort of "reverse engineering" your own design outline. Never use HTML Headings just to get a text enhancement effect; use Font and other similar HTML commands.
Incidentally, do not try to size paragraphs or other text blocks to neatly fit one or more screenfuls. Many visitors will be running screen resolutions different from your own; many others will have selected a different default font size. Arrange your pages by logic not apparent appearance and everyone who visits will find them satisfactory.
Many lazy or thoughtless web-page designers use graphics to try to "jazz up" their work. Such folly can, and all too often does, extend to nonsense like images of pushbuttons for links, "spectrum" bars for horizontal dividers, and images of fancy-font text. Perhaps if you are designing a site for kindergarteners such rococo may be useful in holding their preliterate attention; for anyone else, it is a waste of download time.
But that is not to say that web pages need to or should be all simple black text on a grey background or white on black or whatever. Standard HTML offers a variety of text-enhancement effects; those should be ample for any reasonable presentation need. As examples:
You can make text strong.
You can emphasize text.
You can emphasize strong text.
You can make really big text.
And you can make really small text.
You can make text of all colors of the R A I N B O W .
Best of all, unlike graphics, none of them add anything material to the page size.
Do not, however, get carried away and make displays like those just above. Web pages are about information. Use text enhancement to convey information. Color, for instance, is a pleasant and useful way to further distinguish--beyond sheer text size--between various levels of Headings (as, for example, on this site, where I work down from white at the top through brown then grey then green for progressively lower levels, except when a Head is also a link). Familiarize yourself with all the many text enhancements available in HTML, then use them in whatever scheme seems to you appropriate to help expedite the conveying of your site content.
A last thought here: ABC: Always Be Consistent. Follow out whatever text enhancement scheme you settle on with rigorous consistency from page to page. Inconsistent text enhancement can confuse a visitor worse than no use of it at all. Included in that directive is making an intelligent choice of colors for links--used and unused. While there is no formal standard for link-text coloring, it is more or less conventional to use red for unvisited links and blue for visited ones; that being so, do not use either color as a simple text enhancer lest your visitors try vainly to click on nonexistent "links" in your text.
This would seem too obvious to need mention, but even a brief experience of actual web sites will soon convince anyone that it is not. Somehow, "electronic" communication seems, at least to some minds, to relieve the writer of all responsibilities to the English language and, thereby, to her or his site visitors. If it isn't well enough written to represent you to the world if it were printed in a magazine, it isn't well enough written to represent you to the world on the internet.
If your knowledge of sound English is minimal, get a good basic textbook; the Harbrace College Handbook is as good as any. If you feel comfortable with your grasp of at least the basics of English grammar and syntax, get and peruse Wilson Follett's classic Modern American Usage. There are many, many other valuable resources and I cannot here stop to name even the rest of the more prominent, except that every English user should have a copy of that deceptively thin book The Elements Of Style by Strunk and White.
Be sure to also have to hand a good-quality dictionary. Do not make the mistake of assuming that a dictionary is a dictionary: there are huge differences in reliability. To defend one's usage or spelling by saying "The Dictionary says" is a vain defense unless the particular dictionary is accepted as reliable by those who care about such things.
And it doesn't hurt to have a good encyclopedia and atlas to hand either. Never, ever cite a "fact" you are not 100% sure of. If you have doubts about an assertion and cannot quickly verify it, express your degree of confidence in its reliability explicitly. Visitors who find one mistake often assume there are others they aren't catching and may doubt you altogether.
Be as careful and punctilious as you can in your HTML usage and you will still make errors. There is no harm in making errors if you're not being downright sloppy; harm is in not validating your pages and catching and fixing those errors.
"HTML Validation" is an automated process performed by specialized software which parses a web page in accord with a particular level of W3C HTML and reports all nonstandard uses it finds. Such third-party validation is available for free on the internet, instantly, so you have no excuses. All you need do is surf over to the appropriate site and page, enter the URL of the web page in question (which can be any page, not necessarily one of yours, if you'd like to see how horrid some of the HTML put out by most of the biggest and best-known sites really is), and wait a few seconds for the response. Then review your errors, fix them, re-upload the page, and try again. Just keep on doing that until the validator reports "no errors!"
One fine resource is the W3C's own validation site. (If you click on the W3C logo graphic which appears at the foot of every page on this site, you are simply submitting the page in question to the W3C validator.) That site also has pages with lots of helpful information and links for HTML authors.
Both of those sites can not only validate actual HTML compliance, they can also pick nits from your HTML by way of the "Weblint" parser. Weblint finds HTML usage that doesn't actually violate the W3C standards but does represent poor form or usage. Not every nit Weblint picks need be fixed in your code, but it does give you strong insights into ways to improve that code.
The one problem with validators is that when they report errors, they rarely give you much help in understanding the error; they assume that once it is pointed out, you will understand what was wrong. Here, however, is a tip: Far and away the commonest errors, other than sheer typos and similar obvious blunders, consist of putting HTML elements inside other elements that the HTML specifications do not allow to be so nested. Often, incomprehensible errors of the "not allowed here" species can be fixed by reversing the order of element nesting. As a simple example:
<FONT COLOR="#FFAAAA"> <CENTER> any old text </CENTER> </FONT>is invalid (you cannot put a Center command inside a Font area) and will generate an error, whereas--
<CENTER> <FONT COLOR="#FFAAAA"> any old text </FONT> </CENTER>is valid and will not generate an error. There are many other instances where you need to pay close attention to what is allowed inside of what else: anchors, links, headers, and effects commands are the commonest sources of headache.
Remember: just because your pages look fine in your browser doesn't mean that there are no HTML errors--browsers can be very "smart" and forgiving, but unfortunately not every browser is smart and forgiving in exactly the same way, which is why we have standards in the first place. Always validate every single web page you post. And don't forget to revalidate whenever you make any changes to a page, regardless of how "minor" they seem to you.
Comments? Criticisms? Questions? Other links to suggest?
Please, e-mail us by clicking here.
(Last updated: 27 December 1998.)
This web page is strictly compliant with the W3C
(World Wide Web Consortium)
HyperText MarkUp Language Protocol, v3.2 ("Wilbur");
click on the logo below to test us!
So, if your browser experiences any difficulties with this page,
upgrade or change that browser!