One of the most frequent complaints of users of technical documentation is that the texts contain a lot, but not that, what they are looking for. Technical writers usually reject this accusation and claim that the product is "fully documented". Both are right. Often, relevant information is really present somewhere, but the users simply do not hold out long enough until they find it. And even if a user does not give up and actually finds the information, he or she has spent way too much time getting there and built up a lot of frustration in the process.

Unlike documents that try to cover everything, technical documentation generates confidence, security and satisfaction only if it offers as little information as possible, and if this information really helps the user in a specific situation.

This need not be a contradiction to the concept of complete documentation, and does not imply that a help which offers only little information also actually contains little information. The art is in guiding the user to the relevant information quickly, and in creating levels of information using the method of Information Layering, hiding all that is irrelevant.

The concept of Information Layering is not new, and we encounter it daily in all walks of life. One example familiar to everybody is to be found in railway timetables. The most important information is emphasized optically through bold lettering and font size: destination, departure time, platform number and the most important intermediate stops. This information is of interest to all travelers and contains the key landmarks in a search for the right train. As against this, all other information that is of interest to only a minority, is relegated to the background visually, or is represented by symbols. The result: no one is forced to read through the entire timetable to find a particular train. How nice it would be if this were always the case with technical documentation, too!

In advertising or in product presentations, layering techniques are used to direct our attention towards specific things, and to keep it away from others. One example is in the packaging of foods: motifs and slogans effective in advertising can be recognized from a distance. But to read the cooking instructions, or to find the expiry date, most people would need their glasses. From the users assistance point of view this is a complete failure in presentation, because precisely that information which every consumer needs to know repeatedly, as a "user" of the packaging, is the most difficult to find.

For those of us in the field of technical documentation, therefore, the basic question when it comes to layering should be: What does the user want to know? And never the question: What do we want to tell the user?

The information layers across which you should distribute your information depend to a great extent on the product that is to be documented, and its specific target group. Ask about the users’ goals and, in a first step, analyze what information the users need simultaneously. Information that is required simultaneously should always be compiled into one information layer.

Example: Imagine you would like to document a certain program module, such as a complex dialog. The simplest approach here, without any information layering, would be to describe the dialog in just one topic, as comprehensively as possible: the basics, the parameters and all particularities of use. However, if you ask yourself the question: "What information is needed by the users simultaneously?", the result is totally different. Only beginners will need basic information about the purpose of the dialog. However, at this time these users are not ready to be interested in special parameters or any particularities of use. On the other hand, advanced users already know the purpose of the dialog and might just need a little a little piece of information on one specific parameter. And if we are honest, most occasional users are neither interested in the purpose nor in the special parameters, but just want to get their job done and are therefore looking for a simple step-by-step instruction.

Thus, a detailed description of the dialog does not help any of these users. Everybody will have to wrestle with a lot of information that is really of no interest to them at all.

If we build a user-centered information model oriented towards the information goals and scenarios of the users, we are left with three divisions of the topic:

Fig. 1: Layering mixed information according to information types

In addition to the information type you can in practice often also layer according to one or more of the following criteria :

Layering need not be restricted to the topic level, as in the previous examples. It should begin at the topmost structural level and continue consistently, right down to the level of the sentence.

At the highest structural level, layering begins with a discerning segregation into special documents for different purposes (such as "Setup", "Operation", "Maintenance"), phases of use (such as "Getting Started Guide", "Advanced Users Guide") or user groups (such as "Help for Operators", "Help for the Administrator"). Within a topic, merely following the elementary principles of good technical documentation itself results in a meaningfully layered structure. The basic concern is to burden the reader with as little reading as possible:

If you decide to "layer" your contents, you should also structure the navigation accordingly. Allow the user to move on within an information level, or to go directly to another information layer. In practice, you could implement this, for instance, by organizing the links to related topics according to the various layers that they refer to, instead of listing them arbitrarily in a long list. Thus, for instance, all links concerning step-by-step instructions will be collected together, followed by all the links to reference topics. Again, the sequence within the various groups should be determined by the basic rules: what is used more frequently comes before what is used rarely, what is important precedes the less important.

Normally, it is useful to interlink all layers of a thematic context. Example: In figure 1, we had split the contents that were earlier treated as one unit into three layers "Concepts", "Instructions", and "Details". In this case, the topic containing the concepts should provide a link to the topic with instructions, as well as a link to the topic with the details. Equally, the topic containing the instructions should provide a link to the topic with the concepts, as well as a link to the topic with the details, and so on.

One layering method which has become increasingly popular in recent times are expandable sections, also referred to frequently as "expandable paragraphs" or "dropdown text". In this case, topics consist of a mixture of contents that are visible always, and those that are hidden behind clickable subheadings, when the topic is first loaded.

If the user clicks on such a subheading, the additional contents appear in its place. The remaining part of the main text automatically scrolls down. A lot of authoring tools offer built-in support for this and automatically generate the required Dynamic HTML and JavaScript Code. With a second click on the subheading, the user can blot out the additional contents once again, and regain a complete overview of the overall context. Expandable sections may consist of one or more paragraphs, tables, graphics and animation.

If you are reading this text in its online version, you are just right now in the middle of an expanding section. If you are reading this text in its printed version (PDF), this section appears as a normal paragraph below a normal subheading.

Expandable sections are often successful in putting together contents into one single topic, which would otherwise have to be distributed across several topics. This imparts more clarity to the hierarchical structure, and navigation becomes easier.

As related contents will be located under one topic, additional navigation links become largely unnecessary. Another advantage is that the user does not have to move away from the actual topic, and the contextual coherence is better retained.

When in doubt whether to use an expandable section or not, the basic criterion should always be: Layer some information only in an expandable section, if this information is not vital for the majority of the readers. This can be, for example:

When describing complex dialog windows, you can also use expandable sections very efficiently for summarizing the descriptions of separate parameter groups and to keep the description of the dialog itself clear and uncluttered. The first layer of information, which is always visible, could describe the purpose and logical structure of the dialog. This information is usually adequate for the majority of users, at least for a basic use of the dialog. The expandable sections contain the descriptions of the individual details and need only to be opened rarely.