Re: Recommended books on tech writing
Try my web page: http://www.docsymmetry.com/books-for-technical-writers.html
That's an exceedingly good list, with the right emphasis on style and usage. Perhaps there should be more "how to write technical content" -- but then again, that's probably better learned in the classroom or on the job.
I have to differ with your assessment of the Microsoft style manual. It is worth having around for reference, but I don't consider it a good authority on usage. First off, MS's writers are notoriously sloppy with terminology and organization. (My last job involved documenting an API that built upon MS's APIs, so I had to spend a lot of time reading Windows API docs. An exercise in frustration and confusion.) Second, they place too much emphasis on Big Rules. Rules are important, but you have to use some intelligence in accepting and applying them.
We've had this discussion before:
http://www.raycomm.com/techwhirl/archives/0312/techwhirl-0312-00616.html
But the control jargon issues you mention give me fresh grist for my mill. The idea that end users don't need to know the term "combo box" assumes that the concepts encompassed by this term are only useful to GUI designers, not to GUI users. And that's not quite true. Standard controls, like the combo boxes, each define a collection of idioms that a user can learn once and apply in a lot of different contexts.
It might seem that these concepts are all intuitive and visual, so the fact that they all relate to soemthing called a "combo box" is irrelevent to the user. But that's not quite true. A user who navigates and selects solely with the mouse probably can work that way. But it's inefficient for a user to use combox boxes without knowing that you can skip down to the Zs using the Z key. It's also useful to know that you can make the list drop down without clicking on the button (type alt-down-arrow).
Keyboard navigation tends to get neglected, both in GUI design and user documentation. That shortchanges all users, and imposes severe hardship on many. There are physically disabled users who can't use a mouse. Mouse aversion is also a popular strategy for avoiding repititve stress injury and/or aggravating exsiting RSI conditions. If software and documentation is to be accessibility compliant (and this is often a legal requirement) you can't ignore these issues.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ROBOHELP FOR FRAMEMAKER TRIAL NOW AVAILABLE!
RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web. The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4
---
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.
Previous by Author:
Re: Authoring Tools Advice
Next by Author:
Re: Recommended books on tech writing
Previous by Thread:
RE: Recommended books on tech writing
Next by Thread:
Re: Recommended books on tech writing
Search our Technical Writing Archives & Magazine
Visit TechWhirl's Other Sites
Sponsored Ads