About Marx and Engels, God and Angels
I don’t really know what for
But she looked good in 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 OpenOffice.org 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.
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.
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.
perfection not when there is
nothing left to add, but when
there is nothing left to take away.