Recently in innovation Category

After toiling in obscurity for the past nine months, my new team has finally "gone public." Last summer, I left my gig in Product Planning after nearly six years to head up an Incubation team in Microsoft Office Labs. There are about 60 of us in "Labs," all focused on doing concept tests of interesting ideas focused on productivity.

Concept tests are just what they sound like: they're not quite "full blown" products, but are tools that are fleshed-out well enough for folks to use and experiment with. We hope to learn from each of these and incorporate the best ideas and learnings into our shipping products. We have a pipeline full of these and expect to make them available on officelabs.com on a regular basis.

The site went live today with a few of the team's first projects. One is an Office add-in called Search Commands that allows you to find features you need in Office using more common language and terms. We also shipped a web app called Community Clips, a collection of "how to" videos on Office that anyone can contribute to (the "community" can add its own "clips"...get it? Aren't we clever monkeys...).

So far, there's nothing directly from my team posted on the site. Yet.

My team is focused on building prototypes for mobile workers. We're specifically interested in concept-testing innovations around how the mobile phone can be an even more effective tool for folks who work away from their desk or don't even have a "desk" at all. This is area that is going through some incredibly huge and interesting changes right now as people demand to get their work done anytime, anywhere. We've got some cool things up our sleeves, but more on that later.

For now, check out the Office Labs website and try out some of the stuff we're building. We're very interested in your feedback. And if this sounds like a cool gig (it is), we're also hiring.

Back in the early 'aughts', I was a member of the Macintosh Business Unit at Microsoft (a.k.a. the "MacBU," pronounced "mac-boo"). In my nearly three years there, I lead the Product Planning efforts for Mac Office 2004, the version currently on the market. As you can imagine, I'm very excited to see the MacBU's progress on the next release highlighted in today's post on the BU's Mac Mojo blog.

The new Elements Gallery looks to be an excellent adaptation of principles from the Office 2007 Ribbon user interface, but with a unique Mac twist. The real-time previews are there, together with a tabbed interface that makes browsing through available options more discoverable. But there's also no mistaking this as anything other than a Mac OS X application.

Now, I like the Gallery, but I'm guessing that the embedded toolbar is actually going to be the most striking change Mac Office users will notice. Whereas previous versions of Mac Office applications displayed a single set of toolbars that was shared across all of the open document windows, the MacBU is now following the Apple Human Interface Guidelines (HIG) for Mac OS X and providing a separate toolbar inside of each document window.

Interestingly, this is something we considered doing for Office 2004 as long ago as 2001.

Fig. 1: PowerPoint 2004's Floating Toolbar

The arguments for and against the use of embedded toolbars are pretty straightforward. A single set of toolbars has the advantage of taking up a set amount of screen real estate, regardless of how many documents the user has open (see Fig. 1). This is especially important when screen resolution is low and every pixel is precious.

In addition, the consistent placement of the toolbars on the screen allows users to develop "muscle memory" for toolbar button location, regardless of where the document window is placed. It's not quite a perfect application of Fitt's Law (à la Mac OS X's screen corners for Expose), but the concept is similar. By comparison, with a toolbar in each window, button targets move depending on the window coordinates and its dimensions. There is additional cognition needed to find and then hit these moving buttons.

Simply put, this slows things down and mouse-driven tasks can take longer to complete. We're talking about a few seconds -- or even fractions of a second -- here, but the effect in the end is that people get frustrated from having to constantly look for the application controls and may break their train of thought (an important consideration when your application is used for the creation of content).

Fig. 2: PowerPoint 2008's Embedded Toolbar

During the planning phases for Office 2004 back in 2001-2, we debated this issue for some time. On top of the design argument outlined above, we had development costs to contend with, as well. Time invested in changing the UI would take away from other feature work we might want to do. We had to be sure that the payoff would justify cutting other features to fit it into the schedule. To help us figure this out, we built mock-ups of Office using an embedded toolbar even back then, just to see what it might look like.

In the end, the argument for floating toolbars won out and Office 2004 continued with the toolbar architecture customers had seen in Office for over a decade. The critical factor then was screen real estate.

Remember, this was a time when Apple's newest iBooks shipped with screens capable of only 800 x 600, a 17" Studio Display was $1,000 and most Macs capable of running OS X were sporting resolutions of 1024 x 768 or less. Deduct 100 - 200 vertical pixels for the menu bar, window borders and Mac OS X's plump, new dock and it's clear to see that an embedded toolbar could squeeze the available document workspace to a thin, narrow slit. Hardly ideal conditions for document authoring and editing.

Fast-forward to 2007. New MacBooks ship with a native resolution of 1280 x 800, a 33% increase in the vertical dimension. Most new iMacs ship with twice the number of pixels of those early G3 iBooks and external flat-panels with 1200 vertical pixels and 20" of viewing space cost less than $400. Hardware advances clearly have made embedded toolbars more viable.

But something else changed over the past six years, too: Mac applications. Mac OS X apps in 2001 were all over the map in their look and feel. Many were simply ports of Mac OS 8/9 apps with their user interfaces rebuilt using Aqua controls. Very few had yet adopted Apple's Mac OS X HIG and even fewer new-from-the-ground-up apps were in the market. Worse yet, the HIG was evolving like any new technology, with developers and designers still figuring out the best bits to use as well as the ones to ignore (drawers, anyone?).

The Mac OS X application landscape today is much more stable than it was in those early days. The clunkiness of ported Classic apps has given way to a wide variety of elegant and beautiful products. Apple's own UI tools and APIs have improved, as well, allowing an even larger percentage of developers to create functional products that look and work well, too.

Red Sweater Software's MarsEdit blog editor	HandBrake DVD Ripping App	MetaQuark's AppFresh software updater

Better tools and shared learning across the Mac developer community for what works and what doesn't has driven greater consistency in application design over the past six years, too. Products as varied in their function as MarsEdit, HandBrake and AppFresh all sport similar and now-familiar UI elements. Whereas an Office 2004 with embedded toolbars would have been among the first applications at the time incorporating that design, Office 2008 without them would be equally out of place.

I was among those in the MacBU who hoped we could adopt embedded toolbars for Office 2004. But it was clear in those early years of Mac OS X that it was simply too soon to change the way the product millions of people used everyday looked and worked.

Not only has the hardware, the platform and the Mac applications ecosystem evolved to make this more viable now, it's clear from Nadyne's post that the MacBU has put the time to good use. They appear to have been able to take a much more holistic approach to the entire issue, blending the goodness of the Office 2007 Ribbon with Apple's HIG and some of MacBU's own user interface innovation. They've done more than simply duct tape the current toolbars to the top border of the doc windows.

The proof will be in the actual use of Office, and I'll hold my final judgement until I get a chance to play with it myself. But I like the design direction the 2008 version is taking and now, it finally seems right for this extensive update.