X-title:  Style guide for online hypertext
X-author: Tim BL
X-FILE: STYLE.A82 published in SP82a

                     STYLE GUIDE FOR ONLINE HYPERTEXT


    Copyright: Tim BL 1992,93,94,95 All rights reserved.

   This guide is designed to help you create a [2]WWW hypertext database
   that effectively communicates your knowledge to the reader. It has
   been prepared in the light of comments by readers, and many demands by
   providers of online documentation. Some of the points made may be
   influenced by personal preference, and some may be common sense, but a
   collection of points has been demanded, and so here it is.

   The guide is designed to be read sequentially, but feel free to depart
   from this. The sections are as follows:
     * [3]Introduction
     * [4]Etiquette for a server administrators
     * [5]Overall structure of a work
          + [6]Structure for the reader
          + [7]Trees
          + [8]Document size
          + [9]To refer or to copy
     * [10]Within each document
          + [11]Sign it!
          + [12]Give its status
          + [13]Give links into context
          + [14]A good title
          + [15]Don't format for a particular browser
          + [16]Think about printing it
          + [17]Keep it readable
          + [18]Don't mention the mechanics
     * [19]Test your document
     * [20]Background reading
     * [21]Reader comments

   The above lists all the parts of this guide except for individual
   reader comments.

To print this document

   A [22]single long page with all of them excluding reader comments is
   available for printing (but has dysfunctional links and is not in
   correct html).

This document is open to comment!

   Suggestions are strongly invited, if you think of anything mail it to
   [23]timbl@w3.org, mentioning the Style Guide for Online Hypertext or
   its URL. I', also interested in the URLs of otehr style guide,
   corporate house style guides, or your favority book on style
   (hypertext or otherwise).

Introduction

   You are going to write (or [24]generate ) some online hypertext.
   Because hypertext is potentially unconstrained you are a little
   daunted. Do not be. You can write a document as simply as you like. In
   many ways, the simpler the better.

   You will be writing a number of separate files. These files will be
   linked to each other, and to external documents, to make your final
   work.

   You may think of your work as a "document", and if it were on paper,
   then you would call it that. In the online case though, we tend to
   refer to each individual file as a document. A document may
   correspond, in the book analogy, to a section or a subsection, or even
   a footnote. In this guide, we'll refer to the whole collection as a
   work.

   The document is the unit by which information is picked up. At any one
   time, a document is completely loaded into the reader's computer. It
   is also normally the amount you edit at any one time, though with a
   good editor you will probably have a number of documents open at a
   time.

   This guide has a bit on [25]etiquette for each server , which mainly
   applies to the server administrator: the rest applies to anyone
   putting information onto any server. The section on[26] structure
   discusses how you organize your material into documents. Another
   section discusses how to organise your material [27]within a document
   .

