Latency kills the mobile experience
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.
Latency certainly does kill the mobile experience! Using lookahead and compression, we at Survol Interactive have largely driven latency from our mobile UI, and you’ll find other companies tackling the same problem.
Best wishes for a successful MEX 2007; we look forward to a MEX 2008.
Stan, CTO, Survol Interactive
Both apps are Java, I believe, not native S60 apps. I don’t think you can lay the blame all at Symbian’s door!
Java apps are this slow on most systems, even PCs…..
You’re right, this isn’t necessarily a Symbian problem or a Nokia problem or even a Yahoo or Yell problem. But it’s definitely a problem for the end users and they’re going to vote with the feet rather than sticking around to figure out whether it would run better on a Symbian, Windows Mobile, Palm or embedded OS device. It’s something everyone in the industry needs to work together to solve: faster processors, more memory, greater code efficiency, better application platforms – it’s a lot of work to improve a few seconds of latency, but I think it’s essential if we want to drive usage of mobile services.
Both apps are implementing their own custom text fields in a Java Canvas and almost certainly it is their implementations that are causing the latency. However, it is very possible to implement custom text fields in Java with zero latency on a a device as powerful as an N80 – despite the native Series 60 phone UI being very high latency because of Nokias consistent refusal to put good enough processors into their S60 devices. In fact it is possible to write very fast and usable custom text fields on almost every MIDP device I’ve tried (going back as far as the Nokia 7210), except the really really slow low-end Samsungs and a few others out of the mainstream. You just have to know how to code Java 😉 For examples check out our recent apps for Playtech among others (N80 support coming soon, but other slower devices work fine and the beta N80 version I just tried looked extremely nice).
I have to disagree with the assertion that it is not fair to compare the Yahoo and Yell apps though – as long as you start the comparison from the point where you selected the “Address Lookup” mode on the Yahoo app, then you are dealing with identical functionality which is directly comparable, and Yahoo would appear to be far behind. Trying to do everythign and achieving it badly is worse than a suite of smaller, faster, targetted apps to my mind, but then I’m not an advertising salesman.
I tried the Yahoo World Cup app ages back and gave up because the menu had mutliple second latency when changing selection, and Go appeared to have the same problems when I loaded it briefly – this seems to be because 1) Yahoo don’t code very efficiently and 2) they are trying to network everything, having designed the app to meet their own internal aims, ignoring the needs of the user. This also explains the ridiculously large download for a random mix of functionality a lot of people won’t want. For the next few years at least, this sort of practice will guarantee an app’s failure because networks are too slow to support it and users will instantly switch off.
Thanks for sharing your views Tom. I think you make an important point: “They are trying to network everything, having designed the app to meet their own internal aims, ignoring the needs of the user…”
This highlights one of the key user experience failings in the mobile industry – getting the top-level strategy right. As you say, it may well be possible to code this sort of thing efficiently and get the interface right, but if the focus on end user behaviour isn’t there, the application will still fall down.
To the company executives, it may seem to be in Yahoo’s interests to pack as many features as they can into a single client application. However, from a user perspective, this will only end up frustrating you if you can’t quickly get to the features that you want.
The end result? You stop using the application and the company loses a customer.
I think these same network latency issues may kill the new Microsoft spin-off browser, ZenZui. They appear to be trying to improve the mobile browsing experience by quadrupling the amount of data you download – grabbing four sites at once.
I do like the idea of breaking out of the desktop browser conventions, but for me the most frustrating thing about wap browsing – and the reason why I’d more often than not prefer a well crafted targetted Java app to a wap site even if it was optimised for WML and not just a refactoring of HTML content – is that the network connections just take too long. The screen constraints and navigation controls are also a problem (which a good targetted Java app can improve), but network-driven latency is the real killer for me.
It’s worth pointing out that I think for the majority of content a wap browser is still better than Java, but for certain types of content – particularly anything you regularly consult, anything with a non-trivial UI component and anything with heavy and repeated image/style overhead – dedicated Java apps will serve their users better, and when well written they should cut mobile data bills as well.
I support your views. A key focus for us at Yell is to improve usability and overall service utility. We are working on a second generation Yell.com mobile service which once released (soon) will offer even richer features and reduced latency – all for free. Our great strengths at Yell.com mobile are based around the 2 million+ business listings and understanding/interpretation of the location. Watch this space!
Martin Wilson – Head of Mobile Marketing, Yell
Tom Godber hints at the other reason that this is what Marek described as a ‘classic’ user experience challenge: my sense is that regardless of how we choose to deliver the application’s functionality to the handset, many users have an expectation that they learned online (on the desktop) and that the handset’s own OS reinforces – whilst they’re prepared to be forgiving about a small wait for the network do something in response to a request for eg a restaurant, they don’t see why they should have to wait for the “browser” or “application” to scroll, or accept text input (ie the expectation is that the internet should be fast and the application using it very fast).
This kind of thing is incredibly frustrating, as Marek pointed out (“even simple commands, like scrolling up to input some text into the search box, cause a delay of a second or so”), because the application seems unresponsive to the point of indifferent to the user, without providing any understandable reason for the latency.
Its true you can do responsive Java apps for low end phones, we are just finalizing app to be embedded in 200.000+ entry level phones with JBenchmark of 36 and the custom input field has no latencies.
The other point – to provide good UE – I see its based on building different version for diffrent handsets groups – But not reduced feature set for low-end handset – but targeted for that user group.
In better phones like N80 there definately should be power enough for “one-client-with-all-the-features” app IF its well done. For entry handsets this can be broken down to separate apps. But its true we have seen the problem of customer wanting to have all in on client, like in PC internet. But the problem in my view is: people dont use phones same way they use PC. Phone usage is on/off, fast paced 1-2 minute sessions -> quick look-up here and there – whereas PC is 1-2 hour sessions. So biggest usability driver in my opinion – (disagree with Marek a bit on here) is to have the design principle right – application should be design for Mobile Use. Now applications are designed for Mobile Phones not for Mobile Use. Summarize – I believe good new phones are good enough – we just need to to make good applications now!
I very much agree with Tuomas’ point about designing for the unique usage patterns of the mobile environment. This is a pre-requisite for any mobile company.
In the Yahoo example, however, the interface design principle was very good. The problems seemed to be caused by a combination of network speed, poor Java implementation and ineffecient use of the handset’s capabilities.