Customization In UIs

Jensen Harris has an in-depth look at the customization choices made for Office 2007 and why they made them. I’ve always been a proponent of getting the UI right in the first place and only providing limited or no customization abilities. Mostly this stems from Raskin’s The Humane Interface:

The central point of this issue is that if we are competent user interface designers and can make our interfaces nearly optimal, personalizations can only make the interface worse. Therefore, we must be sparing and deliberate in offering user customizations. If a user can, by a few judicious choices, really improve the interface, we probably have done a poor job.

The exception in this case is also notable:

On the other hand, if a program’s interface is as dismal – to voice an opinion – as that of Microsoft Word 97/98, the situation is reversed. Almost any change the user makes is an improvement, to exaggerate only slightly.

The statistics that Jensen quotes shed a very interesting light on the benefits, or lack thereof, of customization:

Looking across a hundred million or so people using Office 2003, here’s what we found:

• In fewer than 2% of sessions, the program was running with customized command bars.
• Of the 2% of sessions with customizations present, 85% included customization of four or fewer commands

So despite all the vocal demands for customizable software that you hear, and that no doubt will turn up as comments to this post, less than 2% of people actually use customization features and of them, the vast majority only customize four or fewer commands. Jensen goes on to note that most users who do customize tend to make the same customizations. This of course indicates a defect in the UI design, rather than an argument for customization – if the design is corrected an even greater number of people will have no need for customization.

I also found it interesting that Office provides an XML format for customizing the layout of the ribbon, RibbonX. This is actually an approach that I consider has an awful lot of merit – it is the same method used to provide customization of the UI in EditLive! for Java.

The key advantage of using an XML format instead of a UI as in previous versions of Office is that the customization features are effectively hidden away from all those users who don’t care about it, but available for system administrators and company-wide policy makers to change things to suit that particular organization. For EditLive! for Java, this is mostly used to remove functionality from the editor to restrict what user’s can do. For example, removing the font face and font size controls is common to encourage or force users to use CSS styles and more semantic markup.

Finally, Jensen also touches on another common area I seem to argue about a lot – floating windows:

The story with floating UI is similar. Floating toolbars in Office 97-2003 caused a lot of problems, primarily because they were forced on people as the primary means of accessing many features. As a result, toolbars were always popping up over top of what people were working on, needing to be dragged out of the way, or mistakenly docking to the side of the screen.

Our design mantra for Office 2007 was that default feature access wouldn’t rely on floating things popping up on top of the document; the UI would be in a single, consolidated, consistent place.

Amen to that.