Web sites should be organized to provide effective access to the resources that you have on-line. 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". Although usage statistics are intrinsically limited in their accuracy, they are often the only available information, so they should be considered, but with caution.
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.
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.
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.
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.
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 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 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
Use filenames and folder 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 names that the system permits.
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.
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.
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.
Imagemaps on Front-Door Servers 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.
Do not re-type anything that is already being published.
Feel free to put break, paragraph, or horizontal rule separators between list items to force extra white space.
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.
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.
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. Possible sources of graphics include:
Photograph of person, building, or campus scene
Illustration (technical or historic)
Institution Logo if an official page
Smaller font sizes should be sans-serif
Medium and larger font sizes should be anti-aliased
Readability of lighter text on a darker background may be enhanced 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:
Drop shadows that are offset by more than a few pixels, and any drop shadow with darker text on a lighter 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.
Considerable work is required to set up your Web pages such that any revision need be made in only one place - usually you will be maintaining two se[erate versions of identical information.
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 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.
There is no URL that can be quoted to bring up a specific view, only the initial configuration of the frame-set.
Frame-based pages are always fragile.
If 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 recursive loop.
This is accomplished by including within the anchor tag, the appropriate TARGET attribute:
<A HREF="whateverURL" TARGET="_top" >
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.
There are situations where animated images are the most appropriate method to convey information. Animated images, where they will work, are less burdensome than a QuickTime movie clip.
Avoid using short, wide, graphics to separate sections of the page. They may not appear as intended if window size is adjusted. 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.
Avoid making page design choices based on looking at the on-screen presentation with one browser. Ideally, every page should be critically reviewed from FireFox, Microsoft Internet Explorer, Google Chrome, and Safari, including at least one browser on Windows and one on Macintosh.
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 page differences.
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.
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.
Don't count on your readers seeing the full width of any graphic.
Printed output is likely to clip the right-hand portion off of any graphic that is wider than 670 pixels.
Don't count on the display wrapping at any particular width.
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.
On the web, type faces are controlled by the browser. 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.
If you feel you must do something different from the default, you are not likely to encounter any problems by specifying a background color that is lighter than the default.
Using a dark background color and light-colored text has been observed to result in color inkjet or laser printers producing a completely unreadable rendition of a page or wasting incredible amounts of toner or ink.
Individual browsers can be configured to ignore the color directions in the HTML files, so you cannot count on your colors being used.
Please do not specify any TEXT or LINK colors. Reader's become accustomed to the default coloring of their preffered browser and attempting to overwrite that default coloring is incredibly user-unfriendly.
Use strong format for emphasis within a paragraph, rather than bold.
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 small size.
Use italics very sparingly: on-screen italic fonts are almost invariably hard to read.
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. The table below shows corresponding absolute and relative FONT sizes:
no SIZE= at all
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 very small, hard-to-read font.
Do not try to emphasize large blocks of text by putting them in bold or strong format or all in uppercase.
Avoid using graphic images or HTML files that are too large (in kilobytes). The larger files will take longer to load. A home page should be especially conservative in this respect. Twenty to forty KB is the upper limit on file sizes to still have quick load times for dialup users.
Avoid using sound or video clips that are too challenging for your reader's system. 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).
Except for shortcuts, avoid having multiple links in a document that point to the same thing. Name your links clearly, and give a description nearby if necessary.
Avoid using graphic images that contain only text. This is a reasonable approach only for navigational buttons and for banners at the top of a page. Be sure to provide ALT text, so that non-graphical browsers can convey the same information.
Avoid using commercial hit counters or guestbooks. Since you have no control of these services you don't know what that company does with the information it can gather and usage statistics are intrinsically limited in their accuracy.
Avoid using personal accounts on any computer system to serve departmental or organizational Web pages.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. 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 using two consecutive links that lead to the same destination. If you have an in-line image 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.
Avoid having consecutive images with no separators 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.
Avoid using graphics that include extensive areas in which the color (shade or brightness) changes gradually. The problem is that many browsers, especially older PCs running Windows, have only a very limited palette of colors available at any one time, therefore producing large areas of uniform color with distinct boundaries - a sort of "striping" effect.
Here the term "boilerplate" is used 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
The name of the author of the page
The URL of the page, in plain text, so that a printed copy will contain the URL
The revision date
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.