The “Real” Web on Phones and What it Means for Designers

Digg zoomed out in Opera Mini

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 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 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.

The rise in mobile full web browsing has at least four drivers.

  • Improved browser technology is appearing on a sizable percentage of handsets. Opera Software has been a leader with Opera Mobile 8.65 pre-installed on feature phones like the RAZR 2 and the free download of Opera Mini which runs on most handsets. These browsers can load virtually any web page and render it in a usable fashion with techniques like zooming, content folding and fit to width. Other browsers incluing WebKit on the iPhone and S60, the Danger Hiptop/Sidekick‘s proxy based browser and NetFront offer similar capabilities on other phones. Larger, higher resolution displays and the growing market share of smartphones mean that the full web is available and usable on more and more handsets.
  • New web users, primarily in the developing world, whose only way of getting to the web is though their phones. These users aren’t just using the mobile web to do a quick search for directions or the weather when on the move, they are using it to transact business, shop, do academic research and everything else that the web offers.
  • Better transcoders from Mowser, Skweezer and Google make the majority of full web sites usable on even the most brain dead of built in mobile browsers. A lot of the traffic to transcoders is coming from the developing world.
  • The iPhone has increased awareness and desire for the full web on phones. “The web on your phone” sounds great and even though it hasn’t worked that well in the past, a new generation of users has seen the iPhone commercials showing that it is possible.

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 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.

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:

1) Make sure that anyone, regardless of the device they are using, can reach your full web site AND your mobile site. 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

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.

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 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. The user asked for a mobile url, so give to them.

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.

The primary URL (widgets.com) should deliver what’s called, “Thematic Consistency” 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 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.

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 for the benefit of users with unrecognized browsers and others who land on one version of the site when they wanted the other.

2) Take full web mobile browsers into account when designing web pages for PC browsers.K2 WordPress Theme Wordpress Tiga theme 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. 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Ā  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:

Resources:

Nokia Web Browser Design Guide

Opera – How to serve the right content to mobile browsers

NetFront – Production Design Tips

Apple – iPhone Development Guide

6 thoughts on “The “Real” Web on Phones and What it Means for Designers

  1. You raise some good points here, particularly worth remembering that mobile users don’t *always* want to be forced to a mobile site, and also that it is a major pain in the a*se to scroll through pages of rubbish on each page load on a mobile browsing a made-for-pc site, to get past the menus and to the content.

    Having said that, I always balk at this talk of separate domains for separate devices. This is not user friendly, it stinks of a stupid techy workaround constructed by geeks and forced on non-technical users. Plus it’s crap to have to type the extra “m.” or “.mobi” on a phone keypad – *any* extra keypresses are not a good thing. What’s the solution? Automatic redirection is the obvious one, but as you say with links to an alternative version. Or, if a user-agent does not indicate one of the obvious desktop browsers, perhaps a mobile-friendly landing page with 2 plain links to the different versions. I think whatever solution is chosen, the server should use *some* intelligence about what device is browsing and do make *some* inferences on what to serve from that. It’s not the end of the world if a mobile user gets served a lightweight mobile page first, and has a link to the full pc-site content.

    Sites should definitely not force the extra level domain (m. or .mobi) on users. Apart from the keypress issue, lets face it there is no consensus on what extension to use. .mobi are wonderful as a developer resource but the concept of it being *the* extension for mobile sites is daft (esp. considering the keypresses required to enter .mobi on a keypad) and little more than someone’s not-so-bright idea to make a few bucks off the punters (at which they’ve been pretty successful it seems). A consumer should be able to simply go to “domain.com” on any device and get the right site, either automatically or with one click. Having to remember extra daft prefixes or suffixes to that, that are non-standard and vary according to some geek’s daft ideas, is not the future, and should be axed now.

    Finally, this is another reason why Vodafone UK, Vodafone Ireland, and various other operator’s blind and blunt use of content transcoders from Novarra and the like are so damaging. If you block the user-agent string in the HTTP headers, as they do, it makes it damn hard if not impossible to serve the correct content to the device. Despite Novarra’s protestations they are not and never will be a standard. Luckily progress is afoot to put a stop to this stupidity, but it’s worth being aware of currently if you rely on the user-agent for adapting content as most mobile content providers do.

  2. Pingback: links for 2007-11-26 at .Dust

  3. Pingback: Do You Want The Full Web On Your Phone? | StayGoLinks

  4. Hi Jo,

    Thanks for the comments and additional resource links. Regarding multiple sites and thematic consistency, I wasn’t very clear, what I’m proposing is 3 URLs (really URL patterns), not sites.

    – 1 Main URL (wapreview.com, google.com, mtld.mobi, etc.) This url (and any variants of it like maps.google.com or wapreview.com?p=438) uses browser detection and content adaptation to serve content optimized for the user’s PC or mobile browser. This url enforces thematic consistency and should be getting the majority of traffic from both mobiles and PCs.


    – 2 A mobile specific URL or subdomain
    , like wapreview.mobi, google.mobi, m.yahoo.com etc. that always returns a mobile friendly site. This is for the benefit of users who have a need to view the mobile version on a PC or whose mobile browsers are not detected as such by the main site’s detection and adaptation code. I recommend using a .mobi domain for the mobile specific URL because a standard way of representing mobile sites is needed and .mobi is very widely recognized as denoting a mobile site. In addition I support the work of mTLD in defining and promoting standards, encouraging and supporting independent mobile web developers and tools giving like the Virtual Developer Lab and the Ready Mobi Checker to the community

    -3 A full web specific url
    (pc.wapreview.com or http://www.engadget.com/?m=false) that always delivers a full web PC browser site . Like URL 2, this is for the benefit of users who get the wrong version because of the limitations of browser detection or who want to view the full site on a mobile because the information they need doesn’t exist of the mobile site.

    There is no true thematic consistency to the 3nd and 3rd URLs although something like wapreview.mobi/blog/?p=438 and pc.wapreview.com/?p=438 should (but currently doesn’t) deliver the mobile or PC versions respectively of the content multi-served by wapreview.com/?p=438.

    Dennis

  5. I’m not clear what you mean by on the one hand having three sites and on the other hand wanting to offer a “thematically consistent” experience.

    A couple of additional references may be interesting to add to your list above:

    W3C Mobile Web Best Practices http://www.w3.org/TR/mobile-bp/ (see the sections on One Web and Thematic Consistency)

    dotMobi Mobile Web Developers Guide http://dev.mobi/node/201

    Jo

Comments are closed.