A directory of resources inthe field of technical communication.

Documentation

576-599 of 1,526 found. Page 24 of 62.

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 »

Extreme documentation is an agile methodology for developing documentation in small to medium-sized teams in the face of vague or rapidly changing requirements.

 

576.
#35546

How Poor In-House User Documents Cost You Twice

Many organizations produce in-house tools or modify commercially-available tools for their own use. These tools should get documented so they are of use to others in the organization. If this documentation is not created or is poorly written, it costs you twice.

Millman, Barry. Technical Writer Blog, The (2009). Articles>Documentation>Technical Writing>Business Case

577.
#19126

How the Process and Organization Can Help or Hinder Adding Value   (peer-reviewed)   (members only)

Do better information products result when technical communicators are well integrated into product development teams?

Pieratti, Denise D. Technical Communication Online (1995). Design>Documentation>Information Design>Usability

578.
#20336

How to Approach a Systems and Programming Documentation Project   (PDF)

The biggest concern in software development environments is the retention of programmers. What they are really concerned about is the knowledge drain. These organizations know they need to capture this knowledge, but they do not want to do it themselves. They are turning to the writers who have always written the user manuals. These writers, most having no systems or programming background, must develop internal documentation for use in a programming maintenance environment. They do not know where to begin. This paper outlines a methodology for developing systems and programming documentation for programmers in a maintenance environment.

Glick-Smith, Judith L. 'Judy'. STC Proceedings (1998). Articles>Documentation>Programming

579.
#34587

How to Avoid Extinction as a Technical Communicator

Although there will always be a need for people to explain technical material non-technical people, Ellis Pratt said, others may be doing it instead, through the formats users prefer. To survive, technical writers may need to morph into content strategists, managing the information in a systematic way rather than merely creating it.

Johnson, Tom H. I'd Rather Be Writing (2009). Articles>Documentation>Multimedia>User Centered Design

580.
#36011

How to Bring Web 2.0 to User Assistance (and Vice-Versa)

In Conversation and Community: The Social Web for Documentation, Anne Gentle offers tips for mashing up user-generated content with user assistance, including ways to bring Web 2.0 to user assistance, and vice-versa.

Mulligan, Peg. PegMulligan.com (2009). Resources>Documentation>Web Design>Help

581.
#34863

How to Capture the Essence of a Topic

Capturing the essence of a topic is the heart and soul of good writing and editing. If you cannot tell what the main idea is, you cannot write it either. And if you cannot write it, how would you expect your readers to get it? So it all starts with you. Thankfully, it is not mysterious process. Here are two techniques that you can use to weed out the irrelevant details from your core idea.

Technical Communication Center (2009). Articles>Documentation>Technical Writing

582.
#26112

How to Choose a Good Instructional Book about OpenOffice.org

If the success of an open source project can be measured by the number of third-party books about it, then OpenOffice.org is thriving. Not only is OpenOffice.org represented by a dozen books and pieces of training material on Amazon.com, but interest in OpenOffice.org is widespread enough that each of the books is geared to a slightly different audience. This article gives an overview of four of the current OpenOffice.org books, ending with a suggestion of which to buy for your own needs.

Byfield, Bruce. IT Manager's Journal (2004). Articles>Documentation>Software>OpenOffice

583.
#34023

How to Comply With Moral and Ethical Standards in Technical Documentation

Technical writing has a number of moral and ethical standards that a professional technical writer needs to comply with. Violate them at your own peril, by risking the sudden demise of your career. Here are some of these issues.

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

584.
#30808

How to Convince Others of the Importance of Documentation

If you've been a technical writer for long, chances are you've had to convince someone of the importance of documentation. It just comes with the territory. People often don't see the value of writing technical manuals. So how do you convince them?

HelpScribe (2008). Articles>Documentation>Collaboration

585.
#39074

How to Create a Help API

In this post, I want to explore Help APIs, which is actually something in part enabled by static site generators. To put things in context, the web is sort of a giant API. Each browser functions as a client that accesses various resources from servers.

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

586.
#38850

How to Create Flexible Image Grids in Adobe InDesign

In this tutorial we will learn how to create flexible image grid layouts in Adobe InDesign. We will use several useful image frame techniques like Fill frame options, Auto-Fill, Gap Tool, Rounded Corners, etc.

Perhiniak, Martin. Vectortuts (2013). Articles>Documentation>Document Design>Adobe InDesign

587.
#31894

How to Create User-Centered Documentation, Interview with Joe Sokohl

In this podcast, Joe Sokohl explains how to create user-centered documentation by contacting, observing, and interviewing users to gather information about what types of information they use and the help deliverables they actually want.

Sokohl, Joe and Tom H. Johnson. Tech Writer Voices (2008). Articles>Interviews>Documentation>User Centered Design

588.
#15141

How to Get a Good Job   (PDF)

Suggests ways to get a good job by cutting production time and cost on user manuals while increasing access and usability.

Bush, Donald W. Intercom (2000). Careers>Documentation>TC

589.
#34446

How to Improve the UI--Really!

A colleague has made me realize that user assistance writers are codependents of bad UI design. Because we explain how the UI really works, we somehow leave our developers and companies feeling like they're "covered" when the users have a bad experience.

Hughes, Michael A. User Assistance (2009). Articles>User Interface>Documentation>Technical Writing

590.
#32221

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. TechCom Manager (2004). Articles>Management>Documentation>Marketing

591.
#30314

How to Plan On-line and Paper Versions of a Software Manual

On projects for which you must produce both on-line and paper documentation, there are many things you should consider before you start.

Kozuma, Bruce. Boston Broadside (1991). Articles>Documentation>Project Management>Planning

592.
#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

593.
#19752

How to Publish a Great User Manual

When was the last time you curled up in bed with a really good user-manual just for the sheer joy of reading it? Never? Think that is some immutable law of nature, like the one that dictates all textbooks must be dull as dirt? 'Tain't so, McGee.

Tognazzini, Bruce. Nielsen Norman Group (1998). Articles>Documentation

594.
#19501

How to Stop Writing Documentation and Start Working for Your Users   (PDF)

How do you stop writing documentation and instead give people the information they need to use a product? You start by understanding your users: their level of expertise, the tasks they need to accomplish, and the problems they are likely to run into. Then you can help them do their work by presenting the information from their point of view and focusing on real tasks, rather than product functions. With this background, you can develop information that is easy to understand, easy to find, and visually effective.

Bergen, Karen A. STC Proceedings (2001). Articles>Documentation>User Centered Design

595.
#11754

How to Thaw a Turkey

I open my usability presentations with this true story: I was given a large, frozen turkey a few years ago. When it came time to prepare the turkey, I placed it on a kitchen counter to let the turkey thaw.

Thomas, Joyce. Usability Interface (2001). Humor>Documentation

596.
#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

597.
#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

598.
#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

599.
#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

600.
#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

 
« PREVIOUS PAGE  |  NEXT PAGE »

 

Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon