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:RE: craft vs. science vs. art From:"walden miller" <wmiller -at- vidiom -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 24 Jun 2002 12:00:25 -0600
Phil et al.
<< you ask>>
How about an example of something successful in one document failing
miserably in another?
I always like to point to the use of graphics as un/successful in
1. The floating hand which points to something of interest is very
successful in most first world cultures.
It is absolutely unsuccessful in many third world cultures (a hand separated
from a body is disconcerting and overpowers the concept of pointing).
2. Cutesy characters (like Microsoft Help's talking paper clip) are
successful in some docs for some audiences.
Cutesy characters are not successful in API documentation.
Other examples of un/successful elements in docs:
academic writing uses passive, convoluted (and often quite long) sentence
structures. User manuals shouldn't.
Hardware trouble-shooting field manuals are very effective with the use of
tables (often the entire manual is a set of tables)
Because tables condense information (useful in the field), often tables are
considered less-user friendly in documents such as tutorials and user
Inset boxes are tough to decide when to use. Textbooks seem to make great
use of them. Journalism uses them constantly. User manuals or any manuals
that should be read serially seem to be less targetted for inset boxes.
(merely an observation)
the list goes on and on.
IMO, Technical writing is a blend of using techniques, genres, voices, and
designs to persuade a reader to use the document in a particular manner. To
the extent that the reader uses the manual in the proposed fashion, the
document (and writer) is successful. The interplay between intended use,
style, design, genre, etc. and actual use is the place in which technical
writers live. It is not a science in any traditional definition of science
(i.e., adheres to a scientific methodology, scientific paradigm, etc.). It
is a craft or an art. Take your pick.
I still find it humorous that the discussion is between science and craft.
Traditionally, there have been two arguments: science or art; and art or
craft. With implied priorities given to science over art and art over
craft. I do not make that value judgement on importance of science, art,
and craft. Instead I feel that science and art are both attempts to make
sense of the universe in very rhetorically charged manners. craft is a term
I do not use much except as a close synomym for discipline (what is the
craft of science, craft of writing, etc.) It is akin to the Zen concept of
practice. What is your practice?
Enough for now.
Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l
Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.