Technical Writing, a form of technical communication, is a style of formal writing and business communication, used in fields as diverse as computer hardware and software, chemistry, the aerospace industry, robotics, finance, consumer electronics, and biotechnology. Good technical writing clarifies technical jargon; that is, it presents useful information that is clear and easy to understand for the intended audience.
When you think of the crowd, you probably think about a specific mass of people who use the software and hardware that we document every day. The interesting thing about the crowd is that it doesn’t necessarily mean people outside of the enterprise in which you’re working. There are people in your enterprise who can do a lot to help you with the documentation, too. Developer, product managers, QA analysts. They all have knowledge that you can and should tap.
Some of my projects include community-involved documentation. When you work for a church, it’s not hard to find dedicated members willing and committed to sacrificing a few hours for a higher cause. To harness community efforts, I gathered up a large pool of volunteer names and formed a listserv. I communicated project needs with the listserv members and asked for help. Despite some contributions, the majority of volunteers are hindered by too many obstacles — access to information, time, standards, and more — to contribute much. As such, I’ve begun to change my expectations from content creation to content review and feedback.
After carefully studying the various areas that can be touched upon, we identified performance and the need of systematic Technical Writing education as the focus for our research. We prepared two surveys and then hosted them on SurveyMonkey.com for 50 days. The first survey was for Technical Writing Managers (Hiring Managers) and the second was for Technical Writers. The first survey was completed by 14 participants whereas the second survey was completed by 185 participants.
He demonstrates how ministers of state who speak different languages often choose English as the most convenient language of communication. He cites the 11-nation European Central Bank in Frankfurt as a typical organization that works only in English. And he notes that many of the journals published by respected international organizations such as the Pasteur Institute also are published in English. TC-Forum is another example.
Personally, I’d rather see it done as a series of courses and tests covering major areas of the profession. Basing it on a portfolio immediately cuts out a large portion of the writing community who produce proprietary material. Most writers would probably be better off pursuing an advanced degree like an MA from a university that offers a technical communication program.
You are a high-tech/Bio-tech company and your first product is nearing release. The product requires documentation and you ask your self what are our options? Before deciding you should consider these factors.
I have been pondering technical editing processes. Most notably, as I play on my iPad putting together jigsaw puzzles made from my favorite vacation photos, I have pondered whether most technical editors like putting together jigsaw puzzles.
In the world of development, the need to track bug reports and enhancement requests are a given. But they're not generally required for documentation, in the way they are for code Quite the reverse. For documentation, bug reports and enhancement requests provide little benefit, and generally impede progress. This post compares documentation and code, showing why bug reports and enhancement requests are so vital to the code base, and at the same time why those reasons simply do not apply to documentation.
Switching bosses within the same company is not an entirely smooth process. On the day of the crossover, I showed up to work and discovered my badge and my email deactivated. It took most of the day to get security to reactivate my accounts.
Rule number one for a contractor is to never panic about what happens your first day. First days are naturally chaotic, and often companies are not fully prepared for you. Because contractors are usually brought in to solve a particular problem, the people are anxious to get you started, but companies, especially large ones, are not geared for quick action.
My face-to-face interview with the company was similar to my phone interview. So similar, in fact that more than once I found myself answering the same questions I had answered over the phone. They did throw a couple curve balls at me, however. The strangest question I was asked was, 'If we called your references, what would they say about you?' I was unprepared for this one, and I ended up talking more about my references than about what they would say about me.
When I originally spoke to the recruiter on the phone, she gave me a brief description of the job and asked for my rate. We negotiated the rate for a few minutes and came up with an acceptable number ($25 an hour) and she sent me an e-mail with the full job description and a short agreement asking me to confirm her representation and my rate. I sent back my confirmation and that was it for a while.
Documentation for consumer products gets a bad rap. Often, it's deserved. But you can't paint all documentation with the same brush. This post looks at the good and the bad in consumer documentation, and at the elements which can make that documentation good.
Funny thing, documentation. Ought to be easy enough, surely? So why the disappointing results? What IS the elusive spark which distinguishes the professional author from others who put their hand to the pen (keyboard)?
For most of the technical writing community, task-based documentation has become the panacea for presentation of end-product document (in any of its myriad forms including traditional linear manuals and online help). We believe, however, that applying this method to a complex tool, (for example, a software tool without a Graphical User Interface), challenges the task-based approach.
The documentation strategy over the course of some development projects has, unfortunately, resembled a building with several add-ons rather than a single, unified structure—wings added, walls moved, different materials used. Where I live, no one builds like this, except in residential neighborhoods and on college campuses. This approach doesn’t exactly make for a consistent experience for users. It’s what I’d call documentation sprawl.
what can you do if you don’t have a technical writer or the standard tools? You just might have to go quick and dirty. Quick and dirty documentation is a band aid, no doubt about it. But it’s better than nothing. This article presents some thoughts about ways to deliver documentation quickly and cheaply.
I love reading different community perceptions of both FLOSS Manuals, where we write open docs for open software. I’m also lurking on mailing lists and forums where open source projects are figuring out documentation needs for their users. Forgive me if I ramble a bit, but I’ve been thinking about these concepts lately while discussing them with other writers.
The certificate in web design? Not necessary. But a working knowledge of HTML and CSS? Yes, critical, because everything is moving (or already moved about 10 years ago) to the web, including documentation. If you create help in a print environment only, chances are you still publish the PDF on a website somewhere.
There are at least two broad categories of technology that managers often confuse. The first is technology that replaces a particular skill. For example, the cash register at a McDonalds has technology that relieves cashiers from doing math, so they can hire people who are not skilled in math. The second is technology that allows a skilled practitioner to be more productive. For example, the computer makes it possible to write and edit text much more easily than a typewriter, but it won’t make a bad writer better.
For the techno-savvy TechRepublic member, writing in some form or fashion is an almost daily occurrence. But how effective is your communication? In this interview, author Barry Rosenberg shares his thoughts about the current state of technical writing skills.