Buggin' My Life Away

The Glaring Hole in the NSTextInputClient Protocol

2011-11-28T17:04:25Z

The fine folks at Apple generally do a pretty good job of designing the programmatic interfaces, "protocols" in Objective-C speak, that the system and applications use to communicate with each other. I mean that most sincerely. Designing programmatic interfaces is hard, because you have to anticipate the needs of different system components. Sometimes, you have to do that before relevant components have been written, so you'll not always anticipate those needs in a way that leads to a suitable user experience.

The NSTextInputClient protocol has a classic example of this problem. Take some time to read the reference, and see if you can spot the hole. Go ahead. Take your time. I'll wait.

Did you spot it? No? OK. Try this:

Make sure you have the Kotoeri input source enabled (System Preferences/Language & Text/Input Sources; check Kotoeri and at least the Hirigana sub-item). You'll also want to check the "Show Input menu on menu bar" check box.
Launch TextEdit
Go to the Input menu (a US flag if you're a US user), and select "Hiragana"
Type "sa"<return><space>"sa"<return>"
Back up a character, without selecting it, by pressing the left arrow key
On the Input menu, under Kotoeri, select "Reverse Conversion"

At this point, you'll get a popup menu that provides a number of alternative characters to be inserted instead of the default "さ" that was inserted in place of the second "sa" that you typed in step 4.

What just happened? Well, you asked the Kotoeri IME (Input Method Editor) to try to reconvert some text in the document. At that point, Kotoeri needs to figure out what text you want to reconvert. Now, put yourself in the place of someone who's implementing this feature in Kotoeri. Go back to the reference for the NSTextInputClient protocol, and ask yourself, how do I implement this feature?

Well, the first thing you'll do is, see if the user has any text selected, because that's a pretty clear indication of exactly which text the user wants to reconvert. So, you'll call the selectedRange method. If the selected range isn't empty, then you'll just call attributedSubstringForProposedRange:actualRange: passing the selected range you just got from calling the selectedRange method.

In the steps above, however, the user selection is an insertion point. The selectedRange method returns an empty range. Now what? You'll need to probe the document content to figure out what text to reconvert. But, the insertion point can be at the end of the document. As a Kotoeri implementer, the first question you're likely to ask is, how long is the document? Unfortunately, there's no method in the NSTextInputClient protocol that provides a direct answer to this question. Thus, the glaring hole in the protocol.

At this point, as someone who is implementing an input method editor, you have two options. You can create a reasonable range of text to probe based on the location of the insertion point, and call attributedSubstringForProposedRange:actualRange: paying attention to the actualRange value that you get back. Or, you can simply call the attributedString method, and get the length of the result.

It's possible that the Kotoeri IME has been revised for Lion, but, as of Snow Leopard, Kotoeri actually uses the second option. And, note that the attributedString method is optional. If you've written an application that implements the NSTextInputClient protocol but have omitted an implementation for the attributedString method, then nothing will happen if the user selects "Reverse Conversion" in the above scenario.

OK, so what's the big deal? The protocol does provide a solution to the problem from the IME's perspective, so everything's fine, right? Well, not quite. Let's put our end-user hats back on. Some users have documents that are thousands of pages long. You do not want to implement the attributedString method in a way that simply returns a standard NSAttributedString, or even just a regular NSString. Both the performance and the memory usage is not likely to lead to a satisfying end-user experience for people who spend their days editing long documents.

Careful readers of the NSString class reference will figure out a reasonable solution to this problem, but a more robust design for the NSTextInputClient protocol might have obviated the need for applications developers to pay such close attention. Having said that, it's probably not fair to either Apple systems engineers or the folks who implemented the Kotoeri IME to argue that they should have thought of this. Anticipating this kind of corner case is something even very smart people will miss.

Rick

Currently playing in iTunes: Days Is Almost Gone by The Derek Trucks Band

Steve Jobs

2011-10-06T19:16:53Z

There's a lot being written about Steve's passing, but I'm afraid there's so much of it that truly misses what Steve really did for our industry. For example, Matt Yglesias asks, "Why so view?" I posted a brief comment there, but I think the point deserves a good bit of elaboration.

Steve's contribution to the industry I think is epitomized in this video:

As Nadyne might say, there are really two parts of user experience: aesthetics and functionality. Aesthetics is about your emotional reaction to using a product--a certain joy or excitement. It's what people are really talking about when they refer to the "cool" factor. Functionality is what a product helps you to achieve. Does it relieve you of mundane tasks, thereby allowing you to focus your energies on your own creative output? How does a product help you achieve your goals?

Aesthetics leads you to want to break with the past. Functionality leads you to want to build on the past in ways that don't leave people stranded. There's always a certain level of tension between the two, and the amount of emphasis you place on one over the other can lead to some widely divergent design decisions.

Steve placed far more emphasis on aesthetics than the rest of us did. He always thought that if people didn't experience joy in using his products, then he'd failed in some important and fundamental way. The rest of us generally focused on functionality. The one quibble I have with Steve's criticism is this: it's not a question of whether or not we had any taste. It's more a question of whether or not we thought it was an important place to focus our energies. Steve thought it was. We didn't.

But, the key insight that I think is missing in most of the tributes being paid to Steve is that both of these aspects of user experience are important. I truly believe that Steve understood this. He was, after all, the one who had said, back in the dark days of the early 90's, that Apple couldn't survive without Microsoft. He took a lot of flack from people in the industry for that stance, but I think he understood, at least intuitively, Apple users needed our functional focus just as much as they needed his aesthetic focus.

Steve's true contribution to the industry, then, is the way he married both of these concerns. He and Apple set the aesthetic parameters that determined the boundaries in which those of use who developed software for the Mac would fill in the functional aspects of user experiences. That combination leads to some fascinating synergy that began with movable-modal dialog boxes and combination edit/drop-down menu controls in Mac Word 4 all the way on up to how we did the ribbon in Mac Office 2011. If there is any legacy of Steve's that I would hope this industry could cary forward, it's this balance between aesthetics and functionality.

Rick

Currently playing in iTunes: Wayfaring Stranger by The Tierney Sutton Band

Usability and Styles

2010-05-30T16:20:43Z

According to Pierre, I'm too ossified to discuss this subject. On the other hand, when Pierre uses the word "usability," it's very much like the way Vizzini uses the word "inconceivable" in The Princess Bride, and I'm often moved to quote Inigo Montoya, "You keep using that word. I do not think it means what you think it means."

The problem with Pierre's discussion of usability is that it's completely devoid of any discussion of user tasks. Pierre never talks about why a user would want to know what styles are applied to a given location in the document, and how the presentation of that information simplifies common user tasks. Had he done so, he would quickly realize that Pages' solution to some key user problems isn't as elegant as Pierre would have us believe. Indeed, there's one key problem where Pages offers no effective solution at all.

People use styles for two general reasons that are not incompatible with one another: to denote structure in the document, and to maintain a consistent look throughout the document. A common task associated with both goals is to review the document for consistent usage, and it's worth noting that the person doing the review is often not the same person who originally wrote the document.

Note that I've used the word "review," and I've done so for an important reason. A review might involve a scan of the document, but that's not always the case. Indeed, one of the more important questions users ask is, where are certain styles used within the document? Both Word and Pages have a rather quick way to answer that question via the "Select All" or "Select All Uses..." menu options on the individual style items in either the styles pane in Word or the styles drawer in Pages. Though, here, I would argue that Word's solution is better in two ways. First, in Word, you can filter the list of styles to only those styles in use. In Pages, you have to scan a list of styles looking for styles that are in use. Second, in Pages, you have to select the entire document. In Word you don't.

So, think about the work flow for reviewing the use of several styles in a document. In Word, you'd filter the styles list to styles that are in use, then choose "Select All" on the style item menu for each style you'd want to review. In Pages, you first have to select the entire document, then scan the styles drawer for the style you're interested in reviewing, and then choose "Select All Uses" from the style item in the drawer. To review the next style, in Word, you just choose the "Select All" item for the next style you want to review. In Pages, you have to reselect the entire document and then repeat the scan through the list of styles. In this case, Word's UI allows the user to complete the task in less time and with fewer steps.

Now, that covers how users would answer the question, "Where have I used this style?" There are times when the user will want to ask, "What styles are used here?" For character styles, Pages is marginally better than Word. Pierre is correct in noting that Word currently does not give the user a way to answer that question for any arbitrary sub-section of the document. On the other hand, in both Word and Pages, you still need to click around in the document in order to see what styles have been applied in particular locations, and it's not at all clear how seeing the styles used in an arbitrary selection simplifies the overall task of reviewing a document for style consistency.

Moreover, with Pages, the user is still saddled with having to scan a list of styles in order to see which ones are applied. And, as a side note, the two different style menus do not provide a particularly elegant solution either. The little "-" sign next to the style items is difficult for some users to even see, and the fact that the user has to drop two menus to find the relevant information adds yet another step to any user task in which the user seeks to answer the question, "What styles have I applied here?"

A far better solution would be to provide visual cues in the document itself showing what styles have been applied. For paragraph styles, Word has long had this feature in draft view. On the "Word" menu, select "Preferences" and then click on the "View" icon. In the "Window" section, you'll see a "Style area width" edit item.

But, that's not an ideal solution either. First, there's no information about character styles. Second, the user has to switch document views. For Word 2011, we've come up with a better solution. You'll likely see a post on Mac Mojo talking about the work we've done here, but it's a far better solution than those offered by either Pages 2009 or Word 2008. No selection required, no need to drop a menu or scan through a list of styles in the styles drawer. In order to see what styles have been applied, the user will merely need to scroll through the document.

Now, we've talked about two different questions that users often ask: "Where has this style been used?" and, "What styles are used here?" There's a third question that users ask, and it's often more important than the other two. That question is, "Where has direct formatting been used when a style should have been used?" The goal, here, is to correct these cases; to replace the direct formatting with the styles that should have been used in the first place.

Pages currently offers no real solution to this problem. At present, Word does have a solution, but it still requires the user to scan through the document and click where the formatting appears to be different from the underlying style. Though, to Word's credit, the "Current style of selected text" control in the styles pane gives the user a way to select all instances of that combination of style + direct formatting in the document, at which point the user can then simply apply the style that ought to have been applied in lieu of the direct formatting.

As with the "style area width" feature in Word, this is also not an ideal solution to the problem. We can do better. Indeed, perhaps there's a solution that allows the user to merely scroll through the document...

When it comes to usability, it's not enough to just "think different." You have to think about what users are trying to do and what tasks they need to perform in order to achieve those goals. Ultimately, if your "usability" does little to shorten the amount of time it takes for users to complete important tasks, then it really has nothing to do with "usability" at all.

Update: I couldn't talk about the work we've done when I first posted this, but here's a nice screen shot of Word 2011's Styles Guides:

The full article is here, and I'm particularly fond of Edward Mendelson's description of this feature:

The other terrific new feature is the Styles Guide display. When you turn this on, a color-coded column appears (on screen only) in the margin of your document. Each block of color has a number, and the colors and numbers match colors and numbers in the styles menu, so you can see at a glance which styles are attached to every paragraph. This is impossible in all other versions of Word, and all other word-processors. Another option, also available from the Styles menu, turns on a "direct formatting indicator" that outlines in blue all the text in the file that is formatted directly from a menu with (for example) italics or bold, instead of being formatted with a style. I only hope that Windows users will get this terrific feature before too long.

If you look closely at the left-hand document, near the bottom, you'll see a bluish "9" box to the right of the yellowish "7" block. That means there's a character style applied within that line.

Notice, also, that the "7" is drawn black while the "9" is drawn white. I'm proud to say that I came up with the algorithm for figuring the color for the number based on whether the human eye would perceive the background color as being "dark" or "light".

And, by the way, that entire Styles pane is done completely in Cocoa. So, it has some nice animation features when you change the "List:" menu to change the collection of styles that's shown in the list.

Was it John Gruber who said something about attention to detail when he linked to Pierre's original post?

Rick

Currently playing in iTunes: I've Been Working by Van Morrison

Managing Shared Code

2010-05-27T23:08:49Z

Brent Simmons has some thoughts on managing shared code. Those ideas are a good start, the most important being that this code needs to be under some kind of source code management tool, preferably one with good branching/merging facilities.

There are a couple of other ideas to keep in mind. Brent's further bifurcation of code into Foundation and UIKit sub-sections is a good idea. Indeed, it's not a bad idea to start thinking of the relationship between your app and the OS as being the meat (tofu for the vegans out there) in a sandwich. The Foundation code is the bottom slice of bread, and the UIKit/NSFramework stuff is the top slice of bread.

However, I'd take it a step further and break the code up into functional units. In Brent's case, I'd imagine that there's a networking stack, some XML parsing/XML RPC code and some data store manipulation just in the Foundation tree alone. I'd keep those separate from each other.

I'd also reconsider the idea of building static libraries. The shared code, along with the unit tests and any other acceptance testing code, should be in at least one separate project, but it's even better to have each functional unit of code in its own project. The linker should be able to dead-strip anything that any given client doesn't use, especially if these are static libraries, and having separate projects ensures that the code is always built the same way regardless if which client is using it. Managing the build settings for one shared project is much simpler than trying to ensure that the build settings are consistent across all the projects that use the shared code.

If debugging is a problem, then create separate build and debugging/development projects. The latter can help reduce the time required for the edit/build/debug cycle to complete, yet still retain the functional separation that is beneficial to code that's shared.

Once you've separated pieces out into projects according to functional units, have each project build a framework that exports the symbols that are "public" for that shared piece. You can still link the static libraries for actual distribution bits. Indeed, the target that builds the framework should have a single, dummy source file while the framework links in the static library that's actually shared. Doing this will tell you what the interdependencies are between the various functional units. You'll discover whether or not some circular dependencies have crept into your code, and those will almost certainly end up causing you headaches in the future (if they aren't already causing you headaches now).

