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.
Andrew made some really good points about why you would need to know all the
inner workings, etc. relating to complex technologies where the savvy
customer may want to use the product in a way it was not intended. I believe
I have found the crux of my problem with his original argument: when dealing
with complex technologies with savvy users, Andrew is right. You should know
all you can know about a product and the way it works. However, when dealing
with regular old software and barely-computer-literate users, you don't need
to know the code to explain what the user wants/needs to know.
Mike said:
> In this (Web application) example, a quick view of the underlying code
> could tell you, for example, how many characters a user can enter into
> a field. You could also ask the developer (who may or may not know,
> and who most likely would just look at the code) or type characters
> until the product stops you, but it's easier and quicker to check the
> code yourself.
I disagree. That was my point about testing the software and being in on the
design from the beginning. I was in on specifying that this field should
only allow, say 50 characters, so when I wrote the doc. and said maximum of
50 characters, I verified it through the interface. I disagree that it would
have been quicker to check the code; I also think it would be "safer" to
check it through the interface since the programmer could have made a
mistake in the code, that if I only knew slightly how to read code, I
wouldn't have known.
> In this example, more knowledge leads to more efficiency, because
> you depend less on SMEs to tell you what you need to know.
Bad example here....I never once asked the programmer a question when
documenting the app.--not because I was technical enough (which I was in
that instance), rather it was because I could glean all the information I
needed to know from the design specs. (which I was in on) and the interface.
> Bottom line is that if you know too little about a product, you are
> *incapable* of making a reasoned decision about what to include and
> exclude, because you don't know the full set of information that could
Not if you're in on the design and it's not a complex technology.
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
Learn about tools and technologies for user assistance developers at
The Help Technology Conference, August 21-24 in Boston, MA
Details and online registration at http://www.SolutionsEvents.com
---
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.
