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

Articles>Writing>Technical Writing>Technical Writing

629 found. Page 1 of 26.

About this Site | Advanced Search | Localization | Site Maps
 

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 »

 

1.
#24689

Policies and Procedures 1996 PIC Meeting   (PDF)

This session is intended for those interested in (a) policies and procedures as a subject, (b) networking with others concerned with policies and procedures, (c) learning about this PIC, (d) influencing the direction of this PIC, or (e) listening, commenting, or volunteering. The first portion of the meeting will briefly review the PIC's history, mission, membership, budget, teams, goals, and progress. The second portion will be open to discuss new business.

Urgo, Raymond E. STC Proceedings (1996). Articles>Writing>Policies and Procedures>Technical Writing

2.
#29622

A Process Model For Creating Accessible End-User Documents   (PDF)

Electronic information products can be made accessible to blind and low-vision individuals. This is easier to accomplish with thorough planning and execution. This paper describes a five-step model for creating accessible documentation. The steps are (1) Preparing a source file (2) Producing accessible output, (3) Testing output for accessibility, (4) Modifying a source file if needed, and (5) Modifying a production process if absolutely necessary.

Herring, Richard D. STC Proceedings (2005). Articles>Documentation>Writing>Technical Writing

3.
#20548

Adding Life to Your Documentation   (PDF)

Suggests several techniques technical writers can use to enliven their writing and improve their documentation.

Potsus, Whitney Beth. Intercom (2003). Articles>Documentation>Writing>Technical Writing

4.
#25126

Adopting Minimalism in a Corporate Environment  (link broken)   (PDF)

Minimalism is more a methodology or set of principles than a set of measurable qualities. In order for your writers to move to a minimalist approach to documentation, you must be able to explain what you mean by the term and what you expect from your writers.

Swallow, Lisa and Matt Laney. STC Region 7 Proceedings (2002). Articles>Writing>Technical Writing>Minimalism

5.
#29136

Aligning Theme and Information Structure To Improve The Readability Of Technical Writing   (peer-reviewed)   (members only)

The readability of technical writing, and technical manuals in particular, especially for second language readers, can be noticeably improved by pairing Theme with Given and Rheme with New. This allows for faster processing of text and easier access to the "method of development" of the text. Typical Theme-Rheme patterns are described, and the notion of the "point of a text" is introduced. These concepts are applied to technical writing and the reader is then invited to evaluate the improvements in readability in a small sample of texts.

Moore, N.A.J. Journal of Technical Writing and Communication (2006). Articles>Writing>Technical Writing>Rhetoric

6.
#22128

Alternatives to the Paragraph

'It's all in the manual.' How many times have you heard that - or said it in frustration? After all, when you are the person who wrote the manual, you know that all the answers are there. But time and again readers can't find what they need to know, or don't understand the material. Before you blame the reader, look again at how you've presented the material.

Hollis Weber, Jean. Technical Editors Eyrie (1989). Articles>Editing>Technical Writing

7.
#24220

Anything That Can Go Wrong: Lessons Learned from A Decade of Toolkit Documentation   (PDF)

Writing software toolkit documentation for programmers is a special challenge and opportunity for technical writers. Compared with writing software documentation for lay users, toolkit documentation is more demanding and exacting. Checking facts and finding tiny errors is like riding a motorcycle through a swarm of gnats. However, for me at least, toolkit writing has opened doors to a larger role and greater input into product design. Engineers treat me like a peer and I get to see into their culture. I know my readers and salespeople need me.

van Oss, Joseph E. STC Proceedings (1999). Articles>Documentation>SDK>Technical Writing

8.
#28580

Applying Common Sense to Technical Writing   (peer-reviewed)   (members only)

How can budding writers achieve a middle path in their approach to documentation? This no-model approach is an attempt at busting the myth that only a model-based approach works.

Chitkara, Promila. International Journal for Technical Communication (2007). Articles>TC>Writing>Technical Writing

9.
#28228

Applying Web 2.0 Technologies to Technical Documentation

