Using Custom Icons in TOC

There have been talks about this bug in HTML Help Workshop here. After first reading the tutorial I was a bit discouraged as I didn't have any idea what "file://%systemroot%" meant. For those computer novices like me who might be facing the same problem, try to follow these steps in order to use custom icons in your TOC:

1. Create the new icon strip that you want to use. Find very helpful indications in the tutorial I previously mentioned.
2. Save the icon strip as a .bmp file (e.g. newhelpicons.bmp) in the %systemroot% location. To open this location use Start/Run/%systemroot%.
3. Open your help project in HTML Help Workshop.
4. In the Contents tab, press Contents Properties.
5. Select the "Use custom image from a file" option and, instead of browsing the path, type in "%systemroot%\newhelpicons.bmp".
6. Press OK.
7. Save and close the project.
8. Reopen the project and compile.

Unordered Lists Issue

For me, unordered lists used to be the hard nut to crack of Microsoft Front Page. That is, until today. I don't know if it's a bug or just my lack of knowledge, but after hundreds of cries and tears here's what I found out:

.list_1 {
list-style-image:url("../images/bullet.gif");
}

will not work unless you use bullet.gif in at least one html page in your project.
Tricky, huh?

Yucan on my Mind

Reading The Yucan, Your 2nd Best Friend by Mark L. Levinson was the best thing I could do today to compliment my technical writer ego. And to those who may raise an eyebrow in distrust, I must specify that even green technical writers like me have egos that are pretty much out of the ordinary.

In other words, since I began writing user documentation I felt more comfortable talking about what you do rather than what you are enabled, allowed, permitted or, God forbid, empowered to do with the application.

Think again, it may have been that tiny grain of incertitude about my proficiency in English and the inevitable need to simplify everything that led me to the fortunate situation after all...

But anyway, even after the brief reality check, it still feels good :D

Screenshots: Overrated or just Oversized?

Since I was first introduced to technical writing, some ideas got stuck in my head, and only recently my subconscious allowed them to come out in the open.

One such idea is that any help manual should contain as many and as large screen shots as possible, as if only by tickling the users' visual sense could you help them fully understand whatever it is you're writing about.

I know that application help is merely a dry field and rarely would Uri the User venture to the point of actually reading it. In fact, Uri allows himself to press the feared F1 key only after realizing he's been staring at the screen for the last five minutes, not knowing what information should he introduce in a specific field... and after asking at his left and at his right with little use. To be completely honest, so do I.

Imagine that when searching by the name of the troublesome field, Uri gets a link to this help topic, bed sheet size, containing a generous mix of text and full-size screen shots. And then, unconvinced, he starts reading from the top, hoping he will, eventually, stumble upon some info about the field that's bugging him.

My best idea is the link should take Uri to a tiny little text, with a tiny little image beside it, and some tiny little links to related topics, if needed.

On a second thought, the idea of large screen shots with text underneath them spanning six screens long must be tributary to the larger vision that all related should stick together. For example, anything contained in a menu tab should be explained in one help topic.

Maybe this works for printed manuals. But in application help, I'd say each control with it's own topic. Easier to refer to in index, easier to fit on screen, easier to read and understand.

But I could be wrong.

Why don't tech writers get a life?

Two years and a half ago I decided I could be a technical writer. In the meantime, I realized that being a technical writer sucks. Mind your cons on this one, as a list of highly well-grounded reasons follows:

1. At the interview: Though everyone in the company is a skilled documentation writer, as you are told, they don't have time to handle the documentation anymore ... Therefore, they are hiring a tech writer. On a second thought, they'll hire two tech writers.

2. First day at work: You are really needed in the organization, they say, but for the time being there's no documentation that needs to be written. Try to look busy and you'll be alright.

3. First month: 'Still no work for you huh?'

4. Second month: 'Don't worry, we'll find something that you could do around here. Eventually...'

5. Shortly after: 'We finally have something for you. Do you think you could write the help manual for this application by next week?'

6. The next day: Someone has to train you a bit in the new application, you're told, explain you a few things... But nobody has time today. Ask again tomorrow.

7. 'Ask again tomorrow.'

8. 'Today we're all in a meeting, 9 to 5. We'll talk next week.'

9. Finally, somebody remembers you:
'How's the help manual going?'
'I was just about to ask if anyone has time for that discussion today...'
'This week it would be pretty much impossible.'
'But I thought it is due next week...'

10. In one year or so: 'Think you could learn MySQL?' (In the end it is revealed to you that you can't help with MySQL either. There's plenty of trained staff in this field already).

11. In two years or so: 'We might need to let you go after all... No hard feelings, OK?'