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.
John Posada wrote:
>> Sounds cool, but my experience is the manager who would rather
>> get a budget for someone with the skill, instead of getting a
>> training budget for existing staff. That manager is everywhere,
>> doesn't come from
>>
>
> I know for a fact that we have a specific budgeted number allocated
> toward training. I won't give the number here, but it is not paltry.
>
That is cool. I've been through the training-requirement-for-bonus
scenario, and I gobbled trainings up (always met my quota) but the
in-house web-delivered and stand-up training that was authorized were,
well, generic and weak. I've never seen an employer pay for anything
more than that, let alone provide money for training in a major
tool/technology/methodology I wanted to learn. I think one employer
offered to pay for coursework, but I couldn't find the time.
>
>>> By the way, aside to John, I can read about usability and
>>> learn some hints to apply to my work, and not have to take
>>> a formal course - much of which would be me-or-my-employer
>>> paying for review of stuff I'd already read - but it won't
>>> help me any more or less in talking with the company usability
>>> engineer(s). We don't have any of those.
>>>
>
> Hints. Hints does not make you literate in any technology or
> methodology.
>
I think Kevin (whose quote that is) was probably using the rhetorical
device of meiosis there. By hints, I suspect he meant principles. For
me, usability technology or methodology for tech writing is pretty much
pie-in-the-sky, except when I am lucky and glean a few principles
(hints) from usability studies in other areas. This feeds back to the
idea that documentation users have certain responsibilities too. I put
out a good manual, but they have to read it to get the benefits. I may
not be too good at selecting fonts that are easy to read under
fluorescent light, and I may not use white space well, but they still
have to read it. The savings in usability study costs are fabulous.
>
>
>> I worked with a PhD Human Factors guy one time. He wore
>> a lab coat and did a workplace documentation experiment to
>> see if people prefered left-right pages or all-right pages
>> for documentation in 3-ring binders.
>> The result? Inconclusive. Fuh, he had it made.
>>
>
> The key phrase is "one time". To judge what he does by one thing he
> did is like judging technical writing because one day, you observered
> one spending the who day changing a document set from 10 pt to 12 pt.
>
One time is a small sample to draw conclusions from, I'll agree.
Anyway, the guy was a member of the product development team--this was
hardware with an elegant user console that bespoke the value of Human
Factors Engineering. If that skill transfers to documentation tasks,
I'm not sure that I've ever seen the result, except when a lot of ducats
are budgeted for elegant documentation.
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include single source authoring, team authoring,
Web-based technology, and PDF output. http://www.DocToHelp.com/TechwrlList
Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
