David W. Eaton
4848 E. Cactus Rd. - Suite 505-224
Scottsdale, Arizona 85254
Working with this relatively new technology can be enjoyable. Building a few HTML pages and posting them is not very difficult, however, crafting and maintaining a useful Web site is no small task. It takes knowledge, skill, and substantial time. Foresight and planning are the keys to success, and awareness of current trends and tools helps ensure your Web information can be read by your audience.
Be sure to allocate appropriate resources to the project and allow proper training and time to research new developments to keep a site current. Alternatively, all or part of your Web site activities could be outsourced, as is being done by companies both large and small.
Plan your site's logical layout. A simple outline is helpful when writing a paper, but the dynamics of a Web site demand more. In order for a site to be easy to navigate, not only do you need to plan its contents, but also what hyperlinks are needed and expected by your visitors. Key information buried a half dozen links away from your welcome page may never be found before frustrated users give up and assume the information's not there. While a Table of Contents can improve navigation, carefully laid out heirarchical links with appropriate cross reference links can lead readers quickly to what they need. Avoid excessive linking. It becomes distracting and makes it harder for readers to maintain their train of thought. Link new terms to pages that explain them, but resist linking every occurrence of those terms.
Plan your site's physical layout. Although logical links can ping-pong back and forth across directory and machine boundaries, you may find server configuration easier if you provide reader access authorizations based on directory structures. Try keeping material beneath a common directory entry if it requires the same authentication before it can be read. Similarly, if you have different groups providing content to different portions of your Web site, controlling author access with file system permissions will be easier if you have grouped those portions into appropriate subdirectories.
Document your intentions. Particularly if you have multiple authors and administrators, it is important to let them know your site's ground rules and objectives. This will help retain the same "look and feel" of your site across departmental boundaries. These are easier to find and reference if you make them part of a private section of your Web site with appropriate authentication configured for those who need the information.
<LINK REV="made" HREF="mailto:firstname.lastname@example.org">but it is a good idea to provide one. Since some Web users are not set up to send e-mail, they cannot use the "mailto" anchor. Thus, you may want to provide a hyperlink to a page which allows them to submit comments via a Web form, also.
Maintain your hyperlinks. This can be one of the most time-consuming and often forgotten tasks. If you decide to rearrange your site and move pages from one location to another, leave information at the old locations to direct readers to the new URLs. Even if you have corrected all the links on your own site (and we would hope you have), cached versions of your pages, individual "hotlists" or "bookmarks", and explicit links on pages at other sites may still contain the old URLs. Watch your log files and remove the re-directing pages only after references to them have dropped below a level you determine is acceptable. If you know other sites reference a page you have moved, send e-mail to alert them of the change. You might be able to determine the correct person by using your server "referer_log" to determine how people reached your pages, then read the referring pages to determine an owner. If you still are not certain who is the correct person, try mailing to "webmaster" at the domain where the page is located. Most sites honor this convention and have someone to respond to such mail.
Some off-site cross reference problems can be reduced by keeping your links pointing to the highest appropriate level of the other site and letting that site provide navigation to the lower level details. Since the overall architecture of a site changes less frequently than the names and locations of individual pages, there is less chance your links will become obsolete. You can increase the likelihood you will be notified of changes if you first seek permission from the page owner to create the link. (After all, it is usually in their best interest for readers of your page to be able to continue to find theirs.)
The on-line format should be simple and easy to follow. Appropriate use of bulleted lists rather than prose will cut size and enhance readability. (OK, I know I didn't do that here. This originally was prepared for publication where a limited ammount of page real estate was available. I appologize.) As a rule of thumb, try to keep pages to two or three screens (or less) of related information. Once the content has been written, go back and select the appropriate words to use as hyperlink anchors to related pages. This will help ensure that your content will read smoothly, yet allow those who want more detailed information to obtain it quickly. Avoid adding special words such as "click here for more info". They cause a break in the reader's train of thought. Smaller pages of focused information will make it more likely that other links to the content can be made more easily.
As you craft your pages, strive more for appropriate information structure than for a visual appearance of the page layout. Different browsers will render the components of your page in different manners. For example, some may center level 1 headings (<H1>) or make them all capital letters. Others will use a larger font size. With some software, the reader can specify the font style, size and color according to their liking. These features may be particularly important for those with vision problems or color blindness. Time spent on page layout may be lost if the reader's browser displays pages in ways you have not forseen.
For example, a brief analysis of the percentage of browsers used most often to access the InterWorks Web site over several months shows:
Netscape NCSA Mosaic Lynx Other 1996 Feb 70.1 8.1 2.4 19.4 Jan 72.5 9.7 2.9 14.9 1995 Dec 60.2 10.9 2.5 26.4 Nov 64.2 11.3 1.9 22.6 Oct 69.0 16.2 2.3 12.5 Sep 61.3 19.2 3.3 16.2The "Other" accesses to the InterWorks pages were spread across more than 15 different browsers and more than a dozen robot search engines. While it is impractical to test with each of the dozens of possible browsers, knowing which ones are used most frequently will help avoid problems for the majority of your readers. Adhering to the standards set by the World Wide Web Consortium is the best way to assure your Web page can be read by the broadest set of Web users.
Some of the most common problem areas are also some of the "flashiest":
Don't load a page down with large or excessive numbers of graphics. Keep those you do use relevant to the material and small enough to download quickly even over slower transmission lines. The Bandwidth Conservation Revival page was a good reference site for ideas concerning keeping images smaller without loosing their integrity.
Never forget that some browsers can't display graphics and some users of graphical browsers turn off graphics download until and unless they find something they really want to view. Always use the ALT attribute to provide those readers with a meaningful indication of the information they might be missing.
Consider displaying a small (in bytes as well as in screen real estate) thumbnail of a large graphic and let readers decide to select it if they want the full size image. If it is very large, provide an indication of its size beside or as part of the anchor that references the full inage.
The IMG tag allows for optional HEIGHT and WIDTH attributes, but how these are used may depend on the reader's browser. Some browsers fetch the complete text and graphics before anything is displayed. Some display all the text, leaving a place for the graphics encountered, then go back and start filling in the images. If HEIGHT and WIDTH attributes were specified, this type of browser usually allocates enough screen space for the graphics so that the page won't "jump" as the graphics files are processed.
Not all browsers treat these attributes the same, however. Some reserve the space indicated, then if the image is actually a different size they re-allocate the page for the true image size. This causes that page jump, but displays the image as it was built. Other browsers use the provided HEIGHT and WIDTH values and rescale the actual image to fit within that provided value. This is fine if that's what you wanted, but if you really provided a new image and forgot to go back and correct the HTML with the new values, some of your readers may be seeing some very strange pages.
A mis-use for this feature (that I have found used on more than a few sites) is to send a very large image, tie up the line time, then make my browser scale and dither it down to what should have been provided as a small "thumbnail" in the first place. On a re-scaling browser the visual result may be the same, but the access time is much longer. On a re-allocating browser, the reader gets to look at the giant image amidst the text, often with a note to "click here to view full size image." Please don't let this happen to your pages.
Graphics are very effective when used as image maps. The reader chooses what they want to see next by selecting the appropriate location on the screen. But be certain to provide text methods for reaching the same information or you will again loose some readership. Also, resist making a graphic which is nothing but words scattered around and used as an image map. If you don't really have a graphical presentation, use a text approach.
Equally irritating and wasteful of bandwith and reader time are graphic-only representations of a presentation designed for an overhead projector when the presentation consists of titles and bulleted lists with a fancy boarder around them. Consider providing these in a simple text form, perhaps with a small graphic logo at the top or bottom.
When you are mixing text and graphics on a single line, experiment with the ALIGN=MIDDLE attribute. This may make your page read smoother and display nicer.
Watch for emerging graphics standards. Some browsers already support the Portable Network Graphic (PNG) draft standard and others are making plans to do so.
Be certain your form is concise and easy to follow. Remember to view it with several different sized windows to be certain your reader will see what you expect. It is usually best to request specific answers from check boxes, radio buttons, or pull-down lists when possible, rather than text entry. This will make analysis and error checking easier, too.
Using explicit default selections and text entries can make it simpler on your reader, or can lead them into directions you wish they would select while still providing them alternatives.
Remembering to request the submitter's e-mail address will make it easier for you to get back to them, but expect to get quite a few that are incorrect or that at least have typos in them. Saving the user's host name as part of the response may help you detect and correct some of these typos.
Always provide feedback to your user when the submission has been completed. Echoing their selections back to the screen will allow them to print or save the entry for future reference in case they wish to follow up. If your processing script detects an error, try to be as explicit as you can. This will make it easier for them to make the correction. You may even want to have the error at the top of a regenerated form in which you supply the answers they provided. They can then make the correction and continue, rather than needing to go "back" and re-submit.
Provide an appropriate means to exit the form and proceed to some meaningful spot or at least to your welcome page.
Backgrounds are becoming more commonplace. Providing you recognize some viewers won't see them and they are not integral to the understanding of the content of your page, they should be fine. Be aware that dark backgrounds with white letters will be harder for readers to print and the printed copy may look strange. Finally, always be aware that some people try very hard to set up their browser with color schemes pleasing to them. Trying to force your color choices on them may not be welcomed. In fact, the wrong color schemes may make it impossible for a color blind person to read your page as you built it.
The proposed HTML3 attribute ALIGN="CENTER" will display as you want it to on more browsers than will the Netscape <CENTER> tag.
The HTML3 figure tag may result in lost information or double image displays on some older browsers.
Embedded image maps can show the user each URL which will be selected, but not all browsers support it yet. Provide the traditional method as well to be safe.
Browsers supporting Java applets are very limited yet. If you use Java, at least provide alternate text so the rest of your readers know where they can find the information the applet is providing.
Be prepared to invest resources, time and energy keeping up to date as this roller coaster reaches new heights and takes new turns. Most of all, enjoy the ride.
To learn how the Web can help improve business, please refer to our paper titled "Business Case for a Web Site", which is also on this Web site.