Structure

   If you have in mind a body of information to put across to your
   reader, you probably have a mental organisation for it. Normally this
   is a sort of hierarchical tree, like the chapters of a book if you
   were to write a book.

   Keep this structure. It helps readers to have a tree structure as a
   basis for the book: it gives them a feeling of knowing where they are.
   You can also use this structure for organising your files in
   directories.

   You should also bear in mind:
     * [28]The reader's preconceived structure
     * [29]The idea of overlapping trees
     * [30]How big to make each document
     * [31]To refer or to copy

  [32]THE READER'S STRUCTURE .

   Remember always the audience for whom you are writing. If they are
   novices in the subject, it will normally help if you are firm about
   the structure of your work, so that they can learn the structure of
   the knowledge itself. For example, if you feel that the subject falls
   into three distinct areas, then that is an important thing to teach.

   If, however, your readers will already have some knowledge in the
   subject, then they will already have formed their own structure for
   it. In this case they will consciously or subconsciously know where
   they expect to find things. If your structure is different from
   theirs, enforcing it too strongly will confuse them and put them off.

   You may in this case have resist a strong tendency to put across your
   own structure strongly and to the detriment of all others. There are
   two solutions.

   If you have a single well-defined audience in mind, who will share a
   similar world view, then try to write exactly for that world view
   rather than yours.

   If you are simultaneously writing for more than one group, then you
   must provide for both.

   When you make a reference, qualify it with a clue to allow some people
   to skip it. For example, "If you really want to know how it works
   inside, see the Internals guide", or "A step-by-step introduction is
   in the tutorial".

   Provide links for both reader's views. Your work will be more
   connected than a simple tree, but with proper qualification, no one
   should get lost.

   Provide two separate tree "roots". For example, you can write a
   step-by-step tutorial and a functionally direct reference tree for the
   same data. Both will at the lowest level have the same data, but while
   the first will deal with the simple things first, the second may be
   functionally grouped. This is just like having several indexes to a
   book. The tutorial might also include information which the reference
   work does not.

  [33]OVERLAPPING TREES

   Here is an example of a work (describing some programming functions,
   say) with two separate structures:
                        Tutorial                        Reference
                           |                                |
                  Let's do it together                 -----------------
                from simple to difficult              |                 |
                            |                   by Functional      Alphabetical
                            |                       group            by name
                  Task oriented examples              |                 |
                            |                          -----------------
                            |                               |
                  Examples of use of               Syntax definition for
                  specific functions   <-------->    specific functions

   The novice user starts at the top left, and works his way down. Where
   he needs specific details, he will get down to the examples and from
   them a link to the underlying definitive descriptions of each. As far
   as he is concerned, he is reading a tree-structured work. In fact, he
   is reading the same information as the expert who, coming in to check
   on one particular function, then looks up an example of its use.

  HOW BIG TO MAKE EACH DOCUMENT

   The most important point here is that a document should put across a
   well-defined concept. It is not generally worth splitting one idea
   arbitrarily into two bits in order to make the bits smaller. Nor is it
   a good idea to put together ideas which area really separate just to
   make a bigger document.

   A document can be as small as a [34]footnote .

   There are two upper limits on a document's size. One is that [35]long
   documents will take longer to transfer , and so a reader will not be
   able to simply jump to it and back as fast as he or she can think.
   This depends a lot on the link speed of course.

   The other limit is the difficulty for a reader to scroll through large
   documents. Readers with character based terminals don't general read
   more than a few screens. They often only absorb what is on the first
   screen, as if that is not interesting they won't be bothered to scroll
   down. [36]Readers are also put off by being left at the top of a large
   document.

   Readers with graphic interfaces generally scroll through long
   documents with a scroll bar. When the scroll bar is moved a small
   amount, the document should move a sufficiently small amount so that
   some of the original window-full is still left in the window. This
   allows the reader to scan the document. If the document is any bigger,
   then it is basically unreadable, in that any movement of the scroll
   bar will loses the place and leaves the reader disoriented.

   Advantages with longer documents are that it is easier for readers
   with scroll bars to read through in an uninterrupted flow, if that is
   how the document is written.

   Also, one doesn't have to go to the trouble of making (or generating)
   so many links and keeping them up to date if things are altered. If
   making the links is a problem, just settle for one link to a contents
   page. Some browsers have [37]"next" and "previous" buttons to allow a
   document to be browsed serially according to a list.

   (In fact, one can normally scroll up and down explicitly page by page,
   but this is gives the same feeling as the terminal interface.)

   A rough guide, then, for the size of a document is:
     * For online help, menus giving access to other things: small enough
       to fit on 24 lines. Check this by using a terminal browser.
     * For textual documents, of the order of half a letter-sized (A4)
       page to 5 pages.

  REFER OR COPY?

   When you are setting up an information system which refer to
   information which is available elsewhere, be very careful before
   taking a copy.

   Here are some reasons for leaving it where it is:
     * When it is updated, you will either have to have a way of finding
       out, and make a fresh copy, or you will end up with an out of date
       copy.
     * If you feel that your copy will be easier to access, remember that
       this is relative. You will have readers from other places who may
       find the original is closer. If the original has a serious access
       problem, you could find another server (maybe offer your own) as
       the definitive storage point.

   Here are reasons for copying it:
     * If the information is transient, like a news article, you will
       have to take a copy.
     * You may want to refer to a particular version of something which
       will will be changed and not saved in an archive.

   You should be very wary before referring to your own private
   collections of the following, of which plenty of established
   collections exist:
     * [38]Internet FAQ *Frequently Asked Questions) lists
     * [39]RFCs (Request For Comments -- Internet standards etc)
     * [40]Information by subject
     * The "best" URLs on the web. Make a personalized list of pointers
       to things of specific interest. It will be more valuable!

