New Rectangles to the Rescue? (Why the UI, Part 4)
This is the fourth part in my eight-part series of entries in which I outline some of the reasons we decided to pursue a new user interface for Office 2007.
Last time I discussed the UI mechanisms added to Office 2000 intended to reduce the perception of bloat: Adaptive Menus and Toolbar Rafting. I did want to add something I forgot last week. Steven reminded me that the earliest versions of both Excel and Word for Windows had two versions of all the top-level menus, short and long. By default, only a small number of commands were shown, and a user could click the View - Full Menus command to cause the full list of commands to appear. This is interesting because I'm told the push to move back to the "short menus" was an important influence that impacted the design of Adaptive Menus in Office 2000. Just a bit of historical housekeeping.
Today, I'm going to take you forward all the way to Office 2003 and write about two new rectangles that appeared on the screen in recent versions: the Office Assistant and Task Panes.
I'm not going to spend a lot of time on the Office Assistant (a.k.a. "Clippy", a.k.a. "Clippit"). I was introduced to it probably the same way as a lot of you--I was still in college, and a friend got Office 97 loaded on his new computer. I was somewhat puzzled by it, but I did spend time looking at the different choices (I liked Einstein.) I also spent some time right-clicking on it to make it do funny animations. Once I got Office 97 for myself, I'm pretty sure I kept the Assistant on for a while so that people who saw my computer would think I was cool. In a few months, everyone had Office 97, and the Assistant had lost its geek cachet. Besides, I had papers to write, and that's when I'm pretty sure I turned it off for good.
There's been a lot written about Clippy already; if you want to learn about more of the history, I'd read Steven's analysis entitled "Learning from the past." I wasn't at Microsoft then, and most of the people who worked on Assistant v.1 are now elsewhere, so I don't have a lot of historical insight to offer.
I will say this: the Office Assistant was more an experiment in providing contextual help than it was a new UI mechanism. I know because of the e-mail you've sent me that a lot of you want me to write about Clippy. But honestly, it didn't really factor into the Office 2007 discussion as a direction to look at other than that we had to finally take it out of the product for good this time (no option to turn it back on.) If you're looking for a scholarly discussion, you can dig into some of the reasons people found it annoying.
Let's leave it as this: the Assistant wasn't really relevant to the Office 2007 UI, it was more about the evolution of help than the evolution of interaction design, and I personally don't have any good stories about it. R.I.P. Clippy. The end. (OK, I do know one interesting anecdote: the Japanese version of Office used a dolphin named Kairu as the default Assistant.)
A much more relevant rectangle to the Office 2007 discussion is the introduction of Task Panes in Office XP.
As I have discussed before, by Office 2000, menus and toolbars were essentially full. Each additional item that we added was such a small percentage of the overall structure that people didn't even notice new commands from version to version. The relatively poor organization of the menu structure didn't help. So, when Adaptive Menus failed to catch on, Office had a problem--people weren't finding and using the new features.
Contrary to the conventional wisdom of the naysayers, we weren't (and aren't) "out of ideas" for Office. Customers weren't telling us that they didn't need new features--to the contrary, the list of requests is a mile long. Every version we were putting our heart and soul into developing these new features, undergoing a rigorous process to determine which of the many areas we would invest in during a release, and then working hard to design, test, and ship those features. The only problem was that people weren't finding the very features they asked us to add.
The Task Pane was an attempt to bypass the menu and toolbar structure altogether by exposing new features through a new rectangle on the screen. The thought was that people wouldn't be able to miss a whole new rectangle on the screen and, therefore, they would find and use the new features.
(Click to view full picture)
The Task Pane was completely additive; it made no attempt to change the existing menu or toolbar structure. For the most part, legacy features lived in menus and toolbars, and new features lived in Task Panes. The PowerPoint team probably did the most work to embrace the Task Pane model in their user interface between Office XP and Office 2003; a few legacy features, such as Slide Transition (above) did migrate to the Task Pane.
One of the most controversial internal discussions at the time was whether the Task Pane should go on the left or the right. It started out on the left, which gave it a more primary space in the UI, thought especially key for the New Document Task Pane. On the other hand, it conflicted with the PowerPoint left pane, causing a bit of a mess over there. In the end, the reason it finally got moved to the right for good was that on the right the Task Pane wouldn't cause the document to shift as it opened and closed.
The downsides of the Task Panes were many. Number one, given that all the menus and toolbars still had to be present, it did take up a lot of space, as you'll see if you reflect back on my now infamous "Mythbusters" post. Worse, because it didn't actually replace any of the existing UI metaphors, it created yet another rock for users to look under. Now, in addition to short menus, long menus, hierarchical menus, visible toolbars, and the toolbar list, a user had to look through the Task Pane stack as well for features. It just added complexity to the product.
Probably my biggest misgiving about Task Panes is that they encourage bad interaction design. Every PM wanted to design their feature as a Task Pane because they could have a brand new, clean rectangle to put their feature in. This makes their job easier and your experience, as a person using the software, worse. Every feature would whack away the Task Pane of the previous feature (because only one could be up at once.) Some of the Task Panes were quasi-wizards with multiple pages, some of them were really dialog boxes, some of them were just a menu of two commands with a bunch of explanatory text around them. No one really thought about the experience of how to reconcile all of the Task Panes--how to find related functionality in the old UI system, how to use two features at once, and the fact that ever single feature required its own huge rectangle. In just two releases, ending with Office 2003, we already stretched the limit of Task Panes as a manageable UI paradigm.
When we started Office 2007, before any of the application teams really took it seriously that our team was going to deliver on a new UI (you know, healthy skepticism and all that), we looked at the early designs for some of the proposed features and realized that Office 2007 was going to have 10 times as many Task Panes as Office 2003, and it was just going cause a UI train wreck. I honestly believe we would have had to ship 100 Task Panes in Word 2007.
The Task Pane was the last attempt to find a way to scale old-style UI to programs as full-featured as Office. Although it was a successful stop-gap measure, it ran its course in only two versions. I'm reminded of Nathan Myhrvold's First Law of Software: "Software is a gas." Every time we add a new UI mechanism, it fills up. Because we only added and never renovated/reorganized/removed, complexity went up each release.
Office 2007 is our chance to build a new interaction foundation for the next decade of productivity software.
