The MobileESP Project: Easily detect mobile web site visitors

Hi, folks –

A developer using MobileESP for a commercial project and I recently exchanged emails about BlackBerry device detection. Generally speaking, the BlackBerry OS has lagged other smartphone OSes with regards to browser capabilities. This situation has made it challenging for web developers who wish to provide quality experiences on their web sites to BlackBerry OS users.

MobileESP has lots of methods to detect BlackBerry devices — six! But all of them were created for specific purposes to help better target specific classes of BB devices. You may find it helpful to review the full list of BlackBerry detection methods in the MobileESp API documentation. Here is a little more info on the key detection methods nowadays.

The purpose of the old DetectBlackBerryHigh() and -Low() methods was really for the two levels of pre-OS 6 version devices. After OS 6, if you need BlackBerry specifically, then you might use one (or a combination of) the following:

• DetectBlackBerry(): For any BlackBerry device, phone or tablet
• DetectBlackBerryTablet(): For tablets only.
• DetectBlackBerryWebKit(): For any “modern” BlackBerry device (phone or tablet) running BlackBerry OS. Generally speaking, this will test true on OS 6 or later.

So if you want a modern BlackBerry phone (OS 6 or later), then run this recipe:

• DetectBlackBerryWebKit() && !DetectBlackBerryTablet()

Or if you want any BlackBerry phone (any version OS), the run this recipe:

• DetectBlackBerry && !DetectBlackBerryTablet()

Of course when the new BlackBerry OS 10 launches in 2013, we will update MobileESP soon after!

And as you may have already read in the MobileESP blog, we generally recommend using the DetectTierX methods unless you are looking for a specific device for a specific purpose. For example, you should use DetectTierIphone() to detect all modern smartphones with an iPhone-class web browser running a variety of OSes.

This is pretty cool!

We recently ran into this listing of great HTML5 frameworks useful for mobile app development — and noticed that MobileESP made the cut!

http://skytechgeek.com/2011/11/html5-frameworks-and-useful-apps-for-mobile-web-development/

The projects all look great — a few of which were new to me. I’m slowly working my way through them in my spare time. Definitely peruse the list when you have a few moments and check them out. Let us know what you think of them!

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

Hi, folks –

As you may recall, the MobileESP code is written first and foremost so that it’s easy for you to read and customize. Although feedback from people in the field report that the code executes quickly and efficiently on production servers, there’s something you can do to help speed up processing a little more: minify it!

The process of minifying code removes white spaces at the very least, such as spaces, tabs, and line breaks. Depending on other options you choose, it may also remove comments and shorten the method and variable names (also called “obfuscation” because it also makes the code harder to read). So depending on the level of minification selected, you can enjoy significant size reductions!

Brooke D. kindly wrote in to share her favorite PHP minification tool online created by the web hosting company, CustomHost. Brooke reports that she’s been enjoying about a 50% reduction in file size to just 16 kb with no problems in performance. Check it out:

http://customhost.com.ua/php-minify/

 Do you have a favorite online JavaScript minifier tool? Please let us know!

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

Hi, folks!

This is just a quick note to let you know that I updated the MobileESP code to provide better support for tablets.

I also made an update regarding Windows Phone 7 whose Internet Explorer 7-based browser isn’t great. It’s definitely not in the same league as iPhone & Android despite initial optimism. Hopefully, when the IE 9-based update is pushed to devices in late 2011, it will live up to expectations at last.

Here’s a quick list of updates for this rev:

• PHP and Java only: Added a stored variable ‘isTierTablet‘.
• All: Added a new DetectTierTablet() function. This will detect all of the larger screen (minimum 8 inches) devices with HTML 5 support. These larger tablets ought to be able to share the same special web site design, if you decide to do something special for them.
• All: Added a new DetectBlackBerryTablet() function. This will detect the BlackBerry Playbook.
• All: Added a new DetectAndroidTablet() function. These should be at least 8″ and run Honeycomb or later to be considered. Right now, the only useragent we could find was for the Motorola Xoom. As other tablets launch (especially the Samsung and LG tablets), we’ll keep this one updated.
• All: The DetectAndroid() function was modified to exclude Android tablets. You want to show a Motorola Xoom the same version of your site as you would an iPad (either specially formatted or your regular site). You may NOT want to show a Xoom a that small screen, iPhone/Nexus One-optimized page.
  • It’s our current position that 7″ tablets like the original Galaxy Tab should probably be given a web page that has been optimized for the iPhone/Nexus One, if available, rather than an iPad page. This opinion is due to screen size. In portrait mode, it simply isn’t very wide.
• All: Moved Windows Phone 7 from iPhone Tier to Rich CSS Tier. Sorry, Microsoft, but IE 7 simply isn’t good enough.

It seems that I often forget a colon, a }, or some other silly error when I do these updates. So please be sure to let me know if you find any errors!

We’ll continue to monitor the tablet scene for the next crop of great Honeycomb-based tablets, plus the launch of the HP WebOS-based ones. As soon as we can get our hands on some useragent strings, we’ll update the code as necessary.

Special thanks to Justin M., Peter V., & Marc L.! Thanks for your help & support, guys!

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

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