Teach Yourself Web Publishing with HTML 3.2 in 14 Days
Writing and Designing Web Pages: Dos and Don'ts
- Using the HTML Extensions
- Writing for Online
- Design and Page Layout
- Using Links
- Using Images
- Other Good Habits and Hints
You won't learn about any HTML tags in this chapter, or how to
convert files from one strange file format to another. You're
mostly done with the HTML part of Web page design; next come the
intangibles, the things that separate your pages from those of
someone who just knows the tags and can fling text and graphics
around and call it a presentation.
Armed with the information from the last five days, you could put this book down now and go off and merrily create Web pages to your heart's content. However, armed with both that information and what you'll learn today, you can create better Web pages. Do you need any more incentive to continue reading?
This chapter includes hints for creating well-written and well-designed Web pages, and highlights dos and don'ts concerning
- How to sort out the tangle of whether to use HTML 2.0 or HTML extensions or both
- How to write your Web pages so that they can be easily scanned and read
- Issues concerning design and layout of your Web pages
- When and why you should create links
- Using images effectively
- Other miscellaneous tidbits and hints
In the past, before every browser company was introducing their own new HTML tags, being a Web designer was easy. The only HTML tags you had to deal with were those from HTML 2.0, and the vast majority of the browsers on the Web would be able to read your pages without a problem. Now being a Web designer is significantly more complicated. Now, you've got several groups of tags to work with:
- The HTML 2.0 tags
- HTML 3.2 tags such as tables, divisions, backgrounds, and color, which are supported by a few but not all browsers
- Browser-specific tags (from Netscape or Internet Explorer) which may or may not end up as part of the official HTML specification, and whose support varies from browser to browser
- Other proposed HTML 3.2 tags which few to no browsers support
If you're finding all of this rather mind-boggling, you're not alone. Authors and developers just like you are all trying to sort out the mess and make decisions based on how they want their pages to look. The HTML extensions do give you more flexibility with layout, but they limit the audience that can view those pages the way you want them to be viewed.
Choosing a strategy for using HTML extensions is one of the more significant design decisions you'll make as you start creating Web pages. It might be easier for you to look at the choices you have as a sort of continuum between the conservative and the experimental Web author (see Figure 11.1).
Don't think of these endpoints as value judgments; conservative isn't worse than experimental, or vice versa. There are advantages at both ends and significant advantages in the middle.
The conservative Web developer wants the widest possible audience for her Web pages. The conservative Web developer sticks to HTML 2.0 tags as defined by the standard. This is not to say that the conservative Web developer is boring. You can create magnificent Web content with the HTML 2.0 tags, and that content has the advantage over more experimental content in that it is supported without a hitch by the greatest number of browsers and, therefore, will reach the widest possible audience.
The experimental Web developer, on the other hand, wants the sort of control over layout that the more advanced tags gives him or her and is willing to shut out a portion of their audience to get it. The experimental Web developer's pages are designed for a single browser, tested only in a single browser, and might even have a big announcement on the pages that says, "These Pages Must Be Read Using Browser X." Using other browsers to read those pages may make the design unreadable or at least confusing-or it may be just fine.
Which kind of Web developer are you? Depending on the goals of your pages and the audi-ence you're writing for, you may not need to think about this decision. If your readers are going to be seeing your pages only on an internal network using only Netscape 2.0, then that makes things easy for you; you can use all of the tags that Netscape 2.0 supports. If you're designing for an audience that may use different kinds of browsers, however (as you do for the global Internet), you'll have to come up with a strategy for which kinds of tags you'll be using.
For the latter situation, the best position in terms of choosing between interesting design and a wide audience is probably a balance between the two kinds of Web developers. With some knowledge beforehand of the effects that HTML extensions will have on your pages, both in browsers that support them and those that don't, you can make slight modifications to your design that will enable you to take advantage of both sides. Your pages are still readable and useful in older browsers over a wider range of platforms, but they can also take advantage of the advanced features in the newer browsers.
Throughout this book so far, I've explained which tags are part of HTML 2.0, which are extensions, and which tags are available in which major browsers. I've also noted for each tag the alternatives you can use in cases where a browser may not be able to view those tags. With this information in hand, you should be able to experiment with each tag in different browsers to see what the effect of each one is on your design.
The most important strategy I can suggest for using extensions while still trying to retain compatibility with other browsers is to test your files in those other browsers. Most browsers are free or shareware and available for downloading, so all you need to do is find them and install them. If you have access to a UNIX account, it's likely that the Lynx software is installed so you can use it as well. By testing your pages you can get an idea of how different browsers interpret different tags, and eventually you'll get a feel for which extensions provide the most flexibility, which ones need special coding for alternatives in older browsers, and which tags can be used freely without complicating matters for other browsers.
Writing on the Web is no different from writing in the real world. Even though the writing you do on the Web is not sealed in hardcopy, it is still "published" and is still a reflection of you and your work. In fact, because it is online, and therefore more transient to your reader, you'll have to follow the rules of good writing that much more closely because your readers will be less forgiving.
Because of the vast quantities of information available on the Web, your readers are not going to have much patience if your Web page is full of spelling errors or poorly organized. They are much more likely to give up after the first couple of sentences and move on to someone else's page. After all, there are several million pages out there. There isn't time to waste on bad pages.
This doesn't mean that you have to go out and become a professional writer to create a good Web page. But here are a few hints for making your Web page easier to read and understand.
Unless you are writing the Great American Web Novel, your readers are not going to visit your page to linger lovingly over your words. One of the best ways you can make the writing in your Web pages effective is to write as clearly and concisely as you possibly can, present your points, and then stop. Obscuring what you want to say with extra words just makes it more difficult to figure out your point.
If you don't have a copy of Strunk and White's The Elements of Style, put this book down right now and go buy it and read it. And then reread it, memorize it, inhale it, sleep with it under your pillow, show it to all your friends, quote it at parties, and make it your life. There is no better guide to the art of good, clear writing than that book.
Even if you write the clearest, briefest, most scintillating prose ever seen on the Web, chances are good your readers will not start at the top of your Web page and carefully read every word down to the bottom.
Scanning, in this context, is the first quick look your readers give to each page to get the general gist of the content. Depending on what your users want out of your pages, they may scan the parts that jump out at them (headings, links, other emphasized words), perhaps read a few contextual paragraphs, and then move on. By writing and organizing your pages for easy "scannability," you can help your readers get the information they need as fast as possible.
To improve the scannability of your Web pages:
- Use headings to summarize topics. Note how this book has headings and subheadings. You can flip through quickly and find the portions that interest you. The same thing applies to Web pages.
- Use lists. Lists are wonderful for summarizing related items. Every time you find yourself saying something like, "each widget has four elements," or "use the following steps to do this," the content after that phrase should be an ordered or unordered list.
- Don't forget link menus. As a form of list, link menus have all the advantages of lists for scannability, and they double as excellent navigation tools.
- Don't bury important information in text. If you have a point to make, make it close to the top of the page or at the beginning of a paragraph. Long paragraphs are harder to read and make it more difficult to glean information. The further into the paragraph you put your point, the less likely anybody will read it.
Figure 11.2 shows the sort of writing technique that you should avoid.
Because all the information on this page is in paragraph form, your readers have to read all three paragraphs in order to find out what they want and where they want to go next.
How would you improve this example? Try rewriting this section so that the main points can be better picked out from the text. Consider that
- There are actually two discrete topics in those three paragraphs.
- The four ingredients of the drink would make an excellent list.
Figure 11.3 shows what an improvement might look like.
Keep in mind as you write that your reader could jump into any of your Web pages from anywhere. For example, you may structure a page so section four distinctly follows section three and has no other links to it. Then, someone you don't even know might create a link to the page starting section four. From then on, a reader could very well find himself or herself on section four without even being aware that section three exists.
Be careful to write each page so that it stands on its own. These guidelines will help:
- Use descriptive titles. The title should provide not only the direct subject of this page, but its relationship to the rest of the pages in the presentation.
- If a page depends on the one before it, provide a navigational link back to the page before it (and preferably also one up to the top level).
- Avoid initial sentences like: "You can get around these problems by ," "After you're done with that, do ," and "The advantages to this method are ." The information referred to by "these," "that," and "this" are off on some other page. If those sentences are the first thing your readers see, they are going to be confused.
Use emphasis sparingly in your text. Paragraphs with a whole lot of boldface and italics or words in ALL CAPS are hard to read, both if you use any of them several times in a paragraph and if you emphasize long strings of text. The best emphasis is used only with small words (such as: and, this, or, BUT).
Link text is also a form of emphasis. Use single words or short phrases as link text. Do not use entire passages or paragraphs as links.
Figure 11.4 illustrates a particularly bad example of too much emphasis obscuring the rest of the text.
By removing some of the boldface and using less text for your links, you can considerably reduce the amount of distraction in the paragraph (Figure 11.5).
Be especially careful of emphasis that moves or changes such as marquees, blinking text, or animation on your pages. Unless the animation is the primary focus of the page, use movement and sound extremely sparingly to prevent distractions from the rest of your page.
Avoid references in your text to specific features of specific browsers. For example, don't use wording like:
- "Click Here." What if your reader is using a browser without a mouse? A more generic phrase is "select this link." (Of course, you should avoid the "here" syndrome in the first place, which neatly gets around this problem as well.)
- "To save this page, pull down the File menu and select Save." Each browser has a different set of menus and different ways of accomplishing the same action. If at all possible, do not refer to specifics of browser operation in your Web pages.
- "Use the Back button to return to the previous page." As in the previous note, each browser has a different set of buttons and different methods for going "back." If you want your readers to have the ability to go back to a previous page, or to any specific page, link them.
Spell checking and proofreading may seem like obvious suggestions, but given the number of pages I have seen on the Web that have obviously not had either, it bears mentioning.
Designing a set of Web pages and making them available on the Web is like publishing a book, producing a magazine, or releasing a product. It is, of course, considerably easier to publish Web pages than books, magazines, or other products, but just because it is easy does not mean it can be sloppy.
Thousands of people may be reading and exploring the content you provide. Spelling errors and bad grammar reflect badly on your work, on you, and on the content you are describing. Poor writing may be irritating enough that your reader won't bother to delve any deeper than your home page, even if the subject you're writing about is fascinating.
Proofread and spell check each of your Web pages. If possible, have someone else read them-other people can often pick up errors that you, the writer, can't see. Even a simple edit can greatly improve many pages and make them easier to read and navigate.
Although the design capabilities of HTML and the Web are quite limited, there's still a lot you can work with, and still quite a few opportunities for people without a sense of design to create something that looks simply awful.
Probably the best rule to follow at all times as far as designing each Web page is this: Keep the design as simple as possible. Reduce the number of elements (images, headings, rule lines), and make sure that the eye is drawn to the most important parts of the page first.
Keep that cardinal rule in mind as you read the next sections, which offer some other suggestions for basic design and layout of Web pages.
Headings are often rendered in graphical browsers in a larger or bolder font. Because of this, it's often tempting to use a heading tag to provide some sort of warning, note, or emphasis in regular text, as shown in Figure 11.6.
Headings work best when they're used as headings, because they stand out from the text and signal the start of a new topic. If you really want to emphasize a particular section of text, consider using a small image, a rule line, or some other way of emphasis instead. Figure 11.7 shows an example of the same text as in Figure 11.6 with a different kind of visual emphasis.
Grouping related information within a page is a task for both writing and design. By grouping related information under headings, as I suggested in the "Writing for Online" section earlier in this chapter, you improve the scannability of that information. Visually separating each section from the others helps to make each section distinct and emphasizes the relatedness of the information.
If a Web page contains several sections of information, find a way to visually separate those sections; for example, with a heading or with a rule line <HR> (see Figure 11.8).
When you're reading a book or a magazine, each page, each section, usually has the same layout. The page numbers are where you expect them, and the first word on each page starts in the same place.
The same sort of consistent layout works equally well in Web pages. A single "look and feel" for each page in your Web presentation is comforting to your readers. After two or three pages, they will know what the elements of each page are and where to find them. With a consistent design, your readers can find the information they need and navigate through your pages without having to stop at every page and try to find where things are.
Consistent layout can include
- Consistent page elements. If you use second-level headings (<H2>) on one page to indicate major topics, use second-level headings for major topics on all your pages. If you have a heading and a rule line at the top of your page, use that same layout on all your pages.
- Consistent forms of navigation. Put your navigation menus in the same place on every page (usually the top or the bottom of the page), and use the same number of them. If you're going to use navigation icons, make sure you use the same icons in the same order for every page.
Without links, Web pages would be really dull, and finding anything interesting on the Web would be close to impossible. The quality of your links, in many ways, can be as important as the writing and design of your actual pages. Here's some friendly advice on creating and using links.
As I've noted in this chapter and frequently in this book, link menus are a great way of organizing your content and the links on a page. By organizing your links into lists or other menu-like structures, your reader can scan their options for the page quickly and easily.
However, just organizing your links into menus often isn't enough. Make sure when you arrange your links into menus that you aren't too short in your descriptions. It's tempting to use menus of filenames or other marginally descriptive links in menus, like the menu shown in Figure 11.9.
Well, that is a menu of links, and the links are descriptive of the actual page they point to, but they don't really describe the content of that page. How do readers know what's on the other side of that link, and how can they make a decision about whether they're interested in it or not from the limited information you've given them? Of these three links, only the last (pesto.recipe) gives you a hint about what you will see when you jump to that file.
A better plan is either to provide some extra text describing the content of the file (Figure 11.10), or to avoid the filenames altogether (who cares?). Just describe the contents of the files in the menu, with the appropriate text highlighted (Figure 11.11).
Either one of these forms is better than the first; both give your reader more of a clue of what's on the other side of the link.
The best way to provide links in text is to first write the text without the links as if the text weren't going to have links at all, for example, if you were writing it for hardcopy. Then, highlight the appropriate words that will serve as the link text for links to other pages. Make sure you don't interrupt the flow of the page when you include a link. The idea of links in text is that the text should stand on its own. That way, links provide additional or tangential information that your readers can choose to ignore or follow based on their own whims.
Here's another example of using links in text (shown in Figure 11.12), but one in which the text itself isn't overly relevant-it's just there to support the links. If you're using text just to describe links, consider using a link menu instead of a paragraph. It'll be easier for your readers to find the information they want. Instead of having to read the entire paragraph, they can skim for the links that interest them.
Probably the easiest way to figure out if you're doing links within text properly is to print out the formatted Web page from your browser. In hardcopy, without hypertext, would the paragraph still make sense? If the page reads funny on paper, it'll read funny online as well. Some simple rephrasing of sentences can often help enormously in making the text on your pages more readable and more usable both online and when printed.
A common mistake that many Web authors make in creating links in body text is "here" syndrome. Here syndrome is the tendency to create links with a single highlighted word (here), and to describe the link somewhere else in the text. Here are a couple of examples (with underlining indicating link text):
Information about ostrich socialization is contained here.
Select this link for a tutorial on the internal combustion engine.
Because links are highlighted on the Web page, those links visually "pop out" more than the surrounding text (or "draw the eye" in graphic design lingo). Your reader will see the link first, before reading the text. Try it. Here's a picture of a particularly heinous example of "here" syndrome, in Figure 11.13. Close your eyes, and then open them quickly, pick a "here" at random, and see how long it takes you to find out what the "here" is for.
Now try the same thing with a well-organized link menu of the same information, shown in Figure 11.14.
Since "here" says nothing about what the link is there for, your poor reader has to search the text before and after the link itself to find out just what is supposed to be "here." In paragraphs that have lots of "here" or other nondescriptive links, it becomes difficult to match up the links with what they are supposed to link to, forcing your reader to work harder to figure things out.
So instead of a link like this:
Information about ostrich socialization is contained here.
A much better choice of wording would be something like this:
The Palo Alto Zoo has lots of information about ostrich socialization.
The Palo Alto Zoo has lots of information about ostrich socialization.
Just as with graphics, every time you create a link, consider why you are linking two pages or sections. Is the link useful? Will it give your readers more information or take them closer to their goal? Is the link relevant in some way to the current content?
Each link should serve a purpose. Link for relevant reasons. Just because you mention the word "coffee" deep in a page about some other topic, you don't have to link that word to the coffee home page. It may seem cute, but if a link has no relevance to the current content, it just confuses your reader.
This section describes some of the categories of links that are useful in Web pages. If your links do not fall into one of these categories, consider why you are including them in your page.
Thanks to Nathan Torkington for his "Taxonomy of Tags," published on the www-talk mailing list, which inspired this section.
Explicit navigation links are links that indicate the specific paths one can take through your Web pages: forward, back, up, home. These links are often indicated by navigation icons (Figure 11.15).
Implicit navigation links (Figure 11.16) are different from explicit navigation links in that the link text implies, but does not directly indicate, navigation between pages. Link menus are the best example of this; it is apparent from the highlighting of the link text that you will get more information on this topic by selecting the link, but the text itself does not necessarily say that. Note that the major difference between explicit and implicit navigation links is this: if you print a page containing both, you should no longer be able to pick out the implicit links.
Implicit navigation links can also include table-of-contents-like structures or other overviews made up entirely of links.
Word or concept definitions make excellent links, particularly if you are creating large networks of pages that include glossaries. By linking the first instance of a word to its definition, you can explain the meaning of that word to readers who don't know what it means while not distracting those who do (Figure 11.17).
Finally, links to tangents and related information are valuable when the text content would distract from the main purpose of the page. Think of tangent links as footnotes or end notes in printed text (Figure 11.18). They can refer to citations to other works, or to additional information that is interesting but not necessarily directly relevant to the point you're trying to make.
Be careful that you don't get carried away with definitions and tangent links. It's possible to create so many tangents that your readers spend so much time linking elsewhere that they can't follow the point of your original text. Resist the urge to link every time you possibly can, and link only to relevant tangents on your own text. And avoid duplicating the same tangent-for example, linking every instance of the letters "WWW" on your page to the WWW Consortium's home page. If you are linking twice or more to the same location on one page, consider removing most of the extra links. Your readers can make the effort to select one of the other links if they are interested in the information.
On Day 4, "Images and Backgrounds," you learned all about creating and using images in Web pages. This section summarizes many of the hints you learned for using images.
Be careful about including lots of images on your Web page. Besides the fact that each image adds to the amount of time it takes to load the page, including too many images on the same page can make your page look busy and cluttered and distract from the point you are trying to get across (Figure 11.19).
Remember the hints I gave you in Chapter 7, "Using Images, Color, and Backgrounds." Consider why you need to use each image before you put it on the page. If it doesn't directly contribute to the content, consider leaving it off.
And of course, as soon as I mention images, I have to also mention that not all browsers can view those images. To make your pages accessible to the widest possible audience, you're going to have to take the text-only browsers into account when you design your Web pages. Here are two possible solutions that can help:
- Use the ALT attribute of the <IMG> tag to automatically substitute appropriate text strings for the graphics in text-only browsers. Use either a descriptive label to substitute for the default [image] that appears in the place of each inline image, or use an empty string ("") to ignore the image altogether.
- If providing a single-source page for both graphical and text-only browsers becomes too much work, and the result is not turning out to be acceptable, consider creating separate pages for each one: a page designed for the full-color full-graphical browsers, and a page designed for the text-only browsers. Then provide the option of choosing one or the other from your home page.
Keep in mind if you use images that each image is a separate network connection and takes time to load over a network, meaning that each image adds to the total time it takes to view a page. Try to reduce the number of images on a page, and keep your images small both in file size and in actual dimensions. In particular, keep the following hints in mind:
- A good rule of thumb for large images is that at a 14.4Kbps modem connection, your page will load at an average of 1K per second. The entire page (text and images) should not take more than 30 seconds to load, or you risk annoying your readers and having them move on without reading your page. This limits you to 30K total for everything on your page. Strive to achieve that size by keeping your images small.
- For larger images, consider using thumbnails on your main page and then linking to the larger image, rather than putting the larger image inline.
- Interlace your larger GIF files.
- Try the tests to see whether JPEG or GIF creates a smaller file for the type of image you are using.
- In GIF files, the fewer colors you use in the image, the smaller the image will be; you should try to use as few colors as possible to avoid problems with system-specific color allocation.
- You can reduce the physical size of your images by cropping them (using a smaller portion of the overall image), or by scaling (shrinking) the original image. Note that when you scale the image, you might lose some of the detail from the original image.
- You can use the Netscape WIDTH and HEIGHT attributes to scale the image presented in Netscape to a larger size than the image actually is. Note that, of course, this works only in Netscape, and the scaled result might not be what you expect. Test it before trying it.
Many people create problems for their readers by making a couple of careless assumptions about other people's hardware. When developing Web pages, be kind and remember these two guidelines:
- Don't assume that everyone has screen or browser dimensions
the same as yours.
Just because that huge GIF you created is wide enough to fit on your screen in your browser doesn't mean it'll fit someone else's. And coming across an image that is too wide is annoying because it requires the reader to resize their window all the time or scroll sideways.
To fit in the width of a majority of browsers' windows, try to keep the width of your images to less than 450 pixels (most browsers on the Macintosh have a screen width of about 465).
- Don't assume that everyone has full-color displays.
Test your images in resolutions other than full color (you can often do this in your image-editing program). Many of your readers may have display systems that have only 16 colors, grayscale, or even just black and white. You may be surprised at the results: colors drop out or dither strangely in grayscale or black and white, and the effect may not be what you had intended.
Make sure your images are visible at all resolutions, or provide alternatives for high- and low-resolution images on the page itself.
Using HTML extensions, you can use background colors and patterns and change the color of the text on your pages. Using this feature can be very tempting, but be very careful if you decide to do so. The ability to change the page and font colors and to provide fancy backdrops can give you the ability to quickly and easily make your pages entirely unreadable. Here are some hints for avoiding this:
- Make sure you have enough contrast between the background and foreground (text) colors. Low contrast can be hard to read. Also, light-colored text on a dark background is harder to read than dark text on a light background.
- Avoid changing link colors at all. Because your readers have semantic meanings attached to the default colors (blue means unfollowed, purple or red means followed), changing the colors can be very confusing.
- Sometimes increasing the font size of all the text in your page using <BASEFONT> can make it more readable on a background. Both the background and the bigger text will be missing in other browsers that don't support the Netscape tags.
- If you're using background patterns, make sure the pattern does not interfere with the text. Some patterns may look interesting on their own but can make it difficult to read the text you put on top of them. Also, some backgrounds that look fine in lots of colors may interfere with the text when the page is viewed in a 16-color display system or in black and white. Keep in mind that backgrounds are supposed to be in the background. Subtle patterns are always better than wild patterns. Remember, your readers are still visiting your pages for the content on them, not to marvel at your ability to create faux marble in your favorite image editor.
When in doubt, try asking a friend to look at your pages. Because you are familiar with the content and the text, you may not realize how hard your pages are to read. Someone who hasn't read them before will not have your biases and will be able to tell you that your colors are too close or that the pattern is interfering with the text. Of course, you'll have to find a friend who will be honest with you.
In this section, I've gathered several other miscellaneous hints and advice about good habits to get into when working with groups of Web pages. These include notes on how big to make each page in your presentation and how to sign your pages.
Consider including a link back to the top level or home page on every page of your presentation. Providing this link allows readers a quick escape from the depths of your content. Using a home link is much easier than trying to navigate backwards through a hierarchy, or trying to use the "back" facility of a browser.
Each Web page works best if it covers a single topic in its entirety. Don't split topics across pages; even if you link between them, the transition can be confusing. It will be even more confusing if someone jumps in on the second or third page and wonders what is going on.
If you think that one topic is becoming too large for a single page, consider reorganizing the content so you can break that topic up into subtopics. This works especially well in hierarchical organizations. It allows you to determine exactly to what level of detail each "level" of the hierarchy should go, and exactly how big and complete each page should be.
There are no rules for how many pages you must have in your Web presentation, nor for how large each page should be. You can have one page or several thousand, depending on the amount of content you have and how you have organized it.
With this in mind, you may decide to go to one extreme or to another, each of which has advantages and disadvantages. For example, say you put all your content in one big page, and create links to sections within that page (as illustrated in Figure 11.20).
- One file is easier to maintain, and links within that file won't ever break if you move things around or rename files.
- Mirrors real-world document structure. If you are distributing documents both in hard copy and online, having a single document for both makes producing both easier.
- A large file takes a very long time to download, particularly over slow network connections and especially if the page includes lots of graphics.
- Readers must scroll a lot to find what they want. Accessing particular bits of information can become tedious. Navigating at points other than at the top or bottom becomes close to impossible.
- The structure is overly rigid. A single page is inherently linear. Although you can skip around within sections in the page, the structure still mirrors that of the printed page and doesn't take advantage of the flexibility of smaller pages linked in a nonlinear fashion.
Or, on the other extreme, you could create a whole bunch of little pages with links between them (illustrated in Figure 11.21).
- Smaller pages load very quickly.
- You can often fit the entire page on one screen, and so the information in that page can be scanned very easily.
- Maintaining all those links will be a nightmare. Just adding some sort of navigational structure to that many pages may create thousands of links.
- If you have too many jumps between pages, the jumps may seem jarring. Continuity is difficult when your reader spends more time jumping than actually reading.
So what is the solution? Often the content you're describing will determine the size and number of pages you need, especially if you follow the one-topic-per-page suggestion. Testing your Web pages on a variety of platforms and network speeds will let you know if a single page is too large. If you spend a lot of time scrolling around in it or if it takes more time to load than you expected, it may be too large.
Each page should contain some sort of information at the bottom of the page that acts as the "signature." I mention this briefly in Chapter 5, "More Text Formatting with HTML," as part of the description of the <ADDRESS> tag; that particular tag was intended for just this purpose.
Here is a list of some useful information to consider putting in the ADDRESS tag on each page:
- Contact information for the person who created this Web page or the person responsible for it, colloquially known as the "web master." This should include at least his or her name and preferably an e-mail address.
- The status of the page. Is it complete? Is it a work-in-progress? Is it intentionally left blank?
- When this page was last revised. This is particularly important for pages that change a lot. Include a date on each page so that people know how old it is.
- Copyright or trademark information, if it applies.
- The URL of this page. Including a printed URL of a page that is found at that same URL may seem a bit like overkill, but what happens if someone prints out the page and loses any other reference to it in the stack of papers on their desk? Where did it come from? (I've done this many times and often wished for a URL to be typed on the document itself.)
Figure 11.22 shows a nice example of an address block.
A nice touch to include on your Web page is to link a Mailto URL to the text containing the e-mail address of the Web master, like this:
Laura Lemay <A HREF="mailto:email@example.com">firstname.lastname@example.org</A>
This enables the readers of the page who have browsers that support the Mailto URL to simply select the link and send mail to the relevant person responsible for the page without having to retype the address into their mail programs.
This will work only in browsers that support Mailto URLs. But even in browsers that don't accept it, the link text will appear as usual, so there's no harm in including the link regardless.
Finally, if you don't want to clutter each page with a lot of personal contact or boilerplate copyright information, a simple solution is to create a separate page for the extra information, and then link the signature to that page, like this:
<A HREF="copyright.html">Copyright</A> and
<A HREF="webmaster.html">contact</A> information is available.
Even though the Web provides a way to create pages in new and exciting ways, some readers still like to read many things offline, on the bus, or at the breakfast table. These kinds of readers have real problems with hypertext pages because once you start using hypertext to organize a document, it becomes difficult to be able to tell your browser to "print the whole thing"-the browser knows only the boundaries of individual pages.
If you are using the Web to publish anything that might be readable and usable outside the Web, consider also creating a single text or PostScript version. You can then make that available as an external document for downloading. That enables your readers both to browse the document online and, if they want to, print it out for reading offline. You can even link the location of the hardcopy document to the start of the hypertext version, like this:
A <A HREF="ftp://myhome.com/pub/mydir/myfile.ps">PostScript version</A> of
this document is available via ftp at myhome.com in the directory /pub/mydir/
And, of course, a handy cross-reference for the hardcopy version would be to provide the URL for the hypertext version:
This document is also available on hypertext form on
the World Wide Web at the URL:
The main dos and don'ts for Web page design from this chapter are as follows:
- Do understand the differences between HTML 2.0 and HTML extensions, and decide which design strategy to follow while using them.
- Do use HTML extensions with alternatives, if at all possible.
- Do test your pages in multiple browsers.
- Do write your pages clearly and concisely.
- Do organize the text of your page so that your readers can scan for important information.
- Don't write Web pages that are dependent on pages before or after them in the structure. Do write context-independent pages.
- Don't overuse emphasis (boldface, italic, all caps, link text, blink, marquees). Do use emphasis sparingly and only when absolutely necessary.
- Don't use terminology specific to any one browser (click here, use the back button, and so on).
- Do spell check and proofread your pages.
- Don't use heading tags to provide emphasis.
- Do group related information both semantically (through the organization of the content) and visually (through the use of headings or by separating sections with rule lines).
- Do use a consistent layout across all your pages.
- Do use link menus to organize your links for quick scanning.
- Do use descriptive links.
- Don't use "here" syndrome with your links.
- Do have good reasons for using links. Don't link to irrelevant material.
- Don't link repeatedly to the same site on the same page.
- Do keep your layout simple.
- Don't clutter the page with lots of pretty but unnecessary images.
- Do provide alternatives to images for text-only browsers.
- Do try and keep your images small so that they load faster over the network.
- Do be careful with backgrounds and colored text so that you do not make your pages flashy but unreadable.
- Do always provide a link back to your home page.
- Do match topics with pages.
- Don't split individual topics across pages.
- Do provide a signature block or link to contact information at the bottom of each page.
- Do provide single-page, non-hypertext versions of linear documents.
|Q||I've seen statistics on the Web that say between 60 percent and 90 percent of people on the Web are using Netscape. Why should I continue designing my pages for other browsers and testing my pages in other browsers when most of the world is using Netscape anyhow?|
|A||You can design explicitly to Netscape if you want to; your pages are your pages, and the decision is yours. But, given how easy it is to make small modifications that allow your pages to be viewed and read in other browsers without losing much of the design, why lock out 10 to 40 percent of your audience for the sake of a few tags? Remember, with estimates of the size of the Web growing all the time, 10 percent of your readers could very well be a million people or more.|
|Q||I'm converting existing documents into Web pages. These documents are very text-heavy and are intended to be read from start to finish instead of being quickly scanned. I can't restructure or redesign the content to better follow the guidelines you've suggested in this chapter-that's not my job. What can I do?|
|A||Some content is going to be like this, particularly when you're converting a document written for paper to online. Ideally, you would be able to rewrite and restructure for online presentation, but realistically you
often won't be able to do anything with the content other than throw it online.|
All is not lost, however. You can still improve the overall presentation of these documents by providing reasonable indexes to the content (summaries, tables of contents pages, subject indexes, and so on), and by including standard navigation links back out of the text-heavy pages. In other words, you can create an easily navigable framework around the documents themselves, which can go a long way towards improving content that is otherwise difficult to read online.
|Q||I have a standard signature block that contains my name and e-mail address, revision information for the page, and a couple lines of copyright information that my company's lawyers insisted on. It's a little imposing, particularly on small pages, where the signature is bigger than the page itself!|
|A||If your company's lawyers agree, consider putting all your contact and copyright information on a separate page, and then linking it on every page instead of duplicating it every time. This way your pages won't be overwhelmed by the legal stuff, and if the signature changes, you won't have to change it on every single page.|