How Not To Design A Mobile Site - TasteLondon

I'm a huge fan of TasteLondon.  Their card gives discounts in hundreds of restaurants around London.  It's saved me quite a bit of money  and I really recommend the service to anyone who likes eating out.

There is a small problem with it, though.  The directory of restaurants it covers is a fairly heavy paperback book  Rather inconvenient to carry around on the off chance that you fancy popping out for some dinner .  They do have a rather good website - http://www.tastelondon.co.uk/ - but it doesn't work on mobile. Nope. Not even if you've got a Cadbury's iPhone.

Last year I asked TasteLondon if they were planning on developing a mobile site.  They said "yes" and here it is.  It's a textbook example of how not to design for mobile.  Let me take you through it.

Where is it?

How would you expect to get to the TasteLondon mobile site?  Their news page annouces the service but doesn't give the URL! The site is meant to auto-detect a mobile browser but failed to do so on BlackBerry or Android.

I tried guessing the URL.  Was it m.tastelondon.co.uk? Perhaps mobile.tastelondon.co.uk? Surely not wap.tastelondon.co.uk? I know tastelondon.mobi? Nope - none of those.  After much perseverance I discovered it was http://www.tastelondon.co.uk/iphone

Solutions

• TELL YOUR CUSTOMERS WHERE YOUR SITE IS!
• Mobile detection is hard.  You can use services like DeviceAtlas or WURFL to detect if a device is mobile.
• Always offer a link on your main page just in case your detection is wrong.
• If there are several standards, make sure you redirect your customers if they go to the wrong URL.  A simple redirect in .htaccess would have send everyone visiting the m.tastelondon URL to the correct location.
• Don't choose technology specific names in your addresses.  /iphone would indicate that you're not interested in the hundreds of millions of devices which aren't made by Apple.  While the iPhone is popular now - will it be in a year's time? Choose something vendor neutral.

So, here's the front page on my BlackBerry.

I quite like this.  It's simple.  There's a link back to the full site.  The bold indicates that I'm in simple search and, if I want, I can go to Advanced Search.  I wouldn't have made "Simple Search" a link as I'm already here.  Overall, not bad.  Let's see what the search results are like.

JavaScript

So, I hit the button and what do I see?

Don't get me wrong, I love JavaScript. It does all sorts of amazing things and usually makes usability a lot better.  But on mobile?  True, many newer high-end phones have JavaScript - but literally billions don't.  Why would you alienate so many potential customers?

What makes it worse, is that this is a simple form.  We've had forms on the web since its inception.  It's a standard HTML element.  Why would a simple search box need JavaScript?

Is It Necessary?

• KISS
• If you're desperate to use a whizzy new feature - check how widely supported it is.  Make sure there's a fallback option for those users who won't or can't upgrade.
• Whenever you create a new service, test it as thoroughly as possible.  Remember, you are probably not your typical user.  Find out what technology your users have and design for them - not for what's "cool".

Ok, let me grab my Android handset and carry on testing...

Where am I?

So, I've just arrived at Waterloo Station when I see all the trains home are cancelled.  Let's grab a bite to eat nearby.  I'll search for Waterloo.

This is what I get back.

There are three serious errors with this page

1. The result is wrong.  I know the postcode of my home and my workplace.  I've no idea what the postcode is for anywhere else.  Given this is a London based service, I was expecting that a major train station would suffice.
2. No feedback on what I've searched for.  That search bar should be pre-populated with my search.  Just like every other search engine.  This gives allows me to correct any misspellings and serves as a reminder of what I was looking for.
3. Location.  The Prezzo in Peterborough is 265.31 Miles away.  Away from where?  I haven't given my location and, as far as I can tell, the site hasn't automatically detected it.  Where does this figure derive from?

User Needs

• Think about how the user thinks.  Does anyone know the postcode of the pub they're sat in?  If you need a street name for accuracy, tell the user.
• Give the user feedback.  Keep them in the loop.
• Detect the user's location.  This may be complicated for you - but it's easier for the user.

