Mutated Controls

One can forgive poor interface design as a consequence of laziness or time constraints. Crap design is less understandable when extra effort was expended to achieve it.

What's the fascination with skins and garish, non-rectangular interfaces nowadays? Hasn't anyone noticed that rectangles utilize space better? That a consistent look makes things easier for the user? Whatever happened to the "if it ain't broke" slogan? Standard controls work the way they do for a reason. A good deal of research and testing have gone into choosing their colors, sizes and functionalities. Users are familiar with the way they work and expect a control to function the same way from one app to another. Control attributes that are meant to be mutable are exposed through the API. Want a combo box to be editable? Set a flag. Want a combo box to allow selection of multiple items? The fact that such a setting is not available in the API is a good sign that it's not a great idea. It's not impossible to build a better mousetrap but the odds are against you.

Of course there are always programmers who want to show off their low-level programming skills or just make something 'kewl'. These are the same people who insist upon wasting weeks on useless and buggy features that could be more cleanly implemented in a day by a hack with a 'for Dummies' book. We've no sympathy for such gluttons for punishment. Programming is complicated enough without scads of code for re-inventing the wheel. The goal should always be to meet design specifications with the minimum amount of complexity. As many have heard before, "laziness is sometimes a programmer's greatest virtue." Even when developers don't introduce new bugs, they force team members to become familiar with extra code and force users to absorb a new paradigm.

Our perennial whipping boys at Nullsoft go way over the top with widget tweaking. There's hardly a single feature that looks or functions normally. Buttons act like menus. Icons act like buttons. Labels act like tabs. Checkbox menu items act like radio menu items. WinAmp is like a Windows control masquerade. Rather than pick one of numerous easy targets, we'll focus on a control that they almost got right: the scrollbar. Our quibble is minor but demonstrates the subtle problems that can be introduced through haphazard control customization.

Never mind that the playlist scrollbar doesn't look like a standard application's scrollbar. Temporarily concede that looking cool and different is a worthwhile pursuit. The most notable problem is that the WinAmp scrollbar provides no way to jump through a list one page at a time. Actually, so far as we can tell there is no way to do this with the keyboard either.

The WinAmp application is awkwardly segmented into four separate apps (WinAmp, Equalizer, Playlist, Minibrowser). The arrow and PgUp/PgDn keys are not even active until the playlist 'sub-app' has focus. Why this is necessary is beyond us since these buttons seem to serve no further purpose in the entire WinAmp program. Perhaps this is WinAmp's way of telling us where the focus is; there are precious few visual clues. Even when active, though, no keys will scroll the list more than a few lines. Unless you count 'Home' and 'End', which jump to their respective edges of the list.

"No big deal," we thought, "We'll just use the mouse". Using the scrollbar, however yields even more bizarre results. Breaking tradition with every other Windows app we've ever used, WinAmp does not allow the user to click above/below the scrollbar's slider in order to jump up/down a full screenlength. Instead, the slider moves immediately to the clicked location. Not only is this non-standard behavior but it is also less functional than the default implementation. Using either a standard or WinAmp scrollbar, users can already quickly drag a slider to any location; it's easy to get to a general neighborhood within a huge list. With a standard scrollbar, though, a user can also click above or below a slider in order to jump a page at a time. Without this functionality the finer navigation required when a user has neared his destination becomes more difficult. This can make the tail end of a search excruciatingly long when traversing large lists. Thus, WinAmp's behavior duplicates existing functionality by discarding a useful feature. Similar arguments could be made about most customized controls.

Let's play 'find the focus' ... So many unlabelled controls, so little time...
Man, I just wanted to check out the rest of your Blue Oyster Cult collection...

We don't expect a developer to take such a minor detail into account: he shouldn't have to. That's why default implementations exist. If one is going to override a standard, he ought to have some reason other than 'it looks a little cooler this way'. Default implementations may not look unique but they work, are easy to implement and can be customized by power-users through a standard API (see StarDock WindowBlinds/ObjectDesktop, MS TweakUI, Xteq X-Setup, etc.). Through this approach, customizations are more useful: to some degree, users can give other apps your custom look (and vice versa). God forbid if a visually impaired person tries to use WinAmp...