Level: Introductory Peter Seebach (crankyuser@seebs.plethora.net), Writer, Freelance
01 Sep 2005 Customization typically offers users the ability to manipulate shiny objects, but not much real power. Wouldn't it be better to put the time into supporting a more powerful and flexible user interface?
Doubtless, most of my readers have whiled away an idle period
reorganizing a button bar. If you're like me, however, that's as far as
it ever went; it wasn't useful enough to merit much attention. In
practice, the overhead of trying to relearn a customized interface often
outweighs the marginal benefits of moving a few buttons into an
order that might be more intuitive. Besides, for most users,
customization at the level of reordering buttons in a button bar is
totally irrelevant; you're not going to gain anything but a vague sense
of accomplishment from the activity.
Most customization options do very little to alleviate repetitive tasks.
Cutting a few centimeters off of the total area a mouse travels in a 10-step process does not substantially alter the time it takes to perform the process.
On the other hand, certain customization options are very important, at least for some users. This month I'll discuss the variety of customization options available and talk about which ones are most useful. I'll also evaluate how well customizable software adapts to users' needs.
Appearance
Customizing the appearance of an application interface is a good
thing in theory. The ability to select UI colors you like should make you happy. Customizable font size, color schemes, and background images are
generally harmless and fairly easy to support. Sadly, though, such
changes aren't always as harmless as they look. For instance, the appearance of
an application is sometimes imposed by the operating system. Customizing
the application can result in it becoming unusable -- as often happens when you
set the font size on a Windows machine to anything but the default.
Similarly, if you adopt a different color scheme for a Windows or Macintosh
OS you may discover that some of your programs have been cheating, drawing their
own blocks of solid color instead of using the standard interface. Suffice to say that the results are ugly.
Application developers should take different platforms into consideration when designing customizable user interfaces. Some customization options
are good -- they certainly make users happy -- but the results can be disastrous
if taken too far.
Skins
Skinning, or replacing GUI widgets with custom-designed ones
arranged in a custom layout, is one of the most popular kinds of
customization. While skinning is without technical merit from a
usability perspective, users like it a lot-- when they use
it at all, that is. In practice, some users will pick a skin they find
appealing, many users will do nothing, and a fair number will
give up on the program in disgust because they can't figure out how to
make it do what they want.
Skins don't just change the appearance of UI components; they tend to reorganize them. In some cases a given component is omitted entirely. In
the worst case, it becomes a challenge to even find the Close button of an application.
To make matters worse, many skins abandon the essentially rectangular window
designs most users are accustomed to. This is a disaster, not just because it's confusing but because non-rectangular windows are consistently
on the fringes of UI support. Imagine a litany of things that
could conceivably go wrong and all of them probably have. I've had a click
inches away from a window activate it, or possibly even trigger an action as
though I'd hit one of the GUI widgets. I've had fascinating rendering errors.
I've had windows become impossible to reach or manipulate because the OS
placed them based on the bounding box surrounding them, instead of based on any
clickable part of the window.
I'm entirely unconvinced that skins improve user experiences enough to
justify the broad range of hassles they introduce. A certain amount of UI
tweaking is comprehensible to me, but skins seem to be practically designed
to make a user interface unusable.
Button bars and menus
Customizable button bars rarely make a program unusable. On the
other hand, I don't recall ever finding a practical use for them. A large
selection of icons too small to recognize is not a good start on an
interface, and it generally goes downhill from there. On the bright
side, customizable button bars are a widespread and easy-to-implement
feature; they don't soak up a lot of development time, and they
generally work. Button bars are most useful for people who rely on
features that are obscure to most users.
Tooltips are helpful, but if they're necessary past the acclimation
period they're probably not a worthwhile investment. The time spent
waiting for a tooltip to show up is just as much wasted as time spent
browsing through menus.
Customized menus can easily be much worse. One of the points of
menus is that, in principle, they offer the complete range of available
functionality. If you hide that functionality users might be
unable to find it. In most cases, keyboard equivalents are a
better avenue of exploration; users can easily remember the most useful
keyboard commands and menus can still offer the full range of
functionality.
Preferences
Well chosen preference settings can really make an application shine
-- if they're well executed. For example, a popular feature lets a
program open new file dialog boxes in the same location as the
last-manipulated file. This is a nice feature. Programs that start
in a fixed location almost always pick the wrong location; for instance,
a special newly created directory for that program's documents, rather
than the directory I keep all my other documents in. It can get very
frustrating, especially when combined with other interface quirks.
A program I once used a lot (I admit, "just" a video game) used, loaded, and saved several kinds of data files, each of which was stored in a different directory. The custom file dialog boxes for the program always started in the root of the program's installation, though. Because a number of subdirectories
didn't have relevant files, the process of loading or saving a file
necessarily involved scrolling down a page or so in the list. Because the
file dialog box was custom, of course, it didn't support the Page Down key
or any kind of scroll wheel, or even the convention of clicking inside the
scroll bar to move a page at a time: you just had to click on the arrows until you got to the right page.
It's natural for users to want different settings for various UI components and behaviors. For instance, a graphics program might remember whether you like images scaled to fit the page when printed, or prefer them printed at original size. Both options are reasonable to want, so a preference setting is a wonderful addition to this feature. Likewise, remembering window locations and sizes can make life much easier for users. Fortunately these preference settings are fairly easy to arrange.
In conclusion
The trick with customizable features is to focus on making a real
difference for users. Offer useful and flexible settings for primary
program functionality. If you're torn between conflicting demands from
different users, add a preference setting. On the other hand, avoid
pure glitz; it's only fun for a few minutes. Replacing every UI
component with an unrecognizable image gets boring fast -- and can be
incredibly frustrating if it tampers with the program's functionality.
Do account for preferences set outside of your application, such as
font size. Applications that assume a "standard" font size are sometimes
inaccessible to people with poor vision or high-resolution displays.
Whenever possible, use the system's API instead of scribbling your own
pixels on the display.
Don't offer customization just so you can say your application is
customizable; offer it in cases where you know users will have
differing needs that you can best address by offering them a choice.
This week's action item: Go through the entire preferences
list for a program you use regularly. Are there any preferences you wish you had set months ago?
Resources Learn
Get products and technologies
Discuss
About the author  | 
| | Peter Seebach has been using computers for years and is gradually becoming acclimated. He still doesn't know why mice need to be cleaned so often, though. |
Rate this page
| 
