The weird and wonderful world of options for mobile URIs

As long as there's been mobile sites there has been a debate about the correct URI to use.  Back in the dark days of 2001-6 the most common way of denoting a mobile site was to use wap.domain.com if you were running a mobile site.  However, there was always a school of thought that you should use a standard .com address and use device detection to serve up a mobile version if the domain was being accessed by a mobile phone.  However, given the low take-up of the first generation of mobile internet / wap services the debate wasn't that important.   

As the mobile internet has grown having a specific mobile optimized site has become more common, despite the mistaken view that is no need for this now we have the iphone and better mobile browsers on other devices.  At the same time a number of new options have emerged for what type of URL address to use to donote a "mobile site". 

wap. addresses are a toxic brand

Today many mobile services continue to use the old "wap dot" approach for example. wap.getjar.com, wap.mobango.com. This is absolutely not the right way to go as "wap" is such a toxic brand that makes people think of the clunky first generation of mobile services not the exciting, usable mobile 2.0 sites of the present day.  In addition, these sites often seem to use a .wap MIME type (application/vnd.wap.xhtml+xml) or something which prevents you from opening the mobile site in a browser and checking it out - try clicking on wap.mobango.com for example.

.com addresses and device detection have problems

Whilst wap is toxic simply using .com as the address for a mobile service isn't an effective solution either.  The case for using .com is reasonable - users should not have to enter anything special on a mobile browser just to access a mobile version of the service - the service should simply detect the fact that the device is a mobile and serve up the appropriate version of the site.  Update - In the comments, Simon Maddox makes a good point that device detection is useful when pushing people to a specific bit of content (e.g. if you get email alerts to your blackberry with a new story in it) or to push the right site to a user via an SMS short-code request. In addition, it's still necessary to use device detection to serve up the right application, game or content item to a handset.  However, there are a number of problems with this approach when entering dot.com is the only way to access a mobile site:

- if a user is browsing on an advanced browser like opera mini or iphone safari you have no way of knowing whether they would prefer to access the full site or a mobile version

- with the introduction of transcoders, a .com based mobilesite runs the risk of being mangled / transcoded into a "mobile friendly form" as a ".com" address means that the site is not on a white-list of mobile sites which the transcoder will leave untouched

- many detection systems also recognise windows mobile explorer as a web browser and serve up a web-version of the site rather than the mobile service

- if your device detection system depends on sniffing the phone type and checking against a database of listed handsets this can run into problems for the latest models which might not be on the list yet.  As a result, a user with a new phone can get back ridiculous responses to a site request like "device not detected" etc and be prevented from using the site

- using device detection creates another layer of complexity which may not really add value to the user experience.  This is fine if you have lots of resource to run a mobile service, but this isn't the case for everyone. 

So for these reasons, you should still use some kind of mobile specific URL not just "dot com".  But what?

m. is becoming the web and mobile 2.0 standard

 The "m dot (m.domain)" URI has become popular with the big web services as they have launched mobile optimized services like m.facebook.com, m.twitter.com, m.myspace.com, m.google.com etc.  m dot has also been given a push by new mobile 2.0 startups like m.mippin.com, m.reporo.com etc.  As a result, dot m is becoming the obvious thing for a lot of people to type in if they are looking for a mobile service.  Unlike wap. sites the m. domain is associated with new, modern usable mobile sites from the big players and most exciting mobile startups so it actually has a lot of positive value.  Furthermore, most people are getting to know mobile through using the big online services like facebook which will  make m. very well understood by consumers. 

dot mobi has also gained some traction in specific areas of the mobile market

The launch of the .mobi domain in 2006 has also created another option for services looking to offer a mobile internet site.  Some of the mainstream media brands and so on are tending to use .mobi addresses and a lot of small independent mobile sites are also using it, partly as a result of a land-grap by domainers and internet marketeers to get the best addresses.  Dot mobi have been putting a lot of marketing effort behind the domain and have really done a lot to promote good mobile practice and development approaches through ready.mobi and dev.mob.  As a result dot mobi addresses now have fairly wide recognition and awareness making it important to offer a dot mobi extension as a way of accessing a mobile service.  There are also a lot of .mobi directories and communities around which can be a good way to get traffic for your mobile site. 

