Barker chapter 13: Using Graphics Effectively
In this chapter, Barker discusses how to use visual displays to the advantage of the end user. Barker promotes a liberal use of visual elements, so long as each visual is meaningful and useful to the user in some way. Therefore, Barker recommends using visual displays to accomplish the following rhetorical tasks:
- Showing how the program’s tools apply to the user’s job
- Showing the results of the program’s operations
- Presenting an overview of the program so the user can understand when and why to use the program
- Suggesting functions and uses of the program
- Making abstract concepts into concrete images through metaphors (which can be extended throughout a document)
Visuals could certainly be used in other situations as well, but only if the visual helps to accomplish a rhetorical task. Avoid using un-cropped screen captures or excessively complex pictures that would distract or confuse the reader. Instead, cut all information that is not necessary to the user understanding the visual and its place in the document.
Barker assumes that his readers will already know how to create visual displays, so instead of discussing the process of producing a visual, he outlines some general guidelines for using and placing visual displays within a document.
1. Identify needs for graphics by your users
Visuals can be used to answer some common user questions: Where is something? What is something, and how does it work? How do I do something? Where am I in the program/document? What is the big picture?
Barker defines two types of visual cues that can be useful in answering some of these questions: access indicators and progress indicators. Access indicators tell the user where certain things are located in a document or program, and progress indicators tell the user where they are in the document or program. These can tell the user where something is, where they are, or what the structure of the program is.
2. set graphics styles
Consistency is next to godliness in the editing world. Set your visual standards early on and stick to them throughout the document. Many documentation programs have object styles functions built in to help with this.
3. revise and edit
Work with graphics after the text has been written. Barker promotes a balance of text and visual, so that one doesn’t overpower the other. The visuals should play a supplemental role to the text, to help the user retain information more effectively. Don’t let a visual act as a substitute for naming something.
Barker also makes several other specific points about standardizing graphic elements:
- Not all images require titles, unless they are official visuals or copywritten
- Labels are not always necessary, unless you refer to several visuals in the same chapter or section
- Always place a visual as close as possible to the text that refers to it
- Keep rules straight and of uniform size
- Keep visuals within the margins, and crop out all unnecessary parts of them
- Only use reserved colors (red for danger, yellow for caution) for their intended purpose
4. revise for typography
Here, Barker refers to visual typography as the arrangement and construction of the images based on a logic. This refers to the individual elements that make up the visual, such as color, emphasis, alignment, cropping, etc. Barker advises us to use the following methods to enhance the clarity and emphasis of a visual:
- Make important things larger
- Make important things darker
- Make important things central
- Make important things sharper
- Align related things
- Put first things left, later things right
Labels: by William Pass and Lindsay Case
posted by William | 3:15 PM
8 Comments:
A picture's worth a thousand words...sometimes.
I've seen plenty of graphics included in online documentation that are either "fuzzy" or over-sized for the screen. They take away from the documentation instead of enhancing it. I especially appreciate the part where Barker talks about standards/styles for graphics. I think graphic standards are often overlooked.
I envy those who are graphically astute. I'm graphically challenged. I do my best but Picasso I am not!
This is an area where the text is deeply appreciated. I can use all the help I can get!
I’m in the same boat as Carl; I admit that my graphic abilities leave something to be desired and I praise the good people who do all that fine work. I know my strengths, and graphic art isn’t one of them. All those fine graphic artists doing the work for us writers is VERY much appreciated!
I think that graphics can be a great thing for technical documents. Granted, it can distract, but when done right the positives can far outweigh the negatives. As a more visually inclined person, I can appreciate a good visual in a technical document. For me, it can mean all the world in a procedure.
I guess I'm the odd man out here because I like working with graphics. An artist I am not, but I can usually get the graphic placed where I want it in the format that I want. I agree with the authors that huge uncut screen captures are kind of bogus, but sometimes the visual is necessary to get your point across. I guess that IS their point: just use as much as you need to make you r point.
The idea of graphics standards is a good one, and (at least in print) is alive and well and very much in use. In fact, the four steps he suggests using are all good practice in docunment production. (I also like the idea of progress indicators to let you know where you are in the document.)
Since I'm minoring in Studio Art/Graphic Design, it always interests me to learn about how to use graphics effectively. One thing that really bothered me about AuthorIT (and maybe I just don't know the right way to do it...) was that when I imported my Word document with cropped "screen capture" visuals, the pictures were uncropped in AuthorIT and I couldn't figure out how to fix the problem. So instead of having nice, small visuals, my project turned out with large pictures of the whole screen. This is definitely something Barker warns against, as it is distracting to the audience.
I can definitely appreciate graphics when they are usefully incorporated in to any document. I recently put a grill together. I tried using the instructions and going word for word but eventually I just had to look at the picture and go from there. It was just one example of many where graphics have helped me complete a task. I wish that I were better at creating graphics and visual elements.
Again with the use of Graphics in documents, being a graphic design minor helps! :-p
I've always found visuals really helpful, but it can still be possible to confuse your readers if you mess it up. I really dislike the instruction manuals where the lines for the labels blend in perfectly with the lines forming the object under study. I especially like this part; "Avoid using un-cropped screen captures or excessively complex pictures that would distract or confuse the reader." Has anyone else been in the situation where the directions state "press button execute" and as it turns out it's a tiny 2-pixel button that the image has in no way highlighted? At that point you have to wonder why they bothered to put the visual aid in at all.
Post a Comment
<< Home