Mobile META tags can be used in XHTML-MP and HTML markup to tag the document as optimized for mobile devices. Mobile search engines, mobile browsers and even desktop web browsers look for mobile META tags to identify and render mobile-optimized markup.

Mainstream mobile web content is identified using the markup document’s DOCTYPE or document type declaration. If the DOCTYPE declares the document as XHTML-MP or WML, then by definition, the content is mobile-optimized.

Today’s advanced mobile devices and smartphones are capable of rendering HTML 4 and 5 markup (some with JavaScript and AJAX, too). Still, many mobile web developers prefer to deliver a mobile-optimized web experience to these devices. A lightweight and responsive full-HTML mobile web experience provides the best user experience across a mobile network and on the smartphone browser. Since a smartphone-optimized mobile web document uses the full tag set of HTML, its DOCTYPE is no longer the right criteria to use to decide whether the document is indeed optimized for mobile devices.

Mobile META tags can be incorporated into mobile-optimized HTML documents to identify the document as “made for mobile”. Here are several common mobile META tags and their interpretations by mobile browsers, mobile search engine spiders and robots.

The MobileOptimized META Tag

Microsoft invented the MobileOptimized META tag to control the layout width for mobile markup rendered in Internet Explorer Mobile (i.e. Pocket IE). The content of the meta tag is an integer width in pixels. In IE Mobile, the presence of this META tag forces a single-column layout at the specified width, preventing the browser from modifying the layout to “fit” the mobile screen. See this META tag reference at Microsoft for the tag’s interpretation in Windows Mobile 5.


<meta name="MobileOptimized" content="width" />


Some non-MS mobile browsers may also use the tag to force single-column layouts. Mobile browsers and mobile search engine spiders also use this META tag to identify mobile-optimized HTML.

The HandheldFriendly META Tag

The HandheldFriendly META tag was originally supported by AvantGo mobile browsers in Palm devices to identify mobile-optimized markup. Today, it is widely interpreted by mobile browsers and spiders as an indicator of mobile markup and a directive to display the web document without scaling. The value of the META tag is “true” for mobile markup and “false” for desktop-optimized HTML.


<meta name="HandheldFriendly" content="true" />


The Viewport META Tag

Many smartphone browsers scale Web pages to a wide viewport width, one appropriate for displaying desktop-optimized markup. These browsers allow the user to zoom in and out of scaled Web pages. For example, Opera Mobile uses a default viewport width of 850 pixels, and the iPhone uses a default width of 980 pixels.

The Viewport META tag controls the logical dimensions and scaling of the browser viewport window in many smartphone browsers, including Safari Mobile for the iPhone, Android browser, webOS browser in Palm Pre and Pixi devices, Opera Mini, Opera Mobile and BlackBerry browsers. The presence of the Viewport META tag indicates that the markup document is optimized for mobile devices.

Here is a simplified version of the Viewport tag that sets the browser viewport width at 240 pixels and disables user scaling of the content:


<meta name="viewport" content="width=240,user-scalable=no" />


The content value of the Viewport META tag is a comma-delimited list of directives and
their values.

This example <meta> tag lists all Viewport directives and example values:


<meta name="viewport" content="width=240, height=320, user-scalable=yes,
initial-scale=2.5, maximum-scale=5.0, minimum-scale=1.0" />


This table lists the meanings and values of all supported directives of the Viewport META tag.

For more details about the possible directives and values of the Viewport META tag, see the Supported Meta Tags section of the Safari HTML Reference.

The mobile web is a different beast from the good, old, familiar desktop web. Here are my Top 10 most important ways that the mobile web differs from the desktop web and techniques for succeeding on the mobile web.

