Online Technical Writing: Highlighting & Emphasis

Note: This chapter refers to certain other chapters that are not yet complete. Sorry for the inconvenience.

One of the problems in technical writing---in particular, technical writing about computers--involves the use of the various techniques for emphasis. Unfortunately, some technical texts go overboard on the use of the various emphasis techniques which are discussed here.

Actually, several problems involving emphasis can occur:

• Overkill. Emphasis techniques can be used in excess---the text swarms with a dizzying array of bold, italics, alternate fonts, caps, color.
• Inconsistency. Emphasis techniques can also be used inconsistently, which sends conflicting, confusing messages to readers.
• Illogical function. Emphasis techniques can also not be in keeping with readers' needs. Writers may choose the wrong things to emphasize and fail to emphasize the right things.

What is the point of using emphasis techniques? Used properly, they highlight text that readers must see, for example, alerting them to actions they must take or avoid. Emphasis techniques can make following a procedure considerably easier. But the design of the highlighting scheme (which organizes the emphasis techniques around a system of use) must be based on the reader, the tasks that the reader must accomplish, and the characteristics of the text (or the technology) that the reader is using.

Consider a few fundamental principles of emphasis:

• Practically anything that is different from regular body text can function as an emphasis technique.
• Things like italics, bold, underscores, caps, different size type, alternate fonts, color, the various graphical ingenuities (showing, reverse color, outline fonts) can act as emphasis techniques.
• Used in excess, any emphasis technique or combination of emphasis techniques can lose their ability to emphasize and become busy and distracting.
• Used in excess, any emphasis technique or combination of emphasis techniques can cause readers to be reluctant to read a text, if not avoid it altogether.
• When extended text must be emphasized, use the special-notice format (rather creating all-bold or all-caps paragraphs, for example).
• A carefully planned functional relationship must exist between the text that is emphasized and the emphasis technique that is used.
• Emphasis techniques must be used consistently to prevent readers from becoming confused.
• To promote consistency, you must use a style guide or style sheet, which records all of your decisions about how you are going to use emphasis techniques.
• To help your readers understand your highlighting scheme, you must include a brief section somewhere in your document (usually in the preface) explaining how you're going to be using the emphasis techniques.

In the following discussion, you'll notice that any system of emphasis techniques can get quite complicated and hard to remember. You'll notice that there are many equally valid ways of using emphasis techniques: for example, in some cases, it's arbitrary whether you use bold or italics. To offset this complexity, you must document your guidelines for emphasis in a style guide. A style guide is simply a record of the decisions you and your documentation team have made about how you want your documents to look.

Your readers also need to be informed as to the highlighting scheme you plan to use. This can be handled in the preface: include a section called "Highlighting" or "Typographical Conventions" where you list how you use italics, bold, fonts, and other such effects. For an example, see the discussion of prefaces in the chapter on standard components of technical books

This next section goes one by one through the various emphasis techniques, explaining the common practices.

Bold. In publishing, technical publishing in particular, usage is mixed as to whether to use bold or italics for basic emphasis. For example, if you want to emphasize that readers should not turn off the computer without first shutting it down, the "not" can be bold or italics. Traditionally, italics has been used, but, perhaps because of computers, bold is commonly used as well.

Whichever technique you use, use it consistently throughout your text or library of related texts. By the way, readers are not likely to be able to distinguish between levels of emphasis: for example, using italics for important text and bold for very important text is likely to be lost on most readers.

If you are tempted to make an entire paragraph bold, remember one of the principle of emphasis discussed above: using too much of an emphasis technique causes the effect of the technique to be lost. Not only that, but too much emphasis makes readers less inclined to read. Instead of carefully reading an all-bold paragraph, readers may just ignore it entirely!

Instead of creating an all-bold paragraph, use the special-notice format. In it, a key word (for example, Important, Note, Danger, Caution, Warning) is bolded, while the rest of the text is left regular roman (that is, the same font and style as the regular body text).

Legitimate use of bold in technical texts varies widely. As long as you develop a scheme that is directly related to the reader's need and to the characteristics of the text (or technology) and that does not lead to overkill, your use of bold should work fine.

Here are some common, standard uses of bold:

• Simple emphasis. As discussed in the preceding, some technical texts use bold for simple emphasis instead of the traditional italics. For example, "Do not turn off the computer before shutting it down."

• Headings. Obviously, headings use bold in addition to other typographical effects such as different fonts, large type sizes, italics, and even color.

• Commands. Computer texts commonly use bold for commands, for example, "Use the move command to rename UNIX files." See the section on highlighting computer text for a review of the complete set of emphasis techniques.

• Buttons that initiate commands. In a graphical user interface, some of the buttons initiate commands. For example, "press the Exit button to exit the application."

• Field labels. While some computer text bolds field labels, it is not general practice because it leads to highlighting overkill. For example, "In the Indentation area of the dialog box, click on Left." More common is to use the cap style used on the screen. Though by no means standard, it's preferable to write this: "In the Indentation area of the dialog box, click on Left."

• Keyboard or mouse buttons. Another highlighting technique not commonly in practice is to bold the name of a keyboard key or mouse button. For example, "Press the Q key or the left mouse button."

• Information that readers supply. Some computer texts bold text that readers are to type in, but certainly not all. For example, "Type guest and press the Enter key." (The section on common highlighting schemes for computer text points out that an alternate font, typically Courier, is used for text that readers must type in: "Type guest and press the Enter key.")

• Information displayed on the equipment or screen. Some computer texts also bold messages that are displayed on the screen, for example, "The system will then display Do you want to continue?" Some texts also bold the code numbers and letters displayed in the digital read-out windows on computer hardware. For example, "As the computer boots up, the digital read-out window will display 8888." (Again, computer text commonly uses an alternate font such as Courier for system-displayed text.)

• Labels on hardware. Another practice that is not particularly common in computer publishing is to bold the name of a hardware label. For example, "Press the Reset button to reboot the computer."

• Lead-in labels in list items. When you have a long list of bulleted or numbered items, a nice touch is to create a lead-in labels for each item and either bold or italicize it. (The bulleted items you are currently looking at use italics for the lead-in labels because there is so much bold in the text already.)

• Labels on special notices. As mentioned earlier, special notices are the best technique for emphasizing extended text. If you have a sentence or short paragraph you want to emphasize, don't make it all bold---use a special notice instead. With special notices, typically only the Danger, Warning, Caution, Important, or Note label is bolded.

• Definitions in definition (two-column) lists. In a two-column list in which the terms to be defined are in the left column and the definitions of those terms are in the right column, it's common for the terms to be bolded. And of course, this practice extends to any two-column list, not just to those where terms are being defined.

• Labels in figures. It's fairly common for labels used within figures to be bolded: for example, the label On/Off switch would be bold with an arrow leading to the part of the figure depicting that switch.

• Table or figure titles. It's quite standard for the titles of tables and figures to be bold.

• Column headings in tables. Standard too is to bold table column headings. For example, if you had a table that compared autombile costs over a five-year period, the first column "Autombiles" would be bold. The column headings for each of the five years, for example, "1995," would also be bold. (Row headings are also bolded under certain conditions.

You'll notice that the preceding discussion stated no absolute rules. that's the way it is: technical publishing practice is quite varied. The main idea is to develop a logical, controlled system of highlighting, use it consistently, and document it in a style guide so that you and your documentation team members can refer to it.

Italics. Here are some of the standard uses for italics:

• Simple emphasis. As mentioned earlier, usage is mixed on whether to use bold or italics for simple emphasis, although italics has been traditional: for example, "Do not turn off the computer before shutting it down." Whichever you use, be consistent with it, and document it in your style guide or style sheet so that everybody on your document team can see it. If you're not sure which to use, use italics for simple emphasis: it's less busy.

• Variables. In computer publishing, one of the most common uses of italics is for variables. For example:
  
  copy oldfile newfile
  
  Users know not to type oldfile or newfile but to substitute their own file names instead.
• Table titles; row and column headings. Some table styles use italics instead of bold for table titles, row and column headings, or both. For some document designers, the look is cleaner, smoother, cooler to the eye.
• Special-notice labels. The "note" special notice uses italics for the label "Note:" as you'll see elsewhere in this current discussion. Warning, caution, and danger notices use varying styles of bold, however, to attract more attention.
• Figure titles and labels. You'll notice that some style use italics for figure titles, as opposed to bold. The choice is arbitrary, although italics is cooler and less busy to the eye. Similarly, you'll see labels -- those words within a figure naming and pointing to portions of the graphic -- using italics instead of bold.
• List lead-in headings. As already mentioned, when you have a long list of bulleted or numbered items, a nice touch is to create a lead-in labels for each item and either bold or italicize it. (The bulleted items you are currently looking at use italics for the lead-in labels.)
• Headings. In headings, italics is often used in combination with other effects such as bold, larger type sizes, or alternate fonts.
• Definitions in definition (two-column) lists. While bold is more common for the items in the left column of a two-column list, italics is also used. (See the discussion of two-column lists in the preceding section on bold.)

Underscores. There is almost no reason for using underscores in technical text. In the days of typewritten text, there certainly was. However, in these times, when bold, italics and other such typographical effects are readily available, underscores look obsolete. If you want to emphasize something, use your standard guidelines -- for example, use italics or bold. Don't try to create gradations of emphasis: for example, a scale of increasing importance ranging from italics to bold to underscore will be lost on your readers.

If you see good use of underscores in technical text, it will probably occur in heading design.

Capitalization. In technical publishing, there seems to be a running battle between technical writers and technical experts over capitalization. Technical experts like to use initial caps for practically every component and process in a system, while technical writers insist on using caps for proper names only. Also, technical experts (and management) typically use all caps for text they consider important and want readers to attend to.

As a technical writer, hold the line against capitalization. Capital letters are distracting; all-caps text is uncomfortable to read. Capital letters create a busy text, which sends lots of unnecessary signals. Capital letters are traditionally intended for proper names such as Microsoft, Netscape, Gateway, Dell Computers, WordPerfect, Pagemaker, and so on. The classic guidelines in technical publishing is to capitalize the names of separately orderable products only. However, the politics of organizations bends this guideline considerably. If a company is proud of a certain feature in its new release, for example, EnergyMiser, it will capitalize it, even though you can't order it separately. This is the point at which capitalization is being for emphasis. As a technical writer, you'll want to user caps for proper names and keep the use of caps as an emphasis technique to a minimum.

Here are some typical guidelines for capitalization:

• Use the exact capitalization style of messages shown on the computer screen, menu or screen names, field names, hardware labels, and so on.
• Do not use capital letters for emphasis; use italics or bold instead.
• Do not use all-caps for any extended text; use the special-notice format instead.
• Do not capitalize the names of the components or processes of a product. Capitalize only the names of products, that is, components that are separately orderable.
  
  For example, your product may be called WordStuff and of course it must be capitalized according to the style dictated bny the marketing and product planners. However, one WordStuff's features called "spell checker" shouldn't be capitalized -- just about everybody has one of those. However, WordStuff may have a feature called "ZippyFormat" and other called "Image Worker." Even though these are not separately orderable, you will want to use the initial-cap style because of their specialstyle and the ir marketing value. "Image Worker" is obviously something WordStuff, Inc., wants to show off -- therefore, the caps.
  
  But when you have to break rules like this, the exceptions need to go in the style guide or style sheet.

Single or double quotation marks. Quotation marks are often mistakenly used as emphasis techniques in technical text. As a technical writer, limit quotation marks to the traditional usage, which includes quoted speech; numbers, letters, or words referred to as such. Quotation marks, like capital letters, tend to create a busy, distracting text and therefore should be avoided.

Well-designed computer text avoids quotation marks rather vigorously. One of the primary reasons is that some readers might mistakenly assume that they must include the quotation marks in the commands they enter.

Instead of	Use the "move" command.
Write	Use the move command.
Instead of	Enter "copy install installnow."
Write	Enter copy install installnow.

Note: While some technical texts have well-defined uses for single quotation marks, in general there is no standard use for single quotation marks, other than the traditional quotation-within-a-quotation rule. When you see single quotation marks within technical text, there is usually no more rationale for their use than there is for double quotation marks.

Alternate fonts. One of the most common styles in volving alternate fonts is to use Courier or some similar monospaced, old-typewriter-style font in contrast to the standard body font (such as Times New Roman or Helvetica). You can create this effect in web page by using the <KBD> tags. For example, "type install to install the program."

Here's a review of the common uses of alternate fonts:

• Example text. To signal that an example rather than a required entry is being shown, an alternate font like Courier is often used:

  For example, if you want to copy a file, type "copy yourfile.txt myfile.txt" A file called myfile.txt will be created, and its contents will be the same as yourfile.txt.

• Displayed text. Computers and other equipment typically display things such as warning or status codes or error messages. These appear on monitor or in LCD panels and the like. When you refer to this displayed text, you can use an laternate font such as Courier. For example, "If the directory does not exist, the system will respond with No such file or directory." Or, "As the computer boots up, the digital read-out window will display 8888."
• Extended code samples. In computer programming texts, extended programming samples are often shown in Courier, for example:

  #check for naughty hackers if ($address1 eq "" & $address2 eq "") { &wicked_address (500, "Search Error", "Please enter a name."); } elsif ($address1 =~ /[;<>&\*`\|]/ | $address2 =~ /[;<>&\*`\|]/) { &wicked_address (500, "Search Error", "Malformed e-mail address. Please do not destroy our poor, humble, one-vitual-room schoolhouse!."); }

• Screens and menus. This one may sound like the previous one on displayed text, but there is a difference. Menuing systems that do not use a graphical interface (which usually provides fancy proportional fonts) typical have a monospaced-font appearance. For example, DOS-based menus have this look. When a technical writer wants to show readers such menus, they use an alternate font like Courier. However, when they want to show screns or menus in a graphical interface (such as a Windows or Macintosh system), they use a screen capture in order to retain the authentic look of the screen.

Color. Color is used in technical text but it is expensive and hard to manage through the publishing cycle.

However, color is easy to use in online information. It's common to see hypertext links, for example, using color. Online helps typically use green while web pages typically use blue for new links and purple for links the user has already explored.

The tendency to use color indiscriminately in online information is much like the tendency to go wild with bold, italics, type sizes, and alternate fonts in hardcopy information. The feeling must be something like, "It's there, it's cool, so let's use it!"

There are not any strongly developed trends in the use of color in technical text, either online or hardcopy, other than the use of green and blue for hypertext links, mentioned earlier. Printed technical texts rarely use color because of the cost.

If you want to use color, plan it carefully. Don't expect readers to remember that red signals one idea, blue another idea, and green still some other idea. Just stick to one color. In general, avoid using color for extended text. Instead of making an entire warning notice red, just make the Warning label red and leave the warning text regular roman.

Better still, read some of the standard literature on color in the technical communication field. There are general design issues and international issues:

Combinations of the preceding. In general, it's a bad idea to combine emphasis techniques, for example, bold and italics. In nonprofessional technical text, you'll see such garish combinations as all all-caps bold-italics or all-caps bold-italics with double quotation marks. Avoid these!

One legitimate combination is to use italics with alternate fonts. For example, when you show the syntax of a command, you want the entire text to be in Courier, but you also want the variables to be in italics:

copy OldFileName NewFileName

Computer texts may use some of the most complicated highlighting schemes in all of technical publishing. This may have to do with the desire to help beginning users, or it may be because computers make such techniques so readily available to writers. As of 1997, computer publishing seems to have grown away from excessive use of emphasis techniques. You may have used or seen earlier computer texts that embedded graphics of keytops right in the procedures or that used lots of color to highlight keys or commands. These busy, excessive practices seem to be fading, however.

Emphasis techniques used in computer texts vary widely. The following discussion provides an example, not a prescription, of how emphasis techniques can be used together in a scheme that is logical and that avoids overkill. Please don't view this discussion as a series of rules; instead, spend some time browsing computer manuals and guides to get a sense of how widely practice varies. (And as you browse, be critical: highlighting overkill or illogic is common!) Ultimately, you must design a highlighting scheme (a system of emphasis techniques) that works best for your readers, your text, and the tasks and technology that your text documents.

Here is a typical highlighting scheme for a user guide that discusses both hardware and software:

• Commands. Use bold for any command or subroutine, unless it is in an example. For example, "Use the move to change the name of the file."
• Variables, placeholders. Use italics for placeholder names for which readers substitute values. For example, "To change directories, use the cd NewDirectoryName command." Readers will replace NewDirectoryName with the name of an actual directory on their own computer.
• Text that the user enters. Use an alternate font, such as Courier, for text that readers must type in verbatim. For example, "To install the program, type setup speedpro and then press Enter." Courier is traditionally used because it resembles typewriter text, which resembles text on computer screens.
• Text displayed on the screen. Also use an alternate font, such as Courier, for text that is displayed on the computer, such as error messages. For example, "If the directory does not exist, the system will respond with No such file or directory." Or, "As the computer boots up, the digital read-out window will display 8888."
• Examples. Use an alternate font, such as Courier, for examples. The most common usage here is for extended code or representations of screens (such as menus).
• Menu and command buttons. Use bold for buttons on graphical user interfaces (Windows or Mac interfaces). For example, "Press Exit to exit the program." Or, "Press Format for a list of choices."
• Menu names. Use regular roman (the standard type style for body text, without emphasis) for meny or screen names, but copy the cap style used in the menu or screen. For example, "In the Format dialog box, you have a number of choices."
• Field names (labels). Use regular roman for field names (those text labels beside boxes in which you enter data or make choices), but copy the cap style used on the screen. For example, "In the Row to Delete Field, enter the number of rows you want to delete."
• Keyboard keys and mouse buttons. Use regular roman for names of keys on the keyboard, but copy the exact spelling and cap style. For example, "Press the Home key to move the text cursor to the beginning of the line." For mouse buttons, use lower case, for example, "Press the left mouse button."
• Extended emphasis. If any text more than two or three words must be emphasized, use special-notice format instead of making the extended text all bold, all italics, all caps, or some combination.

Although this highlighting scheme is fairly common, you may have spotted some areas of concern. For example, it might be confusing to readers for both example text and text they must enter to be Courier. They might mistake an example for text they must enter, or they might mistake required text for an example. It's considerations like these that explain the variability of highlighting schemes that you see in computer texts---along with the different needs of technology and readers.

Once you've read the preceding, a good thing to do next is to explore technical publications to see what highlighting schemes they use. Watch for the way things like bold, italics, caps, alternate fonts, and other such effects are used. Most likely, you'll see very different usage than what you've read about here. As you explore, think about the logic of the emphasis techniques you see being used; try to formulate the rules that the writers seem to be using; watch for inconsistencies in highlighting; and think critically about the usage you see -- is it logical? overkill? "underkill?"

After you've done some exploring like this, the next logical step is to read the chapter on style guides, if you've not already done so. Highlighting schemes must be documented in style guides so that you won't forget them and so that your documentation team members can refer to them.

Information and programs provided by hcexres@io.com.