Re: What Are Writing Skills

Subject: Re: What Are Writing Skills
From: "John McDermott" <jjm -at- jkintl -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Sun, 27 Feb 2005 10:14:47 -0700


On Sun, 27 Feb 2005 00:00:17 -0700, TECHWR-L digest <techwr-l -at- lists -dot- techwr-l -dot- com> wrote:

I am a bit of an odball on this list, which is why I comment fairly infrequently. I am at various times a TW, a trainer and training materials developer and a product engineer. As a consequence, I often see things differently than some members of each of the three groups. I have some comments on this thread that may be different than some others.

From: Tony Markos <ajmarkos -at- yahoo -dot- com>
Are data flow diagrams needed for cash register
systems or cell phones? I don't know; they appear to
be, software wise at least, very small systems that
don't require alot of analysis to understand.

First, whether data flow diagrams are needed depends entirely on the purpose of the document. A basic user guide is unlikely to need them. Cash registers can be highly complex tools, though, particularly if they are networked to form a complete Point of Sale system. A friend designs such things and they are not simple. (Yes, the cheap ones from the office store are pretty simple.) Cell phones these days are complex with web browsers, cameras, Bluetooth, etc. Some even let users download Java programs. Nothing simple there.

From: "Sharon Burton" <sharon -at- anthrobytes -dot- com>
How you understand how the product works may very well tell you nothing
about what the user uses the product for.
The engineers understand how the product works. What they don't always
understand is now the user will user it to do their tasks.
...
Structuring the information refers to climbing in the users head(s) and
identifying those things the user needs to know to use the product for what
the user wants to use the product for.

This is a big issue in training and TWing both. A *user* manual needs to focus on the *user*; a manual describing how to change the software needs to function on how the software works.

I often see manuals and training materials dealing with how a product works, or how menu items work when the emphasis should be on how to get the task done. Most users read manuals and take courses to learn *how to do* something. The features are not the issue, getting work done is.


Tony, I really don't care what you call good engineering or bad engineering.
Every engineer I've known, every kind of engineer I've known, including the
one I was engaged to (who was a breath-takingly brilliant engineer), is
interested in what the technology does, not what you want to do with it.

Well, then, perhaps you need to get out more :). Seriously, there are probably way too many engineers concerned with what the technology does than what one wants to do with it. I, and many I have taught and many I work with are very deeply concerned with "human factors". I know it is popular today to add features that are cool, but nobody uses. I have lots of software that does cool stuff that I do not use. I have lots of software that I use that does not do what I need it to (e.g. my Powerpoint will not search on font while Word will. I have to write VB code to do the search in ppt. Why isn't it the form as it is in Word?)

When I design software or prepare a course, I start with some sort of needs analysis. "Why do you want this?" or "What are you going to do with this?" are number one questions. My friend who built the point-of-sale system spent lots of time looking at how the salespeople did their jobs before he wrote the system. His goal was to minimize the changes they had to make to use the system. So many systems today require changing the existing (possibly very good) business process in order to use them. This is often a symptom of bad design -- not looking at what the user wants or needs before applying "technology" to the solution.

I could go on, but this is enough of a rant. To get back to the initial question, if something helps the end user of the document understand how to get his or her work done, include it, if not, don't.
--john



--
John McDermott, CCP
Writer, Educator, Consultant
jjm -at- jkintl -dot- com www.jkintl.com
V: +1 505/377-6293 F: +1 505/377-6313


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo:
http://www.webworks.com/techwr-l

Doc-To-Help 7.5 Professional: New version with new features, improved performance and reliability, plus much more! Download your free trial today at www.componentone.com/techwrlfeb.

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.



Previous by Author: Re: Caret or Carrot
Next by Author: Re: Re: Two TOCs (Was: Transitioning user expectations...)
Previous by Thread: Pricing of technical writing?
Next by Thread: Re: What Are Writing Skills


What this post helpful? Share it with friends and colleagues:


Sponsored Ads