This article is based on my presentation at the Institute of Scientific and Technical Communicators' annual conference in October, 2006. Every now and then, there is a change in the value of what technical authors deliver. These are moments when organisations pay attention to technical documentation. This is because they recognise that these changes mean they can create something that will be of real value to the business and to their customers. In recent years, there have been three "waves of interestingness". The first wave was the introduction of Windows Help (WinHelp). The second major wave was the introduction of the Internet and intranets. This was a time when organisations looked at how they could transfer large amounts of information from paper to online. They were faced with issues such as how users could access and understand all this information easily - issues that technical communicators deal with on a day-to-day basis. I believe we're just about to approach the new wave, which we have called "Tech Writing 2.0".

Pratt, Ellis. Cherryleaf (2006). Articles>Web Design>Documentation>Technical Writing

10.
#31780

Are We Giving Readers What They Want, in the Way They Want and Need It?

With all the talk about Web 2.0 and the attendant technologies, are readers actually being better served by documentation now than they were in the past?

DMN Communications (2008). Articles>Documentation>Technical Writing>User Centered Design

11.
#29272

The Art and Science of Policy and Procedure Writing and Publishing  (link broken)

This is an informational site dedicated to topics relevant to writing and publishing business process knowledge, especially policies and procedures. The objective of this site is to openly share information about writing and publishing policies and procedures and other forms of business knowledge.

Kopp, Gary. Policy Procedure Manual (2007). Articles>Business Communication>Policies and Procedures>Technical Writing

12.
#22689

The Art of Writing Technical Articles

My advice for those wish to become writers: Write! Write! Write! I have always maintained that great writers are born, and professional writers are made. In the born writers there is an unquenchable thirst for writing, a passion for writing. Writing is a mission. Writing is the soul of the person. The professional writer does it for a living. There is a deadline and the writer can churn out the required number of words.

Kamath, Gurudutt R. IT People (2003). Articles>Writing>Technical Writing

13.
#23226

ATTW Code of Ethics

This is a working draft of the code of ethics of the Association of Teachers of Technical Writing. As a work in progress, it is subject to substantial change and carries no authority from ATTW. It is meant only for inspection and comment by the ATTW Ethics Committee and general ATTW membership.

ATTW. Articles>Writing>Ethics>Technical Writing

14.
#23612

Avoiding Traumatic XML/SGML Transitions: Moving to XML/SGML Without Losing Your Writers Along the Way   (PDF)

When moving to single-sourcing through XML and SGML, management often spends considerable time on tools evaluation and content management, but not enough on preparing the writers for the paradigm shift to the new environment. This presentation provides some hints for a successful transition for your personnel as well as your documentation.

Gelb, Janice. STC Proceedings (2003). Articles>Writing>XML>Technical Writing

15.
#31107

Baselining Documentation on a Wiki

The dynamic nature of wikis can cause a few headaches when you need to baseline documentation that's on a wiki to correspond with the release of your product. This blog post looks at some ways in which you can try baselining wiki content.

DMN Communications (2008). Articles>Documentation>Technical Writing>Wikis

16.
#19826

The Basics of Quality   (PDF)

With constantly changing deadlines and last minute major revisions, how can technical writers ever hope to create quality documents? Members of the STC Quality Special Interest Group (SIG) will present some basic concepts that will provide insights into ways you can improve the quality of your documentation. They will look at what is meant by 'quality documentation', how documentation quality can be measured, how quality can be implemented in documentation processes, how ISO 9000 requirements can be adapted to help improve the documentation process, and how the relationship between developers and writers can impact documentation quality.

Rupel, Roberta A., Lori H. Fisher, Donald S. Lenk, Ralph E. Robinson and Richard Colvin. STC Proceedings (1999). Articles>Writing>Quality>Technical Writing

17.
#14438

Be Concise

When giving overview information, be concise. Save the details and flowing language for those that want them or have the time, but don't slow down the skimmer. This doesn't mean skip the details, just keep them from people who don't need them.

Bricklin, Dan. Good Documents (1998). Articles>Writing>Workplace>Technical Writing

18.
#25226

Being Personal isn't About Being Their "Buddy"

I have written often about the value of writing online in a personal voice. In particular, emails and newsletters lend themselves to a genuine, personal tone.

