Users expect websites to work on their mobile phones. In two to three years, mobile support will become standard for any site. Web developers must add mobile web development to their skill set or risk losing clients.
How do you make websites mobile compatible? The answer is obvious: By testing them on all mobile phones, and by solving the problems you encounter. But, that’s a useless answer. It’s impossible to test your designs on every mobile phone out there. Within the mobile phone landscape, there are at least ten operating systems (OSs) and fifteen browsers that require consideration. Mobile devices are expensive, and not every web developer can afford to buy five to ten of them. Testing “on all mobile phones” is impossible for most web developers.
In this article, I’ll give you an overview of the mobile web market, as well as phone platforms and their browsers, so that you can decide which mobile devices to test on. Then, we’ll look at how to set up a mobile test bed.
The smartphone market#section2
Web developers should concentrate their testing efforts on smartphones. All good mobile browsers run on one smartphone platform or another. (Few non-smartphones have good browsers. That will change, but for now it’s true.) This begs the question: What is a smartphone? Here’s how I paraphrase the mobile industry’s more-or-less official definition:
A smartphone is a phone that runs a recognizable OS on which the user can install applications.
The smartphone market is divided into several submarkets, each of which has a distinct audience. For more information, read Tomi Ahonen’s articles on smartphone consumers and smartphone market share.
| Market | Share | OSs | Consumers |
|---|---|---|---|
| High-end | 20% | iOS Android webOS MeeGo Windows Phone 7 BlackBerry OS6 |
Within the high-end group, users care about web surfing and applications above anything else, and they’re willing to pay for these features. |
| Business | 35% | BlackBerry Symbian Windows Mobile Windows Phone 7 |
The business group includes phones that companies buy for their employees. The IT department decides which OS can access the company network so that users can retrieve e-mail and browse secure intranets. |
| Mid-range | 45% | Android Symbian BlackBerry bada Windows Mobile |
Within the mid-range category, users are interested in music, a good camera, and/or easy texting (which requires a hardware keyboard)—all in an affordable device. |
Notes:
- In 2009, about 175 million smartphones were sold worldwide. The market is expected to grow by 90% this year.
- Android is moving into the mid-range market with devices such as the Vodafone 845 that have cheaper, less powerful hardware.
- Now that Microsoft has released Windows Phone 7, Windows Mobile will disappear.
- MeeGo was not available at the time of this writing. It is likely to hit the market in the first quarter of 2011.
A game of platforms#section3
The current fight in the mobile world is about platforms. While the operating system is the most important ingredient of a platform, app stores and browsers are also important.
A platform competes with other platforms in its market, and that’s where it gets interesting for web developers. Every platform has its own default browser, and if a certain platform should win the war, its browser would gain a large market share and force web developers to pay attention to it.
In the high-end market, iOS and Android are the current front-running platforms. However, in 2011, they may get competition from Windows Phone 7 (Microsoft) and MeeGo (Nokia). BlackBerry OS6 (RIM) may try to enter this market, too.
Attention must be paid#section4
The problem is that most web designers and developers (not to mention the entire blogosphere) fall squarely in the high-end market. A cultural bias exists against OSs aimed at any other market. As a result, most people focus on the struggle between iOS and Android, and ignore the rest. This has to change.
In the mid-range market, Symbian (Nokia) is dominant right now, but bada (Samsung), BlackBerry (RIM), and the new mid-range Androids (Google) are strong competitors.
The business market is conservative. Although iOS tries to penetrate this market, and Android presumably wants to do the same, they haven’t yet succeeded. BlackBerry and Symbian continue to rule, with a smattering of Windows Mobile on the side.
The situation is complex, especially for someone who’s just starting out with the mobile web. I’ve created a mobile market overview table to help you make sense of it all.
The mobile browser market#section5
Although the platform wars will, in large measure, shape the future mobile browser landscape, web developers are likely more interested in the present environment. Let’s take a look at the current mobile browser market.
There’s only one source of mobile browser market share information: StatCounter. It does have its limitations: Their browser classification is sometimes strange, and the sites on which they measure traffic select themselves by subscribing to the service. Still, there is no other source of data. So what does StatCounter say for November 2010?
| Share | Browser | Notes |
|---|---|---|
| 22% | Opera | StatCounter lumps Opera Mini and Opera Mobile together. My personal estimate, based on discussion with Opera, is that about 90% of this number is Mini. |
| 22% | Safari | StatCounter splits up iOS into iPhone, iPod Touch, and iPad. It includes iPad stats with the Safari desktop—not in the mobile statistics. Therefore, this figure excludes the iPad. |
| 19% | BlackBerry | This encompasses mostly the OS5 and older models, which run a browser with a homegrown rendering engine. From OS6 on, BlackBerry uses a WebKit-based browser, and that will make our job a lot easier. |
| 17% | Nokia | Nokia’s WebKit-based browser comes in various flavors, some of which are better than others. Unfortunately StatCounter does not differentiate between each flavor. |
| 11% | Android | The Android market is pretty fragmented when it comes to browsers. There are some subtle differences between browsers on HTC and Sony Ericsson devices. Expect problems to arise from these inconsistencies. |
| 4% | NetFront | NetFront runs mostly on older phones from Asian vendors, notably Sony Ericsson. This figure includes the Sony PlayStation Portable as well as other gaming devices. |
| 1% | UCWeb | The most popular browser in China. It offers little functionality. |
| 1% | Samsung | StatCounter lumps all Samsung browsers together, from old NetFront-based phones to the new WebKit-based bada. |
These are global stats; traffic shares differ quite a bit from country to country. Find your own country’s stats before deciding which browsers to support. You may want to study your client’s log files to learn which devices people are using to visit the site.
If you’re interested, compare these traffic share stats to sales share stats reported by Gartner; you’ll discover many differences.
iPhone dominance#section6
If you compare the traffic and sales share stats, you’ll notice that Safari for iOS’s traffic market share is out of proportion to its sales market share. Keep this fact in mind while building mobile websites, but don’t use it as an excuse to test only on the iPhone.
There are two reasons why the iPhone dominates: First, iOS is the first platform created specifically for mobile web surfing. As a result, people who want to surf on their phone choose the iPhone (or, sometimes, Android). Second, Apple made sure that those who bought the iPhone would get a flat-fee data plan which encourages web surfing.
The flat-fee data plan is disappearing, however. AT&T in the US, and new iPhone carriers such as Vodafone in Europe, now offer a capped data plan because it is in their economic interest to do so. In the past, consumers reviled T-Mobile in Europe and especially AT&T in the US because they could not maintain good data connections (or even voice connections) for iPhone users. They had no economic incentive to improve their service because more iPhone data traffic wouldn’t generate more income for them. Hence the change in plans.
For this reason, as well as the increasing popularity of other OSs, I feel that the days of iPhone dominance are numbered, although I cannot predict how quickly that will happen.
The best mobile browsers#section7
So what are Safari’s main competitors for Best Mobile Browser?
Currently I rate four mobile browsers as “Excellent,” my highest rating:
- Safari for iOS—the best mobile browser overall,
- Android WebKit,
- Dolfin for Samsung bada—by far the fastest mobile browser, and
- BlackBerry WebKit, the new default browser for OS6 and higher. (Currently only available on the BlackBerry Torch.)
All four browsers support touch events, which are absolutely crucial to any seamless touchscreen-based interface. Also, they are all based on the WebKit rendering engine. Apple created it, and Google, Samsung, and RIM made it the starting point for their own browsers. (As did Nokia, Palm, and most recently LG.)
There is no unified WebKit on mobile#section8
However, WebKit and touch events do not necessarily make an excellent browser. Recently, LG released Phantom, a browser for low-end phones. Despite the fact that it’s WebKit-based and supports touch events, it is not very good.
This underscores a general rule of the utmost importance to web developers: There is no WebKit on mobile. I tested nine mobile WebKit-based browsers and they all behave differently. Not wildly so: Baseline CSS support is good, and JavaScript is definitely workable. Still, each one has its problems and strong points.
Because of this variability, it’s important to test your websites in as many WebKit-based browsers as you can. Don’t assume your website will work on the Android or BlackBerry WebKit-based browsers just because it works in Safari.
The good browsers#section9
The Apple, Google, Samsung, and RIM default browsers form what I call the Excellent class. Below them is what I call the Good class: this includes Opera Mobile, Palm WebKit for webOS, and MicroB, the Gecko-based default browser for Nokia’s Maemo OS, which will soon be replaced by MeeGo.
These browsers do not support touch events, and zooming varies in each implementation. From a pure CSS and JavaScript point of view however, you’ll encounter few problems.
Of the three, Opera Mobile is the most important, because it serves as a default browser for many Windows Mobile devices where the vendor decided IE wasn’t good enough. Currently, it’s an alternative for Nokia WebKit on Symbian, the largest mobile OS.
Opera Mini#section10
Opera Mini is an extremely important browser and you should definitely test your sites with it, because of the unique way it handles web surfing. It’s available for iOS and Android, as well as a host of other OSs.
Opera Mini is different from all other browsers we’ve discussed so far, including Opera Mobile. Where the other browsers just download the HTML, CSS, and JavaScript, interpret it, and render it, Opera Mini does something quite different. When you request a page in Opera Mini, that request goes to a special Opera Mini server. The server downloads the assets, interprets them, and renders the page. Then it sends back an image of the resulting page to your phone. You view the image via the Opera Mini client.
The advantage is that the Opera Mini client needs very little memory, which makes it especially suited to low-end, inexpensive devices. In addition, the actual data download consists only of a highly compressed image.
Opera Mini’s disadvantage is that it offers no client-side interactivity: If clicking on a link fires a JavaScript event handler for some Ajaxy goodness, Opera Mini goes back to the server to ask for instructions. The server handles the script and sends back an image of the updated page. However, it is important to note that this is a feature, and not a failure. For many people around the world, giving up client-side interactivity saves a lot of money, both in device and data plan costs.
Opera Mini is not the only mini browser. The most popular Chinese browser is UCWeb, which works on similar principles. I believe its homegrown rendering engine is lousy—in some situations it can’t even handle a simple link. Their switch to WebKit is only a matter of time.
Nokia WebKit#section11
In the first year of sales, Microsoft sold 240 million copies of Windows 7. Many of them shipped with IE8, of course. In 2009, Nokia sold 432 million devices. Over half of them had a Nokia WebKit browser as a default.
In other words, last year more copies of Nokia WebKit were pushed into the market than IE. Nokia WebKit is staggeringly huge. Still, its traffic market share is modest; the average Nokia user doesn’t surf the web nearly as often as the average iPhone user. That could change, though, and your websites must be ready.
There’s an older Nokia WebKit browser that runs on the S40 (the low-end OS) as well as older Symbian devices (up to S60v3 feature pack 1). There is also a newer Nokia WebKit browser that runs on newer Symbian devices. The latter is a bit odd, but workable. The former is more difficult. If you’re not sure which browser your Symbian phone has, run the Acid 3 test. The later browser will score around 50, while the earlier one will fail completely. Stephanie Rieger has written a great series of articles about Nokia WebKit that’s full of stuff you need to know.
Sites aimed exclusively at the US/Canadian market can mostly ignore the Nokia WebKit browser. Nokia has negligible market share in North America. Sites aimed at audiences in other regions should be tested on this browser, however.
Old BlackBerry#section12
Before OS6, BlackBerry ran its own homegrown browser, which was not a success. Unfortunately, the vast majority of BlackBerry owners still have this older browser; OS6 has hardly hit the market yet. But that’ll change.
JavaScript performance is the biggest problem with the old BlackBerry browser. (It’s pretty much absent.) On OS4.6 and before, this problem was almost unsolvable. OS4.61 and higher offer at least some script functionality, but it’s very cumbersome up until OS6, so you should just forget about scripting entirely for older BlackBerry browsers.
What about IE?#section13
I’ve already covered several browsers that I urge you to test your site on—the total test browser count is already higher than for the average desktop site. There’s a ray of hope between all the gloom, however: IE doesn’t matter on mobile.
The default browser in Windows’ Phone 7 is based on IE7 and incorporates some IE8 features. That’s better than Windows Mobile’s default browser, which is based on IE6. Older versions are based on IE4. Although Windows Phone 7 could become a hit, I believe it won’t ever command a 65% market share as it does on the desktop. I estimate that, in time, Microsoft will conquer 10 to 15% of the smartphone market, tops.
So the question becomes: Do we web developers dust off our IE knowledge, and force IE users to download extra style sheets? Do we force all users to download IE code branches over a mobile connection? Or do we ignore IE? I’m in favor of the latter.
Microsoft is aware of this problem, and knows it can make IE Mobile matter by upgrading it to IE9 levels. In fact, this is being done right now. If all our sites suddenly work in a future version of IE Mobile, all the better! And we might even start testing on it. But we’re not required to laboriously work around one IE bug after another, as we do for the desktop.
Other browsers#section14
There’s a few other browsers that you can ignore right now but that could conceivably become important in the future:
- NetFront is still used widely on older Samsung and Sony Ericsson devices, but it’s way behind the other browsers and will likely disappear in the not-too-distant future. A word to the wise: Ignore NetFront. It takes a lot of effort to support it.
- Obigo is LG’s browser of choice, and it is serious about keeping up with the other browsers. Where up until version 7.x it had its own rendering engine, it is now switching to WebKit. The first WebKit-based Obigo browsers are expected in early 2011.
- An Android beta of Firefox is available, but it still lacks important mobile features such as touch events. Mozilla’s bigger problem is that mobile users will not download another browser just because they can. So I think you can safely ignore Firefox for now, although that will change if a device or platform vendor starts using Firefox as its default browser.
Your mobile test bed#section15
Now, let’s apply your new knowledge of platforms and browsers to create a test setup you can use.
Start testing#section16
Start testing right now. Sure, you may only have one or at most two phones to use, but you will learn a lot just by viewing your site on any phone.
The most tricky mobile problem is one you can address right away: The tiny display. Every mobile phone has a tiny display by desktop standards, and your site needs to fit in it. Start experimenting immediately. Don’t worry that your devices are not representative of market share. Any mobile test is better than no mobile test.
Getting devices#section17
Then it’s time to shell out some money. You probably already have an iPhone or Android. Buy a BlackBerry or a Nokia Symbian—whichever is more popular where you live. Choose a medium-new, popular model. This will represent the smartphone masses that rarely browse the web—yet.
If you don’t have a big budget, buy a Nokia or BlackBerry non-touchscreen device. If you have money, reserve some for a non-touchscreen anyway. Not all users have a touchscreen, and you should definitely get acquainted with other input modes. If you have budget left for a third or even a fourth device, consider any platform I already mentioned, bada, Windows Phone 7, or Windows Mobile. Pick the one or two that have the greatest market share in your part of the world.
Install browsers#section18
Go through my browser list and install absolutely every browser you can download on the devices you already have. Pay special attention to Opera Mini and UCWeb.
Test services#section19
By now you have two to four devices with maybe six to ten browsers in total. If you still have a budget left, buy more. Without a budget to buy devices, you have two choices: test services or emulators.
The two main test services are Device Anywhere and Perfecto Mobile. Compare them and decide which one you like best.
These services have rows upon rows of mobile phones lying in their labs with webcams pointed at each of them, and you can access them through your desktop browser to test anything you want. This costs some money, but it’s a lot cheaper than buying the devices.
Emulators#section20
While emulators are the cheapest way to conduct mobile testing, I admit I’m not a big fan of emulators, because to be really good, the mobile browser has to be ported to Windows (or Mac), and much can go wrong in that process.
Go through the emulator list and install as many as you can. Unfortunately, most need an SDK to run within, which will bloat your computer.
Browser list#section21
Once you have a mobile test setup and clients who want their sites to work on mobile, make a generic browser list to insert into your contracts. Your client needs to know which browsers their site is going to work on.
Two browsers are inevitable: Safari and Opera Mini. Clients will likely ask for Android, too, and the mobile-savvy ones will insist on BlackBerry or Symbian. Agree on browser versions; this probably depends on the devices, test services, or emulators you have available. There are a few tricky bits here:
- Remember that BlackBerry OS4.6 or lower cannot run complicated JavaScript. Besides, you should let your client know that you may need to switch off the script in later BlackBerries, too. Only OS6 with the WebKit-based browser is safe to support.
- We already talked about Nokia WebKit’s versions. Try to leave out the older version; it’ll save you a lot of headaches.
- There was a major Android WebKit upgrade between 1.6 and 2.0. Make sure your contract specifies which Android version(s) you’re going to test on.
Even if your client only asks for the iPhone, make sure your site works reasonably well on at least one other mobile browser. Never pass up a chance to practice.
Progressive enhancement is your friend#section22
Progressive enhancement is your mobile development friend. Not everything will work on every mobile browser, but that’s OK. Not everything needs work on all browsers. If somebody uses Opera Mini and doesn’t see your animations, that’s acceptable. And be prepared to switch off your script entirely for older BlackBerries.
Progressive enhancement will become widely used once mobile web development becomes commonplace. On the desktop you are forced to keep your IE users happy, but on mobile the situation is quite different. So don’t hesitate to turn functionalities off for some browsers. As long as the user can read the content and use the navigation you’ve done your duty.
Mobile: the new frontier#section23
I hope this huge amount of information has given you a starting point for your own adventures on the mobile web. It’s going to be difficult; mostly because it’s so different from the desktop web. Besides, the detailed browser knowledge that we take for granted on the desktop is not available for the mobile web just yet.
That shouldn’t stop you from experimenting, though. Just try something that makes sense to you. Sometimes it won’t work, but that’s all part of the game. And if it does work, please write about it. Your fellow mobile web developers need the information.
Good luck, and remember: you’re not alone.
Reading list#section24
Here’s a reading list of mobile authorities. Subscribe so that you can stay informed on where the mobile market is heading:
- Tom Ahonen, a former Nokia executive, writes Communities Dominate Brands. This is the place to go for all kinds of stats. Reading his blog will give you a desperately-needed, non-web-centric general overview.
- Cloud Four Blog by Jason Grigsby. Jason is both a web developer and a mobile developer and pays particular attention to the media queries and native vs. web apps debates.
- Vision Mobile is a mobile market analysis and strategy firm that publishes a very interesting blog featuring provocative op-ed pieces.
- jQuery Mobile is John Resig’s latest project. jQuery is the first JavaScript library with a definite mobile browser strategy. The Sencha library is also an option, but it has started out as an iPhone/Android-only library and is only now adding more platforms.
- Yiibu by Bryan and Stephanie Rieger, publishes excellent articles about mobile web development and the various Nokia browsers. The site as a whole is an example of how we should go about mobile web development.
- Luke Wroblewski is a web designer with a specific interest in mobile. His touch gesture diagrams are especially interesting.
- WAP Review by Dennis Bournique mainly follows the mid-to-low-end market. He is known for exhaustively testing the mini browsers (Opera Mini, UCWeb, and similar ones). Dennis also features new mobile sites found on the web, which you can study for ideas.
- PinchZoom is Brian Fling’s mobile web company. There are many useful articles here.
- The Asymco blog by Horace Dediu follows the mobile market avidly, and has many a good insight to share.
- Mobile Industry Review is another high-level source that covers the entire mobile world.
- @EricssonLabs on Twitter will point you to the most important mobile stories of the moment.
- This Is Mobility is by Mike Rowehl, a mobile developer interested in the web. In addition to following the mobile world, Mike occasionally writes about how the mobile world views the web world, which makes for an interesting change in perspective.
- The Morgan Stanley Mobile Internet Report (PDF; huge) is probably the most complete overview of the mobile web currently available, even though it’s a year old.
- I founded the mobile web mailing list where plenty of thought leaders discuss mobile browsers, the mobile web, the mobile context, and other important topics.
- And finally the mobile section of my own site, QuirksMode. I write about the mobile market as seen by a web developer, including some densely technical topics that will become required knowledge for mobile web developers.
Editor’s note: this article was revised on 12-16-10 to update flat-fee Iphone data plan information.
Great overview of the mobile landscape. Testing for mobile is a rather tricky task and it’s nice to have a little bit of a roadmap.
If anyone hasn’t listened to it yet, I would highly recommend John Resig’s talk on the subject, given at Web Directions. “http://www.webdirections.org/resources/john-resig-testing-mobile-javascript”:http://www.webdirections.org/resources/john-resig-testing-mobile-javascript/
I’d also like to second PPK’s recommendation of the mobile web mailing list. It’s very active and filled with lots of good discussion – a fantastic resource for anyone interested in the mobile web.
… to test my sites on mobile? Better start increasing my rates for anyone who wants a mobile tested site.
Not to mention that this is an unaffordable sum for many many web developers all over the world. Which will result in many many sites all over the world not being tested for mobile.
What happened to the web being inclusive?
This is a very informative article, but by the end it pretty much wants to make me walk away from the web and go into pottery.
Testing on as many devices as possible is a great idea in theory, but in practice it is untenable. Even if we buy a few devices to try to cover more ground, they will be outdated in just a few months or a year at most. So are we supposed to buy multiple devices per year? (I don’t even like buying *one* new device regularly, to keep up with my personal smartphone habit)
I certainly agree with the author that testing in the top few browsers is important for anyone and everyone. But the mobile space is, simply put, still the Wild West: platforms and devices come and go rapidly, and there are only a few that will prevail, and we already know what they are: Safari and other variants of WebKit on iOS, Android, and Blackberry. And Windows (because evil will always exist in this imperfect world).
I wonder if there isn’t a better way to drive more mobile standardization by purposefully ignoring some of the smaller platforms and devices? As designers, we can help shape the landscape in this way. Platforms and devices have no value if there is no content for them. Trying to do good work for as many platforms as possible is a charitable and happy thought, but the good is the enemy of the great.
Perhaps we should focus on doing greater work for fewer platforms?
Surely there must be some emulators out there for testing the different mobiles? A quick search on Google yielded this:
http://mobiforge.com/emulators/page/mobile-emulators
Does anyone have any direct experience with emulators who could give a recommendation?
I understand that web developers are wary of buying boatloads of devices, but this is something that’s simply going to change in the next year or so.
Yes, buying a lot of devices will cost you a lot of money. But it’s simply an investment that you have to earn back from your clients.
Buying devices is not something you have to do immediately. It only makes economic sense if you’ve got enough clients that want mobile websites. On the other hand, you’ll never get such clients if you don’t invest in devices.
It’s a catch-22 right now. But that’ll change. Just keep an eye on mobile questions of your clients, and decide beforehand when it starts making sense to make an investment in devices. When you have two mobile jobs? Five? Whatever, just make a rule and stick to it.
I just recently acquired a bunch of devices for testing; most of them I purchased _used_ off Ebay and Kijiji and the total cost was only around $1600 CAD. Though, I’m missing a few critical devices like BB OS 6 and WP7 just because they were too new and out of my budget.
My biggest concern while choosing the devices was continued cost. I’m a little worried, like klayon, above, about having to get new devices every year. But I was also worried about the continued cost of just having these devices, so I specifically chose devices with WiFi so I wouldn’t have to pay for phone plans.
The iOS version share is around 50% iOS 4 and 50% iOS 3, is it worth investing in an older iOS 3 device?
I don’t want to seem like a troll, but if any one is interested, I wrote a blog post on what devices I chose: “http://thomasjbradley.ca/blog/mobile-testing-suite”:http://thomasjbradley.ca/blog/mobile-testing-suite
It hurt me how Netfront was tossed away with an “ignore it”.
I happen to live in Japan and the Japanese market, most of it, is Netfront and nothing else. And considering that the japanese mostly use only their phone as a way to access the internet, Netfront cannot be ignored.
Could be for you, but not here.
Great overview of the treacherous mobile landscape. It really enforces the fact that mobile can feel daunting.
Although I can’t really say I agree with going out and buying a fistful of devices in order to successfully optimize your site for mobile. Where do you even begin once you have your armory in hand? How do you manage all the little quirks in each OS/Browser and beyond that each version therein? Why neglect legacy devices?
On top of that the cost of devices alone is enough to make anyone cringe. Don’t forget to take into account the turn around time and lifecycle of the devices. Sure they are important now, but with an industry growing as fast as mobile you’ll miss an update if you blink. I’m getting motion sick just thinking about it — quick someone hold my hair.
Thankfully, I’m shameless and don’t mind plugging Mobify.
None of us sleep very much and browser quirks are what we give each other for our birthdays, which means we’ve spent all our time dissecting this daunting landscape and removing most of the worrisome complexity that comes with taking a site mobile across all platforms/devices, allowing designers/developers/publishers and anyone who wants a sexy mobile site to make one easily and without thoughts of suicide.
So, before you arrange any shady back alley transactions on craigslist, give us a shot.
To test for Opera Mobile and Opera Mini, there are emulators, it reduces a bit the test effort. It doesn’t solve everything.
http://www.opera.com/developer/tools/
There is also Dragonfly, a Web developer tool for tool, usable for remotely debugging a Web page on a mobile device from your desktop machine.
http://dev.opera.com/articles/view/remote-debugging-with-opera-dragonfly/
Both programmatic & declarative Javascript libraries have constantly increasing browser support – check back regularly for actual expectations on Sencha, jQTouch, jQuery Mobile etc
But the fact of the matter is that rich mobile web apps (/HTML5/CSS3/etc) work very well on contemporary WebKit, and can easily struggle elsewhere – so I think this stance is relatively unashamed, but future-worthy in the long run.
The mobile development landscape is indeed challenging. Thanks PPK for sharing your hard work and findings. I agree with testing on as many devices as possible and MOST discrepancies can be accommodated by starting with the lowest common denominator first and progressively enhancing using CSS. While progressive enhancement is a good place to start I think in some situations device detection is warranted. I didn’t see any mention of using device detection, but one particular situation is when delivering video. Have you conducted any research or do you know of any resources where I could find a listing of video formats supported across mobile devices and their browsers?
bq. Buying devices is not something you have to do immediately. It only makes economic sense if you’ve got enough clients that want mobile websites. On the other hand, you’ll never get such clients if you don’t invest in devices.
I don’t know if I buy this. By the time you get these devices and find the clients, the devices that you own will be trash and the carriers will have released a half-dozen new phones, with newer browser versions and their own quirks.
There’s a real problem with the smartphone market, where most of the software is embedded and most OS’s don’t receive updates. While there are a few counterexamples (iOS, the Nexus line), saying that 11% of the Mobile Web is Android is disingenuous, because that 11% is divided amongst n array of Webkit builds with vendor-specific tweaks.
The only real solution, IMHO, is the same solution we’ve been using on the Desktop. Set an arbitrary threshold of traffic above which a browser version qualifies to receive your support and testing. “Yahoo’s Graded Browser Support”:http://developer.yahoo.com/yui/articles/gbs/ is an excellent example of this, and I don’t see why it cannot apply to the mobile space as well.
This is the most depressing article I recall reading for many a day; not that I want to disparage PPK, whose work I’ve admired for many a year. It’s like being back in 1996 again, only worse because it’s the second time round.
If that’s the mobile landscape, I want no part of it. How can we be talking about this again after so many years working towards web standards?
As a professional web designer and developer, I’m taking the stance that these things either work or they don’t. I’m not going to even consider testing in these mobile devices, since to test in them would imply I was going to do something about what I found.
I follow the Yahoo graded browser support chart as best I can; these other things clearly count as X-grade browsers. Let the buyer take responsibility for their purchasing choices, and let the browser and device manufacturers differentiate themselves by how well they can render standards-based pages – there’s no way on earth I’m going to reward those who don’t by working around their bugs and I don’t think any other developers should either.
To repeat, I’m depressed by the article, but also by the acceptance of the premise by some of the other commenters on here that comprehensive browser testing on these devices is a reasonable course of action.
Have we learned nothing from the last fifteen years?
There’s a related but separate question of what the best practice approach should be to support different interaction models (multitouch and gestural UI input) but the answer to that is in my opinion certainly not to start doing fine-grained testing across all the possible devices, browsers and platforms.
I develop mobile sites for a living – here are my thoughts on emulators.
1) BlackBerry simulator is very good – free and a faithful reproduction of the rendering quirks you’ll find on a physical device. Only drawback is that it’s only available on Windows.
2) Android emulator is part of the SDK – again free and perfectly reproduces the *stock* Android experience. Works on Windows, Mac & Linux.
3) iPhone. Part of the SDK – free unless you want to release code on iTunes, Only runs on a Mac.
Sadly, Nokia don’t produce a mobile simulator. I’m sure that will be rectified with MeeGo.
If you *really* want to test on other devices, find a second hand shop an buy some old phones cheaply. Remember, you don’t care about cosmetic condition. As long as it boots, connects to the network and can display a browser window, that’s good enough for you.
It is important to test on old phone and obsolete software versions for one very scary reason. OLD PHONES DON’T DIE!
Seriously, jump on a bus and see what phone people really use – you’ll see Nokias the size of bricks and Chinese knock-offs which went out of fashion 5 years ago. People keep them because they still work and spending a couple of hundred pounds / dollars / Euros on a new phone is just too expensive.
They don’t upgrade, either. No normal user has ever plugged their Samsung or Nokia into their computer to check for software updates. Even iPhone, with its rigid tethering, doesn’t force upgrades upon people.
It’s like having to support IE6 FOREVER!
Anyway, great article!
T
Disclosure: I am increasingly well acquainted with the developers, who are active in the local (Southern Ontario) development community, and I would love to see them succeed. I do not directly benefit from their success, however.
The Ripple Emulator (http://ripple.tinyhippos.com) is a fantastic way to test mobile web applications and widgets. It is a Chrome Extension and emulates several different mobile devices. If you are frustrated by the giant stack of devices necessary to test against I think it is worth trying it out. It is free for the time-being (that may change once it is out of beta, I don’t know) and only takes a few minutes to install, and even fewer minutes to delete if you don’t like it.
An excellent article by PPK, which underlines my own experience in attempting to make mobile-accessible sites–experience that is frustrating and, as “Polsonby”:http://www.alistapart.com/comments/smartphone-browser-landscape/P10/#13 says above, depressing. The situation is indeed worse than the browser wars of old.
I am inclined to agree with Polsonby on the issue of user responsibility. Think about it: if I build a web site where the code adheres to web standards, the HTML is semantic, and I have taken the WCAG into account, then a blind visitor using a competent screen reader will be able to access the site. My responsibility is to code the site in such a way that it will facilitate use of a screen reader; it is not my responsibility to _supply_ a screen reader to every blind visitor to the site, and nor would they expect me to! Similarly in the bricks and mortar world, shops and other premises might provide wheelchair ramps to facilitate access for disabled visitors, but those visitors bring their own wheelchair. I rather think that if web browsing while on the move is important to you, then you should take some responsibility to get competent hardware… don’t buy a phone with a crappy browser. (Yes, I know a lot of buyers may not know the difference, but that’s what reviews are for–and there is no shortage of review sites for mobile phones.)
How far would I be prepared to go? I’m coming to the view that a reasonable and practical approach is the _mobile first_ concept, assisted by media queries (as “described by Bryan at Yiibu”:http://yiibu.com/about/site/ ). This should provide a good experience for competent mobile browsers, while at least delivering the content to incompetent ones, and without involving the developer in all kinds of device-sniffing horrors or testing on thousands of pounds/dollars/euros-worth of hardware. It may result in some devices seeing a simpler presentation of a site than they are actually capable of rendering; but hey, accessible, readable content is better than messed-up or no content.
The argument in “iPhone dominance” would seem to be that some networks that have the iPhone have flat rates, so therefore they have little incentive to improve service and therefore will lose marketshare.
But you also state in that same section that the flat-rate fee cannot continue as it is untenable. In fact that has already happened, and it happened with AT&T (in the U.S.) ahead of other carriers, that are still marketing unlimited plans in some cases.
So then how does it follow that iPhone dominance will decline when none of the conditions you lay out for the decline hold true any longer, yet still do to some degree for other platforms like Android?
I also am not sure I agree with pulling the iPad out of the browser share in terms of figuring percentage of devices to test; in part because one of the aspects to test for in the mobile realm is how touch-friendly the page is vs. needing a mouse.
With respect: instead of being persuasive for why we should target a particular platform framework, your projections and implied trending weakened the article; having data might have improved it, but I don’t think you answered your initial statement of purpose: How to make websites mobile compatible.
Interoperability testing – testing with specific technologies – is important when you absolutely have to validate something works or assess how usable (usability) something is for your clients. As a standards compliance testing and evaluation process, it is worst practice.
We have the same issue when testing for Section 508. Many people try and take the interoperability test approach – testing with a specific screen reader for instance – but that also fails. The most successful approach is validating the document (HTML) or application is coded to the standards and validating the API can be accessed. Testing with a specific assistive technology doesn’t do that in a open, repeatable way. Neither does testing on the particular mobile platform; updates and changes overcome the particular versions used when tested. Content and applications written today doesn’t work the same in newer platforms. The only thing we have to mitigate these changes is a standards-based approach.
I would love to see you expand the article’s ideas into less guessing and more empirical evidence, or specific coding techniques that fail, on a standards-based approach for content used on mobile platforms.
yeah, great article
http://mobiforge.com/emulators/page/mobile-emulators
is quite good
Thanks for putting this great resource together. I’d be interested to hear your thoughts on mobile frameworks like jQTouch, and how much they can alleviate the problems you’ve outlined.
Thnx for this good overview. Personally I think mobile browsing is our most recent incarnation of the web standards nightmare. And like it or not, my clients are not going to pay for (learning!) a bunch of new devices every year.
IMHO we need to degrade our sites for mobile platforms up to a level where it at least works in 95% of the times. And we also need to think of what we show. Not showing large visual headers or animations is only part of the deal. Our mobile version of the web site has a completely different theme and shows different information on its frontpage (e.g. contact information is crucial, sideblocks should not be shown). It’s not the perfect fit for every individual device but at least it works. And its affordable…
a cloud approach to handset access seems like a good idea.
does anyone have some comparison between those two services.
I’ve noticed that PM is much cheaper
Also I saw a similar service from Vodafone (http://developer.vodafone.com) which is actually free to use (you just need to register). is this the same?
Thanks
Wow, this post is more like a book, so I admit I did not read it in it’s entirety. The posts on this site are way too long overall.
But it does not matter because I did not agree with the premise.
Here’s the deal, mobile browsers are going to continue to get more and more like FULL PC/OSx browsers. So doing all this work to make your site display correctly in various mobile browser versions is a waste of time.
Further, the landscape is much simpler than portrayed here. You basically have Safari on the iPhones and the Browser in Android. If you are capable of displaying on those two you have enough of the market, and should spend your time on more important things.
Hopefully this “most recent incarnation of the web standards nightmare” will dissolve in future developments like the IE nightmare is in the process of dissolving and like the Netscape 4.x dissolved 10 years ago …
@ppk Thanks for the inspiration! You triggered an update of my (high-level) overview in “slidesha.re/gVTzDj”:http://slidesha.re/gVTzDj …
I would say the SDKs for both Android and Blackberry are very good and very thorough. I have yet to test something on the SDK and have it fail when testing it on a handset running the same software.
Another thing I have done in the past is to go to AT&T and Verizon stores and play with the display models of each type of phone. Not the quickest way to test, but it helps.
Also, I would think that you, of all people, would have mentioned the webkit link on newer devices, and the use of CSS3. Although fragmentation of the Android OS makes some things work a little odd, 99% of what I write for iOS works exactly the same on BB6 and Android 2.3. Thus, I really develop for one, and tweak a little if need be.
In the US, if your site is related to pleasure and not business, I am not sure there is a reason to build for any other devices. I work for a resort company and our hits from anything else is slim to none. Nokia isn’t a factor at all, and the only wild card is the Windows Phone 7. And although WP7 uses an IE7 based browser, it has been given features beyond IE8, so it could be very competitive. Not to mention the UI of the entire operating system is just so much nicer….
And to the fellow asking about jQTouch, I have used it on two sites now, and although flashy, isn’t anything more than that. It’s core is still jQuery, so if you don’t want the transitions, you would be better building a normal site and using jQuery. And to be honest, it isn’t optimized for building a good site. I had to do lots of band-aids to make it somewhat work like a website.
There are still A LOT of devices out there in real world use that StatCounter cannot detect because their browsers do not support javascript.
The only source of stats for mobile browsers is server logs. Anything that relies on javascript will miss out on a lot of devices. (and remember that you are probably not going to see much traffic from users using devices on which your website is not usable!)
Looking at my own server logs I still see a lot of those older and more basic mobile browsers – after all how often does the average person buy a new phone?
Terrific article! Very enlightening.
Like most others who have commented, I too am a bit appalled that one would need to go out and buy devices just for testing. I say this as a student as well: we are all so ambitious yet all so poor! When I go out and freelance this year, how could I ever expect to make a profit?
I think maybe we need to take a better stand on this issue. If you want a full browsing experience, go desktop. I think that the hardware companies should be ashamed that they are pushing out so many platforms. We cant keep up. And you know it’s one thing if my site works or not. It’s a whole other if we are talking about quirks. Quirks be damned!
And honestly: chances are eighty percent of content is best accessed not on a train, subway, hair salon…
As we say in college: consume responsibly!
This has been a hot topic with me recently. I also think that designing multiple versions of a website for various mobile phones is ridiculous. Most clients won’t pay to have their site reconstructed to support multiple mobile browsers anyway. Personally, I can’t stand surfing the internet on something smaller than my hand. I think a device the size of the iPad is much easier on the eyes and more comfortable to hold/type.
Mobile Design is a new and fast-emerging platform where designers can showcase their infinite creativity. I think Full Sail University is offering an experimental course on this one.
I tried multi-phone emulator applications a few years ago and they’re not very good. But what you could use is the IDEs for developing applications for these platforms. They come with a simulator/emulator with a browser installed. Most of them are free apart from maybe Windows Phone 7, though the iPhone one requires a Mac.
Mobile browsing is just a ~4% of all the market… right?
So I don’t think is critical for all website to have a full support of mobile… It will still make more sens to support IE6. Of course it depend of your audience.
Any way mobile browser become better with a better support of the standard. Except “:hover”….
I just don’t get why client are ready to paid to support iPad (0.2% of the market) it’s just a bad investment.
The best thing I can say here is that mobilcomplexity will most certainly raise your expense as a developer or designer and that absolutely should raise the cost to your client. Let your client decide how much testing they want to fund. If you don’t have a device in your toolkit, charge your client 100% of the cost of the device (without ongoing contract) and give them the option of waiving/reducing that fee to use an emulator for testing (when available). Be honest about the tradeoffs. When you do have the device (or use an emulator), charge a modest mobile testing fee and stash the cash for a future hardware upgrade when needed.
Allowing your client to be the decision maker both educates them on the real world expense and complexity of making their site mobile friendly, and ensures that you aren’t unnecessarily bearing the additional financial burden.
As a web developer, smartphones are now realities, more forward daki think every developer when developing an application that not only will it run on desktop browser but also for smartphones.
YUI 3.2 is also an excellent option as a library for use on both desktop and mobile browser platforms acting as a robust abstraction layer between your own code and the browser. With progressive enhancement built into the core library it helps to get into that mindset of development.
http://developer.yahoo.com/yui/3/
Video: Satyen Desai — ‘A Phone, a Tablet and a Laptop Walk into a Bar…’—YUI’s Approach to Mobile Web Development
http://developer.yahoo.com/yui/theater/video.php?v=yuiconf2010-desai
This is a great overview!
However, in terms of future prospects it’s rather vague.
Inability browse the net the way they are used to from their home computers and view their favorite sites makes people consider other options. Netbook is one of rarely mentioned smartphone rivals. Though it’s usually compared with a laptop, it has a lot in common with smartphones. It’s small, portable, and cheep. Most importantly, it’s perfect for browsing the net, checking your mail, and staying in touch with your friends.
Few people will buy a bunch of brand new devices at a sky high price just to test several sites.
And while the problem of standardization remains unsolved, netbooks and iPads are becoming more and more popular.
I have just recently moved into production for mobile sites and one of the first things I was tasked with was drafting a device classification and supported device strategy.
This article covers a lot of the challenges I discovered through my research, and covers them well. This is a fantastic starting point for those who are moving into the fast changing world of mobile web.
The article implies that Apple wrote WebKit from scratch, and everyone else copied it. Not true. WebKit was a hostile fork from the open source KHTML project, part of the KDE project. The engine, KHTML, is Free Software under the LGPL.
Apple took the KTHML code, forked it, made a lot of (admittedly good) improvements, and then did not contribute their changes back upstream, or at least not in any useful way. Various other parties then started their own branches off of WebKit (which, being LGPL, Apple could not close) and building their own browser variants, sometimes contributing features back upstream and sometimes not. That’s why there’s so much variation between WebKit derivatives, which is a serious problem and will become a bigger problem in the future.
That’s not to say WebKit isn’t a good engine (it is), or that Apple didn’t do good work with it (they did). But to imply that Apple invented WebKit and everyone else just copied-and-broke it as the article does is simply wrong.
Here you can get much information about iPhone accessories, such as iPhone protective case, protective film, charger, cable, etc. All of which is not only the descriptions or images of a device, but also there are lots of interesting topics that are closely contact with our lives! In addition, you will also read the latest and current news from Apple as quickly as possible. http://www.iPhonestil.com
(Source: http://wiki.answers.com/Q/What_is_iphonestil#ixzz1OlfC1JvP )
There are various infinity smart phones available in the market. Through which we can develop websites and also use for entertainment purpose. I having this software on my android phones.
I am not so sure if the separate mobile view will be a success storry. Browsers like Mobile Safari are already good in showing normal websites as you see them on computer, actually even better then IE’s before 9. I think mobile view and computer view will be the same in future.
Resources like the one you mentioned here will be very useful to me! I will post a link to this page on my blog. I am sure my visitors will find that very useful.
Although I can’t really say I agree with going out and buying a fistful of devices in order to successfully optimize your site for mobile. Where do you even begin once you have your armory in hand? How do you manage all the little quirks in each OS/Browser and beyond that each version therein? Why neglect legacy devices?
I wonder how this works for the iPhone 4, which has a 960 x 640 resolution. You could use the only-rule with width:960px, but that means that all screens with a lower width will use this stylesheet. What is the best way to handle this?
Sorry, replied to the wrong article!
Thank you for this great, detailed overview. I agree it can be daunting and you need to stay up to date as it changes a lot. Thanks for including tables, they’re very useful.