If you’re doing any sort of structured authoring, then a content management system (CMS) is a must. But choosing a CMS can be tough. And that task gets tougher when you add DITA to the mix.
In this blog post, Eliot Kimber outlines his requirements for a CMS that supports DITA.
Do you agree or disagree with Kimber’s assessment? And what are your experiences with DITA-aware CMS? Feel free to leave a comment.
Further to a previous post, here’s a very interesting opinion on documentation being a revenue driver from Adobe’s Technical Communication blog. The crux of the post is:
If technical communication is effective, more customers understand the offering in shortest possible time and hence, lead to higher sales or adoption.
I couldn’t agree more.
A large number of organizations have documentation in formats that either aren’t supported or are not widely used anymore. Some of this documentation is mission critical. Some of it needs to be kept around for auditing and compliance purposes. One way to ensure that information is usable now and in the future is to convert it to DITA.
This interview with JoAnn Hackos discusses moving legacy documentation to DITA. Something that I found particularly interesting in the interview was Hackos’ definition of legacy documentation:
There are two ways people define legacy documentation. When you are moving to a content management system, using DITA and XML, everything that exists at this point is legacy documentation. But there’s a second definition: 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.
Every two weeks, Aaron and I hold a virtual meeting. We get on Google Talk, catch up, and talk business. The last time that we did this, we were discussing some matter or another and one of us said “I wish I’d known that when I started in the profession.” In a series of blog posts over the coming weeks, we’ll be sharing some of that kind of information.
The first bit of advice is that knowing how to write isn’t enough. The ability to write well helps, but there’s more involved in being an an effective technical writer.
When we think of help authoring tools, most of us focus on RoboHelp, Flare, WebWorks, and maybe Author-it (which is far more than a HATT). That’s understandable — they’re the big names, and are widely used. But the HATT ecosystem contains a lot of other applications, too. Some of them are good, others are sorely lacking.
In this article at WritersUA, Matthew Ellison looks at three help tools that were developed in Europe. They definitely don’t pack the features that you find in the big name HATTs, but the tools that Ellison discusses have some interesting features and they could be useful if your online help needs are modest.
In a recent podcast, Tom Johnson spoke with Paul Pehrson about Madcap Flare. It’s a wide-ranging discussion that touches not only on Flare and help authoring in general but also some interesting career advice.
What’s refreshing about this is that Pehrson isn’t an employee of Madcap Software. He’s a user of Flare. Well, Pehrson is more than just a user; he’s a really passionate user. He’s an MVP in Madcap’s forums and he regularly helps other Flare users solve problems.