Web sites should be organized to provide effective access to the resources that you have on-line. The initial design may be intended, in part, to conceal missing items; once they are no longer missing, they can be highlighted, instead. Usage statistics can provide some insight into the ways that people use your Web pages, but remember that they are intrinsically incomplete: usage reports are based on Web requests that came to the server. As such they count "hits" for every time a browser starts up that has its home page configured to be a page from the server. They also count hits every time any Web search engine checks the page. No "hits" are recorded for any time a user goes to a page that is displayed from the browser's cache. No hits are recorded for any time a user goes to a page that is displayed from a "proxy server" (such as AOL). Although usage statistics are intrinsically limited in their accuracy, they are often the only available information, so they should be considered, but with caution. For example, if a page is heavily visited, you do not know whether that is repeat traffic, people on their way to various pages that it links, or whether it is one-time visits by people who are desperate because they can't find what they want anywhere else.
Designing a Web site includes three distinct but interacting phases:
The conceptual design (what information will be on what pages, how will the links among the pages be organized, how will navigational and content layers and pages be separated or mixed, etc.).
The choice of the exact text for the terse labels on the shortcut buttons, link menus, and for any banner graphics.
The visual design of the pages: what will be the shape, size, and placement of the shortcut buttons, link menus, and other graphic and text elements.
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:
Keep the text and graphics files small so that the pages will load quickly, and the space they occupy on the screen small so that as many choices as possible are visible with minimal scrolling, even on small screens.
Keep the graphics visually appealing (e.g., use textured or banded rather than uniform ("smooth") color behind the text on the buttons, even though it doesn't data-compress as well).
Minimize the number of files that have to be visited on the way to the item of interest (i.e., have fewer navigational layers).
Keep each file simple, with only a few choices, both to make it easier to choose and also to minimize scrolling.
Have choices that are targeted to various identifiable sub-audiences (e.g., prospective students, their parents, prospective employees, current students, current employees, etc.).
Provide every sub-audience with direct, simple access to all parts of the organization's Web presence, since there really is no telling what might be of interest to each individual, even though you can probably predict fairly well which will be the most popular items for many of the sub-audiences.
Your audience should find it easy to conceptualize the overall organization and structure of the links among your site's pages, based on the first few pages they enounter. They should not feel confused or disoriented when they confront the navigational links. This does not mean that you can't include some "random" links, as needed, but it does mean that the primary navigational links should form a readily visible organic whole.
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.
Web pages, or the Web site consisting of a group of linked Web pages, are "broken-by-design" if they do not make reasonable compromises among the goals discussed in the previous section. Web pages are "fragile" if they work with some browsers, but not with others, i.e., if they are easy to break. In a nutshell, Web pages will break if they contain tags that the browser doesn't understand, or if they have been composed with unjustified assumptions about the browser, its configuration, or the hardware it is running on. The rest of this Appendix discusses the methods you can use to avoid creating fragile Web pages.
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:
If you are a faculty member teaching a class that is scheduled to meet in a lab with large-screen, ethernet-connected machines that are all running the same software, and you are confident that your students won't want to study those Web pages by dialing in from their off-campus housing, then you can be quite uninhibited about the HTML features you use, provided that you test them on a comparable machine running the same software.
If you are writing departmental pages that you expect to be visited by prospective students and their parents from around the world, many of whom may well be using slow connections or mobile devices with small screens, then you need to be very careful to write robust pages.
Additional information on the demographic characteristics of the people who have visited many of the Ohio University Front Door pages, including characteristics of the browsing hardware and software, can be found on-line through the Google Analytics data we collect. Contact OIT's Web Services staff for access to that data.
The methods that you should use to avoid making your pages fragile depend on the technique you use to create and modify your HTML files. In all cases, you can benefit from ensuring that your pages contain valid HTML code; the standard tool for doing that is testing through http://validator.w3.org/.
An ordinary text editor (e.g., Notepad on Windows or TextEdit on Macintosh), directly working with the HTML tags:
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; in particular, if you don't learn how to do browser-sensitive things, you won't include them in your web pages.
A modern word processor with HTML import and export capability, such as Microsoft Word on Windows or on Macintosh:
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.
A "WYSIWYG" HTML editor, such as Dreamweaver or Contribute:
This method is quick, and once you learn the ins and outs of the particular software package will often let you produce a robust page, but you are still vulnerable to the software's hidden assumptions.
For further information on considerations in designing Web pages that are generally accessible, take a look at http://trace.wisc.edu/world/.
WebAIM: The Web Accessibility "How-To" Site includes links to the "Section 508" standards issued under the federal Rehabilitation Act.
The Alertbox: Current Issues in Web Usability is an intermittent column (perhaps two dozen each year). Particularly germane essays include:
Here is a page dealing with the excessive use of "under construction" images: http://www.andrews.edu/~rickyr/noconst.html
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.
Use filenames and folder (subdirectory) names that are legal on all platforms. If you are dealing with the HTML and graphic files directly, you will have to choose filenames that are legal on the personal computer you use to maintain your Web pages and on the server you use to publish them. If you are using a content management system, such as CommonSpot, you could choose any subsite and sub-subsite names that the system permits, but you should choose names that are more generally acceptable. Being careful to choose names that are legal on other platforms will give you the freedom to migrate to another environment in the future with minimal effort and minimal inconvenience to your readers.
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.
Choose a good title for your page: the page itself won't be fragile without a title, but having a good one will make it easier for people to find your page using search engines. Most browsers display the title at the top of the screen, and use it for the visible label for any bookmark set to that page.
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).
If you use imagemaps, use browser-side imagemaps. This will ensure that your page contains HREF attributes with values leading to each of the destinations, so that all the search engines will find and index all of your pages.
Appendix III provides a discussion of methods to use browser-side imagemaps. That discussion includes step-by-step instructions for preparing the imagemap data blocks.
Do not re-create information that duplicates information provided by others.
Use shared graphics rather than making a duplicate. This will make your page load faster for any user who has recently visited a page that also used that shared graphic, since it will already be in the browser's cache, and it will contribute to maintaining a consistent look to your Web pages. See the discussion of Content Standards Visual Issue 9. If the shared graphic lives on a different server, you will need to specify an absolute URL for the image source.
Do not re-type anything that is already being published.
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 email@example.com.
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.
Each home page should provide shortcuts for the reader to go to all of the primary links without having to scroll down. This avoids forcing your reader to scroll and scroll down through your whole page in order to find the link to the next page he or she wants to examine. One of the things you want to encourage is repeat traffic. Shortcuts are a friendly arrangement for repeat visitors, because they are likely to arrive on your home page knowing where they want to go next, and shortcuts let them get there with a minimum of scrolling or clicking.
Shortcuts may constitute the entire content of a purely navigational page, such as you might use for a home page of a large collection of Web pages.
Shortcuts may duplicate the links available within the body of the page.
Shortcuts may function as a Table of Contents for the page.
You will lose the immediate convenience value of shortcuts if they occupy space on the screen beyond what the browser will display without horizontal scrolling. The problem arises in deciding how wide a window you should anticipate the majority of your audience to be using. Palm Pilots and other PDAs have a screen width of less than 400 pixels; Macintosh users usually adjust their different applications' windows to partially overlap, so they do not want to have to take their browser to full screen width. It will be impossible to print your page without losing parts at the edges on some platforms if the graphic exceeds 530 pixels in width, an issue that is less compelling for pure navigational pages, but a real concern for pages with actual text or graphics content.
There are two reasonable methods:
A set of terse text links, often near the top, such as can be found on the Policy home page.
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.
Panoramic ("banner" or "masthead") graphics function well on the top part of the first screenful of home pages, either of organizations or of particular topics. As discussed in the previous point, you should keep the total width narrow enough to be seen in its entirety with any standard graphical browser, even if the user has left the window configured to less than the full screen width. By using a height of 100 to 200 pixels, the shortcuts below them will be visible without need of scrolling.
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:
Photograph of person, building, or campus scene
Illustration (technical or historic)
Institution Logo if an official page
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.
In general, either the home page or a page linked directly from it should include full contact information, including telephone numbers and postal mailing address. This is especially an issue for departmental pages, but should be considered also for personal pages.
Smaller font sizes (12 point and below, for sure) should be sans-serif;
Medium and larger font sizes (20 points and up, for sure) should be anti-aliased (anti-aliasing smaller font sizes may blur their edges too much for easy readability);
Readability of paler text on a darker background may be enhanced, especially for smaller font sizes, by adding a drop-shadow for the lettering. If so, it should be blurred with a radius of two or three pixels, and offset one or two pixels. For example:
Good drop shadow:
Excessive-offset drop shadow:
Without drop shadow:
These graphics use a relatively large font, but you can see that the good drop shadow enhances the definition of the edges of the characters, making them easier to read, while the excessive drop shadow presents the reader with two, overlaid sets of letters, making them harder to read.
Drop shadows that are offset by more than a few pixels (such as the second graphic, above), and any drop shadow with darker text on a paler background, will degrade the readability.
If your institution has chosen particular fonts for particular settings in hardcopy publications, you should consider using the same fonts in the corresponding settings in your Web publications.
Any anchor tags for sending e-mail (so-called "mailto:" links) should specify a single destination address to send the message. Using mailto links with multiple addresses in one link (to send the message to multiple people at once) has been observed to crash Lynx. This obviously prevents Lynx 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."
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.
Browser scripting (Java) has been one of the traditional mechanisms used by evil websites to accomplish their nefarious deeds. Therefore, you must expect part of your audience to have disabled it when they look at your pages.
Avoid using HTML frames. There are multiple reasons to avoid using frames, in spite of the fact that most graphical browsers do reasonable things with them:
Considerable work is required to set up your Web pages, if you do use frames, such that any revision need be made in only one place - usually you will be maintaining two versions of the information, either in separate files or in two places within one file, one for those with frames, and one for those without.
A common use of frames is to create a "fixed" table of contents in a narrow frame on the left edge of the screen. The primary frame (which is likely to be the only part visible to non-frame users) will then have the content, without the navigational aids, making it harder to use.
Your reader may not be able to set a bookmark that will return him or her to any specific view; instead, the only bookmarks that can be set on framed pages in some browsers will just restore the initial configuration of that frame-set, not the particular view when the bookmark was set.
There is no URL that can be quoted to bring up a specific view, only the initial configuration of the frame-set. This is particularly unfortunate for any intructional materials or reference information - it cannot be properly cited. Because departmental pages often contain information that people need to know, and therefore some people need to be told how to get to, frames should never be used for such sites.
Frame-based pages are always fragile, either breaking or at least not producing the intended effect when the browser's window width is outside the range of widths the author designed for.
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:
<A HREF="whateverURL" TARGET="_top">
Exercise Care using Cascading Style Sheets. This feature is not supported uniformly by all browsers.
Exercise Care using HTML Tables. 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, 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.
Be careful setting background colors for individual table cells.
Be careful 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.
Avoid providing free advertising to commercial enterprises. It is OK to provide a link to on-line information, including places where people can download new versions of software that would help in viewing your page, if you have something special on it (RealAudio, Adobe Acrobat, etc.). It is not appropriate for a public university Web page to sport graphic images that are part of the corporate identity of commercial enterprises. If your page is truly "best viewed with browser X," then you need to fix your fragile Web page, and you should certainly not be boasting about its fragility.
Avoid using gratuitous animated images. Animated images are a continuous distraction to your reader, and a continuous drain on system resources (primarily CPU time) on the browsing machine. Furthermore, some of the people who will look at your page may be using browsers that suffer from a "feature" that continually re-writes the animated graphic loading messages in the bottom margin of the window - this both distracts your reader and prevents your reader from being able to use that bottom margin for discovering where the link the mouse is pointing to will go.
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.
Avoid aligning images to the left or right, to cause text to flow around the image. Such pages are always fragile, either breaking or at least not producing the intended effect when the browser's window width is outside the range of widths the author designed for. In particular, text may be hidden completely or partially by the image if the window is too narrow.
Avoid using short, wide graphics, no matter how pretty, to separate sections of the page. If viewed with a narrow window, they will extend beyond the edge of the display. If viewed with a wide window, they will not run from margin to margin. Horizontal rules can be modified with a variety of attributes to be less mundane, for example:
Horizontal rules aren't pretty, but they are robust, and robust is better than fragile. Do also be aware that some people will stop scrolling when they encounter a horizontal rule, evidently believing that they have reached the end of the page.
Avoid making page design choices based on looking at the on-screen presentation with one browser. Again, using only one browser does not guarantee fragile pages, but it does leave you much more vulnerable. Ideally, every page should be critically reviewed from FireFox, Microsoft Internet Explorer, and Safari, including at least one browser on Windows and one on Macintosh. In practice, you will soon learn what constructs to avoid, and therefore you will be able to limit your checking with other browsers. Web page authors should examine their own pages regularly with at least one alternate graphical browser. Be especially careful when first using any particular feature of HTML. Many browser-specific HTML features look dreadful in other browsers.
Lynx is important for several reasons, including:
Many people have convenient web access only through Lynx, including students living off-campus at some institutions and people using some freenets.
Lynx is often used by visually impaired people, since it permits them to take advantage of hardware and software to vocalize the characters on their screen.
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.
Internet Explorer on Windows will probably be used by the clear majority of your audience. You should ensure that your pages work with IE. But don't stop there: a substantial minority of your audience will be using FireFox or Safari, on Windows or on Macintosh. You should ensure that your pages work also with those browsers on both platforms.
For graphical browsers, this viewing should include consideration of at least the following:
Platform: there are consistent differences between Macintosh and Windows machines that can result in pages that have been proofed on either platform, even with multiple browsers, still not working well with any browser on the other platform.
Text will be larger on Windows machines and smaller on Macintosh systems: Macintosh on-screen display is 100% of the printed size, while Windows' on-screen display is 125% of the printed size. Thus the Macintosh uses 80% of the width and 80% of the height to display each character. This means that the number of pixels used to render a given character on Macintosh displays will be 64% of the number used on Windows displays.
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.
Graphics will be smaller on Windows machines and larger on Macintosh systems, in relation to the adjacent text.
Color rendition will vary, both in overall brightness and in color balance.
Graphics will be displayed differently on Windows machines that are set to 256 colors, than they are on Macintosh machines that are set to 256 colors, because only 211 of those 256 colors are the same. This is much less an issue now than it was a few years ago, because most modern computers can display thousands of colors (one of the good results of the popularity of computer action games).
Don't count on your readers seeing the full width of any graphic that is even as much as 400 pixels wide, although the majority of your readers will be able to see graphics as wide as 600 pixels.
Printed output, especially on a Macintosh, is likely to clip the right-hand portion off of any graphic that is wider than 670 pixels, regardless of the window width the browser is set for. It is likely also to clip the text content at the same point if table or frame constructs force the width to exceed 670 pixels.
Don't count on the display wrapping at any particular width - some browsers will be running on very wide displays (up to 1,920 pixels wide), and some will be adjusted to a very narrow window (smaller than 512 pixels is unusual, except for handheld devices).
Using background graphics that are designed with a contrasting region along the left portion of the screen can be problematical. Another copy will be tiled onto the right side of the screen if the browser's window is wider than the graphic. This can easily be distracting, and sometimes makes the page unreadable, if the text on the right portion is specified with a font color that blends with the background that was intended to be displayed only for the left side.
Be cautious trying to control the appearance of text by setting the font, changing its size or color, or making it boldface, even though they are provided by newer versions of HTML and will work in modern graphical browsers.
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. Internet Explorer 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.
Background graphic images that show pale on your monitor may display so darkly on other machines that your text cannot be read. (This has been observed even with both machines running the same browser!)
If you feel you must do something different from the default, you will probably not encounter any nasty surprises by specifying a background color that is paler than the default gray, especially if you go all the way to white, by specifying a color code of #FFFFFF.
The choice of a white background is especially appropriate, because it increases contrast, and therefore enhances the readability of the text. 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.
Using a dark background color and white or light-colored text has been observed to result in color inkjet or laser printers producing a completely unreadable rendition of a page that was readable on-screen, or wasting incredible amounts of toner or ink, or both. Some browsers do not provide any method for ignoring the document's background and text colors just at print time, only as part of the overall configuration.
Individual browsers can be, and often are, configured to ignore the color directions in the HTML files, so you cannot count on your colors being used.
Please do not specify any of the TEXT or LINK colors: people become subconsciously attuned to the colors that their browser uses by default. Your reader has been building up an intuitive feel for the meaning of various colors, based on the default behaviour of his or her browser. When you try to override that, you are discarding the reader's intuition. This is so far from being "user friendly" that it deserves to be called not merely "user-hostile," but perhaps even "user vindictive."
Use strong format for emphasis within a paragraph, rather than bold: Lynx and other browsers that don't know about bold tags will ignore them, leaving no emphasis at all!
Use the typewriter format and pre-formatted text to force graphical browsers to use a fixed-pitch font, but beware of the fact that many browsers default fixed-pitch fonts to a tiny size. Unlike the rest of your HTML page, pre-formatted text also preserves space characters and line breaks - there is no re-wrapping.
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.
Use italics very sparingly: italics print very nicely on laser printers at 300 or more dots per inch, but on-screen italic fonts, displayed at perhaps 75 pixels per inch, are almost invariably hard to read, aren't they? (That would have been even worse in a serif face.) This is especially true of regular-size and small italic fonts; the larger fonts aren't quite so bad, but most people browse the Web with their default font size about as small as they can comfortably read. It is counter-productive to try to emphasize something by forcing it to be displayed in a hard-to-read style!
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.
Be aware that "ADDRESS" and "CITE" format are rendered in italic by many browsers, so use them also very sparingly, if at all.
Use underline format very sparingly, if at all: it may create confusion with links.
Use the font attribute SIZE=n very sparingly, if at all. If you must use it, be sure to use the "relative size" form, with an explicit "+" or "-" preceding the numerical value, rather than the "absolute size" form with neither positive nor negative sign. The reason to choose relative sizes is to avoid making your page completely unreadable by visually impaired people, who may well have set the default font size for display to a value corresponding to SIZE=16, or bigger. The table below shows corresponding absolute and relative FONT sizes:
no SIZE= at all
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. You can safely go to -1 only if you also specify a sans-serif face, or even better a set of sans-serif faces, such as the Ohio default: face="verdana,arial,helvetica,sans-serif": the browser will use the first on the list that is installed on that computer.
Use header tags for section titles. Don't use level 5 or level 6 header tags, because they are likely to be displayed on-screen in a tiny, hard-to-read font, made even harder to read by being in boldface.
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.
DO NOT TRY TO EMPHASIZE LARGE BLOCKS OF TEXT BY PUTTING THEM IN BOLD OR STRONG FORMAT OR ALL IN UPPERCASE. IT MAKES YOUR READER FEEL LIKE YOU ARE SHOUTING, DOESN'T IT?
Sometimes a complete short sentence in the middle of a paragraph will look OK in strong format.
Avoid using too many graphic images on a page. Browsers will only ask for a few files at a time (four, by default, in Netscape and Internet Explorer), and won't ask for another until an earlier file is completely loaded. One large graphic can be loaded much sooner than a multitude of small graphics. Somewhere between a half-dozen and a dozen graphic distinct images is the maximum that you should have on any one page, with the smaller number appropriate for a home page.
Avoid using graphic images or HTML files that are too large (in kilobytes). The larger files will take longer to load, especially for people using dialup connections to the internet. A home page should be especially conservative in this respect. Any link that leads to a page with many graphics or with large graphics should have a warning, so that the reader will be able to decide whether or not to follow the link. Twenty to forty KB is the upper limit on file sizes to still have quick load times for dialup users; navigational pages should keep to the low end of that range, although content pages can be larger. A shortcut button array graphic file of fifty or more KB will take a noticeable time to display.
Avoid using sound or video clips that are too challenging for your reader's system or the network between your server and your reader. Sound and video clips need to be captured or recorded with care, bearing in mind the limitations of the equipment that may be used to reproduce them. Limitations to be aware of include:
Frame size (320 x 240 pixels is also known as "quarter-screen," for example);
Colors per pixel (256 colors are provided by 8 bits per pixel; it takes 16 bits per pixel to even come close to matching the color discrimination of the human eye);
Frame rate (30 frames per second will provide smooth motion; 10 frames per second will be jerky, but may be worth having).
Avoid using so many links that you disrupt the flow of your Web page. Smooth flow is one of the most important aspects of web pages, and it is all too often neglected. Especially if you have a lot of information, it is very important to make the pages and information flow together in a coherent manner.
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.
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.
Every link is an opportunity to take your audience to the page it points to; it is also an opportunity to lose your audience for the page it leads away from!
Avoid using trite images or phrases, especially "under construction". All Web pages are always under construction. You should put them up for the world to see as soon as they are better than having nothing, and then keep improving them.
Avoid using internal labels containing space characters as destinations for links. The HTML specification does not permit space characters within URLs, and there are browsers that are not as forgiving as Netscape in that regard. Some browsers in fact will not even follow the link. Other browsers will go to the top of the page, but will not jump down to the intended location within the page. To tell if you have made this mistake, follow the link in Netscape and then look at the current location: there should be no space characters after the "#" near the end of the URL.
Avoid using graphic images that contain only text. Sometimes this is a reasonable approach, especially for navigational buttons and for banners at the top of a page. If you do it, be sure to provide ALT text, so that non-graphical browsers can convey the same information. Extended text-only graphics (e.g., sentences or paragraphs) are rarely, if ever, a good idea.
Avoid using commercial hit counters or guestbooks. Since you have no control of these services, your page might be broken at any time. Furthermore, if your university is a public institution, you should not be providing free advertising to any specific company. The guestbooks are a particular problem, because you don't know, and have no control over, what that company does with the information it can gather in the process of running the guestbook.
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, because they are based on Web requests that came to the server. As such they will count "hits" for every time a browser starts up that has its home page configured to be a page from this server. They will also count hits every time any Web search engine checks the page. No "hits" will be recorded for any time a user goes to a page that is displayed from the browser's cache. No hits will be recorded for any time a user goes to a page that is displayed from a "proxy server" (such as AOL). In other words, usage statistics are intrinsically limited in their accuracy.
Avoid using personal accounts on any computer system to serve departmental or organizational Web pages. You would certainly hope that the organization would outlive any one individual. Furthermore, personal accounts can be removed at any time, and disk space quota limitations on many systems can result in the seemingly random deletion of files. As commented earlier, it is quite reasonable to have e-mail links that point to an organizational account that is set to forward to the individual maintaining the Web pages. It is not reasonable to build Web pages that will have to be revised as soon as the responsibility for maintaining them passes to another person.
Avoid placing adjacent to a link any blue bullets or other small graphics that are not clickable parts of that link. Blue is the default color of clickable links in most graphical browsers, and you are likely to frustrate your reader, since clicking on the graphic will accomplish nothing.
Avoid saying "Click here to ...", because it is trite and because it doesn't make much sense for Lynx users, who have no mouse, only arrow keys. "Select" is a more universal verb, but a statement like the following is even better:
Other guidelines are also available on-line.
Avoid using two consecutive links that lead to the same destination. (This problem often happens with the first link on a graphical image and the second link on some descriptive text.) If you have an in-line image (thumbnail logo, or whatever) that is clickable, and you have adjacent text that is also clickable to get to the same location, then the image and the link text should be part of one anchor tag, by placing the image inside the link, along with the link text.
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.
Avoid having consecutive images with no separators (line break, paragraph break, or horizontal rule) to force the next image onto the following line. The resulting display will be changed radically if the window width is larger or smaller than expected by the author: items intended to be on the same line will be arranged on consecutive lines if the window is too narrow and items intended to be vertically arranged will be in the same line if the window is wide enough.
Avoid using graphics that include extensive areas in which the color (shade or brightness) changes gradually. Examples include sunsets, the sky in general, and rainbows. The problem is that many browsers, especially older PCs running Windows, have only a very limited palette of colors available at any one time. The consequence is that the various subtle shades of color are all displayed using the small number of distinct colors that are available, producing large areas of uniform color with distinct boundaries - a sort of "striping" effect. This issue is much less of a concern now than it was a few years ago, because most modern machines can display thousands of colors at once.
Avoid using multiple, different URLs to link to the same page, or using multiple different URLs to specify the same image file. Again, this doesn't make the page itself fragile, but in the case of links it does reduce the effectiveness of the search engines in leading people to your page, and for both links and images it increases network traffic and server load, wastes space in the browser's cache, and makes the page load more slowly, on average. In some circumstances it could prevent your page from being listed in the search engine; in other situations it will appear multiple times, slowing the search engine down.
There are three ways this might happen:
If your pages are on a server that is not case-sensitive in paths and file names, the server will provide the correct file no matter what combination of uppercase and lowercase you specify, but the browser will not know that it is the same file it already has in its cache, so it will ask the server to re-send the file.
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.
If your pages are on a server that automatically serves up a standard home page from a directory whenever the URL ends with a slash (e.g., https://www.ohio.edu/oit/webservices/static/index.cfm is the same Web page as https://www.ohio.edu/oit/webservices/static/ ). Having both URLs in use may result in duplicate entries in indexes and duplicate copies in browser caches.
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.
If your pages are on a server that has multiple names, your page could be referred to with a URL that uses any of the IP addresses or domain names for the server, and still have the link function correctly. You should consult with the system manager of that server to find out the name that is most likely to continue to work, and standardize on that one.
Over the years, www.ohiou.edu 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, and with the introduction of the new static-page servers in the Fall of 2008, we have gone farther, as described in the Introduction. Therefore, you should refer to all pages on ww2 by the domain name www.ohio.edu.
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.
In journalism, "boilerplate" is standard text, pre-set and used where needed. Here, we use the term to describe the routine items appearing at the end of each Web page. You will need to adapt the list to your own circumstances, and will probably vary it according to context. In general, each Web page should include the following items:
A link to at least one place your reader might have come from, or might want to go on to. Do not create dead-end Web pages.
The name of the author of the page. This serves to give credit where credit is due and also to encourage somebody to keep the page up to date.
The URL of the page, in plain text, so that a printed copy will contain the clues needed to find it again on the Web. (Some browsers do not automatically incorporate the entire URL in the printed copy.)
The revision date, so that the reader has a basis for estimating the likelihood that the information is still accurate.
An e-mail link for comments, suggestions, or questions. The e-mail address should be part of the visible text, again, for cases where the page is printed.
On personal pages, you should use your own personal e-mail address. If your institution provides a mechanism for a short-form address (such as, firstname.lastname@example.org), you should use that, because it will change rarely, if ever; if not, then use your full internet address on the mail server you think is least likely to change in the future.
On departmental pages, you should use a departmental e-mail address (for example, email@example.com) and then set the forwarding on that address to point to your own address. In this way, if you go on vacation, the person who is covering for you will be able to get the messages by simply changing that one forwarding setting, with no need to modify any of the HTML files.
For official pages, the copyright statement should routinely be near the foot of the page, and so may be incorporated into the boilerplate, if there is no standardized footer that includes it.
Boilerplate is discussed last, not because it is of lesser importance, but rather because this location places the text immediately prior to the boilerplate that I am using for this page, so that it can serve as an example: