Test your document

In a way your hypertext is like a book, which you should have proofread. 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 using several different client programs, to ensure that you have formatted it in a device independent way.
• Monitor the readership of your document. You can do this by analysing the server 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 you 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 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!

Testing your HTML

If you are using hypertext editing software, then your files should always contain valid HTML. Currently though, many people are editing HTML files as plain text files and having to get the markup right themselves. If you are in this category, then it is well worth running the HTML you write through an HTML checker. (There are some pointers to these from the W3C HTML overview.) It is also a good idea when you use a new HTML generation tool to test its output once. There are pointers to clients (some with HTML editing capability)and pointers to more lists in the client list.)