<\/p>\n
The mobile web is always evolving and one current trend is the rise of the full web on phone<\/strong>. By the full web, I mean being able to use any and all the web content available on PCs. It’s happening, thanks to better browsers and transcoders that can render almost any page on a phone screen. I’ve still believe that a made for mobile page will give a better user experience than a programmatic conversion of a page designed for an 600X600 px screen into something that fits the 176×220 px window of a mobile. But we need the full web on mobile phones too. Traditionally, mobile web development has been focused on taking a subset<\/strong> of web content deemed most relevant to the mobile user and rendering it in a format that works well on the limited browsers embedded in phones. Done right a mobile specific page looks great on mobile screens and is easy to navigate, but sometimes that’s not enough. The key is that the mobile web is a subset of the full web. There are times when we need some content or a service that can’t be found on the mobile web.<\/p>\n
The rise in mobile full web browsing has at least four drivers.<\/p>\n
The full web on phones doesn’t mean that mobile specific sites are going away. There will always be a need for small, fast loading sites designed for common mobile tasks like checking the weather, email, news headlines or getting directions. If you doubt that, consider the hundreds of iPhone specific web apps<\/a> that have appeared since that handset’s launch. Even though the iPhone has the biggest screen and one of the best browsers of any phone there’s still a demand for content relevant to the mobile context and formatted for its smaller screen.<\/p>\n
b) There should be a second URL that always loads a mobile specific site. Using a .mobi address is ideal for this but an “m” (m.Widgets.com) subdomain works too. The mobile site could either be a LCD (“Least Common Denominator” – one size fits all) generic one or it could use browser detection to deliver content optimized to specific mobile browsers. If the browser is unrecognized, an LCD site with less than 10KB of markup and a total data size under 20KB including images and style sheets should be delivered. Users entering through the mobile specific address should never<\/strong> be redirected to the full site even if they are using IE7. The user may be a blind person who has found the mobile site works better with their screen reader or it could be someone using an UMPC with a 4 inch screen<\/a>. The user asked for a mobile url, so give to them<\/strong>.<\/p>\n
The primary URL (widgets.com) should deliver what’s called, “Thematic Consistency<\/a>” meaning that, where possible, the same information is delivered to all devices visiting a given URL. The presentation should change to suit the device but the meaning should not. In other words, wapreview.com\/blog?p=438<\/a> should bring up the PC version of this post on a PC and the mobile version on a mobile. This ensures that both mobile and PC users will get the appropriate site when they follow external links to your site.<\/p>\n
Nokia Web Browser Design Guide
\n<\/a>
\nOpera – How to serve the right content to mobile browsers<\/a><\/p>\n
NetFront – Production Design Tips<\/a><\/p>\n
Apple – iPhone Development Guide<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
The mobile web is always evolving and one current trend is the rise of the full web on phone. By the full web, I mean being able to use any and all the web content available on PCs. It’s happening, thanks to better browsers and transcoders that can render almost any page on a phone screen. I’ve still believe that a made for mobile page will give a better user experience than a programmatic conversion of a page designed for … Continue reading