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.
I think part of the problem you are having is that you are not reading
closely. I gave you several ways to structure information generally - the
gatekeeper to least done tasks was an example.
Another problem you're having, I think, may stem from the idea that there is
a rigorous, structured way to rigorously structure information. There isn't.
There are several ways that are accepted as good practices, because users
have responded well to them over the years. And that means they work - they
met the users needs, which is the point to what we do.
Look up minimalist documentation. It was a change of paradigm that hit the
tech writing world about 1980. It dramatically changed how user docs were
done and we are still working out that dramatic change. One of those big
changes was the focus on the user and what their needs are and how do we
meet those needs.
Finally, you are also asking us to describe air, in a way. Beyond the
general guidelines we have given you, we all know what structuring
information is:
Designing the information (general information, conceptual information,
descriptions, procedures, glossary, index, etc), in such a way that makes
sense to the user, keeping in mind the user's environment, tasks, ability,
learning styles, and the nature of the product. (that's minimalism, btw)
Remember, the product may be a cash register, a garage door opener or a tool
to manage changes to your very large Oracle application. Understanding what
the user needs when it's a garage door opener is very different than when
it's a software product.
Structuring information is not necessesarily analyzing the information. The
analysis is for you to understand the product. Now you need to take your
understanding and figure out how to help the user understand WHAT HE OR SHE
NEEDS TO UNDERSTAND TO DO HIS/HER TASKS IN THE PRODUCT. This may very well
be a different level of understanding. The user may never need to know all
of what you know. Given the time you probably take and the depths you go to,
I can almost certainly say the user never needs to understand the product
the way you do.
Do I have a methodology or book I can point you to? Other than the Nuremberg
(sp) Principle, not really off the top of my head. Can I teach you some
specific ways to learn to structure the information for your user? Yes, I
can. Take my online class Writing Effective User's Guides starting this
spring from UCR Extension. I can and will teach you several ways to
structure the information for your user.
sharon
Sharon Burton
CEO, Anthrobytes Consulting
951-369-8590
www.anthrobytes.com
President of IESTC
-----Original Message-----
Bruce:
I started the thread "What Are Writing Skills?" and
have been following posts closely. I was told by
several listserv members that the big thing is skills
in "structuring information". However, the only
definitions of "structuring information" that I have
been given sound like definitions of analysis.
I know what analysis is, and I can define specific,
concrete techniques used and steps taken in it. In
order to differentiate between analysis and
"structuring information", I seek to identify the
specific, concrete steps taken and techniques used in
"structuring information".
I have also checked this listserv's archives, googled
and yahooed. I only got hits on structuring
information for XML and on the need to sometimes
create list and graphs.
Surely, the listserv members who told me that
structuring information is "were it's at" were not
speaking of periferal things like XML and creating
lists! This "structuring information" must not have
more meat to it than that!
If "structuring information" is such a basic and
essential thing to TW, as David Neely states it is,
why does it not seem to exist?
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.
