How do you handle mobile traffic?

[wige]

How do you detect/respond to traffic from handheld browsers (cell phones, PDAs, etc.) on your site?

I am starting to develop a mobile version of my main site, and I am curious what methods people are using, and what issues you may have encountered with different approaches.

A few of the approaches I have been considering:

• Using a handheld style sheet that simply adapts the current page to be more usable on a smaller screen.
  • Requires limited additional development to create the new style sheets.
  • Ensures that browsers will display the correct information, by removing the need for browser detection.
  • The site may not convert easily to a new style sheet.
• Detecting the browser and serving a different page to the user based on the user agent.
  • Allows the creation of a completely different layout, beyond what may be possible with CSS alone
  • Would require a carefully maintained database of known mobile user agents, with spoofing may be error prone.
• Detecting the browser and redirecting the user to a mobile.mydomain.tld version of the site.
  • Would allow "retasking" for mobile users - most mobile users seem to be looking for different information from the site and they can be put into a more mobile-friendly funnel on a mobile-specific site.
  • Duplicate content.
  • Would require a database of user agents and could be error prone.

Have you used any of these methods, or a method I haven't considered? Are there other considerations or workarounds that I have not listed that would make one of these approaches an effective solution?

[NateDesmond]

As I was reading your post, I noticed that you were considering using a subdomain mobile.yourdomain.tld. Instead, I would recommend redirecting mobile users to a .mobi website. There are two main reasons for this.

1) If you do not claim the .mobi domain name someone else most likely will.

2) People using mobile browsers will look for the .mobi domains when they are searching or browsing the web.

Hope this helps!

[Orion]

I don't agree with using a .mobi domain name as you can end up with duplicate content issues... Obtaining the .mobi address can be a good idea but just point it to your site.

Using a mobile style sheet would be my personal preference as people get to know your domain name (branding a single domain instead of multiple tlds).

Either way, make sure, once you have any of the solutions set up, to submit your site to mobile search engines and don't forget to submit a mobile sitemap to google!

[bj]

Just use a mobile stylesheet. It's what they were designed for.

As to the .mobi thing, I personally think that this push to use it is so that domain speculators can reap the benefits of all those (otherwise useless) names they scrambled to buy when the tld was introduced. IMHO, there's no need for a .mobi name. You may choose to snag yours and redirect to your main domain, but I really have trouble believing that no one will find you if you don't use it.

[incrediblehelp]

With mobile screen readers getting more sophisticated will we even need to worry about this 2 years from now?

[alienpest]

I did a lite version of my business site, with just contact info and the bare essentials, it works well on the emulator that I tried, and it must be working for the users, since I am being contacted by that means. I built it with tables, which I now understand is a no no, but since it works, I am leaving it as is!

I built it on a .mobi, because I had some other content on another.mobi, and while I was ignoring it, it earned me a few hundred bucks in affiliate ads! I think people are underestimating the potential of this extension, and the extent to which the public is using it! I have a half dozen of them, and they are all bringing in money, with very little effort.

I think because there are so few mobi sites, and people have had such bad luck accessing regular sites on mobile devices, they go to the mobi directories when they get bored, and start clicking!

[benc007]

Does anyone have sample javascript code to determine if the user is coming to the site from a mobile phone and then use the appropriate mobile CSS?

[DaveSawers]

In the past, I've used Gary Keiths browser detection software to serve up a different, heavily cut down site when a mobile user is detected. This seems to work well and is not notably "error prone".

Would I do it again? Probably not. I think IncredibleHelp's got it right when he says that it won't be necessary much longer.

Some content optimization can be done using a mobile stylesheet and I would recommend going that route in the short term.

[Veikoh]

First you need to decide which versions of handhelds you are supporting. dot mobi name is not good to type using numeric keyboard, so m.yourname.com could be better solution.
separate CSS media="handheld" can be the solution if you can implement the pages this way. However, those will be shown on all handhelds same way. XHTML-MP is very limited too.
More complex systems are using WURFL libary to detect mobile device capabilities and format the output their way. For example image resizing is one of the issues to sort out.
If your site is using Javascript, forget it.

[PixelPusher]

Well, so far as I know most mobile clients don't fully support the media="handheld" attribute anyway.
Furthermore, I advise you that you build a different site compared to your main site. Focus on what a mobile visitor WANTS if he visits your site. Think about one-handed typing, bad light conditions and slow bandwidths.

As for the domain, I guess a "mobile.domain.com" or "m.domain.com" ist best, maybe with an additional *.mobi redirected to it, too.

[qh4dotcom]

