Katy Mears
Erik Sorensen
Chapter 14 Barker: Designing Indexes
Two kinds of index methodology: manual or electronic
Chapter focuses on: what to index, levels of detail, phrasing, and techniques for building and proofreading.
1. Plan Your Indexing Strategy
A manual index requires you to go through the document and write index entries on cards or in a file. An electronic index uses the indexing feature of your software to make the index (437-438).
Manual Indexes: After finishing the document, write index entries down and alphabetize them. To determine index topics, follow these basic steps:
1. Review the user analysis to refresh yourself about the user’s needs.
2. Pick out terms/phrases that should be indexed. Look for: tables, figures, captions, main topics, important concepts, tool buttons, keyboard shortcuts, menu names, main tasks, examples and figures, definitions of terms, and acronyms or abbreviations.
3. Record the locations by page number
4. Alphabetize and edit the entries. Make sure all entries are consistent with formatting.
Electronic Indexes: Word processing software contains functions for indexing, often called “embedded indexing.” By identifying a term on the page and categorizing it, the program generates an index for you, as long as the entire document is in one file or a series of files. There are several advantages—automatic alphabetizing, automatic formatting, and ease of revision (ability to change entries at the last minute). The process is basically the same, with a few minor differences.
1. Review the user analysis to refresh yourself about the user’s needs.
2. Mark the index entries. Use the electronic marking feature of the software to determine the entries. You can do this as you are writing or editing.
3. Build the index. The software should automatically record and index entries and page numbers.
4. Edit the index. Check for inconsistencies such as double entries and missing entries. Edit the marked text not the index itself.
2. Decide What to Index
Many types of information can be indexed. Keep the user analysis in mind and you decide what types of information need to be indexed. The index should “support the activities and actions that the user will undertake in applying the program to workplace needs” (440). Make sure the documentation plan has specifications for indexing, if not, determine what they are and add them.
Index Categories:
Commands and Functions: Terms found on the menus. Format commands so they sound like parts of sentences.
Concepts: Ideas that are related to the subject matter. User must understand these to make the program work.
User Terms and Questions: Connect words the user knows to synonyms used in the program. For example, the software uses “quit” but the user may use “exit.”
Glossary Terms: Include a reference in the index for all the glossary terms.
Proper Names of Products and Companies: If your program writes files in formats usable by other programs or you refer to other companies you do business with, these should be included in the index.
Tasks and Procedures: A special index is sometimes needed for tasks and procedures. Tasks should be highlighted in a way that alerts the user to the guidance and step-by-step instructions.
3. Indentify the Level of Detail
Simple indexes have only one level and only show main headings. They are used for short documents. Two-level indexes organize terms by categories. Three or more levels make a complex index to organize many different types of information. See Table 14.1 for examples of the levels (444).
Light, medium, and heavy indexes show detail in another way. A light index has two to three items per page. A medium index has five to seven items per page. A heavy index has eight to nine items per page.
4. Decide on Phrasing and Format
You should spend some time planning for the phrasing and format of your index entries. There will be some issues such as being consistent in capitalization and bolding certain entries as opposed to others. Make sure to pay attention to special formatting of commands, tasks and functions.
5. Edit and Proofread
Once the index is created you should edit and proofread it for mistakes. Also make sure to pay attention to indents and page references to ensure their accuracy. Editing an index can take up to a 1/3 or the time devoted to creating an index. It’s important when editing to keep in mind the intended user’s characteristics.
Why an Index?
The index will express the overall organization of the document and puts the information in the user’s language. It provides direct access to the desired information. The index may even be put before the table of contents in some documents. The index also introduces the user to the vocabulary of the document.
Online Index vs. Print Index
Print Index – usually at the back of the book and divided by alphabet
Online Index – this type is often seen on websites. Allows scrolling of the index by selecting the letter.
Keyword Searches – Allows user to enter words in manually and then the search will determine the closest related topic. Usually focuses strictly on help topics.
Automatic Indexing Software Programs
There are a number of programs that exist that can create indexes automatically. The programs will do the majority of the examining and then organize information creating links to the topics. The user will still have control over the final product. Often the more exotic the indexing software, the more detailed an index can become.
Indexing with Search Engines
Often times indexing with search engines that examine the whole text provide results that have very little relevance to the desired outcome. To alleviate this problem, many search engines will filter out words that are determined to be useless. Because of the misspellings and other user errors many people have determined search engine indexing to create more work rather than lessen the work load.
Tools for Indexers
The American Society of Indexers (http://www.asindexing.org) lists a number of reference tools for indexers.
Other resources include:
· Dictionaries, thesauri and other language tools
· Encyclopedias, fact books
· Phone directories, geographical maps
Friday, April 11, 2008
Monday, April 7, 2008
Barker Chapter 13 Using Graphics Effectively
Graphics in manuals reinforce the key role images play in informing the user.
1.Identify needs for graphics by your users
Graphics should support user questions:
-How can I use the program easily? Use graphics to help user locate & act by providing images that educate, guide, and support workplace tasks.
-How can I put the program to work? Use graphics to help user understand by strategically placing them, helping to locate and direct
actions, explain concepts, and illustrate examples.
*Identify user questions then choose graphics to respond to user questions.
Where is it? Show user where to look to perform tasks: let the page reflect the screen; use capture and art programs to bring elements off the screen & into manuals & online help. Show concrete versions of abstract things: use images to emphasize important points & show how the program works. Make visuals clear: avoid clutter
What is it? Use graphics to define unfamiliar concepts to the user. Two types of graphics:
1) examples: show documents, reports, printouts, sample data. Explain & label graphics. Use examples liberally in high-tech, command-driven programs such as compilers, scientific graphing & analysis software & operating systems.
2) metaphors: show relation of ideas by relating to something familiar to user & allows users to rely on previous experience. Metaphors compare two things: the abstract & the concrete. Examples of metaphors: radio buttons, sliders, pull-down menus. Language metaphors are stronger if supported by the actual images suggested by the words.
How do I do it? Provide overviews of procedures introducing users to the steps that follow. Example of mental model: input-process-output.
Where am I? Access indicators show users their location in a manual or online help rather than tell them and keeps user from feeling lost. Examples of access indicators: diagrams showing current location in the process, history maps, header & footer icons. Progress indicators are helpful in tutorials so readers can easily see progress through the number of pages or lessons using headers or footers.
What’s the big picture? Users unfamiliar with computing or a new program need to know how it’s all put together (structured) since they cannot draw on previous experience. Experienced users may need reminders and expert users expect to have a structure in place. Keep things as small as possible when creating an overview graphic and use icons to make the connections between things seen on the screen and workplace demands. Color can be used for easy recognition. Some graphics elements to use:
Overall program diagrams: illustrate program system components to show the flow of information.
Menu maps: consist of program menus arranged on a page in the same structure they appear in the program interface; they help maintain as sense of organization of the program’s features.
Conceptual overviews: they reinforce the ideas of how to use a program; help users see how to employ the program in meaningful work through sharing information and resources. Guideline for designing conceptual overviews found on page 418.
How to use the manual: To determine what type of graphics to use to respond to user questions see Figure 13.13 on page 419.
2.Set graphics styles
Consistency is key! Use same types and fonts, same arrow styles, and box, and frame styles throughout your document. Table 13.3, page 421 lists elements of graphical styles. There may be advantages by deleting drawing details and using a cartoon or line drawing style since they help focus user attention on specific elements of a drawing. Photo realism in graphics uses more hard disc and CD storage space. Pre-planning is a good idea and the sooner you decide major issues such as size, type, graphic size, etc. the better.
3.Revise and edit
Once you’ve determined the kinds of graphics you’ll use, and have a working draft, you can revise for overall correctness and consistency. Watch for overcrowding, images, or text.
Guidelines for graphics revising:
Titles: Titles aren’t required on everything. Rule of thumb is the more complex, the more the need for a title. If user can’t easily see the relationship between the image and the text, add a title to clarify the image’s function. More guidelines page 423
Labels: Labels aren’t required for everything; they point out the salient elements of a picture or drawing and direct the user to the correct and informational parts. If you do label see page 423 for guidelines.
Placement: guidelines page 244
Size: guidelines page 244
Colors: guidelines page 245
4.Revise for typography
This means giving an arrangement to the images based on a logic. When using images, arrange and design to convey the meaning you intend. Guidelines: make important things larger, darker, central, and sharper, align related things, put first things left, later things right.
DISCUSSION:
Graphics make clear connections between software operations and workplace actions by:
• Showing how tools apply to the workplace
• Showing results of software operations
• Presenting overviews to integrate software with workplace activities
• Suggesting functions and uses: capture the typical-use scenario
• Making abstract concrete through the use of metaphors
1.Identify needs for graphics by your users
Graphics should support user questions:
-How can I use the program easily? Use graphics to help user locate & act by providing images that educate, guide, and support workplace tasks.
-How can I put the program to work? Use graphics to help user understand by strategically placing them, helping to locate and direct
actions, explain concepts, and illustrate examples.
*Identify user questions then choose graphics to respond to user questions.
Where is it? Show user where to look to perform tasks: let the page reflect the screen; use capture and art programs to bring elements off the screen & into manuals & online help. Show concrete versions of abstract things: use images to emphasize important points & show how the program works. Make visuals clear: avoid clutter
What is it? Use graphics to define unfamiliar concepts to the user. Two types of graphics:
1) examples: show documents, reports, printouts, sample data. Explain & label graphics. Use examples liberally in high-tech, command-driven programs such as compilers, scientific graphing & analysis software & operating systems.
2) metaphors: show relation of ideas by relating to something familiar to user & allows users to rely on previous experience. Metaphors compare two things: the abstract & the concrete. Examples of metaphors: radio buttons, sliders, pull-down menus. Language metaphors are stronger if supported by the actual images suggested by the words.
How do I do it? Provide overviews of procedures introducing users to the steps that follow. Example of mental model: input-process-output.
Where am I? Access indicators show users their location in a manual or online help rather than tell them and keeps user from feeling lost. Examples of access indicators: diagrams showing current location in the process, history maps, header & footer icons. Progress indicators are helpful in tutorials so readers can easily see progress through the number of pages or lessons using headers or footers.
What’s the big picture? Users unfamiliar with computing or a new program need to know how it’s all put together (structured) since they cannot draw on previous experience. Experienced users may need reminders and expert users expect to have a structure in place. Keep things as small as possible when creating an overview graphic and use icons to make the connections between things seen on the screen and workplace demands. Color can be used for easy recognition. Some graphics elements to use:
Overall program diagrams: illustrate program system components to show the flow of information.
Menu maps: consist of program menus arranged on a page in the same structure they appear in the program interface; they help maintain as sense of organization of the program’s features.
Conceptual overviews: they reinforce the ideas of how to use a program; help users see how to employ the program in meaningful work through sharing information and resources. Guideline for designing conceptual overviews found on page 418.
How to use the manual: To determine what type of graphics to use to respond to user questions see Figure 13.13 on page 419.
2.Set graphics styles
Consistency is key! Use same types and fonts, same arrow styles, and box, and frame styles throughout your document. Table 13.3, page 421 lists elements of graphical styles. There may be advantages by deleting drawing details and using a cartoon or line drawing style since they help focus user attention on specific elements of a drawing. Photo realism in graphics uses more hard disc and CD storage space. Pre-planning is a good idea and the sooner you decide major issues such as size, type, graphic size, etc. the better.
3.Revise and edit
Once you’ve determined the kinds of graphics you’ll use, and have a working draft, you can revise for overall correctness and consistency. Watch for overcrowding, images, or text.
Guidelines for graphics revising:
Titles: Titles aren’t required on everything. Rule of thumb is the more complex, the more the need for a title. If user can’t easily see the relationship between the image and the text, add a title to clarify the image’s function. More guidelines page 423
Labels: Labels aren’t required for everything; they point out the salient elements of a picture or drawing and direct the user to the correct and informational parts. If you do label see page 423 for guidelines.
Placement: guidelines page 244
Size: guidelines page 244
Colors: guidelines page 245
4.Revise for typography
This means giving an arrangement to the images based on a logic. When using images, arrange and design to convey the meaning you intend. Guidelines: make important things larger, darker, central, and sharper, align related things, put first things left, later things right.
DISCUSSION:
Graphics make clear connections between software operations and workplace actions by:
• Showing how tools apply to the workplace
• Showing results of software operations
• Presenting overviews to integrate software with workplace activities
• Suggesting functions and uses: capture the typical-use scenario
• Making abstract concrete through the use of metaphors
Sunday, April 6, 2008
Chapter 11 Barker: Getting the Language Right
This is just a comment on Barker's chapter 11, not the initial blog!
The concepts Barker writes about seem to follow the guidelines for all writing such as using active voice, keeping writing simple and geared to the user, and using the parallel structure. I thought he nailed it exactly with the idea that "A manual is like a bathroom key: people want to get their hands on it not because of its intrinsic properties but because it lets them do what they need to do." Perfect. I look for exactly this in any manual. I want the information I need and the rest can wait until later, or never.
I learned about explaining abstract concepts when writing and, at my job, I usually use the operational concept that simply tells me what I need to know. I think AuthorIt might fall into the technical functioning of a program and that may be where I'm experiencing difficulties because I'm required to understand the technical aspects in order to perform what I need to do for the documentation project. I'm more interested in the productivity of AuthorIt than learning the technical parts. And that might be where the sticky part lies.
Understanding the different types of parallelism helps with all tutorial and instruction writing. Parallelism seems to work well in tutorials because it's based on action by the user and that is what our documentation and usability projects require in the quest to be user friendly and user helpful.
The concepts Barker writes about seem to follow the guidelines for all writing such as using active voice, keeping writing simple and geared to the user, and using the parallel structure. I thought he nailed it exactly with the idea that "A manual is like a bathroom key: people want to get their hands on it not because of its intrinsic properties but because it lets them do what they need to do." Perfect. I look for exactly this in any manual. I want the information I need and the rest can wait until later, or never.
I learned about explaining abstract concepts when writing and, at my job, I usually use the operational concept that simply tells me what I need to know. I think AuthorIt might fall into the technical functioning of a program and that may be where I'm experiencing difficulties because I'm required to understand the technical aspects in order to perform what I need to do for the documentation project. I'm more interested in the productivity of AuthorIt than learning the technical parts. And that might be where the sticky part lies.
Understanding the different types of parallelism helps with all tutorial and instruction writing. Parallelism seems to work well in tutorials because it's based on action by the user and that is what our documentation and usability projects require in the quest to be user friendly and user helpful.
Thursday, April 3, 2008
12 Campbell: We're Thinking About Going On-Line
12 Campbell: We're Thinking About Going On-Line
Team 2: Ender, Warren
What it means to go on-line
Going on-line is not a magic cure that will fix policy and procedure problems. It does not guarantee instant understanding or proper application. On-line documentations is just a different method of communicating information. In the past, users were bound by verbal or written information. Now there is also the option of sending information electronically.
Three methods of communicating with users
1. Verbal
2. Written
3. Electronic
What does not change
The content of your policies and procedures does not change. Neither does your writing, editing, or revision processes. All the challenges of good writing still exist.
What does change
The method by which the final policy or procedure is communicated to the user does change. Printing and copying is no longer necessary. Messages are sent on-line, rather than on paper.
Advantages of going on-line
• Logistical
⁃ lower maintenance costs
⁃ faster
⁃ more efficient
⁃ instant distribution of originals and revisions
⁃ space saving
⁃ easier access for disabled users
• Informational
⁃ can link related facts or documents together in a way that gives users faster access
⁃ can jump quickly from one document to another
• Motivational
⁃ less intimidating to users who are familiar with computers
⁃ easier and faster than picking up a 300 page manual
Disadvantages of going on-line
• Logistical
⁃ need for training
⁃ requires major organizational commitment of time, money, and resources
⁃ small screen size
⁃ higher initial costs for design and development
⁃ format limitations
⁃ lower readability
• Informational
⁃ fast access or ability to compare data can be hindered by inadequate software or hardware
⁃ format limitations tend to lend themselves to short documents
⁃ can encourage readers to skim or skip long documents
⁃ some users may not have access to a terminal
⁃ if the system crashes or is down for maintenance information is unavailable
• Motivational
⁃ peering at a screen is difficult and tedious
⁃ users may be intimidated by the system or by the computer
⁃ some users may prefer a hard copy
✓ Page 376: Questions to ask when going in-line externally
On-line design considerations
• Visual ease
⁃ use small blocks of text
⁃ limit the number of colors on the page to two
⁃ limit highlighting and other visual cues for emphasis
⁃ use simple graphics
⁃ use lots of white space
• Ease of use
⁃ use hypertext or searches
• Clear operating instructions
⁃ indicate page, document, or file size on the screen
⁃ differentiate between "page" and "screen"
⁃ use a "continued" notation at the bottom of text
⁃ create screen headers and footers, and be sure to keep them simple
⁃ if not using hypertext, include information on how to find related information
Designing an on-line system
Because of the limited readability of a computer screen, certain design considerations exist. Formats of an on-paper design would most likely be different than from an on-line design. Keep in mind that a computer screen is harder to see and concentrate on than a piece of paper. Try do eliminate visual clutter and keep the reader's attention.
Four design factors to keep in mind:
1. Visual simplicity
2. Ease of use
3. Clear operating instructions
4. Adequate conversion of elements
Team 2: Ender, Warren
What it means to go on-line
Going on-line is not a magic cure that will fix policy and procedure problems. It does not guarantee instant understanding or proper application. On-line documentations is just a different method of communicating information. In the past, users were bound by verbal or written information. Now there is also the option of sending information electronically.
Three methods of communicating with users
1. Verbal
2. Written
3. Electronic
What does not change
The content of your policies and procedures does not change. Neither does your writing, editing, or revision processes. All the challenges of good writing still exist.
What does change
The method by which the final policy or procedure is communicated to the user does change. Printing and copying is no longer necessary. Messages are sent on-line, rather than on paper.
Advantages of going on-line
• Logistical
⁃ lower maintenance costs
⁃ faster
⁃ more efficient
⁃ instant distribution of originals and revisions
⁃ space saving
⁃ easier access for disabled users
• Informational
⁃ can link related facts or documents together in a way that gives users faster access
⁃ can jump quickly from one document to another
• Motivational
⁃ less intimidating to users who are familiar with computers
⁃ easier and faster than picking up a 300 page manual
Disadvantages of going on-line
• Logistical
⁃ need for training
⁃ requires major organizational commitment of time, money, and resources
⁃ small screen size
⁃ higher initial costs for design and development
⁃ format limitations
⁃ lower readability
• Informational
⁃ fast access or ability to compare data can be hindered by inadequate software or hardware
⁃ format limitations tend to lend themselves to short documents
⁃ can encourage readers to skim or skip long documents
⁃ some users may not have access to a terminal
⁃ if the system crashes or is down for maintenance information is unavailable
• Motivational
⁃ peering at a screen is difficult and tedious
⁃ users may be intimidated by the system or by the computer
⁃ some users may prefer a hard copy
✓ Page 376: Questions to ask when going in-line externally
On-line design considerations
• Visual ease
⁃ use small blocks of text
⁃ limit the number of colors on the page to two
⁃ limit highlighting and other visual cues for emphasis
⁃ use simple graphics
⁃ use lots of white space
• Ease of use
⁃ use hypertext or searches
• Clear operating instructions
⁃ indicate page, document, or file size on the screen
⁃ differentiate between "page" and "screen"
⁃ use a "continued" notation at the bottom of text
⁃ create screen headers and footers, and be sure to keep them simple
⁃ if not using hypertext, include information on how to find related information
Designing an on-line system
Because of the limited readability of a computer screen, certain design considerations exist. Formats of an on-paper design would most likely be different than from an on-line design. Keep in mind that a computer screen is harder to see and concentrate on than a piece of paper. Try do eliminate visual clutter and keep the reader's attention.
Four design factors to keep in mind:
1. Visual simplicity
2. Ease of use
3. Clear operating instructions
4. Adequate conversion of elements
Monday, March 31, 2008
Chapter 11 Barker: Laying Out Pages and Screens
By Mary Dobbins
Guidelines for Designing Pages and Screens
1. Review the user analysis. Use typesize, fonts, etc. and design according to user types and experience, and users’ problem-solving techniques. Page and screen layout should support task orientation and lead users to the right kinds of information. Screens and icons should help the user make the connection between pages of the program.
2. Create the page grids. The grid is the framework onto which you put the text and graphics and contains: grid lines, margins, columns, gutters, white space, and baseline.
3. Define the page grid using styles. The grid provides the roadmap for your pages; then you have to identify the styles. Ideally, you should include all components listed in Table 11.1, Page 355.
4. Draw thumbnail sketches. Use sketches as part of your planning. Find an existing page that you like and then use it to follow the exercise on Page 356.
Tips: 1) Make sketches accurate, 2) Keep page items in proportion, 3) Keep shading and spaciousness close to the original.
5. Set up pages and styles in your word processor. This can be time-consuming but is important to ensure consistency in your document.
6. Determine the layout of help documents. Layout of pages and screens can differ which creates limitations. Table 11.2 on Page 360 compares data elements between pages and screens.
Designing Communication Spaces
Two important things need to be decided:
1. Degree of Modularity – breaking information into chunks of text and graphics. The modular format follows the one-task-per-page idea. Some helpful tips include:
- Repeat background information when necessary
- Repeat screens when necessary
- Include information about a related task
- Keep relevant steps together
- Minimize cross-references
2. Degree of Structure – placing information on the page according to patterns. Chunking is a technique that helps the user find information on the page. Structure includes:
- Rules – using different lengths and thicknesses to identify headings
- White space – helps to focus on graphics and creates balance
- Bullets – identifies organization of information easily
- Chunks – identifies related information
How to Look at Pages and Screens
Compare manuals for page density, balance (white vs. text space), and legibility (font and style). Common page designs include two-column format (graphics column and a text column) and a one-column format (graphics and text in the middle of the page). The two-column format works best for guidance-level documentation such as procedures or step-by-step instructions while the one-column format works best for procedures and reference manuals.
Contributing greatly to usability, the elements of page design include: the left margin, columns, headers and footers, icons and diagrams, screenshots, rules (border or artwork), and pagination.
Some tips when designing a screen include: forget line length since users can change the screen border and shape, avoid lots of scrolling because it’s disorienting, indicate another screen by using a “More” button or “1 of 3” indicator.
Multiple Windows Management
Be careful not to cover an entire screen when calling up an additional screen. Avoid using too many windows (window clutter). Make sure screens can be closed by the user.
Other helpful hints include using color to cue important elements, keep graphics simple, use screen grids (as described above), and in general, single spacing is best.
Helping People Recognize Words
People prefer visuals. Manuals that use visuals consistently test higher in usability. Be mindful of using words that could be confused with a look-a-like (disk vs. desk). Using a serif font works well for scanning because it helps the eye move quickly across the page. San serif works for large font size. Simplicity is best. More design advice:
- Choose a recognizable font
- Use a font that clearly shows the tails of the letters
- Choose a recognizable style
- Avoid long passages in italics or all caps
- Keep headings short
- Use serif for body text, sans serif for headings
Distinguish style of text for “hints, notes, or cautions” so that they are set apart of regular body text. Also, distinguish input or output messages (e.g., error messages) – courier new is often used.
Tables and Lists
Emphasize the headings so they are easy to recognize. The substance of the table or list should use the same style and font as the body text.
By Mary Dobbins
Guidelines for Designing Pages and Screens
1. Review the user analysis. Use typesize, fonts, etc. and design according to user types and experience, and users’ problem-solving techniques. Page and screen layout should support task orientation and lead users to the right kinds of information. Screens and icons should help the user make the connection between pages of the program.
2. Create the page grids. The grid is the framework onto which you put the text and graphics and contains: grid lines, margins, columns, gutters, white space, and baseline.
3. Define the page grid using styles. The grid provides the roadmap for your pages; then you have to identify the styles. Ideally, you should include all components listed in Table 11.1, Page 355.
4. Draw thumbnail sketches. Use sketches as part of your planning. Find an existing page that you like and then use it to follow the exercise on Page 356.
Tips: 1) Make sketches accurate, 2) Keep page items in proportion, 3) Keep shading and spaciousness close to the original.
5. Set up pages and styles in your word processor. This can be time-consuming but is important to ensure consistency in your document.
6. Determine the layout of help documents. Layout of pages and screens can differ which creates limitations. Table 11.2 on Page 360 compares data elements between pages and screens.
Designing Communication Spaces
Two important things need to be decided:
1. Degree of Modularity – breaking information into chunks of text and graphics. The modular format follows the one-task-per-page idea. Some helpful tips include:
- Repeat background information when necessary
- Repeat screens when necessary
- Include information about a related task
- Keep relevant steps together
- Minimize cross-references
2. Degree of Structure – placing information on the page according to patterns. Chunking is a technique that helps the user find information on the page. Structure includes:
- Rules – using different lengths and thicknesses to identify headings
- White space – helps to focus on graphics and creates balance
- Bullets – identifies organization of information easily
- Chunks – identifies related information
How to Look at Pages and Screens
Compare manuals for page density, balance (white vs. text space), and legibility (font and style). Common page designs include two-column format (graphics column and a text column) and a one-column format (graphics and text in the middle of the page). The two-column format works best for guidance-level documentation such as procedures or step-by-step instructions while the one-column format works best for procedures and reference manuals.
Contributing greatly to usability, the elements of page design include: the left margin, columns, headers and footers, icons and diagrams, screenshots, rules (border or artwork), and pagination.
Some tips when designing a screen include: forget line length since users can change the screen border and shape, avoid lots of scrolling because it’s disorienting, indicate another screen by using a “More” button or “1 of 3” indicator.
Multiple Windows Management
Be careful not to cover an entire screen when calling up an additional screen. Avoid using too many windows (window clutter). Make sure screens can be closed by the user.
Other helpful hints include using color to cue important elements, keep graphics simple, use screen grids (as described above), and in general, single spacing is best.
Helping People Recognize Words
People prefer visuals. Manuals that use visuals consistently test higher in usability. Be mindful of using words that could be confused with a look-a-like (disk vs. desk). Using a serif font works well for scanning because it helps the eye move quickly across the page. San serif works for large font size. Simplicity is best. More design advice:
- Choose a recognizable font
- Use a font that clearly shows the tails of the letters
- Choose a recognizable style
- Avoid long passages in italics or all caps
- Keep headings short
- Use serif for body text, sans serif for headings
Distinguish style of text for “hints, notes, or cautions” so that they are set apart of regular body text. Also, distinguish input or output messages (e.g., error messages) – courier new is often used.
Tables and Lists
Emphasize the headings so they are easy to recognize. The substance of the table or list should use the same style and font as the body text.
Monday, March 24, 2008
Chapter 11 - We Haven't Used That Procedure in Years
Team 7 Jaeger/Lopez
You must find a proper balance between:
1) Regularly scheduled review and revision
2) As-needed review and revision
The best balance for your organization depend both on content factors and on logisitics.
Regularly Scheduled Reviews:
Ideal time to review policies and procedures is once a year. Otherwise, create a realistic schedule that will work in your organization with your own time frames. The more frequent, the better. Consider your consequences if you choose not to review them. One method of reviewing is called rolling reviews. Roll through different groups of policies and procedures for review periodically and move along to the next, next time around. The key here is a disciplined schedule.
As-Needed Reviews:
A revision is needed when:
1) A significant number of changes have been made to the documents
2) Content changes, such as operation or legal, occur or are pending
3) Certain types of problems or behaviors increase
Accumulated Changes are when a number of changes have been made over a period of time to the policy and procedures document. You must eventually fix the whole and not continue to patch it up. Good rule to follow is if approximately 25% of a given policy or procedure has been changed, it’s time for a complete review.
Content Changes are when a policies and procedures need adjustment anytime you have new equipment, new programs, or new products, procedures, and policies. Makes notes on other people so opinions about your policies. Keep these for future changes.
Significant Clues might tell you that a change is necessary. Pay attention to others conversations and be alert at meetings; they could be telling you something. Some clues that it’s time for a change might include: Accidents, Errors, Complaints, Deviations, Questions, Rejection rates, Confusion, Corrective actions.
When Not to Revise
Even if your policy or procedure isn’t working, that might not mean it is time to review. Look at other reasons why it may not be working. Don’t rush to revision.
How Much to Revise
The goal is to change as much as necessary and as little as is possible. Depends. You can change: A portion of an individual policy or procedure, all of an individual policy or procedure, a section or related group of policies or procedures, an entire handbook or manual.
How to Revise
Research the topic, organize the information, format it, and draft it. Review it, edit it, and get it approved.
How to Clarify the Changes
Make it as easy as possible for the user to see what, and how much, has been revised by: Visually highlight the changes on the page, Use clear, descriptive wording in your transmittal document, and summarize the changes.
How to Hold Users Responsible
Revisions often have people saying afterward that “I never got it!” To avoid problems like this, use a notification system that forces users to share responsibility for updating their document(s). A shared responsibility system is fairly easy to construct.
1) 1) Users are given a revision index form on which they record all revision notices in the order or receipt.
2) 2) All change notices are clearly numbered in an obvious and easy to –identify manner.
3) 3) Users are instructed that it is their responsibility to record all change notices in their revision indexes and notify the appropriate person if any are missing.
4) 4) A summary of all the change notices issued is periodically sent to users.
This system is straightforward and simple, yet very effective.
Sunday, March 23, 2008
Chatper 10 Campbell: But That's Not The Way We've Always Done It
Chapter 10
But That’s Not the Way We’ve Always Done It
Don’t Give Up
You will undoubtedly run in to resistance and grief when trying to implement something new. All the user testing and ensuring there will be minimal problems is not all for nothing. Be patient.
Dealing with Resistance
Keep in mind that most resistance to change occurs because of fear. You will not be able eliminate other people’s fears but there are six things you can do to help users manage change:
Involve
Explain
Listen
Enforce
Reinforce
Evaluate
Early Communication
Initiating communication earlier on in the process will benefit you later. Early communication also serves two other critical purposes: Early detection and advanced preparation.
Early Detection
Skepticism is likely in the beginning. Most users think that the problem will go away or inevitably end up to their disadvantage. Open communication, as well as being honest in the beginning prevents problems in the end. Early detection will also reveal cynicism. Skepticism is one thing but cynicism can reveal a personal agenda. Communication in the beginning will help to reveal cynics.
Advance Preparation
Involving people early and often allows them to be included on the process and therefore allows them to be heard. Disagreements are still likely to occur but if the person feels they are genuinely being heard they are often easier to deal with.
Continuing Education
As implementation continues, keep talking to people. Run status updates by everyone even if nothing has happened. Keeping lines of communication open allows for continued input and allows for valuable opinions to be heard.
Final Notice
If you have kept communication lines open then the final notice of implementation will come as no surprise. Users who were heavily involved will make the transition smoothly. Make sure to keep listening to skeptics but also remember that there comes a time when you many need to put your foot down. Just be sure they understand the consequences of non-compliance.
Grace Periods
Grace periods allow for a gradual adjustment to a new system. The more controversial the policy or procedure the more grace period becomes vital. Grace periods allow for more preparation. Grace periods also let the user know that there is some flexibility initially and that full enforcement begins at a later date. Using a grace period is a sort of announced gradual transition that allows everyone to adapt gracefully.
Delivering Bad News
Don’t try to change an unpopular procedure to popular in a blink of an eye. Planning, patience and preparation are required. The greatest asset you have is the communication that has already taken place. If good communication has occurred than the user will likely trust you enough to listen seriously.
Preempting
Preempting is a way to deal with anticipated issues before they arise. Holding a meeting to discuss likely objections will steal the objectors thunder.
Taking the Heat
You must be willing to accept responsibility for the policies and procedures that you create. Just remember that people have the right to feel strongly about things that affect them or their jobs and it’s not personal. Be patient and calm.
Here Comes Trouble
There are 14 “indicators” for trouble (all 14 are located at the back of the chapter on page 339). Trouble is sometimes unavoidable with policies and procedures, but they are common ways to avoid problems. The most common indicators are:
Unfairness – Unfairness often really means “unreasonable from my point of view.” To avoid this, look at the policy from another’s point of view and make sure it is reasonable.
Negativity – Negativity is an unconscious trap during writing. It is easier to state “don’t do something” rather than an alternative. For example, instead of writing “don’t take extended breaks,” write “observe the scheduled break times.”
Hypocrisy – The substance of the policy must support the company’s goals and viewpoints. Actions that conflict with the words of a policy can be viewed as hypocritical.
Pointlessness – Point out why a policy or procedure is important. Workers are more willing to adapt to a policy that proves it will accomplish a task.
Unworkableness – There are three keys: accuracy, completeness, and testing. Make sure a policy can exist in the “real world” of the company.
Restrictiveness – Maintain a balance between control (policy and procedures) and flexibility (user’s needs). Be detailed when necessary, and specific when necessary.
When the Writer is the Resister
When writing a policy, you as the writer may not agree with it yourself. Be sure to address your own concerns the same way you would anyone else’s: listen and consider. Note the reasons for the policy and why it is being created and keep this in mind as you are writing it.
Subscribe to:
Posts (Atom)