A Few Things to Rant About

Here we are, another Saturday and December already. I got a lot of work done again this week, but one of the tasks I accomplished took longer than it should have because of…

Rant #1: The “All Micro$oft Ensures Compatibility” Fallacy
I agreed to enter a large number of texts for a client via TextStyleM so that said client would have a wealth of examples from which to copy-and-paste when adding additional, similar content later. The texts were provided as a series of Word documents in folders corresponding to the hard copy of a publication. As a result, I could do copy-and-pastes of articles into TextStyleM and then massage the text within the editing box (reintroduce italics and boldface where needed, recreate blockquotes [double-sided indents], etc.).

My browser of choice these days is Netscape 7.1, although I’m considering giving Firefox a whirl soon. But as a developer, I have to turn to IE once in a while, given that it’s the most widely used browser and I have to make sure that pages are rendered tolerably well within it. And it was while conducting such a test that I discovered a problem: some — although not all — of the pages I had been creating had this big ugly gap of white space at the top, which wasn’t occurring in Netscape.

My first reaction, of course, was to blame how TextStyleM generates code. Indeed, I always assume it’s my fault even though there’s no hard evidence of this when I look at the code that’s been generated. It was only once I removed all the TCodes — TextStyleM‘s simplified markup language — and noticed that the gap persisted in IE that I could conclude the culprit was something else. But what? What was making IE cough up such ugly pages?

Thus began one of those notorious searches for the needle in the haystack. The only logical conclusion I could draw was that there had to be some kind of hidden code in some of the Word documents from which I was working, but which one(s)? However, what made me angrier was that whatever code there was that was causing the problem, it was generated by a M$ product (Word) and was then causing havoc in another M$ product (IE).

The ellipses turned out to be the culprit — yes, those innocuous “dot dot dot” (…). I’m not sure whether or not it’s a default setting in Word, but if someone types “period period period,” they get automatically converted to a single character, namely ellipsis (with the periods kerned). Once I had searched for that character and replaced it with three periods within Word before copying-and-pasting into TextStyleM, IE rendered the page correctly 95% of the time. For its part, Netscape never cared one way or the other.

Stuff like this makes me despair about M$ products, just as most professional webmasters will run out of a room screaming their head off at the mere mention of FrontPage to create webpages. I could have understood if the problem was the other way around, that is, if Netscape had behaved oddly when it would encounter an ellipsis character. But IE? The worse thing is that I’m not convinced the problem wouldn’t have occurred if I had been taking Word documents as my base and trying to bring them into FrontPage.

At any rate, now I have to warn clients about this potential problem or, better still, find a way of automatically converting the character back to dot dot dot. And you just know that those who cling to the belief that “all M$ products = no compatibility problem” are going to assume it’s because TextStyleM isn’t M$. It makes me want to bang my head against the wall until it falls off my shoulders.

While we’re on the topic of dealing with clients…

Rant #2: “This Business is my Livelihood, Folks!”
I assume the best of my clients — always have, still do, and probably always will. This assumption implies that I don’t believe my client are intent on screwing me, just as I’m not intent on screwing them. But I’m not sure some clients understand all the differences between dealing with a large company and dealing with a small vendor like yours truly.

They do understand some of the differences, mind you. A small vendor is more likely to be able to provide personalized service than a large, quasi-faceless service provider. And, because a small vendor tends to have lower overhead costs, it is able to place competitive bids on projects — a deal-making factor that has brought many clients on side in the first place. But the part they may not fully grasp is that a small vendor depends on the timely payment of its invoices.

The individuals within any organization who are in charge of paying the organization’s bills have a job one way or the other. Whether they elaborate a policy whereby bills aren’t to be paid before so many days, or adhere to a hierarchical structure resulting in a long and convoluted process to obtain the autorised signatures, they can rest in the assurance that they will be receiving a paycheque every two weeks or every month or whatever. Conversely, a large vendor doesn’t have to rely as heavily as a small vendor on the timely payment of the bills it issues. A large vendor has a bit more elasticity in that regard, although, like any vendor, it can’t afford a high margin of bad debt. The latter is a killer regardless of the size of the vendor.

There is a very direct connection between the invoices a small vendor issues and that vendor’s paycheque and out-of-pocket expenses. Any small vendor will tell you that, out of necessity, they have a buffer for the ups and downs within their receivable folder, but all buffers have their limit. Those whose job it is to pay the vendor’s invoices will continue to draw a salary no matter what. But when a small vendor is caught for too long with a bottleneck in its receivables, it could be forced to fold. And thus the deal maker that has brought some clients to have chosen the small vendor evaporates, along with the small vendor…

I should point out that most of my clients pay their bills in a timely manner, most of the time. Bless them for that! Plus, things shouldn’t be taken personally in business and none of my client has ever acted out of malice. I also regard my clients as human beings, and to err is human. However, when errors occur or systems fail, it might be a good idea to look into how to avoid future errors or fix the system.

I’m just sayin’…