Usborne, Nick. Excess Voice (2004). Articles>Collaboration>Writing>Technical Writing

19.
#31148

Betriebsanleitungen für Anlagen   (Word)

Der Normenunterausschuss NATG-F des Deutschen Instituts für Normung e.V. ist derzeit damit befasst, Regeln zur Erstellung von Betriebsanleitungen für Anlagen zu erarbeiten.

Doculine (2002). (German) Articles>Documentation>Writing>Technical Writing

20.
#24534

Beyond Internationalization: Multicultural Education in the Professional Writing Contact Zone   (peer-reviewed)   (members only)

To bridge the gap between composition and professional communication studies, we should add multiculturalism to the widely accepted international perspective in professional communication instruction, thus transforming the classroom into a contact zone (Pratt). The practical necessity of intercultural communication in a global marketplace necessitates internationalization. The international perspective, accounting for the heterogeneity of the technical communication audience, focuses on audience analysis and leads us to encourage students to learn about the multiple, cultural layers of audience. A multicultural perspective, however, can teach students of professional communication about the complex relationship between language and ideology and the underlying forces that shape and reflect the ways we use language. Multiculturalism's critical component provides insights into the structures and ideologies of domination/subordination and provides students with the linguistic, intellectual, and moral tools for resisting fear and prejudices. Likewise, the international perspective in professional communication can inform issues of audience analysis in composition.

Grobman, Laurie. Journal of Business and Technical Communication (1999). Articles>Education>Writing>Technical Writing

21.
#14026

Beyond the Mechanical: Technical Writing Revisited   (peer-reviewed)

Optimism about the future of technical writing can be sustained only if we persist in setting for technical writing the same standards we apply to other sophisticated modes of writing and require refinement in style as well as accuracy in content. The importance of content in technical writing, of the information presented, may seduce us into seeing technical writing as purely a form of language engineering and into teaching our students to perform mechanical writing tasks, churning out dull reports to fit mindlessly into the institutional norms of industry and government.

Iyasere, Marla Mudar. JAC (1988). Articles>Writing>TC>Technical Writing

22.
#13554

Breaking the Rules   (PDF)

In our early writing years, many of us toiled under strict teachers who drilled the rules of English grammar into our collective consciousness. We sweated drops of blood on our pristine paper as we tried to craft perfect sentences for that much-desired 'A.' We prayed that we didn’t leave a word or clause misplaced or dangling for the teacher’s angry red pen to mark. Yet pick up a work of modern fiction, and you might notice that the writer has broken many of the rules that were drummed into our impressionable heads. These days, fiction often resembles the casual style of postmodern poetry, with sentence fragments and punctuation sprinkled about like seasoning. But in technical communication, we can’t be so casual. We must adhere to those rules of grammar our English teachers upheld— at least, for the most part.

Gallagher, Jolie A. Intercom (2002). Articles>Writing>Grammar>Technical Writing

23.
#14710

Can a Manual Entertain?   (PDF)

MacDonald analyzes the success of irreverent software manuals such as the 'For Dummies' and 'Complete Idiot's' series and suggests ways writers of traditional technical manuals can make their own work more enjoyable to read.

MacDonald, Matthew P. Intercom (2001). Articles>Documentation>Writing>Technical Writing

24.
#29378

Classical Rhetoric and Technical Writing   (peer-reviewed)   (members only)

English departments, eager to boost enrollment, may press teachers into duty teaching technical writing courses on short notice and with little preparation.

Lunsford, Andrea A. CCC (1976). Articles>Education>Writing>Technical Writing

25.
#27251

Communicating Bad

Companies place little emphasis on the quality of an engineer's writing. An engineer's writing is usually only for evidence a particular transaction took place, or for proof they did the appropriate research. There is hardly ever any emphasis on the readability or usefulness of the writing. In this article, the author states several reasons for this problem and that development teams must come to understand in order to find a solution.

Brogan, Nate. StickyMinds (2006). Articles>Writing>Technical Writing>Engineering

 
 NEXT PAGE »

There are 17 readers currently online: 0 registered users and 17 guests. Register.Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon