1. Font A User Manual Should Be A Week
2. Font A User Manual Should Be Like
3. Font A User Manual Should Be A Child
4. User Manual Pdf
5. User Manual Template

Dec 14, 2010  A Little Can Go a Long Way. Periodically, there’s a need for a font that oozes with personality, whether that personality is warehouse party, Pad Thai or Santa Claus. And this need brings us into the vast wilderness of Display typefaces, which includes everything from Comic Sans to our candy-cane and bunny fonts. Dec 12, 2017  Still, the serif font is highly readable and has been used in publishing for centuries. If this is a form of some kind you are creating, a sans serif font may be in order. When in comes to sans serif fonts, nothing is quite as authoritative and ubiquitous as Helvetica.

A user guide is essentially a book-length document containing instructions on installing, using, or troubleshooting a hardware or software product. A user guide can be very brief—for example, only 10 or 20 pages or it can be a full-length book of 200 pages or more. While this definition assumes computers, a user guide can provide operating instructions on practically anything—lawnmowers, microwave ovens, dishwashers, and so on.

The more complex the product, the greater the page count. When this happens, some elements of the user guide get split out into their own separate volumes—especially the installation procedures, troubleshooting procedures, and the commands. A user guide can even contain a brief tutorial—for example, getting users started using the product—but if there is too much tutorial, it too goes into a separate book.

See examples of user guides.

Style and Format for User Guides

A user guide is a combination of many things presented in this online textbook. At its core is instruction writing; you need to be good at the writing style, headings, lists, notices, highlighting, tables, graphics commonly used in instructions. (For an overview of these elements, see the page-design chapter in this online textbook.) As a set of instructions, a user guide should use the style and format that is presented elsewhere in this online textbook:

• Headings. Use headings to mark off key contents of the information so that readers can find it quickly. See the chapter on headings for details on planning and designing headings.
• Lists. Use numbered and bulleted lists to help readers scan information quickly. See the chapter on lists for details on planning and designing lists.
• Special notices. Use special notices such as warnings, cautions, and notes to alert readers to potential problems or emphasize special points. See the chapter on notices for details on planning and designing notices.
• Instructional design. In general, use the standard design of instructions; primarily, this means task-oriented headings and sections and numbered vertical lists for actual steps that readers are to perform. See the chapter on instructions for details on planning and designing instructions.

Instructions—and therefore user guides—also make abundant use of:

• Graphics. Show readers key components of the objects they will be working with, before and after views, and illustrations of key actions that readers must perform. See the chapter on graphics for details on planning and designing graphics.
• Tables. Provide statistical information and other such details in easy-to-access table form. In user guides, tables are particularly useful whenever reference-type information must be presented. See the chapter on tables for details on planning and designing tables.
• Highlighting. Use a consistent and standard scheme of highlighting (bold, italics, alternate fonts, color, caps, and so on). See the chapter on highlighting for details on planning and designing highlighting guidelines.

Components of User Guides

As a book, a user guide must have some combination of the standard book-design components such as the following:

• Front and back covers
• Title page
• Edition notice
• Trademarks
• Disclaimers
• Warranties
• License agreements
• Safety notices
• Preface
• Appendixes
• Glossary
• Index
• Reader-comment form

There is no standard combination or sequence of these elements; every company does it differently. Details on the contents, format, and design of these elements can be found in the book-design chapter.

Information Included in User Guides

Here's review the common contents of user guides:

• Instructions. The most obvious are those step-by-step directions on how to assemble, operate, or troubleshoot the product. Instructions in user guide should generally be task-oriented—that is, written for specific tasks that users must perform. Instructions should generally use vertical numbered lists for actions that must be performed in a required sequence. Similar or closely related instructions in user guides should be grouped into chapters.
• Precautionary information. You'll see notes, warning, caution, and even danger notices in user guides. These represent liability concerns for the manufacturer of the product.
• Reference information. User guides typically contain plenty of reference information, but only up to a certain point. For example, if there are numerous commands, a separate book for commands is necessary. Reference information in user guides is often presented in tables: columnar lists of settings, descriptions, variables, parameters, flags, and so on.
• Getting-started information. Some user guides will actually include brief tutorials that will help new users get acquainted with using the product.
• About the product. User guides also provide some description of the product, a review of its essential features or its new features. Sometimes this information also gets put into a separate volume, if it is extensive. Typically, the volume will be called something like 'Introducing New Product....'
• Technical background. Sometimes, users guides will include technical explanations of how the product works, what physical or chemical principles are essential to its operation, and so on. For example, you will see considerable background in user guides for graphic or audio programs—you can't operate them without understanding the concepts of brightness, saturation, and hue; μ law, A law, and other such.

Descriptive Examples of User Guides

Consider these examples.

Note: Not all of the following styles and formats are not necessarily recommended. Get in touch using the e-mail address at the bottom of this page if you have questions.

