A directory of resources inthe field of technical communication.Editing
151-174 of 382 found. Page 7 of 16.
   
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  NEXT PAGE »

 

151.
#18306

Gathering Together

An index pulls together all the references to a topic that are scattered within a publication. If a reference is omitted, the user may assume that particular sub-topic is not discussed.

Brown, Fred. Allegro Time! (2002). Articles>Indexing>Editing

152.
#15138

Gentle Feedback That Encourages Learning   (PDF)

Offers suggestions on how teachers of technical communication and reviewers of coworkers' documents can offer constructive criticism of others' writing.

Doumont, Jean-Luc. Intercom (2002). Articles>Editing

153.
#19779

Get Smart: Interface Design and Production Meet Editorial on a New CD-ROM Magazine   (PDF)

Creating a new magazine is a large task. Creating a new magazine on CD-ROM can be a huge task. All of the design and layout decisions which are part of any project are magnified in an electronic project. Writers and editors have to learn to write “for the screen, ” illustrations have to fit the size, graphics format and palette determined by the display program, every reference, sequence and link has to be checked online, and the whole thing has to run on a “real world” 386 machine. GetSmart made the journey, with its premier issue release in July 1995.

Quesenbery, Whitney. STC Proceedings (1996). Design>User Interface>Editing

154.
#10814

Getting Ducks in a Row: The Rules for Displayed Lists

When is a list not a list? When it's not recognized as such by the reader. A good displayed list is the mental equivalent of a line of cheerful ducklings behind their sensible mom on their way to an invigorating dip. A short series of items can often be run smoothly into text, but lists longer than eight lines or so tend to stray in the reader's mind from the preceding thoughts. A run-in list that becomes estranged from its lead-in context is worthless.

Jorgensen, Linda B. Editorial Eye, The (1997). Articles>Editing

155.
#15139

Getting Reviewers to Review   (PDF)

Presents ten humorous suggestions for technical writers on how to persuade reviewers of documentation to do their jobs.

Hart, Geoffrey J.S. Intercom (2000). Articles>Editing>Collaboration

156.
#20075

Getting Your Style Guide Written!   (PDF)

This paper describes how to approach the project of writing a stand-alone Style Guide that provides technical writers and other employees with a reference for documentation procedures and policies. A Style Guide project is often placed aside while other priority projects forge ahead. This occurs for several reasons, the most common being that writing a Style Guide is a monumental task! This paper provides you with the skeleton to manage a Style Guide writing project and deliver the product on time

Taylor-Collins, Pamela. STC Proceedings (1995). Articles>Style Guides>Editing

157.
#22691

Grammar Stammer

Don't you think that it is a tragedy that 95 percent of the people who desire to be technical writers have a poor command over the language? I am sure all of us make a mistake or two, once in a while. But to make it in every sentence and paragraph shows utter disrespect for readers.

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

158.
#29778

Graphic File Transformations   (PDF)

This paper examines raster and vector file formats and explains the details necessary to transform them for use in various output devices. Methodologies and suggestions for raster-to-vector, vector-to-raster, resampling of raster, 3-dimensional vector to 2-dimensional vector, and 2-dimensional vector to 2-dimensional vector conversions are discussed.

Porter, Sara J. STC Proceedings (2004). Design>Graphic Design>Image Editing

159.
#10815

The Great Hyphenation Hoax

I want to discuss one particular aspect of Chicago's hyphenation advice, which seems questionable at the outset and is so often abused in practice that I think it needs a good thrashing. This is the notion that a compound adjective should be hyphenated when it immediately precedes a noun, and left open when it follows the noun, for example in the predicate. Chicago's example is fast sailing ship, which is ambiguous because it might mean a sailing ship that is fast or a ship that is sailing fast. Hence, to resolve the ambiguity, you hyphenate fast-sailing if you mean to say it is a ship that is sailing fast. But the hyphen is not necessary except when the phrase immediately precedes ship, because the phrase is not ambiguous elsewhere.

Tadfor, Tom Little. Telp.com (1996). Articles>Editing

160.
#19933

Green Squiggly Lines: Evaluating Student Writing in Computer-Mediated Environments  (link broken)

We have a theory, a trace, a prediction of what will happen in the influence that word processors have had on student writing. By outlining a history of word processors in writing pedagogy and assessment (a vast increase in studies of and pedagogies advocating revision occurred in the 1980s), 'Green Squiglly Lines' sketches the potential impact of electronic portfolios on writing assessment. How will the publication--the turning of academic essays into (pre)professional documents [literally portfolios in the graphic artist sense of the word]--change writing assessment in American higher education?

Whithaus, Carl. Academic.Writing (2003). Articles>Editing>Online>Word Processing

161.
#14134

Guidelines for Technical Edits   (PDF)

The purpose of the technical edit is to ensure that all materials produced by the Documentation department are as complete and technically accurate as possible. Each document will also pass through a peer edit by a member of the Documentation department after the technical edit is complete, so as a technical editor you do not need to be concerned with issues of style and grammar. Your main focus should be on the technical accuracy of the document. The first step, of course, is simply to check the document for any errors. We need to make sure w have correctly described each feature of the software, as well as the overall design and purpose of the forms and systems we are discussing. Beyond checking for errors, however, we want the documentation we produce to be as helpful to the user as possible. For the purposes of the technical edit, this means not only checking for inaccuracies, but asking whether the document has all the information that is necessary to use the software successfully.

