Strategies for Using Information Types in HTML Help

Information types are a new feature of HTML Help, but they are not a new concept to technical communication. Information types are simply categories of information that can be assigned to a discrete piece of information so the information can be displayed or hidden, based on the category selected by the user. The goal of this paper is to get help authors thinking about ways that they can use information types to help their users filter, sort, and understand the structure of the information presented to them through online help.

Introduction
Information types are a new feature of Microsoft’s HTML Help that allows you to "tag" information so the users can filter the information they don’t need, retrieve the information they do need, and understand the structure of the information that is being presented to them. Basically, information types are categories of information based on its content, users, use, or form.

The concept of information types is not new. Techniques such as Information Mapping have emphasized the need to identify information types as a part of the writing and design process. Knowing the type of information has been an important part of determining the structure of the page. With the availability of information types in HTML-based help, technical communicators can now provide multiple potential structures for the overall document which the users can control as they interact with the information. Where we used to create multiple user manuals or online help files to anticipate how the information might be used, we can now provide one source of information and let the users decide how they want to filter it.

Before we can use information types, however, we must understand how they work and why they are important. We must understand how information types are already an inherent part of how users interact with information. We must consider the instructional design principles that guide our use of information types, keeping our users’ tasks and abilities at the center of our designs. And we must start thinking about ways we can implement information types to create more customizable, flexible, usable online help that is controlled by the user.

How do information types work?
During help development, the help author assigns information types to the help topics. This means that help authors should identify the information types they want to use during the planning stages before the text is written or at least by the end of the implementation stage, where the text is all or mostly written. HTML Help allows help authors to identify up to 32 information types. These information types can be grouped further into up to 10 categories. Although HTML Help does not require information types to be placed into categories, RoboHTML requires that all information types be included in a category. Information types are assigned to individual help topics (pages or books). If a help topic does not have an information type assigned to it, it appears for all users regardless of the information types chosen.

In the user environment, information types are chosen by right clicking on the contents window of the HTML help file (or by clicking the Options button) and choosing Customize. Users are presented with a wizard that allows them to choose all information types or to select a subset of information types. Information types can be either inclusive or exclusive, which is determined by the help author. Inclusive information types allow the user to choose more than one inclusive information type in a category at a time (for instance, procedure and reference). Exclusive information types allow the user to choose only one exclusive information type in a category at a time (for instance, English or Spanish). A third attribute called "hidden" exists to exclude topics like field-level help from the table of contents.

At this time, information types only filter information in the table of contents. They do not restrict the Index or Search tabs. In order for information types to work, the help file must be compiled.

For complete instructions about how to implement information types, refer to the online help that comes with HTML Help Workshop. Make sure to consult the ReadMe file through the help for a current list of problems with information types and HTML Help in general.

Why classify information?
Users instinctively classify information when interacting with documentation. They have to decide (usually rather quickly) if the information they are viewing meets their needs. They may see the information as on or off topic, general or specific, or something related to their job or something that somebody else is supposed to do. Many users of online help are trying to answer a specific question or solve a problem, which means they enter the help looking for the type of information they believe they need.

With information types, help authors can help the users accomplish three important goals: (1) filter (or sort) the information, so they can find what is and isn’t relevant to their situation, (2) retrieve the information they need faster, (3) and understand the structure of the information that is being presented to them. Classifying information is a natural part of filtering, sorting, and understanding the structure of information. Help authors can provide users with a headstart by helping them classify and identify types of information.

These three goals are traditional documentation goals; however, they are more easily accomplished through online help.

The first goal, filtering, is well-known to help authors. In WinHelp, some help authors tried to help users filter information through alternative tables of contents. Some authors even provided shortcuts from the Help pull-down menu to sub-contents in the help. And, of course, context-sensitive help was an effort to help users go directly to information that was relevant to their task. Additional filtering techniques include See Also or Related Topics sections at the end of topics as well as links in the non-scrolling region such as How To and Examples.

The second goal, retrieving, has also been addressed in WinHelp. First, an index was provided that allowed users to type keywords and move to the related topics quickly. Later, a full-text search was added so users could find specific words that the help author may not have included in the keyword index. And more recently Answer Wizards allowed users to type questions that retrieved help topics related to their inquiry.

The third goal, understanding the structure of the information, has not been treated as much by WinHelp. The main attempt was adding the tree view of the help contents, which allowed the users to expand and collapse books until they found the pages they needed. The structure of the information was reinforced when the users would perform a search, locate a topic, then see in the tree view how that topic was situated within the overall help. The reason users need to understand the structure of the help is so they can build a mental model of how it is organized, which helps them know how to navigate through the help and devise strategies for using it.

If help authors can anticipate how their users will classify the information in the help, they can assign information types to the help that assist the user in filtering, sorting, and understanding the structure of the information. Help authors may determine the major categories through usability evaluations, including audience analysis, interviews, and formal testing. The information can be classified using information types, which can be further reinforced through distinctive design cues that help the users know what type of information they are viewing. The end result is more usable online help.

How do we classify information?
For this discussion, I propose that information types fall into four main categories: content, users, use, and form. Content refers to the nature of the information that is included in the help. Users refers to the levels of users’ experiences and the cognitive tasks they are trying to complete. Use refers to the situation where, when, or how the information is used. Form refers to the delivery and format of the information.

Although help authors will discover many more uses for information types in the years to come, in this paper I will discuss eight basic information types.

Kinds of information
One of the best known classification systems for kinds of information is Information Mapping, which groups information into seven major types¹:

• Procedure (action/steps)
• Process (how something works)
• Structure (equipment)
• Concept (definitions/new ideas)
• Principle (rules or guidelines)
• Classification (data)
• Fact (categories/lists/types)

For Information Mapping, placing information into these seven groups helps determine the page organization for a single topic. On a document level, a similar approach could be taken. For instance, information could be placed into high-level groups such as: policies, procedures, troubleshooting. Users could choose the kind of information most appropriate to their situation. Or the information types could denote the kinds of information at a lower level. For instance, the Microsoft Word online help could use information types such as styles, tables, headers and footers, index, and table of contents. An income tax application could use information types such as IRS regulations, how to use TurboTax, and advice for record keeping.

One rule of thumb for how to identify kinds of information is to think about what kind of manual the information would logically go in if you were writing manuals. Think about the different kinds of manuals: policy manuals, user manuals, troubleshooting guides, reference manuals, quick reference cards. All of these kinds of manuals reflect kinds of information. Our industry has moved away from creating individual manuals based on kinds of information contained in them because of cost restrictions. HTML Help allows us to deliver a single help file that still provides the benefits of separating different kinds of information.

Features of product
Another way to identify information types based on the content of the information would be to base them on the features of the product. For instance, the tool Kai’s Photo Soap is organized around the metaphor of a graphics lab, including several rooms:

• In Room
• Prep Room
• Tone Room
• Color Room
• Detail Room
• Finish Room
• Out Room

In this case, the product interface reflects both the areas of functionality in the application as well as the process of touching up a photograph. The information types for the help could be based on the rooms (features of the product).

An even better example would be an application that combines several tools in a single interface. If users want help only for the one tool they are using, they should be able to use the information types to filter out the help for the other tools.

Some products may be "customized" for different users, where builds are made that include different features or a reduced functionality version is made to lower the product cost. In this case, a single help file could be written for the overall product, and information types could be used to specify which features are included in the customized product.

Basing the information types on the features of the product might also lead to information types that reflect the release when the feature was added. For instance, some products go through several releases in a single year. Users of these products often have a hard time figuring out what information is new. To help the users get up-to-speed, technical communicators create special documents to highlight and explain the new features, they deliver update training, and sometimes they just list the new features in the README file and expect the users to investigate on their own. If information types were assigned to help topics to reflect the release when they were added (or updated), users could choose the information type for the most recent release and review the new features in the help file. A significant advantage of basing information types on releases of the product would be delivering a single help file for multiple releases.