Delarina WinFax LITE User's Guide. This book is 5.5 × 8.5 inches and under 150 pages. It uses by-chapter pagination, with new chapters and sections beginning on a righthand page.

• Covers: On the front cover, you see the full book title, a version number, the company name with its logo, and warning that the book is not for retail sale. The back cover contains advertising material—rather atypical for user guides—on the product's best features, special offers on the full version, a 1-800 number to call, and the book number.
• Title page: The first page inside this user guide is the title page, which includes the product name, the book title, the book edition number, the date of the edition, the company logo (which includes its name), several addresses for the company, and the not-for-retail-sale warning. The company name has a registered trademark symbol beside it; the product name has the trademark letters beside it. No trademark symbols are shown on the front or back covers. A greener approach is to omit the title page, since it is practically a duplicate of the front cover, and put the edition notice on the back of the front cover.
• Edition notice: On the back of the title page is the edition notice. This edition notice includes the book title, a copyright notice, legal statements concerning copying the book, list of trademarked product names occurring in the book, and the document number.
• License agreement: On the next page is the software agreement, a two-page thing that outlines permitted uses of the software and related warranties.
• Table of contents: The TOC begins on a right-hand page numbered 'i' and lists up to level of headings within the chapters.
• Headers and footers: The book title is used for both the left and right footers: on the left page, the title is right-aligned; on the right page, the title is left-aligned. The page number appears opposite of both footers, and a solid ruled line is placed just above both footers. The chapter title is used for the inside header on each page; the current heading is used for the outside header on each page. A solid ruled line is placed just beneath these headers.
• Preface: The overview which is treated as chapter 1. It contains some promotion of the product, a diagram of the product's many uses, hardware and software requirements on its use, an overview of the manual contents, and instructions on how to get help.
• Body chapters: Chapters use the following design features:
  
  • Headings—First-level headings are about 1 point smaller than chapter titles, left aligned, with a solid ruled line just below. Second-level headings are about 2 points smaller, left aligned, with no ruled line. Third-level headings are the same size as body text but use bold italic Arial and are placed on the left margin.
  • Graphics—Numerous screen captures are used through the book; they are all centered.
  • Highlighting—Text that users must type uses a sans serif type (probably Arial) as do screen buttons, options, field names, and system messages. Bold is used for simple emphasis.
  • Index—The book ends with a 10-page index whose page are numbered with lowercase roman numerals starting at i. The index uses the standard but does something unusual with entries. It uses a table-of-contents format for the entries and their page references, connecting them with the sort of leader dots you'd see in TOCs.

IBM Aptiva Reference Guide. This book is also 8.5 × 5.5 inches. It is uses consecutive page numbering throughout the book and is about 120 pages long.

• Covers: The front cover has a graphic design with stylized numbered 1, 2, and 3 along with large grid pattern and various sorts of shading. The three elements of the book title are placed at the top, upper third and bottom of the area, respectively. You also see the words 'information,' 'getting help,' and 'troubleshooting' which seems to float between the second and third title elements, giving readers a more detailed sense of the book's contents. The back cover continues the grid pattern and includes the IBM logo with the part number of the book, its print date, a statement that the book was printed in the 'USA' and a bar code for the book number.
• Title page: This page contains the words 'Aptiva Reference Guide' in large serif letter in the upper right of the page—and that's it!
• Edition notice: The edition notice occurs on the back of the title page. It is pushed to the bottom of the page and uses a smaller type size, probably 7-point, for its body text. The heading for the edition notice is the edition number followed by the month and year of the edition. The paragraphs of the edition notice states that the book is provided 'as is' without any warranty, that the book is for multiple models of the product and that portions of it may not refer to the reader's own particular model. Also included are an address where comments can be sent, a 1-800 number to request additional copies, and the standard copyright line.
• Table of contents: The TOC is an unusual design in which all entries are left aligned in the center of the page, with the page numbers to the left about an inch. First-level entries use bold. TOC begins on page iii.
• Notices section: The first body section of this manual is for notices—specifically, trademarks, highlighting conventions used in the book, safety notices, and regulatory (communications) notices. The section begins with its own title page on which is displayed the word 'Notices' in a large serif font in the upper right corner and with a grid and shading design similar to that on the front cover. The text of the notices section begins on a right-hand page as does the chapter title page.
• Body text: Here are the key design features of the body text:
  
  • Text—Text for this book is indented nearly 2 inches. Body text is a rather small sans serif font, probably Helvetica, probably 9 or 10 points. The hanging-head format is used.
  • Headings—First-level headings align to to the far left margin, use a blocky bold sans serif font with a solid ruled line above. Chapter titles use a large gray serif font in the upper right corner of the first page of the chapter. Second-level heading align with body text, use sentence-style caps (as do first-level headings) and use the same font as do first-level headings but about 2 points smaller.
  • Highlighting—In stepwise instructions, the following elements are bold: buttons, tabs, menu options, menu names, keyboard key names, icon names, parameter settings. Names of disks supplied with the product are in italics. System messages are in regular roman and double quotation marks.
  • Steps—Instructions sequences are introduced with a gerund-phrased heading in the bold font. Substeps or alternate subtasks use infinitive phrasing with the same font but smaller and are punctuated with a colon. Actual steps use a number in the same smaller font without a period.
• Headers and footers: Only footers are used. Bold page numbers (using the same font as the first-level heading but much smaller) are on the outside; the current heading, not chapter title, is centered and in a serif italics font using sentence-style caps.
• Special notices: This book uses a light gray box with a white checkmark in it to call attention to special notices. The text of the special notices is the same as the footers: small italic serif font. Usually, the checkmark box is located on the far left margin and the notice text is aligned to the normal body text. Where possible, the checkmark box and the notice text are in the open area between the far left margin and the body text.
• Troubleshooting section: The body of this section begins with a flowchart that must be meant to orient a user to the overall process of troubleshooting and to the different troubleshooting resources available. The next section consists of common questions with actions to take depending on yes or no answers. The text of the actions is bulleted or numbered depending on the content and contains cross-references to other areas of the troubleshooting information. The next section is designed in two columns, the left column with the heading 'If the problem is...' and the right column with the heading 'Here's what to do...' The problem statement in the left column is in bold. the next section is similar except that it lists error codes that are displayed on the computer and actions to take.
• Index: The book has a 6-page index formatted in 3 column. Two levels of index entries are used. The page references are set about a half inch away from the text entries.

Process and Internal Documents for User Guides

Font A User Manual Should Be A Week

An important part of user guides—in fact, of almost any technical document—is the process that produces it:

1. Initial planning. Early planning on a user guide involves needs assessment (is any documentation needed at all?), audience analysis (who will be using the user guide; what are their needs?), task analysis (what will users use the product for; what are their common tasks?), library plan (what books and media, in addition to a user guide, are needed to support the product?), and so on.
2. Documentation proposal. If you are working freelance or as part of an independent documentation firm, you may have to write a documentation proposal in an effort to win a contract to do a certain technical documentation project.
3. Documentation plan. User guides need documentation plans, which are internal supporting documents that specify content, audience, design, format, production team members, schedule, and other such information about a documentation project and its 'deliverables.' The documentation plan resembles the documentation proposal in certain ways, but the plan represents an established plan agreed upon by everybody involved in the production process (and that means both the user guide and the product it documents).
4. Prototype and specifications. Important planning tools, which also serve as useful reference tools during a documentation project, include the prototype of the user guide and the specifications for the user guide. The prototype is a dummy version of the book with all planned components of the book (see the list on book-design components) and all planned elements (see the list under format and style). However, the prototype uses 'greeked' text (also known as Lorem ipsum like the following, instead of real text:
   

   Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullam corper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan.

   
   Typically, the prototype of the user guide is very brief: it need include only as many pages as it takes to illustrate every unique textual component and textual element that will be used in the user guide.
   Specifications are descriptions of a book design in table form. Specifications describe every unique component or element of a book, so that it can be recreated by someone who might not have access to the electronic files, templates or styles of that book.
5. Template and style catalog. A well-designed user guide, and a well-designed process to produce that user guide, should include templates and style catalogs. A template is an electronic file that defines such aspects of the user guide as page size, headers and footers, page-numbering style, regular and special page layout, and other such detail.
   A style catalog is also an electronic thing that defines the format and style of textual elements such as headings, headers, footers, lists, paragraphs, tables, and so on. For example, a style for a 'heading 1' might specify 24-point Arial bold with 24 picas above and 12 picas below. Styles help you create a user guide more efficiently; styles also help you maintain consistency in the format and style of that user guide.
6. Multiple review drafts & sign-off. A good process for the production of a user guide also includes several drafts that editors, technical experts, usability testers, and documentation team members can review and provide comments on. You as writer then implement those comments and produce a new draft for these same people to review again. When everybody is satisfied with the draft of the user guide (or worn out or out of time), they sign off on the user guide, and it can then go into 'production,' which means producing the finished bound copies or the PDF that is made available to users.

As you can see, a user guide brings together many of the topics covered in this online textbook. If you are taking a technical writing course, you probably cannot implement all these features and phases of a user guide. Get with your instructor to see which are required.

I would appreciate your thoughts, reactions, criticism regarding this chapter: your response—David McMurrey.

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.

Font A User Manual Should Be Like

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 writyer, 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.txtmyfile.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:
• 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!'

Font A User Manual Should Be A Child

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!

User Manual Pdf

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:

User Manual Template

copy OldFileNameNewFileName