A directory of resources inthe field of technical communication (and technical writing).

Technical Writing

351-374 of 1,149 found. Page 15 of 46.

About this Site | Advanced Search | Localization | Site Maps
 

« PREVIOUS PAGE 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25  NEXT PAGE »

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.

 

351.
#32216

How to Justify Hiring Technical Writers During Hard Economic Times

With our economy still on the down slope, it is difficult for technical managers to justify keeping an excessive amount of technical writers on their staffs, let alone hiring new ones. In many cases, managers feel they don’t even need writers, arguing that everyone has writing ability. Of course, today’s technical writers not only write, they also perform many other tasks: programming, web development, training, and so on. Add to that the fact that many are also highly trained and certified in other areas besides writing.

Datta, Aparna. TechCom Manager (2005). Articles>Management>Writing>Technical Writing

352.
#21261

How to Make Yourself More Marketable in a Small Company   (PDF)

In a time when corporate downsizing is the norm rather than the exception, technical writers must constantly increase and market their skill sets to make themselves more valuable to employers. Based on our experiences as technical writers in a small company, we will define why and how to market yourself:

Holman, Peter M., Susan Gonzalez and Jennifer Privette. STC Proceedings (1997). Careers>Writing>Marketing>Technical Writing

353.
#31714

How to Market a Documentation Department

When you first ventured into the tech writing ranks, marketing the department was likely the furthest thing from your mind. You already had work to do, so marketing was somebody else's job.

King, Robert. Writing Assistance (2006). Careers>Management>Technical Writing>Marketing

354.
#36706

How to Prepare and Do Research For a Technical Document Before Writing It?

There are many preparatory steps in technical writing that you as a writer need to take before actually sitting down and start writing a technical document. Here are 7 issues you need to consider in the pre-production phase of your documentation project.

Akinci, Ugur. Technical Communication Center (2010). Articles>Documentation>Research>Technical Writing

355.
#34027

How to Structure FrameMaker Paragraphs While Using the Unstructured Interface

Using the structured features requires advanced training and you probably won’t need them anyways unless you’re doing any “single sourcing” (which is the topic of yet another article). For example if you were doing any XML-based authoring or “database publishing” then you would definitely need to learn how to use the FrameMaker’s structured interface. However, there is an easy way to imitate structured documentation while you are still in the unstructured mode. This is one case in which you can have your cake (unstructured FM) and take a bite out of it too (by enjoying one selected feature of structured documentation).

Akinci, Ugur. Technical Communication Center (2009). Articles>Document Design>Technical Writing>Adobe FrameMaker

356.
#36383

How to use Advertising in User Guides

Putting advertising in user guides may seem rather flaky at first, but it could work. Here’s why.

Standard Operating Procedure Templates (2010). Articles>Documentation>Technical Writing>Marketing

357.
#35496

How To Use An Apostrophe

A clear, well-illustrated guide to when one should (or should not) use an apostrophe.

Oatmeal, The (2009). Articles>Writing>Grammar>Technical Illustration

358.
#34039

How to Use the Bulleted Lists Properly in Your Technical Document?

Bulleted lists are important in technical writing. They summarize information in a manner that is easy to read and absorb. Use them whenever you can to get your information across quickly. Bullets are ideal for things-to-do, equipment, sets, collections, cooking ingredients, and all kinds of other lists.

Akinci, Ugur. Technical Communication Center (2009). Articles>Documentation>Style Guides>Technical Writing

359.
#21429

How to Write a Report Without Getting Lynched

You put forth your best effort to explain to the stupid sods exactly how and where they screwed up, then they have the temerity to not appreciate your fine efforts. Here's how to write a report that will cause change, instead of uproar.

Tognazzini, Bruce. Nielsen Norman Group (2001). Articles>Usability>Reports>Technical Writing

360.
#34369

How to Write a Technical Report

This presentation describes the standard structure of a lab report and provides a methodology for successfully producing such a report. It includes a description of the generic structure of a report and variations on this theme.

Jobling, C.P. SlideShare (2007). Presentations>Writing>Technical Writing>Reports

361.
#26024

How to Write a White Paper

A white paper in the high-tech industry is a technical document that describes how a technology or product solves a particular problem. It's a marketing document and a technical document, yet it doesn't go too far in either direction. A good white paper is informative and is designed to show off the advantages of a product or technology.

Knowles, Michael. Writing World (2001). Articles>Writing>Technical Writing

362.
#21981

How to Write Copyright Pages   (Word)

A well-designed user guide contains a copyright page, which provides copyright information for your company's products as well as for any third-party products mentioned in your document.

Amott, Lyndsey. Docsymmetry (2004). Articles>Intellectual Property>Copyright>Technical Writing

363.
#21299

How to Write Instructions

These guidelines are written primarily for people who are not technical writers. If you are new to technical writing, you will probably find these instructions useful.

Unwalla, Mike. TechScribe (2003). Articles>Documentation>Writing>Technical Writing

364.
#36809

