30 May 2006

General Theory of Design

I was catching up on some of the blogs I try to read and I found this fantastic definition of design by Brian Sooy:

"Design consists of creating things for clients who may not know what they want, until they see what you've done, then they know exactly what they want, but it's not what you did."

This is so true. As I see it, the only way around this is to ship as frequently as possible. The folks over at 37 Signals provided the more visual representations both above and below.

27 May 2006

What's Temporary is Permanent

When you code you often have to make a decision to either hack together a temporary fix or design a robust solution. It's often easy to do the temporary fix, because for example: 1. It isn't critical code 2. Time is of the essence, "We need to ship now!" 3. There is high degree of confidence that it be visited again after we ship and be fixed up. 4. Surely, this code will not last that long. I'm sure there are other good reasons to "git 'er done!" and get things working, but more often than not, what isn't critical code, becomes critical. What was going to be revisited and re-factored, now works, and in priority queues of life, "if it ain't broke, why fix it?" Lastly, rarely does one "come this way again" just to tidy up. The moments spent in front of a block of code are more fleeting than you think. This may not be news to developers more experienced than I, but as much as I hate to admit it, what was once temporary, almost always becomes permanent. There will come someone this way again, but not to tidy up, more often than not, they come to build upon your work and in the best of object oriented abstraction, your implementation and all it's bandages, bailing wire and duct tape often remain hidden. Hidden that is, until they break in catastrophe. All this reminded me of a poem I recently heard by Will Allen Dromgoole:

The Bridge Builder An old man, going a lone highway, Came, at the evening, cold and gray, To a chasm, vast, and deep, and wide, Through which was flowing a sullen tide. The old man crossed in the twilight dim; The sullen stream had no fears for him; But he turned, when safe on the other side, And built a bridge to span the tide. "Old man," said a fellow pilgrim, near, "You are wasting strength with building here; Your journey will end with the ending day; You never again must pass this way; You have crossed the chasm, deep and wide- Why build you a bridge at the eventide?" The builder lifted his old gray head: "Good friend, in the path I have come," he said, "There followeth after me today, A youth, whose feet must pass this way. This chasm, that has been naught to me, To that fair-haired youth may a pitfall be. He, too, must cross in the twilight dim; Good friend, I am building the bridge for him."
When you write code, consider what it might look like to a new hire 10 years from now. Make it something that can be built upon, because whether your like it or not, it will have a long, long life. Note 1: The same could probably be said for UI design as well, but that's probably worth another post entirely. Note 2: The picture above is of the the Eads Bridge built in 1874 is the oldest bridge over the Mississippi River, and the world's first steel arch bridge.

26 May 2006

Putting a Voice to the Name

Last Wednesday I was interviewed on the Your Mac Life show. I know it is nice some times to get a better feel for the voice behind the words, so if you'd like, head on over and take a listen. My part starts a bit before half way through the show. Enjoy.

25 May 2006

Wither the Wireless Mighty Mouse?

When the Mighty Mouse was announced, I was very skeptical about the Scroll Ball. I thought it would be too small and not responsive enough. Boy was I wrong. I love it, I think it has the best multi-directional feel of any mouse I have tried. After I had used it with the Intel iMac at work, I knew I wanted one for home, but I wanted the wireless Bluetooth edition. Only a few months and there will be a wireless one available right? That was 10 months ago! Please Apple, release the mouse from it's corded captivity! It wants to be free!

24 May 2006

Open XML Spec: 3975 pages!

I've mentioned before some of the challenges we've had this product cycle, but it's hard to really express the scope and scale of things sometimes. Today, I got some help. One of the major changes under the hood this product cycle is support for the new Open XML based file format. The format has been submitted to ECMA and after approval there, it will go onto ISO for approval. You can find the full spec online. Well, 24 MB of compressed PDF and 3975 pages later, you'll have all you need to understand the details of the new file format. Now, that's what I call documentation! (via Brian Jones)

23 May 2006

Think Different. Just Do It. Brilliant.

This is a wonderfully useful iPod addition. But what about all us cyclists? Great work Apple. I always wondered why Apple didn't call the iPod the iListen or iMusic etc. I'm glad they left it generic. More and more the iPod becomes the hub of Apple's off-line story. Now, if only it could be a phone that also kept my mobile user folder, that would be something!

19 May 2006

Mactopia Newsletter

Did you know MacBU has a monthly email newsletter? If you didn't, now you do. You can sign up for it here. It can inform you of interesting articles like how to share Entourage information with other devices or Nine ways to speed up Virtual PC for Mac. Enjoy.

18 May 2006

Mac Office Resource Kit 2.0

A while back I mentioned that we were working on a new version of the Office Resource Kit for Mac Office 2004. Well, we just release version 2.0 and it's located here. It's 153 pages of technical information that I think will really help with large scale deployments of Mac Office. Thanks for all the feedback and keep it coming!

17 May 2006

Office Open XML Performance

I remember when we first heard that the default Office 12 file format would be XML. As we talked about it, the converstation always seemed to come back to two things: 1. It's a great idea. 2. What's the performance going to be like? A lot of time has passed since that first conversation, but performance continues to be critical. If the XML format is not fast enough, it will not get used and if it's not used, much of the benefit will be lost. I recently read a very interesting post about some of the work Win Excel is doing to make sure things are fast. Things you might not consider at first, like the size of the tags used, become very important at scale.

Remember, we're not talking about creating a format for hobbyists. This format is supposed to be used by everyone, and most of those folks aren't going to be happy with feature loss and performance degradation just so they can save out as XML (the average user doesn't care about XML). The original SpreadsheetML from Office XP was actually more like a hobbyist format, and as a result, it was really easy to develop against, but it was bloated and slow. I wish that we didn't have to worry so much about performance, but if you really expect these formats to be used by everyone, then you have to take the training wheels off. That's why the standardization in Ecma is so important though, so that we can ensure that everything is fully documented and all the information is there to allow you to develop against them.
The full post talks more about the XML parser and I found it fascinating. As always, great performance is about making the right tradeoffs, in this case some human readableness was sacrificed for significant performance gain.

16 May 2006

Performance at the Lower Levels

I've written about performance before so it's no surprise that when I heard about UC Berkeley's Jasjeet S. Sekhon's analysis I thought I better take a closer look. His basic conclusion is that for "statistical computing", Mac OS X is too slow to be considered. Sure enough, the ever anonymous ridiculous fish (presumed Apple employee and blogger) took some time to get to the bottom of the "Mac OS X is slow" meme. His summary response is classic:

To sum up the particulars of this test:
  • Linux, Windows, and Mac OS X service small allocations from the application heap and large ones from the kernel’s VM system in recognition of the speed/fragmentation tradeoff.
  • Mac OS X’s default malloc switches from the first to the second at an earlier point (smaller allocation size) than do the allocators used on Windows and Linux.
  • Sekhon’s test boils down to a microbenchmark of malloc()ing and then immediately free()ing 35 KB chunks.
  • 35 KB is after Mac OS X switches, but before Linux and Windows switch. Thus, Mac OS X will ask the kernel for the memory, while Linux and Windows will not; it is reasonable that OS X could be slower in this circumstance.
  • If you use the same allocator on Mac OS X that R uses on Windows, the performance differences all but disappear.
  • Most applications are careful to avoid unnecessary large allocations, and will enjoy decreased memory usage and better locality with an allocator that relies more heavily on the VM system (such as on Mac OS X). In that sense, this is a poor benchmark. Sekhon’s code could be improved on every platform by allocating only what it needs. Writing this entry felt like arguing on IRC; please don’t make me do it again. In that spirit, the following are ideas that I want potential authors of “shootoffs” to keep in mind:
  • Apple provides some truly excellent tools for analyzing the performance of your application. Since they’re free, there’s no excuse for not using them. You should be able to point very clearly at which operations are slower, and give a convincing explanation of why.
  • Apple has made decisions that adversely impact OS X’s performance, but there are reasons for those decisions. Sometimes the tradeoff is to improve performance elsewhere, sometimes it’s to enable a feature, sometimes it’s for reliability, sometimes it’s a tragic nod to compatibility. And yes, sometimes it’s bugs, and sometimes Apple just hasn’t gotten around to optimizing that area yet. Any exhibition of benchmark results should give a discussion of the tradeoffs made to achieve (or cause) that performance.
  • If you do provide benchmark results, try to do so without using the phrase "reality distortion field."
  • I build some of the tools we use to measure performance of Mac Office. When MacBU was formed, my first job was building Excel performance automation, so this is a subject near and dear to my heart. It's easy to take for granted how difficult it is to get a responsive piece of software, and yet, a responsive application experience is key to any great Mac application. If there's anything I've learned about performance it's this: perception is reality. What you choose to measure better be exactly what your users use when they perceive the performance of your application. When you do dig down and try to solve the performance problem, you will often find lots of performance tradeoffs, but the key is to fix the ones that effect what the user perceives. Trying to use low level performance measurements to indicate what the user will experience simply does not tell the whole story, in-fact, it can often hide the most important story.

    Glossy MacBook

    Today Apple released the new MacBook. Several things to point out: 1. It comes in white and in a black! Cool. I wonder if the white is that cool "ivory" white like the first white iBooks... 2. FireWire is included and therefore not dead. ;-) 3. Larger trackpad to deal with larger screen. For me, and others with large hands, this is a bummer. The palm of each hand touches the track pad on each side, which makes the OS think I'm two finger scrolling. This makes my cursor disappear and then there's a delay when I go to use the mouse as the OS figures out that I'm no longer scrolling. I hope Apple fixes this in some future OS update. 4. Glossy screens. Just a few weeks ago my Dad asked me why his buddy's PC laptop had this shiny screen while his PowerBook's screen was not. I explained that this was for in store sales. I believe that glossy sells better on the show floor, even though in actual use the reflection is worse. I'm guessing Apple choose to go with glossy because of this. I don't think they'll ever go glossy on their Pro series. Update: You can get a glossy screen for the MacBook Pro as a build to order option! 5. The keyboard is new, "MacBook features a unique new keyboard design that sits flush against the bed for a sleeker, lower profile. Plus, you'll find a firmer touch when typing. That ought to make your fingers happy." Uh, sounds like some marketing spin... Before you buy, head down to your local Apple store and try out the keyboard first. I know I will. 6. IR port moved to the right hand side, rather than the center. 7. No latches or buttons to press on open! Magnetic latches. I'm going to want to try this out as well. Thank goodness we don't have floppy disks hanging around with all the magnetics in the lid and power cord port, you'd be bound to lose some data. My last remaining question is where are the wireless antennas? Is there a huge bar on the hinge like the MacBook Pros, or are they installed in the screen area? This laptop is very competitively priced. I think it will do very well. Update: A very nice comparison chart is located here.

    11 May 2006

    Questions about UI Design

    There was a good comment full of questions on my last post and as I composed a response, it became big enough, I thought I'd better make it a full post. That said, holy loaded questions! At least they didn't include how to find happiness, fame and fortune! ;-) Seriously, the short answer really is easy: I don't know. The longer answer is that I have some ideas, but I'm still not sure. Others smarter than I will probably chuckle at my naiveté, but here goes: Q: One thing that puzzles me though is how one can successfully apply this concept on an evolving project (like Mac Office or any other mature app)? A: I think the way you apply this with any project is that you design the UI first, because that's what the user will experience. For example with a web UI that means building a HTML page. For a Vista application that means building the XML files that represent the UI in a designer tool. For a Cocoa application that means building the UI structure with Interface Builder. For a Carbon application that means building the UI in Photoshop and committing the design to code later. When your UI designers don't produce "code-able artifacts" or stuff that goes directly into the application, this just means the developers have to work a bit harder to make the feature a reality. Q: Word for instance is highly criticized for feature bloat. A: I think you are picking on Word a bit too much. ;-) Seriously, consider any application that has been successfully selling for 20+ years. ... Okay, there's not many, so let's say for 10+ years. Do they all have lots of features? Of course they do. Even younger applications like say OmniGraffle 4 or Final Cut Pro, they all have lots of features. Does this make them intrinsically bad? I don't think so. Providing customers access to your functionality is a challenge with any large professional software tool. The challenge is really this: How do you expose these features in such a way that the beginner can step right in and be productive and be gently guided to the more powerful features, but at the same time allowing the power user the ability to simply rock and roll with the tool and be in the "flow" of the creative work they are doing? This is a tough question. Some folks have said that you simply shouldn't build in so much functionality, and some how that makes it better for everyone. Perhaps they'd like to see a bunch of smaller specifically purposed applications. We've had this idea before on the Mac OS and it was called OpenDoc. We have it today in some ways with the many Web applications online. If you have many cohesive, loosely coupled applications and you are building one of these applications, when do you stop building one application and start building another? How do they all communicate? What is the user experience like? Does this make life better for the user? What if you create a new application, but your competitor simply adds the feature to an already existing tool? These kind of questions do not even get asked until the product has been successful for many years and already has many features. I think the idea of many small specifically purposed tools makes sense in the physical world, but doesn't fully translate to software tools. Q: Why hasn't the formatting toolbar been removed from Word when the formatting palette was introduced - or else why not in the next major release? A: Obviously I can't talk about the next version of Mac Office (and remember I'm not a designer for Office and I wasn't part of the design of the formatting palette), but I can easily guess that in a customer base as diverse as Office, I am sure there are those who prefer the formatting toolbar over the formatting palette. Q: And speaking of tools, why are there so many toolbars? A: This is a great question. I think most Mac users like to think about UI design and especially for tools they use all the time like Office. Jensen Harris is one of the UI designers for Win Office 2007 and I'd recommend taking a day or two and readying his blog about how the Win Office team has gone about designing the new Win Office UI. It's very interesting, at least for me. He addresses dealing with "the toolbar issue" throughout, but I think these posts will more specifically answer your questions: Combating the Perception of Bloat (Why the UI, Part 3) Ye Olde Museum Of Office Past (Why the UI, Part 2) For Sale By Owner The Biggest Loser The Size Of Things I hope that provides some food for thought. These are great questions and I love the discussion. I really enjoy that so many Mac users care about this kind of stuff.

    The Importance of a Clean UI First

    I've always been a believer in designing the UI first and then moving in from there. Test Drive Development reinforces this idea; just replace the "UI" with an API. There are several reasons to do this, but I just realized today the last and perhaps the most important reason to nail the UI first, and then work on the rest of the product. The realization came when I remembered a quote from Malcolm Gladwell the author of The Tipping Point.

    "If the first broken window in a building is not repaired, then people who like breaking windows will assume that no one cares about the building and more windows will be broken. Soon the building will have no windows. Likewise, when disorderly behavior is left unchallenged, the signal given is that no one cares. The disorder escalates, possibly to a serious crime."
    By building the exterior first and really showing that you care about the outside, this sends a message about expectations for the product and I think produces higher quality code inside. I think that for this reason alone, applications developed with Cocoa's AppKit have a remarkable advantage, not technically, but emotionally over tediously built UI in Carbon without NIBs. The very tedium of building the Carbon UI from scratch means doing the UI last and therefore negates the positive emotional influence it could have over the course of the project.

    10 May 2006

    Screencast Demos with ARD

    Similar to Win Office, Mac Office is developed in a number of sites around the world. We have our PowerPoint and Entourage crew in Mountain View, California, then Messenger, Word, Excel and Office Core teams in Redmond. Much of our Japanese work is done in, you guessed it, Tokyo, Japan, while our European localizations are done in Dublin, Ireland. When you have a team spread out like this, deploying a new tool to the organization isn't just a lunch time chat. Yesterday we tried something new and it turned out pretty well, so I thought you might find it interesting. We were giving a presentation and demo of a new automation tool in Redmond, but we want everyone to experience the demo. Folks on vacation, sick or simply sleeping in Ireland needed to see how the tool worked. Here's what we did: The presenter used a MacBook Pro with a QuickTime Pro license and the QuickTime player. During the presentation he stayed more or less in front of the MacBook Pro and this is how we got audio and video of the presenter. On my MacBook Pro I connected to the presenters machine via AirPort and "watched" the screens (ARD 3.0 has great multiple screen support, by the way) and then recorded the action with Snapz Pro X. Also, I recorded the audio of the presentation so it was synchronized with the screen. ARD 3.0 had some difficulty keeping up with the PowerPoint transitions, but when the actual demo was run, it was very watchable. The nice part about using ARD to record the screen is that when the presenter switches from on Machine to the next, in ARD you simply change the window that you are recording and that's it. Slick.

    09 May 2006

    Disclaimer 2006

    I just read Chris Anderson's disclaimer and I liked it so much, I'm adopting a similar one for my own. Here it is: The content of this site are my own personal opinions and do not represent my employer's view in anyway. In addition, my thoughts and opinions often change, and as a weblog is intended to provide a semi-permanent point in time snapshot you should not consider out of date posts to reflect my current thoughts and opinions. I work at Microsoft in the Mac Business Unit. I believe it is a great company and the Mac Business Unit is an especially fabulous place to work. No, I don't think that everything that Microsoft does and produces is wonderful and perfect. I believe that everyone is entitled to their opinion, as am I. I hope that was obvious, but just in case, I thought I'd make it formal. :-) Now, on to the fun posts...

    E3 Announcements

    So today Microsoft announced that Xbox Live will work not just on Xbox consoles, but on Windows PCs. I am not a gamer, but it's hard to be blind to how well done the "Live experience" is on the Xbox and the idea that this will come to the Windows OS is just one more great reason to dual boot into Windows on my Mac. The Xbox Live team is just firing on all cylinders and frankly my hat's off to them. Among other things announced Halo (remember that game that was first demo'd so many years ago at MacWorld?) turned three. Additionally the Xbox Live Arcade catalogue will include by the end of the year Pacman, Ms. Pacman, Galaga, Dig Dug, Rally-X, Frogger, Track & Field, Contra/Super Contra, Defender, Paperboy, Root Beer Tapper, Ultimate Mortal Kombat 3, Sonic the Hedgehog. It's amazing to me how popular these old games are becoming. Too bad we can't get this kind of milage out of Mac Word 1.0!

    02 May 2006

    The Sad State of Mac OS backups

    For some great info about Mac OS X backup software check out these two articles: The State of Backup and Cloning Tools under Mac OS X Mac Backup Software Harmful Conclusion: Only SuperDuper works 100% Amazing. Since all our OS restores in the Lab are done with ASR and in "block copy" mode, we aren't effected by the 10.4.6 bugs, but still, this stuff should "just work" right? Guess not... :/

    01 May 2006

    Get a Mac

    As much as I loved the switcher commercials Apple's new "Get a Mac" ads are just wonderful. Take some time to watch them. Simple. Straight forward. Easy to understand. Sound familiar? Enjoy. Link