Ahh, what a nice winter break.  So nice in fact that I haven’t posted  the following which I wrote while skiing in Whistler (gorgeous, recommend to anyone who hasn’t been.  Great snow, nice people, and it’s oh-so close to seattle…)

What role does UI play in pro creative tools?

I first started with professional creative tools back in 1986 when I was using all the early era Mac graphics packages; Hypercard, Macromind’s VideoWorks, Pagemaker, and the first crop of digital photo tools such as Digital Darkroom.  I pulled up a screen shot of VideoWorks just now, and it's actually shocking how little things have changed -- core elements of interactive design and animation are there, as they are today--transport controls, the stage, tools for direct drawing, timeline and keyframes, and the resource library full of "actors".  There have clearly been great improvements in the usability of creative pro tools, as well evolving aesthetics in terms of the “chrome” of the interfaces… but it has really been in the much more recent years that the really interesting innovation has come, and I believe that the next 5 years will be more radical still, with amazing evolutions and advancements in UI, driven by new platforms/tools for building UI, and more importantly by a new generation of designers and advancements in the craft.

When I arrived at msft to join the Expression team one of the first things that I took up as a personal ambition for the product was to *radically* rethink the way the product looked, not to mention the way it worked (usability and workflow).  At Siggraph mid-year that first year (2004) I and many others were awed to see Apple’s new Motion product, which sported a radically new and different interface that departed from the traditional Final Cut Pro interface and Adobe After Effects look/feel/behavior.  I and others were so bowled over by the look, that it was lost on us that the tool was actually very much a v1 and not quite ready for primetime… several of my friends in production confessed to me within weeks that “yeah, it looks pretty good, but you can’t actually do anything with it yet”.  I think Apple repeated this mistake in an even bigger way with Aperture 1.0, which was so embarrassingly bad that I and other early adopters actually got a $200 store credit when they lowered the price just a few months later and rushed 1.5 to market—could there ever be a bigger mia-culpa for a 1.0 product?  The lesson to me as a marketer was two-fold: the obvious = good looking innovative UI is something that can immediately set a product apart from a crowded and iterative set of knock-offs within traditional tool segments, and more importantly, you better back up that new UI with some pretty compelling and useful capabilities… because when you fall on chrome-sex appeal you fall *hard*.  I’ve personally been very disappointed with several tools in this regard, initially with Softimage’s DS – equally amazing, if not the most amazing looking thing I’ve seen in a new 1.0 --, and more recently with Motion and Aperture—they all demoed great, but I put them away after a few hours of experimentation and haven’t gone back to them (I hear DS is now excellent, many versions later, and I’m sure Apple will keep at it and bring the motion graphics and digital photo tools to bare on Adobe’s position in those categories).  Alias’ Maya, on the other hand, nailed it all in V1—great UI innovation, with a revolutionary product; wow, what a 1.0!.  So, for Expression, specifically the Blend product (at the time code-named “sparkle”) the question was how to really pack in some gorgeous visuals and to have those drive the actual usability and customer success with the product.  I’ll let our customers tell us how we did as far as the results—but I thought I’d share how we did it from a development perspective.

Building the UI of our UI design products

