Chad Perrin: SOB

30 April 2009


Filed under: Geek — apotheon @ 11:18
I tried to tell her
About Marx and Engels, God and Angels
I don’t really know what for
But she looked good in ribbons

– Sisters of Mercy, Ribbons

The Microsoft Office 2010 preview screenshots at Neowin look awful. Seriously, it’s ugly and cumbersome as hell. It’s the kind of thing that makes me wonder why anyone uses software like this, even pays money for software like this. It’s a study in poor interface design. It looks like hell.

Of course, in some respects, this is actually an improvement over earlier versions of MS Office. The interface of is no peach, either.

The key characteristic of the MS Office 2010 preview interface is the Ribbon — something that’s not exactly new to the 2010 version. It is, at the same time, both a great idea and a terrible travesty of interface design.

Over the years, office suites have gotten more and more complex. Feature creep has loaded office application suites with so many buttons and menu items and so on that eventually something had to be done to avoid making the application start looking like Internet Explorer circa 1999 with half a dozen malware toolbar add-ons. Over years of evolution, “clutter” had become the defining characteristic of office suite interface design, because there was simply no way to show everything software vendors wanted to show without ending up with a cluttered interface.

MS Office Excel Ribbon

Two major “innovations” — radical changes in office suite interface design philosophy — have been developed to deal with the problem. One of them is a context-dependent dynamic interface design incorporated into new versions of Microsoft Office called the “Ribbon”. The other is the Google Docs approach.

MS Office’s Ribbon is actually a pretty smart answer to the problem of making an interface navigable when you have hundreds of features you want to make available when needed at the user’s fingertips. For every change of interface context, a different set of features is made available. Similar approaches to menu design for complex Website design have been around for years, but they tend to be more simply and directly hierarchically constructed, which doesn’t scale well to hundreds of options, even though they’re nothing more than menus. The Ribbon scales much better to that level of interface complexity.

Actually, the Ribbon scales much better to an even greater level of interface complexity. Because what the Ribbon provides isn’t a hierarchical file structure — because it’s a set of features that are not so easily categorized — the complexity of the task of organizing them is considerably greater. Despite this, the Ribbon does a better job of providing a usable interface than Websites with context-dependent menus that have cluttered collections of documents often do.

That doesn’t make it a good interface, though. Ribbon interface designers talk about how they have done usability testing and determined that people visually scan differentiated icon blocks better than uniformly organized blocks and achieved all kinds of great advances in interface design for the purpose of managing gigantic collections of clickable features in a sustainable, usable manner. They’re right, too — they’ve done great work on mitigating the problem of cluttered application design. The problem, though, is that all they can do is mitigate it as long as good interface design isn’t allowed to take precedence over feature creep in application design. Sometimes, you run across the price that has been paid for that mitigation, such as when you want to lock a document and discover that the feature is effectively inaccessible when you need it.

No matter how inventive you get with your interface design philosophy, a cluttered feature set in an application will create problems for the design of its interface — either features will be essentially hidden away where you can’t easily get at them (or even find them), or the application will take on a cluttered look. Unfortunately, the very idea of an office application suite is itself the genesis of office suite clutter, because too many separate types of applications are being integrated into a singular whole — and design considerations for each separate application type in the suite will affect the design of the other application types, cluttering them up. The Ribbon is just the most recent delaying tactic in the battle against intolerable clutter.

For a less cluttered application, the Ribbon would be a terrible interface design feature. The only reason it has any value to speak of at all is that, while it’s awful at the low end of the application complexity scale, as application complexity grows, its own awfulness grows much more slowly than previous interface design philosophies. Past a certain point of complexity, which was passed by the major office suites’ infectious featuritis years ago, something like the Ribbon becomes the better alternative.

Google Docs Icon Bar The Google Docs approach to office suite design produces something much better approximating actually good interface design, and that approach is simple: eliminate features until you get things under control again, and can make the interface more elegant, simple, and clear. When you reduce the complexity of the application’s feature set itself, you get an application whose interface can be actually improved, rather than merely having its awfulness mitigated somewhat.

If Google wants Google Docs to eventually achieve the kind of perfection to which Antoine de Sanit-Exupery refers in his famous quote about simplicity of design, it still has a ways to go. In contrast to MS Office development over the last couple decades, though, it is at least moving in the right direction.

A designer knows he has achieved
perfection not when there is
nothing left to add, but when
there is nothing left to take away.

– Antoine de Saint-Exupery


  1. Best analysis I’ve ever read of the ribbon. I’ve been trying to explain forever to people that the ribbon is a much better way to organize a feature set as massive as Office applications have than the giant menu tree and equally sized sqare icons. But, as you say, the real issue is that the feature set is entirely too massive to begin with.

    Office’s UI downfall is that its mission is to be potentially useful in every imaginable scenario. When you try to stisfy everyone from screenplay writers to paralegals to engineers, you are bound to have a debacle. I would love to see Office applications have some sort of “I’m doing XYZ” mode or “my job is ABC” system so that it could slash the readily available command set to what is actually useful. Someone writing a novel doesn’t need table tools, but someone writing a technical reference probably does, for example…

    No easy and usable way to do it, unless they want to release a “Word Light” for basic tasks (hint: beef up OneNote slightly), and then have a “Word Heavy” where you spend a few moments prepping the app to be useful to you before starting to work.


    Comment by Justin James — 30 April 2009 @ 07:09

  2. Thanks for the kind words about my analysis of the Ribbon.

    My take on how to break up the functionality logjam a bit is to basically make modular applications that can be fit together a bit like Lego bricks. Apply the functionality you need in the configuration you want, and go to town. Start with broad task classes of functionality, and fine-tune the specific functionality you want as you go. Build a profile that can be reapplied to later upgrades of the software to get close-to-perfect application feature sets, with minimal fine-tuning even when working with an upgrade. Bring your profile with you when moving around, maybe a bit like an emacs config file — but, ideally, more like a hexadecimal code (that’s really short so you can remember the damned thing) that essentially acts as DNA for the specific species variant you want to use, allowing you to plug it into any fresh install and get instantly gratifying results.

    I dunno. There are options for how one could turn an office suite into a much more modular, specialized tool perfectly suited to one’s own needs, without a bunch of crufty nonsense cluttering up the interface. The first thing that would have to go, though, is the core notion of “office suite”. The whole point is that you not only don’t need, but don’t want a does-everything application.

    Comment by apotheon — 30 April 2009 @ 08:01

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License