A range of other non-standard approaches being used

In addition to the major approaches listed above a range of non-standard urls are also being used, including:

• variations on the use of a mobile subdomain or folder e.g. http://mobile.wired.com or bbc.co.uk/mobile
• specific addresses for their site rather than subdomains or folders e.g. http://cnnmobile.com
• using other words like mini in a similar way e.g. http://www.techmeme.com/mini
• using an xhtml extension - e.g. http://google.com/xhmtl
• legacy URLs from when mobile sites were built for pdas like - http://slashdot.org/palm
• an attempt to get people to call mobile sites "rivers" e.g. http://diggriver.com/

... and more ...!

iphone sites getting their own sub domains

Despite the capabilities of the iphone browser, there has been a massive push to create iphone specific mobile websites.  It seems the the iphone. URI is becoming a bit of a standard here such as iphone.facebook.com, iphone.ebay.com and iphone.foxnews.com.  If the iphone really does start to gain market share in the mobile web world them we might see this getting shortened to i. ?  Believe it or not some web sites have built iphone versions of their service before even building a mobile site to serve all the other phones out there.  For example, the local reviews site Trusted Places has an iphone site http://trustedplaces.com/iphone/ but nothing for other phones at an m dot address. 

There is a longer term question about what will happen to this going forward as other manufacturers launch more touch screen handsets like the iphone and full featured web browsers (e.g. ajax, flash) become more common.  Is it likely that the iphone will be able to continue justifying having its own specific URL?  However, for now, it seems important to have a separate site and URL specifically for the iphone if you have built an interface optimized for that device. 

So what to do?

Given the fact that there are so many different options for naming a mobile site and no single approach has become a true standard yet, the best approach is to hedge your bets.  IMO good practice is to do the following:

- promote or market a m. site as your main domain

- also register a .mobi address and forward it to your mobile site and potentially promote it in parallel to the m. address but into the .mobi specific directories, communities and so on. 

- offer users a mobile version of the site through a link on your dot.com page (E.G. "Switch to mobile version") so that a user accessing on a mobile can make their own decision about which version of the site they are looking to use 

- offer users a web version of the site though a link on the mobile version of your site (e.g. "Switch to PC version")

- if you are making the investment in serving the iphone as a key user group with a special site then use the iphone. address to denote the site

What shouldn't be done is to use either just a .com with device detection or one of the weird and wonderful alternatives like palm, mini, river etc.  Having said all this, with the lack of a true standard there is no fool-proof right or wrong way to go, and for some sites different things might work better. 

There's some other good posts on the topic for example, London Calling say dot m is the way to go and Russ Beattie is also pretty bullish on m.dot, Whatleydude called dot m a "de facto standard" a while back but also recognises there's some value in dot mobi, whilst you still find other people pushing for using .com and device detection.  A post from dot mobi shows that wap. is still the most popular approach in terms of raw numbers of mobile sites.

No doubt other people have opinions on this - good to hear them in the comments or @mjelly on twitter.

Comments

[Simon]

I disagree. Device detection *should* be used.

If someone sends me a link to an article on bbc.co.uk and I'm on my mobile when I read it, I don't expect to see the normal site.

You can detect a mobile device by more than just checking the User Agent against a database. And, of course, suitable fallbacks should be used to ensure that the user never sees a "Device not detected" message.

[alfie]

Great post James, particularly like your summary of .com / device detection which I thoroughly agree with.

[alfie]

Simon - you say

"You can detect a mobile device by more than just checking the User Agent against a database."

How exactly?

[james (mjelly)]