Remember, agile programming isn't about you being agile. It's about making your code agile. And, if you're sharing code, it really needs to be agile enough to work in the variety of contexts in which its shared.

Rick

Currently playing in iTunes: Lost In the Flood by Bruce Springsteen & The E Street Band

UX Design: Context is Everything

2010-05-14T14:59:30Z

Well, that didn't take long, did it? My second post after a lengthy hiatus, and I end up on the front page of Daring Fireball. Clearly my talent for stirring the pot hasn't waned in the least over the past couple of years.

I'm also amused at a number of the comments on that post. It's a product of my age. Not only do I remember a time when floppy disks really were floppy, my experience with them dates back to high-school when I had the, um, pleasure of doing accounting on an old IBM work station connected to a computer housed in a semi trailer that seemed to use up half the back parking lot. Those were 12" floppy disks, and they didn't hold very much data.

But neither my age nor floppy disks address the overall point I was trying to make; a point that commenter Michael McWatters, stated very succinctly:

As in most things UX-related, there can be no immutable laws, only best practices and context-sensitive design solutions.

"UX" stands for User eXperience. It goes beyond just usability, and involves a systematic effort to understand how users feel when they use something. It's applicable outside the world of software, but it's becoming increasingly important in the software industry. In my previous post, I linked to this Wikipedia entry, which gives the ISO definition of user experience as "a person's perceptions and responses that result from the use or anticipated use of a product, system or service." You'll also see the word "affective," in the psychological sense, used to describe these feelings.

