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.
June 28th, 2006 at 9:14 pm
I have used every version of MS Office, Star Office, Open Office, Wordperfect etc etc and I have to say the context sensative office 2007 menu structure isa godsend compared to anything I have ever seen before
June 29th, 2006 at 7:56 am
You say, “… 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 …”
That’s probably correct when the customizations in question are additive, but not otherwise. If 10% of your users customize, and of these, 80% remove Button X (or replace Button X with Button Y), your rule might prompt you to remove Button X from the default UI. But then you might just tick off a lot of the 92% of your user base that were fine with leaving Button X where it was.
June 29th, 2006 at 8:12 am
Considering the context in the Jensen’s post, I think it’s pretty clear that’s not the case. Besides which, I’m not sure why people would remove a particular button rather than just ignore it. If they were to remove a number of buttons, they may be trying to save screen space but one button is a total of about 12-16 pixels so it’s not worth the effort of removing. If they did just remove a particular button and you had evidence to show that other users used it a lot, you would simply ignore the user who customized it.
June 30th, 2006 at 12:05 am
Adrian, I’m sorry I don’t follow your first sentence. Perhaps you could clarify.
As to why people would want to remove buttons, I don’t know. But they do. From Jensen’s post: “The most popular single customization? Removing the ‘Read’ button from the Standard toolbar in Word.”
So if 2% customize Word, but they all remove the “Read” button, I don’t think that indicates the presence of the “Read” button in the default UI was a mistake. As to whether we need to allow them to remove the button at all, that’s a different question.