How long is half a second? In the context of a mobile user interface, it can be long enough to cripple the experience and make the difference between a converting a user from a casual browser to a dedicated customer.

Latency – the time lag between inputing a command and receiving a response – is a user experience killer.

I’ve been testing Yahoo’s Go application recently. When I first read about the new 2.0 release I was excited by what I saw. At first glance, the application looks great – intuitive interface, great integration between all the different features and a service clearly built from the ground-up for mobile, rather than simply re-hashed from the desktop environment.

However, I have found it to be almost unusable in real world situations.

In one instance, I had 15 minutes to spare on a train journey and wanted to find the location of the restaurant where I was meeting my friends. According to the marketing materials, Yahoo’s Go is ideally suited for this – it should be able to find the restaurant, show me a map and even offer directions.

In reality I found that even with 15 minutes of dedicated searching I received nothing but a sense of frustration from the application, let alone the result I was looking for.

At every stage of the process, the huge latency destroyed the user experience. It took more than 20 seconds for the application to open, display it’s splash screen and then show me a prompt asking whether I would allow it to establish a data connection.

Once connected, the interaction times for the application slowed down to a crawl. I presume this is because it is busy caching data in the background to fill the various on-screen widgets which tell users about things Yahoo thinks may be of interest.

The latency is so bad that even simple commands, like scrolling up to input some text into the search box, cause a delay of a second or so. It doesn’t sound like much, but it makes the navigation unclear and frustrating. As a result, I often found myself clicking too many times and ending up missing the object I was trying to navigate to.

It got worse when I was trying to type in the name of the restaurant I was looking for. The latency even affected text input, so much so that it took me over a minute to enter just two words, with significant time wasted waiting for the system to allow me to enter the next character.

Having spent about 10 minutes with Go I realised I was nearly at my destination and decided to quit and try an alternative method.

I also have Yell.com’s mobile client installed on my handset, so I opened this and was presented with a simpler interface than the visual richness of Yahoo’s Go. There were 3 boxes to complete – one for the category (Restaurants), which auto-completed after I had entered the first ‘R’, another for the name of the establishment and a third for the location.

The data connection was not established until I clicked the ‘Find’ button, which seems like a sensible way to reduce the time delay which Go suffered from. However, Yell.com’s application had the same problem with lag times when entering text, making the input process very frustrating. Clearly this is an inherent problem with the processor, memory and operating system combination of the N80 I was using (a 220 Mhz TI chip, 30 Mb of RAM and Series 60 version 3 running on Symbian 9.1).

Yell found the restaurant I was looking for at the first attempt and presented me with the address and a quick link to call them. It also showed me a map.

It’s not fair to compare Yahoo Go and Yell.com, as the applications target different requirements, and that is not the intention of this article. However, it is clear from these real world tests that even a dedicated address finding service can suffer from experience problems caused by interface latency.

Responses need to be instantaneous in the mobile environment to create a good experience. Even the shortest delays need to be masked behind some sort of visual response (i.e. something which tells the user the application is busy) otherwise the process flow rapidly becomes disjointed. A delay of just a fraction of a second can make the user think the application has stalled and that’s unacceptable in the linear interaction chain inherent with small screen mobile devices.

This issue is what I’d describe as a ‘classic’ user experience challenge. To solve it requires progress to be made at several levels of the value chain. As an analyst, I could lay the blame for my poor experience at the feet of the application developer (e.g. Yahoo or Yell) for not optimising their interface for my device. Or I could point to the speed of the operator’s network, which caused Yahoo Go to spend so much time downloading content in the background. There’s also an argument that Nokia is at fault for not choosing a faster processor or Symbian for not creating an operating system with better support for third party applications.

From an end user perspective, however, I simply don’t care – I just want it to work. Users aren’t going to waste their time trying to figure out who is at fault, they’re just not going to use the application. And when that happens, everyone in the value chain looses – the application developer looses a customer, the operator looses data traffic and the manufacturer and platform provider will find customers less likely to choose advanced phones in the future because they can’t see the benefit.

This is a great example of the kind of broad thinking on user experience we’ve been trying to encourage with our MEX conference. On the surface of it, this problem was about a user encountering a poorly designed interface. In reality, the problem goes much deeper and is as much about network connectivity, processor choice and OS capabilities as it is about the visual appearance of the application. As such, it affects companies throughout the value chain.

Perhaps the long-term solution is to work towards providing developers with an open standards-based browser environment capable of displaying rich interface elements without the latency problems encountered when running 3rd party applications on-top of the OS?

At our next MEX conference in London on 2nd – 3rd May 2007 we’re bringing together leading thinkers from operators, handset manufacturers, content providers and software developers to try to solve some of these issues. I’d encourage you to register (delegate places are priced at GBP 1349) and join the debate.