I wouldn't bother doing anything about mobile traffic unless I was getting a significant amount of mobile visitors

[Orion]

Originally Posted by benc007

Does anyone have sample javascript code to determine if the user is coming to the site from a mobile phone and then use the appropriate mobile CSS?

There is no javascript code or at least no need for it... most handhelds don't support it anyway.

when you add media="handheld" to the <link> tag

<link rel="stylesheet" type="text/css" media="handheld" href="foo.css" />

it will automatically serve that stylesheet to a browser supporting the handheld CSS..

So far as support for the 'handheld' media type goes, it was slow to catch on however now I think you'll find the majority of mobile or handheld browsers do support it. Seems the it has better support using <link> over <import> also.

It would probably be a good idea to have a mobile only site or page as PixelPusher mentioned in that small site link to the full site though for those that have unlimited web and want to take the time. I know I use my PDA in wifi mode quite extensively and it's an older model win mobile 2003.

Hope that helps...

[MattE]

mobile web browsing is already big business - I read somewhere that 40% of web traffic globally is on mobile phones.

BUT!! most sites do not suit mobile browsing in their current form - mainly because of
1. images - banwidth humgry and generally add nothing
2. site layout and navigation differences are needed

So my suggestion, build a site suited to mobile if you think there is a change a mobile browser will stop by.

[Terry Van Horne]

Originally Posted by PixelPusher

Well, so far as I know most mobile clients don't fully support the media="handheld" attribute anyway.
Furthermore, I advise you that you build a different site compared to your main site. Focus on what a mobile visitor WANTS if he visits your site. Think about one-handed typing, bad light conditions and slow bandwidths.

Agreed. This is an important point as the display is different and the users needs/wants IMO, are much different than a website user. Therefore, tailor the display to be optimized for the display and needs/wants of the user. I have been doing this long enough to be very certain that the technology will change again before it reaches critical mass. ie; you gotta' have a mobile presence. IMO, for 99% of the sites out there there is not enough mobile traffic to warrant building a mobile presense.

Most sites with mobile likely get more traffic from directories then they do from mobile. IMO, you can start now if you are pretty sure of the needs of the user and can provide a solution that meets the needs. For example walmart could have a map and search that showed where products are available or store locations near you. Anything beyond that is IMO, putting the cart way before the horse.

Users will not shop on mobile they'll use it to find a location/contact info and product availability. IMO, only a moron believes people in NA will shop on a mobile phone. Outside NA and in particular emerging economies like India and China there are different user preferences for connectivity and devices. They are more likely to shop online with their phone because Internet connections are more costly than in the developed world. The problem here is that most of the phones sold into these markets are the cheaper phones which often don't support the internet.

Certain elements of the industry are promoting mobile as being needed now but... that's just to put a$$es in seats at mobile seminars and conferences. AIUI, The total traffic is less then 1% why worry about that. It's kinda like sweating about getting no traffic from ODP! The traffic is not a technology issue, it's a cost issue, and I'm fairly certain here in Ca. the telcos will keep it like that for as long as they can. The all you can eat data plans in the US will help and it will be interesting to see how that changes the traffic totals.

Originally Posted by PixelPusher

As for the domain, I guess a "mobile.domain.com" or "m.domain.com" ist best, maybe with an additional *.mobi redirected to it, too.

.NET has built in capabilities for detecting which devices are requesting a URI and that IMO, should be the most graceful way to handle the different device requirements. I remember when there were two different types of coding of html for mobile browsers and IMO, the platform is still evolving. I see it eventually going the way of the iPhone and it's use of safari. Sure, some things won't work the same but... it's just a little dumbing down.

IMO, CSS is always a klunky kludge that seldom works as expected on all platforms! I'd use it for marking up different blocks/areas but beyond that I think it is pretty wonky and I wouldn't be counting on it to handle something as complicated as marking up a different platform/device.

[Terry Van Horne]

Originally Posted by MattE

mobile web browsing is already big business - I read somewhere that 40% of web traffic globally is on mobile phones.

MattE not doubting you but... what is the source of that 40% figure and was it including data/phone calls? A lot of phone calls are now routed over the net so... is that applicable to our discussion? I'm fairly sure about the <1% but couldn't find my source for that. It may have been something I saw on a business channel on TV. I get the feeling that figure is like the 1,000,000,000's of "references" yellowpage directories claim are using the yellow pages. Yeah, sure I use it as a doorstop but... is that a reference when I place it in front of the door?

[bj]

IMO, CSS is always a klunky kludge that seldom works as expected on all platforms! I'd use it for marking up different blocks/areas but beyond that I think it is pretty wonky and I wouldn't be counting on it to handle something as complicated as marking up a different platform/device.

