078. A Tour of “Ye Olde Museum Of Office Past”

New! Listen to this post here. Free podcast RSS feed.

Welcome to “Ye Olde Museum Of Office Past.”1 This section is one of the more deeply product-focused of Hardcore Software. I hope to make it fun. In this section, I will go through the history and evolution of the Office user interface. While there were numerous innovative user interface systems and approaches across the industry, what we developed in Office by virtue of the breadth of usage and position of influence was viewed by many as a standard to be followed. Many readers have experienced the innovations discussed here. By stepping through over 20 years of user interface designs for Microsoft’s word processing applications, we can see the dedication to solving problems. We can also see the creeping introduction of bloat.

Back to 077. What Is Software Bloat, Really?

How did we get to Office 2003 with a menu bar, toolbars, context menus, keyboard shortcuts, task panes, dialog boxes (with tabs), widgets, buttons, and pop-up commands?

We got here by solving customer problems. We got here by making the product easier to use. We got here by listening to the market. We got here by winning reviews. It was that simple.

Or was it?

It is easy to see what happened in hindsight. We added new features, one after another. To make features easier to discover and use, we added additional user interface. Layer after layer, or solution after solution, we built up an array of user interface elements that when looked at in totality created bloat. But it is just so easy to say that in hindsight.

One simple observation was that to win in the market when Microsoft started making applications, we had to win reviews. These reviews meant everything in a world with many competitors, retail distribution, and little word of mouth (and no internet). Reviews were giant checklists of features. For example, Software Digest compiled yearly reviews of all products in market. The 1984/5 edition of their 200-page book on just word processors had a 4-page fold-out checklist of 50 features and a dozen abstract criteria. Fail any of those and the overall score sank. A losing score meant no ability to advertise winning, no recommendations from salespeople, and then the next release and review started in a hole. So, for a decade we made sure to always have those features. There was no choice other than to win reviews. And we did.

When should we have stopped and taken a first principles approach? When would the upside have exceeded the potential downside? When would the market and reviews have tolerated a big change? What if the market rejected a solution we tried? We would have reverted to the old way and delayed addressing bloat for how long, another decade? It drove me bonkers when people thought bloat was obviously caused by too many features. It also drove me bonkers when those that should know better would so quickly conclude that we were making things worse by winning reviews.

Give a gift subscription

There is no easy answer to asking when the right time is to make a wholesale change in approach. Anyone in product development saying it is obvious hasn’t really lived through the risk of making a bad choice or is simply applying hindsight.

Innovator’s dilemma and disruption make it seem so easy to identify and act at the right moment. They also make it so easy to make fun of the leaders who are terrified, I mean literally shaking scared, to make a dramatic change to a product. No one ever gets fired right away for not making a big change. Many people get fired right away for making a big change at the wrong time. The worst part? So many big changes are eventually proven correct over time.

In the case of evolving Office, we were going so fast cranking out releases no one stopped to ask anything big. Customers were buying our product as fast as we could press new CDROMs, so to speak. We were winning reviews. Our biggest competitor was ourselves. We were so ubiquitous that we were punchlines on everything from David Letterman to Saturday Night Live to Dilbert.

Then suddenly, we were boring, bloated, and not particularly interesting. So much so that a buggy, poorly implemented, sort-of clone became a symbol of everything we had apparently done wrong. The world was saying that StarOffice was good enough. Ugh. Our sales, however, were not dented even the slightest. But could they be? We did lose that deal in one city in Germany. StarOffice was a German company so maybe it wasn’t so bad. Then there was a medium-sized US government agency loss. When do you panic when something like this happens? There’s no playbook.

Hemingway wrote in The Sun Also Rises:

     "How did you go bankrupt?" Bill asked.
     
     "Two ways," Mike said. "Gradually and then suddenly."

We became bloated gradually, and then suddenly it was too much. The product was collapsing under its own weight.

It was time to revisit from first principles everything we’d done and ask why. And to come up with a better approach, a wholesale reinvention.

The aim of this section is to briefly cover the history of those innovations that got us here so that we have the necessary context in the next sections on the design of Office12. When it came to telling the story of Office12 once he showed it to customers, Jensen Harris (JensenH) dubbed this his tour of “Ye Olde Museum of Office Past.” Please join us on a tour.

Comparing a typical command in Office from the time it was introduced to a release decades later is a great lesson in the compounding complexity of products. Making text bold debuted in Microsoft Word 1.0 for MS-DOS in 1983. Text was made bold simply by selecting the text (actually, it wasn’t simple at all since few had a mouse, but I digress), hitting the escape key, the letter F for format, the letter C for character, and finally the letter B for bold. For those with a fancy monitor, which not everyone had at the time, the text became bold on the screen. Choices at each step were limited to approximately five.

Commands also had keyboard shortcuts from before the mouse as an affordance for touch typists. Early keyboard shortcuts were simple, like using INS(ert) key to copy text from the scrap (clipboard). WordPerfect, and other early MS-DOS apps, devised schemes that were nearly impossible to memorize. Most people had some sort of cheat sheet nearby or keyboard overlay to help remind them of keyboard sequences. Lotus 1-2-3 had a highly structured command architecture known as slash commands as navigating the character-based menus began by striking the forward-slash key (for example, to open a file /WFR for slash, (W)orksheet menu, (F)ile menu, (R)etrieve command). Competitively, the two behemoths in productivity software of the MS-DOS era, WordPerfect and Lotus, arguably clung to their keyboard methods while the industry shifted to the graphical interface, even maintaining compatibility with those keystrokes during the rise of the mouse and standardized menus.

Macintosh, with menus and a mouse (and later Windows), aimed to simplify all this. In Microsoft’s Word 1.0 for Macintosh, text was selected with a mouse and Bold was chosen from the Character menu, like what Apple did in their MacWrite 1.0. MacWrite had about 35 menu commands in total. Menus were mostly a direct mapping of the features to the product code. The whole product could be described by showing screenshots of all the menus in a two-page magazine spread as Popular Computing did in 1984 when Macintosh was launched.

Over time more and more formatting options were added: subscript, superscript, underline, different fonts, color, and so on. Excel was even more complicated because it supported formatting cells as dates or currencies, plus single underline, double underline, accounting underline, and more. This was great—we listened to customers, observed what they were trying to do in the real world, took advantage of new hardware, such as laser printers, color ink-jet printers, and fancy screens, and were adding features like mad. Soon, though, the menus got too long for even basic formatting.

Microsoft’s early Macintosh applications introduced dialog boxes, which were windows that popped up and showed all the formatting options. This was inconvenient for routine formats, so the menus had a mixture of common commands like Bold and Italic, and then a menu to “bring up that complicated dialog box.” This was the start of hide-and-seek with features.

Excel realized these challenges about the same time Microsoft Publisher did and created toolbars. (There’s a history of debate over toolbars—what is considered one, and which team or even company invented them. Many on the Excel team were hardcore about their version of the story.) Toolbars were used for common commands, like Bold and Italic, as well as Print, Save, and Copy. In 1990, the front of the Excel 3.0 box and associated advertising displayed giant toolbar with buttons for Bold and Italic. Toolbars they were such a big deal. Eventually, toolbars were so popular everyone wanted their favorite commands on them, so we created more toolbars and made it easy to rearrange the buttons and hide/show different toolbars.