Interrobang's Journal: Straw Poll: Do Technical Writers *Do* That?

In my current job, and in several of my past jobs, a significant portion of my time (say, as much as 20%) is finding inconsistencies/typos in the interface, noting and logging them, and tracking crashes and runtime errors and what I did to produce them. (In my current job, they've decided to use my method of error logging in their fix cases now!) An example of finding a typo in an interface would be noting and logging an incorrect apostrophe usage in a menu item ("Copy another suppliers' setup"), or finding an inconsistency would be noting that some fields refer to an item by one term and other fields refer to the same item by another term (in the current application, we're having a persistent problem with switching the term "Dealer" over to "Ship To" and standardising the abbreviation for "Purchase Order" to "PO" not "P.O." or "Po." (Incidentally, I've seen the abbreviation used both the two former ways on the same tab in the application.)

Is this normal tech-writing kind of stuff (once a copy-editor, always a pain in the ass), or have I really and truly crossed over into testing (or what)?

Incidentally, this is why I think there should be a separate job title for someone who copy-edits the text in a UI.

Twenty percent seems a bit high...

[johndiii]

Checking the UI for wording, grammar, and spelling has been the province of the tech writers in each of the places that I've worked that have had them on staff. Sadly, a significant number of developers and testers just aren't competent enough in the language to do it themselves. This is among those whose native language is English. So it's a matter of necessity to have someone who can recognize incorrect grammar and misspellings, not to mention menu items or interface text that does not say what was int

Re:

[Interrobang]

It's not that I mind doing it, exactly, and they seem delighted about my ability to find and report bugs (I've had that experience at two jobs now, so I must be doing something right). There are a lot of problems with the UI on this one application, though.

We do contract with one professional tech writer to oversee the documents. But I'm not sure that I completely trust her -- she confuses "tantamount" and "paramount".

Oii, no, don't. *wince* Thanks a lot, whoever you are, for making the rest of us l

Re:

[johndiii]

I've actually been keeping you in mind as a telecommuter for a while, and I would certainly make that recommendation should there be a position.

Re:

[tomhudson]

Sadly, a significant number of developers and testers just aren't competent enough in the language to do it themselves. This is among those whose native language is English

"pro-grammar knot knead two unnerstan engrish two right coed - just doStupidCapitalizationTricks()"

(I know, to be really authentic, I should have written "grammer" instead of grammar :-)

The sort of mistakes you're looking at come from a poorly-organized project - nobody has taken the time to put all the strings into one or more com

Re:

[johndiii]

Two jobs ago, I was in charge of the internationalization effort for a factory automation package. We had committed to our international partners to deliver French and German versions within 30 days of delivering the English version. Due to the package's origin as a DOS-based real-time database kernel, its age, and the tendency to grow by accretion, we had 180 different executables that had to be internationalized. And four different ways of doing it - a proprietary method involving text files stored in

Re:

[tomhudson]

But by dint of starting the translation way ahead of time, we actually did bring it in by the deadline.

That's probably a first in the computer world :-)

I couldn't help but notice that the string-parsing routines I'm working with aren't "utf-16 clean" ... and because the original "designer" was in love with global variables, its not going to be just a case of substituting the wide-character versions for strlen(), sprintf(), strcat(), strtok(), strstr(), etc. And people wonder why I keep saying it would

Spellcheckings, sure... the rest? Testing

[FortKnox]

Spellchecking is almost a must for tech writers, cause geeks are notoriously either bad spellers, or english as a second language. Crashes and such, though, isn't your job. Its nice if you run across one that you report it, but actually filling out bug reports and attempting to find them is well out of the realm of your job description.

Job description?

[Interrobang]

You're assuming I have a job description... :)

I don't think I've ever had a job description qua job description. They call me a tech writer because I spend most of my time hacking out documentation, but I also do a significant amount of information design and management, some bug tracking, and a little web work. (I wrote some copy for the website at work and sent it to the web guy as a raw HTML file, for example.) I've also done course content writing for CBT and asynchronous distance learning in the p