Open thoughts about… performance

Written by
Matthias Wagler
01 December 2010

Photo by dodge challenger1

Very quickly mobile computers (a.k.a Phones, Tablets, Communicators, …) have become our central hub to interact with the rest of the world. I’d like to talk a bit about something I’ve observed over the last months while using and crafting mobile interfaces. Because there is one particular aspect of an interface in this context that can ruin or glorify the experience you have with it: its performance. I think that this is one of the most important driving factors that have led to the recent success of Apple’s product range. And as we all know Apple is really putting a lot of effort into not losing the control of hardware performance.

But hey it’s 2010, why do we still have to take care about performance when designing and building applications? On the one hand these little gadgets don’t have that much computing power yet. On the other hand multitouch is currently the prominent way of interacting with mobile computers. Which means that most interfaces deal with direct manipulation. This kind of UI needs to react even faster to your behavior than your average desktop app. Otherwise this can be a very frustrating experience.

Most interestingly, great performance apparently can balance negative aspects of a product. If an interface provides stunning feedback, people tend to forgive small usability flaws much faster. So what can we learn from these insights when designing stuff for a mobile context? We should not only design for joy of use and for usability. We should also design for performance.

First level of performance optimization: Dropping features and design kitsch

There are some questions one should have in mind when designing for a mobile UI: Does this new feature slow down my device? Does this alpha gradient ruin the scroll performance? If yes, should we drop it or can we find a simpler solution? As performance is such an important aspect for the overall product experience as well as for customer perception we should do everything to keep the product as responsive as possible. The easiest way to build a responsive UI is to kill features that may spoil it. And as Jason Friedman mentioned some time ago: Saying no to features is generally a good idea when crafting interfaces.

Second level of optimization: Shaping the assumed performance

Convincing a client or fellow designer to skip that much-beloved feature is certainly a tough one. So what about another tool to optimize performance: just fake it. Or in other words you can shape the “assumed” performance.

What the heck does that mean? Well, if you’re in a situation where your device lacks performance, for example because it’s doing some heavy lifting and pulling data from the web, you can tweak our minds with some simple tricks. Delay those tasks that commonly eat up your performance, even if it’s just a few milliseconds. Favor touch feedback instead, add a progress indicator and then start the actual task. Buttons that don’t give a feedback on tap or scrollable lists that hang while you’re pinching can be a real downer. These tricks can speed up the assumed performance of a product. So, nailing it down to a few simple rules:

  • Give touch feedback as fast as possible, every millisecond counts
  • Make your app feel responsive by using swift (hardware accelerated) transitions and animations
  • Let your customers know when your interface is doing something by using progress indicators
  • Make progress indicators fun. There are thousands of possibilities to entertain people while they’re waiting -  just don’t pick the obvious one

Let’s check out an example. The following video is a little iPad HTML Prototype that grabs photosets from flickr and displays them in a list. If you tab on a set you can then swipe through the photos. The scroll and swipe interactions have already been optimized with hardware accelerated animations for fast feedback but still loading large photos from the web can take some time. So we added a little message to let you know about it…

Now we’ll look at the prototype again. This time we’ve tuned the progress indicator. It’s now being animated in and out smoothly and it comes with a little animation telling you that this app is currently doing everything to get your photo from the web. Let’s have a look…

If you actually use it, you’ll see that waiting in the second prototype feels not that long although it takes the same amount of time.

The bottom line

This is not a huge insight, it’s just something that you should keep in mind when designing mobile interfaces. The constraints of this mobile context can really help us to focus on simple principles again. Focus on simplicity, focus on performance.

Shout outs

The scrollable list in the prototype is built using the fabulous iScroll component by Mateo Spinelli.

Case Studies