Within each document

   This section of the [41]style guide deals with the layout of text
   within a "document", the unit of retrieval of information on the web.

   To be completed.

   You should try to:
     * [42]Sign your work
     * [43]Give its status
     * [44]Make links into context .
     * [45]Use context-free document titles
     * [46]Format device-independently
     * [47]Write for the printed work too
     * [48]Write readable text despite the links
     * [49]Avoid talking about mechanics

  SIGN IT!

   An important aspect of information which helps keep it up to date is
   that one can trace its author. Doing this with hypertext is easy --
   all you have to do is put a link to a page about the author (or simply
   to the author's phone book entry).

   Make a page for yourself with your mail address and phone number. At
   the bottom of files for which you are responsible, put a small note --
   say just your initials -- and link it to that page. The [50]address
   style (typically right justified) is useful for this.

   Your author page is also a convenient place to put and disclaimers,
   copyright notices, etc which law or convention require. It saves
   cluttering up the messages themselves with a long signature.

   (If you are using the WorldWideWeb.app hypertext editor, then you can
   put this link from your default blank page so that it turns up on the
   bottom of each new document automatically)

  THE STATUS OF YOUR INFORMATION

   Some information is definitive, some is hastily put together and
   incomplete. Both are useful to readers, so do not be shy to put
   information up which is incomplete or out of date -- it may be the
   best there is. However, do remember to state what the status is. When
   was it last updated? Is it complete? What is its scope? For a phone
   book for example, what set of people are in it?

   Not every document needs a status declaration, if there is something
   in the overview page of the work which covers it.

   You can of course also give a feel for the status of the text by its
   language ... bad spelling, missing capitals, and relaxed grammer all
   indicate informal notes. Careful use of verbs such as "shall" and
   "should", and the introduction of Long Capitalised Noun Phrases
   (LCNPs) will give at least the impression of an ISO standard. ;-)

    Date it

   In some cases it can be useful to put creation dates and last modified
   dates on your work. (Note that this is the sort of thing which one
   could make a server do automatically with a little programming).

   Figure out whether putting one might later save the reader from
   following out of date information.

  LINKING TO CONTEXT

   A major difference between writing part of a serial text, and an
   online document, is that your readers may have jumped in from
   anywhere. Even though you have only made links to it from one place,
   any other person may want to refer to that particular point, and will
   so make a link to that particular part of your work from their own. So
   you can't rely on your reader having followed your path through your
   work.

   Of course if you are writing a tutorial, it will be important to keep
   the flow from one document to the next in the order you intended for
   its primary audience. You may not wish to cater specially for those
   who jump in out of the blue, but it is wise to leave them with enough
   clues so as not to be hopelessly lost. Some ways of doing this are:
     * Watch that your text and vocabulary stands by itself. Starting a
       document with "The next thing we we consider is..." or "The only
       solution to this problem is..." will certainly confuse.
     * Sometimes the opening words refer to the context, and can be
       linked to background information. For example, in the [51]WWW
       project documentation, the first occurrence of the acronym WWW is
       often linked back to the central project document.
     * The navigation hints at the top or bottom of the document can give
       explicit pointers. Examples are at the bottom of this document.

   It can also be useful to imagine as you are writing that you yourself
   may wish to reuse the document. some day.

    Navigational Icons

   Icons make great navigational hints. It is very effective to have the
   same consistent icon throughout the work, always (except on the "top"
   page) linked back to the top page. This kills two birds with one
   stone: it gives consistency to the work, so readers know when they are
   in it and when they are outside it, and it also gives them a quick way
   of getting back to the top of it.

   You can do the same thing with sections, so that at the top (or
   bottom) of each page you might have a small string of icons, the first
   to go back to the top of the work, the second to go back to the
   chapter, the third to go back to the section within the chapter, for
   example.

   [This style guide was for a long time empty of icons because I was
   editing it with the old hypertext editor which doesn't handle images.
   I may fix that with time -tbl]

  DEVICE INDEPENDENCE

   The hypertext you write is stored in HTML language, which does not
   contain information about the fonts and paragraph shapes and spacing
   which should be used for displaying the document.

   This gives great advantages in that your document will be rendered
   successfully on whatever platform it is viewed, including a plain text
   terminal.

   You should be aware that different clients do use different spacing
   and fonts. You should be careful to use the structuring elements such
   as headers and lists in the way in which they were intended. If you
   don't like the rendering on your particular client, don't try to fix
   it by using inappropriate elements, or trying for example to force
   extra spacing with empty elements. This may well end up being
   interpreted differently by other clients and looking very strange. You
   can in many cases configure the client displays each element.

   For example:
     * Always use heading levels in order, with one heading level 1 at
       the top of the document, and if necessary several level 2
       headings, and then if necessary several level 3 headings under
       each level 2 heading. If you don't like the way heading level 2 is
       formatted, fix it on your client, don't just skip to heading level
       3.
     * Don't put extra spaces or blank lines into your text to pad it
       out, except in preformatted (PRE) sections.
     * Don't refer in your text to facets of particular browesrs. Asking
       someone to "click here" won't make sense without a mouse, just as
       asking someone to "select a link by number" will betray the fact
       that you were using the line mode browser. Just leave a link. The
       instructions get boring as the user will normally know how to
       select a link.

   See also: [52]testing your document .

   Following these guidelines you may find that the end result does not
   appear on your screen exactly as you would like, but your readers will
   probably be happier.

  PRINTABLE HYPERTEXT

   In an ideal world, paper might not be necessary. In a next to ideal
   world, one would have enough time to write a hypertext version of a
   document and also to write a completely separate paper version.
   However, the real world, you will probably want to generate any
   printed documents and online documents from the same file.

   Suppose the HTML files will be the master, and you will generate the
   printable from this, by making one long document, and possibly
   printing it via translation into TeX, or some word processor format,
   for example. You might not initially, but you might want to one day.

   Try to avoid references in the text to online aspects. "See the
   section on [53]device independence " is better than "For more on
   device independence, click [54]here .". In fact we are talking about a
   form of [55]device independence .

   Unfortunately, the recommended practices of signing each document and
   giving navigational links tend to mess up the printable copy, though
   one can of course develop ways of stripping them out if they follow a
   common format.

   For example, the most common comment about this document was that it
   is difficult to print. I therefore made a [56]single pageversion of
   the whole thing with a few scripts, and put a pointer to it from the
   [57]cover page. But then people still ask, not having read the cover
   page. (The scripts were just bits of "sed", which I am not supporting.
   I have put rules in at the top and bottom of each page and the scripts
   use these to chop off bits which are not needed in the printed copy.)

  MAKE YOUR (HYPER)TEXT READABLE

   This is just a little rant about two style issues in hypertext
   that[58] I'm seeing more of and don't like much.

   The first is the _here_ syndrome, e.g.:
        Information about Blah Blah Blah is available by clicking _here_.

   where the word _here_ is the link. This style is really awkward; when
   you click on 'here', you have to look around to make sure it is the
   *right* here. Let me urge you, when you construct your HTML page, to
   make sure that the thing-you-click is actually some kind of title for
   what it is when you click there. E.g. say
        Information about _Blah Blah Blah_ is now available.

   And use:
        Information on _how to do searches_ is available.

   instead of
        For information on how to do searches, choose _this link_

   .Not quite as bad, but still awkward is where someone will use a topic
   word as a link, but it still talks about the links:
        Here are links to a _CREDITS_ page and _technical details_ ...

   Instead, try to write something like
        Many thanks go to _various people_ for their contributions.

   _Technical details_ of this system are available now.I.e., make your
   HTML page such that you can read it even if you don't follow any
   links.

  AVOID TALKING ABOUT MECHANICS

   Announcements of internet services have typically been followed by
   pages for information about how to use FTP, mail servers, etc, to get
   at the information. The WWW is designed to make all this unnecessary.

   The temptation is to strip out these instructions and leave a link
   like:
        There is now [59]WWW accessto our large FTP archive which was
        previously only available by FTP, NFS and mail.  This
        collection includes much public domain software and text
        whose copyright has expired.

   The web is read by people who don't need or, often, want to know about
   FTP and NFS - or even WWW! So the following is better:
        Our [60]archive includes much public domain software and text
        whose copyright has expired.


   Keeping on the subject of discourse rather than the mechanisms and
   protocols keeps the text shorter, which means people are more likely
   to read it.

   Even when you are working within the web metaphor, use links, don't
   talk about them. For example
        You can read more about this in the tutorial which is
        linked to the home page

   obviously would be be better as
                The [61]tutorial has more about this.

   Another common one is
        The [62]tutorial contains sections on mowing, sharpening the mower,
        and buying a mower.

   Give the reader a break, and let him or her jump straight there!
        The [63]tutorial contains sections on [64]mowing, [65]sharpening the mo
wer,
        and buying a mower.

Test your document

   In a way your hypertext is like a book, which you should have
   proof-read. In a way, it is like a program which you should have
   tested. At least get someone from the target group for which you wrote
   the document to read it and give you some feedback. Other ideas are:
     * Read the document several different client programs, to ensure
       that you have formatted it in a [66]device independent way.
     * Monitor the readership of your document. You can do this by
       analysing the server [67]log files . You may find that some parts
       are not being read, perhaps because people are looking in the
       wrong place for them. You may see that people often follow a path
       and backtrack. If you can guess what they were looking for, you
       can make the clues around the link more helpful. (Remember to keep
       log information confidential until you have removed user
       information from it.)
     * Make it clear whether your will accept criticism or suggestions
       from your readers, and how they should send it.
     * Ask people to solve problems using the document, and report on
       their success. If they fail, find out what they were looking for,
       whether it was in the document at all,

  HOW MUCH TESTING?

   Testing takes time. The decision of how much testing you do is based
   on the quality of the document you wish to provide. You are balancing
   your reader's time and effort against yours. If your document is
   "selling" an idea, or if you are selling the document or providing a
   service, you will want to make it as easy as possible for the reader.
   If many people will read your work, a little of your time will save a
   lot of theirs.

   If however you are documenting some obscure part of a system in which
   no one other than yourself is likely to be interested, or if you feel
   that your readers are lucky to have anything available at all, there
   is no point wasting time testing it. In the event of someone needing
   the information, they might have to go to some extra trouble to follow
   several links to find what they want, and then to understand what you
   have written. This may be the most efficient way of working. I
   emphasize this because there is very much information which is for a
   fleeting moment in people's minds, or is hastily scribbled down on
   some file, and which may be important to posterity. It is better for
   this information to be available even in unpolished form than for it
   to be hidden out of embarrassment for its form. Before electronic
   technology, the effort of publishing was such that this information
   was never seen, and it was a waste, and and considered an insult to
   one's readers, to publish something which was not of high quality.
   Nowadays, there is "publishing" at all levels, and both high quality
   and hasty documents have their value. It is important, though, to
   [68]make it clear what the quality of a document is when making a
   reference to it, to avoid disappointment.

   Monitoring the server log files will tell you which documents are
   really being read. You can use your time most efficiently to improve
   the quality of those. Of course, analysing the server log files also
   takes time!

Background reading

   Some other documents which may be of relevance, if you are reading the
   [69]Style Guide for Online Hypertext :
     * [70]The HTML Specification and references from it
     * [71]A Beginner's Guide to writing HTML
     * [72]World-Wide Web server software - a list of pointers
     * [73]Web Ettiquette -- for Server Administrators

   This list is far from complete. There are many books now (1994) about
   how to buld a web site and write HTML. If they have a common failing
   it is that they assume a particular browser. Pick one which inspires
   you, as they are generally full of enthusiasm and good ideas. Browse
   the web, get your own ideas, and mail me mentioning the guide.

[INLINE] Reader comments

   I have put these in a list apart from the rest of the [74]guide as
   some of them may be specific views from specific insitutes.

     * [75]Lutz Falkenhagen

     * [76]Robert Stockton

     * [77]Lars Aronsson
     * [78]Scott Nash
Date: 15 Apr 93  8:23
From: "(Lutz Falkenhagen)" <falken@tnt.uni-hannover.dbp.de>
...

we use WWW as a local information server at the moment and I am responsible
for installing the clients and to establish the document style.

We agreed that it is useful to add the date of creation in the document title
and to sign the document at the bottom with the name of the author. This name
is a link to a document with the whole address of the author. We agreed on a
date format 06-FEB-1993, because this format is known by everyone, although it
is not the nicest (it reminds to VMS).

