TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Thinking in Pictures From:Maurice King <benadam -at- CYBERDUDE -dot- COM> Date:Wed, 14 Apr 1999 15:56:43 -0400
A topic that is rather close to me involves the use of graphics in technical documentation. I know that there are many schools of thought on this subject, but it's one that has special meaning to me.
If any of you have read Temple Grandin's book, Thinking in Pictures, you have an idea of what I speak. My son has the same syndrome as Ms. Grandin, and, therefore, for him to comprehend written words alone is often difficult. To help him in learning basic skills such as arithmetic, I found that I needed to use a lot of visual reinforcements to spare him the necessity of visualizing what the words say, something that is difficult for him. Ultimately, I reached the conclusion that many users of products that I document may well have the same difficulty and may need the visual reinforcement. For that reason, I use graphics to reinforce ideas that may get lost in a sea of textual explanation.
This idea works only for some companies. Some companies with very established standards balk at the idea of implementing visual cues in documentation. In the past, online Help was a particularly difficult subject because the use of graphics caused performance problems and was often regarded by many as unnecessary. However, I have often found that when a product poses a challenge because of possible confusion, especially when interface design is not user-friendly, the use of graphics can lead a user through the confusion.
The reason I am bringing up this issue is that it has often been a subject of heated discussion when documenting complex products that have no previously published documentation. One project I recall involved a radio with soft keys that changed function with each user menu to the point that the user could easily get lost in a seemingly senseless procession of menus. The only solution that I found -- and the one that ultimately went into the user's manual -- was to recreate all the menus and to display them alongside each user step to guide the user through the menus to execute the various commands necessary to utilize the radio's various functions. The principal concern in this project was that there might not be enough time to prepare all the graphics. History relates that there was more than enough time, but then another concern arose: the PDF version of the manual, processed without compression of graphics, was over 10MB in size! There was a lot of debate, but ultimately th!
e graphics all stayed in the manual that went to print.
The old saying "a picture is worth a thousand words" can be overdone. However, when there is a chance that readers of technical documentation may find that mere words only cause confusion, it seems to me that a picture helps clear away the fog. Yet there are companies who strenuously oppose such a practice.
When functionality of language is not sufficiently clear, what other methods exist to clarify to the user? I am very interested in hearing how others approach this problem. I use the method of graphics because it is the one that I live daily, but there may well be other ways to achieve the same effect.
- Maury
---------------------------------------------------------
Get free personalized email at http://geocities.iname.com