Alas, for the Blend team we had one incredible rocky and complicated development challenge that I don’t think many products have faced, certainly not to this degree.  Expression Blend is a tool for designing WPF (Windows Presentation Foundation) based applications, which itself is built using WPF.  In this regard, Blend is the most existential app that I know of.. each change to WPF platform required iterative changes to the app itself, from a UI and behavioral perspective, as well as to the functional capabilities.  It would be as if Flash was actually built on the Flash player, or DVD Studio Pro was a DVD player based tool … it’s patently absurd to suggest such a thing of other tools, but in our case, they had to build using the tool/platform that was still being built.  This led to incredibly difficult development challenges, where every week we had massive breaking changes and as the WPF project iterated through different templating, styling, animation, etc. models the entire Blend app would blow up and need massive re-working.  Amidst this relative chaos, how could we really push the envelope on the interface of the tool itself?  The answer was, we couldn’t!  If you looked at Expression Blend in March of 2006, you saw a generic looking app with some massive usability problems.  I dare say, I for one, thought it was a real stinker, and several former colleagues at Macromedia took great relish in pointing that out to me politely whenever I saw them.  This wasn’t lost to anyone on the team—we just couldn’t pull back and focus on that area because there was literally too much going on at the platform level that had to be addressed first.  Fast forward less than 6 months and look at the app we put out in Beta Dec 2006 (effectively only 3-4 months of actual development work, given the testing and locking down that occurred before Beta), it’s really amazing what transpired.  Huge improvements to usability/utility, and a completely new look feel that goes beyond simple color palette changes, and includes new controls/modalities that we didn’t have at our disposal just weeks earlier.  The reason this was possible was because of the nature of WPF—and speaks to the very core promise of the platform. 

Unlike traditional applications where the way a control looks, behaves, and functions are inexorably intertwined in the code that makes up the control… with WPF these concepts are separated and therefore independently editable and just as importantly iterate-able.  A team of “visual designers’ went to work on a series of mood studies and layouts for the interface, which a separate team of interactive designers ingested and applied the concepts to the interface using XAML. In traditional software UI development the next step would be for the designs to be handed off as Photoshop files or flattened PNGs, nay maybe even just a piece of paper!, and a team of developers would begin scratching their heads thinking of how to recreate those visuals using code and user drawn controls.  Not in our case.  Manuel Clement, the Blend product’s first designer, had this demo he would do internally to other msft teams that would absolutely bowl everyone over where he’d actually use an alpha version of the software to make changes to the interface controls that made up the app itself, then he’d check in his changes, rebuild, and voila—“Sparkle Eats Sparkle as he called it.. the ultimate existentialist demo, where a Blend was used to design Blend itself.  It would be nice if we could have really built the entire UI that way—but the truth is that the rapid changes in the platform and the tools always kept the working solution just beyond our reach except for a few scenarios where we got lucky; for the majority of the work we used Expression Design to design the visuals and generate XAML code, but the actual implementation into our UI set required a lot more manual work than we would have liked.  Still—we were using XAML code from end-to-end, and the inherent power of the WPF platform to fully customize the look/behavior without impacting the functionality.  Samuel Wan, a wicked Flash designer/developer and the Program Manager that did much of the actual implementation of the UI designs created by Aaron Jasinksi (visual designer) was able to work with the XAML UI, using Blend features that were working and manually when not, to rapidly implement the designs.  The speed with which the results took shape were amazing—with daily builds in august showing incredible advances each morning at 8:30 as I eagerly arrived to see what wonders the team had accomplished in the last 24 hours.  It reminded me of my days at Industrial Light and Magic, where each morning I looked forward to “dailies” (viewings of the previous day’s work on the film shots we were cooking up)—“Blend UI Dailies” if you will.  Feedback from beta customers has been very positive, particularly from our Windows Vista ISVs who had been using the product for over a year and were delighted to see their feedback incorporated into the new build(s). 

The best part is that now that we have Expression Blend almost finished, we can increasingly use the tool itself as we design the rest of the product family’s UI and iterate on our next releases coming down the pipe.  I’ve been on numerous projects in the past where the idea of changing anything remotely as complex as what we were able to do with Blend v1 would have been an entire product cycle unto itself… the fact that we were able to ship a solid 1.0 product, with tons of usability innovations and a significant breadth of functional capabilities, plus a innovative and modern look/feel… wow, it bodes very well for software design/development in the years ahead and is harbinger of the many exciting innovations that we will be seeing very soon from the ISV community building WPF apps for Windiows.  As we bring “WPFE” to market this year we will aim to bring similar capabilities to the design-development process for rich web applications and beyond… a cornerstone of our vision for the Expression family of tools.