Tag Archives: user interface

The Fifth Bottleneck

CodingHorror points out that the game of “find the bottleneck” that is computer performance optimization is always looking for a bottleneck in CPU, disk, network, or memory.

But there’s a fifth bottleneck — a fifth resource most applications wait on. The user.

If an interface is too difficult to understand, or if an action takes too many clicks or keystrokes, the application will be stuck waiting on the user. If an interface is really bad, the application will sit idle while the user is searching for “how to do X in ProApp 8.0,” or reading the manual, or asking their friends for help, instead of working. And the ultimate interface failure, when a user decides to stop using an application, means, from the point of view of performance, that it will never complete — it’s blocked forever.

Sure, a bad interface won’t slow down a computer. But it does slow the user down. And that’s why programmers care about performance – because we humans want to complete our tasks faster, not because we want computers to complete their tasks faster.

Worst website ever

Zzzphone.com. Excessive use of flash. Unsolicited, over-compressed, auto-starting audio (on the specs page; there’s no surer way to get users to leave a site and never come back than automatically assaulting them with unexpected audio when the page loads). Random fonts and sizes, and graphics containing text. Best part: click on the shopping cart link at the bottom of the page (obviously without ordering anything first), and this comes up:

Step 3 of 6? Am I allowed to skip steps like that? Buy another nothing? Can I get a discount on that? (via Max.)

Oh, and in case anyone out there needed reminding that you can design complex, interactive, highly graphical sites in HTML without Flash, check out Shiftn’s Obesity System Influence Diagram.

The third flavor of focus-follows-mouse

Steve Yegge’s excellent Settling the OS X focus-follows-mouse debate explains why OS X’s application-centric paradigm, with its application-global menu bar, doesn’t work so well with focus following the mouse but no automatic window raising. Background windows, attached to background applications, can’t, and aren’t expected to, listen for modifier+key events, because the application’s menu isn’t active.

The lack of focus-follows-mouse on OS X is one of the biggest reasons that I stick with Linux and Xorg on my main machines. Whenever I use one of my Macs for an exended period of time, I feel like a marathon runner who’s had to trade in his sleek running shoes for a pair of swimmer’s flippers. If there was a third-party tool to provide focus-follows-mouse on OS X that worked properly, I’d install it in a heartbeat.1

Yegge also points out that the auto-raise flavor of focus-follows-mouse is a taste only an epileptic could love. Set the auto-raise delay too low, and moving your mouse across big windows towards a smaller target window, or moving it too slowly, causes a cascade of ugly, annoying window raises and destroys your carefully crafted window tabbing order. Set the auto-raise delay too high, and you’re waiting too long for windows to focus once you’ve got the mouse there. In my experience, there’s no delay setting that works — every setting is too high, too low, or both.

But there’s another flavor of focus-follows-mouse, that, as far as I know, is only available via a third-party plug-in to the semi-abandoned and deeply buggy Sawfish window manager. It’s a flavor that is evocative of ripe nectarines and raspberries on a summer afternoon. And it’s so good it’s kept me using Sawfish despite its abandonedness and bugginess.

It’s called stop-focus, and it works like this:

  1. While the mouse is moving, don’t raise windows.
  2. Once the mouse has stopped, raise the window it stopped on.

“Stopped” is defined as below a certain configurable velocity (ten pixels per second works for me), and windows are only raised after a short (200ms) delay. Stop focus lacks the cascading window raising behavior of auto-raise. Moving the mouse across slowly across several large interim windows doesn’t raise them or screw up window tabbing order. Starting to move the mouse to another window, and then stopping and moving it back to the currently focused window, which you and I do more often than we care to admit, doesn’t cause any window raises at all.

So, while focus-follows-mouse without raise-on-focus (Yegge’s preferred autofocus), may not be feasible on OS X right now, there is a variant on focus-follows-mouse, with sane rules about when to raise the window under the pointer, that might make all us old focus-follows-mouse Unix relics happy.

If I were an OS X hacker, I’d probably just go code this up right now. But I’m not, because, among other things, OS X’s mandatory click-to-focus bugs me too much. Chicken, meet egg; Egg, meet chicken.

  1. One of the other big reasons I don’t want to switch to OS X is that, for reasons I won’t get into here, the global menu bar really bugs me. Funny that these two gripes of mine turn out to be intimately connected. []

Why your Flash website sucks

your_flash_website_sucksThis all-Flash interface (screenshot) is a complete reimplementation of the WordPress blog interface; One single Flash widget fills the entire browser page, and implements not only the home page, but categories, comments (including posting), and article pages. It sounds like the author intends to use it to replace the HTML interface to his blog entirely. It’s a great example of why you should never build an entire website purely in Flash.

Continue reading

Rethinking the Progress Bar

Rethinking the Progress Bar doesn’t really rethink it so much as prove what should have been obvious; people prefer progress bars that speed up as they reach the end, rather than progress bars that slow down towards the end. Execute your unpredictable-duration activities, like network transfers, at the beginning of your code, and your predictable-duration activities at the end.

I wonder why we’ve never seen progress boxes or regions, that express two simultaneous processes by growing in two (or more) dimensions simultaneously, at different rates. Seems like you could map one dimension to radius and the other to angle, and have a progress region that progresses from a single center point, to a wedge, and finally to a filled circle. Probably too complicated, but I’d love to find a use for that.

Internet, meet Spydentify

spydentify-400x107Spydentify is a new experiment/side project of mine. It fills a niche that I first identified over at the Typophile Type ID Board: people love looking a pictures and trying to figure out what’s in them. The site’s interface is designed to be as addictive as possible, with a neverending, rapid flow of interesting images, big, shiny buttons to click, and instant feedback on your actions. I’m going to add more ego-stroking, viral-spreading and moderation features soon.

The interface also follows the MVC pattern I laid out in this article. It uses one static HTML file, all dynamic data is loaded through XMLHTTPRequest (AJAX, for those of you who speak Web 2.0), and all HTML generation is done via JavaScript manipulation of the DOM. The backend uses Pylons, which gave me a chance to learn Pylons, Paste, Routes, SQLAlchemy, FormEncode, and Mako. And comments are rendered with my own PottyMouth.

I also designed the logo all by myself.

Check it out.