Where's Rick?

Wow, leave blogging aside for a while, and the world just passes you by. The past few weeks have been so busy, that I haven’t even been able to read the blogs I follow. I fired up NetNewsWire this evening, and there were over 700 posts awating my perusal. Clearly, I’m not going to get through them all.

So, why have I not been blogging lately? Well, we sent Mac Office 2004 off to manufacturing, at which point we all took a few days to just decompress. At the end of a product cycle, you tend to not even want to look at a computer, let alone sit down in front of one in order to type out a few random thoughts. Unfortunately, my boat was out of the water getting a new coat of paint on the bottom, so I didn’t get to do much sailing either. Yes, my timing was impeccable.

Also, the end of April is a very busy time for members of the Bahá'í Faith. We have three holy days, an annual meeting, our regular monthly meeting (monthly in terms of the Bahá'í calendar, not the Gregorian calendar—don’t ask), and a national convention all packed into the span just short of two weeks. In any event, my evenings have been pretty clogged, and, in fact, I have another meeting to go to tonight.

After the decompression time was over, it was back to work where I’ve had three major items on my plate. The first is engineering excellence planning which is where we take a look at some of our development methodologies and think about ways we can improve the process. As part of this, I’ve been working on writing some new unit testing code for Word which my Win Word counterparts are interested in stealing when I’m done (and I’m almost there).

The second is some product planning for Office 12. I’ve blogged about this in broad strokes before. Basically, we take some prototypical users, and we design some product use scenarios around those users’ needs. I’m a member of a cross-discipline team that’s drilling down into one of those scenarios. There is a different team drilling down into each scenario, understandiing what users are doing, looking into how our products presently help them solve the problems they’re facing and identifying what might be referred to as users’ “pain points” as they try to solve these higher-level problems. From this work, we’ll design the features that will go into the next version of Mac Office.

The third big item on my plate was the Customer Council meeting. The Customer Council consists of a number of customers who have purchased premium support. One of the things you can have with premium support is the ability to sit down with the product teams and discuss what your issues are. We had representatives from firms like the Rand Corporation, Turner Broadcasting, Gannett News, and several others. I think there were about 25-30 representatives present.

Normally, presentations at the Customer Council meetings are handled by program managers, but, following the release of Office 2004 to manufacturing, we had some personnel changes in the program management group affecting Word. So, I got to be the one making the presentation for Word, which is something I really enjoy doing and don’t often get to do because I’m a developer. The other cool thing about it was, after I’d finished my presentation and discussed some of the future directions we plan on taking with the next version of Office, none of the members of the Customer Council had any further questions. Members of the Customer Council don’t pull their punches, so when they don’t have any further questions or comments after you’ve finished the presentation, you’ve pretty much nailed it.

The other very cool thing about this year’s Customer Council is that we spent a good chunk of time sitting down with representatives from Apple, and the level of communication in the room was appreciably better than anything I’ve seen in the past almost 14 years. The results were so positive, that we think we want to do this kind of thing, sit down with customers, representatives from Apple and representatives Microsoft all at the same time to hammer out some issues. I don’t think it will be all that long before users reap some benefits from this kind of cross-communication. It’s very much a sea-change, and, I think, a very welcome development for the industry.

Anyway, so while I’ve been doing all this, Chris Pratley has been on paternity leave (congratulations on the baby, Chris). He’s been blogging, and blogging, and blogging and blogging about some of the history of Word. The posts provide a nice compliment to my post on Mac Word 6.0. Unfortunately, in the process, Chris discussed some of the things I had in mind.

One of the issues I wanted to talk about is why there is no “reveal codes” feature in Word. People ask me about this relatively often, and, when they do, I know I’m talking to former Word Perfect users. As Chris points out, Word Perfect used markup codes to do things like turn on bold, then, later, turn it off, similar to the way HTML works, while Word uses what might be described as a parallel array of runs of text matched to buckets of formatting properties (well, actually, they’re coded as differences from the underlying style, but that’s a detail for another post). One of the things Chris doesn’t point out, however, is how Word’s design is better suited for WYSIWYG word processors.

Suppose I give you an arbitrary location in the document (because, say, that happens to be the first character of the first line being displayed in the current document window), and ask you whether or not the character at that location is bold. Under the markup design, you have to start from the beginning of the document, and scan forward to the arbitrary location I’ve given you. Under Word’s design, you merely search for the corresponding run of text that contains that document location, and go look at the property bucket to see if bold is there. In Computer Science terminology, Word Perfect’s design requires an O(n) search, while Word’s design requires an O(log(n)) search.

Now, this didn’t mean all that much back in the days when the word processor presented the document on a character-based display. In fact, it actually put Word at a bit of a handicap, because Word was doing extra work to maintain the parallel buckets for all the formatting informtion. Word Perfect could just dump whatever characters you typed into the file without having to worry about ensuring that any formatting that’s applied to the newly-typed text gets stored as well as the new text. When people start using Windows, however, Word’s design had the advantage while Word Perfect’s design was at a disadvantage. This is yet another data point showing why we need to design the UI first, and then implement the features. It’s also something to keep in mind when people think about the history of word processors.