What’s it all about?

For real people to actually use your application in daily life, it’s not enough to bundle it with a nice UI and a bunch of cool features, it has to be really responsive as well. The reasoning is simple – people hate to wait. People hate to wait in
lines (except the British, hehe), they hate to wait for their salary, they hate to wait for the weekend to arrive and they
hate to wait for the next season of their beloved TV series. Ok, sometimes the anger can transform into excitement (and vica versa) – but raise your hopes too much, this seldom happens in the case of web apps. Yes, people hate to wait after the click.

Responsiveness is often described by how quickly an application reacts upon a user triggered action. Basically everything we do in the web is interaction- the website or application waits for an user action and then replies. There has been already a lot of research on today’s topic, concluding for instance that people already get the feeling they’re waiting if the result doesn’t come up in less than 0.5 seconds. But the answer to the problem is the tricky bit.

The obvious solution: Performance optimizations

Many of todays apps and websites are Ajax driven, to the extend that a user initiated action triggers a request to the server. This is why the most obvious solution coming to mind is to improve the time each request takes. Be careful though – this is also exactly why responsiveness is so often forgotten in the frontend planning. People tend to think of it as something non-visual, therefore they let the backend guys do the work.

Now after you speeded up the requests and your backend, you have to take the frontend really serious. The JavaScript powering your website is often the most visible bottleneck because it’s directly happening on the client, even before any backend request can happen. And it’s not only JavaScript – heavy usage of CSS Frameworks (especially resets) for instance can horribly slow down any application as well. Remember – if your frontend performs bad, the backend guys don’t even have a chance to make up for it. Of course I could go into detail how to actually optimize your code, but that’s content for another blog post.

Transparency and disguise

In the last couple years I noticed a general pattern when designing a responsive experience. There are essentially two ways to tackle it: The first is total transparency – the user should never be clueless, and if the application is in a loading state, tell it to your user so he doesn’t get annoyed too much. The second, and to me the one with almost unlimited potential is illusion.

Fixing the experience without fixing the implementation

Something only very few people I met realized is that an application can be improved even without fixing the implementation. There is really only one thing that matters to the user – how the application feels. Yes, let me repeat that: Your implementation doesn’t have to be responsive – it just has to feel that way.

Apple – masters of illusion

The best way to describe what I mean by making your application *feel* responsive is through a perfect example. It’s the best illusion of responsiveness I’ve seen so far. I’m talking about the iPhone.

The iPhone runs a very sophisticated operating system based on Mac OS X, with thousands of API’s for developers to use. Combined with the fact that the iPhone isn’t running particularly fast hardware (more than a standard cellphone, but way less than any netbook), simple performance optimizations could only get you so far here, and this is is where the magic comes in.

Almost every interaction on the iPhone uses an animation to transition from one state to another. You’ll see animations when you launch or quit applications, when you slide through screens and on many other instances, sometimes so tiny you don’t realize it. Since they’re very well integrated into the general flow of the interaction, they not only excite users but serve as visual cue helpers that let the user ‘grasp’ what’s happening. But the key is what happens during the animation: Any application you launch or close on the iPhone needs time to initialize and to de-initialize. You guessed it already: It’s all done when the user is distracted by a beautiful zoom effect. How cool is that?

As a summary: At the cost of slowing down the operating system in technical terms (every animation takes a fixed amount of time), Apple improved the whole user experience and made the iPhone feel extremely responsive .

Loading indicators

As a conclusion to the illusion technique, in 90% of all cases a loading indicator is evil. Why on earth would you want to highlight the slow parts of your application? That being said, a loading indicator is always better than a frozen state and a clueless user. As a general rule, only add a loading indicator to your application if all other improvements fail. For instance, there are situations where you absolutely can’t predict when the result will arrive. Imagine a multiplayer game with two players, and you’re waiting for the other player to select his character. In this case you have to notify the user that the game is waiting for a response.

See you next time!

I was a bit skeptical when I first read about all the cool functions that work in Webkit iPhone, but nowhere else, because there was little documentation, and literally nothing done by other developers, no demos, no tests. I thought, surely, some students with too much free time must have jumped on that immediately?

Well, I decided to give it a go, and started Dashcode, created a new web application and hacked in some CSS Transforms into my elements. One very important discovery I’ve made is that only 2D CSS Transforms are directly visible on the WYSIWYG canvas in Dashcode. So when you think the actual 3D functions won’t work, run the iPhone simulator.

The iPhone simulator is actually capable of using the exact same API than the iPhone. This is awesome and a bit funny, since I always thought the 3D functions don’t work in the browser version of Safari yet, because they need to be bundled tightly to the hardware, but apparently, there must be a different reason.