1. Bandwidth Matters: Mobile web pages must optimize for byte size and minimize network round-trips required to download all page components. The smartest mobile device accessing the web on the fastest 4G mobile network still accesses the web an order of magnitude slower than a desktop computer. Mobile networks have coverage and capacity issues that mobile web developers must consider. Use whitespace minimization techniques, exploit browser caching and consider MIME/Multipart encoding for supported devices.
2. Mobile Sites are Silos: The mobile web is not nearly as connected as the desktop web. Mobile web sites generally do not cross-link to very many related sites. There are few authoritative sites on the mobile web that are not direct extensions of desktop web brands. Search ranking algorithms like PageRank that rely on websites conveying reputation through cross-linking do not apply on the mobile web.
3. Content Adaptation: Content adaptation on the mobile web is complex and challenging. Screen sizes on mobile devices vary by a factor of 17. (i.e. the largest mobile device has a screen that is 17x larger than the smallest mobile device.)
4. Browser Quirks: Web browsers in mobile devices frequently contain bugs in implementations of web standards. Operators sometimes rush popular mobile devices to market with enough pressure to overlook or bury “minor” browser quirks, causing endless frustration to mobile web developers. (For example, I know of a smartphone recently launched in North America with default microbrowser settings to download JPG and PNG images but not GIFs. Users could change this setting but – my god – the browser was set to ignore GIFs by default! Not a very smart phone.) Mobile web developers build up arsenals of known mobile browser bugs and workarounds. Users have little or no control over browser caching behavior.
5. Usage Patterns: Mobile web users want answers, not surfing. Users are generally on-the-go and looking for specific, timely information. Location-awareness is a key feature of mobile web services. The average mobile web session length is 3 minutes.





6. Discovery: Mobile users have difficulty discovering new mobile web sites and services. Desktop sites should advertise their mobile versions (and vice versa). What is the mobile version of example.com? example.mobi or m.example.com or wap.example.com or example.com/m/ or example.com/mobile/?
7. Transcoders: To “preserve the web browsing experience” for featurephone users, many mobile operators deploy transcoders that re-format desktop web sites (and some mobile sites, much to the frustration of mobile web developers) to provide syntactically-correct web surfing for mass-market mobile devices. Unfortunately, transcoding almost always destroys the usability of a web site. One desktop web page may be re-formatted into 20+ mobile pages. Forms don’t submit, content is re-formatted and text is spread across several clicks. Transcoders sometimes re-purpose (read: hijack) the original content by adding branded headers, footers and advertising. This is at best a questionable use of copyrighted web content.
8. Markup Validity: About 4% of desktop web sites use valid HTML markup. Desktop browsers tolerate invalid markup. On the mobile web, however, invalid markup can have drastic ramifications. Invalid mobile markup can cause mobile browsers to crash and even reset the mobile device. I have personally observed this worst-case scenario on mobile devices in the market as of this writing. Mobile web developers, become best friends with the W3C Markup Validation Service and ready.mobi mobile validator.
9. Keep URLs Short: Most mobile users still perform text entry with triple-tap. Keep a mobile site’s entry point URL short to give triple-tappers a break. Mobile users are more likely to browse to site.mobi vs. verylongbrandname.mobi/mobileversion/.
10. User Identification: It’s difficult to identify unique mobile users and track them over time. Mobile browsers may not support cookies. Operator proxy servers may strip cookies from HTTP traffic. IP addresses assigned to mobile devices are neither unique nor static.

Starting in Fall 2009, I will teach Advanced Mobile Web Development at Portland Community College in Portland, OR. It’s a new class that teaches advanced techniques for creating rich and interactive mobile web sites for smart mobile browsers that support full HTML and Javascript interactivity.

Students will learn to build advanced mobile web sites for iPhone, Android, Blackberry, Windows Mobile and other smartphones. Topics include interoperability, optimizing markup for advanced microbrowsers, embracing WebKit extensions, JavaScript and AJAX on mobile devices and effective use of device databases. Class project is to build an interactive, device-adapted mobile web site targeting smartphones.

See the Advanced lessons of the Mobile Web Development curriculum for details.

If you have ideas about Advanced Mobile Web Development lessons or any other feedback for this course, leave it in the comments or contact me directly.

I’ll post the CRN and other PCC registration details when they become available.

The Spring Term section of Mobile Web Development is available for registration at Portland Community College in Portland, OR. Here are the details:

• Class: CEU976E Mobile Web Development
• Review the Course Syllabus and Prerequisites
• CRN: 27913
• Fee: $350
• May 6 – Jun 10, 2009
• 5:30pm – 9:30pm on Wednesday evenings
• Class meets in Room 118, Mt Tabor Hall at PCC SE Center (SE 82nd and SE Division)
• Class location is a computer lab. Computers are provided. Laptops are encouraged. If using the PCC computers, bring a thumb drive to save your work.
• 2.40 CEU credits from PCC Computer Education Training and Certification program

The Winter Term class ends this Wednesday (March 11). It was super fun to teach. I think my seven students learned a lot about mobile development, mobile design and the cowboy realities of deploying a mobile web site on the public Internet. But, I’ll let them speak for themselves in the comment section (cough! cough!).