Application responsiveness is like the weather
I used to live in Los Angeles, and I was always amazed at those “Best Places to Live” articles that failed to properly weight (in my opinion) the weather. Living in Southern California it’s easy to take for granted that the weather will be nice most of the time. If I even thought about the weather I’d simply look out the window and smile at yet another perfect day. Now I live in St. Louis, and I check the weather forecast online every day before I head out. Don’t get me wrong, I love St. Louis, but the fact that I could freeze to death if I dress wrong is a bit of a negative.
When it comes to usability, responsiveness is like the weather: everyone agrees that a slow user interface is a bad thing, but the moment some feature comes along that looks cute but runs a little bit like sap in winter we still have to deal with interfaces that suck because they’re slow. It’s important to remember that the CPUs in our computers today are roughly one hundred times as powerful as the CPUs of just fifteen years ago. Those CPUs managed a GUI that wasn’t that different than the computers of today.
So why are GUIs slow today?
Pervasive Multi-Tasking. Today’s computer is doing many more things than the computer of 1995. Open the Activity Monitor or the Task Manager and take a look. The Mac of 1995 also famously didn’t have pre-emptive multi-tasking. In a way that was a good thing: it meant that the program in front of you had the power to use as much of your 25MHz CPU as it needed to try to keep you happy.
Web Apps. They suck (with rare exceptions) because javascript is interpreted and it’s too easy to add features to web apps. At my last job I used the Zimbra email client. That thing ate my soul one second at a time. I found that I didn’t respond to email as well or as promptly because of the minor inconvenience of repeatedly waiting on Zimbra’s interface.
Eye Candy. It’s nice, and it can even be a usability boon, but the moment it slows you down it should go. It’s important here to distinguish between reality and appearance. Studies have shown that people are happy to wait longer for something that appears to be doing something than they are for something that gives no feedback. So if the eye candy is the zoom out-zoom in of switching applications on the iPhone, even if it makes the actual transition take a bit longer that’s a net win.
Innefficiency. I don’t know this for a fact, but it would seem there’s not enough eye candy in recent OSes to justify the hardware requirements they demand.
An example of instant done right
Back the 90s there was a company called Be that put out the Be Operating System. Initially it ran on custom hardware with two 66MHz CPUs in it (still ten to thirty times slower than what you likely use now). The Be reps did a demo where they would start a dozen or so applications and show that both CPUs were pegged at full utilization. Then they would grab a window and drag it around the display. Everything else slowed to a crawl, but that window would continue happily doing whatever it was doing, because the BeOS knew how to prioritize: it was an end user system, not a server, so whatever you focused on, that got the first shot at the CPUs. The reps would then repeat the demo, but with one of the CPUs disabled. Even with the same tasks that maxed out two CPUs, when they dragged a window around, while everything else nearly froze, that window was still immediately responsive.
That’s the way it was fifteen years ago, and there’s no reason why it shouldn’t be that way today. Everyone I’ve read who’s had their hands on the iPad says that it gives instant feedback in a way that other devices don’t. If it does, I’m looking forward to it.
Addendum: some things that should be instant but aren’t
- In the Finder, right clicking a file and selecting Open With. The submenu should be pre-calculated based on file type. For the few hundred most common file types that would take what, a few kb?
- Clicking Update in the WordPress editor for this post.
Geoff Canyon's Appeal to Authority 