Levels of users
When we talk about levels of users we often use the terms beginner, intermediate, and advanced. In this case we are talking about the level of the users’ skill using the product. In some cases, there may be advanced topics that might confuse a beginning user or more detailed topics that might annoy an advanced user. Information types would let users choose the skill level that they prefer. The problem with such distinctions is determining how users would know which category to choose and how they would progress to the advanced topics as they learn to use the product more proficiently. Help authors must also remember that a novice user to a product may be an expert in his/her field (for instance, an accountant using Quicken). Also, someone new to a product may have expert skills using a similar tool (for instance, a person migrating from WordPerfect to Word).

Basing information types on the skills of the users may be a good idea, but the topics should be inclusive rather than exclusive. This would allow a user to see all of the topics at the same time. Making the information types exclusive could make it harder for users to locate the information they need because they might be an expert using some features of the application (style sheets) while they are a beginner at others (mail merge).

Rather than use the terms beginner or novice and expert or advanced, try to make the information types more descriptive of the information they represent. For instance, an accounting application could use a category called "Type of user" with information types such as:

• Accountants
• Users who have used earlier versions of this product
• Users preparing records for their accountants
• Users filing their own tax returns

Users should be able to place themselves into the groups you use quickly without hesitation.

Cognitive tasks
Basing information types on cognitive tasks requires that you know what mode the users are in when they are using the information. Are they trying to learn? Are they trying to do something? Are they trying to troubleshoot a problem? What are the users goals for reading the information?

You may also need to account for different types of learners: top down learners v. bottom up learners. Top down learners are conceptually driven; they like to get the big picture before they start learning about the details of the product. They want to know how it all works together and what is the overall process (overviews and concepts). Bottom up learners are data driven; they want to learn to do things and then figure out how everything fits together. They tend to be active learners who want jump into the product and learn as they go (fast track instructions).

A good example of organizing information around cognitive task can be found in Conrad Gottfredson’s "One-Stop Documentation," which uses a modular design to support different cognitive tasks². The basic goal of a one-stop document is to create a single manual that can be used during training in the classroom as well as on-the-job after the training is complete. When users are learning to use the product, they are focus on overviews, terminology, key concepts, and practice and review. Bottom up learners may prefer to move right to the procedures, which they can do because the manual is modularized. When the users are in the workplace trying to do something, they are concerned with procedures. When users need to answer questions, they turn to the reference materials in the appendix.

HTML Help could be modularized in the same way using information types. In some ways, this information type is similar to kinds of information, but it goes a step further by anticipating learning v. doing v. referencing and by distinguishing between top down learners and bottom up learners.

Information function
Information types can be based on the function of the information. In How To Write Usable User Documentation, Ed Weiss identified four functions of user documentation: Orientation (to train new users), Guidance (to train experienced users), Reference (for people who know what they need to know), Motivation (selling ideas and methods). These first three functions could become information types: overview, procedure, and reference. Motivational text is not extensively used in online help, and when it is it is combined with the other types of information, so it would not make a good information type.

A good example of information types based on the kind of information is the Windows 95 online help contents, which includes topics such as:

With information types, the table of contents does not have to be based on the types of information because the users can select the information types they want to view. This means that a help file such as the Windows 95 online help (when moved to HTML Help) could use overview, procedure, and reference as its information types but have a different contents to reflect the actual content of the help file such as:

Each of the books above might include several overview, procedure, and reference pages beneath them. If a user chose procedure as the information type, the contents might remain the same but the number of pages beneath each of the books would be reduced, allowing the users to view only step-by-step instructions.

Job functions
When creating information types, help authors could consult the official job descriptions of users to classify the information functionally. Information types based on job descriptions may be ideal if part of your objectives are teaching or reinforcing an organizational process. Separating information by job function can help users understand what they are and are not supposed to do. However, job descriptions and job functions do not always match. Many employees wear different hats, even if their job description does not explicitly say so. If there is a substantial cross-over of job functions, then the information types should be made inclusive rather than exclusive. If functional areas overlap significantly, job functions should not be used as information types.

