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.
RE: I've been wrong all along...more pictures less words
Subject:RE: I've been wrong all along...more pictures less words From:"Lauren" <lt34 -at- csus -dot- edu> To:"'Daniel Ng'" <kjng -at- gprotechnologies -dot- com>, <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Fri, 10 Aug 2007 11:28:45 -0700
> From: Daniel Ng
> My general mantra for
> electronic
> help has been more conceptual visio diagrams, concept descriptions,
> detailed how to steps, put in examples, no software
> screenshots(minimal
> at least).
I don't see how a piece of software can be effectively communicated to an
appropriately wide enough audience without screenshots. Words are always
abstract representations of concrete concepts and screenshots with
explanations are about as concrete as a writer can get at conveying
information, short of literally holding the hand of the user and putting the
user through the motions of using the system.
As writers, we see things in abstract terms. This is part of our job. We
also need to communicate these "things" as concretely as possible without
insulting our readers.
No matter how clear or concrete we think our documentation is, we can never
escape the fact that words are always abstract representations. People who
engage in careers that do not normally require a lot of abstract thinking,
such as factory workers, will not be very receptive to having to read about
how to do their jobs. So pictures, like screenshots, how-to diagrams, and
drawings of people doing a certain job are a must.
> Wats a training guide when you have a user's guide.
I've seen this a few times. I have developed PowerPoint presentations and
training plans to support training, but the documentation that supports
training is usually the user guide. Trainers like to walk the users through
the system with the user guide and the user guide becomes a reference for
the user after training. They like having familiarity between the training
and the use of the system with one document that the users mark-up with
their notes. After about a week or so, the document just becomes desk
clutter anyway because the user knows how to use the system.
> Have I got my assumptions wrong all these years? I guess change is
> sometimes difficult. Have I been wrong?
I think that what is happening in the 21st century is that technology is
reaching people who otherwise would not have used technology. Line-workers
are now in positions that require using software. Using software requires
reading documentation. Reading requires synthesizing abstract concepts.
Synthesis of the abstract requires using parts of the brain that are not
required for line work, concrete concepts. The brain burns 25% of a
person's calories per day, so using one's brain can cause fatigue if a
person is required to use more parts of their brain than they would
normally.
Here's an example. Go buy a bicycle that is in pieces in a box. Take out
all of the pieces. Now assemble that bicycle using instructions written
with only words and no pictures. How about using a new database developed
in an environment and language that is new to you? Perhaps this new
database places GUI controls in positions that are unfamiliar to you. Keep
in mind that any software used by a line-worker will be unfamiliar to that
line-worker because these are people who do not normally use software.
I think that, in this case, part of understanding the audience requires
understanding that an audience may not be of the sort that will want to read
documentation. This, of course, is not a criticism given that I have the
utmost respect for people involved in manual labor. When I want major work
done on my car, I don't choose somebody that has read a lot about cars, I
choose somebody with experience working on cars and a positive track record.
These are the types of people who get overwhelmed when I discuss my work,
but then I get overwhelmed by some car issues.
When I worked in auto parts (my first career), I would look through
specification manuals. I would have been lost if there weren't pictures to
illustrate what parts looked like. Back then, I didn't know the difference
between a differential and a transfer case, so I needed pictures. I can
fully understand the need to illustrate documentation effectively.
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