Hi Simon that's a good point and a good example - maybe I should refine the argument a bit. I think I am saying that mobile sites should not really 100% on a single dot com URI but that's not to say that device sniffing etc shouldnt be used to serve up the right content.

[james (mjelly)]

thanks Alfie - yeah I am anti just using dot com after many bad experiences of mobile sites that rely on this approach.

[Andrea Trasatti]

There was a post on the dev.mobi blog that is very similar to yours, but mostly about numbers and not why you should choose one or the other, so it's complementary. See "The Growing Mobile Web" ( http://dev.mobi/blog/the-growing-mobile-web).

In reply to Alfie about how to detect a mobile device, I would like to suggest our own DeviceAtlas ( http://deviceatlas.com ).

[Simon]

@alfie there are two other ways I can think of. Firstly, using IP address/hostname lookups. This isn't very accurate, but coupled with user agent detection can increase accuracy.

Also, get agreements signed with the networks. With these in place, your domains will go on a whitelist. Sites on the whitelist get passed things like msisdn, extra network info, whether the user is connected over 2G/3G etc... all VERY cool things (of course, it's not cool at all to store the msisdn).

If you're not in a position to do this, you can 'sort of' do it by registering with someone like Bango, and using their Identifier service.

Of course, this won't detect whether someone is using a laptop over the mobile network, so user agent lookups should be done to complement this.

[james (mjelly)]

thanks Andrea have added the link to the post - amazing so many people are still using wap. I guess there are a lot of legacy sites out there but maybe wap doesnt have the same poor image in other countries?

[james (mjelly)]

Simon - i think what you are saying highlights the issue around "complexity" in doing device sniffing - it's great if you have the resources but IMO too many mobile services get hung up on this when they dont have to rather than focusing on building the core service.

[Simon]

Sorry for the multiple comments - but I've got something to add :)

At work, the main way users find our site at the moment is through SMS campaigns. When we receive an SMS, we have no idea which version of the site they'll need. The mobile site? The iPhone site? The desktop site? (If they're using a data card)

The only way to do this is by device detection - we can't send them a m. url, just in case.

[james (mjelly)]

Simon - all your comments are useful! That's another good point actually and have updated the post to agree with it.

[Simon]

"Simon - i think what you are saying highlights the issue around "complexity" in doing device sniffing"

Device sniffing makes it harder for the developer, yes. But it also makes it easier for the user. Isn't that the right way round? :)

[:: Sitios WAP ::]

James, I agree that the WAP label has expiration date, but please not the burial before it is death.

[Veronique]

marketing dollars have to be used only on one brand. a dot com with a good device recognition should do the job. With a redirection to whatever.domain.com

Anyway, let's the users choose :)

Veronique

http://dating.agamata.com

[Anthony Hand]

Hi, James --

Nice article. I wrote an article on my site recently taking a more neutral stance. The point of my article was that companies should assume that users will use a bunch of the emerging patterns (like m.XX) as well as continuing to use the legacy ones (like wap.XX). As a result, I think it's a good idea to settle on one approach, and then provide redirects for the other likely scenarios. The article:

http://www.hand-interactive.com/resources/mobile-web-access.htm

When it comes to device detection, I think it's more important to detect *platforms*, if one must, like iPhone or S60 or WAP/WML.

For example, if you have an iPhone optimized version of your site, then you may wish to direct people there. And all you need to know is if it's an iPhone or iPod Touch, not which firmware version (at this point), etc. etc.

Detecting for the platform is a bit easier than detecting for individual devices.

I just published an article with free PHP code for detecting mobile platforms on my web site yesterday:

http://www.hand-interactive.com/resources/detect-mobile-php.htm

Cheers,
Anthony

[james (mjelly)]

thanks Anthony - useful

[Qwertydesign]

Nice article. We recommend that clients work with one url and then use a handset detection web service to do the hard bit. there are a few out there, but we use handsetdetection.com who seem ok.

[james]

Interesting comments posted to this blog im not sure if im fully convinced though.