This is true if you have not yet learned how to use CSS. Different platforms/devices is EXACTLY the reason css was developed. Simply taking the presentational layer OUT of the html by using css allows mobile sites to load sites more quickly. And proper use of a mobile stylesheet does help. But if you don't know how to code properly then you're right. None of it will work.

[wige]

I thank you all for your advice and comments so far. For my site, mobile traffic is definitely not trivial, and although it does not lead to high conversions (possible because the site looks awful on handheld devices) we see the traffic as a chance to generate leads and build our brand.

For me, the more I look into my mobile traffic (which over the last few months has grown to nearly 10% of all traffic to my site, which is what got my attention) the more I see a need to develop the mobile capability as a completely seperate site. It seems that mobile users are looking for different information, and would benefit from a different environment. However, now it comes down to what the best way is to get the mobile users to the alternate site.

Would you recommend forcing users to the mobile/desktop site based on browser detection, or would displaying an appropriate message to the users advising them of the existence of the other site be better?

[bj]

Wige, I don't know that browser detection will work all that dependably on this platform. I think you're better off putting a link right at the top of the body, and also using the mobile stylesheet, so they at least get a somewhat stripped down version so they can find that link easily, without a lot of cruft meant for bigscreens.

Let us know how it goes.

[dmanjra]

Originally Posted by wige

I thank you all for your advice and comments so far. For my site, mobile traffic is definitely not trivial, and although it does not lead to high conversions (possible because the site looks awful on handheld devices) we see the traffic as a chance to generate leads and build our brand.

For me, the more I look into my mobile traffic (which over the last few months has grown to nearly 10% of all traffic to my site, which is what got my attention) the more I see a need to develop the mobile capability as a completely seperate site. It seems that mobile users are looking for different information, and would benefit from a different environment. However, now it comes down to what the best way is to get the mobile users to the alternate site.

Would you recommend forcing users to the mobile/desktop site based on browser detection, or would displaying an appropriate message to the users advising them of the existence of the other site be better?

Depending of the level of work you want to put into it, i would suggest that linking in a service like handsetdetection.com would be a good start. From that point, when someone visits the site, you can establish, on a live basis what the device is and then, from that point, either send them to a single mobile version, or have a number of versions for iphone and other devices. These could be stand alone, or managed by your CMS system.

dm

[kgun]

Originally Posted by bj

Wige, I don't know that browser detection will work all that dependably on this platform. I think you're better off putting a link right at the top of the body, and also using the mobile stylesheet, so they at least get a somewhat stripped down version so they can find that link easily, without a lot of cruft meant for bigscreens.

Let us know how it goes.

DreamWeaver implements this

<div class="skipLinks">skip to:
<a href="#content">page content</a> |
<a href="pageNav">links on this page</a> |
<a href="#globalNav">site navigation</a> |
<a href="#siteInfo">footer (site information)</a>
</div>

div tag in some of the templates. I think that same method can be used for mobile devices. See the first post in this

Bots and crawlers are not "human beings" yet.

thread for additional information.

Google:

class="skipLinks"

class="skipLinks" mobile

or variations thereoff.

[Terry Van Horne]

Originally Posted by wige

Would you recommend forcing users to the mobile/desktop site based on browser detection, or would displaying an appropriate message to the users advising them of the existence of the other site be better?

IMO, it is always best to detect the capabilities of the device and deliver only content they can use. For instance you may get a user with iPhone. Runs for the most part in a safari web browser why redirect? However if the pages are text heavy will the user want that text heavy version or just a search or quickway way to phone. I know I would have a .Mobi, positively, if it was a brandname or a brand I planned to build, otherwise, just detect and deliver the appropriate content... do people really care what domain they are on?... only the user experience they receive while visiting. I would be sure to let everyone know on both sites that you have both versions and the features/advantages of each version. IMO, You have to often own domain names whether you use them or not.... I personally don't sweat the where only the what as in what was the experience like?

As to detection I've used browserhawk (windows component, and no I think it's stupid to use it to cloak) for years. I prefer to detect things with components at the server level rather than JS at the client level and the component isn't dependent on JS. I'm not a big fan of using JS for anything especially when it affects user experience. Sorry if you are on the NIX. I'm not a lot of help since going to the darkside in 98.

[advancedmerchant]

We have taken an entirely different approach. We have set up small areas just for the mobile devices, and have a new URL redirected to the page. As an example, when deploying our software for Treo users, we direct them to LoadTreo.com, which is tailored for that device's screen size, and has the links to deploy our packages.