Re: Benchmarking Technical Documentation

Subject: Re: Benchmarking Technical Documentation
From: "Kelly Williamson" <kwcwtech -at- iwaynet -dot- net>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Wed, 25 Jul 2001 15:20:49 -0400

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.

/Kelly Williamson
Columbus, OH



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

*** 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.


References:
RE: Benchmarking Technical Documentation: From: Mike Stockman

Previous by Author: RE: Benchmarking Technical Documentation
Next by Author: Re: New TECHWR-L Poll Question
Previous by Thread: RE: Benchmarking Technical Documentation
Next by Thread: Benchmarking technical documentation?


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


Sponsored Ads