Dire times indeed

Discussing the dire times of the Israeli high-tech industry, Paula Stern says technical writing is going "no where fast". She has recently conducted a survey saying there are much more unemployed writers that there were several months ago. I have no information that contradics these numbers. Obviously, they sound reasonable. For example, they fit into the fact the a start-up company I had worked for a year ago, no longer exists.
What is the technical writer expected to do when the times get hard?
Paula says: learn DITA.
I'd refine this, and add: increase your vauability to the organization that pays your salary. I am for facing your clientle, you boss, whomever and boldly ask what would they like you to do in order to improve their business.
no onwe is likely to say they need 12 new user guides, 200 pages long each, and hand you a payment in advance. However, they're likely to help you help them to do a little better business.
Several years ago - where business were OK - I was asked to convert an 1000 topics-long RoboHelp project into FrameMaker. As profitable as this project may be, I told my employers there is no reason to convert, as Frame is less productive than RoboHelp. My assertion is questionable, of course, and I know there are many Frame fans that would love to fry me for this. However, with the customers in mind, you simply don't let them to do such a conversion. If the customer is eager to spend 1000 hours on documentation, they have to know there are several other ways to spend this budget and maybe gain things they never dreamt of.
This story took place in 2006.
Today, no one is expecting to gain more from their documentation, but they will be happy to gain whatever they are currently gaining, with half the budget. I say, go ahead and let them. Find ways to double your productivity. Ditch lously tools; learn new tools really fast; use Word if it works for you (although no writer that respects himself uses it any longer :)
Keep your customer in mind, and you'll make it past this dire times.

Katriel of Method M says that DITA is the least worse approach to documentation. I sadly agree. I don't know DITA, so what I am actually agreeing to, is the concept of "least worse". Whenever I find myself telling my managers about the poverty of the tools I use, I end up frustrated. They are willing to open up their check-books, it is me who tells them to save their money, as to be able to write, circulate for feedback and deliver 2000 topics/year, MS-Word is the only tool available.
MS-Word???
Yes, I answer, exactly because it is the least worse tool. Although I write with RoboHelp as a primary source, and CHM a primary output, I admit it is no better than Word.
But there is a solution, say the DITA people.
DITA, they say, will save me from myself. I admit that I don't exactly know what DITA does. It is said to ease the ability to deliver multiple types of outputs. However, I ask, why deliver multiple types of output in the first place? No one read printed documentation anymore, and for on-line readers, no one can tell the difference between PDF and CHM. They're both easy to navigate, search, and find what you are looking for.
Let's take a different angle. Suppose I throw everything I write to a single website. Suppose that this website is well protected (acceessible only to registered users, for example) and well accessible (it takes a fraction of a second to perform a search, and the search returns excellent results). Now, looking, for example, for installation guidelines for some product of mine, wouldn't it be safe to assume that the readers won't mind whether the piece of information they're after is titled "installation guide" or "installation notes for version 1.1.0.35" or "fix to defect #35022"?
If my assumption is correct, piling everything I write onto a single website will eliminate the entire single-sourcing empire (an empire of pit-falls, if I may). No more DOC-to-CHM, RoboHelp-to-PDF. Wow. This is a Wow, no less.
So, this leave me with what Katriel calls "DITA is a standard — and is implemented using topic-centered and minimalism (methodology)". I'd buy this guidlines anytime.

Creating an Image Report with RoboHelp

When I discovered that my primary layot is On-Line Help, and therefore switched from writing with MS-Word to writing with RoboHelp, I have started to hide my screenshots.

Instead of presenting the reader a set of steps that span through several pages, I deliver a 10-rows-long text-only set of steps whose screenshots are hidden behind the text. Clicking a step reveals the screenshots and most of the readers are usually happy with that.

The problem within this arrangement is the way I maintain these screenshots. Ever so often I am required to update the On-Line Help to match the product's new GUI. In some of these cases, only the GUI changes, while the logic (the way the user uses the application) remains intact. Such a screenshot replacement should be a breeze. It is, indeed, very easy, given that I know where my screenshots are.

How do I know that?
Writing into MS-Word, I simply run through the pages, look at the shots and replace them on the spot. RoboHelp is less intuitive here (no such thing as run through the pages...) but it provides an Image Report.
Quickly bypassing the report's pitfalls (Selecting All Folders doesn’t recognize Conditional Build Tags; Selecting a parent folder results in an empty report) we come up with a list of all images per topic. Properly laying out the topics (i.e. one task sequence per topic), the images read task1-image1.gif, task1-image2.gif, etc.

(Blogger allows for a single picture per post, so no more images for you. Come back other day.)

Earlier this week I have copied such a report into an MS-Word file, along with tiny-little-hand-crafted screenshots icons. Too much work.

Generating the report on a daily basis throughout the project, should do.

Selecting an authoring tool

The technical writer's wet dream looks like this:
"I've recently joined a startup company that has never had a techwriter and needs me to write all the doc from scratch."
Being a wet dream, this question has more that one right answer. However, as I managed not to send my reply to the group (one of the strongest YahooGroups features), I recall it here.
I'd go for constructing a writing culture from scratch. Having my documents reviewed by Markeing / PM / R&D is crucial for their quality. Writing in FrameMaker, PDFing the document and shipping it to R&D for a review, is actually saying "Please don't comment to this document. If you feel you must comment to it, a 'job well done' will do. Here, let me spell 'job well done' for you".
Writing in MS-Word, on the other hand, is far better. Tech Writers don't like Word for several good reasons. However, Word allows for tracking changes in a manner no other writing tool does. Having the document straight with all R&D comments taken care of is far more important than having an FM file nicley * transferred to WWP. **
Tech Writing is a customer facing business. Keeping that in mind makes happy customers. Happy customers make rich Writers.

* I know that 'nicely' is very generous here
** If you don't know what WWP is, count yor blessings