Won’t happen I know, but a gal can dream can’t she?

I think managers in charge of a product ought to lose $100 in bonus for every complaint received about the documentation, then they’d have some incentive to put someone half-decent on the job. It’s amazing how people do what they’re incented to do and don’t do what doesn’t count. As my HR prof said, you get what you measure.

That explains *so* much.

It’d be funny–except it’s not.

Many years ago I worked with a major defense contractor as vendor. When they’d bring engineers over from Pakistan or Korea, they’d put them to work for 3 months in the technical writing dept to learn English, then they’d shuffle them into their technical specialty.

Confidence inspiring.

MS help files are worse than you can imagine. In our classes we ALWAYS teach people what the different parts of the screen are called, so when we get calls we can be told “my standard toolbar” disappeared, as opposed to “I don’t know where the long thing at the top of my window went” (not that we don’t get those calls).

With the latest revisions I usually had to delve deep into the help files to figure out what the hell this new widget was called, and as for having a help file that labels all the parts of the screen? Forget it. Not happening.

As far as the writing, some is good, but much is along the lines of what I quoted there.

And it makes me MAD, because crap like that is why people don’t bother to read the documentation WE put out, because they automatically distrust software instructions. (Hello? That’s why we write our own damned documentation! READ IT!)

I do know that when my husband was getting his CS degree, every class required them to write documentation for their code. Unfortunately, they usually did it to turn it in, and quality tended to… lack.

And are people willing to hire people who can write to do this? HA! Let’s say that I lucked into my position and now they have me they’ll keep me, but the documentation we had before I took over? Forget it. They had whoever had free time write it, and that’s how it read. I think people tend to use textbooks as the template for user manuals–throw as much technical jargon in as possible, assume a high end user, and everyone else? too bad.

Yeah. In case you hadn’t noticed, technology is one subject likely to set me off.

And the former Marine in my lab made sure all the Chinese grad students in our lab knew what that acronym meant.

Part of the problem, I think, is the user, most people don’t use Help, or can’t be bothered to look in the Help file (hmmm, maybe we need to update the phrase RTFM to RTFHF, oh wait…). So, in the interest of cost effectiveness, MS first decided to delete in the paper manual, and now the embedded manual is going away slowly – being replaced with idiot-o-grams and video. People simply can’t be bothered to know how their systems and software actually work – this is equivalent to driving a car, and not knowing how to change a tire.

The rest of the problem, I think, is the tech writers. They’re computer geeks, and worse, they’re MS insiders. They start from a series of assumptions – i.e. they think everybody who reads the manual and help files has the same level of understanding they do. Wrong. What they need is a 74 year old man with bi-focals and a deep seated fear of computers to do their proof-reading. MS also needs to adopt industry standard terminology – or build their search engines with enough AI to make the connection between accepted terms and what MS has actually decided to name the function in this build.

And I agree with you, I have no idea what that phrase is supposed to mean.

::running away now::