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.
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.
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.
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.
