Having been ill for a couple of weeks I’m just catching up with my reading list and there have been some fascinating posts and articles to read. Quite a few of them struck a chord and I’ll need to give them some more thought before I tackle them myself but all in all it’s a pleasure to be able to read such insightful posts from some very smart people. Ain’t blogs wonderful.
The agile technical writer
An excellent write up of the typical processes followed by a technical writing team in an Agile environment. It’s good to read this kind of thing, as it matches roughly what we do so… we must be doing it right?
In a similar vein I’ve recently written up an article for the ISTC Communicator magazine which outlines what I consider an average day in my working life. Naturally there is no such thing but the things I do, and the processes I follow match Sarah’s.
My ideal blog engine company would hire some seasoned blogger and technical writer to be a documentation czar, keeping docs up to date when new versions are launched, produce screencasts for introductory users, and provide complete documentation at a stable URL that applies to every version of the product.
Moving legacy documentation to DITA
Scott pointed out this interview with Joann Hackos and, as ever, she offers sensible advice, particularly as I’m in the midst of planning such a move (to AuthorIT, not DITA):
Among your previously existing information, some of it we may call legacy because it documents products that are not changing much. Much of this information isn’t worth changing. There’s low value in converting or updating it.
Visual communication is the communication of ideas through the visual display of information. Primarily associated with two dimensional images, it includes: art, signs, photography, typography, drawing fundamentals, colour and electronic resources.
I’ve not read more than a couple of pages but this is fascinating and worth a look if you are at all interested in information design of any type.
The common challenge is to create useful FLOSS documentation in a timely manner. The documentation must be continually updated as the software and projects evolve. It must be simple to understand yet comprehensive. The documentation must be easily translated into dozens of languages. It must be easily revised and distributed in a variety of display and publishing formats (HTML, PDF, PostScript, etc.).
Some handy tips and thinking points for anyone looking to streamline (and speed up) their content creation processes.
Writing in times of resource constraints
Mike Hughes offers some sage advice with some business perspective applied to the resourcing issue many of us face:
If your resources are tight, ask yourself whether you are writing the essential stuff at a level of quality users will notice
“Good enough” documentation is a reality that many of us don’t like to admit, but there are good reasons to understand when it is applicable to use that benchmark.