by Robert Lentz (email@example.com)
The entire process has been compared with sculpting (having to release the statue from the stone). (If you are comfortable with scripting languages, you should seriously consider learning Perl to assist you with your document maintenance.)
In all cases you should try to keep "top level" documents as small as possible so people are not rudely surprised by having to wait for a large document or lots of images. In all cases you should warn the user if following a link will possibly result in a long wait due to image size or complexity.
While most browsers currently do not require these tags, you should include them to assure proper future funtionality.
A more formal method has been adopted which clients can use to allow a
reader to send comments or problem reports to the author. This involves a
link" tag, within the "head" section of your document, such as:
<link rev="made" href="mailto:firstname.lastname@example.org">,
but you of course would use your own email address.
Both methods should probably be used.
While a great portion of the excitement over the World Wide Web and Mosaic involves the multimedia capabilities, these capabilities must be used only when appropriate, or at least sparingly; otherwise your reader faces the prospect of waiting for upwards of half a minute for you document to load. Most of us have by now run into documents which take a seemingly long time to load and can thus sympathize.
Not only will large inlined images provide sluggish response, but lots of images, even small "thumbnail" images, will cause a sluggish response in the loading of your document. (The author suggests no more than 20K and five images per page. More information on readership impact, based on the author's experience, is available.)
Large numbers of inlined-images can also provide a display problem. Most color displays will only be able to deal with 256 colors simultaneously. Large numbers of images with differing color maps will soon fill this, impacting negatively on each other and whatever else the reader's monitor might be displaying. Using grayscale images is one way to minimize this problem.
A similar display problem occurs because not everyone uses a color monitor, many people will be viewing from monochrome displays. This should be kept in mind when designing, or deciding to include, your images. You should probably test out the look for yourself by changing your monitor's setting.
If an image is central to your communication, especially as a link, you
should also include an "
alt" attribute in your
If you must burden a document with large (numbers of) images, first consider making them external images, with a description within the document as a link to them. Another approach would be to just include a smaller, thumbnail, version within the document as a preview and a link to the real version. In all cases you should warn the user if following a link will possibly result in a long wait.
Since most clients have a cache for inlined-images, you could probably use a consistent set of navigational icons throughout your hierarchy, though the cache would be negatively impacted upon by any other inlined-images you use. Once we have a campus image server, it would be advantageous to standardize on a set of navigational icons. (For a variety of reasons the author is partial to textual buttons, constructed by <enclosing a link> with angled brackets.)
You probably also want to provide a "What's New?" section so people can easily see what has changed or been added. (The author is partial to a small section at the top page of a document tree as it avoids the trouble of retrieving two different documents, or storing two different links.)
A compromise is to provide an "outline" of the document as a separate
document which people would first browse. The sections of this "outline"
would refer to "named anchors" within the target document; this way readers
do not have to waste time downloading the main document. You would probably
also want to provide a copy of the outline at the top of the document for
people to refer to once they have accessed the main document. This copy of
the outline would use only the named (
href="#name") portion of
the corresponding URL to avoid reloading the main document. Then within the
document, at the end of each section, you could provide a link back up to
the in-document outline.
In preparation for this eventuality, if you are planning on publishing
dynamic data, you can include expiration information within your document.
This is done through the
<meta name="Expires" value="Tue, 04 Dec 1993
21:29:02 GMT"> tag and attributes in the "head" section of your