TECHWR-L (2000). Articles>Editing>TC

162.
#29318

Harnessing the Power of PNGs

Compared to GIF and JPEG, the PNG file format has a lot to offer: smaller file sizes, higher quality, and superb transparency. All you need are a few guidelines and techniques to expand your design toolbox.

Sawyer McFarland, Dave. Creative Pro (2007). Design>Graphic Design>Image Editing>Standards

163.
#15140

Help Stamp Out Hype   (PDF)

Offers tips on eliminating hype from editorial copy.

Eyman, Carol L. Intercom (2001). Articles>Editing

164.
#22127

Hints for Developing a Table of Contents

Planning a project before beginning the detailed work is one of the vital steps to success in technical communication. Developing a table of contents is one of the steps in the planning process of a document.

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

165.
#30818

Hockey Sticks and User Assistance: Writing in Times of Resource Constraints

If you have all the resources you need, do the very best job you can in all respects. But if your resources are tight, ask yourself whether you are writing the essential stuff at a level of quality users will notice. Also, ask whether the value of the documentation you are producing aligns with the economic pressures on your company.

Hughes, Michael A. UXmatters (2008). Articles>Writing>Technical Editing

166.
#24058

How Careful Should Editors Be?

Three recent incidents prompt me to ask, How careful do editors have to be in checking facts? Is it possible for publications people to be too careful?

Taylor, Priscilla S. Editorial Eye, The (1996). Articles>Editing

167.
#24063

How Do Editors Do It?

Do you ever feel you'd like a second opinion on a particularly miserable paragraph you've been editing?

Editorial Eye, The (1996). Articles>Editing

168.
#20810

How Do You Handle Letters to the Editor?

Letters to the editor can be a headache. Many editors play fast and loose with them, often under orders. Among the worst and most common offenses are choosing letters to bolster a policy and having staff members write letters under other names to influence or misrepresent readers' views.

Writing that Works (2003). Articles>Editing>Business Communication

169.
#13461

How Much Technical Knowledge Do Editors Need? The Authors’ Perspective   (PDF)

Technical communication professionals and educators often discuss how much technical training editors need to effectively perform their job: however, their authors’ opinions are seldom considered. Thus, I designed a survey to gauge the authors’ perceptions of how much technical knowledge editors need and how this technical knowledge affects the editorial process. The survey results indicate that most authors think technical editors should have some technical background, but this background does not have to be in any particular subject. In addition, most authors believe that this technical background improves the editorial process.

Roper, Donna G. STC Proceedings (1993). Presentations>Editing

170.
#14831

How Papers Can Find and Retain Copy Editors

The American Copy Editors Society wondered what papers were doing to address this problem, whether editors felt that the academic community should do more to feed the pipeline, and what the industry was doing to encourage people to enter the field. The study was administered by copy editor Carrie Camillo of the Star Tribune in Minneapolis. With the support of her paper and its editor, Tim McGuire, she produced a 33-page report that is the most comprehensive work available on the subject. This column is taken from Camillo’s report.

Glamann, Hank. ACES (2000). Careers>Editing>Journalism

171.
#19700

How to Conduct a Review Meeting   (PDF)

Although technical reviews of many draft user’s guides, references, and help systems occur through the black box (that is, the author sends out the material, and reviewers send it back marked up, without the two ever seeing one another), many technical communicators find that a personal meeting ultimately saves time and improves communication in the process of developing a technical communication product.

Carliner, Saul. Intercom (2003). Careers>Management>Editing

172.
#30528

How to Cool a Hot Photo   (PDF)

When your photo can't be changed, surround it with a cool color.

Before and After (2005). Design>Graphic Design>Image Editing

173.
#19673

How to Edit for Content   (PDF)

Editing involves more than just formatting and inserting page numbers. You need to ask, 'How can I improve the communication?'

Bush, Donald W. Intercom (2003). Articles>Editing>Writing>Technical Writing

174.
#10816

How to Proofread and Edit Your Writing

Proofreading is a pain. There's no doubt about it. It can be tedious and boring--if you approach it as correcting errors. But proofreading isn't correcting errors so much as it involves reviewing the paper for ideas and for readability. It allows you to read your draft, to consider what you've written, and to change your mind. It's an opportunity to clarify--for yourself as well as for your reader--what you've said and to make some choices. Proofreading is in your control, no one else's. No one, really, can proofread for you because the kinds of changes that come form proofreading are changes in your meaning, your intent, and your purpose in the draft. But while no one can proofread for you, others, a classmate, or a writing assistant at the Writing Resource Center, can help you proofread; they can help you assess the draft, propose some alternative solutions, and make some choices. So, while proofreading can be tedious, it doesn't have to be lonely.

Morgan, M.C. Bemidji State University (1997). Articles>Editing

175.
#24894

How to Think (and Act) Like an Editor: Training for Editors   (PDF)

In this workshop, participants will experience portions of a performance-based training program for technical editors. The program emphasizes the skills that STC Fellow Lola Zook calls 'learning not only what the editor is to do, but what the editor ought to be.'

Ecker, Pamela S. STC Proceedings (1995). Articles>Editing



 
« PREVIOUS PAGE  |  NEXT PAGE »

 

Copyright © 2001-08 by the EServer. All rights reserved.Add a Work | Site Preferences | Discussion Forum | Habitués  

There are 5 readers currently online: 0 registered users and 5 guests. Register.RSS feedClick here to learn how to embed the RSS feed of this category in your website.