Not all mobile devices are created equal. Thus the age-old problem in mobile design and development: devices can be vastly different from each other. It would be easy if different devices simply supported different attributes—one supports CSS3 and one doesn’t. But it isn’t that easy. One device might support CSS3 and another device might support CSS3 poorly—or worse, incorrectly.
Honestly, this might not be a problem at all if we only had a few platforms or browsers to contend with. For example, how many big desktop platforms are there? Three: Windows, Macintosh, and Linux, with the first two making up almost 95 percent of the market. And how many big desktop web browsers are there? Four: Internet Explorer, Firefox, Safari, and Opera, with the first two making up nearly 90 percent of the market, the most recent versions of which all pass the Acid2 test for CSS2 support, effectively making them web-standards-compliant.
The mobile industry is an entirely different story altogether. In mobile, you have a half a dozen or so platforms, like the S60, iPhone, Android, BlackBerry, Windows Mobile, and LiMo smartphone platforms, plus a dozen or so feature phone platforms. Add the plethora of mobile web browsers that run on each of these platforms, for which less than 1 percent of all mobile browsers are able to pass the Acid2 test for CSS2 support, for example, and you can start to see that the mobile web is a very fragmented and difficult space to support.
Case in point: one would assume that if I enter www.domain.com into a web browser, I would be taken to the appropriate experience for my device and viewing context, right? This simple action is what we’ve promised to users regarding how the Web works. But of course in mobile, it isn’t that simple. Sometimes entering www.domain.com detects your device and sends you to the desired mobile experience. Sometimes we have to create m.domain.com , and the recent trend is to also create iphone.domain.com .
Where does it end? At what point do we just tell users that when they want to go to a site, they should enter a web address, regardless of their device? This is the topic of this chapter: adapting for multiple devices.
Detecting, adapting, and supporting multiple devices has historically been the worst pain point of mobile design and development. It usually requires a software system to perform a three-step process in order to render the best experience per device, creating plenty of opportunities for problems. Though there are several strategies to solve this problem, each of them work in this basic way:
This entire process is often referred to as multiserving, device adaptation, or simply adaptation. As you might imagine, this process requires the consideration and adaptation of many variables. It is in no way an obstacle that cannot be surpassed, but it does add significant cost and complexity to a mobile project.
Luca Passani, who maintains the largest open source device database (a necessity in this process), puts it this way:
Multiserving is a necessity, but creating (and maintaining) more than three versions means going down a very slippery slope.
So what are we, as designers and developers, to do? We know that mobile technology is important—it is the platform for the future, and we want our content in the space—but dealing with all of these devices seems like a headache that we don’t exactly want or need.
I’ve said before that whenever there are multiple options in mobile, there are no right or wrong choices—just what is right for the user. Let me stress that point here again as well. Not only are there no right or wrong answers in how you adapt for different devices, but there is strong support and intense opposition for a number of different approaches. Members of both the web and mobile communities have an almost religious belief that one approach is better than another, either through dogmatic principle or through years of experience.
Even this book isn’t immune to this debate. Each of the technical reviewers invited to review this chapter offered different suggestions and techniques for how to solve the problems of adapting for devices. Some were based on how the adaptation should be, and some were based on how to get it done in today’s environment. If I, as someone with more than a decade of experience in the mobile ecosystem, struggle to make sense of this topic, then I can only imagine how you must feel. However, I can provide my own perspective on the topic, which is a bit unique.
I come from a family of entrepreneurs. My father was an inventor and business owner. Each of my six brothers (of which I am the youngest) either own or have owned their own businesses. You could easily say that entrepreneurship runs in my family. I’m not immune; I own my business now, but I certainly didn’t start there. Like most people, I’ve worked for a number of different companies, and many of them just happened to be mobile companies.
In fact, I’ve had the pleasure of working with some really great companies and brands over the course of my career in the mobile industry. This topic, adapting for multiple devices, has been the coffin nail for the majority of them. Not only did the costs run them out of the mobile business altogether and force them to sell off assets way below their value, but the companies also started to lose faith in the long-term viability of the medium.
As an entrepreneur, I cannot in good faith recommend to anyone something that I wouldn’t be willing to make myself. To me, this is the only principle that matters. It isn’t a matter of industry dogma: it is a matter of business ethics.
In my experience, adapting for multiple devices is the greatest risk that your project can make. Too many challenges are unforeseen, there is too much knowledge that takes too much time to learn, and the hidden costs can too easily multiply beneath you. As you might imagine, I get a bit conflicted, as I also believe that mobile will be the most powerful and defining medium of the next 25 years.
So how does one balance the necessity of multiserving while still keeping mobile investments of time and money under control? I’ve found five basic strategies to work around this seemingly insurmountable obstacle:
In this chapter, I will discuss all five approaches to adapting experiences for multiple devices. I will focus primarily on the mobile web, but there is no reason why most of this knowledge couldn’t apply to all mobile experiences as well.
I will try to leave out debate as much as possible and just report what I believe that you need to know. There are of course many elements of this topic that could be expanded upon; in fact, an entire book could easily be written on just this one topic. But for the purposes of this book, I will introduce to you the general principles of adaptation and will leave it up to you to decide what is best for you, and more importantly, what is best for your users.
Let’s start with the circumstances that might cause you to consider an adaptation strategy in the first place.