Bagel Belly Blog

Deep linking to Vodafone content

The other day I wanted to check train times on my mobile (which is the "killer app" for WAP/Web on my mobile phone, it sucks too badly for anything other than this, because of the low speed and the screen size).

I have a bookmark to the "My Trains" page of Vodafone Live! which currently links to http://vodafonelive.mytrains.kizoom.co.uk/index#main. At the time, this link resulted in a 404 Not Found error. Cue much cursing and swearing: finding the particular deep link you need on the Vodafone Live! site is a combination of horrific price gouging (as Vodafone force large unnecessary images down your throat in order to make a quick buck on GPRS charges) and the need for endless patience (as you work through the unintuitive menu screens which are only usable once all the images have loaded).

I saved a bookmark to the new train times page, which has the delightful URL of http://live.vodafone.com/idserver/dserver/!?url=http%3A%2F%2Fvirtual-cae%3A8224%2Fcae%2F3pi_wrappedML%2Fdisplay.do%3FnodeName%3Dcon08_findandseek_travel_liveinfo,4kdf5yV5vM.

Someone at Vodafone needs to do a bit of reading up on the basics of web application design. Firstly, Cool URIs don't change. I should never EVER see a 404 on a service such as this. Each 404 is a reason for me to stop using the Vodafone Live! service on my mobile phone, and is therefore a direct hit on Vodafone's profitability (if you multiply it either by the number of annoyed potential users of the service or the amount I personally spend on my mobile... )

Secondly, that URL needlessly tells us a bit about how their back-end application is working. It looks to me like a chunk of their back-end content is stored in XML and they are passing in the node to load (a reference to a bit of XML) via the URL. Ugly and IMHO destined to break in the future because of the implied tight contract between the URLs and the XML file structure. Of course, the URL could actually belie a truly elegant and well-architected back-end system. But if the people that design their back-end systems also design their URLs, I'm not holding my breath.

Thirdly, when every bit counts, a 170+ character URL hurts (especially if you think a URL like that will probably be loaded for every page you view). If I was being pessimistic, I'd say the maximum URL length for the first page would be 50 characters - e.g. http://live.vodafone.com/trains/?sessioncookiehash. And that's assuming they couldn't drop 'live' and shorten 'vodafone' and that you have to store the cookie reference in the URL (I can't recall if WAP supports cookies, and I'm not assuming they will risk storing a session reference based on your mobile phone connection). On an average use, I reckon there's about 6 hits to the server to get the information you want. That's 1020 characters the old way or 300 characters the new way ... a difference of 720 characters. Quite a bit of overhead on just the URLs alone. Remember, this is on a slow GPRS link where you're lucky to get 3000 of those characters a second on a download. You want to save some of that space for useful information ...

So what about the alternatives? Well, National Rail Enquiries mobile phone information refers to a branded version of the original kizoom service that Vodafone offered. The URL of the first page? http://wap.nationalrail.co.uk/bm/ followed by a string of 15 alphanumeric characters which I assume is a hash referring to my mobile phone number and my phone type. And the URL of the timetable lookup page? http://wap.nationalrail.co.uk/keep_history_consent?a=prompt&consent=true&js=AbCdEfghiJKlmN1O&seq=1&sid=45_1234567#main ... at 118 characters, it looks like they are trying to emulate Vodafone's "best practice".