![\"Digg](\"https:\/\/wapreview.com\/images\/digg.png\" "\\"Digg")
<\/p>\n<\/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 Most mobile web traffic is still to mobile formated sites. But more and more users are wandering off onto the full web in their search for information and services they can’t find on mobile specific sites. What does the increasing use of non-mobile sites on mobile devices mean for us as content providers and developers? As always it’s about the user experience, make it easy and intuitive for users to find and consume the content they want. To me this means two things:<\/p>\n 1) Make sure that anyone, regardless of the device they are using, can reach your full web site AND your mobile site. <\/strong>Too many content providers, having created a mobile version of their site, redirect all mobile users to the mobile site with no way to get the full site. This is presumptuous and anti user. That user may be a village doctor in Zambia looking up information critical to a patient’s survival, information that’s not on a mobile site. A related problem is that many sites route unrecognized mobile browsers to the full site. The databases driving mobile browser detection and content adaptation can never be 100% complete, there are just too many devices, in too many markets with new ones being released almost daily. It’s really annoying to be redirected to the full, often unusable, version of a site because my phone is too new or uncommon to be recognized. I believe every website that offers both a full site and a mobile version should have three main URLs<\/strong><\/p>\n a) The site’s default URL, for example, “Widgets.com”, should use browser detection to route users to the version of the site that the content provider believes will give the best experience on the user’s browser. In other words, send PC browsers and unknown browsers to the full site and mobile browsers to a mobile site. There could be additional adaptation of the mobile content to specific browsers or classes of browsers.<\/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 c) The third URL should always deliver the same web content a user running Firefox or IE would see regardless the actual browser being used. I’d caution against the www subdomain (www.widgets.com) as the URL for these PC specific sites. Many users think they have to start URLs with “www” and some mobile browsers will add “www.” and “.com” to addresses entered without any dots in them. It’s better to treat “www.widgets.com” exactly like “widgets.com”, delivering browser specific (mobile or PC) content. The PC specific URL should be something like pc.widgets.com or web.widgets.com. There’s nothing wrong with applying browser specific tweaks and hacks to optimize the rendering for known PC or mobile browsers but all the content should be included.<\/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 Always provide a link to the equivalent mobile page at the top of each full web page and a link to full content at the bottom of mobile pages<\/strong> for the benefit of users with unrecognized browsers and others who land on one version of the site when they wanted the other.<\/p>\n 2) Take full web mobile browsers into account when designing web pages for PC browsers<\/strong>. Resources:<\/strong><\/p>\n Nokia Web Browser Design Guide 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 \n
![\"K2](\"https:\/\/wapreview.com\/images\/k2.png\" "\\"K2")
![\"Wordpress](\"https:\/\/wapreview.com\/images\/tiga.png\" "\\"Wordpress")
The most important thing about making your pages look good on mobile full web browsers is to put main content as close as possible to the top of the source markup<\/strong>. Mobile full web browsers and transcoders usually ignore CSS positioning and render a page as a single column. Screen items appearing first in markup are rendered first. Some CMS and blog templates put the sidebars above the main content in the markup which has a disastrous effect on usability in mobile browsers. The screen shots compare two WordPress themes, K2 and Tiga. Each shows a single post from the respective theme’s development blog\u00a0 in Opera Mini. Notice the difference in scrollbar position. I had to scroll through an agonizing 21 screenfulls of sidebar content to reach the post on the Tiga site. With K2, the first post appears at the top of the page no scrolling needed! There are other things you can do with markup and CSS to optimize a site’s appearance and usability in mobile full web browsers. I’ve listed some resources for designers below:<\/p>\n
\n<\/a>
\nOpera – How to serve the right content to mobile browsers<\/a><\/p>\n