6. What are a dozen Web Page features I should use?
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. A more complete discussion is available on-line.
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.
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 University 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 Computer Services' Academic Technology Manager.
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 two non-breaking spaces) 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. If there are more than a half-dozen destinations, then use an imagemap with a single graphic file, and create a separate text.htm file for Lynx users, unless there are also text based links to those destinations in the body of your page.
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 520 pixels wide and at most 200 pixels high, preferably between 450 and 470 wide and 100 to 125 pixels high. The limitation on width is in order to be able to see the entire graphic on the default window width of Macintosh Netscape, and for the entire graphic to be printed with the page. 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 the old standard VGA (640 x 480-pixel) display. Example graphics include:
This banner graphic and the shortcut button array graphic 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.
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://oak.cats.ohiou.edu/~piccard/oacrao98/good.html) on November 4, 1998.
Please E-Mail comments or suggestions to "piccard@ohio.edu".