User experience is inherently subjective. Indeed, it's about as far to the subjective end of the objective-subjective spectrum as you can get. We can't measure it directly, but we can take a look at the factors that determine a user's perceptions and responses. The user's past experience, for example, is one of these factors. Another factor is what the user wants to achieve--the user's goals. Yet another factor is the user's aesthetics.

We use the word "context" to refer to the collective set of factors that determine a user's perceptions and responses to using a system, hence Michael's use of the phrase "context-sensitive design solutions."

And it's the user's context that matters, not mine or John Gruber's, or yours unless you're a user. Even then, as an individual user, your context only matters to the extent that your context shares elements of the contexts of other users. That last statement is important, because users aren't homogeneous. The "average" user is as much of a statistical fiction as is the "average" household that, at one point, had 2.5 children and 1.5 cars.

Users don't all have the same shared context. A couple of comments on my previous post help to illustrate this point.

One commenter pointed out that, for Mac users, the use of a floppy-disk icon seems to be unique to Office. Let's take that as true. However, we've already had to limit our user population to Mac users. Furthermore, given the history of Mac Office, the use of a floppy-disk icon is part of the context for existing Mac Office users--the people most likely to use newer versions of Mac Office.

Another commenter suggested doing away with the save operation altogether. We actually did that once, not with Mac Office, but with another app. We were quite surprised to see the number of users who were disturbed by their inability to figure out how to save their work. It never occurred to them that the app was saving their work as they went along.

Since applications inherently target different users, the archetypical context for one app won't be the same as that for another app. Hence, a particular design decision that makes sense in one app, e.g. using a floppy disk as the icon for a save button, wouldn't make sense in another app.

As an exercise, go back and read Apple's HIG in light of this idea of "context." Do those guidelines favor certain user contexts over others? Might there be some users for whom the target context inherent in Apple's HIG wouldn't be appropriate? Why, indeed, are they called "guidelines," and not "rules"?

I'll leave you with that thought for now. In an upcoming post, I'll talk a bit about how we break down user contexts into relatively homogeneous groups, and how that helps us prioritize the work we've done on Mac Office.

Oh, and John, if you're still paying attention, the next time someone asks you what icon they should use on a "save" button, tell them to use a piggy bank.

Rick

Currently playing in iTunes: I'd Rather Be Blind, Crippled and Crazy by The Derek Trucks Band

John Gruber Makes a Mistake

2010-05-12T02:08:02Z

Over on DaringFireball, John Gruber points out an annoyance he has with icons used for "Save". Specifically, he doesn't like the idea of using a floppy disk as the icon, and he, rather snarkily, suggests using "S-a-v-e" to mean "Save".

Couple of problems with this. First, the question is about icons, not labels. In the vast majority of cases, the label for a save button at least includes the word "save". There are, however, legitimate cases where you'd want to have an icon as well, so suggesting that developers not use any icons at all isn't really a viable choice.

Second, text in an icon violates one of the cardinal rules of localization. Once you put text in an icon, you then have to have a version of the icon for every language you want to support.

John closes his remarks by saying, "I can’t think of a single floppy-disk-for-save button anywhere in Mac OS X or iPhone OS..." Well, I can think of three: Word, PPT and Excel use a floppy disk as the icon. It's the icon we've been using for "Save" since back when having a floppy disk for that icon actually had meaning.

Now, this does raise a rather interesting question for apps that have been around the block a few times. Do you change an icon which has a rather established meaning for current users when the nature of changes in computing have stripped some of the meaning from that icon? Personally, if we were doing Mac Office for the first time today, I'd much prefer something like Mars Edit's document-into-a-folder icon. But, for an icon that has an established meaning, the "right" answer isn't obvious.

For any app that gets past version 1.0, this general question is a constant issue. We face it so often, that we've expanded user experience (UX) as an engineering discipline within MacBU. We've made it coequal with the development, testing and program management disciplines, and are increasingly incorporating a variety of UX design techniques, not just usability testing, into our development process.

As I find time, I hope to be able to talk a bit more about what this means, but, if you're interested, the Wikipedia entry isn't a bad place to start.

None of this, though, actually highlight's John Gruber's mistake. What was that mistake? Never get snarky in a blog post that includes the phrase, "I can't think of."

Rick

Currently playing in iTunes: It's Only A Paper Moon by The Tierney Sutton Band

Am I Back?

2010-05-08T14:07:57Z

OK, so Nadyne, after posting a nice article about using PowerPoint on Mac Mojo, spilled the beans, so I suppose I should say something. Though, the fact that I wanted to title a blog post with, "Use the Right Tool for the Job and You won't become One," is probably more than ample evidence that I should not be blogging.

The problem with blogging is really finding something to talk about. Well, there is a lot that I could talk about, but there's this fine print in my employment contract that leaves quite a bit of what I'm working on off the table.

For example, I could talk about the travails of transitioning from Carbon to Cocoa, but it doesn't take a rocket scientist to put two and two together to figure out that Microsoft is moving Mac Office to Cocoa. And, of course, the more details I discuss, the more people can figure out just how far we have progressed along that transition.

I see comments on various blog posts where people ask or this or ask for that, and I want to say, "Guess What!" But, I can't! And it's horribly frustrating.

So, am I back? I don't know. I'm contemplating. In the mean time, Red Sweater has released Mars Edit 3.0. So, I'm taking it for a spin. Now, if I can only remember where "Currently Playing in iTunes" is. Ah, yes...

Rick

Currently playing in iTunes: Change It by Stevie Ray Vaughan

Craig's Bug

2008-02-01T05:01:00Z

One of the things I love about this job is tracking downinteresting bugs. It’s like readinga good who-done-it, complete with plot twists, multiple potential suspects and a fascinating array of characters. Late last September, Craig Eisler submitted a bug that had all of these elements.

Now, when your general manager submits a bug, you don’t necessarily have to get on it right away. But, it’s not a good idea to let it linger for too long. So, after this bug had been on the list for about a week or so, I decided it was time to figure out what was up.

The bug involved a document Craig had been editing with revision marking turned on. He’d made some changes to the document, saved it, quit Word and, when he opened the document back up, some of the spaces between words were missing.

With a bug like this, the first thing I do is open it up in Win Word. If the problem appears there, then there’s a strong likelihood that the bug is in the code that writes the file. If the bug doesn’t appear in Win Word, then I know to start looking at the code that reads files. In this case, the problem appeared in Win Word, so my first suspect is going to be somewhere in the save code.

Also, the missing spaces seemed to be in or around areas of the document where revisions had been made. So, the first suspect was somewhere in the code that writes revisions. I created a document, added some text, turned on revisions made some changes and saved the file stepping through the code that handles revision marking.

