Articles>Documentation>Writing

Five Skills for Managing Documentation Projects in an Agile Environment

Sometimes, the Agile software development methodology seems like it could be renamed the “Fly by the Seat of Your Pants” methodology. But really, it means that you need a somewhat different set of project management skills for your documentation. I could certainly improve in these skills, but here are a few I rely on in an Agile environment.

Quick Reference Guides Are More Useful Than a 150-Page User Doc

I’m working on a project to boil a 150-page software user document down to a one-page reference guide that can be tacked to a CSR’s cube wall. Our goal with the one-page reference guide is to give the CSR a description of all the navigation elements and application functionality so they can quickly navigate to where they want to go without first having to trudge through the complete 150-page user doc.

Writing Great Documentation: What to Write

Tech docs can take a bunch of different forms ranging from high-level overviews, to step-by-step walkthroughs, to auto-generated API documentation. Unfortunately, no single format works for all users; there’s huge differences in the way that people learn, so a well-documented project needs to provide many different forms of documentation.

Writing Great Documentation: Technical Style

Now that I’ve discussed what kinds of technical documentation to write, I can move on to the question of how to actually develop a writing style that produces great technical documentation. So how do you learn to write (anything) well? There’s only one answer: you’ll learn to write well if you write. A lot.

Writing Great Documentation: You Need an Editor

All good writers have a dirty little secret: they’re not really that good at writing. Their editors just make it seem that way. It doesn’t matter how well you’ve mastered the language; nobody, even grammar geeks, gets this stuff right on the first pass. If you really want to produce great documentation, it needs to be edited.

Quick-Start Guides Require a Minimalist Mindset

The point of a quick-start guide is, as the name says, to help the users get on their feet as fast as possible. This requires the writer to ask, “What is the absolute minimum that someone needs in order to get started?” The next best question is “What is the user going to do the most often?”

Minimal Procedure Content: Reasoning

The procedure I wrote about creating a Twitter list uses abbreviated content. This post describes the reasoning behind and decisions made in writing the topic.

Coffee and Documentation

I like the concept of not treating the readers of documentation like idiots. This little card gave me the information that I needed and couldn’t know ahead of time (how much water to use, the filter looks too big but is the right size, only push the button once) without wasting my time by giving me information that I either already knew or could easily guess (I can get water from the sink, I need to use a cup). Can we use this concept in software documentation? What parts can safely be left out so that we are only highlighting the pieces that are really needed?

Minimizing Documentation

Is less always more? I’m not sure. But if Apple’s minimalistic designs are any indicator of trends, minimalism in documentation is something to pay attention to. Here are five ideas for minimizing documentation.

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.

Sometimes, You’ve Got to Break the Rules

In a case like this, you don’t need documentation made up of perfectly-chosen words and phrases. Instead, you need something that can be easily scanned, easily understood, and easily digested. Documentation that distills the main points quickly. Far more quickly than even the kind of minimalist documentation that I encourage can.

The Doc Whisperer

Doc whisperers are more commonly known as "senior technical writers", but what's in a name anyway? So if you want to be a great tech writer—start whispering.

Change Your Writing Style to Make Documentation More Usable and User-Friendly

When the subjects of usability and user friendliness in relation to documentation are broached, writing isn’t often the first thing that comes to mind. But it should be.

Technical Communications as a Profit Center

Those within technical communications have long argued that product documentation provides significant value in terms of a customer satisfaction and downstream savings in customer support and service. In the broader, enterprise perspective, however, documentation is generally viewed as simply one of many requirements for product launch. This perspective is often the result of the lack of visibility that is generally available into the business value contributed by product documentation. Aberdeen investigated and isolated the quantifiable business impact of technical communications makes for 165 participating companies. An analysis of this data indicates that when leveraged effectively, technical communications stands to contribute as much as a 42% increase in customer satisfaction and an associated 45% increase in product revenue. This report provides a quantified framework for understanding the potential impact on technical communications makes for business profitability as well as the best practices to adopt to drive greater value from this organization.

Seven Steps to Clear Technical Writing

These points are not meant to be all-inclusive. However, if you are new to tech writing, this should put you on the right road.

Sometimes, Simple is the Way to Go

I’m advocating boiling the documentation down to the essentials. Remove any superfluous material. Tell the user how to do things with a piece of software or a gadget, not what that something can do. You might wind up with documentation that’s just a set of procedures connected together by linking material and cross references. Don’t bog them down with what’s not necessary for them to get things done in a fast and efficient way.

The Missing Manual Authors’ Guide

This Authors’ Guide tells you everything you need to know to write Missing Manual. It starts out by giving you a brief introduction to the Missing Manual way of explaining things and then takes you through the nitty gritty of style guidelines, figure formatting, and so on.

Why Technical Writers Shouldn't Be "Writers"

Technical writers love the written word. Perhaps, we love it a little too much? We need to ask ourselves is the written word the best thing for documentation? Is it the best thing for us as an industry, and is it the best thing for you as a content developer.

Change is Gonna Come

There's a shift happening in the way in which documentation is produced. We’ve all seen the beginning of it: the growing volume of what’s called (among other things) user generated or crowdsourced documentation. That trend is growing. And while a number of people in our profession are still resistant to the idea, it’s only a matter of time before users are our main partners in creating documentation.

Textual Grounding: How People Turn Texts into Tools

The author argues that users see texts as tools when they recognize the texts' specific value and function within highly localized use settings. The author argues that users "ground" their texts to local use settings by altering the ways in which the texts structure and represent information (e.g., underlining, annotation, and sketching). The author discusses three practices by which texts are grounded as tools in document reviews: mode shifting, layering, and marking. These practices reflect different ways by which users add, subtract, and restructure information in a text so that it is usable under very specific conditions. This article explores document review as a practice in which grounding is the object of discussion (how others use the reviewed documents) and a practice by which review is facilitated. These observations will be important for exploration of technology to support "grounding" practices.

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.

Cut, Cut, Cut your Content and Procedures

Sure. We’ve been reducing word count in procedures for some time. It’s time to do more, however. As noted in an earlier post, we have to think mobile. Think small screens and small devices. Screen real estate will be at a premium.

What’s the Point of User Documentation, from a Marketing Perspective?

In order to understand the way marketing people see the world, it’s worth reading Blogs on marketing (by people such as Seth Godin), the Cluetrain Manifesto, and reading a few books on marketing.

Authoring Tools Do Matter

The authoring tool does matter. Writers are focusing on the wrong set of issues (leading, kerning, print formatting), none of which is actually relevant for the output.

A Mile Wide and 30 Seconds Deep: A Metaphor for Help from Mike Hughes

Help needs to be a mile wide—it must cover everything—and 30 seconds deep—tackling only small amounts of detail at any given point.

Writing Technically: Bad Docs Rarely Mean Bad Sales

Technical writing is a cost activity, not a revenue or a profit activity.

Let's Reinvent Technical Writing

More and more, I think it’s time to discard main approaches to tech writing and come up with new methodologies. The world and technology is changing so much that I think it’s time to start fresh. Just as sometimes when you’re working on a sentence and you tweak it and change it, but it’s still not quite right, and you finally just drop it and come up with something different. Perhaps it’s time to drop existing methodologies and develop something new instead of trying to tweak what’s there to fit what’s happening now. Perhaps the old methods no longer work.

Documentation for Consumer Products: Give it a Chance

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.

Writing User Manuals

Writing user manuals isn't so difficult if you start with a clear understanding of the structure of such documents. This post will provide you with some guidelines for producing a great manual, and links to templates to help you get started.

Reveal Bugs in Release Notes, Not User Guides

Really, I think documenting the software the way it works with bugs is making more work for myself, so that’s probably the main reason I avoid it. I’ve got enough to do without changing the doucmentation whenever a bug is fixed. Release notes are easier—a much smaller deliverable whose focus is what’s changed and what’s still not quite right.

Identity and Authority. Why the Foundation of Documentation is Changing

There is most definitely a technical communicator identity crisis underway. Three posts from well respected industry professionals in the span of one month, all dealing with a fundamental shift in an core product development profession. What’s going on here? To put it plainly: documentation now has competition.

Twitter as a Medium for Release Notes

I’m going to start with a short introduction to Twitter, mentioning particularly the aspects that I found useful when tweeting release notes. If you’re already a twitterologist, you may want to skip that bit. Then I’ll describe how we’ve used Twitter as a method of communicating the highlights of our release notes.

Finding Information in Documentation

Finding information in documentation is easy. Or is it? This blog post argues that there's no universal solution, and that each document and each delivery method offers challenges and requires a slightly different solution.

Dividing It Up, With Any Crowd

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.

Is Help Necessary?

Do we need to have an external help system? Why not embed help right into the application? Why not take this a step or two further? Instead of having a separate help system, integrate more useful, more robust, and context-sensitive help into the user interface.

Form and Function

A musing on the need to balance documenation that looks good with documentation that has substance.

Does Your Documentation Suck?

I’ve been browsing a lot of online documentation lately and in a past life I spent an enormous amount of time worrying about how my users were interacting with documentation. It never ceases to amaze me how bad most product documentation is, especially when the documentation is published in a half-measured attempt on the web. Do companies not realize the negative effect poor documentation, both content and presentation, have on their users?

Creating Topics: Where do you Draw the Line?

It's hard to look at a page of text and try to decide where to divide things to create individual topics. That "bottom up" approach is kind of pointless, in fact. There are better ways.

Docs Aren't Code

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.

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.

The Many Faces of Content Management: A Primer

None of the technologies mentioned so far support the production of content for purposes of producing technical documentation. Such a system is a specific type of content management that has specialized functions for technical communicators doing multi-channel publishing, yet it hasn't spun off its own specific acronym.

What Technical Communicators Can Learn from Comics

Citing the rise of graphic novels, comics, and in particular, Google’s new web browser Chrome, which has a comic-book-style manual, Opsteegh argues that technical communicators can learn a thing or two about conveying information from graphic novelists.

User Paradox with Not Reading User Manuals

Users would save time by reading the manual, but instead they try to figure the application out themselves and then get lost/frustrated as they end up spending even more time getting up to speed with the application.

Quick Reference Guides: Short and Sweet Technical Documentation

Users often want documentation in a format that will give them the basics and get them on their way as fast as possible. Quick reference guides provide a short version of a manual, condensed from dozens or hundreds of pages down to just one double-sided sheet of paper. Despite the brevity of quick reference material, the thought process involved in creating, organizing, and laying out the content is time consuming. The format requires you to assess the content and decide the most important information the user needs to know. You must describe with extreme concision and clarity processes that usually require dozens of pages to explain. This article provides an overview of the strategies, tips, challenges, and benefits we have learned in using quick reference guides for our documentation projects.

“Good Enough” Really Isn’t

I’m enough of a perfectionist that I mentally wince every time I find myself thinking, “It’s good enough.” It sounds like a cop-out. It sounds like avoidance of responsibility and ownership. It sounds like I’m indifferent.

The Matter of Dark Text

Dark text refers to the many layers of hidden meaning in any text segment. It ranges from the implied meaning that the author intended, or that the reader infers, to much deeper, more hidden meanings. As technical writers, we must be aware of dark text, and where possible, try to minimize it.

What Should You Include in Your User Documentation?

Technical authors are faced with limited time and resources, so they often are faced with the dilemma as to what to include and what to leave out of their user documentation. You may ask, if 80% read only 20% of the content, is there any value in documenting the rest?

Quick Reference Guides: Short and Sweet Documentation

In this article, my colleague and I provide strategies, tips, and approaches we’ve learned in creating quick reference guides for software documentation projects.

Where Did All the Documentation Go?

Documentation is a huge cost factor in software development, and companies are looking for ways to trim costs. If you cut back on product doc and customers don't complain, there's a temptation to keep cutting. Eventually you end up with software engineers writing bits of doc because all the tech writers were laid off, but there'll be one guy who didn't get laid off who has to work like heck to wire it all up and make it continue to look like professionally written doc.

Structured Authoring for Everyone

While the concepts of structured authoring are more than just slightly useful for technical writing, they can be beneficial for just about any writing task within an organization. But how do you bring XML-based structured authoring to the masses? Perhaps by taking a cue from a word processor called Yeah Write.

Advantages of Using Microsoft SourceSafe While Writing Your Technical Documents

Microsoft’s Visual SourceSafe was not created with technical communicators in mind. It was created for engineers writing software source code. But it is successfully used by technical writers in offices around the world to control documentation.

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.

Ten Commandments of Storytelling as Applied to Technical Documentation?

Anyone who reads this blog will know that I’m a strong advocate of storytelling in all forms of communications. I believe that it applies as much to technical or marketing communication as it does to your favorite novel or movie. This article applies McKee’s 10 Commandments to Technical Documentation.

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.

Wurman’s LATCH Model of Information Organization For Technical Documentation

Technical writing has its mechanical aspects that need to be mastered. A good technical writer must know how to use English effectively as well as various software products to produce acceptable technical documents. But I wish technical writing were all about that. The hardest part comes before one even sits down in front of a computer to type the first word. The hardest part in documenting anything is organizing the information in a way that makes sense from the user’s point of view. Otherwise a technical document suddenly looks irrelevant.

Emotional States of Computer Users in Times of Frustration

If there’s one undeniable characteristic of the frustrated computer user, it’s that her patience is gone. She will not be slowly flipping through the user manual. Notice her jerky movements. If she turns to the help (which she doesn’t here), she’ll search for keywords, skim rapidly, click quickly from topic to topic. As we write for users in this state of mind, we have to remember the hurry.

FLOSS Manuals Sprints to Build Quality Free Documentation

Documentation is one area in which free/libre/open source software (FLOSS) is weakest. A project called FLOSS Manuals is trying to remedy this situation. The idea behind project is to create quality, free documentation for free software.

Writing Technical Documentation with Sphinx, Paver, and Cog

I've been working on the Python Module of the Week series since March of 2007. During the course of the project, my article style and tool chain have both evolved. I now have a fairly smooth production process in place, so the mechanics of producing a new post don't get in the way of the actual research and writing. Most of the tools are open source, so I thought I would describe the process I go through and how the tools work together.

How Color Defines Purpose in User Assistance Content

Of all the visual cues in your help interface, color is one of the strongest. Users will recognize and react to the color of each element in your help window before reading a single word of text. Color allows users to determine the purpose of each element on the computer screen. When designing the visual aspect of your help content (via CSS and so on), as well as the help interface itself, be sure to use the same color for objects that share a purpose.

Why Wikis Won't Kill Technical Writing

Many people have predicted that wikis will replace traditional help in the future. Ok, I can buy that. But I've also heard that technical writers will surrender content control to SMEs and users, and will move into other roles such as merely editing wiki content, or switching to programming, training. Sorry. I just can't see that happening. In the world of wikis, technical writers will still be kings of content.

Giving the Instructions a Fair Shot

We as technical communicators ought to afford each other the courtesy of using each other’s materials when the need arises. As the writers, we know how valuable it can be, and if we don’t use it when the need arises, we’re contributing to the prevalent concept that “no one reads it anyway.” By doing so, we shoot our own profession in the foot.

The Sacred Cow Blocking the Road

When product teams ask technical writers to document software products, writers usually start their projects by analyzing the tasks users will perform when working with them. A task analysis generates a list of procedures—plus the supporting information users need to follow them—and eventually results in a document in which sequentially numbered instructions are the dominant type of information—neatly organized under user-centered task headings and preceded by enabling knowledge. It sounds ideal, classical even. The problem? Users don’t read procedures.

Placing Value on User Assistance

User assistance writers are often the Rodney Dangerfields of the UX world, bemoaning the fact that we don’t get any respect. I think the real problem is that user assistance folks are not particularly good at communicating the ways in which we add value to an enterprise. This column explores two models that show how user assistance adds value and how we can communicate that value to those who pay our salaries—something I would like to encourage other user assistance writers to do.

Error Message Guidelines

An error message is text that is displayed to describe a problem that has occurred that is preventing the user or the system from completing a task. The problem could result in data corruption or loss. Other message types include confirmations, warnings, and notifications. The guidelines in this topic are intended to help you write clear error messages that are easy to localize and useful for customers.

