44 Reader Comments

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.

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.

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/

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.

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.

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…

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?

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…

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.

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.

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.

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

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. www.iPhonestil.com
(Source: http://wiki.answers.com/Q/What_is_iphonestil#ixzz1OlfC1JvP )

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?