Monthly Archives: March 2008

by Scott Nesbitt

Essential documents for a software project  Clip to Evernote

To the uninitiated, it can be shocking how much documentation a software project can generate — outside of manuals, help files and the like, that is. Design and test documents, specifications, architecture references, and more.

That said, there are many projects which have little or no supporting documentation. Why? The answer varies. With some projects, developers and project managers can’t be bothered putting anything down on paper. With others, they might not know what documents are needed up front. In a few cases, the supporting documentation is written after the fact. Strange but true.

So, what documents are needed for a smooth and successful project? This article outlines the documents that no project can be without. It might be useful to pass it on to development and project leads at the beginning of the development cycle.

by DMN Communications

Weekly links roundup  Clip to Evernote

  • Tom Johnson is asking “what’s the best thing you’ve done to grow your career?”
  • Peter Grainge offers some great advice on authoring, RoboHelp, and Flare.
  • New to technical communications, or thinking about it as a career, and wondering what the typical day in the life of a tech writer is? Here’s one perspective.
  • The curious might want to check out this comparison of DocBook and DITA.
  • An interesting look at Madcap Blaze.
  • Mike Unwalla at TechScribe has published a case study on reaching new markets with clear documentation.
by Scott Nesbitt

Naming your files: a few guidelines  Clip to Evernote

One thing that many of us, I’m sure, don’t think about is how we name our files. I don’t think anyone reading this goes to the extreme of tagging their files as file0001, file0002, and so on. But well-chosen file names make managing documents and their collateral a lot easier.

This post at TECHWR-L puts forward the following guidelines for naming files:

  • Use descriptive names
  • Use alphanumeric characters
  • Use underscores rather than spaces
  • Avoid numbering
  • Use short names
  • Be consistent

What guidelines do you follow when naming files? Feel free to leave a comment.

by Aaron Davis

OpenOffice 2.4.0 packs a punch with new features, improvements  Clip to Evernote

If you’re using OpenOffice Writer to create your tech docs (and there’s no reason that you can’t), you’ll be happy to know that OpenOffice 2.4.0 is now available. This release packs a number of great new features and enhancements, documented over at OOONinja. Some of the highlights of the newest version of OpenOffice Writer include:

  • Enhanced PDF export to PDF/A-1 for future-proof document archival
  • Support for relative links within PDF files
  • Ability to import custom properties from Microsoft Word
  • Improved localization support (10 new languages included)

Will this latest release help OpenOffice gain a little market share from Microsoft? And how favorable will these changes measure up against Word in Bruce Byfield’s next comparison study? Let us know what you think.

by Scott Nesbitt

Keep marketing away from the documentation  Clip to Evernote

Marketing and technical writing. They’re at two ends of a spectrum. As a former co-worker once said “We deal with facts. Marketing deals in hype.” That might seem a bit extreme, but that’s the way it sometimes feels.

But in some circles, there’s a feeling that marketing should be involved in the creation of user manuals. I’ve heard a number of people, notably Kathy Sierra, argue that marketing should play an integral role in the the documentation process.

Darren Barefoot (with whom Aaron and I will be appearing on a DocTrain panel in May), on the other hand, disagrees. This older post explains at length why documentation should be kept out of the hands of the marketing department.

Darren makes one really solid point:

The user has already bought the product. They want to know how it works, not why it’s good. Often the people using the product are not the people who bought it. They don’t care why it’s good. They just want to know how (not why) it will make their lives easier.

In a few instances in my experience, the documentation that I’ve worked on has been used as part of marketing and sales efforts. The folks involved in pushing the software didn’t have a hand in writing the docs, but they did use the manuals and help to do what Darren mentioned: show potential customers what the application can do. In a couple of cases, the documentation played a small role in making the sale.

by Scott Nesbitt

A different way to look at procedures  Clip to Evernote

The way I look at procedures has evolved over the course of my career. Like many street-trained tyros, I first viewed procedures as being mere numbered lists. Perhaps broken up by the occasional nested bulleted list with a bit of indented text here and there. But then it dawned on me that I could make the procedures more useful and more usable by incorporating such elements as tables, task lists and topic maps.

This article from UXMatters looks at a number of ways in which you can enhance procedures, advice that works both for printed and online documentation. One cogent piece of advice is:

Put the critical information in the first three words of a sentence