Help for Help files

Normally I like to write positive stuff and I really love Uxmatters.. it’s a great site. BUT, the recent article PDF Manuals: The Wrong Paradigm for an Online Experience from my perspective is pretty much everything that’s wrong with Help today.

Will Write for Metamucil

I am ill equipped to write for an emerging segment of the marketplace. But that doesn't mean I'm used up like a worn-out number two pencil stub (my favorite simile these days). But it does mean that I need to reevaluate where and how I add value.

Glossaries Aid Clarity

A glossary is an alphabetically arranged list of terms, with a definition or an explanation of each term. A term can be a single word or many words. Typically, in a printed document, the glossary is at the end of the document. Usually, in online help, each term in a topic, or the first instance of a term, has a popup that explains the term.

Writing for an International Audience

Ideally, software and its documentation is localised (translated) into the languages of the target markets. However, in many cases, it is not cost-effective do this. Even if the target markets are the English-speaking countries, differences exist between the way English is used in the US, the UK, and Australia for example, and it is easy to cause confusion. This article examines some issues.

How to Write Good FAQs

FAQs don’t have that great a reputation, but recently, I’ve been working on FAQs for a client. Their computer help desk was annoyed about answering the same things again and again. Why not divert potential callers to a FAQ instead?

'Read Rage' Over Instruction Books

"Read rage" is sweeping the UK - as consumers become fed up with the often incomprehensible language used in many of the instruction manuals produced by manufacturers.

Don't Let Your Product's Features Become Expensive Flaws

Your product's unexplained features can turn into costly flaws. This article describes three real-world products with just such "features." It presents ways you can prevent these feature-to-flaw conversions by improving the User Documentation for your products.

Has Anyone Used Your Product

Before you release a product, have some people use it. From these "test users" get solutions to problems, tips and knowledge that would help your real-life Users. Put that information in your User Documentation, and on your product support website.

Building a DITA-Wiki Hybrid

Learn about theoretical and practical examples of merging DITA (Darwin Information Typing Architecture), a structured authoring methodology, and wiki’s freeform authoring and editing capabilities.

The "Quick Web" for Technical Documentation

So how did the wiki become a seemingly permanent fixture in the landscape of today’s Web? Which wikis have succeeded as technical documentation, and how can we replicate their success?

Placing Value on User Assistance

Writing with Authority

Technical writers write with authority. That’s the job: to present the subject with authority, so the reader will feel confident about the accuracy of the information or confident about using the software. There’s no place for hedging. You write, ‘Press the OK button’. You don’t write, ‘Press the OK button – I think.'

Collaborative Walkthrough Video

Collaborative walkthroughs are a technique that my team used while rewriting our Help and adopting DITA. We believe that we were able to improve the user experience by improving the collaborative experience.

Driving Development

By partly adopting the process suggested by Daniel Brolund we, the technical writing team, can be involved right up front and the documentation can be one of the methods used to validate the software as it is being built.

A Curmudgeon's Guide to Computer Documentation

Is documentation a bad word? It is if you’re the Curmudgeon, a character I invented, who some say bears an amazing resemblance to … me.

Why Manuals Fail

A very brief review of the first edition of Edmond H. Weiss’s How to Write a Usable User Manual.

Editing Modular Documentation: Some Best Practices

Much has been said about the creation of modular documentation - from content management systems, to information architecture, to delivery forms, to the usability of modular content (content being easier to use, easier to understand, and easier to find), and so on. However, not much has been said about the editing of that content, and what the editor's role is in such an environment.

Technical Support According to Dilbert

Help desks often follow written scripts based on how an application should work, but what if the user is faced with something out of the ordinary, and it’s something not written in the script? Software might not always behave as it’s supposed to; did a technical writer somewhere have to form a logical conclusion that might not have been correct?

What's a Topic?

Back in 1998, I defined topics as "'chunks' of information in a Help file that answer one question or provide focused, specific content." Ten years later, I typically use the same definition. However, there have been some changes in how those "chunks" are developed.