How to Write Interesting Headings for Documentation

Perhaps our headings should focus a bit more on user benefits? For example, "Overview of batch printing - Save time and improve document organization" is a bit more engaging, especially if your customer is struggling with those issues.

HelpScribe (2010). Articles>Documentation>Information Design>Technical Writing

365.
#31181

How to Write Really Good Documentation

Write a really bad manual and you’ll not only lose users, you’ll create ex-users who go out of their way to tell others how bad your application is. Documentation matters.

Forte, Brian. Red Hat Magazine (2007). Articles>Documentation>Writing>Technical Writing

366.
#31184

How to Write Really Good Documentation: Donald Knuth Was Wrong

In the continuing absence of maturity in the software world, it’s the documentation that has to treat the tool-user with respect. Which is a further argument against Knuth’s Literate Programming. Since it’s all too common to see software toolmakers treat tool-users with short shrift, it’s a useful caution to have the ’software is written in one corner and documented in another’.

Forte, Brian. Red Hat Magazine (2007). Articles>Documentation>Writing>Technical Writing

367.
#31182

How to Write Really Good Documentation: Four Rules and an Axiom

Keeping to the four rules articulated here—and never forgetting the axiom—will definitely improve your documentation. If nothing else, recognizing and observing these rules will raise the status of documentation and the people producing it. And they’ll use that raised status in at least two ways.

Forte, Brian. Red Hat Magazine (2007). Articles>Documentation>Writing>Technical Writing

368.
#29781

How We Write: Putting the "Technical" in "Technical Writer"   (PDF)

By becoming more technical, you can interact more efficiently with software developers and qualify for a greater variety of software documentation projects. This paper outlines ways to learn more about three prevalent technologies: programming languages, databases, and Web server technologies.

Owens, David. STC Proceedings (2004). Articles>Writing>Technical Writing

369.
#38516

Hybridizing F2F and Virtual Collaboration between a Government Agency and Service-Learning Technical Writing Students   (peer-reviewed)   (members only)

This case study reviews a hybrid face-to-face (F2F) and virtual collaboration between the State of Hawaii’s Division of Forestry and Wildlife and a team of university technical writing students to indicate specific features of the hybridity as it shaped the collaboration. In a course focused on organizational authorship, students were tasked with learning about the organization’s workplace culture to successfully represent its ethos in a report on the history of forestry in Hawai‘i. Moments and modes of collaboration are discussed chronologically as they enabled successful report writing, featuring key components: clearly stipulating terms of collaboration through service-learning, assessing fit between the course and the organization, emphasizing the need for onsite visits by students to ascertain the workplace culture, conducting swift follow-up on challenges in meshing the virtual with the face-to-face, and leveraging each mode of collaboration synergistically rather than discretely.

Henry, James M. IGI Global (2011). Academic>Business Communication>Technical Writing>Collaboration

370.
#30503

Hypertext as a Productivity Tool for Technical Writing   (PDF)

Hypertext is a novel approach to computer-based information management based on associative indexing. The concept in general and the characteristics of typical systems are briefly reviewed. Strategies for applying hypertext techniques to the process of writing a technical document are examined. The way in which hypertext documents are used is discussed, focusing on a commonly encountered problem -- user disorientation within the document. Hypertext-based technical documents are compared and contrasted against their paper-based antecedents.

Lenarcic, John. STC Proceedings (1993). Articles>Information Design>Hypertext>Technical Writing

371.
#37281

I Don't Want You to Think

These are just a few ways in which we can reduce your time spent thinking about the documentation and get you back to your task at hand. Unfortunately our ability to excel at these tasks are limited by two rather large factors:

Pollack, Ryan. Technically Speaking (2010). Articles>Documentation>Technical Writing>Usability

372.
#22399

I Heart Tech Docs

A technical writing/technical communication weblog with tips, tools and templates for technical writers.

Walsh, Ivan. I Heart Tech Docs (2003). Resources>Documentation>Blogs>Technical Writing

373.
#36433

“I Never Really Understood That Feature, So I Left it Alone…”

I’m not sure what you can do to help users continue to increase their knowledge of an application. The problem is that even if you provide the means for advanced learning, whether through tips, newsletters, blogs, or interface notes; users already familiar in performing a core set of tasks are inclined to remain in their comfort zone.

Johnson, Tom H. I'd Rather Be Writing (2010). Articles>Documentation>Technical Writing

374.
#32483

I Want to be a Technical Writer

How do I break into a career in technical writing?

Basu, Anindita. Writing Technically (2008). Careers>Writing>Technical Writing

375.
#33416

I'm a Technical Writer: Dispelling the Myths

Technical Writers (aka Technical Authors, Content Wranglers and Documentation Managers) have an unfair image. This project aims to challenge this image, by showing technical writers in a different light. The photos below are of technical communications professionals, doing a variety of activities.

Cherryleaf (2008). Careers>Writing>Technical Writing

 
« PREVIOUS PAGE  |  NEXT PAGE »

 

Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon