You're doing handlers wrong

Okay so it's a link bait, sensationalist title, but that fact I've recognised that fact makes it okay yeah? Anyway like I said you're doing handlers wrong... or rather, to stop with the hype-generating, FUD-like statements; If you're waiting for RPC/Async handlers to return in order to update your application's interface then allow me to propose a new approach:

Always assume the call you're making will work.

Some context for the above, I recently got sick of my iPhone and decided to give Android a spin, side-stepping the obvious discussion here, one of the things that has irked me about the Android experience is that it just doesn't feel as responsive as the iPhone for certain applications, specifically email. So I started to compare the two and realised that the iPhone reacts to my interactions immediately whereas Android seems to wait for approval from the server. This eye-opening discovery led to me imposing a new standard here at Moov2:

Every user interaction must have an immediate and obvious reaction.

Proud and smug feelings of wearing my user experience hat were soon interupted when challenged to explain wtf I actually meant by this. So, for example, deleting an email from a list of viewed email messages. When I hit delete I expect that message to be removed from the list and if that happens as soon as I press the delete button, I'm a happy chap. Conversely, if I have to wait, even a couple of seconds, I may think I missed and try hitting it again... and again... etc. So developers, quite simply, as soon as that delete button is hit, remove the message from the list and THEN send your call informing the server to do it's part. This approach can be applied to pretty much any application development that involves a rich user interface, Flash, Flex, Silverlight, AJAX, Android, iPhone, native desktop apps and whatever.

But what if something goes wrong?

Of course, just throwing the message away willy-nilly is reckless, there's a whole host of things that could prevent that message from being deleted. The user might be offline, the email list might not be up to date or there may just be some other bug elsewhere making the delete email process just plain not possible at the moment. In this case, sheepishly, politely and unobtrusively, let your user know the fact and pop the email back where it came from. This will obviously be a nuissance to the user, but how often does this really happen in comparisson to how often it works? Very rarely, and it's no less annoying for the user than having to sit there waiting with no response only to find out the action failed.

What if I NEED the response in order to update the UI?

So deleting is a fairly convenient example because we're taking away from an already viewable interface, what about if we're adding to our interface based on the response from our call? For example displaying the list of emails in the first place. Well, for this I suggest you present all of the interface elements that you know are going to be available and just provide some indication that something else is going on to reassure the user that their input has been acknowledged. So when the user chooses to view their inbox, immediately react and change the view, present them the 'Inbox' title, show them any user controls they might be able to interact with and display the space those messages are going to load into with some form of preloader/spinner and note indicating their messages are being retrieved.

So take a minute and review your result handlers to see how much UI stuff is being done there. Could it be moved to before the call was made? This sometimes means you need to think about how to best back-track when things go wrong but for the 95% of the time when you just get the result you'd expect you'll deliver a MUCH more responsive feeling interface that your users will thank you for.

By the way, if you'd like to actually see some code demonstrating this concept tweet the following message to Pete who has prepared a very clean implementation of this for a Flex application we're currently working on: "Hey @peterkeating, codez pls http://bit.ly/f8HOyp. I'm sure he'll oblige with a sample soon enough.