Customer Reviews

How to Communicate Technical Information: A Handbook of Software and Hardware Documentation

5 star:		(3)
4 star:		(3)
3 star:		(1)
2 star:		(1)
1 star:		(0)

 

 

It covers a lot in the 400+ pages of which it is comprised. Much of it is devoted to the planning stages of creating a technical document (with emphasis on software user guides). This book would be great for anyone who has between 1-3 years technical writing experience, or anyone attempting to implement new documentation procedures for their department. I still refer to the book from time to time. It also serves as a very good reference tool.

This book is clear, readable and interesting (more than I can say for my other reference books on this subject). It uses not just examples of good doc writing and formats, but also examples of first-cut not-so-good ones, and contrasts them. The layout of the book is easy to use, and the content complete.

I have several other reference books on this subject, and this is the one I love.

If you read only one tech writing book, this should be that book. Saying neither too much nor too little, this book steps you through everything you need to know, from where and how to find the background documents you need in order to learn about your subject, through how to schedule your project, to how to produce your outline, drafts, and finished document. Read this book!

The reason for my post is this: it gave me a good viewpoint and methodology on how to budget, estimate, and quote hours s ell as the Software Development Lifecycle (SDLC).

This book will tell you what it takes to design information concerning all aspects of software and hardware documentation. What it does, and I believe sets itslef from other books, is how to budget and plan estimates for software and hardware technical writing.

It will tell you how to write procedures, install guides, indexes, nice-to-haves, and user manuals. It will tell you what the SDLC is and what needs to happen at each stage; very useful to a novice (me). Great book for that and a good reference manual for those looking for tips on how to write; it will take you through step-by-step on how to deliver proper documentation... invaluable.

For its time, it was formatted in a way that was acceptable. If you can see past that and take away tidbits and chunks of information, this book is for you additionalto what I have said above.

It served my purpose of learning SDLC nuances; it talks of how to write and interview SMEs (very valuable to a novice), and give a great way to figure out how to estimate and plan a project.

I give it a B+ in 2006 times. I wonder what these knowledgeable authors would write if it was updated -- and they are very knowledgeable.

Enjoy

This is the book that took me from recent college graduate with an English degree to my first job as a technical writer in the software industry. It shaped my approach to task-based user documentation and helped me hone my skills and advance in my career. I now run a technical training and documentation department (15 years later) and I still love this book! I lost my copy and I'm now reordering it!

This is a 1993 book about how to write a manual for a computer application. If you are writing a manual, it will give you some helpful ideas. However, it was written, and published with a different title, before the Internet. It does not truly help you with communicating tchnical information -- just how to write a manual.

This is very much a book for beginners. What areas it does cover are only done on a superficial level. Anyone that has any formal training/education in technical writing will find very little in this book that is not either basic information or common sense. Important areas are covered in such a way that you know that you have to go elsewhere for the full story. There are too many better books out there.

I took my first technical writing job in August, 1987 and I've been a technical writer ever since. I came across a copy of this book at a book store in Kansas City, Missouri, shortly after the book was first published. (The book store may have been a Barnes & Noble outlet.) I bought the book and read it through and through while we were on vacation in KC and I found the "style" information (Chapter 19) the most helpful. I purchased another copy of the book just a few weeks ago to refresh my memories and I find the content still useful primarily in renewing the fundamental concepts of the technical writing I want to accomplish in my daily work. I agree with other reviewers' stating the book is best suited for beginning tech writers while I add my own comment about refreshment of wonderful memories of projects past.