Nothing. Everystep along the way, everything was happy. The code was writing all the appropriate XML tags, and none of the text was missing. Of course those two sentences summarize about two-three hours of sleuthing, after which I was able to exclude the revision marking save code as a suspect.

Well, maybe it’s something that only appears to be related to revision marking. Let’s take two files, one that exhibits the problem and one that doesn’t, and compare the contents (much easier to do now that the document content is XML).

Again, nothing. Other than a few gratuitous differences (revision save ID’s, for example, which are uniquely generated every time new text is saved in a document), everything in and around the missing spaces was identical. Another couple of hours spent cracking open various documents and comparing the XML, and I still haven’t a clue whothe real culprit is.

Well, but, if the documents are identical, maybe the problem happens when we read the file. So, I set a breakpoint on the code that handles runs of text from the XML parser, and, sure enough, our “characters” callback wasn’t getting called for just the missing spaces. Hm… Progress.

About another hour or so, I had tracked it down to some general XML parsing code we’d ported from Win Office. One of the problems with writing filing code that’s intended to handle future situations is that, when you write the code, the future hasn’t arrived yet. Well, for Win Office, Mac Office represented the future, and some of the stuff we’d added exposed a subtle bug in the code we’d ported (note: the problem has been fixed in WinOffice before Mac Office shipped, so people shouldn’t run into this at all).

By the time I had finished all of this, implemented a fix and verified the fix, it was about 1:30 in the morning. When I get engrossed in a good mystery, I sometimes find it difficult to put the book down. Same thing goes with good mystery bugs.

And, the bug being a good mystery bug that geeks like Craig and I appreciate, I sent off an e-mail to Craig outlining the basic nature of the bug and the fix (which turned out to be just a couple lines of code—this is almost always the case with a good mystery bug). This being in the middle of the FIFA Women’s World Cup, I ended the mail by saying that I was going to go home, drink some coffee, and stay up to catch the USA match (I forget who the opponent was).

The next day, I got a response from Craig with some questions about the bug. I replied to Craig’s questions and, at the end of the e-mail, lamented over the fact that, after all that effort and all that coffee to stay up to watch a soccer match, our local cable company saw fit to pre-empt the last 30 minutes of the match with a taped question-and-answer program starring Mike Holmgren, the Seahawks coach.

For a born-in-Green-Bay, prick-me-and-I-bleed-green-and-gold, Packers fan like me, having a soccer match for which I’d stayed up all night to be able to watch be preempted by Mike Holmgren is seriously rubbing salt into the wound, and I conveyed my displeasure at this to Craig by saying that the only reason we still have a working television in the house is the fact that there were people asleep in the house at that time.

What ensued was a series of e-mails between Craig and I with a dual thread about the bug he’d reported and my television set. His response to my previous e-mail was to suggest that I should have taken the TV outside and smashed it there. Wake up the neighbors instead of the kids, and I get to vent my hostilities.

In my reply, I explained that this was not an option giventhe size (36”) and weight (over 260 lbs) of my TV set, to which Craig replied, “A CRT!? How quaint! Do you get slivers when you go to the bathroom after watching that TV?”

Having an uber-geek general manager is cool. You get great bug reports, and he likes to hear about the nature of the bug and the fix. Just be a little careful when you talk about the technology around your house.

Rick

Currently playing in iTunes: New World Blues by Gov't Mule

What the Hell is That?

2008-01-22T01:54:04Z

Seattle. Middle of January. Nothing in the sky but this huge, yellow thing. Looking at it hurts your eyes. In that context, read this transcript.

"Don't put your lips on it!"

Rick

Currently playing in iTunes: Afternoon by the Pat Metheny Group

Trading Fours

2008-01-11T22:56:44Z

I've had quite a bit of positive feedback on my last post, so I thought I'd do another musical post.

"Trading fours," or "trading eights," is a jazz term that refers to one or more soloists taking turns in a solo. The idea is for each musician to pick up where the previous one left off, as if the alternating musicians are really playing the same solo. It takes an enormous amount of skill and practice to pull this thing off.

Below is a video from a 1989 concert involving members of Dizzy Gillespie's "United Nations Orchestra"--an all-star group of musicians who are, today, very prominent in Latin jazz. This particular number is a medley of Seresta, a duet between clarinetist Paquito D'Rivera and pianist Danilo Perez, that segues into a full orchestra performance of Samba for Carmen.

The latter opens with long solos by trombonist Slide Hampton and trumpeter Claudio Roditi, but closes with a round of trading fours where D'Rivera, Hampton and Roditi work the idea to perfection.

As something of a side note, it wasn't until I'd seen this video that I realized that D'Rivera had put down the clarinet and picked up his alto sax for the round of trading fours--such is the mastery of the instrument's range that D'Rivera exhibits in this piece.

The Music of Derek Trucks

2008-01-08T23:49:45Z

It's mid afternoon Saturday, July 27, 2007. The scene is Toyota Park, suburban Chicago, Illinois, home of some minor league soccer team. We're between acts during the Crossroads Guitar Festival, and Bill Murray walks out to introduce the next act. A few folks in the audience have heard this guy play, and are on the edge just itching to hear his band.

"This is a guy who works two jobs," Murray begins. "He works days with this fellow, Eric Clapton. Night time, he masquerades and plays for these fellows called the Allman Brothers. He's got a beautiful wife who can sing like a bird, he's come all the way to you from Florida, he's gonna rip this place apart and do a lot of damage to you. Let's [unintelligble] The Darryl Trucks Band!"

What?! Did he just say, "Darryl?!" Aw crap! Derek Trucks is about to perform with his own band in a venue that's likely to result in his widest exposure yet, and Bill Murray screws up his name. The irony is bitter. If there's anyone in music today who's music deserves far more notice than it's getting, Derek Trucks is it.

There's a lot that can be said about Derek Trucks himself. Most of it's already been said. The nephew of Allman Brothers charter member Butch Trucks, he was a child prodigy. Currently 28 years old, he's already had a professional career that's well into its second decade. Derek, along with Warren Haynes and Oteil Burbridge, has been an integral force in the resurgence of the Allman Brothers band earlier this decade. He's toured with Eric Clapton, and, while many went to see the original guitar God himself, many came way talking about the tall, baby-faced kid with the long blonde pony-tail.

But, it's the music that matters. And Derek is doing something insanely new and unique, and worthy of in-depth study and review.

To illustrate this point, I'm going to deconstruct the various elements of the first song that Derek Trucks and his band played at the Crossroads Festival. I've embedded the You Tube video below. RSS folks can click here.

The raw material he's working with is a couple of songs, Sahib Teri Bandi and Maki Madni, written by Nusrat Fateh Ali Khan. This is Punjabi folk music, known as Qawwali, in the Islamic, Sufi tradition, and is generally performed by large groups in pursuit of Sufi mystical experience.

A Qawwali song follows a general pattern. A lead singer begins with a subtle, improvised introduction that leads into a "raga," which conveys the melodic theme of the song. In this case, the raga is six bars. The raga is repeated as others join in, and this builds in a crescendo as singers emphatically increase the intensity of their effort, until the performance comes to an abrupt end.

There are several things worth noting about this performance. The first is that Derek's own performance of the song is done with a Gibson SG '61 Reissue plugged straight into a 60's vintage Fender Reverb amp. There are no pedals, and no effects. Just Derek's slide technique with which he mimics the sound of a Qawwali singer's voice right down to the micro-tonal variations. At times, you can almost hear the plaintive wail of the Sufi supplicant in the midst of a mystical experience--as if Trucks, himself, is having his own mystical experience.

The second notable aspect of the performance is that, while the band loosely follows the Qawwali pattern, the execution more closely follows a tradition in Jazz music wherein a familiar melody is purloined as a vehicle for improvisation. On a fundamental level, this is a jazz performance, even though the music isn't what we'd generally consider to be jazz.

This point is made even more clear following the flute solo when the band transitions into the Maki-Madni portion of the song. This digression incorporates an additional element of a raga, in that the band builds to a crescendo before returning to the Sahib Teri Bandi theme. This melding of two similar, yet complimentary, melodies into one song is, again, a traditional element of jazz music.

A third notable aspect of this performance is that, at 6 minutes and 35 seconds, it is shortened considerably from the usual performance which is often more than twice that long. Even the studio version released on the Songlines album is nearly 10 minutes long. The usual performance is even more free and less structured than this performance, and incorporates a wider array of improvisation.

The last, and perhaps most remarkable, aspect of the performance I want to point out is how taught the improvisations are. This isn't a free-rambling, almost aimlessly wandering, form of improvisation that's commonplace for jam bands like, say, The Grateful Dead or Widespread Panic. The band exercises a strict discipline that also involves a subtle interplay amongst all the musicians producing a cohesive whole. While the song is used as a vehicle for improvisation, the improvisation itself is kept within, and contributes to, the overall aim and effect of the song itself.

This last element is really more something out of the blues tradition than the jazz tradition, which is largely why the end result isn't really jazz per se, though the performance also lacks many of the complex harmonic interactions that would also move it more fully into the jazz realm.

This performance, in overall effect, is typical of what Derek Trucks is trying to achieve musically, but that effect is also why Trucks' music remains relatively obscure. It's not jazz, so you won't hear it on jazz radio stations. It's certainly not pop, but it also doesn't fall into any other convenient categories like blues, funk, gospel, rock or r&b. His music incorporates and interweaves, to varying degrees at different times, elements of all of these forms of music in such a way as to create an entirely new category all its own.

By any objective standard, this is musical art of the highest order. But I fear for its obscurity. A good part of the greatness of other musical pioneers is that they blazed a path that others were able to follow. That Trucks is blazing a new musical path is indisputable. In blazing his particular path, however, Trucks and his compatriots bring such an amazing level of virtuosity to the table as to lead me to wonder whether or not anyone will be able to follow.

Perhaps it's too soon to tell, and perhaps I'm underestimating the virtuosity that other musicians are able to bring to the table. Or, perhaps I'm overestimating the ability of Trucks' music to inspire other musicians to follow. But there is one thing I find disturbing. I've assiduously searched the web looking for a similar analysis of his music to the one I've given here, and I've not found any. I'd expect someone other than a relatively obscure software developer to have already written something like this.

So, the question is, when Bill Murray messed up Derek's name, was it an omen? Or was it merely a bump along the way? I hope it's the latter, but I guess it's really up to us to decide. Isn't it?

Rick

Currently playing in iTunes: Desdemona by the Allman Brothers Band

Finding My Voice Again

2008-01-08T02:19:08Z

Wow. What a stretch. We shipped the bits for Office 2008 off to manufacturing back in December, and that very day I was still in the office until 10:00 that night doing some prep work for the next release of Office. Having been head down in Office 2008 for so long and so hard, to just flip the switch from ship-mode to down time would have been like jamming the car into reverse while driving at highway speed.

Mac Office 2008 has been my 8th major release since I started working here, and this release is the first time I haven't been able to flip that switch--the first time I've had to ease my way back out of that intensity that permeates what we generally refer to as "ship-mode."

This has affected my blogging, and I've spent some thinking about the direction to take this blog in the future--an introspective exploration into what I want to say, even to the point of figuring out if I have anything left to say.

I've always been a sporadic blogger. To a certain extent, that comes with the territory of being a part-time blogger with a job that alternates between periods of high intensity and periods of reflective down time. But I also find it exceedingly difficult to just sit down and blog about something for the sake of putting a post up on the blog. I tend to not say anything unless I think something needs to be said.

So, I'm trying to ease my way back into blogging, and I'm looking for things that need to be said. As I do that, I'll probably not talk all that much about Word or Office. If I do, those posts will likely end up on Mac Mojo. This space will get more personal. There are a few things I have in the pipeline, and I'll get to them as I can.

In the mean time, I'll be down at Mac World next week doing at least a stint or two in the blogger lounge. Who knows, I might get more of my voice back then.

Rick

Now playing in iTunes: Hercules by the Derek Trucks Band

The OOF Infinite Loop

2007-07-27T22:42:00Z

I'm surprised that I haven't hit this before at Microsoft, but I actually hit an OOF infinite loop today.

For those who don't know, "OOF" is an acronym that refers to someone being out of the office. The Exchange team gives a nice run-down on the history the term here.

When people are out of the office, it's common to set up an auto-reply e-mail message providing contact information, and these messages often refer the sender to someone else for urgent issues. By now, you've probably guessed what an OOF infinite loop is: person A has an auto-reply OOF message that says to contact person B, and person B has an auto-reply OOF message that says to contact person A.

Of course, it doesn't have to be that simple. There really is no limit to the number of people who can be involved in one of these infinite loops. Which gives me an idea for what to do right after we ship Mac Office...

Rick

Currently Playing in iTunes: Will it Go Round in Circles by Billy Preston

The GM Shuffle

2007-06-09T20:21:00Z

By now you’ve read the news. MacBU has a new general manager. I only found out about this via e-mail on Thursday, and, yesterday, I got a chance to meet Craig. I’ll get to my initial impressions of Craig in a bit, but I also want to talk a bit about Roz Ho.

Before I talk about Roz, I should point out that, in Microsoft terms, I’m a wierdo. That’s not just because I work on Mac software. No, I’m an anomoly in a very different sense. In a couple of weeks, I’ll mark my 17th anniversary of working on various versions of Word, all but one of them for the Macintosh. That’s so rare, that people have suggested they make a place for me somewhere in the Microsoft Museum (just what I want: to become a museum piece).

Microsoft is pretty big on career advancement. It’s not a “move up or move out” kind of thing. It’s more of a do something cool and good here, you get to do something cool and good somewhere else. That’s why I’m such a freak. I keep managing to advance my career without having to move on to something completely different.

For a general manager, this career advancement thing becomes something of a problem. Opportunities to climb the management ladder start getting really thin. So, how do you reward a GM for doing a great job? You find a different kind of business for that GM to run—something that might involve cool new technologies, or something that requires a different approach to management, or a host of other kinds of chances to do something, well, different.

So, earlier this year, a very interesting and exciting opportunity opened up for Roz to advance her career. This kind of thing always brings out mixed emotions in me. I hate losing someone as good as Roz, but I’m also proud that someone from MacBU is being recognized for doing a great job. I’m very excited for Roz in her new role, and I think it will be good for both her and for Microsoft.