The Hidden Power of the Online Manual

Writing software manuals is boring, isn't it? We often think, "My software is easy to use. The user interface is intuitive. Why should I waste so much time writing documentation which nobody will read anyway?" Sometimes it's true. I've never read the WinZip or Internet Explorer manuals. Everything seems clear enough without further explanation. Nevertheless, even if your manual isn't being helpful to your software users, it may be helpful to you. Publish your manual online and turn its hidden power into a real benefit for your business.

Writing Cost-Effective Documentation for Software Systems

There are many situations when you have an application but there is no help file with it, and you have no time to write complete documentation yourself. At the same time you have no budget to hire a professional technical writer who can do this tedious work for you. Let's consider the most common of such situations.

Excel Hacks for Help Writers

One of my earlier careers was in manufacturing management, and it grounded me in the principles of project planning and management. When I moved into technical communication, I brought my project management disciplines with me, and I embraced the prevailing tools of my new profession. I dutifully produced documentation plans in Microsoft Word and supported them with detailed project plans in Microsoft Project. However, the problem is that—like bad relationships—these artifacts never gave back results that were sufficient to reward the effort I put into creating them.

Developing Knowledge Base Articles

A short article that offers some tips on writing articles for a knowledge base, whether internal or client facing.

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?

Thinking Outside the (Tech Docs) Box: Structured Authoring as Competitive Advantage

There was a time when technical writing was seen as a cost center—a necessary function, but hardly a key lever for competitive advantage. This is quickly changing as globalization and hyper-competition put customers in control and organizations scramble for new and different ways to strengthen relationships.

Getting to Expert

The gaps in your documentation aren’t there because you haven’t consider a particular level of user; the gaps in your documentation are there because you haven’t considered how one level of user becomes another. How DO you get from Beginner to Expert?

Avoid the SOX (Sarbanes-Oxley) Documentation Nightmare With These Five Tips

The Sarbanes-Oxley Act has been called the most comprehensive reform of corporate law since the Securities Exchange Act was passed in 1934. The effects of SOX are far reaching. Its provisions govern actions by management, audit committees, and boards of directors of public companies. Like it or not, Sarbanes-Oxley is here to stay. Its impact on IT departments is major and growing. The reaction of many IT groups is to document everything in sight in an attempt to cover themselves. In the end, this can be counter-productive, expensive and wasteful.

The First Line of Support

Customer support costs account for as much as 60 percent of a high-tech company’s total costs. Documentation is the first line of support for most customers, and customers usually use documentation to find the answer to a problem they’re having. The inevitable result of poor or nonexistent documentation is that more people try calling the customer support lines for help.

The Why and How of Content Convergence and Integration

Content producers are about to live through interesting times, to adapt the popular saying, with the dawning of The Age of Content. Industry is discovering content as a commodity; the rules are changing, and fast. What have traditionally been seen as the lowliest form of commercial content within an enterprise, technical manuals, are starting to take their place alongside the other valued corporate assets.

User Assistance: Writing for a High-Context Culture

What we consider to be good technical writing often reflects an American cultural perspective. One facet of this cultural orientation is that technical writing tends to use a low-context style. Most notably, we tend to write user assistance as if users have never seen the user interface we are explaining. Secondly, we tend to write user assistance as if users have never even used software before. But users rarely go to Help before they have tried to accomplish a task on their own first, and most users today have extensive experience using software and are familiar with the standard ways of interacting with user interfaces. So a user interface is a high-context artifact—one a user has already seen before reading our documentation and that uses rules and conventions the user already knows.

When Tech Writers Don't Read Directions

Find out what the Unspoken Rule of technical writers is and how to avoid violating it.

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.

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’.

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.

Improving Your Technical Document Writing Skills

Discusses the general technical writing process.

Betriebsanleitungen für Anlagen

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.

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.

Musings on User-Generated Documentation

User-generated documentation is a big issue in technical communication circles. If properly done, tapping into the knowledge of users can improve the quality and breadth of your documentation.

Eleven Tips for Writing Incredibly Useful Procedures

Procedures are the meat and potatoes of technical writing. They help users get the job done. Follow these tips for writing clear and useful procedures that your users will appreciate.

Nine Tips for Writing Better FAQs

Frequently asked questions, or FAQs, are an important part of your product documentation. Writing well-targeted and thorough FAQs allow users to quickly find the answers they need so they can be more productive when using your product. Here are some tips for writing FAQs that will get your users on track quickly and help reduce Customer Support calls.

Why Write Instructions That No One is Going to Read?

I know that a lot of people never read instruction manuals or online help. But you know what? Some people do.

Users' Documentation Preferences

At a user group meeting in 2007, TechScribe researched users' experiences of the software documentation that they receive. Do they prefer online or printed documentation? Do they read the manual, or do they call the help desk? How important is background information? Which is more useful, a 'how to' user guide or a reference manual? Do people prefer explanations using visuals, descriptions, or a combination? Read the survey to find the answers (we obtained 29 responses from 64 attendees).

Is Your Website Poised to Deal With Its Growth?

Every webmaster nourishes the dream that his or her website will make it the big way. This is very much human because people carry out any task in ardent hope. What is more human out here is that earthy fellows like us base our aspirations more on speculation rather than specific set of steps undertaken to bring the dream a bit closer to reality. And this is not all, particularly in case of growth of a site which brings newer problems in the wake of its growth. It cannot be disputed that you can probably get some good web hosting on economy price. But if you expect top of the line service on this price, acknowedge gracefully that your are just asking for the moon. Probably you are not catching up with wisdom that business needs decisive investments.

Implicature, Pragmatics, and Documentation: A Comparative Study

This study investigates the link between the linguistic principles of implicature and pragmatics and software documentation. When implicatures are created in conversation or text, the listener or reader is required to fill in missing information not overtly stated. This information is usually filled in on the basis of previous knowledge or context. Pragmatics, the study of language use in context, is concerned with the situational aspects of language use that, among other things, directly affect implicatures required of the reader. I investigate how two manuals for the same software product can be analyzed on the basis of implicature and pragmatics. One is an original copy of the documentation that came with the product, the other an after-market manual. Results show that the aftermarket manual requires far fewer implicatures of the reader and does a better job of providing pragmatically helpful information for the user.

Reducing Complexity in Documentation

With more emphasis being placed on customer satisfaction, technical writers need to focus on information strategies that will lead to happier customers. The complexity of the information is one common complaint of customers. Writers need to understand what customers think is complex. Then, writers need to develop strategies to combat these complexities.

Early Involvement: Writing at Product Design Time

Lead writing is a process that moves the information development cycle into the product development cycle. Writers and programmers work together from the beginning to produce both code design and supporting information. This process ensures that information developers can actively participate in design, and programmers can contribute to supporting documentation. Both groups gain an appreciation for each other's perspective, expertise, and skills, producing a more customer-oriented product.

Hidden Factors of Documentation Quality -- Part 1

The first impulse of many documenters is to turn our work over to editors and graphic designers, or to form committees and develop style guidelines. All of these measures are useful, but none can assure us of quality when there are basic problems with the way we go about producing documentation.

Let the User Write the Documentation

Teaching non-writers how to write can be challenging, especially when they are adults using new software to do their jobs. But who knows best how to write about their jobs than the end users. Through field experiences and case studies, this paper describes methods and approaches for eflectively including the end user in the documentation process, as well as educating experienced writers who are new to the system.

Writing Procedures Like a Pro: The "How To" of "How To's"

Do you need to brush up on your procedure-writing skills? Or do you need to teach others--like clients or coworkers--these valuable skills? If procedural writing isn't your focus, keeping these skills honed is a challenge. This workshop is designed for communicators at all levels who must--in some fashion--tell people how to do something. During this highly interactive workshop, you'll find out about the differences between process descriptions and procedural writing, some tips for planning procedures, and the secrets of writing techniques for procedures. So bring your thinking cap, and join a couple of seasoned writers/instructors for this fun and informative session!

Technical Writing and Instructional Design Techniques

