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.
Rick