Roz became the general manager of MacBU back in December of 2002. She oversaw the release of what has been the most successful version of Mac Office ever. Her more than four years as general manager covers nearly half of Mac BU’s ten year existence. Of the three general manager’s I’ve worked with until now, I think Roz has been the best, and she’s certainly been the most pleasant to work with (which is, by no means, a knock on either Ben Waldman or Kevin Browne).

I say all of this to express my personal gratitude to Roz for what she’s done for MacBU, for the Macintosh in general, and for me personally. I’ll miss you Roz, though I still think you messed up the Connectix deal for not getting all of us our own “Switch/Switch Back” t-shirts.

So, what about Craig Eisler? As I said, I only found out about this on Thursday, but I see that he’s a blogger and enough of an Apple enthusiast as to have 5 Apple TV’s, 3 iMacs, a Mac Mini, a Mac Cube and a PowerMac G4. Oh, and, ah, I think there’s a video iPod in the mix as well. So far, so good.

I did a bit of poking around the internet, and found quite a bit of information about Craig, like he was once a competitive power lifter, and he once, quite by accident, managed to bring down the entire Canadian banking system. Four times. In one day.

UWTV did this interview back in April of 2004. It’s a bit long, but very interesting.

On Friday, we had a bit of a get-together out on the patio outside our building, and I had a chance to chat with Craig. If I had to choose a single word to describe my first impressions, it would be “exuberant”—almost, but not quite, effusive. We swapped a few stories. Someone mentioned my suggestion box, and he said that he’d read my blog and thought the suggestion box was a scream.

So, he gets the Mac, he gets Microsoft and he understands that running a successful business is measured in terms of the value of the product to users and customers. Best of all, he gets my twisted sense of humor. I’ll have to try out some of the Canadian jokes my daughter brings back from school. C-eh? N-eh? D-eh?

Rick

Currently playing in iTunes: You da Mann, by the Derek Trucks Band

Your Text Here

2007-05-03T00:48:00Z

On one of the many informational, internal e-mail lists of which I am a member, someone, today, posted one of those ubiquitous "How-Do-I" requests where the solution involves some form of "your text here".

Someone replied with a nice and quick answer to the original question where the "your text here" phrase was "booga booga," and the person who sent the original request replied:

Perfect. Elegant in its simplicity. I might just keep the “booga booga” as well.

I'ts one of those things you just have to preserve for posterity, hence this post.

Rick

Currently playing in iTunes: Ain't Life Grand, by Widespread Panic

There Comes a Time

2007-04-05T04:48:00Z

In every project, there's a point where you have to stop tweaking this and touching up that little bit of behavior and focus on just fixing bugs. If you don't, then you never ship. Nadyne gave some of the details over on mac mojo.

Well, we're getting close to that time with Mac Office 12. In honor of nearing such a milestone, I prepared something for our program management friends. These are the folks who are responsible for designing how the various features are supposed to behave from the user's point of view. It's a suggestion box, and it looks like this:

Mind you, this suggestion box is for PGM use only. Think of it as my way of saying that now is the time for us to shut up and listen to the real users who are trying out the product during the private beta.

Enough fun. I need to get back to fixing bugs.

Rick

Currently playing in iTunes: Beautifully Broken by Gov't Mule (w/ George Porter Jr.)

John Madden?

2007-01-17T06:50:00Z

Kinda makes ya wonder...

Rick

Currently playing in iTunes: Boom! Boom! by John Lee Hooker

Lounging Around at MacWorld

2007-01-11T02:18:00Z

MacWorld always has its surprises, but some of them are quite personal. For me, the surprise was the discovery, at 5:20 this morning, that a previous occupant of my hotel room had set the alarm-clock but hadn't turned off the alarm. I've been told by others that my failure to check the alarm clock when I checked in is a sign that I don't attend trade shows often enough. Actually, I think I probably attend too many as it is.

Whatever the case, thanks to this inconsiderate person, the Word file format converter is now about four hours closer to being done than it would have been had said person learned how to turn the alarm clock off. I expect, however, that those hours will revert back during an upcoming, afternoon nap.

I got a chance to chat with John Welch today, and I'm happy to inform you all that he appears to be in much better shape than he did yesterday. And, you know, things were so busy in the Blogger Lounge, that I forgot to ask John if he's been able to check out Songlines by the Derek Trucks Band.

I've yet to get any opportunity to personally wish Shawn and Lesa a happy wedding anniversary, so I will here. Happy anniversary, Shawn and Lesa. In one of those cute MacWorld stories, Shawn and Lesa met at MacWorld three years ago. Two years ago, Shawn proposed to Lesa at MacWorld, and, last year, they got married at MacWorld. I think we should petition the event sponsors to rename MacWorld the Shawn and Lesa Wedding Anniversary Celebration.

Shawn does have a lot of pictures from the show, and a couple of cool interviews with Chuck Leavell and Bob Weir. It seems MacWorld always has at least one musician I admire roaming the floor, but I still think my personal best was getting Herbie Hancock's autograph in the Microsoft booth a few years back.

Lastly, I almost got a chance to chat with Andy Ihnatko. I still remember Andy raking me over the coals about Mac Word 6. I hadn't realized how much shorter than me Andy is, and that's saying quite a lot, but I still think Andy is much taller in stature. He's still one of the best writers in the Mac commentary field.

That's about all from the Blogger Lounge. I need to bag some z's before it's time to spend an evening with the Mac MVP's.

Rick

Currently playing in iTunes: Midnight Pass by Sea Level

BBEdit 8.5

2006-12-15T01:14:00Z

MacWorld has a decent review of BBEdit 8.5, but it fails to mention a new feature that is of particular use to programmers.

One of the features of CodeWarrior that I'd missed was the syntax highlighting that the IDE applied to symbols that were defined within the project. In fact, I hadn't realized just how much I'd come to rely on that feature when writing new code until I started working with BBEdit and XCode. I had a sudden, new-found paranoia about whether or not I'd typed in a symbol name correctly.

Well, if you use ctags in association with BBEdit, BBEdit will apply syntax highlighting to any symbol that's in the tags file that it would use for the "Find Definition" command on the Search menu.

Rick

Currently playing in iTunes: The Rainy Season by Marc Cohn

Open XML Converters for Mac Office

2006-12-07T21:04:00Z

There’s been a bit of flak about the Office Open XML file format converters for Mac Office. Sheridan posted an update on MacMojo, and Schwieb weighed in regarding some of the comments that people have made. There’s quite a bit of speculation gong on, and not a whole lot of information, so I’m going to try to dispel some of the fog.

This discussion centers on Word, because I’m a Word developer, but the general ideas hold for all three of the affected Office applications. The most significant difference between Word and the rest of the suite is that Word has a converter API. There’s a WinWord converter SDK that’s downloadable from the Microsoft support web site. While there are some subtle differences (FSRef’s instead of file paths, for example), the overall API is the same for Mac Word. Of particular importance is the fact that the lingua franca for converting Word files formats is RTF.

So, in order to write a converter for Word, you need two things: 1) a component that reads and writes the external file format; and 2) a component that generates and parses RTF. Also, because of the hierarchical structure of XML, you need to have some form of intermediate representation of the file.

Let’s put our Win Word hat on for a second, go back in time about two years, and think about how we might do this. Well, by the time Win Office ships, we’ll have a software component that satisfies all of those needs: Word itself, or the new version of Word, to be precise. So, one, very efficient, way to implement that converter is to refactor the UI out of Word 12, repackage the result up with any other necessary components, and write a wrapper around all of it that exposes the API that the older version of Word expects converters to implement.

