User Choice, Customization, and Confusion

Tuesday Jan 18th 2005 by Mike Gunderloy

When to allow and when to avoid making it possible for users to customize your applications.

Almost every Windows application offers the user some choice in the way that it works. Whether it's a matter of adding buttons to toolbars, selecting options from a menu, or picking an entire "skin" to change the look of the application, users have grown to expect customization. In this article, I'll discuss some of the ways that you might offer customization, as well as some of the pitfalls to avoid.

The Default Choice: No Customization

Before you rush in to implement code allowing the user to customize something, think about the low-cost, low-risk alternative: don't write the code at all. Instead, design the feature the best way that you can, and then leave it that way, giving the user no control over form or function.

There's one big advantage to not allowing customization: This approach lowers support costs. If you allow the user to customize the user interface, then you must check during any support communication to see whether they're using the stock user interface or not. This leads to additional time spent doing support, and additional confusion on both sides of the conversation.

On the other hand, if you don't allow any customization, users may feel that you've left something out. Even if you don't believe the customization will add anything to the application's functionality, users may feel cheated if they can't customize toolbars in your application just like they can in other applications. On the whole, you probably won't be able to get away with a hard-nosed "no customization" stance.

Sometimes a Little is Enough

If you've decided that you must offer customization of a particular feature, the next decision is over how much to offer. Consider the common task of letting users add, remove, or rearrange buttons on a toolbar. Figure 1 shows the customization dialog box for Windows Explorer. You can add, remove, or rearrange buttons, and set a few options.

Simple toolbar customization

Now, you might think that would be enough control over toolbars to satisfy any user. So would I, for that matter. But apparently the Microsoft Office team disagrees with us. Figure 2 shows just a part of the customization options for a toolbar button in Microsoft Excel 2003.

Advanced toolbar customization

In general, I urge you to stick with the simplest possible customization scheme in your own applications, for several reasons:

  • Less customization means less code to write, meaning fewer bugs in your code.
  • Less customization means lower support costs, because the user interface won't flop all over the place.
  • Less customization means a shallower learning curve for users, who won't be faced with such a plethora of options.

Colors and Skins

Every application should allow the user to customize the colors for its display - even though only very rare applications should have any user interface to enable this customization. How is this apparent paradox resolved? The answer is that Windows offers its own facility for color customization, which is available through the Control Panel Display applet. By sticking with this uniform interface for color customization, you can keep your application's user interface looking the way that the user likes their applications to look. As a bonus, you don't have to write code: just use the colors provided by the system.

At the far end of the customization spectrum from using system colors is the increasingly-common use of "skinning" to customize applications. Some applications, such as many music players, let you change every aspect of their interface. This applies not just to the colors used, but also to the location of controls, shape used for the main window, size and position of the Windows controls such as the minimize button, and so on. Skinning lets artistic designers rearrange an application to look like anything from a block of wood to a futuristic toaster. Figure 3 shows Windows Media Player with a skin applied. If you didn't know in advance, you'd be hard-pressed to identify this as a Windows application.

Windows or nightmare?

Although you can buy frameworks that enable skinning for your application with little or no work on your part, I believe that you should think long and hard before doing so. On the plus side, a skinned application undoubtedly gives the user the feeling of being in complete control, and lets them make their system look "cool." But on the minus side, such applications fly in the face of all the conventions that make using Windows easier. Your application may look more futuristic when skinned, but it will be harder for most users to use. In almost every case, that's a bad tradeoff to make.

The Dreaded Tools...Options Dialog Box

All of the customizations that I've discussed so far in this article have been very generic. They apply equally well to a great many applications. Beyond that, of course, your application may require its own customizations. For example, there may be a default directory where you look for templates, or perhaps a set of colors that you use when portraying new objects on a drawing canvas. Such choices are typically wrapped up in an Options dialog box accessed from the Tools menu.

Many applications today expose dozens or even hundreds of customization options in this way (Microsoft Office applications are prime offenders in this regard). With software being as large and complex as it is, it's easy to understand where these choices come from. Developers look at their work and realize that they're about to hard-code something: a number of files, a path, a display status. Rather than placing a constant in the code (which we're all trained to think of as somehow inelegant) they decide that this is something that could be put under user control. And presto! Another user customization option is born.

The fallacy here lies in the assumption that just because something can be placed under the user's control it should be placed under the user's control. When faced with the opportunity to add another customization option to your application, you should consider three questions:

  • Is there a single best setting for this option that will be optimal for every user of the application? If so, you should code that setting and eliminate the option.
  • Is the option setting something that will only need to be updated only occasionally by power users, perhaps with the aid of technical support? If so, you should consider exposing it via a Registry setting rather than in the user interface. Alternatively, you can ship a separate utility application that performs the customizations, but which won't be obvious to the casual user.
  • Is the option setting something that the user will only choose only once? If so, prompt for it during installation rather than exposing it in the user interface.

Be Smart About Customizations

As with many other things choices in user interface design, there are tradeoffs here. The more users you have, the more likely it is that someone will appreciate the ability to change some setting that you thought should be fixed. But the more settings you expose, the higher your support costs will be, and the more confusing your application will be. Most users seem to feel that dialog boxes which spread dozens of option settings over several rows of tabs go too far.

It's all too easy to say "Oh, add an option" when you're developing an application. But keep the end user in mind before you do so, and try to decide whether there's another approach that makes better sense. That will help both you and your users in the long run.

Mike Gunderloy is the author of over 20 books and numerous articles on development topics, and the lead developer for Larkware. Check out his latest books, Coder to Developer and Developer to Designer (from which this article was adapted) from Sybex. When he's not writing code, Mike putters in the garden on his farm in eastern Washington state.

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved