The MobileESP Project: Easily detect mobile web site visitors

I just uploaded the code bases for the following issues:

• In the DetectIphone() method, added a call so that the Apple iPad does not provide a false positive. (We also do this so that iPod Touches don’t report themselves as iPhones.)
• In the QuickMobile() method, added a call for the iPad so that iPads do not report as TRUE. Why do this? Instead, if you want to provide a special UI design for iPads (such as special layouts or to remove Flash), then make an explicit call using the new DetectIpad() method. Otherwise, let the iPad visitors get your regular web site rather than a site optimized for a small mobile phone’s screen.
• In the DetectWindowsMobile() method, added some new calls. One call checks for “ppc”, which is an indicator of Windows Mobile Professional (aka PocketPC) and is often the only clue for many such devices. The other call looks for both “HTC” and “Windows”. Many HTC Windows Mobile Professional devices try to pass for regular PCs, so this seems to be the best technique for sniffing (most of) them out.

I’ve already uploaded the code to the Google code repository. Please let me know if you spot any bugs!

UPDATED (June 6, 2010): Thanks to Tony, we discovered that the initial enhancement to detect PocketPC (“PPC”) in the DetectWindowsMobile() method also accidentally caught Macintosh PowerPC browsers. So I did a quick update today based on the suggestions which ought to hopefully disambiguate the desktop Macs.

Designing mobile-optimized web sites is hard enough. Imagine spending all of that time and money building a fantastic mobile-optimized web site — only to discover that no one actually visits the site because they can’t find it.

Experienced mobile web users have learned to expect that major web sites also have mobile versions. Unfortunately, the major mobile web sites use a handful of conventions for providing access to the mobile-optimized version of their sites. Some sites offer “m.mycompany.com” while others use “mycompany.com/wap” among many other variations.

So what is the best practice for supporting all of these different mobile web site address conventions? Support all of them, of course! Don’t turn away mobile traffic unnecessarily (nor the juicy mobile advertising dollars, if your site is ad supported). Best yet — it’s easy to do and ought to take only a few minutes’ of your tech team’s time. (Okay, maybe as long as an hour…)

Directory Structure

At Hand Interactive, all mobile-optimized web pages are saved in the “m” directory. So our mobile-optimized home page is actually:

www.hand-interactive.com/m/index.htm

Virtual Sub-Domains & Directories

It doesn’t matter too much where your content lives, whether it’s the “m” directory, “wap”, “mobile”, “foo” or whatever. What does matter is whether your users can find your mobile content.

So this is where you need to take the smart approach and re-direct the short list of easily “guessable” domains and directories to your mobile content’s real home.

We recommend that you enable the following addresses and redirect them to your mobile content. Click on the links to see them work with Hand Interactive’s own web site.

• /m: www.hand-interactive.com/m This is the real location where our mobile content is stored.
• /mobile: www.hand-interactive.com/mobile
  (Redirected to /m)
• /wap: www.hand-interactive.com/wap Even though our content is not in WAP format, it can be easily viewed on most WAP browsers, and many people are in the habit of looking for content using the WAP keyword. (Redirected to /m)
• m.mycompany.com: http://m.hand-interactive.com
  (Redirected to /m)
• mobile.mycompany.com: http://mobile.hand-interactive.com (Redirected to /m)
• wap.mycompany.com: http://wap.hand-interactive.com(Redirected to /m)

iPhone-Specific Sub-Domains & Directories

There are a growing number of companies offering content that has been optimized for display on the iPhone (plus iPod Touch, Android, Palm WebOS, etc. etc.). As with generic mobile web addresses, there appears to be one of several approaches to web naming that companies follow.

We don’t currently have any iPhone-specific content, but if we did, we would store it in the “i” directory. Until we do, we redirect the following sub-domains and directories to our regular mobile content directory (/m):

• /i: www.hand-interactive.com/i This might be a good place to store your iPhone-optimized content. (We redirect to /m)
• /iphone: www.hand-interactive.com/iphone
  (Redirected to /m)
• i.mycompany.com: http://i.hand-interactive.com(Redirected to /m)
• iphone.mycompany.com: http://iphone.hand-interactive.com (Redirected to /m)

Summary

In summary, the best practice is to support all of the obvious sub-domains (like wap.mycompany.com) and directories (like www.mycompany.com/wap) and redirect them to the real location for your mobile content.

(This article is re-posted from the original source on Hand Interactive.)

FYI: This page has been translated into Serbo-Croation: http://science.webhostinggeeks.com/mobilni-dizajn

Here are  a few quick recommendations for dividing up the mobile world online. You can use the FREE open source MobileESP mobile device detection code to help you optimize your web experiences.

OVERVIEW

In general, I recommend having two versions of each web page. They can offer the same news, articles, and other content, but the UIs (especially around page layouts, navigation and search) may vary considerably between them.

• One mobile site should be optimized for iPhone, Android, WebOS and other “iPhone Tier” devices.  These devices can display rich CSS (with CSS-driven layouts, colors, buttons, input fields, etc.) and handle rich JavaScript (such as sliding drawers, thumbnail image marquees, smart CSS-coded”popoups”, etc.). Use the DetectTierIphone() method to detect these.
• The other mobile site is for all other mobile devices, including smartphone devices with poor CSS and/or JavaScript capabilities (Nokia S60, BlackBerry, Windows Mobile) and the long list of mass market “feature phone” devices with small screens and limited browsers. (Think the Motorola RAZR, LG Dare, and anything else you can get free on a plan nowadays.) Use the DetectTierRichCss() and DetectTierOtherPhones() to detect these.

RICH CSS DEVICES

A quick note on what I call “Rich CSS devices.” If you’re really fancy, you could show the iPhone version of the page to Rich CSS devices (like BlackBerries and Nokia phones), but there are… a few issues with such a plan.

First, the Rich CSS class devices often display CSS acceptably if you are willing to make many compromises in your design. Plus, since these devices can’t reliably use JavaScript (or for some like BlackBerries, not at all), you would have to disable JavaScript features on these pages. So, unless you have a very compelling reason to go through such pain, I recommend simply offering these devices your general mobile-oriented pages.

Look at it this way: Why cripple the experience for your iPhone and Android users just so a few Nokia and BlackBerry users can see a prettier-but-crippled web page?

OPTIMIZATIONS FOR IPHONE THAT OTHER DEVICES CAN USE — OR GRACEFULLY IGNORE

As you may have heard, the iPhone has some extra smarts built into the browser. When you optimize your web site for the “iPhone Tier” of devices, the good news is that some of these features can also be used by other devices since most of them share the WebKit-based browser engine. Whatever the other devices can’t use, they will simply ignore silently and without causing error popups. Of course, I’m hoping that other devices pick up some of these unsupported features soon-ish. But in the meantime, don’t leave these out!

<HEAD> Section

• Optimize the Viewport for Mobile Screenwidths: <meta name=”viewport” content=”width=device-width, user-scalable=no”> (Alternatively, you could turn on scaling, if you prefer. Helps ensure content is re-laid out when the user rotates touchscreen devices.)
• Set the Favicon: <link rel=”shortcut icon” type=”image/x-icon” href=”images/favicon.ico”> (Some mobile browsers store the favicon for the bookmarks list, too. Not used by iPhone.)
• iPhone Home Screen Icon Image: <link rel=”apple-touch-icon” href=”images/apple-touch-icon.png”> (The icon needs to be 57 x 57 pixels.)
• Run a Web Page in Full Screen Mode: <meta name=”apple-mobile-web-app-capable” content=”yes”>
• Content is Mobile-Optimized: <meta name=”HandheldFriendly” content=”true” /> (De fact standard, not used by iPhone. Tells search engines and mobile browsers the content is mobile friendly.)

CSS Styling

• Input Field Virtual Keyboard Optimization: Tell the device’s virtual keyboard if the input field is for general text entry, an email address (<input type=”email” />), a telephone number (type=”number”) or a web address (type=”email”). Supported by the iPhone; other mobile browsers ignore these hints for now and default to plain text. [View article]
• Input Field – Turn On Auto-correction and Auto-capitalization:Sometimes you want these features on and sometimes you don’t. For example, you explicitly want them off in an email input field. Or you might want them on in a site-wide search input field. Here’s how: <input type=text autocorrect=”on” autocapitalize=”on” /> (Seems to be iPhone only)
• Input Field – Show ‘Watermark Hint’ Text: Show the label in the input field or an instructional hint such as “Enter search” which is shown only in an empty input field. Here’s how: <input type=text placeholder=”Enter search” /> (Seems to be iPhone plus some desktop browsers. You might consider a fancy JavaScript technique for clearing the field for non-iPhone devices on focus if the text in the input field matches the placeholder value.) 
  
• Rounded Corners: Don’t use clumsy images to give your boxes rounded corners! Instead, use CSS. All of the iPhone Tier devices can use the “-webkit-border-radius” and related CSS hints, so please use them!
• CSS3 No-Image Buttons: There are multiple techniques available for displaying custom buttons without using background images. They look great on the iPhone Tier device browsers.
• iPhone Animations: Mobile CSS/JavaScript toolkits like jqTouch are great and can include cool iPhone-specific animations — which don’t work on other devices. So be sure to turn them on only for iPhone devices. (For example, by putting animations in a separate CSS file that you dynamically load only for iPhone devices. Use the DetectIphoneOrIpod() method in MobileESP.)

FYI: This page has been translated into Serbo-Croation: http://science.webhostinggeeks.com/mobilni-dizajn