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.
-----------------------------------
chuck martin wrote:
You shoudl not be designing, either product or documentation, primarily
for "power users." Nor should you primarily for beginners. Focus your
efforts on perpetual intermediates, then add enhancements for outliers
and corner cases when appropriate.
-----------------------------------
Excellent point in general, but I'd rather take it one step further. Design for a specific user. In some cases this might be the novice user. In some cases this might be the intermediate user. And in some cases this might be the advanced user. That target will have a dramatic impact on design, and should have a dramatic impact on how you write about the product. The question that no one has asked the original poster is "who is this product for?" Goals, experiences, expectations, and willingness to learn will be different. (At least I don't think that question has come up, maybe it has). That should inform our advice.
I don't know, I guess my orginal point was against what seems to be the de facto assumption that one can NEVER use technical terms in documentation, and while no one has suggested that in this thread (I don't think so at least), I have heard it argued, and I have seen it done. That attitude is as backwards as assuming that one should always use technical terms.
---------------------------------
Besides, users are far from "stupid," they just don't know about your
product. They are smart in their own domains--which is where their
priorities lie, not in learning about what you're so passionate about. We have the power and the capability to understand how users work, play, and communicate, and we should be the ones who bend to accommodate them, not vice versa.
---------------------------------
I agree and I feel that the assumption that we can _NEVER_ use technical terms, and the desire to invent a new word for an existing word simply because the original sounds too technical, is assuming our audience is too stupid to understand something.
I would argue caution to the notion of bending, because I have seen it taken to ridiculous lengths. Bending doesn't mean always replacing technical terms.
Be responsive to user needs in whatever form that takes. :-)
SEE THE ALL NEW ROBOHELP X5 IN ACTION: RoboHelp X5 is a giant leap forward
in Help authoring technology, featuring Word 2003 support, Content
Management, Multi-Author support, PDF and XML support and much more! http://www.macromedia.com/go/techwrldemo
>From a single set of Word documents, create online Help and printed
documentation with ComponentOne Doc-To-Help 7 Professional, a new yearly
subscription service offering free updates and upgrades, support, and more. http://www.doctohelp.com
---
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- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
