Yes/No/Cancel

About a month ago Victor Keegan of the Guardian wrote: “The mobile web is finally getting started”. He points out both some of the benefits…

“It is interesting why so few of us use one of the breakthroughs of recent years: the ability to search the web from wherever we are with a mobile phone. This ought to be hugely empowering, enabling us to answer any question from wherever we happen to be instead of having to wait until we are within reach of a computer.”

…as also the main reasons for its slow start:

“There are a number of reasons why this hasn’t happened and why it may be about to change. It is partly because the operators have been shamefully greedy in trying to raid our pockets by charging for all the data we download [...] the user experience is still not good enough. Mobiles were designed to make telephone calls. Now things are changing.”

– Victor Keegan, “The mobile web is finally getting started”

I recently came across some great examples demonstrating why for complex web sites, there is no alternative to designing a specifically mobile version. This is not so much for technical reasons, as rather that mobile users may have totally different requirements. It’s not so important to be able to access every single bit of content; instead those things which mobile users do require need to be instantly accessible. After all, think why a user may want to use the mobile web rather than the desktop web: it’s very much tied to now, an instantaneous requirement. In the words of Sarah Lipman, from an interesting paper on mobile search paradigms:

“‘Mobile Search’ = I want it NOW. I can’t wait, I won’t wait.

When a user gets the sense that ‘I’m not going to find what I want right now’ he stops looking, because that is almost always the path of least resistance. At the same time, he will also have a small sense of failure. [...] If search cannot deliver on the promise of ‘I want it NOW’, it won’t be utilized.”

– Sarah Lipman, “Search patterns in nature: Informing computer search interfaces”

For mobile users it is even more important than for normal web users that the designer has figured out exactly what the most frequently needed aspects of his site are, and made those aspects immediately and very easily accessible. This means that a mobile page can contain far fewer navigational elements (links) than a page intended for desktop viewing. Going from desktop to mobile therefore involves prioritising links in a page — some of them are going to have to go (moved into a sub-page, or removed entirely). This is not something which software can do automatically — a human editor or information architect has to sit down and decide.

Two examples to clarify:

• Nigel Choi and Luca Passani have produced an impressive example contrasting the mobile-specifically designed version of the Wall Street Journal with its desktop version when automatically adapted for mobile use. (The purpose of the article is actually to criticise Vodafone UK’s approach to content adaptation, but it serves very well as a general example of the limitations of automatic adaptation versus manual redesign.) The mobile-designed version even goes as far as offering all content without requiring login (as opposed to the desktop version, a lot of which is subscription-only access), because WSJ recognise that people don’t like typing in user names and passwords on a phone keypad! Go to the article.
• The BBC News website comes in at least four different versions: a desktop version, a PDA version, a XHTML phone version and a WAP version. Simply comparing the structure of the news front page in each version gives a very insightful comparison. When I last checked, the front page of the desktop version contained 201 links; the PDA version contained 56 links; and the phone/WAP version contained 24 links. Same site, but different prioritisation of content. That’s the way it should be.

Blue Flavor has also produced a presentation on the basics of good mobile web design.