Do that, and you can ship the converters the same time you ship Office. The big upside of this idea is that you can really narrow down the scope of testing you do on the converter itself, because you’ve already tested both the RTF and the Open XML components by testing Word itself. So, you gain leverage from both a development and a testing perspective.

Now, let’s put our Mac Word hat back on, and think of what our options are given the reasoning I’ve stated above. You can’t really ask the Win Office team to toss their idea in the trash just so you can work on the converters in tandem. Well, you can, but one would have to be very optimistic to expect more than a polite, “Sorry.” I can’t think of a clearer example of the tail trying to wag the dog.

Instead of following in Win Word’s footsteps, how about we spin off a separate development team to work on the converters separately from Word itself? I've read suggestions made by some that writing converters from scratch could have been done in a relatively (in some cases ridiculously) short amount of time. So, let's test that idea by doing some back-of-the envelope calculations. You can check these numbers for yourself by downloading the reference XML schemas and performing some searches through the .xsd files.

First, when could we have realistically started working on this? Well, not before Office 2004 shipped in April of 2004, so, ignoring the availability of specifications for the new format, let's assume that we began work on this roughly two years ago. The final draft of the spec wasn't submitted to the ECMA until this past October, so in terms of actually having a spec to write to, 24 months is extremely optimistic for the time period available.

How big is the task? Word, alone, has more than 1100 individual XML elements that need to be processed. We do this processing by writing something called a "handler", and each one of these elements needs a handler.

Now, some of these elements are more complex than others. A single, user-defined document property isn't very complex. A paragraph, or a document section, can be very complex. For some of these handlers, one developer can whip out two or three a day. Some of the other handlers will take a single developer up to an entire month to complete. Trying to get more than one developer working on the same handler at the same time ends up being very counter-productive. So, one handler per developer, and, on average, it's fair to assume productivity of one handler per dev per day.

At that rate, a team of 5 developers will implement 25 handlers a week, which means that we'd have all the XML handlers written in 44 weeks. Well, a little more than that, because I've rounded the number of elements down to the nearest 100. Nevertheless, we’ve taken a little less than a year to get the converters reading the new file format. We still aren't writing the new file format, we have the RTF side of things to worry about, which is actually more complex than the XML side, and I’ve completely left out all of the design and coding for the intermediate representation of the file. The intermediate representation, itself, is at least 6 to 8 months worth of work.

In other words, we're almost halfway through the schedule, with less than a quarter of the development work done. You want more developers? I don't have more developers. This is just for Word. We need additional teams for Excel and PowerPoint. People want Universal Binaries of Mac Office in their hands, they’re adding new features to Win Office 12 that Mac Office 2004 won’t understand, Apple has a new HIView architecture that requires some re-architecting of parts of Mac Office, and none of this work adds a single new feature to Mac Office.

More importantly, we’ve also run out of time to test the converters. Had we started writing converters from scratch, by the time we had something fully tested and ready for public consumption, it would have taken us longer than it has taken us on the route we’ve chosen, in no small part due to the fact that the current route we’ve chosen allows us to leverage almost all of the development work of the Win Office team.

The only reasonable choice for Mac Word has been to follow in Win Word’s footsteps. For those of you who attended the last Mac BU customer council meeting in Redmond and were wondering what I was doing while sitting in the back corner, now you know. I was busy refactoring Mac Word so that Mac Word 12 could, eventually, become the converter for the new file formats.

The big win for this strategy is that we get to do all of the things that customers are asking us to do with the next version of Mac Office: Universal Binaries, support for most of the new data types in Win Office 12, re-architecting the UI to take advantage of composited HIViews and add some compelling new features.

Lastly, can we port the Win Word converter? Well, actually, in a way, porting the Win Word converter is exactly what we have been doing, but we’re still faced with having to wait until Win Word ships before we have the final source code to merge into what we’ve already ported. Once that merge is done, then we still have to go through several months’ worth of testing and bug fixing before they’re ready for public use.

And that is precisely why there’s a delta between Win Office 2007 shipping and the full availability of converters for Mac Office.

Update: I’d like to clear up some things about what I said earlier. My back-of-the-envelope estimates included a lot more work than just supporting Open XML in Mac Office. Open XML is the easy part. It included the work required to generate RTF in both directions and to implement tools for developers.

If we had to add support for Open XML to Mac Word 12 without being able to port code from Win Word, the read/write estimates shrinks down to about 8.5 man/years (44 weeks x 5 devs x 2 for read+write). As I recall, this about half of what it took to add HTML support to Word: 10 or so devs over a release cycle of 2 years. Doing the work for PPT and Excel isn’t strictly a multiple of Word, because about 30% of the XML elements are shared between the three apps. So, for all of Mac Office, I’d estimate it would take a total of about 5 devs over the release cycle to add full Open XML support starting from scratch, as part of the larger project.

Rick

Currently playing in iTunes: Time Loves a Hero by Little Feat

Muddy Mojo Waters

2006-08-28T23:26:00Z

Somewhere in the backroads of Issaquena County, Mississippi, along the banks of the Mississippi river, McKinley Morganfield was born. Likely due to his early life so close to the Mississippi river, McKinley later came to be known as Muddy Waters. The father of Chicago blues. The man most responsible for introducing the electric guitar into the genre. At one ponint in history, the terms "Electric blues" and "Chicago blues" were synonymous.

Talking about Muddy Waters, Eric Clapton once said, "His music changed my life, and whether you know it or not, and like it or not, it probably changed yours too." The very roots of Rock-n-Roll itself traces directly back to the music of Muddy Waters. His influence is comparable to, nay even surpasses, that of say Charlier Parker or Dizzy Gillespie on Jazz. So wide is Muddy Waters' influence that a long standing British combo and a well-known monthly magazine, as well as a Bob Dylan tribute, took their names from the title of one of his songs, "Rollin' Stone."

But I'm not going to talk about Muddy Waters' music per se. Rather, Muddy Waters is known for another contribution to American culture. More than anyone else, Muddy Waters is responsible for the word "mojo" having made its way into our lexicon.

I say that with some care. His contribution derived not from his skill as a lyricist, but the strength of his performances. Nonetheless, the lyrics of many songs Waters' made popular were suffused with references to African folk magic. The song "Hoochie Coochie Man," written by Waters' bassist, Willie Dixon, is typical:

I got the black cat bone, I got a mojo tooth
I got the John the Conqueror root, I'm gonna mess with you

Another classic is Preston Foster's, "I've Got My Mojo Working," which opens with the line, "I got my mojo working, but it just don't work on you."

So, back on March 29, 2005, Dave Winer was in some kind of Muddy Waters, mojo mood mostly involving Yahoo 360. Coincidentally, Betsy Aoki shared her Got Dot Net Blues with us, which prompted me to add this comment.

Fastfoward to a couple of weeks ago in a meeting where we'd invited Betsy to share some thoughts on running our Mac Office Team blog. We'd had a name for it, but hadn't really settled on that name. During the course of the discussion with Betsy, however, she used the phrase, "Your Mac mojo," in a rather off-handed, throw-away kind of fashion. The blog's name itself wasn't the topic of disussion, but, in one of those unpredictable, synergistic moments, the name stuck. So, we now have our Mac Mojo woikin'.

