TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Indexing HTML documents From:Yvonne DeGraw <yvonne -at- SILCOM -dot- COM> Date:Mon, 30 Oct 1995 10:49:00 -0700
Bill Bledsoe wrote:
>I still don't think the Index is worth the effort involved because the user
>will most likely want to just keep "clicking" on hypertext until they find
>something accidentally (Excerpted from Bill's famous "What's wrong with the
>Web Speech #24 :-) ). There's a chance that a well thought out Hypertext
>index could help the user here. But keep in mind, once the search
>technology on the Web advances to the point where it is useful (Hyper-G??)
>the index will go by the wayside there too.
The problem with search engines on the Web currently is that they find all
occurrences of the search keywords. Some search engines are pretty good
about giving higher weighting to occurrences of the keywords in headings,
in the first paragraph of text, or in various character tags. I've seen
proposals to add tags to mark text as an indexed keyword. The search tool
could then look for matches within this tag. This method could make
indexing like we see in printed books unneccessary. (Especially if there is
a tag for indexing hidden synonyms.)
Unless you implement some sort of weighted searching, I think it's nice to
have an alphabetic index page (like in a printed book) for large sites
where keywords are used in many places but discussed in detail in only one
or two places. I don't see these very often. I did one for my former
employer, but for various reasons I won't go into, their Web site still
isn't public. It was fairly easy to put together if you are familiar with
the page content.
I also like to see a comprehensive table of contents for medium-sized
sites. (For large sites, you'd probably need to split it up into several
On the large vs. small Web page question, I agree with others who have
posted that it depends on the type of content and the audience. If the
audience probably wants all the information whether online or printed, I
would go ahead and create a long page, but provide help navigating through
the page. For example,
o Include a table of contents with links to the headings in the page.
o Provide ways to navigate within the page, not just ways to navigate to other
o Provide a clear summary or abstract at the top of the page.
o *Always* specify the width and height of figures so that Netscape (and some
other browsers) can load the text first and fill in the images later.
o Add images throughout the page to keep it from being too gray (or whatever
your background color is). But, minimize the file size of your images as much
Yvonne DeGraw Technical Services o Web Authoring
yvonne -at- silcom -dot- com o Technical Writing http://www.silcom.com/~yvonne/ o Database Design and Publishing
Tel: 805/683-5784 o Human-Interface Design