![\"](\"https:\/\/wapreview.com\/images\/tower.jpg\" "\\"")
<\/p>\n<\/p>\n
I don’t mean “internets” in the sense of the George Bush’s<\/a> “I hear there’s rumors on the, uh, Internets”. I’m thinking that while there is only one internet, there really are several separate unequal mobile webs. The inequality comes from the huge variation in capabilities of mobile phone browsers. I like to divide mobile browsers into 5 broad categories; full web, big page, advanced embedded, basic embedded and wml-only<\/strong>.<\/p>\n At the top are the mobile “full web” <\/strong>browsers like the iPhone’s Safari, Opera Mobile, Opera Mini 4.0, Nokia’s WebKit and the Smartphone version of Netfront. These browsers can handle pages of almost any size and have pretty decent JavaScript and CSS support. They can resize images on the fly and, because they are running on devices with fast processors, can render big, complex pages quickly. It’s not really<\/em> the full web because there’s no Flash or Java applet support, and the screens, although big for mobile, are never the 800×600 that most desktop sites expect. Desktop web sites do load on these devices but usability suffers compared with a PC. This is where the bleeding edge of mobile web development is occurring with sites like SoonR<\/a> or Leaflets<\/a> and other “iPhone Web Apps<\/a>” featuring complex formatting and the beginnings of a mobile AJAX. Full web mobile browsers are responsible for a small but significant, I’m guessing 10%, part of total worldwide mobile web traffic.<\/p>\n One step down are what I call “big page” browsers <\/strong> because they can handle relatively large (300+ KB) pages. This class of browsers has fairly good CSS rendering and usually has some limited JavaScript capabilities. Examples include the latest Blackberry Browser, Palm’s Blazer, Mobile Internet Explorer, Danger Hiptop\/Sidekick and Opera Mini 3.1 and earlier. These browsers can also load most desktop pages but the user experience is worse than the full web group because of weaker CSS and JavaScript support. I see more and more pages designed for this class of browser. These mobile sites feature large pages with the lots of text and\/or many images, for example, Engadget Mobile<\/a> or New York Times River<\/a>. Big page mobile browsers drive another 10% of total mobile web traffic.<\/p>\n A rung down are the “advanced embedded browsers”, <\/strong>the better feature phone browsers, capable of handling pages up to about 60 KB. They support basic CSS and render pages with multiple images fairly quickly. Whether a browser falls into this category or the one below often depends more on the amount of memory and the speed of the CPU it’s running on than the actual brand or version of the browser. On good hardware, Nokia’s Services Browser, Netfront Compact and the latest Obigo Browser fall into this group. These browsers can handle almost any made for mobile page relatively well. I’m guessing that this group makes up maybe 35% of the current mobile browser universe.<\/p>\n Then come the less capable xhtml browsers found mostly on lower end phones. This group, which I’m calling “basic embedded”<\/strong>, includes Motorola’s MIB, Openwave 6 and 7 and the older Teleca and Obigo browsers. Depending on how much memory they are given these browsers can handle maximum page sizes of anywhere from 10 to 60 KB. They tend to have quirky or incomplete CSS support and to slow to a crawl or lock up when asked to draw complex pages with many links, drop downs or images. This group comprises about 35% of all mobile browsers worldwide. The percentage is higher in the US due to Motorola’s market dominance and the fact that two national carriers, Nextel and Verizon, have standardized on old versions of the Openwave browser for all of their feature phones.<\/p>\n At the bottom are the wml-only<\/strong> browsers. While these are mostly gone in the developed world, they are still common on the used handsets popular in Latin America and Africa. I get a lot of traffic from wml-only browsers using the YesWAP.com portal’s html to wml transcoder. The transcoder is the most popular page on the portal, accounting for 75% percent of the total portal traffic, about 12,500 daily page views. Worldwide, wml-only browsers represent about 10% of the total today, a percentage that is slowly decreasing<\/p>\n What’s a mobile developer or site owner to do to support all these different classes of browsers. It is a mess and there is no way that a single site with no adaptation will even work on all devices let alone deliver a satisfactory experience. Like any design effort, a mobile site will be a compromise based on the target audience and available resources. I think there are three viable approaches; adaptation, least common denominator and tiered sites.<\/strong> Here’s a brief look at each:<\/p>\n Adaptation<\/strong> means using a device repository like WURFL<\/a> to drive a server side adaptation engine. The adaptation customizes image and page sizes and other site features like the presence of Ajax or multi-serving xhtml and wml. Building a good adaptation engine can be very complex but done right has the potential to deliver an optimal experience to every mobile visitor. Adaptation is commonly used by sites delivering multi-media content like videos, ringers, themes or wallpapers – where delivering the right content for a particular handset is essential to the business model.<\/p>\n Least Common Denominator<\/strong> (LCD) means creating a single version that works reasonably well on as many devices as possible. This approach provides the most bang for the buck. Some general rules for creating an LCD site that will work on 80% of all devices:<\/p>\n A tiered site<\/strong> extends the LCD approach by adding separate sites (tiers) that are more or less complex than the main LCD site. The idea is to start with an LCD site but supplement it with a richer full web browser or Ajax site (the highest tier) and\/or a bare bones or wml site as a lower tier. You can use a relatively simple script to redirect wml devices based on their Accept headers and full web browsers based on their User Agent header. A word of caution, simple script based redirection isn’t perfect, always provide and publicize alternate URLs with no redirection so that users can reach any of the tiers with any phone. OS News<\/a> is a good example of a tiered site.<\/p>\n Whichever approach you take I think it’s important to consider all five tiers of the mobile web and try to support as many as possible. While it’s certainly fun to experiment with mobile Ajax or to push the limits of Safari on the iPhone, if your site requires a full web mobile browser you are throwing away 90% of potential traffic.<\/p>\n","protected":false},"excerpt":{"rendered":" I don’t mean “internets” in the sense of the George Bush’s “I hear there’s rumors on the, uh, Internets”. I’m thinking that while there is only one internet, there really are several separate unequal mobile webs. The inequality comes from the huge variation in capabilities of mobile phone browsers. I like to divide mobile browsers into 5 broad categories; full web, big page, advanced embedded, basic embedded and wml-only. At the top are the mobile “full web” browsers like the … Continue reading \n