Did my comment have anything to do with Betsy's use of the phrase "Mac mojo" during our meeting? I haven't a clue. But, hey, I'm allowed a certain amount of room for dellusion over such things. Whatever the case, I hope everyone enjoys the new team blog. There are some pretty interestings posts in the queue.

Rick

Currently playing in iTunes: Hoochie Coochie Man by Eric Claption

Claiming Technorati

2006-08-25T09:42:00Z

My profile is Technorati Profile. Nothing to see. Move along, now. Rick

Virtual PC and Visual Basic

2006-08-09T21:01:00Z

Scene: A fly-over view of Microsoft's campus focuses in on the building that houses Mac BU. The camera "flight" enters one of the offices through a window. During the fly-over, a voice-over says:

New 3.0 GHz Mac Pro: $3,599.00
Two 23" Apple Cinema HD Displays: $1998.00
Office space: $350.00/mo
Competent developer...

You get the picture. For years, one of our program managers has been coming into my office with feature questions that invariably begin with, "Is it possible to...?" Well, of course it's possible. Anything's possible if you give me enough time.

So, earlier this week, we announced that we're not going to ship a Universal version of Virtual PC and that we're going to discontinue support for Visual Basic for Applications. The latter is particularly painful for a number of our customers, and people are quite understandably livid about it.

While Erik Schwiebert has posted a sound explanation of the technical hurdles involved, there remains the more general question of finding the resources capable of doing the work required to overcome those hurdles. Many people who are not at all familiar with the exigencies of software development look at Microsoft's balance sheet, and the maxim that anything's possible in this industry, and wonder whether or not we're pulling their legs. They don't understand that the constraining resource isn't money. It's people.

There are two pieces in the people puzzle. The first is head count, and, for various reasons, Mac BU has always operated with open head count. "Open head count," means having a budgeted slot to hire someone, but not having an actual employee in that budgeted slot. Due to the turn-over of people who move on to new challenges, and the difficulty of finding candidates who we believe won't write something worthy of being posted to The Daily WTF, despite the steady stream we keep interviewing, I don't see this condition changing in the near future.

The fact that we've always had open head count points out a subtle aspect of the budgeting issue. Picture yourself being Roz Ho's boss. She comes to you asking for an increased budget for more head count. You look at the existing budget, and see that there are open head count. Your question is likely to be, "Why are you asking for more head count when you haven't filled the head count you already have?" The point: the people resource issue isn't a budgeting problem.

The second part of the people issue is a bit more difficult to understand when you haven't spent a great deal of time trying to ship software in the real world, but there is a point where adding new people to a project results in diminishing returns. Fred Brooks refers to this as the Mythical Man Month. If you ask me whether Mac BU is still on the increasing side of the curve or if we've come close to the diminishing side, I'd honestly have to say that I really don't know. This is one of those cases where you don't really know you've hit the point of diminishing returns until you get there, and, even then, recognizing that that you have is exceedingly difficult. There are a number of variables that affect the time it takes to complete a software project, and it's very difficult to account for them all.

However, Schwieb's estimate of two or more years to rework VB/VBA isn't far off the mark, and it assumes that we put every resource onto that project that we can possibly put on it. That estimate also takes into account the issue of dependencies. This part of the Mythical Man Month isn't all that well discussed in the Wikipedia article linked above, but it's one of the more important problems we face. The number of people you can effectively put on a project is determined by the number of discrete tasks into which the project can be broken down and by the extent to which those discrete tasks depend on the completion of other tasks.

Consider the VBA execution engine that Schwieb mentioned. One might be tempted to take each opcode, and turn that into a discrete task to be worked on by an individual developer. Unfortunately, that kind of approach will lead to less coherence in the overall project. Are there any common elements to certain subsets of the full set of opcodes? If there are, and we have one developer per opcode, then there's a high probability we'll have a large number of subtly different implementations of these common elements. The more discrete tasks into which you break up a project, the greater the logistical difficulty of integrating each of those discrete tasks into a coherent whole.

Now, I've read a number of suggestions that people have made: take a Ruby on Rails approach, figure out a way to use PowerPC/CFM VBA running under Rosetta, and a few others I can't recall off the top of my head. There are ideas we'd explored that I haven't seen anyone suggest. I can't think of any one of them that would not have involved more work than working with the design parameters of the current VBA implementation--not the least of which is the fact that all of the applications implement their object models using the OLE Automation, dual-dispatch/type library approach. One has to be very careful with such ideas, because there are a number of hidden gotcha's that are very difficult to accurately assess.

So, could we have done something about VB/VBA? Certainly, if we'd had enough time. Do we make those users who really don't care about VB/VBA wait several years before we ship a Universal Binary version of Mac Office? At some point, the tail starts to wag the dog.

But that does not mean we are unaware of the pain this will cause to a significant number of users. If you think we are not aware of that pain, consider this. David Weiss can give you a better number on this, but our testing methodology has always made extensive use of scripts for automated tests. Not just a couple of scripts, but thousands of scripts per Office application. At one point, all of those scripts were written in VB/VBA. In order to carry that testing effort forward into the era of Universal Binaries, every single one of those scripts had to be rewritten in AppleScript. I don't think it's even a remote exaggeration to say that our use of VB/VBA was at least a couple orders of magnitude greater than even our most automated customers. Do we know your pain? You bet we do.

Rick

Currently playing in iTunes: Feel So Bad by The Derek Trucks Band

Opportunity Cost

2006-06-23T06:43:00Z

Back when I started blogging, I had a go-around with Pierre Igot. I'm not going to rehash it, but I think the best summary of the entire affair can be found here.

During that discussion, I made the mistake of bringing up the concept of "opportunity cost." The mistake wasn't so much that the concept didn't apply to the discussion. Rather, my mistake was in believing that Pierre and some of the other folks in his echo chamber would understand what I was talking about.

So, from time to time, one of them tries to mock me by throwing the phrase into a discussion somewhere. The most recent instance is in a comment made by someone named Warren Beck, on Eric Schwiebert's recent post explaining his take off on J. Geils' Love Stinks.

Now, I suppose I could take the time to explain "opportunity cost" to these guys, but I can also spend that time playing a game with my daughter, or reading Dick Davis' recent translation of Abu'l-Qasim Firdawsi's Shahnameh: The Persian Book of Kings, or watching the latest episode of CSI. Better yet, rather than explaining to these guys why I might be inclined to fix someone else's problems before I get around to fixing theirs, I can spend that time actually fixing bugs.

Now, I'll bet that at least one of these guys will offer a comment complaining about how we place profits over fixing bugs, thereby demonstrating that they really don't get it. If they do, I will most certainly approve their comments. Do you think any one of them will stop to ask themselves why I might be inclined to approve such a comment?

Do you think I might be allowed to coin the word "egonorant"? (My daughter suggested that I give the latin term for this: ego rectalitis. That's where the head swells, and it gets stuck.)

By the way, I should point out that none of this has any bearing on whether or not we, at MacBU, pay any attention to Pierre's bug reports. In fact we do. I've even given him credit for his assistance in helping to track down a bug.

Rick

Currently playing in iTunes: Ain't Wastin' Time No More by The Allman Brothers Band

Michael Bartosh Memorial Scholarship

2006-06-17T04:42:29Z

Those of you who knew, or knew of, Michael Bartosh, might want to check this out. John Welch, over at bynkii.com is pretty passionate about it.

Currently playing in iTunes: Fallen Down by Gov't Mule