For example, a company uses a customized application to link the overall sales process. The Headquarters Sales team uses the tool to target potential customers; the Sales team in the field use the tool to get more detail about a targeted customer before visiting them in person; the Contract team uses the tool to create the contract; and the Finance team uses the tool to manage costs and billing. These job functions may be very distinct. Perhaps the user interface even changes for each type of user who logs in. In this case, the help could use information types based on job functions and possibly even use the exclusive attribute.

Suppose that for this same tool the most experienced Sales people in the company can target the customer, make customer visits, create contracts, and even review the billing information. If these users could not view all of the help topics at once because the information types used the exclusive attribute, it would be inconvenient for them. Perhaps the information types would still be based on job title but they should use the inclusive attribute.

Types of media
Help authors may want to indicate the type of media available in the help file so users can locate specific ones they want. For instance, they could create information types based on regular help topics, web-based topics, and tutorials. The icons associated with these types of topics help distinguish information in this manner to some extent already. However, some users seem motivated to explore the help when they can isolate the more graphical or interactive components of the help file. These flashier methods of displaying information could result in further exploration of the help file and the product.

Languages
Information types could be used to deliver multiple languages in a single help file. Maintaining and distributing a single help file can be easier from a development standpoint. HTML Help is supposed to support programmatic selection of information types, which would allow the language of the help file to be chosen during installation of the product.

A related information type would be to specify the operating system – the language of the computer.

This approach is not a strong option now because the Index and Search are not affected by the users choice of information type. Also, the programmatic selection of information types during installation does not appear to be possible yet. However, these limitations may be fixed in HTML Help Workshop soon.

Conclusion
One very important point to make about information types is that they should not be the only cue the users get to the type of information they are reading. Even after users select one or more information types, they should know as soon as they see a topic what kind of information it contains. When users interact with information, they want cues so they can immediately identify the kind of information they see so they can skip what they don’t need. Of course, foreign languages and numbered lists may already be visually distinctive, but the more subtle types should stand out as well. This means that once you identify the information types you want to use for a help file you should integrate those choices into your overall help design. For instance, if you decide to use three information types based on job function, then make sure the users can tell what job function a topic relates to when they look at it. You can do this through use of icons, repeating text in the title, or consistent use of font or color changes in the heading (avoid color changes). Remember that users who choose to view all information types still have to find what they want quickly and easily if your help file is to be successful.

Another concern is how help authors should use the inclusive and exclusive attributes. In most cases, information types should use the inclusive attribute because it allows the users to view as many information types as they want. The goal of information types is to help guide the users, not to create road blocks or inconveniences for them. The following table suggests what attributes information types should use.

A final caveat is that the overall number of categories and information types should be limited. Just because we can assign 32 information types does not mean we should. Once the users have to concentrate to decide which information type to choose, we’ve added to their information overload rather than helped them avoid one. We should identify all possible information types, then choose the ones that will be most helpful to our particular users.

My goal for this paper was to get help authors (including myself) thinking about ways that they could use information types to help their users filter, sort, and understand the structure of the information presented to them through online help. While information types are one of HTML Help’s impressive improvements over WinHelp, they are not a good enough reason to start creating HTML Help. There are several bugs related to information types in HTML Help and plenty of problems that are even more significant. If you do not have a solid reason for moving to HTML Help, you should probably wait.

Don’t wait to learn about HTML Help though. Download the HTML Help Workshop from the web (www.microsoft.com/workshop/author/htmlhelp/) and create some HTML Help files.

If you have any good ideas for how to use information types, share them on the Winhelp listserv or send me e-mail at rob.houser@pobox.com.

References

• Horn, Robert E. Developing Procedures, Policies, and Documentation. 1992. Publication is available through training only by Information Mapping. Contact 781-890-7003.
• Gottfredson, Conrad. One-Stop Documentation. May 1993. Publication is available through training only. Contact 801-379-3337.