Technically Speaking

I have a new-found interest in grammar these days. It has to do with my new job, and the work done by my new company.

Then I stumbled across the an article about how scientists are using “grammar” (of sorts) to fight bacteria, including anthrax.

And if the article encouraged you to brush up on your grammar, here’s a great podcast I came across yesterday. It’s called Grammar Girl, and the episodes are short (under 5 minutes) and deal with a variety of grammar topics. It is a great podcast.

So brush up on your grammar boys and girls. This stuff’s important!

Once a week, Christina comes down for lunch. Yesterday we went to Rumbi. While we were waiting for our meal, we could hear the conversation of some people who were still in line. It went something like this:

1: “Did you hear about Jim’s cell phone?”

2: “No. What?”

1: “He lost his cell phone this morning at the Sandy TRAX station. And some homeless guy picked it up and called me.”

2: “Really? A homeless guy?”

1: “Yeah, I got this call, and said, ‘Is this Jim?’ and the guy was like ‘No. But I found this phone. And I’m homeless and wondered if you guys could help me out, in exchange for the phone.’ So he was totally negotiating to get the phone back. I told him that I would try to get a hold of Jim, and I’d have Jim call him back. So Jim’s got to call the homeless guy back and try to negotiate the return of his phone. I’m sure he wants it back, so it will be interesting to see what happens.”

And with that, they moved out of hearing distance.

Poor Jim. Now he’s got to schedule the drop. Paying ransom to get the phone back.

What a random conversation.

In my opinion, Adobe Framemaker has a major flaw: it doesn’t support external sytle sheets. External style sheets could be huge. Maybe I should explain.

One of the powerful things about FrameMaker is the ability to create templates that you can reuse across all your documents. For the current release of my product at work, I’m working on about 200 pages of printed documentation, spread out across four books and about fifteen separate documents. Before I started my project, I created a template book. In my template book I created a template chapter, and defined all the styles, or rules for formatting the text.

When most people use a word processor, like Word, they apply ad-hoc formatting. This means that when you want to create a heading, you select the text and you apply bold formatting, or change the color, or change the font size. They follow this same procedure for every heading that they create.

Frame doesn’t like that approach. Rather, you are supposed to create paragraph formats (Word calls them “styles”) that you apply to the text. You have a number of styles (my guides currently have about 50 possible styles) that cover everything from the body text appearance, to headings, to your title on your title page, to the style of the picture captions. Once these are pre-defined, you just select the paragraph, and apply the format. If you ever want to change the format, you just use the paragraph designer to apply the format. It’s pretty powerful, and it saves me a bunch of time, after the formats have been created and refined. However, here is where we encounter Frame’s weakness.

When you create a style, you apply it to the document’s template. When you create new documents, you base them off the template. However, Frame doesn’t remember that you based the document off of the template, so if you ever make changes to the style in the template, you have to open up every separate document and import the style information. Every document contains its own style information, so if you change it in one document, you have to import those same style settings into all other documents to keep them consistent.

I wish Frame supported external style sheets. HTML allows you to use external style sheets, and they work really well. With an external style sheet, you have a separate document that contains all the style information. At the beginning of an HTML document, you create a connection between the HTML file and the style sheet. When the page is delivered to the web browser, the web browser gets the text from the HTML file, and then formats the text according to the style information in the style sheet. You can have multiple (actually an unlimited number of) HTML pages that use the same style sheet, If you want to change the formatting of a particular heading, you open the style sheet and you cange the formatting options. Remember that individual documents don’t store formatting information; all the formatting information is derived from the shared, connected style sheet as the page is loaded in the brower. That means all pages are updated to the changed style as soon as the change is made in one place.

Frame doesn’t support external style sheets. In Frame, every individual document contains its own formatting information. Currently, if I want to change the style, I open up the template document for the type of document I’m working with. I make the style change, and then I save the document. Then, one at a time, I open every document I’ve based off that template, and I import the style information into that document. Its a labor-intensive process, and it is totally unnecessary. If Frame supported external style sheets, I could just open the external style document, make my change, and go on my way, knowing that all the styles would be “updated” as each document was opened.

So, if you are listening Adobe, please, please, please consider adding external style documents in the next release of Frame. It will literally save me hours of time during each release cycle of my product documentation.

Yesterday we had a potential client who asked a weird question. This client wanted to know how much documentation we ship with our product. I guess that is a natural question, although I do think it is kind of unusual. (Are they not going to buy the product because there is too much/not enough documentation? I suppose it is possible.)

This client’s question, however, entered the weird realm when we realized that they didn’t want to know how many pages of documentation or how many guides we provide. No. They wanted to know how many bytes of documentation we provide.

I’m scratching my head on this one. How many bytes do you want? Do you like pictures? More pictures means more bytes. I publish the documentation in PDF format. I have two 30 page guides I released with the beta version of our product. One was 300KB (which, since they asked for bytes is actually 307,200 bytes). The other was 800KB (or 819,200 bytes). The guides are the same length. One just has more text and one has more images.

Crazy.

What makes the question particularly difficult is that I haven’t even written the bulk of the content yet for two of the guides. How am I supposed to make a guess at how many bytes they are going to be when I’m finished?

What a bizarre request….