Where Does Bloat Come From?
Steven Sinofsky has another deeply researched post about the history of UI complexity and bloat in the Microsoft Office applications. His post provides the background behind the decision to radically rework the Office UI with “the ribbon” (and lots of other related changes) in Office 2007. For the Office 2007 product cycle, I was running development for the Word, OneNote and Publisher teams and then half-way through the product cycle took over as VP for development for Office, directly in charge of development for the shared Office teams building much of the new UI infrastructure.
A lot of the deep history that Steven provides in this post going back to the very early days of Word and Excel was before my time. I arrived in 1996 with the FrontPage acquisition. I worked with all the Office teams as the FrontPage development manager, but it was only the Office 2007 product cycle (starting in 2003) that I moved into a more central role.
I did have a long history building graphical applications, starting in 1982 on custom graphical workstations. I had seen some of the same progression in UI density Steven describes for the Office PC applications, but a little earlier than the PC progression because I had mostly been working on workstation applications. Workstations had more memory and processing power and much bigger screens than PCs of the time so were not operating under the same set of constraints. For example, taskpanes added in Office 2003 had been a common UI feature in workstation applications over the previous decade.
I would say the biggest “hole” in Steven’s post was its almost sole focus on UI features, density and complexity. He talks about “winning the reviews” as driving much of this feature development, but mostly leaves off what those review-winning features were that were demanding so much new UI.
Really what was directly driving that UI complexity were new document content features. In a subsequent release, when we did a survey of the 1000’s of commands in Word, the vast majority of the commands were directly setting properties on the underlying content data structures. Office Art, which allowed you to directly create complex drawings in Word (and the other Office applications) added 100’s of new commands. New features supporting style sheets required new UI to control these new document constructs. In The Math of Easy to Use, I discussed how complexity in the underlying application data model inevitably leads to complexity in the UI.
Beyond the UI complexity around the document surface, all these new content features meant there was additional complexity directly on the document surface in the typical document that a user was likely to encounter. As document sharing took off with email and server-based document storage, users collaborated on documents with complex content that they had not created. This made it more likely that they were encountering documents that made use of features that they did not understand.
I can come up with tons of examples of complex document features that add confusion and complexity to the editing experience. (I am sure you can as well.)
What is that dotted line on the document surface? A page break? A section break? Why can’t I select it and delete it?
Why is this text laid out in two columns? Is that a two column page layout? Or a two column table? Or a text box floating on the page?
Why does adding one paragraph to this page cause this complex graphical figure to explode into pieces?
That last example is a member of a class of complex features that were specifically targeted around dynamic editing behavior to make the process of creating complex documents easier over the entire document lifetime. Graphical objects have a visual location on the page, but are also anchored at some logical point in the text flow. If that anchor moves to another page, its visual location might change significantly. This behavior is a feature — it means that as you edit a large document, the figures stay close to the text that is related to it. But if you don’t understand this, it can be confusing as hell. A common “bug” is that a document author would insert a number of graphical objects that were positioned visually relative to each other when created on the same page but where the anchor positions were scattered randomly around the text. Everything looks fine until subsequent editing and some of those anchors get split onto different pages. Then all hell breaks loose.
Of course, there’s another feature that addresses that as well (insert a canvas object and anchor all the graphical objects inside that object). And then there needs to be a whole class of other dynamic behaviors around (optionally) automatically inserting a canvas object when you go to first insert a graphical primitive or trying to infer which existing canvas object to anchor a new primitive graphical object in as it gets drawn on the page. Magical if you know what’s going on (and if your usage pattern matches the design point the feature was built around). Otherwise not so much.
As the design for the ribbon was being worked on, we got into lots of discussions about UI features that made it easier to create some of these complex document features but did not address the resulting complexity on the document surface. One feature we did end up doing (but were nervous about) was “Insert Cover Page”. This would insert a new section in order to start page numbering at the main content pages (you knew sections were the way Word supports alternate page numbering, right?). It would also typically (depending on style chosen) insert various custom text boxes to get interesting layouts. If you didn’t understand sections or using text boxes to achieve flexible layout, you might find yourself putting all the rest of the document content into that cover page section. (I see that more recent versions of Word use simpler page breaks rather than section breaks for most of the cover page styles it inserts.)
Multi-level lists have a special place in hell reserved for people to be tortured by trying to make them behave. Even though I’ve built multiple word processors, have managed the Word team and even worked on its internals, have written RTF importers and exporters for multiple apps, I can’t explain what all the features in that list dialog does (many of the features were designed around the requirements of complex legal documents and matching capabilities in other word processors like WordPerfect during the competitive feature wars). The ribbon added new UI to insert and make some limited changes but in some ways made it worse. One egregious bug was that after making some edits using the ribbon interface, if you brought up the more complex list editing dialog to even make a simple change (like change indent depth), the dialog was not preloaded with the current state of the list. This made it almost impossible to do a minor tweak as well as making it hard to understand what the behavior of that ribbon interface really was. (This was fixed in Word 2010.)
Lists are a good example of how complexity builds up over time because there were multiple interacting sources for that feature complexity. The first was just a “clean slate” feature design around the user requirements, especially where it was focused on particularly demanding users like lawyers with documents with very specific long-standing characteristics. Additionally, there were the competitive feature checklist battles that Steven alluded to. And finally, an important source of complexity was the need to import existing documents created by other applications (especially WordPerfect in the case of Word) with “perfect” fidelity. In many cases, this required matching behavior feature-by-feature (and sometimes bug-by-bug) rather than translating to a different internal data model. The desire to import HTML with great fidelity also generated a lot of additional feature requirements — and complexity — especially when Word became the default HTML email reading surface for Outlook.
There is one list editing behavior Steven mentioned that has an interesting personal history. If you are editing in a list and press return to get a new list item, pressing another return in that empty last list item will end the list. I thought Word did not get this quite right in a couple ways. For one, they would move that current paragraph out of the list, but then they would insert another additional paragraph. That seemed wrong, since normally you just want to type into that immediate trailing paragraph. Secondly, in a multi-level list Word would end the entire list rather than just moving out one list level.
I had implemented a different default behavior for a word processor I wrote in the 80’s (at the suggestion of a collaborator from CMU). That program only had a few thousand users (although those users included many of the inventors of the Internet). The behavior I implemented was that pressing return in that empty last paragraph simply moved it out one indent level. That made it easy to create multi-level lists by simply pressing tab to indent a new level and then return to jump back out a level.
I subsequently implemented this in all the word processors I worked on, including FrontPage. When I was put in charge of Word, OneNote and Publisher, I was able to convince the teams to change to match this list editing behavior. I always thought it funny that this word processor with a few thousand users ended up trailblazing the behavior for apps with billions of users. As well as all the other apps that model basic editing behavior to be “just like Word” — I notice Google Docs has the same list editing behavior as well.
My all-time top “feature from hell” is Word’s “Automatically Update Style”. When you have this attribute checked on a style, any time you change the formatting of a paragraph that uses that style, the underlying style sheet changes — which means that every paragraph in the document that uses that style changes. If you don’t know this is on (or likely didn’t even know such a feature existed) trying to edit a document with it on is an exercise in frustration and confusion.
I really could go on and on. The challenge is not (just) the UI, the challenge is the sheer complexity of the model being exposed in the application. Trying to expose a simpler UI without simplifying the data model is an exercise in futility (which was a significant basic obstacle in the Office Lite project that Steven described since document compatibility was one of the first requirements).
My “favorite” (gritting teeth) example of a bad experience when an application supports a more complex data model then it can effectively edit is just paragraph spacing in a rich text editor that doesn’t also expose controls to manage it (like Outlook’s rich text editing surface for many releases). This is both a simple enough and common enough example that it is easy to explain and relate to.
As experienced in Outlook, this was before they switched to use Word for all their content. By default, Outlook would define paragraphs without spacing between them — users would just throw in an empty paragraph if they wanted space between paragraphs (like the space you see here). The “right” way to do it is to specify paragraph spacing as a paragraph property. You could get this spacing to show up in the Outlook editor by pasting in text from some other application that supported paragraph spacing (like Word). The editor would show the spacing, but then you would have no way to get rid of that damn extra space!
You still see email messages flying around with bizarre spacing issues due to this issue.
HTML/CSS is a good example where the data model has gotten so complicated that a “generic” universal HTML editor (that tried to be useful for virtually any HTML you threw at it, like FrontPage or DreamWeaver originally aspired to) is essentially infeasible now. There are lots of HTML-based editors around, but they either define their own very limited data model (e.g. the Medium post editor) or restrict the HTML they gracefully handle to a very limited subset and otherwise just leave the user to thrash.
If you don’t (or can’t) simplify the data model, you are going to struggle greatly with simplifying the UI.