Technical communicators and instructional designers use similar techniques in producing written documents. This paper discusses how the Perot Systems Instructional Design team creates its documentation in a similar manner as technical communicators. We start by discussing the use of the ADDIE model for developing documentation; 2) explaining how we implement our Word and PowerPoint style guides with a brief mention about our client-driven Training Engagement Methodology; and 3) ensuring copyrights are respected. The subject matter experts that we support as technical communicators and instructional designers sometimes view us as the documentation police because we constantly question the data and quotations.

Documentation Solutions for Complex Tools: Task-Based Design at the Cross Roads

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.

A Process Model For Creating Accessible End-User Documents

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.

Instructions for Giving Instructions: Creating Effective Documentation

Increasingly technical communicators are being asked not only to write documentation and instructions, but to also teach subject matter experts how to write their own process explanations. While writing good documentation is an art, there are also formulas and templates that help guide effective process explanation. Whether instructions appear in written, verbal or digital formats, they should all observe basic conventions for graphics, layout, content organization, overviews, development of ideas, ample warnings and cautions, trouble shooting and tool lists.

The Presentation of Safety Information in Product Manuals

Technical communicators may be asked to design and develop safety information for a product manual. During this process, technical communicators can add value to the presentation of safety information. In addition to adhering to a manufacturer’s internal guideline for the content and formatting of safety information, other factors can be considered as well. This paper presents the following factors: (1) an overview of common failure-to-warn allegations, (2) an analysis of current practices in automotive owner’s manuals for presenting safety information, and (3) an update on a new ANSI Z535 consensus standard for the presentation of safety information in product manuals.

Taking Advantage of Reflexive Responses

None of us likes to admit that we have conditioned reflexes that override our higher cognitive abilities, yet such denials notwithstanding, each of us does occasionally respond without thinking something through clearly. As technical communicators, it's important for us to accept this fact of human nature and plan for it in our documentation, and to work with the developers of the products that we document to both take advantage of the helpful reflexes and find ways to ward off the harmful ones.

Improving the Usability of Programming Publications

This paper summarizes the work of a study group on ways to improve the usability of publications that support programming products. Task orientation, an approach to providing, organizing, and packaging information, is covered, together with innovations to improve the usability of programming publications: ease-of-use education, measurement of user opinion, and incorporating usability into the publications development process.

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".

S1000D: A Standard for Technical Documentation

S1000D is a military standard for the creation and delivery of technical documentation. Many companies can benefit from its methodology. Review its history and principal concepts, and learn important information to keep in mind when applying the standard to your work.

Managing the TWI Mailing List: As Tough as it Gets

The success or failure of any mailing list depends entirely on its members - as in how effectively can they contribute on the list or how diligently can they enhance the quality of ongoing discussions. If you watch closely, the level of discussions combined with the maturity of posters is what characterizes these mailing lists to a large extent. For instance, take a firsthand look at Technical Writers India mailing list or TWI, as it is popularly called.

Meaningful Microcontent

Microcontent refers to small, granular, and possibly representative (that can provide a summary of or a navigation to a larger set of information) bits of information, typically available on the Web. An example in the domain of journalism might be headlines and news summaries, small bits of content that can be used on a front page of the news with links to more in-depth articles. The definition has grown in scope as much as in its application.

Software Documentation

Software documentation or source code documentation is written text that accompanies computer software. It either explains how it operates or how to use it. In fact, the term software documentation means different things to different people. This article describes the term as used by the largest groups of users.

Developing a Web-Based Tutorial in RoboHelp

The very first thing you should do in developing a tutorial is to be familiar enough with the subject matter that you can write the content.

Types of Documentation Needed by Companies

Every business--large or small--needs documentation to operate effectively. Requirements for extensive internal documentation are spelled out in the ISO 9000 series of international standards. The major classifications of needed documents include marketing, user guides, administrative material and published works. Technical communicators are needed to write each of these types of documents.

Creating Professional Documentation with Linux Tools

While Linux lacks standard Windows tools such as FrameMaker, RoboHelp, and WebWorks Publisher, it's still a viable environment for technical writers. Linux users can take advantage of a number of documentation tools, including both free or open source software (FOSS) and proprietary software. All of them give technical writers the ability to author and publish professional documentation.