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
Subscribe to:
Post Comments (Atom)
7 comments:
I love using graphics in documentation! I think it is worth so much to actually show a user a picture rather than just describe screens and buttons and clicks. I also have learned, though, that using graphics can be a constant task to maintain because anytime there are screen changes or updates, your documentation needs to change too. No small task! The other thing to consider is that once users are somewhat familiar with the screens, they may not want all of that anymore. That's why it helps to have a helpful hints document or some other shortcut document that just cuts to the chase on the steps the user needs to take.
While I was writing my documentation, I started out by adding arrows to all my pictures and pointing to specific parts. It got so confusing that I ended up quiting and discarding the whole idea. I found it was better to just have a clear picture and explain where the button(s) or item of interest is located on the picture. It seemed to work a whole lot better. I even did a mini usability of some of my writings to my brother. For most of the pictures he was able to follow the directions very clearly.
The use of graphics can be a great asset when creating documentation. I think is really adds a lot of information for the user. Most of us are visual learners, so these visual ques can be of great help. Consistency seems to be the key in anything that we create and this is emphasized throughout this chapter.
I'm with Mary...I LOVE using graphics in documentation. If I had my druthers, I would handle the graphics on a technical team project, and leave the grammar and punctuation editing to someone else. There is something so satisfying about finding just the right picture to enhance an explanation. I think that using graphics is the ultimate seal to the deal in writing software documentation.
I think Barker could have put a little more emphasis in the chapter about the 'expectation' that graphics are included in an instruction manual. Have you ever picked up a how-to book that contained no pictures? I can't recall if I ever have, but I'm sure I would have quickly put it back down.
My boss did not like excessive use of graphics in documentation only because he was in a hurry and felt adding pictures took way too long and was unnecessary. I disagreed with him 110% but I didn't have enough data to hold my own in a debate. 'Gild the lily' he called it. He just didn't understand that those pictures just solidified the point it was trying to make.
The concept of consistency in graphics makes senses to me, since it is important to be consistent in documentation as well. I do not have a lot of experience in making and working with graphics, so this chapter taught me what to look for. When working on my documentation project, I used graphics mostly for examples. If I were writing the entire instruction manual on how to use the software at my company, I would definitely use graphics as examples and to show the structure of the company and how the ordering process works. There are several warehouses involved that are all for different parts of the process, and a graphic explaining this would eliminate a lot of confusion for new employees. I've seen documents with inconsistent graphics and using the same fonts, arrows, and colors makes things less confusing for the reader and it takes less time for them to interpret and learn from the graphic.
Graphics are so important in documentation. I don't think you can ever have enough screen shots- although I know I'm wrong. I think they help so much, and if you don't know what level your user is at, the more pictures, the better in my opinion.
I think I realized the importance of graphics while doing my documentation project. I decided not too add graphics that were not clear and therefore would be more confusing if there just weren't any. However, I really prefer that graphics be included and cannot say enough about what clear, concise graphics can do for a document. I think if nothing else, graphics can add clarity if language fails because it's harder for people to misinterpret a picture compared to written instructions.
Post a Comment