Appendix VI: Keeping Your Web Pages Robust
The following files [will] contain specific instructions for dealing with particular fragilities when using the named software. They are linked here for your convenience when returning to this page.
Designing a Web site includes three distinct but interacting phases:
Some otherwise attractive conceptual designs or visual layouts will falter in practice because of the difficulty of one or both of the other phases, especially the difficulty of communicating through terse text or compact graphics exactly what will be found if one follows a particular choice. The current design of the Ohio University Front Door has room for enhancement in this respect (e.g., many people do not immediately recognize that the Cutler Hall woodcut logo is a clickable link to the main Ohio University page).
Designing a Web site calls for the balancing of several mutually contradictory design goals! In particular:
Goals 3 and 4 are always in conflict. For example, to navigate among the 80,000-plus Web pages at Ohio University requires a minimum of 5 navigational layers, but that only works if there are a dozen choices at each layer. If the layers were simpler, with only two choices at each point, it would require 17 layers of navigation! For most Web sites, the navigational layers' pages should offer between four and ten choices.
If we follow goal 5 but don't pay attention to goals 6 and 7, we would end up with most of our audience frustrated by having to choose between using a generic home page as a starting point that requires an extra layer of navigation to reach any content pages, on the one hand, or, on the other hand, using a specific home page as a starting point that is often one click closer, but sometimes requires going back up to the generic home page and down an alternate path. One way around this would be to have all the audience-specific pages be like the generic home page, except with the choices in a different sequence, and with perhaps a few choices at or near the top that are "promoted" from the second or third layer of the generic set. For example, have "Admissions and Financial Aid" as one button on the generic home page, and have four of the choices from that sub-page all be on the "Prospective Students" home page. This does run the risk of compromising goals 1, 4, and 7.
A very convenient feature of HTML is that browsers will ignore tags that they don't understand. This means that it is easy to predict what all older browsers will do in the presence of a new tag, so that it is possible to make correct decisions about whether, and how, to use new tags.
As you browse the Web with a modern graphical browser, you will see many pretty pages, whose authors have done things you will be tempted to emulate. In many cases, however, you will find that you must make a compromise between page designs that are pretty on some browsers, but fragile (and therefore ugly or non-functional on other browsers), and robust page designs whose appearance may be more "sturdy and functional" than "elegant." Often you will find that for a comparable or only slightly greater initial effort, it will be possible to create page designs that are both robust and elegant.
As you make your choices about the design of your pages, you should keep clearly in mind the user population you expect to be serving; for example:
Additional information on the demographic characteristics of a large population of Web surfers and their hardware and software can be found on-line at the Georgia Tech survey page; look particularly at the most recent survey. Additional insight may be found in the analysis of the Ohio University Front Door server log files: go to http://www.ohiou.edu/operations/analog/ and select a recent month (beware the large file size), and then select "Browser Summary" and scroll down through it to the "Operating System Report". A modest but significant fraction of our audience is not using Microsoft Internet Explorer, and a modest but significant fraction of our audience is not using Microsoft Windows.
This method takes more learning at the start, because you must confront the raw HTML, but there are no concealed assumptions, so you retain complete control.
This method provides a good quick transition from an existing written document to put it on the Web, but the resulting page will almost always be riddled with fragilities because of the word processor's assumptions.
This method is quick, and once you learn the ins and outs of the particular software package will usually let you produce a robust page, but you are still vulnerable to the software's hidden assumptions.
A check-list is available that can serve as a table of contents to this section, because it includes links directly to the discussion of each of the following items.
This is especially important for departmental or other organizational Web pages, where you should presume that someone else will eventually be responsible for maintaining the pages.
Following the rules of thumb for robust filename choices has the added advantage of producing URLs that are compact, and therefore easy to type when your reader is called upon to do that. Please see the discussion in Chapter I, Section A.
The title should be reasonably terse, descriptive of the contents, with neither acronyms nor obscure abbreviations, and unique (at least among all the pages controlled by that author). It is often a good idea to include the organization's name for official pages. It is both trite and also redundant with its own existence to use the phrase "home page" in either the title of the Web page, or in the first header in the body of the page.
Often, but not always, it will be sensible to choose identical text for the TITLE and for the first-level header at the top of the document, or for the displayed text of a banner graphic at the top of the document.
The height and width specification will speed up display of your page, because the browser can continue to lay out the text without waiting for the image file to be returned by the server.
The ALT text should be specified on every image, so that Lynx users (and graphical browser users with image loading turned off) are informed (if there is text) or not distracted by the default "[image]" text (which will be suppressed by having an empty string or space character for the ALT text, as opposed to having no ALT text at all).
Server-side imagemap support is, by definition, server-specific. Most servers are configured to use either CERN or NCSA format for the imagemap data file. Consult with the system manager of your server to learn how it should be done. You might also want to take a look at Appendix III, for a discussion of methods to use server-side imagemaps. That discussion includes step-by-step instructions for preparing the imagemap data files in either CERN or NCSA format, for use on OAK or CSCWWW.
If you type in information that others are responsible for knowing as part of their job, then your pages will not start out broken, but they will be out of date sooner, more often, and for longer times. One of the daunting aspects of the world wide web is the responsibility for revising and updating all that information. In cases where there is a department within the University (e.g., Registrar's Office, University Publications) that is responsible for hardcopy publication of information you want to have on-line, please contact that department to make arrangements for on-line publication.
As each organizational unit gets started with the Web, there will be situations where people want information to be on-line that the responsible party is not yet prepared to place on-line. When that happens, it is usually a good idea to contact the people responsible for the University's home page, so that they can coordinate the various projects that are in progress.
By working with the party responsible for the information that you want to have linked with yours, you can ensure that the proper tags are inserted in the on-line version of their documents, too.
Unresolved issues (whether of content or timetable) should be brought to the attention of the Web Team, by E-mail to webeam@www.ohiou.edu.
Using lists for a set of links, rather than embedding those links in a paragraph, has the advantage that Lynx users will be encouraged to use the down arrow key to get from one item to the next, the correct method. If the items are embedded in a paragraph, a Lynx user might type, for example, the right arrow, which will take them into the current link, rather than moving over to the next link. The list format therefore helps to avoid frustrating your reader!
Feel free to put break, paragraph, or horizontal rule separators between list items to force extra white space. Unlike with paper publications, it does not cost anything extra! One reasonable rule of thumb is that if one or more items in the list is so long that it will be wrapped to two or more lines for display, then there should be a paragraph break between items.
There are two reasonable methods:
When using this approach your readers will appreciate having extra white space, which makes mouse pointing seem less challenging, so use a paragraph break between lines to increase the vertical separation, and on each line use " " (which forces a non-breaking space) two or three times between each pair of items, in order to increase the horizontal separation between items.
If there are only a few destinations, you can use a separate graphic for each, whose ALT strings will provide the identification for Lynx users. The more graphics you have on a page, the longer it will take to load and display, because all browsers have a limit on the number of files that are "in progress". That number is typically four, so that if you have four graphics on your page, it won't even send away for the fourth one until either the HTML file itself, or one of the earlier graphics, is completely transferred.
In each of these, the link from the shortcut text or graphic is directly to the location of interest.
A banner graphic should be at most 525 pixels wide and at most 200 pixels high, preferably in the range from 100 to 125 pixels high (stick to the shorter end of that range if the very top part of the page is an institutional framework graphic). The limitation on width is in order for the entire graphic to be printed with the page in portrait, rather than landscape orientation. The limitation on height is to ensure that as many as possible of the shortcut links will be visible on the first screen of the page, even by people using older, smaller displays, or with their browser window set to less than full screen size. Possible sources of graphics include:
This banner graphic and any shortcut button graphics should be designed together. They do not have to be of the same width, but the aesthetics of the combination should be considered, rather than creating them independently.
These graphics use a relatively large font, but you can see that the drop shadow enhances the definition of the edges of the characters, making them easier to read.
A check-list is available that can serve as a table of contents to this section, because it includes links directly to the discussion of each of the following items.
Some pages containing Java have been observed to crash Lynx. This obviously prevents those users from seeing your page and also prevents your pages from being included in any keyword searchable index that is created using Lynx as the "crawler," such as that provided on Ohio University's Front Door.
Some pages containing Java or Javascript have been observed to crash Netscape, or to freeze the whole system, forcing your reader to restart the computer. This is user-hostile and does not create a favorable impression of your organization!
The various versions of Netscape and Internet Explorer have implemented Javascript in non-compatible ways. For example, the code
var year=time.getYear();
if (year<100) year="19" + time.getYear();
else year=time.getYear();
will produce different results on different browsers, because the time.getYear() returns the number of years since 1900 in some browsers, and the full four-digit year in other browsers. A more universal approach, instead, would be the code
var year=time.getYear();
if (year < 1900) {year += 1900;}
For those situations where Java does seem to be the appropriate solution, or just to satisfy your curiosity, we provide some additional information on using Java.
If, despite all of this, you do decide to use frames, be very careful that any links to pages outside of your own are constructed to appear in a full window, frame-free. If not, there is real risk that you will get into an endless recursion of frames-within-frames-within-frames... (the Versailles hall-of-mirrors effect).
This is accomplished by including within the anchor tag, the appropriate TARGET attribute:
Because they ignore the various Table tags, non-table-aware browsers are only likely to do something readable with a single-row table, especially if the first item within each cell is tagged as a header. For partially table-aware browsers, such as the latest version of Lynx, you should experiment and see how it works.
A tabular presentation can also be achieved by using pre-formatted text. Remember to keep each line to at most 80 displayed characters (not including any embedded tags), so that it will be displayable in Lynx.
Beware using STRONG format or HEADERS within pre-formatted text: most browsers display strong formatted text and headers by using bold-face, but each bold-face character is wider than the corresponding plain character, destroying the intended column alignment.
Beware setting background colors for individual table cells. Version 2 of Netscape ignores table cell background colors, but does obey BODY attributes for text and link colors, as well as FONT color tags, including those within cells. It is therefore quite easy to create a table that looks very nice in later versions of Netscape, but in which the text is impossible to read using Netscape Version 2, because the text and background are identical colors.
Beware using table structures to attempt to control the placement of items on the screen. Such pages are always fragile; they will be broken by having the window set to different dimensions than anticipated.
There are situations where animated images are the most appropriate method to convey information (for example, to show the flow of materials in a chemical engineering process). Animated images, where they will work, are less burdensome than a QuickTime movie clip.
It detracts from a Web page, however, to use an animated image where no animation is necessary.
Be aware, also, that faster machines are likely to display the animation sequence so suddenly that it is just a blur anyway, and loses all postive impact.
When your reader prints a page containing an animated image, only one of the sequence of images will be printed, essentially at random, so your page is likely to look lame when printed.
Horizontal rules aren't pretty, but they are robust, and robust is better than fragile.
Lynx is important for several reasons, including:
This does not mean that you should invest major effort in optimizing your site for use with Lynx; it does mean that you have practical, ethical, and legal reasons to invest the effort needed to ensure that your site is usable with Lynx.
For graphical browsers, this viewing should include consideration of at least the following:
Small or italic type will therefore be harder to read on Macintosh than it is on Windows. Having the extra pixels in each character makes the Windows characters smoother and easier to read. The Macintosh, on the other hand, has more words visible on the screen at any one time, and text will fit into tables of a defined size in pixels on a Macintosh that will not fit on Windows.
On the web, unlike hardcopy publishing, type faces are controlled by the browser. Lynx uses fixed-pitch fonts for all text, because Lynx works with displays of 24 rows of 80 characters each. Netscape usually uses two type faces, a proportional-spaced font (usually Times) and a fixed-pitch font (usually Courier). Browsers that don't know about the font or bold tags will ignore them, and the text "marked" with those tags will simply blend in with the surrounding text, instead of being emphasized.
The choice of a white background is especially appropriate for a web page that is to be used as a slide show for a presentation, because it increases contrast, and therefore enhances the readability of the projected display. Beware specifying colors by name (e.g., "darkgreen") instead of by RGB color value (e.g., #006600). Some older graphical browsers do not understand the color names.
Typewriter format will look just the same as the surrounding text when viewed with Lynx or other text-based browsers, so do not use it for emphasis.
In scholarly work, it is common to format bibliographic citations using italics for certain parts of the text (e.g., the title of a book or journal). It is probably better to conform to that standard style, and be hard to read, than to appear illiterate.
Absolute(bad) |
Relative(good) |
| SIZE="1" | SIZE="-2" |
| SIZE="2" | SIZE="-1" |
| SIZE="3" | SIZE="+0" or no SIZE= at all |
| SIZE="4" | SIZE="+1" |
| SIZE="5" | SIZE="+2" |
| SIZE="6" | SIZE="+3" |
In most situations where you would be tempted to use positive values of n, you should instead use either strong format or header tags (see the next item). Negative values of n are a major readability problem, because most browsers display text with a default size that is about as small as people can comfortably read on screen, in order to provide the maximum amount of interesting information on the screen at any one time. Even going down one step in font size will make it much harder for many people to read. Be especially careful about this if you are using Windows, because Macintosh systems use 64% of the number of pixels that Windows systems use to render each character, so "small but readable" text on your screen is likely to be "tiny and unreadable" on Macintosh screens.
Do not use header tags to emphasize a whole paragraph, use strong format if you must, but it is even better to use some other technique to make a whole paragraph special. (This paragraph, for example, is preceded and followed by horizontal rules, and those horizontal rules are included, along with the paragraph, in a blockquote section.) See also the next point.
Sometimes a complete short sentence in the middle of a paragraph will look OK in strong format.
Pages with paragraphs of information that look like this are distracting to read, and impossible to navigate. Sometimes you cannot even get one clean sentence of information read without having a bunch of links distract you. It is similar to trying to watch 3 TV programs at the same time, each showing you a minute's worth of the show before switching to the other.
Yuk!
It does sound contrary to the overall principle of the web, but try to use links sparingly. Except for shortcuts, avoid having multiple links in a document that point to the same thing, unless it is something like an example to look back on repeatedly. Name your links clearly, and give a description nearby if necessary. Give people a chance to read your information and rest their mouse button finger.
It is an effective use of system resources to generate a single monthly report of Web server activity, based on the server software's "stream-of-consciousness" log files. Trying to maintain a "hit counter" that is continually updated is not efficient. "Hits" are a mediocre measure of viewership, as explained in the home page for the usage statistics of CSCWWW.
Other guidelines are also available on-line.
Including the in-line thumbnail logo inside the link causes the image's ALT string, if any, to be part of the link text when viewed from Lynx. This also has the result that in Lynx a single down-arrow keystroke will move past that link, instead of requiring two keystrokes. Be sure to include a space character or non-breaking space (" ") between the image and the rest of the link text.
Netscape displays a characteristic (blue or magenta) border around an in-line graphic, when the graphic is part of a link. The border is continuous with the underlining of the text part of the link. Clicking on the icon functions identically to clicking on the highlighted text of the link, and with many graphical browsers there is no "dead" space between them where clicking accomplishes nothing.
There are three ways this might happen:
The simplest way to avoid this problem is to be sure to always use all lowercase letters in URLs for resources on such servers, even though any combination of case will work to get to the pages.
The simplest way to avoid this problem is to be sure to always write the URL out in full, including the filename. This is also required in order to be able to test the link from your hard disk, if it refers to one of your own pages.
Over the years, CSCWWW has performed two separate functions: serving the university's Front Door pages and serving many departmental pages. Once upon a time those two functions were performed by two separate machines. In order to keep the URL for your Web pages as short as possible, we have decided to keep those two functions consolidated in one machine. Therefore, you should refer to all pages on CSCWWW by the domain name www.ohiou.edu, including:
For example, http://www.ohiou.edu/athens/tour/tour.html.
For example, http://www.ohiou.edu/~habitat/.
The complete URL (with the correct IP address or domain name if it is an absolute URL), including the full path and filename, should be used both in anchor tags and in imagemap data files.
Boilerplate is discussed last, not because it is of lesser importance, but rather because it places the text immediately prior to the boilerplate that I am using for this page, so that it can serve as an example:
Dick Piccard revised this file (http://www.ohiou.edu/pagemasters/memo85/append6.html) on August 7, 2003.
Please E-Mail comments or suggestions to "acatec@www.ohiou.edu", or use the feedback form.