Success!

I'll try again.  I've got the feeling that I'm in the postal area of W2.  Here's what success looks like.

A really good page.  Pretty, well formatted, lots of information.  Can you spot the four glaring usability issues?

1. I can't click on the phone numbers.  Some advanced phones will detect the number string and allow you dial it.  If not, you've got to find a scrap of paper, scribble down the number, close the browser, go to the phone's dialer and type the number in yourself.
2. Where is Craven Hill Gardens? Why not link to Google Maps. Or Yahoo Maps. Or any mapping service.
3. What do those icons mean?  Anyone already intimately familiar with the TasteLondon system may know what they mean.
4. Where do I go for more information?  The names of the venues aren't clickable.

Is This As Easy As It Could Be?

Make everything as easy as possible for your users.  In four simple steps the usability of this site could dramatically be increased.

1. Make phone numbers easy to dial.  Your user is on a phone, they need to book a restaurant, you've given them the number - why wouldn't you make it easy for them to call?  You can use WTAI or tel: to make it easy for any user to dial the number you've presented.
2. Maps.  On the desktop, users are quite happy to copy and paste text into another page or application.  It's not so easy on mobile. If something can be a link - it probably should be.
3. Familiarity. Because we spend all day in our jobs, we often forget that not everyone understands the acronyms and syntax we use.  Don't hide behind obscure icons unless you hyperlink those icons to a page describing what they mean.  Consider having a "key" or "legend" at the top of a jargon heavy page.
4. Have you given me enough information to make a decision?  Perhaps I want to see the menu, prices, review or some other information.  If the information is available on your main site, it should be available on mobile.  This is the central tenent of the One Web.

The Tyranny Of Choice

Let's pop into Advanced Search.  It's fairly comprehensive.

There's a sensible amount of options. Availability, Cost, and Offers all have 3 - 4 options.  Cuisine obviously has rather a lot of choices - 40 of them from African to Vietnamese. Yummy!

How many results do I want to see?  According to TasteLondon, it could be over 500!

Rational Choices

• Too many choices can be confusing and distressing for the user.
• How much information does a user want to see?
• How long will it take a user to download 500 results onto their phone?
• If you are going to offer a large results set, give the user a way to sort.
• Rationalise the choices you offer and how you offer them.  Is a list the best way? How about radio buttons or check boxes?

Sharing Is Caring

So, I've found the perfect restaurant for me and my friends.  I guess I'd better check that it's OK with them all.  How can I do that? I know! I'll SMS them the URL.

Ah... A problem.  The URL isn't specific to the restaurant.

Take Advantage of the Platform

• If you want people to visit your site, make it easy for them to share it with their friends.
• Consider having a "Send To Friend" button which will save your users the cost of a text message.
• Create useful URLs. Watch this presentation about URL design or read it direct from the mouths of experts - Cool URLs Don't Change.
• For this site, I'd use two different types of URLs.
• The URL for the search page should be similar to m.tastelondon.co.uk/?l=w2&c=veg&a=1&c=2&o=3 This enables your users to send the message "Hey, which one do you like the best?"
• The URL for each restaurant should be similar to m.tastelondon.co.uk/?r=1234 This enables your users to send the message "Hey, do you like this restaurant?"
• You can use "smsto://" on some phones to make it easier to send the URL by text.

Conclusion

I love my TasteLondon card.  It is tremendously valuable.  It has paid for itself many times over.  The mobile site is, frankly, a bit disappointing.  It works - on some phones.  It gives me information - but only the bare minimum.  It tries to be clever - but gets the basics wrong.

If I were dining on my own, didn't really care about the menu and hoped cabbies knew London as well as they're meant to - this wouldn't be a bad site.  I do use it - but find myself skipping into Google Maps and external restaurant review sites.  I have to copy and paste details or take a screenshot if I want to share information with friends.

TasteLondon's mobile site has only been live for a few weeks - I look forward to watching its evolution.