Be like an empty cup. That sounds like something out of a martial arts melodrama. Which is probably where I lifted that nugget. Regardless of how hokey it sounds, it’s good advice in any career. And especially in technical writing.
If you’ve ever printed a Web page or a portion of an online document (don’t deny it, we all have), you’ve probably noticed that in many cases along with the text you get other superfluous page elements like navigation and ads. They can take up a lot of space, and cause the text on a page to wrap badly.
It doesn’t have to be this way, though. Cascading Style Sheets (CSS, which enable you to change the look and feel of Web content) also enable you to style documents for printing. Using CSS, you can change the layout of a Web page and leave out any content — like navigation or even graphics.
Doing this is pretty easy. The following are good introductory guides on how to work with CSS for printing:
Even if you use an authoring tool that automatically generates printer-friendly CSS, the content of these articles is useful if you ever need to modify the CSS code.
You may have heard the term component content management but you’re probably wondering what the term means, and what it means to you. This article — written by Paul Trotter, CEO of Author-it Software Corporation — is a very detailed look at component content management.
As technical communicators, we’ve all heard the arguments against documentation. You know the ones I’m talking about: “Users never read the manual or help” or “The product is easy enough to use” or “The documentation is horrible, so what’s the point?” Ad infinitum. For a true professional, these kinds of statements are a slap in the face.
But do those statements have any validity? Maybe not, according to this article at UXmatters. The article is very interesting, and has some excellent real-life examples of people actually using the documentation for a product. My favourite? This one:
In a usability test of some small business financial software programs, we all froze when one participant reached for a fat manual. We were all wondering whether the rest of the session would be spent watching him read through the book, looking for an answer. Amazingly, it didn’t. Within a few minutes, he had found the answer and used it to successfully solve the problem he’d been stuck on.
What Tom describes can be categorized as more of a like/dislike relationship than something as intense as love and hate. But he gets to the core of some of the great features of Flare, and some of the wonkiness of the product. And Tom did it the right way: he took the time to get to know Flare. As I wrote elsewhere, that’s the only honest way to review a product.
That said, we have to keep in mind that Flare is a relatively young product. It’s going through some teething pains. And, as I understand it, the folks at Madcap Software listen very carefully to their users, and (I hope) will eliminate or at least smooth out the 31 issues that Tom pinpointed. At the same time, I hope that they’ll improve upon the 45 things that Tom likes about Flare.
To be honest, though, I’m sure that Flare will always contain some features or functions that don’t appeal to everyone. No matter how much you love a piece of software, there will always be something about it that annoys you. I get frustrated sometimes with FrameMaker and OpenOffice.org Writer — and I’m a big fan of both.
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.