Coyote Tracks

If you’re going to reinvent the wheel, you should at least make sure your new version is somehow better than the previous kind. Reimplementing standard UI and OS widgets is one of the most common ways developers reinvent the wheel these days — it started with Flash developers building their own controls, and has now spread to Adobe AIR and Silverlight.

It might be a welcome trend, if the replacement widgets people were building had more functionality than the OS-native ones that are available for free in any other context. But usually, the widgets I see in these frameworks have less than half the functionality of the things they try to replace. I’m going to pick on scroll bars for now, because I’ve seen them horribly mangled too many times.

To start with one aspect of scroll bars that we often take for granted: Can you guess which of these text boxes contains more text?

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Quisque est est, luctus quis suscipit et, lacinia ac odio. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Quisque est est, luctus quis suscipit et, lacinia ac odio.

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.



Of course you can; you don’t even need to guess. The one on the left has more, and you can tell immediately because the movable slider on its scrollbar is smaller. This is a feature you get for free from the native OS widget, and one I have never seen implemented in a Flash, AIR, or similar interface.

Here are all the things a native scrollbar does. I absolutely guarantee you, if you’ve reinvented a scrollbar, your implementation is missing at least two of these features:

1. As mentioned above, the slider object changes size automatically, to give a general impression of how much content the scrollable area contains.
2. The arrows at the top and bottom of the scrollbar are clickable, and clicking them once will move the content up and down by a small amount (typically 1 or 2 lines).
3. Clicking and holding the top and bottom arrows will cause the content to scroll more rapidly.
4. Clicking and dragging on the slider will scroll the content smoothly to any position the user chooses. (Yes, I have seen scrollbar implementations in which the slider was not a draggable item!)
5. Scroll wheel support: If the user’s hardware includes a scroll wheel, scrolling it will move the content up and down. This is many users’ preferred method of scrolling content these days, and yet it’s totally ignored by over half the Flash interfaces I’ve encountered in the past year. I’ve bolded it because it’s the one that gets so egregiously ignored.
6. The “gutter” in between the arrows and slider is also clickable. Clicking on it once will scroll the content up or down by, roughly, the size of the visible area (a “page”, as it were).
7. Of course, clicking and holding in the “gutter” area will repeatedly and rapidly scroll the content. (This is rarely apparent unless you’re dealing with a tall scrollable area and a fairly long document. Try loading a 25-page or longer document into a word processing program, and set the program to full-screen.)
8. When the content is scrolled (by whatever method), the slider will move up or down to indicate how far from the beginning or end you are. (Essentially the converse of item #4: Moving the slider scrolls the content, and scrolling through the content moves the slider.)
9. The arrow buttons and the gutter area give a visual indication when they’ve been clicked, so the user has better feedback. (This is one of those little things that makes the user experience so much better. It’d be so easy to do, and yet I’ve seen about 2 Flash scrollbars in my life that have bothered with that feature.)
10. If you set your cursor focus on the scrollable area, using the up and down arrow keys will scroll the content. Either the Home and End or Ctrl+Home and Ctrl+End keystrokes will move directly to the beginning and end of the content. The PgUp and PgDown keys may also move the content by an amount similar to clicking in the gutter.
11. The scrollbar — including its arrows, gutter and slider — looks just like every other scrollbar on the user’s computer. The user can immediately identify the items and finds them familiar.

Even if you have done a smashing job of replicating the first 10 points on this list, you simply can’t get the final one in an AIR, Silverlight, or Flash interface. If your whiz-bang interface platform provides some other benefit, then dropping that last feature might be worth it.

But it’s no excuse for dropping all the other stuff. Most non-native scroll bars I’ve seen support only 3 or 4 of these features, which means anyone who normally uses any other ways of interacting with scrollbars winds up cursing and deciding that this broken implementation is cheap and chintzy.

Which it is. If you’re going to reimplement the wheel, at least make it something that will roll smoothly.