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.

Gryphon Mountain (2008). Articles>Documentation>Technical Writing

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.

HelpScribe (2008). Articles>Documentation>Technical Writing>Wikis

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.

Haiss, Craig. HelpScribe (2009). Articles>Documentation>Technical Writing>Color

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.

Hellmann, Doug. O'Reilly and Associates (2009). Articles>Documentation>Software>Technical Writing

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.

Nesbitt, Scott. Linux.com (2008). Articles>Documentation>Open Source>Writing

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.

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

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.

Porter, Alan J. Content Pool, The (2009). Articles>Documentation>Technical Writing

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

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.

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

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.

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

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

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.

Nesbitt, Scott. DMN Communications (2009). Articles>Documentation>XML>Technical Writing

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.

assertTrue (2009). Articles>Documentation>Programming>Technical Writing

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.

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

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?

Cherryleaf (2009). Articles>Documentation>Technical Writing

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.

Tech Writer's World, A (2009). Articles>Documentation>Technical Writing

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

Gryphon Mountain (2009). Articles>Documentation>Quality>Technical Writing

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.

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

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.

Johnson, Tom H. and Benjamin Minson. Gryphon Mountain (2009). Articles>Documentation>Technical Writing>Quick Reference

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.

Opsteegh, Michael. Intercom (2009). Articles>Information Design>Technical Writing>Documentation

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.

Bailie, Rahel Anne. STC San Diego (2006). Articles>Content Management>Documentation>Technical Writing

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

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.

Armstrong, Eric. Sun Microsystems (2008). Articles>Documentation>Information Design>Technical Writing

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.

Armstrong, Eric. Sun Microsystems (2008). Articles>Documentation>Programming>Technical Writing

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?

LugIron Software Blog (2009). Articles>Documentation>Technical Writing>User Experience