Introduction and overview pages shall not exceed the size of the client window.
These pages should also be arranded in the form of tables or lists.

Each page should not contain more than three formats:
e.g. h1 - (ul,li,dd) - address

I suppose the arrangement of content, that we havedefined in our institute, can
not be fixed in general.

        Lutz



Date: 22 Apr 1993 00:36-EDT
From: Robert.Stockton@elrond.gandalf.cs.cmu.edu
To: timbl@nxoc01.cern.ch
Subject: Re: Style Guide for Online Hypertext

I have read through your style guide (via XMosaic) and, although, I am
certainly pleased with the current contents, I have some additional
questions concerning formatting trade-offs that are not covered.

I have recently been experimenting with producing browsable versions of
the various Project Gutenberg etexts (which are, by nature, fairly flat
texts) and have been trying to figure out tradeoffs between placing each
chapter in a separate file vs. keeping the entire document in a flat
file with a separate index page that points to individual chapters via
named anchors.  The tradeoffs that I have identified are the following:

In favor of multiple files:
* Individual [79]file retrieval times (and possibly memory usage) are
  reduced
* [80]Users will not be scared off by the sheer size of the document

In favor of a single file w/ named anchors:
* The user may follow the flat structure by simply scrolling through the
  file, without having to navigate around chapter boundaries
* The document is more likely to be consistent, since there is no need to
  keep "next/previous" links
* The elimination of navigation links for flat browsing makes it easier
  to leave the document via the "back" command.

The last point mentioned above seems especially significant to me.
Since xmosaic/WWW allows you to jump through a wide variety of contexts,
I depend upon the ability to use the "back" command to return to my
starting point.  When I have been browsing through an "info-like"
document (such as the style guide), I must pop a great many
sub-documents off of the stack in order to get out of that document and
back to the link that led me there.

Ideally, I would like to see browsers implement a "next-document"
command which pops back to the "parent document" and then immediately
follows another link to some logical successor to the current document.
(This choice would not always be straightforward, but in many common
"menu selection" cases it would be obvious.)  This would not only
simplify linear reading of linear documents, but would allow (without
zealously enforcing) multiple linear orderings of the same set of
documents.

My questions:
  1) Am I missing some important point which would invalidate my
     reasoning?
  2) Would these issues be worth discussing in the style guide?
  3) Should I, perhaps, start agitating for a "next-document" feature in
     xmosaic?

                                        Robert Stockton
                                        -rgs@cs.cmu.edu


Date: Mon, 3 May 93 07:55:24 +0200
From: aronsson@lysator.liu.se

Hi,
  My name is Lars Aronsson.  I co-maintain the WWW service at
www.lysator.liu.se port 7500 (see file Main.html).  I have read
[81]Tim's Style Guide and [82]Robert's "reader's comment" using X Mosaic.

First, Tim, I have told you before that this is a good thing.
However, after having written my first HTML structured documents,
I must add that the Style Guide deals a little too much with
basic issues that could be summarized as "use your brain".
There are some issues, like those Robert mentions, where we need
to find answers, and the present Style Guide does not provide them.

Robert, my experience is very similar to yours.  I have some large
texts in plain ASCII that I consider to add to our WWW service, and
I might also consider writing new texts with WWW in mind.

The concept of a tree structure as a base for hypertexts is good.
It is used for example in GNU Emacs info documents.  The problem,
as Robert states, is to maintain the Up, Previous, Next links.
Also, with HTML/WWW every "Document" is a separate file, which
makes maintenance more complicated.  In GNU Emacs info, all
"Documents" in a "structure" (all chapters in a book) are contained
in one file.

Some of the Previous and Next links in Tim's Style Guide are missing.
This makes me believe you maintain those links manually, Tim.

I have made a prototype program in C++ that reads a GNU Emacs outline
format file and creates many HTML files where the Up, Previous, and
Next links are added.  Every section of the outline file becomes a
separate HTML file.  All I do is to maintain the large outline file.
The children of a document are automatically listed in a <ul> list
in the parent document.

Robert, I can only agree with your comments about the Back function of
X Mosaic.  The history paths get too long for the Back button to be
useful.  The history paths should be shortcut whenever possible.

Lars Aronsson
     Aronsson@Lysator.LiU.SE





Date: Wed, 3 May 95 18:43:49 JST
To: timbl@w3.org
From: snash@cac.co.jp (Scott Nash)
Subject: HTML Guide

   I have a comment on style that I feel relevant to HTML page structure
   in general and your setup in particular -- small documents with too
   many links to other documents when one larger document with links
   inside that document might be more appropriate.

   As an example, when I viewed your document, I had to hit Intoduction
   just to see a page of info, then move back to the main menu to jump to
   another area of text. Much of time, I like to save my information or
   print it out to read on my train ride into work. Jumping around and
   having to continually reload to see what could be presented in one
   slightly longer document with links inside seems to be more work than
   necessary.

   Of course, if the documents are loaded with pictures or there is the
   problem of server load, that is another matter, but all in all, even
   at 2400 baud, waiting for another 5k of text to load is preferable to
   having to click all over the place for it.

   Thanks for your time.


    Scott Nash CAC, Tokyo Japan

Disclaimer and Copyright


    [83]MIT / [84]LCS 545 Technology Square, Cambridge MA 02139, USA

   This information is provided in good faith but no warranty can be made
   for its accuracy. Opinions expressed are entirely those of [85]myself
   and/or my colleagues and cannot be taken to represent views past
   present or future of our employers.

   Feel free to quote, but reproduction of this material in any form of
   storage, paper, etc is forbidden without the express written
   permission of the author. Intellectual property rights in this
   material may be be held by the author, CERN and/or MIT. All rights are
   reserved.

   If you notice something incorrect or have any comment which you don't
   think is a FAQ, feel free to [86]mail me. If I don't get around to
   answering, please forgive me -- I try to answer everything!


    [87]Tim Berners-Lee
