It’s no secret that I’ve been eagerly awaiting the release of MadCap Blaze for … well, for a long time now. It looks like the release will be happening sooner rather than later — sometime in March or April.
Last week, my colleague Keith Soltys took part in an online demonstration of Blaze. Keith’s written a lengthy and detailed blog post about the demo. If you’re wondering about whether to take in a demo, or if you aren’t able to, then Keith’s write-up is definitely worth a read.
Do more with less. That seems to be a popular mantra of modern business. When Aaron and I toiled at The Company That Shall Not Be Named, we were incredibly constrained by a number factors. As mentioned in a previous post, the documentation department was part of the sales organization. We were expected to make money, but since we didn’t our budget was tiny. To say the least.
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.
You might also want to take a listen to an interview that I did on this subject with Chip Gettinger of Astoria Software.
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.