The Mobile Book PDF

e Mo b i l e B o o k
B y S ma s h i n g Ma g a z i n e
THE MOBILE BOOK
Published 2012 by Smashing Media GmbH, Freiburg, Germany. Printed in EU. Cover Design and Illustrations created by Mike Kus. Proofreading: Andrew Lobo, Clarissa Peterson, Iris Ljenjanin. Author Bios: Cosima Mielke. Editing and Quality Control: Vitaly Friedman, Iris Ljenjanin. eBook Production: Talita Telma-Stckle, Andrew Rogerson, Markus Seyfferth. Marketing: Stephan Poppe. Design and Layout: Ricardo Gimenes, Mike Kus, Melanie Lang, Markus Seyfferth. Typefaces used: Elena by Nicole Dotin (Process Foundry), Whitney by Jonathan Hoeer and Tobias Frere-Jones, Skolar by David Bezina (Type Together). The Mobile Book was written by Peter-Paul Koch, Stephanie Rieger, Trent Walton, Brad Frost, Dave Olsen, Dennis Kardys, Josh Clark. The extra eBook chapters of the book were written by Greg Nudelman, Rian van der Merwe, Nathan Barry, Arturo Toledo, Sebastiaan de With, Remy Sharp. Reviewers: Andreas Constantinou, Brad Frost, Bruce Lawson, Bryan Rieger, Dave Olsen, Dennis Bournique, Francisco Inchauste, Krijn Hoetmer, Lyza Danger Gardner, Peter Beverloo, Rian van der Merwe, Scott Jenson, Tom Giannattasio, Tim Kadlec, Trent Walton, Vasilis van Gemert. Idea and concept: Vitaly Friedman, Sven Lennartz. All links featured in this book can be found at smashed.by/links. The Mobile Book: smashed.by/the-mobile-book.
FOREWORD
BY JEREMY KEITH
TABLE OF CONTENTS
Foreword by Jeremy Keith
PART ITHE MOBILE LANDSCAPE
9 55
Whats Going On In Mobile? by Peter-Paul Koch The Future Of Mobile by Stephanie Rieger
PART IIRESPONSIVE WEB DESIGN
91 129 175
Responsive Design Strategy by Trent Walton Responsive Design Patterns by Brad Frost Optimizing For Mobile by Dave Olson
PART IIIUX DESIGN FOR MOBILE
225 289
Hands-On Design For Mobile by Dennis Kardys Designing For Touch by Josh Clark
BY JEREMY KEITH
FOREWORD
his book is an artefact of its time. There will come a time when this book will no longer be necessary, when designing and developing for mobile will simply be part and parcel of every Web workers lot. But that time isnt here just yet. So in the meantime youve got the current state of all things mobile packed together into this single volume. Youll nd technology-agnostic chapters on design patterns for mobiles and touchscreen devices; patterns that will prove useful whether youre building native apps or publishing on the Web. But, unsurprisingly, the majority of this book concerns itself with responsive design. Thats good. Thats very, very good. I remember when responsive design was rst unveiled. It really resonated with meIve always been a big fan of the One Web approachbut I thought it would be a hard sell. At the time, the default strategy for dealing with mobile devices was to build a separate mobile silo, usually in a subdomain sequestered away from the real site.
Its been amazing to see how quickly the practice of responsive design has spread. In retrospect, I shouldnt be surprised: the silo strategy simply couldnt scale to cover the multitude of different devices out there. Also, if youve ever explained responsive design to a non-techie, their response is usually something along the lines of Well, thats just common sense, isnt it? Its certainly sense but it isnt quite common enough yet. There will come a time when conferences and books targeted specically at mobile devices will seem quaint and anachronistic ...but were not there yet. So enjoy this bookdont let PPK scare you with his horror stories. And hold on to this book even after youve read each and every knowledge-lled chapter. Because this book is an artefact of its time.
ABOUT THE AUTHOR Jeremy Keith has been building websites since the 90s. After a few years of freelancing, he formed the design agency Clearleft with his fellow Web nerds Andy Budd and Richard Rutter in 2005. His message to you: I know it feels like there is an innite amount of new stuff to keep up with every single day, but you know what? Its okay. Its okay not to know everything.
6 | FOREWORD
The Mobile Landscape

i. ii. Whats Going On In Mobile? The Future Of Mobile
8 | WHATS GOING ON IN MOBILE?
CHAPTER ONE
BY PETER-PAUL KOCH
WHATS GOING ON IN MOBILE?
he most chilling moment of my entire 13-year career as a browser tester occurred back in 2009, when Id been studying mobile for a few weeks. I started my mobile investigation by testing as many browsers as I could, ably helped by the fact that the Vodafone ofce in Dsseldorf allowed me unlimited access to its huge device library. I asked the Vodafone guys to surprise me with odd devices with a wide range of operating systems, input methods and browsers, and one day I was handed a Samsung F700. I ran the browser through my JavaScript browser detection script and found that it was Opera Mini 2. That surprised meOpera Mini was at version 3, and version 4 was going to be released soon. Why would the F700 run such an antiquated browser? I jotted down a note with a question mark and went on to the next device. A few weeks later I ran the F700 through the server-side detection script that Id meanwhile written and found that the browser was NetFront 3.1. I went back to my client-side script and still got
BY PETER - PAUL KOCH |
Opera Mini 2. Also, there was a bright red navigation bar that I hadnt coded into my page. I still remember the chill that crept into my heart. This browser was not obeying the rules. This browser identied itself as Opera Mini 2 on the client and as NetFront 3.1 on the server. Thats not allowed in my bookand Id never encountered anything like this in the wild. I loudly complained to the Vodafone guys, and one of them said, Oh, that. Its content adaptation. He ddled with my phone, and the effect disappeared, never to return. From then on, client and server agreed that the Samsung F700 ran NetFront 3.1. It turns out that operator networks run a script that detects your device, and if it decides your device is too old, it automatically switches you to an old version of Opera Mini that runs on their servers and that includes its own navigation bar on any website you visit. That explained the Opera Mini that my JavaScript detection saw. However, the browsers real HTTP_USER_AGENT header arrives at the server, which was the reason why my server-side script returned NetFront 3.1 as a result. All of it was caused by a SIM card setting. Compare this behavior to normal ISPs. Say you run a slightly antiquated Firefox on a not-too-new desktop computer, and your ISP decides that its not good enough for you and switches you to an old Opera running on its servers, including its own navigation bar on any website you visit. People would be livid. Its not the job of your ISP to change your browser for you. Mobile operators, however, do this sort of thing all the time because they think its a serviceand because they want to control their customers. They want to avoid the fate of the desktop ISPs, which have become dumb pipes that exist only to move data from A to B. You have to remember this crucial difference between desktop and mobileit explains many of the operators actions. The same Samsung F700 nicely illustrates another crucial fact of the mobile world: fragmentation. When I studied the phone, I had no
clue which operating system (OS) it ran. NetFront mostly appears on proprietary Samsung (and Sony Ericsson) OSs, so it was my initial guess. Later I learned that it runs Windows Mobile (Windows Phones predecessor), ably disguised by an uninformative browser string and a rather lousy UI that doesnt resemble Windows at all. If Samsungs Windows Mobile interface resembled any other Windows Mobile interface, consumers wouldnt care what kind of phone they buy, and device vendors would become commoditized. Therefore, all device vendors that use someone elses OS prefer to customize it, whether doing so makes sense or not. This episode taught me several valuable lessons:
Never assume anything on mobile. Never. Anything. There are vastly more browsers on mobile than on desktop. Operators and device vendors are afraid of commoditization
and irrelevance and will defend themselves by inuencing the overall user experience. Sometimes this is not a good idea. Learn these lessons by heart. Youll need them. Writing a chapter on the mobile market is challenging because its one of the fastest-changing environments everfaster by far than the Web. Most of what I could write now in the summer of 2012 Thanks to Peter Beverloo, Dennis Bournique, Andreas Constantiwould be outdated by the time nou, Vitaly Friedman, Lyza Danger you read it. So, what Im going Gardner, Vasilis van Gemert, Krijn to do in this chapter is teach you some fundamentals of the mobile Hoetmer and Bruce Lawson for market, and illustrate them with reviewing this chapter or parts of it. examples from 2011 and 2012. With a bit of luck, the underlying principles will still be valid when you read this, although the examples will likely be outdated. So, here we go. Its going to be quite a journey.
11
The Mobile Value Chain

Traditionally, operators (called carriers in the US) and device vendors have formed the mobile value chain. Recently operating system vendors have entered the value chain, too. In fact, the software layer is rapidly gaining in importance, and thus software vendors such as Google and Microsoft are becoming equal partners to operators and device vendors.
FIGURE 1.1. The mobile value chain consists of operators, device vendors and OS
vendors, all of which compete for consumer attention in order to lure him into their closed silo. Currently the OS vendors succeed best at this, and operators and device vendors are falling behind.
Each link in the chain enhances the value of the others: for example, a mobile network is worthless without mobile phones, and vice versa. Parts of the mobile value chain can act against each other. Each of them has the same goal: commanding consumer mindshare and money. Each of them would love to lock the consumer into a vertical silo of its own making, where anything the consumer does
is controlled by the company and makes money for the company. (Apple is, of course, the most successful example.) At the same time, operators and device vendors fear becoming commoditized, i.e. becoming indistinguishable from their direct competitors. Later on well look at the details of this process in the operator and device vendor worlds. OS vendors have not yet entered the commoditization phase and are becoming more powerful at the time of writing; but in the end, theyll succumb, too. Especially if the Web becomes the dominant factor in mobile, why would a consumer care if theyre on Android or Windows Phone or BlackBerry? On a large scale, studying the mobile market is mainly the process of predicting which companiesand which parts of the value chain will be more successful than others in avoiding commoditization. The Nokia E-series running Symbian, aimed at business users. When BlackBerrys became a success, Nokia copied the design. Youll still nd them in many users pockets. (Image credit: RafeB,
smashed.by/symbian)
This Nokia 2730 runs the S40 feature-phone OS, customized for the Chinese market. Remember also that while Nokia is declining in smartphone sales, it remains strong in the feature phone segment.
(Image credit: (northirish), smashed.by/nokia2730)
13
Operators
The operators own and maintain the mobile networks. Until now, they were the winners of the mobile game because they make incredible amounts of money, especially on text messages, and dominate the consumer market by subsidizing devices. Although the operators still control well over half of the money that streams through the mobile value chain, they have no points of differentiation: in the end, the consumer cares very little whether theyre on Vodafone or T-Mobiles network. Besides, operator prots are falling as a result of changing consumer habits: customers are sending fewer text messages, preferring to use other IM solutions, such as BlackBerry Ping and WhatsApp. So, the operators are in trouble. I expect them to gradually become less important, as other mobile players, especially device, OS and service vendors, win consumer mindshareand the consumer money ow.
OPERATOR SUBSIDIES Subsidies are the most powerful weapon that operators have at their disposal, because the psychological mechanism behind them is so devious that nearly all consumers fall for it. Operators offer phones to consumers for a lower price than theyd nd elsewhere. If you buy a new high-end Android phone
in the operators store, youd pay only 100 or so, while the normal sales price is more like 600. Of course, the operators dont give you 500 out of their own pocket: they get it back (and actually earn more) on the two-year contract that youre obliged to sign. Although buying a smartphone for the full price and a separate contract for connectivity is cheaper in the long run, the psychological difference between 100 and 600 is so huge that most consumers dont even think about buying a phone anywhere else than in an operators store. (My sister saw through the operators cunning plan
without my having to brief her, and bought her iPhone directly from Apple. I was very proud of her. But shes an exception.) Theres something you should do every few months. Go to an operators store near you, pretend you know nothing about smartphones, and ask for advice on purchasing a phone. The store Note that operator subsidies are forclerk will efciently steer you bidden by law in certain countries; towards the type of phone that for instance, in Belgium and Italy. the operator wants you to buy. There, operators have much less Store clerks earn a slight power, and high-end smartphone commission on any phone penetration is somewhat lower. they sell, but the exact amount depends on the type of phone. This mechanism enables operators to make sure clerks steer consumers towards a certain type of phone. At the time of writing, that type is always an Android phone, and often a Samsung. Consumers are familiar with the brand, and most Android vendors are able to produce phones fairly cheaplycheaper than Apple, RIM and the Windows Phone vendors. That frees up extra money for the operators, store clerks, independent resellers and sometimes even consumers. Through this process, operators gain considerable power over device vendors. If the operators decide that they dont want to sell certain types of phones, they can simply remove them from their stores. Sometimes theyre contractually obliged to offer the phones, but in that case they place the devices at the back of their stores and slash the clerks commission, with the obvious result that nobody buys them anymore. This is whats happening to Nokia at the time of writing, and its deadly. When you visit an operators store, always note carefully which phones are in the display windows and which ones are in the back. It teaches you a lot about the operators current thinking.
15
The take-away for Web developers is that, by deciding which phones will be offered to unsuspecting consumers, operators inuence the mobile browser market, because those devices default browsers will get more market share. Thus, keeping track of operators current preferences is important.
Apple Disrupts the Model From the operators point of view, this system is ideal. However, Apple is disrupting the model to a certain extent because it controls a large part of consumer mindshare. Some consumers are in love with Apple products and want only an iPhone. They dont care about any other kind of phone. These consumers go to an operators store to buy an iPhone and dont allow the store clerk to steer them towards any other phone. This deates a lot of the operators power. Although they still make a nice chunk of money on the contracts, the operators do not decide which phones these consumers will buy. Also, Apple has an independent retail outlet in its Apple Stores. Thats not quite as important as owning consumer mindshare, because operator subsidies will still entice clients to buy a phone with a contract, but its one more way in which Apple inuences consumers without the operators having any say. Only Apple has this particular power. All other device vendors crave it, but so far they havent succeeded in capturing consumer mindshare like Apple has. At the moment, Samsung comes close, but its mindshare is to a large extent based on the fact that operators love selling Samsung Android phones. If operators switched away from Android or Samsung, the Korean giant would be in serious trouble.
IDENTITY MANAGEMENT AND PAYMENTS Operators hold two trump cards in the mobile value chain, but refuse to play them:
Operators can establish a consumers identity much more easily
than any other party. Operators can handle payments much more easily than any other party. Operators can establish your identity by reading your SIM card. Every call or data connection you establish tells the operator who you are (or, rather, which SIM card youre using, which amounts to the same in most cases). Similarly, because your operator already Granted, establishing identity will sends you a monthly bill, it not work with a prepaid SIM card. would be very easy to add When buying one, consumers may items youve purchased online choose not to divulge their identity and make the purchase run (at least, thats how it works here in through its channel. Holland). Payments will still work Even better, operator billing ne: theyre subtracted from the would be independent of credit users prepaid account. cards, which are required for all proprietary payment systems such as Apples App Store, Googles Play market and so on. More than half of the worlds population does not have a credit card, and currently theyre excluded from the payment systems. Of course, credit card holders are generally more afuent and, thus, a more interesting target audience for mobile payments, but the potential of an app sold to 3 billion people for $0.49 is immense. Ask the ringtone vendors. Recently, several operators, including Vodafone and Telefnica, have started to offer payment options, but they are restricted to their own network and are incompatible with each other. That is especially annoying to Web developers, who create apps that can run anywhere but dont have a payment system that works everywhere. If you want in-app purchasing in a Web app, you need to support Vodafones way, Telefnicas way, T-Mobiles way, AT&Ts way
17
and so on. And you have to make sure it works with Google, Facebook, Nokia, Amazon, Apple and BlackBerry, just in case. Hmm, and maybe add Microsoft and Samsung to that list. Anyway, you get the point. Telefnicas payment system is Payments will remain a probBlue Via; see smashed.by/bluevia. lem for some time to come. We Vodafone offers the OneAPI, need a solution that works on which includes payment options; more than just the creators see smashed.by/oneapi. platform, but mobile players currently have little incentive to standardize payments, especially because theyre thinking primarily about closed app stores, not about open Web apps. Operators, which already have billing relationships with just about everyone on the planet, could play a major role in creating payment standards, but at the time of writing there is no evidence that they plan to do so. Keep an eye out for solutions not only from operators and from device and OS vendors, but also from services companies such as Facebook and Amazon. If a payment system works beyond its creators platform, you know youve found a winner. And if the system also includes ways to pay without a credit card, so much the better.
Device Vendors and Hardware

Mobile networks are worthless without mobile phones. Duh. Its time to turn to device vendors and their role in the mobile market. Device vendors create the mobile hardware, and sometimes the software. Most of them try to cover the entire mobile market, from cheap to expensive, by creating several lines of phones. Obviously, the cheap phones have less powerful hardware and less functionality than the expensive ones.
FOLLOWING A PHONE
Before delving into the details, we need to understand the big picture. So, lets follow a phone from its inception until it ends up in the consumers pocket. Suppose Samsung decides to produce a new high-end smartphone. The rst item on the agenda is to gure out what kind of components it can afford for a reasonably priced phone while still making a prot. Tightly tied in with this is the selection of an OS. The most obvious choice at the time of writing is Android: its a good mature OS thats also free of royalties, and consumers and operators like it. Still, Samsung could choose another OS like bada or Tizen or maybe Windows Phone. Lets say Samsung goes for Android. That inuences the exact components it needs, as well as its marketing plan. Then the phone gets designed: the hardware, the UX and the changes to the default Android software. Also, Samsung decides which of its own apps it will include as rmware. This is roughly the time at which the phone is announced. Marketing copy is created and disseminated through the usual PR channels. Samsung hopes the pending release triggers a wave of interest, which would help it in the next phase. Then comes the trickiest part of all: negotiating with the operators. Samsung wants the operators to display the new phone prominently and do a good job of marketing it to their customers. The operators will be buying a lot of phones from Samsung to resell them to their customers, and they will want a bulk discount. Then comes the actual production process in Samsungs factories, with prototypes and nal versions. Test units are sent to strategic partners (operators, app developers, Google, maybe some browser-compatibility researchers). After a nal feedback round, the phone is shipped to the operators, as well as to independent stores. Usually this is decided country
19
by country, which is why at the start of their lifecycle, most phones are available in some countries but not in others. Most operators decide to also place their own apps on the phone, next to Samsungs and the default Android ones. Now the phones rmware is complete. Now the operators do their job by enticing consumers to buy the phone with a two-year contract. Simultaneously, Samsung starts up a marketing campaign to rmly lodge the phone in consumers awareness. The operators may do the same, depending on how well they think the phone will perform in the market. Then the consumer enters the operators store, is gently steered towards the phone by a commission-hungry clerk and eventually buys it. From inception to entrance in the market, the process takes roughly six months. That assumes an existing OS: if the OS is new and untried, the process would take rather a year because several software iterations are needed to get the OS right.
THE GLOBAL DEVICE MARKET
What kinds of devices are being sold, and how much of each type? How does that affect mobile Web development? These questions are surprisingly hard to answer. Ill provide some numbers, and their caveats, later on. Lets rst discuss the global device market qualitatively. In general, the more expensive phones are sold in richer countries, and the cheaper ones in poorer countries. Thats a generalization, though: rich elites in poor countries buy expensive smartphones for status reasons (sometimes in addition to a basic or feature phone that they actually place calls with), and middle-class people from rich countries might not feel the need for a smartphone and instead buy something cheaper. Despite these generalizations, the global device market doesnt exist. Instead, there are dozens of regional markets, and although you can aggregate the data to create global statistics, they dont tell
you anything useful about particular markets. Theres too much difference in demographics, culture and disposable income to dene general worldwide rules for the phone market.
Sales, Installed Base and Browsing Market Shares Pure sales statistics are actually not all that important to Web developers. More important is installed basethat is, the types of devices people have in their pockets right now. Its all well and good to know that sales of Nokias Symbian OS are crashing dramatically, but plenty of people still have a Symbian phone in their pockets. Sure, when they buy a new phone, theyre likely to switch to Android, but that hasnt actually happened yet. If they want to surf now, theyll re up a Symbian browser. Is your website ready for that? Even more important than installed base is browser market share. As well see in a moment, Androids sales share in Q2 2012 was about 67%, while its installed base was about 41%. Still, Android WebKits browsing market share was only about 20%. The reasons for this discrepancy are hotly debated. Do Android users genuinely browse less than iOS users? Are the sales numbers wrong? Is there an error in the detection scripts? Although this discussion is interesting in and of itself, in the end we Web developers dont care about the entire phone market, but only about that part that actually uses its devices for browsing. Later in this chapter well see that the Android WebKits browsing market share is roughly equal to Safaris, so we should pay roughly equal attention to the two browsers, despite Androids higher sales and installed base shares. Even general reports of browser market shares should be only moderately important to you. In the end, what matters is which browsers people use to visit the website of your client. Other statistics should be used only if your client doesnt have reliable statistics of their own.
21
Smartphone Sales Market Share Now, what are the actual numbers as of Q2 2012?
SMARTPHONE SALES MARKET SHARES FOR Q2 OF THREE YEARS
Vendor Country OS Q2 2012
Samsung Korea Android, bada, Windows Phone Apple Nokia US Finland iOS Windows Phone, Symbian, MeeGo HTC Taiwan Android, Windows Phone ZTE RIM Sony Huawei LG Motorola Others Phones sold (in millions)
FIGURE 1.2. In 2010, Tomi did not yet count these vendors separately. They are part of Others. Source: Tomi Ahonen Consulting: smashed.by/2012-market, smashed.by/2011-market, smashed.by/2010-market.
Q2 2011
16%
Q2 2010
5%
33%
17% 7%
19% 15%
14% 39%
6%
11%
7%
China Canada Japan China Korea US Varies -
Android BlackBerry Android Android Android Android Android, Symbian -
5% 5% 5% 5% 4% 4% 9% 153
3% 12% 5% 4% 5% 4% 5% 108
* 18% * * * 4% 11% 62
First, a caveat. These numbers are less precise than youd think. At the time of writing, Samsung is not divulging its exact sales guresjust the total number of all phones it has sold. Its up to analysts to split up this number into Android, bada, Windows Phone and proprietary OSs, and sometimes analyst houses disagree. So, rather a lot of guesswork is involved in creating these overviews. Nokia was once the undisputed The exact opposite of Nokia is smartphone front-runnerin fact, Motorola, which is strong in the the Nokia Communicator 9000, US but negligible elsewhere. It released in 1996, is considered the used to have market share in the rst smartphone. But Android rest of the world but lost it in became more popular, and Nokia 2007 when it couldnt create a decided on a dramatic change of successor to the wildly popular course by embracing Microsofts Motorola Razrand the iPhone Windows Phone. So far, the results was released. have not been overwhelming. Still, while most of the world witnessed the Nokia tragedy with awe, sadness or glee, the US remained unaffected. Americans hardly know Nokia because it never made inroads in the US market, even though it was overwhelmingly dominant everywhere else. This is a good example of the regional differences that I mentioned earlier in the chapter.
OS Sales Market Share What we Web developers need to know about more than the devicevendor split is the OS split. The browser that a visitor uses depends on the OS, after all.
23
SMARTPHONE OS SALES MARKET SHARES FOR Q2 OF THREE YEARS
OS
Developer
Google
Vendors
Q2 2012
Q2 2011
45%
Q2 2010
18%
Android
All but Apple, Nokia, and RIM
67%
iOS BlackBerry Symbian
Apple RIM Mainly Nokia
Apple RIM Nokia, some Japanese
17% 5% 3%
19% 12% 16%
14% 18% 44%
Windows Phone bada MeeGo Other Phones sold (in millions)
Microsoft
Mostly Nokia
3%
1%
Samsung Nokia Varies -
Samsung Nokia Many -
3% 1% 1% 153
5% 2% 108
6% 62
FIGURE 1.3. Source: Tomi Ahonen Consulting. Same articles as for the previous table.
Android is clearly the big winner of 2010 to 2012, with the iPhone holding on to its market share but not rising beyond one in ve, Windows Phone winning a bit, and the rest slipping. Again, these are global statistics. They dont necessarily say anything about your country. To illustrate that, here are the OS sales market shares for ve countries for June 2012:
SMARTPHONE OS SALES MARKET SHARES FOR THE US, AUSTRALIA AND THREE EUROPEAN COUNTRIES, JUNE 2012
OS
US
UK
Germany France Australia

69% 17% 1% 6% 5% 1% 1% 59% 15% 10% 4% 3% 8% 1% 57% 31%
< 0.5%
Android iOS BlackBerry Symbian Windows Phone bada Other
50% 37% 5% 1% 3%
< 0.5%
57% 26% 11% 2% 4%

< 0.5% < 0.5%
4% 5%
< 0.5%
4%
3%
FIGURE 1.4. Source: ComTech, smashed.by/android-rules.
Do you spot the differences? Androids share uctuates between 50% and 69%. Samsungs bada is nowhere to be seen, except in France, where it performs quite decently. BlackBerry holds on to the UK and France but is wiped out elsewhere. And the iPhone is doing relatively poorly in Germany and France. There is no global device market. There is only a collection of regional ones.
OS Installed Base Still, global numbers are the easiest to come by. Thats why the next table is global again. It shows the installed base of the various OSs.
25
SMARTPHONE OS INSTALLED BASE FOR Q2 OF THREE YEARS
OS
Android Symbian iOS BlackBerry bada Windows Phone Windows Mobile Others Millions of phones
Q2 2012
41% 25% 19% 10% 2% 1% 1% 2% 1,059
Q2 2011
27% 35% 16% 12% 1% 1% 2% 6% 910
Q2 2010
9% 49% 11% 14% 7% 10% 700
FIGURE 1.5. Source: Tomi Ahonen. smashed.by/2012-market, smashed.by/2011-nal-numbers.
As you see, Androids installed base is still below the 50% mark, while Symbians is still a quarter. That will change, but only gradually over the next few years.
DIFFERENTIATION AND FRAGMENTATION Take another look at the table for device vendor market share. As you see, well over half of the vendors produce Android phones. That being the case, why would consumers care whether they buy a Sony or a ZTE Android device? Device vendors want to stand out from the crowd. They want to differentiate their devices from their competitors. Differentiation is the positive way of looking at this process, while fragmentation is the negative way. The word you use depends on whether you think it is a good idea.
In general, device vendors and operators love differentiation because they want to stand out. OS vendors and developers hate fragmentation because they prefer a single system to maintain or to test their apps and websites against. As for consumers, they might benet from less fragmentation, too, but they dont really understand the issues involved and usually dont have an opinion.
Android When Google released Android back in 2009, it deliberately allowed fragmentation in order to make Android more interesting to device vendors. Not only was the OS free to use, but anyone could make changes to the system. Specically, each device vendor could change the UX layer to its hearts content, and thats exactly what they all did. HTC Sense, Samsung TouchWiz, MotoBlur and a host of other UX layers were born and added on top of Android. Device vendors could also make changes to apps, which led to differences in the browsers. The default Android WebKit came with every Android installation, but device vendors were allowed to switch a lot of ags on and off, which is the cause of the dreaded Android browser fragmentation. All this changed with Android 3. Google announced that it was going to crack down on fragmentation because that was in its own interest as well as the interest of Android developers. That was bad news for the device vendors. Back in early 2011, I tested two Android 3 tablets at the same time. I found literally no differences, except for a few home screen apps. Subsequently, I even forget who manufactured the tabletsI think it was Samsung and Motorola, but Im not sure any morejust because there was no differentiation at all. You see? Around the same time, and probably in reaction to Googles crackdown, some vendors, especially ZTE and Huawei from China, but also Amazon, started to create their own Android branches. Essentially, Google completely lost control over these branches.
27
The Nokia Lumia is the best-selling Windows Phone device, and it sports an interface that everyone agrees is unique and interesting. (Image credit:
vernieman, smashed.by/lumia)
Built by HTC, the Nexus One, Googles rst phone, would become the gold standard of Android programming until the release of its successor, the Samsung-built Nexus S.
(Image credit: johanl, smashed.by/htc)
Samsungs 2012 smash hit: the Galaxy III. Sporting the latest Android build, the Galaxy III was the default phone for anyone who didnt pick an iPhone, and Samsungs market share soared. (Image credit: Sergey Galyonkin,
smashed.by/galaxys3)
Then Google acquired Motorola, and the other Android vendors started to get nervous and cast around for alternative OSs. Google had to placate them, and one of the easiest ways to do that was by allowing differentiation once again. Besides, the growth of nonGoogle Android branches meant that Googles attempt at centralization had failed anyway. I see this as a victory for the device vendors and a defeat for Google. Device vendors got what they wanted, to the detriment of Google and developers. Basically, Google lost control of Android and wont ever regain it.
Windows Phone Compare the Android story to Windows Phone. From the outset, Microsoft was very strict in prescribing exactly what kind of hardware its OS could run on and in disallowing any change to the native UX layer. Thats great for developers, but its also one of the reasons why Windows Phone hasnt taken off. If device vendors cant differentiate themselves from their competitors, why would they use the OS? Especially when they have to pay a hefty royalty fee to Microsoft. So far, Microsoft hasnt budged: differentiating Windows phones (except by screen size) is still not allowed. It should probably relax its stand, or else Windows Phone will never amount to much. If by the time you read this Windows phones have started to become differentiated, youll know that Microsoft has lost this particular battle.
ENTERING THE DEVICE MARKET Because the mobile market is clearly the next frontier, company after company is trying to enter it by setting up production of its own mobile devices. In 2011 and 2012 we had rumours of Facebook, Intel, Dell, Lenovo and many others working on their own phones.
29
In general, all of these efforts are doomed to failure because entering the mobile market is extremely difcult. Designing and building a phone is but one of the challenges. Go through the Following a Phone section again, and imagine a company trying to go through all of these steps without any experience or connections in the mobile market. You see the problem? Even if a company managed to do it, it would cost billions and billions of up-front investment. Few companies have pockets so deep and can keep shareholders silent while making these investments. Thats why you should ignore any press release that states that company X, which so far hasnt played a part in the mobile world, will release phones on date Y. It wont. The only possibility for new entrants is to buy an existing device vendor outright, including its hardware designs, supply chain, operator relations and marketing. Even that is not certain to work, though. In fact, up until 2012, not a single party has succeeded in taking over a mobile company and its sales share as well. The next few years might see a successful acquisition, with both Nokia and (likely) RIM going up for sale. Its theoretically possible that each will be bought by a company that knows what its doing. Give the acquiring company the benet of the doubt for about a year or so, and then write them off if nothing happens.
OS Vendors and Software

Any phone, even a basic one, needs an OS that makes sure the right things happen when the user presses a button or touches the screen. (Please take a moment to recover from this stunning revelation.) Since 2008, the quality of the OSthe software layerhas become more important than the quality of the device, the hardware layer. More importantly, many of the traditional mobile powers noticed this too late and are still having trouble adjusting. Nokia and RIM spent 2010 to 2012 improving their software layer. At the
time of writing, its fairly certain that Nokia failed, while the fate of RIM still hangs in the balance.
IMPORTANT OSs Currently, the most important OSs are Android and iOS. Still, the contention that these are the only two OSs that matter is untrue. The mobile world is not like the desktop world of the 90s, when Windows
and Mac battled it out. Most mobile players have good reason to create and maintain their own OSs, and will continue to do so. It is sometimes said that Windows Phone will be the third OS because operators are looking for a competitor to Android and iOS. Its very unlikely; Windows Phone doesnt have enough differentiation. Be very critical when you encounter this idea in the wild. In my opinion, the mobile OS market will reach an equilibrium, with about four to six OSs gaining a market share of 5% or higher. Two of those will certainly be iOS and Android, but who the other two to four will be is unclear at the time of writing.
OS UPDATES
It usually takes a while before a new OS version is distributed to consumers, and this is a frequent cause of complaints from consumers and developers, who are forced to continue to work on older OSs. OS updates take so long because device vendors and operators want to make sure that their own apps work on their devices. Say you have an HTC Android phone thats sold by Vodafone. Google delivers the new Android version to HTC, which starts to test the hardware, the UX layer and its own apps. Only when they are all conrmed to work with the new OS, or when new versions have been written, does HTC distribute the Android version. This can easily take a few months. The distribution goes to Vodafone, which also has to test its apps against the new OS. This can again take a few months. Then, nally,
31
the new Android version is ready to be distributed to HTC phones on the Vodafone network. By that time, the next Android version is almost ready. The irony, of course, is that most consumers hardly use HTC or Vodafones apps. Still, the device vendor and operator each need its own point of differentiation.
SEVERAL OSs PER VENDOR There is no law that requires a device vendor to use only one OS. Nokia has a long history of producing several OSs by itself. It was the driving force behind Symbian, and its S40 feature phone OS is wholly proprietary. When it became clear that Symbian was too old, Nokia started to develop a new OS: MeeGo. In this sense, Nokias 2011 adoption of Windows Phone was a break with the past. Many Android vendors also use Windows Phone, although it seems their hearts arent entirely in it. Sales are quite disappointing at the moment, and the lack of potential for differentiation leads to the conclusion that device vendors arent too keen on Windows Phone. Samsung created its own OS in bada (meaning ocean in Korean), despite using Android and Windows Phone. Everyone assumed that Samsungs plan was to let bada grow quietly in the shadow of Android until it was good enough to replace Android entirely. At the time of writing, that plan has been cancelled, but Samsung is working on the Tizen OS, which could ll the same role. THE WEB AS AN OS In 2009, Palm astonished the world by announcing it was going to use the Web as its next platform. Native apps would be written in HTML, CSS and JavaScript, and the OS would be called webOS. The plan was great; the execution lousy. Palm didnt bother to reach out to Web developers, and the marketing was a disaster. webOS disappeared silently.
Still, the Web will likely have a future as an OS. Currently, there are two major initiatives for the Web as an OS: Firefox OS by Mozilla, and Tizen by Samsung and Intel. Firefox OS is supported by a slew of worldwide operators, while Tizen is supported mainly by Samsung. The rst thing to keep track of here is device vendors or operators that brag about using Firefox OS or Tizen. If one does, then it is expecting the OS to make a difference in the market and can be relied on to support it as much as it is able to. The second thing to keep track of is whether it reaches out to Web developers and gives away a lot of devices. A Web-based OS can be expected to garner interest among Web developers, but they will need actual devices in order to create apps. Also, remember that the Web is the weapon of choice for the losers in the mobile platform game. Platforms with a healthy ecosystem, notably iOS and Android, do not really need the Webthe struggling also-rans are the ones that are likely to bet on the Web, because they have no other choice. This doesnt mean theyre wrong: the Web remains the only way to create an app for more than one platform. It also means that none of the strongest mobile players will back the Web beyond offering a good browser.
Browsers
A modern mobile OS needs a browser, so its time to look at this area. Im not going to give you a long list of browsers and their quirks; not only is my information incomplete, but the list would get outdated very soon. If I were to write about mobile browsing today, I would sing the praises of BlackBerry WebKit and Samsung Doln for bada (not to be confused with Dolphin for Android). These two mobile browsers are excellent, but most Web developers have never heard of them. Im not sure theyre going to be relevant by the time you read this,
33
so I wont talk about them. Instead, Ill give a general overview of mobile browsing. If youre only used to the simple ve-browser ecosystem that exists on the desktop, youre in for a rough surprise in the mobile market. So far, I can identify about 30 to 35 mobile browsers, ranging from lousy to great. Not all of these browsers are equally important: in fact, about 25 of them are rather marginal. On the desktop, there are four rendering engines: Trident (IE), Gecko (Firefox), WebKit (Chrome and Safari) and Presto (Opera). There used to be many more on mobile, but its clear now that none of them can even approach the quality of the desktop ones, and one of the continuing themes of the mobile browser market is the gradual replacement of mobile rendering engines with desktop onesespecially WebKit. There are two important distinctions in the mobile browser world: proxy browsers versus full browsers, and default browsers versus downloadable ones.
PROXY BROWSERS Full browsers are browsers as we usually know them: when the user requests a page, the browser fetches the HTML, CSS, JavaScript and other assets via HTTP, and once it has everything, it renders and shows the page. All of these steps take place on the client. Proxy browsers, of which Opera Mini is by far the most important, are different. They work as follows:
1. The user requests a page. This is not a normal HTTP request, but a
special request to a proxy server over an encrypted connection. 2. This proxy server makes the normal HTTP request to the Web server that the user wants to access. It requests the HTML as well as all assets, such as CSS, JavaScript, images and what not.
3. The proxy server contains a rendering engine (Presto, in the case
of Opera Mini), which renders the page as usual. 4. The proxy server then compresses the rendered page to a highly compressed image of the website. Think of it like a PDF or an image map. It has hotspots that the user can click on, and the user can also select text. Operas version is called OBML (Opera Binary Markup Language). 5. The proxy server sends this le to the client, again over an encrypted connection. 6. The client shows the le to the user. The user can scroll and zoom and click on links.
Advantage: Cheap This process serves primarily to save the user money. Because all the client has to do is show static les, allow for clicks and generate a simple UI, its fairly light and, thus, able to run even on low-speced phones. So, users do not have to buy an expensive smartphone in order to access the Web. Besides, all the client receives is a highly compressed le, which is much lighter than raw HTML, CSS, JavaScript and image les, and it uses only a single request and 90%: See for instance response. This saves a lot of mobile smashed.by/march-madness data trafcsometimes up to 90%. under Pages transcoded. Also, this will work even on older networks, which is important to operators that dont want to spend money on upgrading. Proxy browsers serve to make the Web accessible even to low-income users who cant afford a desktop computer or a smartphone. It is not a surprise, then, that theyre especially popular in the developing world. Opera was the rst company to see this niche and has taken the lead in the proxy browsing world mainly because it was the rst to enter the market.
35
Nowadays there are many more proxy browsers. UC, the biggest browser in China, has followed the same path as Opera, as has its domestic competitor QQ. Nokia released the Ovi proxy browser to directly compete with Opera Mini on its own phones. And, as we saw in the introduction to this chapter, some operators decide that you should use a proxy browser, whether you want to or not.
Disadvantage: No Client-Side Interactivity Theres a disadvantage to proxy browsing, too: no client-side interactivity. Proxy browsers support JavaScript, but every time the user res a JavaScript event (by clicking on an AJAX link or something similar), the client sends a request back to the server for instructions. The server executes the script, fetches new assets if necessary and sends back the updated page, which, as far as the client is concerned, is a completely new page. Its important to realize that this lack of client-side interactivity is a feature, and not a bug. By giving up client-side interactivity, users save themselves a lot of money. Executing JavaScript costs users money, and some prefer not to pay the price.
DEFAULT VS. DOWNLOADABLE Every phone has a default browser, i.e. a browser thats part of the rmware and thats usually developed by the OS vendor. In addition, downloadable browsers are available for many, though not At the time of writing, iOS and all, OSs; users may download, BlackBerry do not allow the instalinstall and use them, if they so lation of other rendering engines, so choose. there are no other full browsers for The difference is in market these OSs. Installing proxy clients penetration. Generally speakis allowed, though, so Opera Mini is ing, default browsers have available for both. larger market shares than
downloadable ones, because few mobile users bother to install a different browser on their phonemost people arent even aware that its possible. Theres one exception to this rule: Opera Mini is downloaded a lot in developing countries because people want cheap Internet on their phones. Its not yet possible to update a default browser without also updating the underlying OS. Thus, iPhone users will get a new Safari when they upgrade to the next iOS version, etc. One advantage of downloadable browsers is that they can be updated independent of the underlying OS.
WEBKIT
Android is at the other end of the spectrum: an incredible number of browsers are available, because its the easiest platform to port a browser to and, thus, gures in the calculation of every aspiring browser vendor. At the time of writing, I have nine browsers on my Android phones: Androids default WebKit, Chrome, Dolphin (not to be confused with Doln), UC, QQ, Opera Mobile and Mini, Firefox, and NetFront. Except for Firefox and the two Operas, they all use WebKit.
So many mobile browsers use WebKit as their rendering engine that its more efcient to list the ones that do not:
IE Mobile uses Trident. Opera Mobile and Mini use Presto. Firefox Mobile uses Gecko. Nokia mostly uses WebKit, but occasionally Gecko (for in-
stance, in its Ovi proxy browser). Older versions of several browsers (such as BlackBerry, UC, QQ and NetFront) still use old, proprietary and, frankly, quite lousy rendering engines.
37
Still, the fact that a browser uses WebKit does not mean its the same as any other WebKit-based browser. In fact, there are considerable differences between them. Of course, basic stuff is supported in every WebKit-based browser. Features such as the :nth-child CSS selector are supported in WebKit itself, which means it works everywhere (as long as the vendor uses a modern enough WebKit version). Still, WebKit is a rendering engine, not a browser. If you hand it HTML, CSS, JavaScript and images, it will deliver a rendered page. However, it does not contain the modules necessary to request the assets or to actually show the rendered page on the phones screen. It depends on the OS for interfacing with the keyboard, mouse and touchscreen. WebKit provides support for hardware-accelerated animations but does not contain the modules that communicate with the GPU and that make sure that hardware animations actually show up on the screen. If you want modern form elds such as <input type= "date">, you must write the date interface yourself. WebKit includes Apples JavaScriptCore as the default JavaScript engine, but you may decide to switch to another, such as Googles V8. Finally, you may use a different WebKit version than the other guy. So, there is no WebKit on mobile. A lot of browsers use more or less the same rendering engine but differ a lot in their details. Thus, testing your website in all individual WebKit-based browsers is best. If it works in Safari for iOS, it will not necessarily work in BlackBerry WebKit, or Samsung Doln for bada, or Android WebKit, or Chrome, or Obigo WebKit, or Symbian WebKit, or Dolphin for Android, or MeeGo WebKit, or well, you get the point.
OPERA Opera was the rst desktop browser vendor to recognize the potential of the mobile world. It released its rst mobile browser in 2002 and pioneered the concept of a proxy browser. It was also quick to establish good relations with operators and device vendors. Back in those days there were no real browsers on mobile phones. Mobile websites used either WAP or XHTML-MP (Mobile Prole), which were dumbed-down versions of HTML deemed suitable for mobile. In addition to these formats, Opera could also handle real HTML. That appealed especially to operators, because if their customers would be able to visit real websites, theyd spend more on data plans. Opera Mini and Mobile are In addition to the Opera Mini proxy available for free, and Mini has browser, theres also Opera Mobile, become very popular in certain which exists for Android and Symcountries, including Russia and bian. Its not nearly as important as India. Consumers have discov- Mini because it doesnt have Minis ered that with proxy browsers advantages, and few people bother the Web becomes more accesto replace their default full browser sible to them, and they also ad- with another full browser. vise their friends to download Opera Mini. Opera capitalizes on this by making sure its browsers exist for as many platforms as possible. Opera Mini is available for all smartphone OSs except Windows Phone and for a lot of proprietary feature phone platforms. Operator relations are still very important to Opera today. If you look through Operas press releases, youll nd that many of them are about a partnership with operator X that will bring cheap mobile Internet to consumers in country Y. Thus, Opera wins market share, while operators entice people to use more data trafc. All of these strategies have combined to make Opera the second or third most used mobile browser in the world. Its popularity is geoBY PETER - PAUL KOCH |
39
graphically determined: it is used a lot in poorer countries, where few people can afford modern data-hungry smartphones, and is hardly used in wealthy countries with a lot of iPhones and Androids.
READING MOBILE BROWSING STATISTICS I referred above to Operas market share. As soon as you hear such a statement, wonder where the author got that data and whether they
are interpreting it correctly. The best statistics on browser market shares are the ones that come from your clients log les. Study them to nd out what kinds of phones are used to visit their website. Be aware that users of some phones might not be able to use the website and, thus, might be underrepresented. I usually look only at statistics for the home page or another important landing page and ignore the other pages. If a certain mobile browser is visiting the home page in decent numbers but is nowhere to be seen elsewhere on the website, then users of that browser are likely encountering a problem that you must solve. Finding and using general worldwide mobile browser market shares is fairly hard. What we need are the mobile browser statistics of a rst-rank website such as Google or Yahoo. Unfortunately, these companies keep their statistics a secret. Search engine vendors pay browser vendors a slight commission for every query they send, and they want to hide these vital statistics from their competitors (and from browser vendors). Thats why they do not share the browser make-up of their home page hits. So, were reduced to using analytics services that gather these statistics from their clients and share them freely. Unfortunately, Web designers have to sign up for these services and install a counter script, so the statistics will not be representative of the entire Internet.
We have the same problem with desktop browser statistics, which are gathered in exactly the same way. The choice is yours, then: either use the statistics, knowing theyre incomplete and biased, or use none at all. To me, any data is better than no data, but your mileage may vary. At the time of writing, I know of three such services, and I encourage you to compare them or even sign up your clients for one of them.)
StatCounter
Why I Prefer StatCounter Ask yourself two questions about mobile browser statistic services. Beware of services that are unclear on either of these points:
1. How does the statistics service

treat tablets? Ideally, tablets should be treated as a separate device category, neither desktop nor mobile. If they arent, then they should be counted as desktop. Tablets have more in common with desktop computers than with mobile phones.
(smashed.by/statcount) NetMarketShare (smashed.by/netms) Akamai (smashed.by/akamai) With all of these caveats, have a look at some mobile browser statistics on the following page.
2. What is the geographic spread of

the sample? If youre interested only in US data, then all three sources are ne; but if you want truly global statistics, then the only real option at the time of writing is StatCounter. Its global spread and the fact that it does not count tablets as mobile devices are the reasons why I use StatCounter, knowing full well that its data is likely not entirely correct. Id rather use the least bad source than have no data at all.
41
MOBILE BROWSER MARKET SHARES FOR Q2 OF 3 YEARS
Browser
Safari Android Opera
Q2 Q2 2012 2011
24% 22% 22% 22% 17% 22%
Q2 2010
28% 6% 26%
Remarks
For iOS For Android Mostly Opera Mini, on many OSs
Nokia*
11%
17%
15%
Symbian browser and S40 Ovi proxy browser
UC* BlackBerry NetFront
8% 5% 4%
1% 13% 3%
1% 14% 3%
Chinese proxy browser WebKit-based since OS 6 Mainly for Samsung and Sony feature phones
Doln Samsung
1% 1%
1% 1%
1%
For Samsung bada For Samsungs non-Android, non-bada phones
IE Others
1% 1%
3%
6%
For Windows Phone A lot of minor browsers
FIGURE 1.6. StatCounters detection script had an error that counted UC browsers as
Nokia browsers. This error was corrected in Q4 2011, and its the reason why UC won and Nokia lost such a large share in 2012. Source: StatCounter, smashed.by/statcount.
Dont stare yourself blind on tiny differences that are statistically meaningless. StatCounter shows both Safari and Opera (Mini) at roughly 22 to 24%, with one then the other growing slightly larger. These uctuations mean nothing: the only conclusion you can draw is that, according to StatCounter, Safari and Opera have roughly one quarter of the market each.
Trends, on the other hand, are meaningful. BlackBerrys share dropped sharply in 2012, and this no doubt is an actual trend, even though the percentages that StatCounter gives might not be exact. Finally, the mobile browser market is highly localized. Here are the Q2 2012 statistics for the US, the UK, India and Brazil:
MOBILE BROWSER MARKET SHARES FOR Q2 2012 IN FOUR COUNTRIES
Browser
Safari Android Opera Nokia UC BlackBerry NetFront Doln Samsung IE Others
US
49% 40% 2% 2%
< 0.5%
UK
43% 22% 3% 1%
< 0.5%
India
1% 5% 36% 19% 22%
< 0.5%
Brazil
9% 23% 36% 18% 1% 1% 3% 1% 1% 1% 5%
4%
< 0.5% < 0.5% < 0.5%
29%
< 0.5% < 0.5% < 0.5%
10% 3% 2%
< 0.5%
1% 2%
1% 1%
2%
FIGURE 1.7. Source: StatCounter, smashed.by/statcount.
If you cant get useful data from your clients log les, use your countrys market shares, not the global ones.
43
iOS and Android are the two most important mobile OSs. But theyre not the only ones; about 15% of the smartphones sold in 2012 use other OSs.
(Image credit: Daniel Y. Go, smashed.by/lgandroid)
The BlackBerry 9630 is one of the many models aimed at people who type a lot: business people answering mail and youth pinging each other. I hope BlackBerry will survive, but its not looking good in the end of 2012.
(Image credit: Dan_H, smashed.by/blackberry)
Iconic and game-changing, this phone needs no introduction.

(Image credit: thronx, smashed.by/iphone)
Developing Mobile Websites

Now that we have addressed the mobile market, its time for some Web development advice. Because the other chapters in this book are replete with excellent recommendations on various mobile topics, Ill address only a few general issues. The rst bit of advice is the most important: start mobile browser testing today. You likely have an iPhone or Android device; test your current project right now. Also, download Opera Mini and test in that browser, too. True, your single device is not representative of the market as a whole, but it still allows you to start working on the most serious mobile problem and its solution: the small screen and responsive Web design.
CREATING A DEVICE LAB The most signicant obstacle that beginner mobile Web developers will encounter is nding enough devices to test on. Buying devices is expensive, and you wont want to shell out thousands of dollars the very rst time you undertake a mobile project. Save at least 100 per month to buy devices. This will allow you to buy two devices per year. Thats not really a lot, but its better than nothing. The more you save per month, the better, obviously. Make sure to buy a wide range of devices. iOS and Android are the most important ones in the Western world, so youll likely start there. Once you have one of each, buy something else thats important for your market: a BlackBerry in North America and the UK, and Symbian in Europe. True, their sales are dropping like a stone, but these devices are still in quite a few pockets. Also, consider Windows Phone, although at the time of writing its big breakthrough hasnt happened (yet).
45
Make sure to buy at least one non-touchscreen device. Not all consumers want a touchscreen: heavy texters, especially, are addicted to hardware keyboards and will buy accordingly. Your A word about money: Ive noticed websites should work on these that some Web developers do not devices, too. want to spend anything on devices A second Android would and complain loudly when I mention be useful: as weve seen, that the need to buy them. I nd that OS has a lot of fragmentation. very odd. You buy a computer and Buy an Android from a differsoftware because you need them ent vendor with a different for your job, and you expect to make Android version and a different the money back from your clients. screen size. That will give you Buying devices works exactly the the greatest scope for nding same way: you invest now in order subtle incompatibilities. to serve your clients betterand If youre setting up a device make back the money youve spent lab anyway, add a few tablets: over time. an iPad, Android tablet and BlackBerry PlayBook. They will give you more screen sizes and more browsers to work with, which never hurts.
OPEN DEVICE LABS Still, if youre a freelancer who can afford two devices per year, youll initially have a lab of only three or four devices: the two professional ones, your personal one and maybe your personal tablet. Thats still not enough. Fortunately, youre very likely not the only one in your area with this problem. If you nd other developers who are building a library of their own, invite them to compare notes and swap devices. Not only will you be able to test your websites on more devices, you will also acquire useful contacts to discuss technical issues and the mobile market in general, and perhaps gain surplus clients.
In fact, open device labs are Smashing Magazine has an excelbecoming popular. Usually lent article on setting up a device founded and supported by a lab: smashed.by/open-device-lab. small local company with a The website lab-up.org is dedicated decent set of devices, these labs to making available lists of open deare open to anyone who wants vice labs around the world, and also to test mobile devices, provided links to good resources about open you reserve a slot in advance. device labs. Look there if you need In return, you can leave your one or want to found one. devices there if you dont need them for a while. Finding out whether your city has one is worth the trouble. If it doesnt, maybe you should set one up?
WORKING WITH PROXY BROWSERS Ive said it before and Ill repeat it one more time: test in Opera Mini. A proxy browser doesnt quite work like the browsers youre accustomed to, and many users will get their rst taste of the Web via a proxy browser. Having at least some experience with them is mandatory. The problem is not in the HTML or CSSthey work pretty much as youd expect because its all static anyway (except for a few dynamic CSS properties such as :focus). Its in the JavaScript that youll encounter the most serious problems, because any JavaScript execution requires a round-trip to the server. Although proxy browsers support JavaScript and, thus, JavaScript events, most of them disallow certain events. For instance, if you have an onscroll event handler, it should re whenever the user scrolls. But in a proxy browser, that would mean making a server request with every few pixels of scrolling, which would make the page completely unusable. Therefore, proxy browsers disable the scroll event.
47
As a rule of thumb, assume that only events that clearly show the users intent to load new data will work in proxy browsers. In addition, mouseover is widely supported because so many websites depend on it, and load and unload because they will be processed on the server anyway. Thus, for instance, you can expect click, The denitive guide to JavaScript in Opera Mini can be found at change, focus, submit and the smashed.by/opera-js. like to work, but mouseout, the key events, resize and scroll will not work. I advise you to keep it simple and concentrate on the click event, which always works everywhere. Add submit if youre working with forms. Thats mostly it, though.
OVERCOMING OUTDATED REFLEXES There are some reexes from traditional desktop Web development that we have to let go of. The most important ones are our distrust of browser detection and our unthinking use of JavaScript libraries.
Browser Detection, Good Traditionally, on desktop, browser detection is a no-go for Web developers. If you distinguish between IE and Chrome through their navigator.userAgent, youll face the scorn of your peers. Instead, detect the feature you want to use, and make decisions based on the result of that check. I have been preaching feature detection ever since 1998 and played my part in convincing the Web world at large of the evils of browser detection, so it took me a while to acknowledge that the situation on mobile is different. As soon as I started speaking with really knowledgeable people with years of experience in mobile, they all told me that some sort
of browser detection is a necessary evil. The more experienced a mobile Web developer is, the more they rely on server-side browser detection. For instance:
1. Suppose you need a Back functionality on your website.
Certain OSs, such as Android and BlackBerry, have a native button for that, and inserting your own button would only confuse users. 2. Some Android devices claim to support input type="date" and such, but dont actually have the native components to ll in a date. 3. BlackBerry 6s default browser supports touch events and tells you soeven if it is running on a device without a touchscreen. 4. A browser might support a lot of stuff but have such a cheap CPU that everything slows to a crawl, and the user would be better off without the advanced features. In all of these cases, feature Even Modernizr, arguably the best detection wont help you. Defeature-detection library, cannot tecting the presence of a Back detect everything (see button is impossible, and in smashed.by/github-modernizer). the other examples the feature Undetectables for a list of what it detection would return a false cant detect. If you must use one positive. If one of these cases of these features, then a browser applies to you, it might be time detector might be necessary. to start detecting browsers. Theres a whole ecosystem of device detection services, of which WURFL (smashed.by/wur) and Device Atlas (smashed.by/atlas) are the best known. Hand it the UA string of a mobile browser, and it will tell you something about its capabilities. It took me a while to shake off my desktop-formed preconceptions and to recognize that in the mobile world the art of browser
49
detection is much more evolved than on the desktop, and that it is simply necessary due to the hundreds of devices that might visit our clients websites. If you must roll your own detection script, assume that any device is of the worst kind and does not support the feature you want to use unless it appears on your white list. Create this white list yourself by adding the browser UA strings of devices that support the given feature. And yes, this is pretty tricky because youll have to test hundreds of devices in order to create a really good white list. Thats why, in general, going with established services is better.
Javascript Libraries, Bad The second outdated reex is to use a JavaScript library for absolutely everything. This is the sad result of the over-reliance on libraries that we developed in the 2006 to 2011 era, to the extent that some Web developers cant even write JavaScript anymore. Ive always had reservations about JavaScript libraries, and they were Who Killed My Battery?: reinforced by a research paper from Analyzing Mobile Browser April 2012. The researchers measured Energy Consumption, see the battery use of an Android phone smashed.by/wwwcon. while loading several websites, including Wikipedia, and experimented with redesigning one function of that website. Wikipedias accordion script, which uses jQuery, was replaced by a custom-made function, and the measured energy consumption for downloading and rendering the page fell by one third. The size of the download isnt even the issue: library vendors are well aware of that problem and have taken steps to make their les as light as possible. The problem is that the entire library has to be executed, draining the battery as feature after feature is initialized and your page might not even use most of the features.
If Web developers would just use JavaScript instead of a library for simple tasks, the mobile Web would be a much better place. Complex interfaces with a lot of script-driven interactions are another matter. With them, the judicious use of a carefully crafted JavaScript library might be warranted. On the other hand, it might not. In any case, we have to get rid of the reexive use of libraries without thinking about the mobile network and battery life.
THE MOBILE NETWORK Finally, a few notes about the mobile network. Although TCP/ IPand, thus, the Webworks ne over the mobile network, its nonetheless quite different from the networks were used to on the laptop, because it was made for different use cases.
Network Speed Instinctively, Web developers assume that a 3G connection is slower than a Wi-Fi connection. In general, thats true, but its important to realize that this general rule doesnt always hold. Sometimes a user is in a public space with Wi-Fibut its slow or unreliable Wi-Fi thats being used by many people simultaneously. In that case, the users 3G connection might actually be faster. Do not fall into the trap of assuming that a user on 3G has a slow connection speed, or that a user on Wi-Fi has a fast one. Connection type is not a proxy for connection speed. The roll-out of LTE (or 4G), which is proceeding apace in the US but is going much slower in Europe, will likely improve mobile connection speeds signicantly. Nonetheless, all caveats that we discussed will continue to apply, since LTE connections, too, may be overwhelmed by sudden demand for connections, or slow due to technical difculties. Again, connection type is not a proxy for connection speed. What we really need is a way to gure out the true connection speed. Id love to have a JavaScript property that gives a users estiBY PETER - PAUL KOCH |
51
mated average connection speed over the last ve minutes or so, so that we actually have useful data to decide whether to send highend or low-end images to the device.
Connectivity Mobile networks were set up to accommodate devices that only have to be reachable occasionallywhen a device makes or receives a call and when it sends or receives an SMS. Setting up a mobile connection takes some time, Steve Souders has done groundand if the mobile connection breaking research in this area and remains idle for a while, it is found the numbers quoted here closed down in order to save (see smashed.by/mobile-connection). battery life. Chapter 5 contains a lot more inforThis principle also goes mation about the mobile network. for websites: when the browser requests assets, it takes roughly 2 seconds to set up a mobile connection, which then closes down after 5 to 12 seconds of inactivity. Two seconds might not sound like much, but compounded with the normal latency of a mobile network and Web server, it makes for an annoying wait. This is where early Androids went horrendously wrong: they treated the mobile network as if it were a normal xed landline network and ran countless background services that requested data every few minutes or so. The error was corrected in Android 3. The worst thing you could do is send a request for a tiny bit of data, then wait for the user to do something else, and then send another request for a small bit of data. Every single time the user requests something, they have to wait, and that becomes very annoying after a while. Its much better to make an educated guess as to which bits of data the user will need, load them while your main website is loading, and then make similar guesses every time the user requests bits of data that you did not foresee.
Tablets
Finally, a brief note about tablets, which we havent really talked about yet. To me, tablets are part of the desktop market. The only reason theyre often lumped with mobile is that theyre a new category and have touchscreens and run mobile OSs (except for Windows tablets). No one will hesitate between buying a tablet or a mobile phone, but more and more consumers are wondering whether to buy a tablet instead of a laptop. Thus, tablets are competitors of desktop and laptop computers, not of mobile phones. Technically, treating tablets as part of the mobile market might make sense: Safari for iPad is the same browser as Safari for iPhone but doesnt resemble Safari for Mac much. Still, the fact that some technical aspects of tablets fall in the mobile realm (because we dene iOS, Android and BlackBerry as mobile) should not blind us to the fact that the tablet market is completely distinct from the mobile one and that the two do not interact to a meaningful degree. Tablets have much larger screens than mobile phones, so much so that non-mobile-optimized websites will usually render decently. Thats why its best to start on mobile when you study new devices, and leave tablets aside for the moment. In my opinion, theyre just not different enough from desktops in screen size.
Conclusion
Weve reached the end of our journey through the mobile world. As youve seen, its quite different than the desktop space. To summarize the most important conclusions of this chapter:
Never assume anything on mobile. Never. Anything. There are vastly more browsers on mobile than on desktop. Operators and device vendors are afraid of commoditization
and irrelevance and will defend themselves by inuencing the users overall experience. Sometimes this is not a good idea.
53
Operators could handle identity and payments much more eas-
ily than any other party but, mysteriously, dont do it. Each country is its own device market. Sales market share is less important than installed base, which is less important than browser market share. To avoid commoditization, operators and device vendors try to differentiate themselves from competitorsespecially ones that use the same OS. Entering the device market is very difcult and expensive. OS vendors are becoming more important. The Web will become an OS, but currently its a weapon in the hands of the losers. Desktop rendering engines are taking over the mobile world. Proxy browsing saves customers money at the cost of clientside interactivity. One WebKit-based browser is not the same as another WebKitbased browser. Create a device labby yourself or with other freelancers or small businesses. Use browser detection. Dont use JavaScript libraries. Good luck in nding your own way through the mobile landscape. This is Only the start of your journey.
ABOUT THE AUTHOR Peter-Paul Koch is a mobile platform strategist, consultant, and trainer in Amsterdam, the Netherlands. He specializes in HTML, CSS, JavaScript, and browser compatibility.
CHAPTER TWO
BY STEPHANIE RIEGER
THE FUTURE OF MOBILE
First mobile was the standard old cell phone. You talked into it. The second mobile era was brought to us by the iPhone. You poked at a screen. The third era will bring us a mobile that saves us from clicking on the screen. Robert Scoble1
redicting the future of technology is always hard. Seen from a distance, progress feels almost inevitable. With each passing day, products seem to get better, smaller and cheaper. The transition from one technology to the next is rarely painless (or free), but by the time technologies enter the lives of normal people, most major kinks have probably been worked out. Of course, we are not those normal people. We designers seek out technologies well before they reach the mainstream. We dream up crazy ways to use or enhance them. Sometimes we are even called on to dene them. Its therefore not surprising that we sometimes forget how long it can take for a technology to truly matter to normal people. Take the humble touchscreena technology that rst leapt into the mainstream with the release of the iPhone and is now so common that its practically become an expectation on portable devices. The iPhone was obviously not the rst device with a touchscreen, but what you might not know is that touchscreen techno-logy has in fact existed for more than 40 years.2
1. Mobile 3.0 Arrives, smashed.by/3rd-generation. 2. Wikipedia provides a good overview under smashed.by/history.
BY STEPHANIE RIEGER | 55
Those 40 years have seen a great deal of change, including the rise of the microprocessor, the invention of on-board memory, vast improvements in battery life and, of course, advancements in touch technology itself. Those 40 years also saw the release of many products whose features and capabilities were, in many ways, not all that different from the iPhonesfeatures such as the ability to install applications, to surf the real Web using a standards-based browser, to control the device or input text using touch, and even to draw or annotate content using the touchscreen. What made the iPhone more successful than many of these products was not its use of a new technology, but the brilliant, thoughtful and fun way it brought so many existing technologies together. This is what made the iPhone great and revolutionized the way we use (and think about) the humble touchscreen. The rise of the touchscreen provides a great example of how challenging predicting the future can be. While its easy to identify technologies that will reach (or have already reached) sufcient maturity to be commercialized, its far harder to predict which will grow the fastest, what new behaviors will be created, and what new and unexpected products will be spawned in return. Its also hard to predict where we might get stuck along the waydue to patent wars, not invented here syndrome and the reluctance among many companies to cannibalize their existing products by releasing something truly disruptive. In this chapter, I will provide a glimpse of where the future of mobile might lead, and what technologies may lead us there. These include new low-power computer chips, fantastic new display technologies, new APIs and the growing penetration of near eld communication (NFC). But more important than the technologies themselves is how they will need to work together, enabling new and exciting ways to do business, to connect with friends and family and to interact with the world around us.
56 | THE FUTURE OF MOBILE
Lets begin by examining key trends that have already begun to transform our lives and that will continue to shape our future. These trends all revolve around connectivity and the impact that new ways of connecting will have on peoples lives.
Trend: Everyone Will Be Connected

Fast low-cost computer chips and open software have taken the world by storm. Each and every day, millions of people purchase a smartphone.3 These devices are cheaper, faster and more versatile than they have ever been. Most are also Internet-enabled and include a modern Web browser. If current trends hold true (and there is currently nothing to indicate that they wont), we will very soon all be connected. While many of us will not have constant access to broadband or Wi-Fi, most of us will live within reach of a cellular network. We will also own devices that can connect to these networks, and we will have access to reasonable data rates. Many of our devices will be smart, but as we will discover in this chapter, the meaning of smart will likely change. The impact of all this connectivity can be hard to predict, but its sure to affect every aspect of our lives. We already live in a world where, thanks to the software on our mobile phones, getting lost is almost impossible; a world where connecting and collaborating with people across the globe is becoming increasingly cheap and easy; a world where we have the sum of all human knowledge (and cat photos) at our ngertips at any time and any place. The growth in connectivity has clearly revolutionized the way we live. We can only imagine how our lives will change once we are all connected.
3. Pinpointing the most accurate phone activation data can be difcult, so lets look at just
one platform. As of September 2012 (smashed.by/android-activation), Android alone accounted for 1.3 million activations a day, up from 1 million in July and 700,000 just a few months prior. Given that Android is just one smartphone platform, the total number of daily phone activations could easily be twice that much. BY STEPHANIE RIEGER | 57
Trend: Everything Will Be Connected

Did you know that our world already holds more connected devices than people? In fact, Cisco predicts that by 2015 there will be 15 billion connected devices on the planet. 4 If these trends hold true, our future will be populated not just by connected people, but by connected things. These devices can be loosely broken down into two categories:
connected things with screens, connected things (without screens).
Calling a group of devices connected things with screens might seem simplistic, but its not far from the truth. A screen is merely a component of a larger product. Each component has a basic unit cost. That cost is added to the bill of materials5 and ultimately passed on to the consumer. As components go, screens are pretty expensive (especially modern ones that respond to touch); so, historically, products havent included screens unless they really needed them. Recently, however, the cost of touchscreens has substantially decreased and is expected to continue doing so.6 Connectivity is also a component (or, as Smart Things author Mike Kuniavsky would say, maybe even a material). Like any other component, connectivity imposes design constraints and affects the cost of the device. In recent years, however, the components that enable connectivity have been bundled have been bundled into tiny chipssome costing as little as $0.20.7 These chips also consume
4. Evans, Dave. Ten In Ten: Ten Technology Trends That Will Change The World In Ten
Years, smashed.by/teninten. 5. Wikipedia, Bill of Materials, smashed.by/billofmaterials. 6. According to Moores law, the number of transistors on a microchip doubles every 24 months. This results either in far more capable chips or in equally capable chips that sell for a fraction of their original cost: smashed.by/mooreslaw. 7. The Guardian, Flycatcher computer chip, smashed.by/ycatcher.
very little power. This creates an interesting environmentone where its now feasible to embed connectivity into almost any product. But these products are are not computers (at least not in the traditional sense). They dont necessarily require a screen. They may not even require direct human interaction. These products (and the ecosystem in which they operate) are commonly referred to as the Internet of Things (IOT)a world inhabited by millions of autonomous connected objects. We will discover later in the chapter that todays mobile device may not yet be a part of this ecosystem, but will likely play an important role in its future success. CONNECTED THINGS WITH SCREENS We are in the early days of the connected things with screens era. We can expect a great deal of experimentation in the coming years, with more than a few products released simply because we can. This opportunistic pairing of screens with devices is already well under way in the lifestyle and home appliances sectors.
Connected TVs Connected TVs (increasingly referred to as Smart TVs) dont neatly t into the connected things with screens category, but they will likely play an important role in our future. Television habits have already changed a great deal. Thanks to smartphones and tablets, a large number of consumers already combine television viewing with Internet use. This behavior includes general multitasking, texting friends about a program and Googling products seen on TV.8 Adding connectivity to the TV will not only change how the TV is used, but will also change the role of mobile as a companion device. One of the most obvious uses of mobile is as an enhancementor
8. Watching TV while using a device is often referred to as dual-screen behavior. An Inter-
net search for this term will return the most up-to-date studies.
outright replacementof the traditional (and much hated) television remote control. Certain manufacturers already offer apps to ofoad complex interactions such as inputting URLs and credit cards to far more usable smartphone and tablet interfaces. Some of these apps also enable users to initiate streaming of content such as photos and movies from one device to the other. And because many Web browsers now include automatic tab and bookmark synchronization, sharing Web content from device to device should soon be quite straightforward as well. Manufacturers are also introducing Once controlling the TV gesture-and voice-based interacbecomes trivial and we are tions for TVs. This may prove to be able to seamlessly beam (i.e. push or pull) content from one one of those purely opportunistic feature choices that come back device to another, we might to haunt us. Adding a camera and begin to think of the TV in an entirely different way. It could audio-in capabilities makes the TV ideal for video chatting with famsimply become just another ily and friends, so why not use that screen, one that is as suitable same camera to enable gestures? for watching a lm as it is for After watching an exhaustedcompleting a tax return or looking sales person demonstrate enjoying a video call with gesture-based surng and data family.
input in a Bangkok showroom, I have a feeling that this feature will require Connected Fridges a lot more iteration before we deterConnected fridges are still far mine what its truly good for. from mainstream, but new models are appearing with shocking regularity. Some consist of no more than a screen embedded in the fridge door, the way an ice dispenser might be. Conceptually, these devices are not that different from the mini-TVs that appeared in kitchens in the early 1980s. Now, instead of simply watching TV, you can surf or send mail while you cooknot exactly
life-changing, given that you can do the same with a tablet (which can be conveniently repositioned as needed). In an attempt to make these products more useful, manufacturers have recently begun embedding fridges with apps that control refrigerator settings or provide recipes.9 The long-term goal is to turn the fridge into a virtual kitchen helper, using sensors to keep track of whats in the fridge, to suggest meals and to automatically place an order when key ingredients are running low. Connected fridges are a perfect example of a technology that could take years to nd its place. While the idea of a fridge that shops for you sounds useful, the technology wont be useful unless the items in the fridge are discoverable. An entire ecosystem will have to develop before these features are workable. In the meantime, it will be interesting to see how many consumers embrace the check your mail and watch a movie while cooking scenario. Tip: Be sure to read the section titled Control vs. Interoperability near the end of this chapter for a surprising answer to this question.
In-Car Displays Most car manufacturers are already experimenting with ways to enhance the dashboard using a collection of touchscreens.10 These screens often provide a single interface that groups functions that were previously separate, such as radio, music, navigation, trip computer and vehicle congurations such as those for interior mood lighting. In an effort to improve safety (and to meet state-and countryspecic regulations), manufacturers have also provided connection points for devices. These enable drivers to control common phone functions hands-free and also to share data such as contacts with
9. The Smart Fridge Finds the Lost Lettuce, for a Price: smashed.by/smartfrigde. 10. Wikipedia, Connected Car, smashed.by/connected-car.
the in-car navigation system. This is an interesting extension of the things with screens concept in that it enables drivers (or passengers) to bring their own device and bypass the native controls in favor of context-appropriate ones. These displays will be mobile, but not in the way we would normally expect. Location will often play a key role, but a users current location could in some cases be far less relevant than their intended destination. Regional searches could, therefore, be far more important than the 1 to 2 kilometer radius that we currently think of when designing services for local search. Another long-term consideration will be lack of connectivity. Even if cars come equipped with a SIM card for wireless network access, this service will be prone to interruption as users drive from one region to the next, pass through areas with poor connectivity, or switch from one regional provider to another. Apps that seamlessly manage and negotiate changes in bandwidth will do very well in this environment.
Consumer Customization Things that dont natively come with screens may also acquire them at a later dateeither temporarily or as a permanent improvised enhancement. A quick Google search already uncovers all manner of bracket designed to afx a smartphone or tablet to your wall, desk, or in-car dashboard. As devices get cheaper (and communication protocols are standardized), it might make more sense for a consumer (or service provider) to choose the most appropriate device for their market or price point, install context- or task-specic applications and then simply mount the device in the given environment. Devices used in this way have already begun to appear in retail and hospitality settings, where self-serve tablets are pre-xed to
tables in lieu of menus and store directories.11 Some of these simply provide information, while others enable customers to choose products and even nalize the transaction. These do-it-yourself scenarios are unpredictable, but they happen every day. They may also provide more value to users than an opportunistically-connected fridge. As a designer, its increasingly important to consider that your product will be interacted with in novel and unexpected ways. These scenarios should be embraced and directly considered when designing future products. As illustrated in the examples above, mobile devices may not always be the center of attention. In fact, they are often most useful when interacted with sporadically to enhance everyday interactions with people, places and things. This less-focused mobile behavior will only increase. The smarter the things around us become, the less we will need to spend our days staring at our beloved glowing rectangles. CONNECTED THINGS (WITHOUT SCREENS) Lets begin by clarifying the difference between connected things and the connected devices we use today. The majority of todays connected devices are, in effect, small multi-purpose computers. They have sophisticated operating systems and (thanks to third-party applications) offer a seemingly endless range of capabilities. Being connected to the Internet greatly increases their usefulness, but they are still useful in many ways when out of contact with the network. The connected things we will discuss next are not computers in the traditional sense. They are regular objects in which connectivity has been integrated as enablers to larger services. The connectivity (wireless, infrared, etc.) exists for the sole purpose of exchanging data with the cloud or an adjacent device.
11. USA Today, iPads Increasingly Crop Up on Restaurant Menus for Ordering,
smashed.by/ipad-restaurant. BY STEPHANIE RIEGER | 63
Connected things may, therefore, not have traditional (i.e. softwarebased) user interfaces. This is because interacting with data while using the object isnt necessarily the pointit may merely be a very useful side effect. To better understand the relationship these objects may have with mobile devices (and the people who use them), lets look at a few services that already incorporate connected things.
The Sonos Multi-Room Music System Sonos is a service that enables users to stream music throughout their home.
FIGURE 2.1. The various components of the Sonos system. (Image: Stephanie Rieger)
The system consists of a series of wireless speakers, a tiny control box and an optional handheld remote control. The control box connects wirelessly to your music, which is either stored locally on a computer or network-area storage (NAS) or streamed off the Internet using services such as Spotify and Internet radio. The Sonos system then streams this music to the speakers distributed throughout your home.
Sonos supports the creation of different zones, enabling you to simultaneously play different tracks in different parts of the house. Once the system is set up, the speakers and control box do all the work necessary to negotiate streaming from room to room. Purchasing the Sonos remote control is optional. Users can instead download a smartphone app that enables them to create playlists, adjust the volume and change tracks. Connectivity is an integral component of the Sonos system, but certain components in this system (the speakers, for example) are merely connected objects and communicate only with other devices. Embedding a screen in each speaker (which is likely hidden behind furniture or mounted high up on a wall) wouldnt improve the user experience at all; proxying this interaction through the overall service and then accessing it (from anywhere in the house) using a mobile device makes far more sense. The next example takes the idea of a connected object a step further. In this case, the connected object is a fairly mundane piece of plastic that weighs just a few grams, yet is the heart of an entire service that could ultimately save lives.
The GlowCap Service The GlowCap service is designed to ensure that patients properly take their medication. The service consists of a cloud component and a series of objects that periodically transmit data back to the cloud. These objects are about as far from traditional computers as you can imagine. They are simply smart-connected lids for pill bottles. Pharmacists use these lids when dispensing medication to GlowCap subscribers. Once at the users home, the lid communicates with a small control box, which in turn connects to the cloud. Each time a patient takes their medication, the GlowCap lid reports the date and time of the action. The service tracks usage, so if
the patient forgets, the lid glows and emits a sound as a reminder. If the patient still does not comply, the cap communicates with the control box once again to trigger an email to the patients doctor or designated family member. Patients and doctors can track their progress using the GlowCap website or smartphone application. Similar to Sonos, the value is in the data and the overall service. Most interaction with the service happens naturally, by simply taking the cap off the bottle. There is no screen- or software-based user interface. This keeps the cost of the lids down and is far more useful than forcing the user to interact with a tiny screen embedded in an object that could easily become FIGURE 2.2. A prescription bottle feawet or end up in the bottom of a turing the GlowCap. (Image: Vitality) purse.
Connected Things Outside the Home The previous examples have described products we use primarily at home, but we can also expect to nd an increasing range of connected objects in our city spaces, shops and recreational areas. How we will interact with these objects will vary. Similar to the in-home examples, some objects may not be designed for human interaction at all. Many will simply consist of sensors, actuators and some form of connectivity or communication capability embedded in day-to-day infrastructure, such as lamp posts, public transportation vehicles, product labels and parking spots.
Systems such as these are already being used to monitor and collect a host of infrastructure, process and environmental data in warehouses, logistics operations and major city infrastructure around the world. This data is analyzed in real time, enabling adjustment of trafc patterns on busy streets,12 letting drivers know the cost and location of the nearest parking spot,13 and sensing the temperature of a railway track to predict when a wheel is about to fail.14 These types of connected objects exist simply as part of a large, invisible system designed to improve our lives. So long as they work, we will be happy if we never see them or know they exist. But in other scenarios (such as retail or maybe transportation), discovering and seeing these objects may be the entire point. In Brazil, for example, a retailer by the name of C&A15 has developed connected clothes hangers that displayin realtimethe number of likes that a particular item of clothing has received on Facebook. Clothes hangers are pretty useful on their own, yet, thanks to connectivity (and a small LCD display), these hangers are no longer simply well-designed lumps of wood or plastic. They can now play a more active role in the retail value chain. But is a Facebook-aware clothes hanger truly useful? How could we further improve its value to retailers, as well as to consumers? Imagine for example that your smartphone could directly communicate with the hangerusing it as a proxy to interact with the Facebook service. You could then not only see the number of Likes, but also add your own without the need to open (or download) a Facebook app, and then nd that particular pair of jeans amongst millions of other products.
12. Wikipedia, Trafc Light Control and Coordination, smashed.by/trafc-control. 13. SFpark: smashed.by/sfpark. 14. Information Week, Union Pacic Delivers Internet of Things Reality Check,
smashed.by/union-pacic. 15. Mashable, Clothes Hangers Show Real-Time Facebook Likes, smashed.by/clothing-rtlikes. BY STEPHANIE RIEGER | 67
Then again, you might not care how those jeans rank on Facebook at all. You may be far more interested in their washing instructions, the materials they were made from or the manufacturers ecological footprint. You might also want to know how best to accessorize the jeans with using nearby items. Displaying this level of detail on a tiny 2-inch LCD attached to a clothes hanger would, of course, not be appropriate. Projecting it onto a single point-ofpurchase (POP) or wall-sized display would also be impractical (after all, there could be hundreds of individual clothing items in the store). The most obvious candidate to display this information might instead be the device that shoppers already happen to have with them. But using todays technologies, it could take several minutes, and many taps or swipes to locate this information on a brands website. Most shoppers are also unlikely to download an app just to look up washing instructions for a pair of jeans that they might not end up buying. Wouldnt it make far more sense for shoppers to simply ask the clothes hanger (or the smart label attached to the jeans) to provide them with this information, and then to use whatever screen they happen to be carrying to display it? But were not quite there yet. The technologies required to enable these types of interactions arent terribly complex, but for this to work, theyre all going to have to nd ways to work together. Thankfully, the bits and pieces we need to make all this happen are slowly falling into place.
Key IoT Technologies The rst thing we will need are communication and identication protocols that enable these smart (but often mundane) objects to exist on the network, to securely transmit data, and to do so using as little power as possible. The Internets TCP protocols might seem ideal, but they require far too much processing power. Standards
bodies16 such as IPSO, 6LoWPAN and ZigBee IP have, therefore, been formed to develop a whole new generation of low-power IP (Internet) protocols. As is often the case with standards, potential solutions may come from several groups and its impossible to tell which will be adopted long term. What we can only hope is that the successful standards enable simple and exible communication not just with (and between) objects, but also between the standards themselves. The second critical component will be a UI layerone that is easy to implement, widely interoperable and (ideally) non-proprietary (i.e. that doesnt require people to download an applet alone a different app for each store, brand or location they wish to interact with). A Web standards-based solution would obviously be a strong candidate, but the Web platform will need to evolve to make this possible. There are also technical barriers to overcome if we wish to use standard IP protocols as a communication channel in objects that might not contain a power supply. This brings us to the nal key component: some sort of discovery service, one that ideally combines the ability to search for objects and an unobtrusive push-style mechanism to discover objects nearby.17 Lets now turn to a few technologies that are far closer to becoming a reality, especially for the real people we mentioned at the beginning of this chapter.
16. Wikipedia, IPSO Alliance, smashed.by/ipso. 17. Scott Jenson, former Creative Director of frog design, has written an excellent series of
articles (http://jenson.org) describing the Internet of Things ecosystem, the challenges of just-in-time discovery and how such a discovery system could work. BY STEPHANIE RIEGER | 69
Future Technologies
In this section, we will explore a few additional technologies that will enable the future contexts weve discussed:
future display technologies, RFID and NFC, new Web and device APIs.
These technologies will enable three key aspects of our future environment: smaller, cheaper and more exible displays, new ways to spontaneously exchange data between devices, and new methods of communication between software and host devices. FUTURE DISPLAY TECHNOLOGIES The past 10 years have seen an explosion in computerized displays. Screens already pretty much surround us: in our pockets, on billboards in the subway, in shop windows on the street and throughout many of the rooms in our homes. The way we interact with screens is also changing: transitioning from purely indirect manipulation (using a mouse, keyboard or remote control) to a combination of touch, gesture and even voice. Were still barely getting used to this diversity, yet products are on the horizon that will further challenge how we design for and use the screens that surround us. One of the most exciting changes will likely be the commercial release of exible displays. Two technologies are likely to dominate this marketplace: exible e-paper and exible active-matrix organic light-emitting diode (AMOLED). E-paper has been around for many years18 but has nally entered the mainstream thanks to lower costs, and the success of e-Readers
18. Wikipedia, Electronic Paper, smashed.by/epaper.
such as Amazon Kindle. All e-paper devices to date have been rigid, but announcements from the likes of LG suggest that we will see the rst commercial release of exible e-paper as early as 2013. Where these screens will rst appear is anyones guess, but the magazine industry has expressed great interest in them as a means of embedding interactive content zones into existing print media. To date, all commercial implementations of e-paper have also been monochrome. Color technologies do exist, but they are still quite expensive, and color saturation tends to be far lower than on conventional displays. The PPI can also be quite lowaveraging about 110 PPI. This is where Flexible AMOLED comes in. Flexible AMOLED displays are said to provide the same power consumption, brightness, color saturation and contrast of AMOLED, while also being exible, and fully transparentenabling you to look right through the display. Pixel densities of up to 300 PPI can be achieved, yet the display is light and exible enough that it can be rolled up like a newspaper. These are exciting developments that will introduce many new contexts of use, and new interaction models. Imagine for example being able to twist or ex a display to indicate intent. This would be similar in principle to the interaction in accelerometer-enabled racing games. Tilt the device to the left and the car goes left; tilt it forward and the car speeds up. Now transpose these interactions to your favorite application on a exible e-paper device. Bend the paper towards you to scroll up a list. Bend it away from you to scroll down. The more you bend, the faster you scroll. These interactions are disruptive and will introduce many of the same challenges we are currently grappling with on touchscreens:
How will we provide appropriate affordances for these interac-
tions? How will we minimize accidental triggering? How will we support multi-modal devices, or ensure backwards compatibility. Surely, these interactions wont be practical on all devices? In which contexts will they be most appropriate? How will we accurately detect these capabilities? What properties will we even need to detect? How will these properties map to existing platforms and standards? These questions are obviously yet to be resolved and may well prove as disruptive as the recent shift away from xed layout and pixel measurements in Web design. Its also worth remembering that we may have a lot of seemingly mundane uses for exible displays. E-paper technology is already being used as a exible (i.e. bendable) display on disposable batteries. Being able to determine how much charge is left in your battery might not require sexy gestures, but it certainly is useful! Until these technologies are released, the best way to learn about them is on the Internet. This collection of videos should provide food for thought about regarding the interactions we can expect to see in coming years:
Nokia Kinetic device, a exible smartphone:
smashed.by/nokia-kinetic More videos available on Nokia Conversations: smashed.by/nokia-bendy PaperPhone, a paper computer prototype from Queens University in Canada: smashed.by/paperphone
Samsung exible-paper AMOLED prototypes:
smashed.by/samsung-exible Concept video: smashed.by/samsung-concept Plastic Logics color e-paper technologies, featured in a BBC documentary: smashed.by/plastic-logic Heads-up displays (HUD) are transparent displays that present data without requiring users to look away from their usual viewpoint. To date, HUD technology As display technologies evolve, we has primarily been used to can also expect to see new and novel overlay valuable contextual uses of small displays. A particularly data (such as air speed and interesting small-screen context will altitude) on vehicle windbe the heads-up display (HUD). shields in military and aviation settings. Thanks to improvements in display technologies, afxing tiny HUDs to a simple headpiece or pair of glasses is now also possible. Google has recently showcased an upcoming HUD product, codenamed Project Glass.19 At the time of writing, very few details have been released, but early promotional videos suggest that users will be able to record, send and receive data while wearing Googles futuristic-looking set of glasses. Whatever the nal feature set, Project Glass is sure to prompt a great deal of discussion regarding the social and personal repercussions of cheap, unobtrusive HUD technology.
Privacy
Will it be socially (or legally) acceptable for a person to wander around a city, corporate ofce, or playground surreptitiously lming or photographing everything around them?
19. For the latest details on the project, be sure to visit the Project Glass page on Google+:
smashed.by/googleglass. BY STEPHANIE RIEGER | 73
Safety
In what contexts would it be unsafe to use HUDs? Many countries (and quite a few US states) have already banned the use of handheld phones while driving (although using a phone handsfree is typically permitted). Its hard to imagine how projecting an email inches from your eyeball could be less distracting.
Usability
Little information is available regarding the way we will actually use Googles HUD. Given the size of the display, interactions will likely involve a combination of voice, the odd press of a FIGURE 2.3. A model wearing the Project Glass prototype heads-up hardware button (to turn display. (Image: Google) the device on and off), and simple gestures such as nods of the head. Will these limited (and possibly comical to watch) forms of interaction be sufcient, practical and usable in daily life? RFID AND NEAR FIELD COMMUNICATIONS (NFC) RFID is a means of exchanging information between objects or devices. If you live in a town or city, you may already use RFID daily when taking the bus or train to work. In this scenario, your bus card is an RFID transponder. It contains electronically stored information that will be read by an RFID reader each time you swipe the card when entering the bus.
RFID is also widely used in inventory and logistics to automatically track and identify items in warehouses and shipping depots. In fact, these types of implementations are far more common than in the public transportation scenario. This is because RFID tends to have high associated set-up costs. For large companies such as Amazon that must pick, pack, track and manage millions of stock items, the benets of implementing RFID-based logistics may be immediate, and easy to meaOne of the most successful rollouts sure. In public transportation of RFID-based payments is the Hong scenarios, the benets are typi- Kong Octopus Card.21 Implemented cally long-term and the impact in 1997, the system was initially deless immediately measurable. signed to eliminate the need for comThe main problem is that muters to nd exact change. Fifteen RFID requires some level of years later, Octopus is a full-edge ecosystem. Readers must be in- payment alternative, accepted as stalled on platforms and within payment at tens of thousands of cabusses or trains. Customers fs and convenience stores throughmust be notied of the new out the region. You can even use the payment type, and convinced card to pay your electricity bill. to switch from whatever old system they are used to. There may also be external partners, such as local and regional ticket vendors, that will need to be notied of the change, and trained to use the new equipment.20 This can lead to a frustrating chicken- and egg-scenario: investors and stakeholders may not understand the benets of the technology until a critical mass of usage has been reached, but without money for infrastructure there will be little usage to reach that critical mass.
20. Wikipedia, Octopus Card, smashed.by/octopus.
NFC NFC (a newer subset of RFID) seeks to remove many of the challenges of RFID while also increasing functionality and improving user experience. NFC differs from RFID in that it can be used for one- or two-way communications and has three operating modes: read/write, card emulation and P2P (peer-to-peer). Read/write mode behaves similar to RFID, but with the added benet of writing capabilities, making it easy for almost anyone to embed retrievable data into an object. A common scenario is a subway poster to which an NFC tag has been attached. The user would simply tap their phone against the poster,21 triggering the transmission of a URL or other information stored in the tag. In this scenario, write mode refers to the ability to write the data on the tag before its embedded into the poster.22 In the future, we can imagine using read/write tags to provide just-in-time information about objects in shops, retrieve location-specic data about historical monuments, or access critical point-of need specications in industrial settings. Card emulation mode transforms an NFC device such as a smartphone or tablet into a contactless smart card. This enables contactless payment and ticketing (as described in the RFID transportation payment example), but without costly changes to the existing infrastructure.23 This technology should also make it cheaper and easier to prototype payment scenarios to obtain much-needed buy-in from users and stakeholders. Finally, there is P2P mode, which allows two NFC-enabled devices to communicate, share information and exchange les. In cases where the data is smallfor example, a 2 to 3 KB vCard contact NFC can be used to exchange data during the short period of time
21. See the NFC website for more on NFC smart posters: smashed.by/smart-posters. 22. See the section below entitled Get Your Hands Dirty for examples of how to easily
prototype with writeable NFC tags. 23. NFC Forum: Frequently Asked Questions, smashed.by/nfc-faq.
that the devices are touching. For much larger data, NFC can be used to open a Wi-Fi or Bluetooth connection with the paired device. The data is then transmitted using the higher data-rate technology. There are many possible uses for P2P mode, such as quick sharing of contact information, in-store coupon delivery, initiation of two-player gaming sessions or connecting a camera and printer simply by touching one to the other. This choice of modes enables a much wider range of uses than the simple payment and tracking scenarios of RFID. Similar to RFID, however, whats still missing is an ecosystem of readers and opportunities to use them. The device that will enable widespread NFC use will probably be the smartphone. Estimates by Forrester Research suggest that NFC-enabled handsets will reach critical mass (set as 15-25%) in the UK by 2014. But NFC support is only part of the equation. To ensure widespread adoption, NFC FIGURE 2.4. A Samsung read/write NFC needs to prove that it can TecTile. (Image: Samsung Mobile) provide real value to merchants, transaction processors and customers. Until this happens, we can expect to see continued growth in proprietary (non-NFC) digital wallet or payment systems, such as those offered by Starbucks24 and Square.25 These systems are akin to the polylls that were used to on the Web: enabling valuable functionality, introducing behaviors, and creating mental models in preparation of an emerging standard.
24. Starbucks, Mobile Applications, smashed.by/starbucks. 25. Square, smashed.by/squareup.
Get Your Hands Dirty The best way to understand the true potential of a technology is to start prototyping. Prototyping an NFC user experience is becoming easier by the day with the release of products such as Samsungs TecTiles.26 TecTiles are NFC tags that can easily be programmed to perform simple tasks using a mobile phone. Tags can be easily afxed to all sorts of objects (using the sticky backing provided) and programmed to trigger a call, set an alarm, update a Facebook status and much moreall with a single tap of an NFC-enabled phone. An NFC-enabled Android device is required to use TecTiles. You will also need the free TecTiles smartphone app that will enable you to write data and program actions to the read/write tag.
NEW WEB AND DEVICE APIS The more devices can exchange data with other devices and platforms, the more useful they ultimately are. The presence (or absence) of an API is, therefore, a key indicator of how a technology may progress. Whether an API is open or proprietary may also impact its usefulness in the long term. New APIs are actively being developed to bridge the communication gap between platforms and devices. Developing APIs is a complex task. Progress is often slow, and there are many false starts. This can be discouraging, but whats important to remember is that with each new API comes a new opportunity to experiment. This experimentation leads to better understanding of the problem the API is trying to solve, which, in the end, leads to better and more useful specications.
Device APIs W3C Device APIs27 seek to facilitate deeper integration between
26. smashed.by/tectile 27. smashed.by/dap
Web applications and the capabilities of their host devices. These capabilities include access to the camera, microphone, address book, calendar, and even system information such as network connection and battery level. Device APIs arent exactly new. Similar standards were developed in the early 2000s as part of emerging (and now defunct) widget and packaged Web app frameworks such as Opera Widgets and Nokias Web Runtime.28 Mozilla has also undertaken the Launched in 2011, the Firefox development of a similar set of Mobile OS (previously named device APIs. 30 These APIs are Boot to Gecko) is a lightweight primarily destined for Mozillas mobile operating system designed Firefox Mobile OS, but they for lower-end smartphones, such might eventually be impleas those popular in many emergmented in Firefoxs standalone ing economies. Developed using mobile Web browser. open standards, Firefox Mobile OS aims to eliminate the need for apps to be built on platform-specic native APIs. The initiative is backed by leading global network operators including Deutsche29 Telekom, Etisalat, Smart, Sprint and Telefnica. The rst FMOS device is expected to be released in 2013.30 Of course, communicating with a camera or calendar will only get us so far. To enable an Internet of Things, we will also need access to sensors. Here again, the native platforms have a head start, but the upcoming Sensor API Working Group31 is working hard to dene DOM sensor events and data formats for the browser.
28. An excellent overview of this history and the progress of current Device API initiatives is
available in a slide deck (smashed.by/web11) and video (smashed.by/web11vid) from James Pearce, Head of Developer Advocacy at Facebook. 29. Mozilla Wiki, WebAPI, smashed.by/webapi. 30. The Mozilla Blog, Mozilla Gains Global Support for a Firefox Mobile OS, smashed.by/mobile-ff. 31. smashed.by/sensor-api BY STEPHANIE RIEGER | 79
These APIs aim to detect ambient temperature (in degrees Celsius), pressure (in kPa), relative humidity (as a percentage, ambient light (in Lux), ambient noise (in decibels adjusted, dBA) and proximity (in centimeters). Also of interest is a new framework called Web Intents. While Device and Sensor APIs communicate with device hardware, Web Intents32 looks to enable client-side service discovery and interapplication communication. Through Web Intents, services (i.e. apps) can register their intention (or ability) to handle an action on the users behalf. The system then listens for action requests
FIGURE 2.5. An artists rendering (from left to right) of the idle screen, inbox,
incoming call screen, gallery, contact details and browser start screen in the upcoming Firefox Mobile OS. (Image: Mozilla)
32. W3C Wiki, WebIntents, smashed.by/intents.
(based on verbs such as share, edit and view) and presents the user with the most appropriate services for that action. This should enable far more uid, seamless and personalized interactions between the user and the platform.
Sensors and the Physical World

Building an application that interfaces with your phones hardware is one thing, but how do you interface with everyday objects? Until recently, experimenting with the Internet of Things was a fairly specialized domainhome to people who could program, who understood electronics and who were happy to keep a soldering iron on the kitchen table. But as the Internet of Things moves from the domain of geeks into the mainstream, tools are nally emerging to enable almost anyone to write programs that interact with the physical world. Ninja Blocks (currently in Alpha) are small computers designed to make it easy to experiment with the Internet of Things without having to deal with electronics or programming. Whereas FIGURE 2.6. A Ninja Block. Samsungs TecTiles used NFC to em(Image: Ninja Blocks) bed data within everyday objects, Ninja Blocks monitors and captures real-world data (such as temperature or movement) using a series of plug-in sensors. This data can then serve as a trigger for actions such as taking a picture or sending an email. All of this is initiated using a Web service called Ninja Cloud. Using the Ninja Cloud interface, controlling your things is as simple as writing a recipe:
FIGURE 2.7. The Ninja Cloud Web interface. (Image: Ninja Blocks)
1. Select an event that you want to watch. Events can be physical
(detected by a sensor) or virtual, such as the arrival of a new tweet. 2. Dene a reaction for the event, such as take a picture or update my Facebook status. The beauty of Ninja Blocks is that it includes a full system: a microcomputer, sensors and an API that almost anyone can experiment with. Many of its components are also open, enabling users with more advanced skills to extend the blocks while taking advantage of the pre-built API. This creates an ideal environment for small teams of designers, developers and students of all disciplines to cheaply prototype products and interactions. Another interesting characteristic of Ninja Blocks is the way the blocks were initially prototyped. Manufacturing plastic blocks may be far cheaper than it once was, but producing products on a small scale still results in a high cost per unit. This makes it prohibitively expensive to design in an agile manner and to generate early and nal-resolution prototypes. To alleviate these challenges, the makers of Ninja Blocks chose to print the early prototype blocks just in time using a table-top 3-D
printer. This enabled them to experiment and iterate the design using materials similar to those in the nal product, but without the high cost and long lead times of a proper manufacturing process. And because Ninja Blocks has open-sourced its hardware specications, its easy to imagine other companies, students and even hobbyists taking a FIGURE 2.8. A MakerBot Replicator printer similar approach to prototyp- and collection of 3-D printed objects. (Image: MakerBot Industries) ing custom blocks of their own.
Preparing for the Future

We live in exciting, and yet often confusing times. Certain changes come quite quickly (last year, there was one Smart TV in my department storethis year there is almost nothing but). Meanwhile, other changes (the implementation of certain standards and APIs, for example) feel as if they may still take years to materialize. What we can be certain of, however, is that the future will be full of new technologieseach bringing new opportunities to innovate, delight customers and improve peoples lives. Many new products will be developed, but if history is anything to judge by, quite a few of these will fall short of their full potential. Some of the blame can be put down to poor timing (early e-paper eBook readers greatly suffered from a lack of available books), yet much of the blame may well lie with usthe people who design and develop these products. Companies have a long history of trying to own new technologies or ecosystems, often believing that if they lock each bit of a product down, consumers (or partners) will have no choice but to
come to them. We are already seeing examples of this mind-set in products such as the connected fridge. CONTROL VS. INTEROPERABILITY I recently spent time reading online comments from more than 60 owners of connected fridges. The fact that 60 such people existed was shocking enough. Connected fridges have long been the butt of jokes in the UX community. Does anyone really need to check mail on a fridge (especially with all of the tablets and other connected devices that we now own)? Yet these 60 families had spent an average of $3000 US dollars (2500) to buy one of these amazing new contraptions. Reading the comments, I half expected to nd nothing but disappointment, yet most people absolutely loved this fridge. The fridge itself was well designed. It had big storage drawers and well-thoughtout controls, but more importantly, people were actively using the built-in touchscreen to access applications. The only recurring complaint was that the connected bit of the fridge (the computer on the inside) didnt play well with anything else in their house. One user was desperate for Bluetooth connectivity (or at the very least an output jack) so she could plug in her favorite speakers to listen to music (the manufacturer had provided speakers, but she didnt like the sound of them). Another complained that there was no way to connect the fridge to a printer (turns out its hard to follow recipes when youre forced to stare at the fridge the whole time, so this owner wanted to print them out). Others complained that the customizable screensaver software wasnt accessible in a normal way (such as through a le system or cloud-based interface). It was therefore impossible to remove the pre-installed promotional screensaver photos, or to easily create collections of family photos to display on the fridge.
None of the requested features and capabilities were all that strange, yet you can somewhat understand the manufacturers reluctance to implement them. You see, this manufacturer also makes printers, speakers and other kinds of electronics equipmentproducts that would make an ideal up-sell when purchasing a fridge. Why include industry-standard protocols and components, when you can lock users in to your own little connected fridge ecosystem? Connected fridges are an entirely new category of product, so imposing lock-in early on could also guarantee a dominant position in the budding connected home market. This type of logic often makes sense on paper but doesnt map well to the world we now live in. A more exible and interoperable product will always be more useful to consumers. It can be customized to suit each persons needs, tastes, or budget, and the exibility also entices third parties to develop add-ons and accessories. Far from reducing a products appeal, the presence of a third-party ecosystem actually enhances it. Would the iPad have been nearly as popular had Apple prevented third parties from developing helpful accessories, such as waterproof cases for the beach, mounts for the car dashboard or rubberized, chewable childproof bumpers? Apple took a big risk in choosing a non-standard connector plug for its rst few generations of iOS productsa risk that paid off only because its devices were so incredibly successful. Thousands of products (including cars and hotel bathrooms) now sport an iOS plug, a plug that Apple recently announced it is discontinuing, in favor of yet another non-standard plug design. Will Apples products remain iconic enough for these manufacturers to change all their products to meet the new design? One could argue, however, that owning an iPad or connected fridge isnt critical to a persons well being. Does it really matter how interoperable it is?
In the grand scheme of things, the answer is probably No. But would you feel any differently if we were talking about an entirely different type of connected object? What about a connected diabetic sugar monitor? Or maybe an entire country full of connected railway track safety sensors? Should these products be based on open and inclusive standards, or controlled by whichever company won the initial installation contract (thus forcing taxpayers and consumers to choose between the cost of remaining with a supplier that no longer suits them, and the cost of upgrading specic hardware in order to be able to engage an entirely new supplier)? These are the types of questions we will need to answer if connected objects are to fulll their true potential and help us lead better lives. TOWARDS THE FUTURE History has taught us that new technologies need at least two things to succeeda strong ecosystem, and a handful of iconic products that demonstrate why this technology is truly useful (and wonderful), rather than simply being new. History has also taught us that, in many cases, the seeds of these future products were sown many years ago. Most of the technologies we will encounter in the decades to come are already here, just waiting to be discovered and experimented with by a whole new generation of designers and developers. Seek out these new technologies. Experiment with them where you can, and begin to think about the kinds of products and ecosystems that will enable them to shine. Remember as well that the content and services you design today may need to communicate (or at the very least co-exist) with a whole host of new and often unexpected connected things. As our connected fridge example revealed, the key to making friends with these future things will be
exibilityexibility that will enable users to decide where and how to access your product, and will enable it to adapt to rapid or widespread changes in context (you will likely experience both). My nal advice is this: dont try to predict the future. Carefully observe whats happening today, and learn about what is coming next. Think of ways to build exibility into each and every product you develop. Make the best decisions you can make based on your or your clientscircumstances, goals and constraints. And be prepared for change. Lots of work remains to be done to make all of this work, and its really just the beginning. As mobile Web designer Brad Frost often says at the end of his presentations: This is going to be fun!
TThe future is a journey, not a destination. Bruce Sterling
ABOUT THE AUTHOR Stephanie Rieger is a writer and designer with a passion for the many ways people interact with technology. With a diverse background, Stephanies expertise lies in marrying design, technology, and business goals to craft simple, elegant experiences.
Responsive Web Design

iii. Responsive Design Strategy iv. Responsive Design Patterns v. Optimization For Mobile
CHAPTER THREE
BY TRENT WALTON
RESPONSIVE DESIGN STRATEGY
am allergic to cedar pollen. Here in the Texas Hill Country, cedar trees pollenate during the winter, triggering a cedar fever blight that makes over half the population miserable, cranky and desperate to know how bad pollen levels will be each day. Some days its so bad that Ill wear a bandana or surgical mask over my face if Im going to be outside for too long. And with that, your perception of me as a rugged Texas mountain man is shattered. Alas, moving on During this season, the rst thing I do is check the weather section of my local news website to know the pollen levels for the day. Ive visited this website every winter day for three years until recently, when the news outlet launched device-specic versions of the website with a completely different information architecture and hierarchy from one device to the next. Even worse, it decided to pare down core content in the various versions from desktop to tablet to mobile. When I pulled up the website on my phone, I got a mobile version with 10 general headlines and no clear path to
BY TRENT WALTON | 91
the pollen levels, even after multiple guesses with the drill-down navigation. This update wasnt about optimization, and the overall strategy was ill-conceived. Ive not been back to the website since. Creating a new version of your website for each new device that hits the market is neither a responsible nor a sustainable practice. This is why a responsive approach has become the default for how I build for the Web. If I were advising a small community center or a mega-corporation on its Web presence, my advice would be the same: responsive Web design is the best, most sensible place to start for any project. In the case of that news outlet, it would have one version to maintain, one version to budget for and one version of consistent content for users. Thus, when new devices hit the market (like seven-inch tablets), it wouldnt have to segment its Web budget again to start from scratch on a whole new experience. At its core, responsive Web design (RWD) is dened by three key components: exible grids, exible images and media queries. In the next three chapters, we will discover that these components are just the tip of the iceberg. And with the ever-increasing number of devices ooding the market, RWD is the most effective way to address them all at once. We will always be able to enhance or optimize further through techniques such as app caching and browser detection, but RWD is denitely the best place to start. So, where should we start? How about with a confession?
From Pixels to Proportions

As much as I believed RWD was the brilliant future of our craft, every cell in my Web designer body screamed out in terror when I rst saw it in action. I wanted to cower under my desk after reading Ethan Marcottes visionary A List Apart article Responsive Web Design1 in
1. A List Apart, Responsive Web Design, smashed.by/rwd.
92 | RESPONSIVE DESIGN STRATEGY
May of 2010. Ethan had coined the term, connecting the dots from exible grids to exible images to media queries. He even built us a demo showing how they work together magically, reowing the page into any sized viewport. What wasnt so quick and easy, however, was my acceptance of this new reality. My fear was rooted in how I perceived and understood the Web. Maybe my working style was a lot like yours: my team and I would work on content and design based on the understanding of a single xed-width layout, usually designed in Photoshop. Designing in Photoshop was where we could exercise complete control, and I took solace in that. What we saw in the PSD was, for the most part, exactly what wed execute with the front-end code. In this way, pixel perfection was a point of pride for us, and the idea that what wed be designing would ex, resize and rearrange itself based on the viewports size was terrifying. How could we ensure quality? How could we retain control? But that level of control has always been a myth. We all experience this everyday as we work to accommodate varying browser support, font rendering, monitor sizes, screen color set-ups and connection speeds. Moreover, now that users are visiting from pocket-sized to television-sized screens, its time to accept that Web design is about so much more than creating desktop-friendly layouts. Ultimately, I realized that we must trade the control we thought we had in Photoshop for a new kind of controlusing exible grids, uid images and media queries to build not a page, but a network of content that can be rearranged at any screen size to best convey the message.
RESPONSIVE WEB DESIGN ISNT BOLT-ON Ive found that adapting approaches, workflows and strategies to get the most out of RWD doesnt typically happen overnight.
Unlike easy progressive enhancements for rounded corners (border-radius) and Web fonts, RWD cant be quickly added, tested and then removed from an existing website. Consider how easy it would be to open a website that you built a year ago and add border-radius to a button. RWD isnt bolt-on in the same way. Its not something that can be easily added to a nearly nished website because its exible foundation requires us to rethink the very units of measure that we build on, from pixels to proportionsthings such as ems (based on the current font size), rems (based on the root font size) and percentages. All the things weve become accustomed to designing in certain ways (such as calendars, checkout ows, tables and navigation patterns) can still exist, but they must be reconsidered to work optimally in a responsive setting. But before we get too far ahead of ourselves, lets gain a fresh perspective by briey looking at each of RWDs core components.
Flexible Grids
If theres anything Ive had to learn the hard way, its that this core component of RWDexible gridsextends beyond grid structure to type, vertical spacing, positioning and even decorative items such as border-radius and text-shadow. Establishing this exible foundation, regardless of whether you plan to add media queries, is a great way to help future-proof a website, preparing it for proportional scaling. Think about it this way: take a button with a font size of 1 em and 20 pixels of padding. Then, use a media query to increase the font size to 1.5 em at widths greater than 600 pixels. You will have to declare a larger pixel value for the padding if you want the button to grow proportionally. If you had declared 1.250 em instead of 20 pixels
FIGURE 3.1. Basic setup for two buttons.
for padding, then that proportional growth would have happened automatically with less code.2 Because I used so many pixel values on the rst responsive website that I built, I had to go through each media query and update just about every property to adjust those pixel values to suit. The style sheet just looked wrong. After establishing that exible foundation, I was able to go back and simply change the bodys font size and watch all of the em-unit-sized pieces of the website scale proportionally. This process facilitated a two-thirds reduction in code, all thanks to our dear friend, the exible foundation. Think twice about using pixel values in your CSS. Now, on to the grid itself. Ill assume youve already chosen your favorite calculator and have mastered Ethans handy-dandy formula:
2. A demo: smashed.by/grids-demo.
target context = result
If you need to nd the proportional amount for four equally sized 230-pixel columns within a 1000-pixel container, youd plug in the following:
230px 1000px = 0.23 or 23%
Great! So, well set each of the four columns at 23%. Next up, lets say we have 10-pixel margins on each side.
10px 1000px = 0.01 or 1%
Well plug in the 1% margin and watch it exall too easy. But what happens if the container (i.e. the context) is 1080 pixels?
230px 1080px = 0.21296296296296
OK, I know what youre thinking, but leave those numbers intact. Resist the urge to trim, as unsightly as they may be. If your calculator gives you 0.21296296296296, dont shorten the percentage to 21.3%. We want the truest proportional representation possible. Plus, computers are smarter at math than you are, and they know it, so dont do them any favors. Note: Aside from setting margins to separate grid columns, you could also take advantage of box-sizing: border-box. This allows for the addition of padding and border without expanding the width of the box.3 OK, grids? Flexing. Next, lets tackle images.
3. Irish, Paul. { box-sizing: border-box } FTW, smashed.by/box-sizing-ftw.
Flexible Images (and Media)

Implementing exible images is a breeze.
img { width: 100%; }
Here, images are set to ll the width of their containers. But what happens if the images actual size is much smaller than the container itself and we are worried about it becoming horribly pixelated? This is where max-width becomes incredibly useful.
img { max-width: 100%; }
With max-width, image sizes still ll the width of their containers, but they wont render larger than their actual size. In other words, a 400-pixel image will scale perfectly to ll a 300-pixel container but will not suffer a resolution blowout if it continues to scale to a 500-pixel container, stopping at 400 pixels.
PROTECTING IMAGE ASPECT RATIOS
What happens to an image whose width and height attributes are dened in the HTML when max-width: 100% is applied to them? As Bruce Lawson reminds us in his post on preserving image aspect ratio, 4 we must remember to set height: auto to ensure that images arent horrendously squeezed in only one direction at a time. That way well be able to override that static height and enable all images to ex proportionally in all directions.
4. Lawson, Bruce. Responsive Web Design: preserving images aspect ratio,
smashed.by/asp-ratio. BY TRENT WALTON | 97
EXTENDING THINGS TO MEDIA The convention is to extend this to other forms of media elements by adding to our code to cover design elements such as video and Flash objects.
img, embed, object, video { } max-width: 100%;
Great! All our bases are covered. With uid images being so easy to implement, the rest must be just as easy, right? Youd think so, but gaining uid-width video embedding isnt always as automagical as wed like. Thankfully, Dave Rupert and Chris Coyier have built a solution in the form of a jQuery plugin named FitVids.5 FitVids automates the intrinsic ratio method created by Thierry Koblentz6 to achieve fluid-width videos in a RWD. Essentially, Thierry suggests adding a magic wrapper (the parent) around the container for the media element (the child)a container that proportionally resizes itself according to the width of its parent. This means creating a box with the proper ratio (4:3, 16:9, etc.) and then making the video inside that box stretch to FIGURE 3.2. Fitvids.js let you easily embed vidt the dimensions of the eos with exible width. box. With this technique,
5. FitVids.js, smashed.by/tvids. 6. Koblentz, Thierry. Creating Intrinsic Ratios for Video, A List Apart, smashed.by/intrinsic-videos.
browsers are able to determine a videos dimensions based on the width of its containing block. With intrinsic dimensions, a new width will trigger a new calculation of height, allowing videos to resize and scale the way images do. Here is the markup:
<div class="wrapper-with-intrinsic-ratio"> <div class="element-to-stretch"></div> </div>
And here is the CSS magic:

.wrapper-with-intrinsic-ratio { position: relative; padding-top: 25px; padding-bottom: 56.25%; height: 0; } .element-to-stretch { } position: absolute; top: 0; left: 0; width: 100%; height: 100%; background: teal;
To create a box with an intrinsic ratio, all we need to do is apply top or bottom padding to a div. Whatever the width of the viewport, the teal box should keep its aspect ratio (in this case, 16:9 = 0.5625, which corresponds to 56.25%). Ordinarily, you would also need to
consider the height of the chrome and player controls (in this case, 25 pixels for the YouTube chrome).
ABOUT IMAGE OPTIMIZATION Later chapters will dig into various responsive image techniques and proposals, but be sure that the images you start with are optimized as much as possible. ImageOptim7 has become an indispens-
able part of my workow. It strips out unnecessary comments and color proles from PNG, JPG and GIF images. Smush.it8 is a similar tool, but with a Web uploader interface. Another tip is to edit the actual images themselves. Jeremy Keith recently wrote a post9 about his optimization of the 2012 dConstruct website, for which he took the speakers photos and blurred the outer edges with a photo editor. Anything that wasnt the focal point (i.e. the speakers face) was blurred. This reduced the number of jagged artifacts in the raster images, thus reducing overall le size by up to 85%. And because we tend to focus on human faces, the technique isnt really noticeable. Brilliant!
MOVING TOWARDS RESOLUTION INDEPENDENCE As easy as it was to gain uid-width images, reevaluating how were
using those images will be important. Let me pose a few problems that could arise. First, using images instead of CSS to create buttons with effects such as borders, shadows and gradients makes it harder to resize and reshape the buttons. The need for this ability increases in a responsive setting because size and layout change from one viewport to another. Embedding text in images (such as JPEGs for advertisements) is always risky, but the negative effects are compounded on uid-width
7. ImageOptim, smashed.by/imgopt. 8. Smush.it, smashed.by/smush-it. 9. Keith, Jeremy. dContruct optimisation, smashed.by/dconstruct.
pages. The font size of text embedded in an image will scale with the containers size. Without proper planning and care, the text could become illegibly small or blurry as the image resizes. With the introduction of high-pixel-density displays (such as Apples Retina), the more we can use resolution-independent techniques, the more future-proof our websites will be. Consider icons. If were using CSS sprites, we could create multiple versions of a sprite and load an actual-sized or a doublesized version to ensure crisp rendering; but creating multiple-sized assets isnt as future-proof as seeking true resolution-independence through either SVG sprites or icon fonts. Ive recently taken to using icon fonts whenever possible. Theyre the most easily scalable solution because were using only font-size instead of background-position and backgroundsize, which are necessary for sprites. We can change the color on the y (although fonts are limited to a single color), and theyll look crisp regardless of the pixel density of the display. Implementing icon fonts is relatively easy. Use a service such as Shifticons10 or Pictos11 or roll your own. Chris Coyier has a nice write-up on icon font usage12 that hes been updating regularly as best practices are hashed out. Chris maps icons to Unicode symbols and includes the aria-hidden attribute as an accessibility upgrade. Heres what an implementation might look like if we wanted to add an icon before a link to the weather section of a website:
<a href="/"><i aria-hidden="true" data-icon="☁"></ i><span class="screen-reader-text">Weather</span></a>
10. Shifticons, smashed.by/shifticons. 11. Pictos, smashed.by/pictos. 12. Coyier, Chris. HTML for Icon Font Usage, smashed.by/font-usage.
And the CSS would be this:

@font-face { font-family: 'Icon-Font-Name'; src: url('icon-font.eot'); src: local(''), url('icon-font.woff') format('woff'), url('icon-fontweb.ttf') format('truetype'), url('icon-font.svg#webfontIyfZbseF') format('svg'); } [data-icon]:before { font-family: 'Icon-Font-Name'; content: attr(data-icon); }
One other icon font service Im giddy about is Symbolset.13 In addition to using Unicode and CSS classes, Symbolset also lets designers apply icons to plain-text keywords, replacing them with matching icons. For example, one could replace the word cart with an actual shopping cart icon. This method is particularly helpful when an icon will appear without accompanying text, which is fairly common on responsive websites that constrict to a narrow layout and on which space is at a premium.
Media Queries
Sooner or later, uid-layout break columns will become too cramped, navigation items will wrap in an unsightly manner, and paragraphs will become difcult to read. We can use media queries to repair broken layouts by having them target device or browser
13. Symbolset, smashed.by/symset.
properties. Media queries have two parts: the media type and the query. Lets look at an example.
@media screen and (min-width: 1000px) { body { font-size: 125%; } }
The screen type is the one we are most familiar with. But we could also target other output media, such as print, projection and tv. Their support is very limited (so far), but keep them in mind nevertheless. For a complete current list, refer to the W3Cs CSS2.1 specication.14 The min-width is the query itself. Width- and height-based queries are common, as are device-width and device-height. For a complete current list of queries and information on whether they support minimum and maximum values, refer to the W3Cs media queries specication.15 With media queries, not only are we able to repair layouts when they break at a given view, but we can harness their power to ensure ideal experiences across the ever-increasing array of device types and screen sizes. Take a basic two-column layout. When the exible grid scales down to a narrower viewlets say 600 pixels widethe columns would get too cramped. We could use media queries to stack the columns on top of each other.16
14. CSS 2.1: Media Types, Recognized media types, smashed.by/media-types. 15. CSS3: Media Queries, smashed.by/media-queries. 16. Demo: smashed.by/stack-demo.
FIGURE 3.3. Maintaining an ideal experience for users on small devices.
HTML:
<div id="container"> <div class="row"> <div class="col one"> <p>Nullam quis risus eget urna mollis ornare vel eu leo. Donec id elit non mi porta gravida at eget metus. Curabitur blandit tempus porttitor. </p> </div> <div class="col two"> <p>ullam quis risus eget urna mollis ornare vel
eu leo. Donec id elit non mi porta gravida at eget metus. Curabitur blandit tempus porttitor. </p> </div> </div> </div>
CSS:
.col { float: left; margin: 2%; width: 46%; } @media screen and (max-width: 600px) { .col { float: none; margin: 0; width: 100%; } }
Success! With this example, weve altered the architecture of the page, maintaining an ideal experience for users on small devices and narrow viewports.
ESTABLISHING BREAKPOINTS Most importantly, set media query breakpoints based on the content and not any particular devices screen size. While 480 and 768 pixel breakpoints are common today, they arent universal, and they become less and less ubiquitous with each new tablet or smartphone that hits the market. Simply add a breakpoint when
the layout breaks. Use media queries to prevent navigation items from wrapping awkwardly, columns from cramping and text from becoming difcult to read at any given viewport size. With all of these possibilities and problems to solve, managing media queries can quickly become unwieldy. Because of this, I try to consolidate media queries around a few key breakpoints. For example, If I realize that I added breakpoints to accommodate content at 650 pixels and again at 670 pixels, then I might seek to unify those changes under just one. Sure, we ought to be willing to extend things beyond that, but consolidating will help everyonefrom copywriters to designers to developersto maintain and communicate about the website. As you can imagine, the more media queries and breakpoints you add, the more difcult keeping track of them will be. Even when a exible foundation is rmly in place, the CSS code can pile up. While there are innite ways to wrangle things, below are a few that have worked for me.
Top Down Regardless of what view I design rst, I always structure my CSS for mobile rst by coding for the narrowest view rst, and then adding in min-width media queries to build towards a full-width desktop view. For this, the simplest method, everything should live on one style sheet. Another benet to ordering things in this way is that it reinforces a mobile-rst strategy any time the website undergoes maintenance or gets a new feature. This limitation of space can serve as an editor of sorts, continually honing a websites objectives and message. Module-Based Organization For large websites, having everything in one le can make it difcult to navigate the code as well as to keep your head wrapped
around which media queries affect the layout at which times. In situations such as these, Ill rst establish CSS for the basic layout and typography. Then, Ill import style sheets for each part of the page that I plan to modularize. For example, a news website could have sheets like headlines.css, weather.css, newsfeed.css,
menu.css and ads.css.
Breakpoint-Based Organization Another option is to import style sheets for each key breakpoint. This can help designers mentally separate key shifts in the layout that occur at various screen sizes. It would look something like style. css, 540.css, 720.css, 1000.css and so on. I prefer starting with (and importing) narrow one-column views as the base and building up from there. Of course, when a website goes into production, its not uncommon for all of the les to be merged into one and minied. Media Query Splitting Another approach, outlined by Simurai,17 is to set some breakpoints 1 pixel apart and to split the styles instead of overriding from one media query to the next. This would alleviate the need to reset something like box-shadow: 0 1px 3px #333 to box-shadow: none when one is set in an alternate media query. To my mind, this technique is probably most useful in conjunction with a mobile-rst, minimumwidth approach, but it would surely ease some of the mental strain from tracking media queries during development.
There is an innite number of ways to go about organizing media queries, so dont feel like you need to lock into a single one. To complement a good system of organization, there are some useful tools to keep track of which media queries are triggered and when:
17. Media Query splitting, smashed.by/mq-splitting.
Responsive.is (smashed.by/inbrowser)
Resizes a website in-browser to typical preset device sizes and orientations. Responsivepx (smashed.by/respx) Remy Sharps tool helps you pinpoint pixel values for when a responsive layout breaks. Aptus (smashed.by/aptus) A Mac app that acts as a dedicated browser for testing a website at any size. My favorite part is that it stores custom breakpoints so that you can quickly preview and diagnose layout issues in one click. VERTICAL MEDIA QUERIES If youre like me, most of your media query attention centers on width. But what can be done with height-based media queries? Ive recently found a few uses. One of my favorite things to do with media queries is to increase the font size in larger views. One problem Id run into, however, was that I didnt want short but wide screens to trigger the largest of font sizes, because then everything would just look awkward. I used a min-height media query to solve that:
@media screen and (min-width: 1000px) body { font-size: 137.5%; } } and (min-height: 700px) {
With this, only views wider than 1000 pixels and taller than 700 pixels would get the extra-large type. Another helpful use of this Ive found is to manage the fold. Im not trying to incite a debate on
whether or not the fold exists, but lets suppose youd like to ensure that certain important pieces of content are visible upon initial loading without any scrolling. You could use vertical media queries to reduce vertical padding or margins or even to crop images on thepage.
RELATIVE UNITS FOR MEDIA QUERIES Up to this point, weve been using pixel values for our media queries. I do this regularly when building out a website, but recently Ive been completing the pixel-value purge and using em units for media queries as well. As Lyza Gardner of Cloud Four points out,18 this can help facilitate proportional scaling, which is especially handy when users zoom in the browser. To do this, wed simply calculate the em-unit value based on the baseline body font size, which is 100% or 1 em. Suppose we start from a baseline of 16 pixels, and we have the media query @media all and (min-width: 400px) in our CSS. To calculate the appropriate em values, we would just calculate 400 pixels 16 pixels = 25, resulting in @media all and (min-width: 25em). The difference is that if users zoom in (i.e. make the text larger in their browser), then they would no longer be using the 16 pixels baseline that we used for pixel-based media queries. With the em-based media query, were better equipped for the whatever baseline they dene in their browser. My favorite tool for quick calculations is PXtoEM.19
MEDIA QUERY SUPPORT Browser support for media queries is great until you get to IE 8 and below. But never fear. Weve got a few options for handling this, which I choose from depending on a projects scope and requirements.
18. Gardner, Lyza. The EMs have it: Proportional Media Queries FTW!, Cloud Four,
smashed.by/queries-ftw. 19. PXtoEM, smashed.by/pxtoem. BY TRENT WALTON | 109
Scott Jehls Respond.js20 was built as part of the Filament Groups work for the Boston Globe. The group has kindly placed it on GitHub as a polyll for min-width and max-width media queries. Another option is to structure CSS mobile rst, using min-width media queries to re-architect the layout from single-column narrow views up to the full-width desktop. IE 6 through 8 will get that mobile single-column narrow view, but with your amazing design chops, Im sure thats nothing to frown about. A third option is to build xed-width layouts for older browsers, with targeted LT (i.e. less than) IE 9 style sheets that mimic the layout at full width (or some arbitrary container width, such as 960 pixels). I like this option because it helps separate the layouts for older browsers from all of the progressive enhancement we do for the main version. Because so many of the newer CSS properties we enjoy are supported only by browsers that also support media queries, we can push things further with the main style sheet.
Getting to Work
Weve broken down each of the three core responsive components and looked at tips for each of them. Now that the dots have been connected, lets dive into examining how teams can begin to work together to build their next website responsively. DECOMPARTMENTALIZE THE WORKFLOW In the production model that I was used to, a project was passed down the assembly line from content to design to development to launch. While it might not have been the best approach, it worked because each step was a prerequisite for the next. The content would be set; the designers would lay things out; and then the developers would code according to the image mockups.
20. Respond.js, smashed.by/github-respond.
With RWD, were designing that aforementioned network of content, rather than a page, so I now favor an approach with rapid iteration and a lot of show and tell. This requires all team members to work even harder to foster healthy collaborative relationships. If youre a designer but dont yet know how to code, Id recommend learning how to use basic browser development tools, such as WebKits Web inspector. Requesting bumps in pixel values in the margin or padding will mean less to those who code in percentages and em units. If youre a developer working with designers, make sure they get easy access to view the website while in production. With RWD, screenshots wont fully convey the progress thats been made or make it easy for collaborators to understand where things need to be improved. RWD will further blur the line between the Web designer and developers roles, so be willing to expand your skill set by taking advantage of these collaborative working situations.
BUILDING THAT NETWORK OF CONTENT Now that your workow is in order and everybody loves each other, whats next? One of the biggest challenges for a team new to RWD (and were all new) is discussing the content and hierarchy for a layout that has become a moving target. Its easy to revert to thinking about content arrayed across a full-width desktop view and to forget that space will come at a premium in alternate views. Because of this, I like to start with low-delity mockups. These could be paper sketches, gray-box wireframes, anything you want. The trick is to keep them simple, because at this point its less about how things look and more about providing visuals to generate a discussion about how content should t in the space at any given width and how to maintain the hierarchy.
Theres no time like the present to abandon static ways of thinking about how layout and content interact. Test ideas by quickly sketching alternate views, trying to poke holes in the plan. After all, what might seem like a great idea for a full-width layout might not make sense at narrower views. This will also help the team pinpoint where the layout might run out of space sooner than later. Perhaps the content needs to be edited down. Maybe the game plan needs to be rethought. This is one of my favorite parts of the process. Its laid back and collaborative, so invention is bound to happen.
DESIGNING RESPONSIVELY
Once the team has all of its best guesses for Plan A down on paper, its time to start designing. Similar to the hierarchy sketching stage, picking any view and designing it is OK. I like to start with the full-width desktop view and then, before getting too far, gather the team for a review. As mentioned earlier, I still favor a mobile-rst approach from a content and coding perspective; Ive just found that my team likes to start at full size during the design phase. If we nd that were designing ourselves into a responsive corner, well quickly sketch out how things could shift and reow at various widths. Its also not uncommon for coding to begin at this point. If theres something were unsure well be able to develop, then we take to websites such as JS Bin21 and CodePen22 to experiment with potential solutions. For some designers, Photoshop may not be necessary for anything other than asset creation (logos, textures, etc.). Designing in the browser is both a viable and a smart option, especially in a responsive scenario. Ive recently noticed that we rarely wait until Photoshop comps are completed before getting into the code. Because any one comp can capture only a sliver of the vast array of
21. JS Bin, smashed.by/jsbin. 22. CodePen, smashed.by/code-pen.
what users will experience at various screen sizes, the only true way to evaluate a responsive design is in the browser. Because of that, Samantha Warren has created Style Tiles,23 which can help teams collaborate on a design without committing to a series of fully eshed out Photoshop mockups.
FIGURE 3.5. Style Tiles, a new design process for responsive websites,
smashed.by/style-tiles.
Any time I have presented a handful of breakpoint-based comps for a page, I nd myself elding a series of What if questions that wouldnt have been asked had the design been presented in the browser. Style Tiles could be used to get approval on core design elements, before the process of developing a fully formed layout begins. Those elements can then inform the process once approval has been gained. This is why gradually transitioning the team to a more browsercentric workow can pay off in the long run. Full disclosure: I still like my Photoshop comps for quick ideas and brainstorming because I nd myself in such a different mental mode in an image editor than in a code editor. However, once ideas take shape, I transition to code
23. Style Tiles, smashed.by/style-tiles.
as soon as possible to really kick the tires. I also nd that saving all of the precise nudging and typesetting for code makes the most sense. After all, youre not gaining any ground by perfecting a JPG layout when its going to wind up in code anyway. Save all the blood, sweat and tears for the browser.
Tending to the Network

As we further develop the HTML and CSS for our responsive project, a few things can be done to help preserve the hierarchy and keep this painstakingly developed network of content intact.
FIGURE 3.6. An introduction to content choreography on Trent Waltons
blog: smashed.by/cont-chor.
CONTENT CHOREOGRAPHY Earlier, we used media queries to re-stack elements on the page when columns became cramped in narrow views. Taking things further, we shouldnt just consider the space available; we must also consider the content. Imagine a four-column website at full width: as the view narrows, four will become three, then two, then one. A common solution is to stack them on top of each other in chunks.
Now, theres a good chance this rearrangement is consistent with the content hierarchy on the page, but what happens if the rst column is really tall? Is the content in column two less important than all of the content in column one? In some cases it might be nice to interdigitate content by folding elements into each other as the viewport narrows. On the next page are a few techniques we can use to better choreograph how content ows from one view to the next. No, these arent names for 1950s dance moves; theyre just horribly coined terms from yours truly. Hey, what do you want from me? Imagine this for that local news outlets website I referred to at the beginning, with the forecast (including pollen levels) in the top right. In a narrower view, well want the forecast to be directly below the headline graphic, instead of being shuffled down to the bottom of the first column.
FIGURE 3.7. Often elements are stacked
on top of each other in smaller views.
FIGURE 3.8. Sometimes it might be more
useful to interdigitate content by folding elements into each other as the viewport narrows.
FIGURE 3.9. For example, the weather
section could be placed under the main headlines rathen than pushed to the bottom of the page.
The Bunch and Slide One way to handle this is by grouping columns in the markup in a particular way. We could create a row for content that we want to bunch together (in this case, the headlines and local weather). Then, before continuing with the rest of the content, wed simply close the row and start with yet another container row for the rest of the content down the page.24
FIGURE 3.10. In this case headlines and weather are bunched together in
one row, while the news container lls out the rest of the page.
24. Demo: smashed.by/bunch-slide.
<div id="container">
<div class="row"> <div class="headlines col"> <p>Insert headline code here.</p> </div> <div class="weather col"> <p>Insert local weather here.</p> </div> </div> <div class="row"> <div class="news col"> <p>Insert additional news stories here.</p> </div> </div> </div>
And the CSS:

.col { float: left; display: inline; } .headlines { width: 70%; } .weather { width: 30%; } .news { width: 70%; }
@media screen and (max-width: 33.750em) { .headlines { width: 100%; } .weather { width: 100%; } .news { width: 100%; } }
The Slide and Float Another option is to use media queries to manage oats. What if our objective were to place local weather above the headline graphic in one-column views because some twerp kept lling out a feedback form complaining about not being able to nd pollen levels? First, wed reorder the HTML to reect our new change in hierarchy.25
<div id="container">
<div class="row">
FIGURE 3.11. We could place the weather
section above the headlines as well.
<div class="weather col"> <p>Insert local weather here.</p>
25. Demo: smashed.by/hierarchy.
</div> <div class="headlines col"> <p>Insert headline code here.</p> </div> </div> <div class="row"> <div class="news col"> <p>Insert additional news stories here.</p> </div> </div> </div>
Then, the CSS could look something like this:

.col { float: left; display: inline; } .headlines { width: 70%; } .weather { width: 30%; float: right; } .news { width: 70%; }
@media screen and (max-width: 33.750em) { } } } .news { width: 100%; } .weather { width: 100%; .headlines { width: 100%;
Voil! For any width greater than 540 pixels (33.750 em), the weather would be oated to the right side of the page, adjacent to the headlines.
The Squishy Flexbox Whereas our rst two dance moves techniques allow for minimal content choreography, the sky is the limit with the exible box layout. Lets revisit the initial markup:26
FIGURE 3.12. In this case headlines and weather are bunched together in one row,
while the news container lls out the rest of the page.
26. Demo: smashed.by/squishy-x.
<div id="container"> <div class="headlines col"> <p>Headlines</p> </div> <div class="weather col"> <p>Weather</p> </div> <div class="news col"> <p>News</p> </div> </div>
Then, in the CSS, we could try this:

container { display: -webkit-flex; display: flex; } .col { flex: 1; } .headlines { order: 1; } .weather { order: 2; } .news { order: 3; }
@media screen and (max-width: 33.750em) { #container { flex-flow: column wrap; } .headlines { order: 2; } .weather { order: 1; } .news { order: 3; } }
You can rearrange the stacking order of elements on the page by changing the order.27
RESPONSIVE IMAGE HIERARCHY Another important aspect of maintaining hierarchy is physical space. Simply put, the larger something is on the page, the more important we perceive it to be. Lets take this page as an example:
FIGURE 3.13. A layout with a large and 3
column images on wide views.
27. The exbox specication is still being rened and has recently undergone a massive
overhaul, so implement with care. To learn more, check out the specication at: smashed.by/exbox. Also, Chris Coyier has a rather nice side-by-side demo comparing the old and new specication: smashed.by/new-exbox. 122 | RESPONSIVE DESIGN STRATEGY
Obviously, the large panoramic banner is important. Its higher up on the page and larger than the three images below. With uid images, what will happen to this layout as it is displayed at narrower views? Perhaps the layout displayed on the right? No way! What happened to our visual hierarchy here? That banner graphic was the largest thing on the page, appropriately sized to suit the importance of the content relative to the rest of the page. In this narrower view, things are out of FIGURE 3.14. A whack and all we see is a tiny strip of image, much layout with a large smaller than the rest of the images on the page. and 3 column images on narrow What can be done to resolve this? Once again views. with the exible media save is my coworker Dave Rupert.28 We can wrap the panoramic element in a div. Lets call it .banner-item.29 Then, well use min-height, height and overflow: hidden to keep things proportional. Heres what the code could look like:
.banner-item { overflow: hidden; min-height: 300px; /* 300px is arbitrary. */ } .banner-item img { width: 100%; } /* 600px / 37.500em is about the width "locked in" at */ @media screen and (max-width: 37.500em) { .banner-item img {
28. Rupert, Dave. Responsive Image Hierarchy, smashed.by/image-hierarchy. 29. Demo: smashed.by/exmedia.
FIGURE 3.15. A technique that wraps the panoramic element in a div and uses min-height, height and overflow: hidden to keep things proportional.
width: auto; max-width: none; height: 300px; } }
With this media query, weve stopped the reduction in height at 300 pixels, maintaining proportional hierarchy. Now that weve explored so many ways to approach exible grids and layouts, lets look at how this affects text and readability.
FLUID TYPOGRAPHY
Amidst all of this, we want to ensure readability across all devices and widths. A key part of this is managing characters per line. In a uid layout, browser width and typographic measure are linked: the wider the viewport, the more characters per line. The Elements of Typographic Style Applied to the Web30 tells us that 45 to 75 characters per line (including spaces) is generally accepted as safe for comfortable reading. Bearing that in mind, we can do a few things to avoid extra-long lines of text in uid layouts. First, we could use media queries to adjust the width of the container. As the viewport gets wider, we could decrease the containers width to give lines of text less distance to span across. Secondly, we could increase the font size in wider views. A trick I like is to place two asterisks in some placeholder text:
Lorem ipsum dolor sit amet, consectetur adip*isicing elit, sed do eiusmod *tempor incididunt ut labore et dolore magna aliqua.
As I widen the browser window, if at any point the two asterisks appear on the same line of text, then I know its time to increase the font size. These adjustments are easy (usually one CSS property) because Ive used percentage, em and rem (rather than pixel) units in the CSS.31 To my delight, Josh Brewer and Mark Christian released a jQuery plugin named Responsive Measure,32 which helps to automate this by generating the font size needed to produce the ideal measure for text at a given width.
30. The Elements of Typographic Style Applied to the Web, Choose a comfortable measure, smashed.by/comf-measure. 31. This technique is a small part of a post I wrote titled Fluid Type: smashed.by/uid-type. 32. Responsive Measure, smashed.by/resp-measure.
This is great for paragraph text, but what if we want the text to behave more like a uid image, scaling based on the width of the browser window, for more intensely typeset headlines? I had this problem on my own blog, and, fortunately for me, Im friends with Dave Rupert. He built a jQuery plugin, FitText, to inate Web type, and we released it on GitHub.33 Sean McBride has a great example of FitText in use.34 There, Sean has applied FitText to an h1 heading whose width he has governed via padding: 5em 40% 2.5em 5%. The 40% padding on the right leaves room for the focal point of the photograph. The text scales to ll the width of the container with the addition of the following script in the head:
FIGURE 3.16. Increasing font size is easy because percentage, em and rem
units have been used here.
<script> $(function() { $(' .heading h1').fitText(5.7) }); </script>
33. FitText, smashed.by/ttext. 34. Demo: FitText, smashed.by/ttext-demo.
Actually, if you like FitText, then youll love Molten Leading.35 Dreamed up by Tim Brown and built by Mat Marquis, Molten Leading automatically adjusts line height to a minimum and maximum range within a minimum and maximum pixel value width range. In other words, it gives us a uid way to set line height. Even better news is that, one day, things like FitText could be made obsolete by vw, vh and vmin units of measure. Its pretty simple:
1 vw is 1% of the viewports width; 1 vh is 1% of the viewports height; vmin is 1 vw or vh, whichever is smaller.
Instead of using JavaScript and the percentage-based widths that FitText requires, these units would do the job all on their own. These units could also be used to more precisely govern typographic measure across all viewport widths once they gain more browser support.
CODE-BASED WEB DESIGN STANDARDS As basic design elements such as typography, buttons, navigation and general page structure become nalized, its worth considering building a page or an asset library website. This would help get things ready for production, but it could also help establish visual standards and assets for a project.36 In my mind, I picture this as a light version of the fantastically comprehensive Twitter Bootstrap,37 but unique to your project. Having design examples in a live code setting is the most accurate way to test and continually improve a website. The way I see it, using images to show a responsive layout is like test driving a car thats stuck in park.
35. Molten Leading, smashed.by/molten-leading. 36. You can review some examples of front-end style guides in a Gimme Bar collection:
smashed.by/frontendguides. 37. Twitter Bootstrap, smashed.by/tw-bootstrap. BY TRENT WALTON | 127
Onward!
Responsive Web design has restored my sense of wonder for our craft. Weve reached a new frontier, and the uncharted territory ahead is gnarly. With a spirit of bold adventure, lets press on. How will online banking, extensive drill-down menus and content management systems look in a responsive setting? Brad Frost, the responsive Webs faithful docent, will take over in the next chapter, helping us to begin answering some of these questions.
ABOUT THE AUTHOR

Trent Walton is one of the founders of paravelinc.com, a small Web shop based out of the Texas Hill Country, where the chicken fried steaks are as big as your face. Together with Dave Rupert and Reagan Ray he is designing and building for the Web since 2002. The most important lesson he has learned in his career is that there is no substitute for being in control of your own destiny.
CHAPTER FOUR
BY BRAD FROST
RESPONSIVE DESIGN PATTERNS
s responsive design continues to evolve, were confronted with difcult problems about how to create adaptive interfaces that look and function beautifully across many screen sizes and environments. How do we handle navigation thats four levels deep? What about tables with a ton of columns? How do we deal with carousels? The exciting news is that the community is discovering ways to create responsive layouts, adapt existing design conventions to a multi-screen world, and generate entirely new interaction methods. Its a great and challenging time to be a Web designer as we dive head rst into this multi-device future.
Modularity and Patterns and Style Guides, Oh My! Its literally impossible to articulate in Photoshop all of the different design outcomes that arise from different device environments, screen sizes and user settings and a host of other variables. So, as Trent mentioned in the last chapter, we must address this by moving away from designing Web pages and toward designing systems.
BY BRAD FROST
129
Just as all matter consists of small molecules, which consist of even smaller atoms, Web interfaces are made up of many small components. This means we can break the entire design system down into more modular, more manageable chunks. In doing so, we dene the elements of our interfaces, gure out how each element works in a responsive environment, and then build the nal system by assembling these units. This type of atomic thinking is certainly different than the way a lot of us are used to crafting Web experiences. Thats where frontend style guides can be a tremendous help. A front-end style guide is a collection of your projects interface components. In her article Front-End Style Guides,1 Anna Debenham explains the many benets of a front-end style guide: it makes testing easier, establishes a better workow, offers a shared vocabulary among team members, and serves as a useful reference to keep coming back to. In my expe-
FIGURE 4.1. Anna Debenham explains the many benets of a front-end style
guide on 24 Ways.
1. Debenham, Anna. Front-end Style Guides, smashed.by/front-end-guides.
130 | RESPONSIVE DESIGN PATTERNS
rience, the guide becomes a sort of glue for a projects team members, communicating to everyone involved how the design system works. With the rise of responsive Web design, style guides are becoming more important than ever. What better way to show how an element will adapt than to show it in its nal environment? Thankfully for us, a lot of great work has been done recently in the area of responsive style guides. Starbucks2 graciously published its responsive pattern library, which it used to guide its responsive redesign. Samantha Warren created Style Tiles,3 a design deliverable that captures a projects fonts, colors and interface elements. Dan Cederholm created Pears,4 an open-source framework for developing ones own pattern library. And, as it happens, Ive created an opensource library of responsive patterns.5
Picking Things Apart

We need to look at our designs in a more modular way. So, lets get our hands dirty, pick apart Web interfaces and look at some emerging responsive patterns! Well look at some common ways to handle layout, navigation, interactive elements and more. By examining these emerging patterns, we can see what options are already in the wild and use them as a starting point to evolve and innovate. Remember, these techniques are all relatively new, so dont treat them as gospel, but rather as great starting points for your particular project. There are plenty of opportunities to improve existing patterns and perhaps even create entirely new techniques. These are exciting times, indeed!
2. Starbucks Style Guide, smashed.by/starbucks-styleguide. 3. Style Tiles, smashed.by/style-tiles. 4. Pears, smashed.by/pears. 5. Responsive Design Patterns, smashed.by/rwd-patterns.
BY BRAD FROST
131
Page Layout
A logical place to start is with layout, because it is certainly the most affected by the core tenets of responsive design. Historically, weve created multi-column designs without batting an eye, but now layouts need to work harder than ever to ensure that users have a legible, functional experience, no matter how they access the Web. So, what do we do with all of these columns and modules? How should they reow in a responsive environment? Luke Wroblewski answered these questions when he wrote about the various avors of responsive layout patterns6 in the wild, after having combed through Mediaqueri.es,7 a responsive gallery website. Lets take a close look at the patterns he discovered in his research.
MOSTLY FLUID In this pattern, the layout relies mostly on a uid grid for most of the adaptation; it stays roughly the same on medium and large
FIGURE 4.2. The mostly uid layout remains consistent until it appears
on a small screen. See a demo at smashed.by/mostlyuid.

6. Wroblewski, Luke. Multi-Device Layout Patterns, smashed.by/md-patterns. 7. MediaQueri.es, smashed.by/mq-showcase.
screens and only dramatically shifts on small screens. This mostly uid pattern is popular for many responsive websites because it requires maintaining only two major design views, instead of more complex patterns such as the column drop or layout shifter described next.
COLUMN DROP The column drop is a popular technique for three-column designs. If the viewport is too small to display three columns side by side, one of the sidebar columns drops beneath the other two columns. The columns eventually all stack above one another on small screens. This pattern can be effective if the content contained in the three columns isnt related, but content hierarchy can become difcult to manage if the content chunks in the columns depend on one another.
FIGURE 4.3. A demo for the column drop layout pattern is available
at smashed.by/col-drop.
BY BRAD FROST
133
LAYOUT SHIFTER
This relatively complex pattern involves creating distinct layouts at each breakpoint. As Luke states in his article:
Because this inherently requires more work, it seems to be less popular than the previous two patterns I outlined.
Media queries are certainly a lot of fun, but take care to avoid overcomplicating layouts just for the sake of declaring Look, ma! Its responsive! Once you introduce big changes at every major responsive breakpoint, you are basically creating different states in your layout that might need to be addressed separately and that, thus, could increase complexity. Remember that the goal of responsive design is to create legible, beautiful and functional experiences across as many environments as possible. Sometimes that involves 200 media queries, while other times it involves just 2.
FIGURE 4.4. The layout shifter pattern creates a distinct layout at
each breakpoint. See the demo at smashed.by/layout-shifter.
TINY TWEAKS Speaking of minimalist approaches, the tiny tweaks pattern is as simple as it sounds. Especially suitable for single-column layouts, tiny tweaks maintains its basic structure while subtly adjusting
type size, images and other components where appropriate. This pattern is useful for pages that contain only a single piece of content, such as articles, and for one-page linear websites.
FIGURE 4.5. The Tiny Tweaks pattern subtly adjusts type, images and other
components in an otherwise consistent layout: smashed.by/tiny-tweaks.
OFF-CANVAS Luke lays out one of the fundamental problems with the previous patterns:
While theres a lot of variety in the responsive design layout patterns listed above, theres also some common characteristics. They all tend to stack everything vertically on small screens resulting in long pages full of diverse components.
FIGURE 4.6. Off-canvas layouts move supplementary content off screen, from
where it can be brought in as requested: smashed.by/off-canvas.
BY BRAD FROST
135
Stacking content on top of each other isnt necessarily a bad thing, but mobile users are typically used to scrolling through a singular content type, such as a social feed, email feed or group of contacts, or diving deep into an article. Introducing multiple content types further down the page requires users to go on a scavenger hunt to nd them, and it could lead to frustration and/or confusion when users stumble upon this new, potentially unrelated content. What are the alternatives? The off-canvas pattern8 is a clever solution that moves a page component just off screen and, when requested, exposes the content using a sliding-door effect. This technique was popularized by Facebooks mobile y-out navigation.9 The off-canvas approach reserves the visible screen area for core content, while keeping additional content off to the side for easy access. Be sure to check out Jason Weavers and Luke Wroblewskis excellent off-canvas demos (see the footnote above).
FIGURE 4.7. Facebooks mobile navigation popularized the off-canvas technique.
8. Wroblewski, Luke. Off Canvas Multi-Device Layouts, smashed.by/off-canvas-layouts. 9. Responsive Navigation Patterns, smashed.by/nav-patterns.
CONTENT CHOREOGRAPHY
As we just saw with the off-canvas pattern, theres more to responsive layouts than simply stacking everything on top of each other for small screens. Be sure to check out the techniques that Trent lays out in the previous chapter for thoughtfully reowing the layout while maintaining a logical content hierarchy.
LAYOUT CONSIDERATIONS Whatever approach you decide to take for your responsive layout, focus on delivering a legible, logical experience to your users. Some things to think about:
Ensure that content ows logically.
As mentioned, users dont want to sift through a bunch of disparate content to nd what theyre looking for.
Treat layout as an enhancement.
In his talk Rethinking the Mobile Web, Bryan Rieger eloquently stated that, The absence of support for @media queries is in fact the first @media query. By constructing layouts mobile-rst, were able to serve optimized layouts to more mobile platforms, which are less likely to support media queries. This approach also embraces the cascading nature of CSS and results in smaller, more legible, more maintainable CSS.
Let the content, not device dimensions, determine breakpoints.
10
Way too many devices and screen sizes are out there, and new ones pop up every day. Instead of chasing down the screen sizes du jour, establish breakpoints where the design necessitates them, such as when line length becomes uncomfortably long, images become
10. Rieger, Bryan. Rethinking the Mobile Web, smashed.by/mobile-web.
BY BRAD FROST
137
unruly or interface elements looked stretched and unnatural. Follow Stephan Hays advice: Start with a fluid layout, start small and expand until the layout looks like shit. Time to insert a breakpoint!
Dont go overboard.
While dramatically changing a layout across screen sizes is certainly fun, dont feel obligated to insert breakpoints and radical changes just for the sake of being responsive. Instead, do whatevers required in order to create a legible layout thats a joy to interact with.
Navigation
Navigation is sometimes the most important interaction in a Web experience. Ive always said that navigation should be like a good friend: there when you need it, just like a friend whos willing to help you move into a new home. But it should also be considerate enough to give you your space, just as a good friend doesnt demand your constant attention. The community has been creating some clever solutions for dealing with responsive navigation.11 Lets look at some of the more popular techniques.
TOP NAVIGATION, OR DO NOTHING For navigation that contains
only a few links, keeping it at the top of the page might make sense. Its certainly easy to implement, but its not particularly scalable and could
FIGURE 4.8. Top navigation simply
displays links across the top of the page. Demo: smashed.by/topnav.
11. Ive been researching and collecting them in my very own blog post on Responsive Navigation Patterns smashed.by/nav-patterns.
potentially take up a lot of valuable real estate. Remember that we want navigation to be accessible but not take up a lot of space, in order to make room for the core content.
THE FOOTER ANCHOR
This clever solution places the navigation in the footer, leaving a simple anchor link in the header that lets users jump to the footer. This clears up room for the core content while still providing quick access to the navigation. It is relatively easy to implement and provides great support. Just keep in mind that a jarring jump to the websites footer could disorient some users.
THE SELECT MENU Another clever approach is to transform navigation links into
FIGURE 4.9. The footer anchor lets users
jump to the navigation in the footer. Demo: smashed.by/footeranchor.
a select form element for small screens. This approach saves a lot of real estate; but the select menu pattern could also be confusing because youd be using a form element outside of its natural environment. This approach can FIGURE 4.10. The select menu also be tricky if your navigation converts navigation links into includes submenus (more on com- a drop-down menu: smashed.by/dropdown-menu. plex navigation later).
BY BRAD FROST
139
THE TOGGLE
The toggle is one of the more elegant patterns out there. On a small screen, the navigation is collapsed, with only a button (typically denoted by three horizontal lines12 or a Menu anchor) that, when tapped, toggles the navigations visibility. The result is navigation that saves space but is still easily accessible. We need to make sure that the navigation remains accessible to users with poor JavaScript support. But we can bypass JavaScript altogether with this pattern by using the technique that Aaron Gustafson describes in Build a Smart Mobile Navigation Without Hacks,13 employing the :target CSS pseudo-selector to toggle the navigation.
FIGURE 4.11. The toggle collapses navigation items, revealing them
conditionally: smashed.by/togglenav.
12. Moore, Jordan. The Semantic, Responsive Navicon, Smashing Magazine,
smashed.by/design-navicon. 13. Gustafson, Aaron. Build a smart mobile navigation without hacks, .net magazine, smashed.by/nav-no-hacks.
NAVIGATION FLY-OUT
The navigation y-out is a good implementation of the off-canvas pattern explained in the layout section earlier. Instead of appearing above or below the core content, the navigation exists just to the side, off screen, and slides in when requested. This technique is certainly elegant, but because there are plenty of (literal) moving parts, make sure to test in as many environments as possible to avoid rendering the navigation non-functional, as Stephanie Rieger explains in her article A Plea for Progressive Enhancement.14
FIGURE 4.12. The navigation y-out pattern tucks the navigation off screen and
animates in when requested: smashed.by/navyout.
PRIORITY+ The name priority+ was coined by Michael Scharnagl to describe
the technique of exposing what are deemed to be the most important navigation items and tucking away less important ones behind a More link. This pattern can be effective for navigation that contains a lot of links at the same hierarchy level. However, deciding which navigation items to prioritize requires making assumptions about the users intentions; while we hope those assumptions are correct, the user may be looking for something else.
14. Rieger, Stephanie. A plea for progressive enhancement, smashed.by/plea-enhance.
BY BRAD FROST
141
FIGURE 4.13. Priority+ exposes the most important navigation icons and
hides the rest behind a More link: smashed.by/priority-nav.
THE HIDE N CRY This pattern (or should I say anti-pattern?) hides navigation that is deemed unimportant for small-screen users. While this certainly saves real estate, it deprives the increasingly mobile audience of access to those parts of the experience. Remember that small-screen users want to do anything and everything that large-screen users do, provided that its presented in a usable way. Dont penalize users for the device they happen to be browsing with.
Complex Navigation
Desktop screens have plenty of room for navigation. In addition, the mouse enables users to hover over parent categories to reveal drop-down menus containing child links. However, the mobile Web environment, with its lack of screen real estate and lack of hovering, poses a signicant challenge for implementing complex navigation. Sometimes whittling thousands of pages of content into three little links that t tidily on a phones screen is not realistic. Major organizations, massive e-commerce retailers, universities and other owners of large websites often need complex multi-level navigation. So, once again, the community is rising to the challenge and creating some great solutions for complex navigation for responsive designs.15 Lets dive in, shall we?
15. Complex Navigation Patterns for Responsive Design, smashed.by/complex-nav.
THE MULTI-TOGGLE
The multi-toggle is basically just a series of nested accordions. The user taps on a parent category to reveal child categories below. At a large enough screen size, the navigation converts to the usual multi-level drop-down menus were used to seeing. This pattern allows the user to easily scan parent categories, while providing quick access to child elements. Its also a scalable solution for navigation that is many levels deep.
FIGURE 4.14. The multi-toggle is basically a series of nested accordions:
smashed.by/multi-toogle.
THE OL RIGHT TO LEFT While the multi-toggle reveals child categories beneath the parent
category, the ol right to left takes a cue from the off-canvas pattern and slides in sub-navigation from off screen to the right. This is denitely one of the more elegant solutions for complex navigation; it is scalable to multiple levels, and it follows a common mobile convention of enabling the user to drill down into an experience with right-to-left animation. Because this approach is relatively intricate, test it in as many environments as possible to ensure the navigation remains accessible. Also, keep in mind that
BY BRAD FROST
143
FIGURE 4.15. The ol right to left pattern animates submenus in from the
right when requested: smashed.by/right-left.
animation (especially on mobile browsers) can vary extremely in performance (or be absent altogether).
SKIP THE SUB-NAVIGATION
Sub-navigation typically contains items that are also included on the parent categorys landing page. Because that content is accessible on the landing page, its perfectly viable to simply take smallscreen users straight to the landing page and let them make their next move from there.
FIGURE 4.16. This pattern takes small-screen users to a new page for submenu
items: smashed.by/skip-subnav.
This approach frees the user from having to deal with sub-navigation altogether; however, requiring a full page refresh just to get to the next level of navigation isnt very efcient.
CAROUSEL+
In this pattern, parent categories are displayed as a carousel, with sub-menus displayed individually as a list below. The user can swipe horizontally or use right and left arrows to move through the carousel. This pattern is unique; however, while swiping through a carousel can work well on touch devices, it can feel tedious on non-touch ones. Also, by not exposing all parent categories at once, the FIGURE 4.17. Carousel+ is carousel navigauser is forced to interact with tion that exposes sub-navigation options the menu just to see what below the chosen option: smashed.by/carousel-plus. other categories are available to them.
NAVIGATION CONSIDERATIONS Whatever navigation method you choose, keep these things in
mind:
Find the balance between navigation accessibility and unobtru-
siveness. Like a good friend, it should be there when you need it, but not always in your face, demanding attention. Because navigating is such an important interaction, test in as many environments as possible. See how the navigation works on a variety of devices and mobile browsers, including proxy
BY BRAD FROST
145
browsers. (Proxy browsers ofoad JavaScript interactions to the server and can yield interesting results; read more about them in Peter-Paul Kochs introductory chapter.) If youre collapsing the navigation for small screens, be explicit with the navigation icon. An icon consisting of three horizontal bars is becoming the de facto standard.16 Just make sure that whatever icon or wording you use screams Navigation! to the user.
Conditional Loading
Different environments provide different constraints and opportunities, so its essential to understand that responsive Web design does not mean serving up the exact same experience to all users (and adjusting only the layout). Serving hefty desktop designs and functionality to small screens does not make for a good mobile experience, but that is what the majority of responsive design implementations do today, as Guy Podjarny explains in his article Performance Implications of Responsive Design.17 Conversely, serving a barebones mobile experience to massive 27-inch screens doesnt really capitalize on all that extra screen space and processing power. Is there a happy medium? Enter conditional loading.18 Its not one of the three core ingredients of responsive design, yet this incredibly powerful technique can signicantly enhance the performance of a responsive website. Conditional loading entails serving up an initial core experience (i.e. the content that is essential to the experience and that is dened by the URL), while providing links to chunks of supplementary content (things like related posts, products and content; comment modules; social sharing widgets; maps; and other third-party content) and loading them on demand. So how exactly do we do it?
16. Clarke, Andy. We need a standard show navigation icon for RWD, smashed.by/navicon. 17. Podjarny, Guy. Performance Implications of Responsive Design, smashed.by/rwd-perf. 18. Keith, J. Conditional Loading for Responsive Designs, 24ways, smashed.by/cond-loading.
CREATING CONDITIONALLY LOADED CONTENT
1. Create a main HTML page, as well as separate HTML pages that contain only supplemental fragments of content. 2. Link to those content fragments on the main HTML page. This will ensure that they remain accessible, even for users with poor or no JavaScript support. 3. Using JavaScript, detect when the user clicks or taps a link to a content fragment or when the screen size warrants loading the supplemental content. 4. Load the relevant content fragment via AJAX.
FIGURE 4.18. This example segments lists of related products and reviews
as their own HTML fragments, which can be pulled in when requested.
By not including everything and the kitchen sink by default, we are able to serve up a relatively lightweight core that ensures fast page loading, while still providing access to non-essential content and functionality. And when the screen becomes large enough, we can dynamically pull in that supplemental content to build the nal, full experience.
BY BRAD FROST
147
FIGURE 4.19. Supplementary content is loaded for screens that are large
enough: smashed.by/mobile-rst-example.
Conditional loading not only helps performance, but also makes pages more scannable. Earlier, in the layout section, we discussed how sifting through disparate content types can confuse users and make it harder for them to nd what theyre looking for. Presenting a link with a heading and/or excerpt, instead of the full content, reduces clutter and enables the user to scan the page more quickly.
CONDITIONAL LOADING CONSIDERATIONS
Giving users different experiences is alright.
However, the full functionality should remain accessible to everybody in some way, shape or form. For example, its perfectly ne to have small-screen users tap to load a blog posts comments, while loading comments by default for large-screen users. Sure, the experience is a bit different, but access to the comments is what truly matters.
Screen size is just one variable.
Conditional loading neednt be limited to screen size. Touch events, geo-location, CSS animations and a host of other variables can be checked to pull in advanced functionality. Check out Modernizr19 for a broad list of features and capabilities that can be detected.
Large screens do not necessary imply a fast connection.
A laptop user could easily be on a aky connection, just as a mobile user may be on a strong Wi-Fi connection. While theres currently no reliable way to truly detect connection speed, keep an eye out for the emerging navigator.connection20 to detect connection type and speed.
Mind the number of HTTP requests being made.
Dynamically pulling in a lot of extra scripts, styles and content chunks can add many HTTP requests and bog down performance. Thankfully, tools such as the Filament Groups Quickconcat21 can concatenate all of those extra les and minimize the number of requests being made. Ultimately, be prudent with conditional loading, and keep performance at the top of mind.
Look into server-side optimization.
Conditional loading doesnt need to be solely a client-side technique. In the next chapter, Dave Olsen will explain how RESS (responsive design with server-side components) can be very useful when conditionally loading different views and content for different contexts.
19. Modernizr, smashed.by/modernizr. 20. Calhoun, David. Using navigator.connection on Android 2.2+, smashed.by/navcon. 21. Quickconcat, smashed.by/quickconcat.
BY BRAD FROST
149
Images
In case you havent noticed, the Web is chock-full of images. In fact, images often make up the bulk of a pages payload, 22 so handling them properly in a responsive design is important. Many factors come into play when serving graphic elements to multiple devices:23242526
Varying screen size Conditional Loading for Respon-
sive Designs23 Jeremy Keith provides a great overview of what conditional loading is and how effective it can be for responsive designs.
An AJAX Include Pattern for
Modular Content24 Scott Jehl explains how his team used conditional loading for non-essential elements on the Boston Globes responsive website.
SouthStreet Progressive En-
We have to deal with small screens, large screens and everything in between.
The growth of high-resolu-
hancement Workow25 The Filament Group has created lot of useful (and opensource!) scripts to help our community execute conditionally loading properly.
Creating a Mobile-First Respon-
tion displays Led by Apples Retina displays, high-resolution displays are becoming increasingly common.
Varying bandwidth
sive Web Design26 My tutorial and demo go through some considerations to make when implementing conditional loading.
Bandwidth runs the gamut from EDGE to 3G to blazingly-fast FiOS connections.
22. HTTP Archive stats, smashed.by/httparchive-stats. 23. Keith, Jeremy. Conditional Loading for Responsive Designs, smashed.by/cond-loading. 24. An Ajax-Include Pattern for Modular Content, smashed.by/mod-content. 25. Southstreet, smashed.by/southstreet. 26. Creating a Mobile-First Responsive Web Design, smashed.by/mobile-rst-example.
The need for art direction
Jason Grigsby sums up the issues involved in art direction for responsive images in his post A Framework for Discussing Responsive Images Solutions:27 Authors need to be able to provide different sources for images at different sizes [] based on the judgment of the designer for what is the best image at a particular breakpoint.
Image types
Images on the Web appear in a few common ways, e.g. as background images, icons and even good ol fashioned <img> elements. Lets now look at how to handle each image type.
BACKGROUND IMAGES Background images are dened in CSS, which means we can conditionally swap out or introduce background images in media query blocks. We can detect for certain screen dimensions or pixel densities and conditionally serve the appropriate background image for the device at hand. Tim Kadlec has done some extensive testing28 and found that browsers do a good job of ensuring that redundant background images arent downloaded. For the record, background images are stylistic elements that
dont add semantic meaning to a Web page. Im saying this because (as well nd out in a bit) responsive <img> elements can be tricky, and some people mistakenly think they can skirt the issue altogether simply by turning <img> elements into background images. This is not semantically sound, so dont consider it as an option.
27. Grigsby, Jason. A framework for discussing responsive images solutions,
smashed.by/rwd-images-solutions. 28. Kadlec, Tim. Media Query & Asset Downloading Results, smashed.by/download-research.
BY BRAD FROST
151
Considerations
Dont load large background images by default.
We should be authoring everything in a mobile-rst manner, and background images are no exception. Mobile browsers that dont support media queries shouldnt be forced to download large images that were never meant for small screens. Instead, serve smaller background images (or no images at all) by default.
Optimize for high-resolution screens.
We can create crisp background images for high-resolution screens by detecting pixel density in a media query using the 29 min-device-pixel-ratio property. That is, we include larger images and then use the background-size property to shrink them down to the appropriate dimensions.
ICONS Icons can be found throughout Web interfaces: shopping cart icons, social media icons, arrows, carets and much much more. Icons clarify actions and guide users through tasks. However, their relatively small size means they are quite susceptible to becoming blurry on sharp screens. Also, all of those tiny icons can add a lot of HTTP
requests and bog down performance. Here are some techniques for dealing with these important little elements:
Use Unicode characters.
Some common icons have Unicode character equivalents. This eliminates the need to include bitmap images for tiny elements, instead allowing for widely supported vector characters. These Unicode characters are great, but be careful because not every OS
29. Smus, Boris. High DPI images for variable pixel densities, smashed.by/high-dpi.
supports the same character sets. For example, some BlackBerrys and old Android devices will render an upward-facing caret as a square.
Implement icon fonts.
Another trick to avoid using raster graphics is to use icon fonts. Icon fonts are Web fonts that contain vector icons, which you can include on your website via the @font-face declaration. Symbolset30 and Pictos31 are great tools to get up and running with icon fonts. Again, keep in mind that not every device and environment supports @font-face.
Use background sprites.
Image sprites are raster graphics that are used to reduce HTTP requests and manage interface images all in one place. Maykel Looman nicely sums up the process of producing high-resolution sprites in his article Using CSS Sprites to Optimize Your Website for Retina Displays:32 1. I nstead of loading all of your assets as separate les, put them in a sprite. 2. Create another version of your sprite that is exactly double in size, with graphics that are exactly double in dimensions. 3. Gather all selectors that reference the sprite, and point them to the @2x sprite in the media query for high-resolution displays. 4. Dont forget to set the background-size property to translate the dimensions of the @2x sprite.
30. Symbolset, smashed.by/symset. 31. Pictos, smashed.by/pictos. 32. smashed.by/retina-sprites
BY BRAD FROST
153
FIGURE 4.20. Optimizing sprites for high-resolution screens can be
as simple as creating one thats twice as large as the original.
Sprites are implemented as CSS background images, so proportionally larger sprites may be swapped for them on high-resolution displays. If done correctly, optimizing for high-resolution screens should only require declaring a new larger sprite and sizing the background image accordingly.
IMAGE ELEMENTS Web designers need to be able to conditionally load different image
assets based on such conditions as resolution, pixel density, network speed and more. Unfortunately, the lowly <img> element isnt cut out for such a tall order. The topic of responsive images could easily ll a book on its own. This certainly isnt the place to get into all of the history, browser behaviors, political hurdles and so on, so Ill spare you. If youre curious about why responsive images are so challenging, I recommend checking out Mat Marquis article Responsive Images: How They Almost Worked and What We Need.33
33. smashed.by/resp-images
FIGURE 4.21. Web designers need to be able to load different image
assets for a number of conditions.
So, what are we to do about responsive images? Discussing all current solutions at length wouldnt be very useful because they are changing and evolving at an amazingly swift pace. So, I wont discuss them here (although if I had to choose one, Id put my money on Picturell34 by Scott Jehl). If youre looking for a good rundown of the many solutions out there, be sure to check out Chris Coyiers post Which Responsive Images Solution Should You Use?35
RESPONSIVE IMAGES CONSIDERATIONS While responsive image solutions vary in implementation, you
should follow these general guidelines:

Load small image assets by default.
Keeping with the mobile-rst strategy, we need to avoid making easy assumptions about our users context. By defaulting to small images, we are less likely to serve bulky assets to less capable mobile browsers and constrained environments.
34. Picturell, smashed.by/picturell. 35. Overview of Responsive Images Solutions, smashed.by/resp-images-solutions.
BY BRAD FROST
155
Make only one HTTP request per image.
In How Apple.com Will Serve Retina Images to New iPads,36 Jason Grigsby explains how Apples website loads both low- and high-resolution versions of images for Retina screens. Avoid this at all costs, because one of those assets will always be dead weight and result in a big waste of bandwidth.
Make image content legible on small screens.
Make sure that users can make out the content of images on small screens. This sounds obvious but its important because images (especially desktop-sized images squished down onto mobile screens) can be difcult to decipher.
Serve crisp images to high-resolution displays 37
In his article Retina Revolution, Daan Jobsis explains that image compression impacts JPG le size more than image dimensions. Jobsis found that we can serve JPGs with larger dimensions by default to ensure images look crisp on high-resolution screens. But because those larger JPGs are more compressed, theres no real toll on performance. This technique is promising because it removes the need to maintain and swap out multiple assets for the same image.
Avoid text in images.
This practice is commonplace. Besides basic accessibility issuestext rendered in bitmap graphics cant be searched, read by screen readers, copied and pasted, etc.it looks especially fuzzy on high-resolution displays.
36. smashed.by/retina-ipads 37. smashed.by/retina-revolution
Maintain hierarchy.
Images of different shapes and sizes that look very distinct on large screens run the risk of looking uniform when scaled down to small screens. One image might be a giant full-width banner on large screens, while another might be supplemental and occupy only a third of the width. Maintaining the hierarchy of these images is important, even when theyre being viewed on a small screen.
Consider server-side detection.
Many client-side responsive image solutions are still being ironed out, so looking into server-side responsive tools might be worthwhile until a long-term solution is in place. Check out Sencha.io Src38 and Adaptive Images.39
Media Objects
Media objects, such as videos, slideshows and maps, need to be given many of the same considerations as images because they, too, need to be uid, legible and performant. In addition to these considerations, we also need to ensure they are functional.
VIDEO
Videos and other media objects are different than images in that they dont maintain their aspect ratio when resized. Besides the myriad of codecs that need to be juggled, the scaling issue presents a big challenge for serving up video to a slew of Web-enabled devices. Thankfully, there are ways to create intrinsic ratios for videos, 40
38. Sencha.io Src, smashed.by/sencha-io. 39. Adaptive Images, smashed.by/adaptive-images. 40. Koblentz, Thierry. Creating Intrinsic Ratios for Video, A List Apart,
smashed.by/intrinsic-ratios
BY BRAD FROST
157
and theres even FitVids.js, 41 a plugin that does the heavy lifting of serving up videos that maintain the correct aspect ratio when resized. (Trent explained how the technique works in the previous chapter of this book.)
MAPS More involved media objects such as maps may require more than simple resizing in order to create the best experience in every context. While techniques42 exist to create uid and scalable embedded maps, Id argue that embedded maps dont translate all that well to the mobile context. There are a few reasons why we might not want to serve embedded maps to mobile users. First, mobile viewports are small to begin with, so forcing our users interact with a map that occupies a fraction of that viewport will make for a cramped experience. Secondly, many mobile operating systems (including iOS and Android) intercept links to Google Maps and open the devices native mapping application, resulting in a much more robust and familiar experience.
FIGURE 4.22. Take context into account when working with maps in order
to create the best possible experience: smashed.by/embedded-maps.

41. Fitvids, smashed.by/tvids. 42. Responsive Google Maps, smashed.by/responsive-maps.
Lastly, the performance cost of loading a bunch of external scripts and images might not be worth it, considering the limited user experience that embedded maps ultimately provide. So, what are we to do? This is actually a great opportunity to use conditional loading to serve the best mapping experience for the given context. By default, we could simply include a static image of a map that links to a third-party service, such as Google Maps. Thus, when the image is tapped, most major mobile platforms will re up the native maps application, where the user will have a richer experience. If that fails, the user is simply taken to the Google Maps website, where they receive a dedicated full-screen mapping experience. We can also detect when the screen is large enough to include an embedded map, and then dynamically load the embedded map experience. This technique comes in handy for features such as store locators and other location-specic needs. While it doesnt make sense in every circumstance, it makes the most of each context, instead of simply creating a one-size-ts-all experience.
Typography
Serving a legible reading experience to the multitude of devices that access the Web is critical. Thankfully, responsive techniques give Web designers some level of control over type size, line length, rhythm and more. Much can be said (and has been said) about responsive typography; so, while reducing and increasing font size across resolutions is common, bringing up a few emerging type-related patterns would be worthwhile.
FLUID TEXT Fluid images are great because they scale to perfectly t the size of their containers. However, hypertext just doesnt work that way out
BY BRAD FROST
159
of the box. Thankfully, some clever people have devised tools such as FitText43 and SlabText44 to create text that scales proportionally with its container. This enables designers to create striking headings (see Trent Waltons website45 for some inspiration) and blocks of text that scale with their parent containers.
MOLTEN LEADING Another challenge with responsive design is ensuring that type remains legible and beautiful across all screen resolutions. However, font size and line height dont scale proportionally the way images do. Tim Brown discusses this in his article Molten Leading (or Fluid Line Height),46 proposing a pattern that enables designers to control line height uidly, so that the leading can ebb and ow with the available screen space. CONDITIONAL TEXT Should we apply conditional hiding and showing of text based on screen size? In Is There Ever a Justication for Responsive Text?47 James Young describes the pattern and concludes that if text isnt worth displaying on mobile screens, then it shouldnt be included anywhere. While I am certainly a fan of content parity, there are cases in
which hiding supplemental information on smaller screens is valid (such as article excerpts, minor meta data, etc.), so long as users are able to accomplish all of their tasks and make informed decisions based on the available text.
43. FitText, smashed.by/ttext. 44. SlabText, smashed.by/slabtext. 45. Trent Waltons website, smashed.by/trentwalton. 46. smashed.by/molten-leading 47. smashed.by/resp-text
FIGURE 4.23. The Boston Globe hides supplemental text in its weather widget,
while still getting the point across.
A good example of conditional text in action is the weather module on the Boston Globes website, which hides supplemental text (like Mostly sunny or Sunny and cool) from small screens while still giving users the gist of the weather. Tread lightly when using the conditional text pattern; theres a ne line between hiding supplemental text and hiding text thats essential to the experience.
Interactive Components
Some website elements contain more moving parts than simple text and images, and putting relatively complex interactive components into a responsive environment can be tricky. Lets take a look at how the community is handling common interactive components like carousels and accordions.
CAROUSELS
We see carousels everywhere on the Web: home page promotional areas, featured stories, product images, related content and so on. Theyre a convenient way to save real estate; they establish hierarchy within a group of content elements; and they introduce
BY BRAD FROST
161
a sense of motion and interactivity that can really enhance the experience. Lets look at some ways to implement carousels in a responsive environment.
Fully Fluid The fully uid carousel matches the visible panels width to the screens size, similar to a uid image. While the result looks similar to a static image, more is going on under the hood because the carousels logic needs to be adjusted via JavaScript to ensure that the panels advance according to the screens size.
FIGURE 4.24. A fully uid carousel scales each panel to match the con-
tainers width: smashed.by/uid-carousel.
Another consideration is placement of type. A common desktop convention is to overlay text on top of a panels images. But small screens mean small images, so setting text over an image could obstruct the images content. To avoid this, we can simply stack text underneath the image on small screens to ensure that both the type and the image remain legible.
THE REVEAL The reveal pattern exposes more carousel panels when space is available. This technique is used on many uid desktop websites, such as Amazons and Vimeos, and on responsive websites, such as Disneys.
FIGURE 4.25. The reveal exposes more panels in the carousel for screens
that can accommodate them: smashed.by/reveal.
The reveal keeps content compact on small screens, while capitalizing on more space by exposing more content. A common complaint against mobile-rst responsive design is that large-screen versions of mobile-rst designs look vacant. The reveal solves this by introducing more content to ll the space.
Carousel Considerations
Make sure you actually need one. Many carousels are used to
sweep content under the rug. A carousel should not be a lazy substitute for making important content strategy decisions. Cycle through like items. Carousels should be predictable. The user should have a rough idea of what the next panel will be. Instead of cycling through disparate items (Check out our summer sale!, Like us on Facebook!, Read our blog!), give panels a running thread (product images or related news stories or related products, etc.). Load only what you need. If a carousel has 20 panels, please dont load all 20 by default! You dont know whether the user will even make it to the second panel. Dont load more than you have to, to keep the experience nice and fast.
BY BRAD FROST
163
FIGURE 4.26. Disney, Vimeo and Amazon all use the reveal pattern to
show more related content for screens that can accommodate it.
Be explicit. Tiny little dots sitting by themselves below a carou-
sel arent explicit enough to tell the user that this is a carousel. Add previous and next arrows, and indicate the users current position in the carousel. Treat touch as an enhancement. Enabling touch gestures to swipe through a carousel is a great way to add some pizazz to the user experience. Remember, though, that not every device or browser supports touch events. Provide additional means of navigation for optimal support.
ACCORDIONS Progressive disclosure is an extremely useful technique to help deal with super long page lengths on small screens. Progressive disclosure hints at more content by providing a title or summary of a content chunk thats hidden or not loaded. Once the user taps the desired section, the section is expanded and the associated content chunk is revealed.
FIGURE 4.27. Wikipedias mobile website uses progressive disclosure to
enable users to quickly scan each section.
BY BRAD FROST
165
Accordion to Full Accordions have long been a common interface convention, but they makes even sense for small screens where space is at a premium. Collapsing sections of content makes for more scannable pages on small mobile screens. However, once enough screen space is available to accommodate more content, it might make sense to remove the accordion altogether and simply expose the content in full.
FIGURE 4.28. The accordion-to-full pattern collapses content sections on
small screens and exposes them on large screens: smashed.by/accordion.
What Ive just described is a basic accordion. Not terribly exciting on its own, but in a responsive environment, an accordion makes sense when space is at a premium. And if the screen is large enough, simply remove the accordion altogether and expose all of the content.
Accordion to Tabs Tabs are another component that work really well for conditionally exposing chunks of content. However, tabs dont always t right on small screens. Thankfully, accordions work consistently well on small screens. We can combine these two popular patterns, so that an accordion is shown on small screens for a group of content and then converts
FIGURE 4.29. The accordion-to-tabs pattern presents an accordion on small
screens and a set of tabs on large screens: smashed.by/acc-to-tabs.
into a series of tabs for large screens. While doing this certainly requires a bit of hoop jumping, the solution ensures that users can efciently navigate those chunks of content.
Forms
Forms add a vital element of interactivity to the Web experience. Because forms are so crucial, they must be as easy to use as possible, no matter how a user accesses the Web.
FULLY FLUID
A common challenge on small screens is creating fully uid form elds while still maintaining a xed amount of padding. The traditional box model makes this surprisingly difcult. Thankfully, the CSS box-sizing property gives us a way forward. By setting 48 box-sizing to border-box, we can make form elds fully uid while keeping a xed amount of padding.
48. Irish, Paul. * { box-sizing: border-box } FTW, smashed.by/box-sizing.
BY BRAD FROST
167
FIGURE 4.30. The CSS rule box-sizing: border-box makes elements
such as form elds fully uid, while retaining xed padding and borders: smashed.by/uid-form.
TOP-TO-LEFT LABELS Aligning labels to the left of form elds is common on large screens. But the pattern doesnt always translate well to constrained screens. A simple solution is to stack labels on top of form elds on handsets.
FIGURE 4.31. We could stack form labels vertically on small screens
and oat them left on large screens: smashed.by/top-left.
Considerations
Look for alternatives to forms.
Look for opportunities to reduce friction and perhaps remove a form altogether. Social log-in buttons can reduce the pain of logging in on small screens, and geo-location can be used in lieu of address, city and ZIP forms to serve up location-specic information.
Reduce the number of elds in a form.
Completing forms is a chore, especially if the user is pecking on a mobile keyboard. So, in adapting your big honking form to small screens, look for opportunities to shed extraneous elds.
Use the appropriate input types.
The proper HTML5 input type will pull up a contextualized keyboard in many mobile browsers. For example, specifying type="email" will pull up a virtual keyboard containing dedicated .com and @ buttons, which makes completing the form just a little less painful.
Consider different input methods.
Keep in mind that devices with a myriad of input types are used to access the Web: touch, D-pads, scroll wheels and many others. Employing things like the tabindex attribute can make forms more accessible and enjoyable, regardless of input method.
Data Tables
Responsive data tables are tricky buggers. A table is one interface component whose semantic meaning is closely tied to its presentation, making it a challenge to translate across many screen sizes.
BY BRAD FROST
169
Chris Coyier has rounded up49 some of the more popular ways our community is dealing with responsive data tables. Lets look at some of the techniques.
Priority Similar to the priority+ navigation pattern, this one displays columns that are deemed to be most important for small screens, while still giving users a ltering option to see the remaining content. The wider the screen, the more columns are conditionally displayed. The result is a relatively elegant solution that gives users control over what data to view.
FIGURE 4.32. Priority tables expose the most important columns on
small screens, making the remaining ones available on request: smashed.by/display-data.
Horizontal Overflow Another approach taken by data-rich mobile websites such as Wikipedia is to use the overflow-x CSS property, which lets mobile users scroll horizontally to view more columns. Some techniques even dock the left-most column for easy comparison and analysis.
49. Coyier, Chris. Responsive Data Table Roundup, smashed.by/resp-tables.
FIGURE 4.33. The horizontal overow pattern lets users scroll horizontally
to see more table columns: smashed.by/overow-tables.
Definition List
One way to deal with tabular data on small screens is to avoid using a table altogether, swapping it with a denition list, which is more scannable on small screens. But prioritize semantics, and use whatever is most appropriate.
FIGURE 4.34. The denition list pattern converts a table into a denition
list, which is friendlier to small screens: smashed.by/table-def-list.
Table to Chart One of the wilder solutions out there is to convert data tables into pie charts on small screens. While not appropriate for every data table, the solution is pretty interesting and visually appealing for some use cases (see image on the next page).
BY BRAD FROST
171
FIGURE 4.35. Some tables can be converted into graphical charts on small
screens: smashed.by/table-to-charts.
Opt-Out Responsive Design

The last pattern well look at is an interesting one. Up until recently, mobile-optimized websites have been separate and (unfortunately in many cases) inadequate experiences. Because mobile users have been consistently let down by these inadequate experiences, theyve become conditioned to immediately sh for the View full site link upon reaching a mobile-optimized experience. Also, some users simply prefer the full zoomed-out view of a Web page to the close-up view provided by a mobile-optimized design. Ive heard many stories from (and know a few) people who say theyd rather see a birds-eye view of a layout, and then pinch and zoom into the desired section. I concede that having a birds-eye view is better than having to sift through a load of disparate content (as described in the layout section at the beginning of the chapter). Chris Coyier explains how to execute the opt-out technique in his post Opt-Out Responsive Design?50 The technique satises the
50. smashed.by/opt-out-rwd
users desire for an unoptimized mobile experience (hey, they asked for it!). Chris lays out these steps:
1. Query a parameter in the URL string (something like http://yoursite.com/?resp=no). 2. Remove the viewport meta tag and a responsive class from
the body. 3. Adjust the CSS to tweak the desktop view. 4. Provide a way for the user to switch back and forth between the responsive and unresponsive versions. I foresee this technique fading away as (hopefully) more fully functional, robust mobile Web experiences become more common. In the meantime, this could be a viable technique to better serve your users.
Into the Great Wide Open

We as Web designers are tasked with crafting experiences that look and function beautifully in a host of contexts, even ones that havent been invented yet. Thats certainly a tall order. But by breaking the overall interface into smaller puzzle pieces, we can make these admittedly tough problems a little more bearable. We can always count on change in this ever-shifting Web landscape. Pick this chapter up in a year or two and youll see what I mean. As responsive design continues to evolve, well see some techniques and patterns fall away, and the ones that stick around will surely evolve. And thats OK. While implementations will surely change as time marches on, the need remains to serve the Web in all its glory to more people in more environments than ever. Thats certainly a challenge for us, but also an absolutely amazing opportunity. Heres to the future!
BY BRAD FROST
173
ABOUT THE AUTHOR Brad Frost is a mobile Web strategist and frontend designer at R/GA, where he helps famous brands navigate this ever-changing device landscape. The biggest lesson he has learned in his career is that there is no one right way to do things and that in order to do your best, you have to be yourself. Brads motto: Wake up excited.
CHAPTER FIVE
BY DAVE OLSEN
OPTIMIZING FOR MOBILE
esponsive design has given us the power to deliver our content to anyone who happens to be using a device with a browser. Much of the discussion today surrounding responsive design seems to focus primarily on exible layouts and the decisions on how to implement them. Thats understandable. The push and pull of the browser window provides a visceral and satisfying interaction with a websites design. Unfortunately, it obscures the larger opportunity that responsive design provides usnamely, the ability to truly deliver our content anywhere. Today, a responsive website may be viewed on devices ranging from a TV box over high-speed Internet connection to an embedded system with a low-powered CPU to a mobile device with slow or metered network access. The latter device is becoming more important by the day. 17% of todays US population use a mobile device as their primary means of accessing the Internet.1
1. Smith, Aaron. Cell Internet Use 2012, smashed.by/pewinternet-reports.
BY DAVE OLSEN
175
To paraphrase Erik Runyon of the University of Notre Dame, because of this shift we should think of RWD as standing not only for responsive Web design but also for responsible Web design. We should do everything in our power to make sure that our websites are optimized for performance. Its the responsible thing to do. Unfortunately, many recent designs and trends show that we have a ways to go in making sure that our websites are truly optimized for performance.
The Web Is Getting Heavier

Its true. The Web has been putting on some serious weight in the last few years. Since 2003, the average weight of a Web page has risen from 300 KB to 1,098 KB, or just a little over a 1 MB (using an average of 85 requests per page to do so!).2, 3 Its both fascinating and disturbing to me that it now takes that much content to display something as simple as a Web page. Tim Berners-Lees rst ever Web page, weighing in at a measly 2.5 KB, could be downloaded over 420 times using the same amount of bandwidth as it takes to download todays average page. Two things have driven this gradual increase in overall page weight: images and JavaScript. Combined, they make up 82% of the 1,098 KB needed to load todays average page. Images alone account for 64% of that average weight. While these may be the primary technical reason for the increase in page weight, there is a more important reason: ourselves. As designers and developers, weve bought, hook, line and sinker, into the notion of an ever faster Internet, an Internet where speeds can and will only increase. Thats because, quite frankly, its a handy
2. Grigsby, Jason. Going Fast on the Mobile Web, SlideShare, 18 Sep 2008,
smashed.by/slideshare-presentation. 3. HTTP Archive, Trends, 14 Oct 2012, smashed.by/httparchive-trends.
176
FIGURE 5.1. This graph of total page transfer sizes between November 2010 and
September 2012 shows that the Web has been putting on some weight over the last few years.
rationalization for the things we want to do. Larger screen resolutions have given us larger canvases to ll with images. New browsers and JavaScript libraries have enabled us to create richer experiences. With an ever faster Internet, why worry about page weight? Surely bandwidth will eventually catch up with what were pushing. With mobile, the ever faster Internet rationalization ran head long into reality. Bandwidth wasnt catching up. It actually took a huge step back to the bleep-bloop heyday of the dial-up modem. Unfortunately, with the rollout of supposedly high-speed mobile networks, the ever faster Internet rationalization may once again induce us to overlook our bad practices. By wearing our desktop Web blinders and focusing solely on bandwidth as the only performance optimization factor, were ignoring the true bottleneck of performance on mobile networks: latency.4
4. HTTP Archive, Trends, 14 Oct 2012, smashed.by/httparchive-trends2.
BY DAVE OLSEN
177
LATENCY: THE MOBILE NETWORK KILLER
While mobile network speeds are slower than desktop speeds, they arent on the whole that bad. The real Web performance difference between the two is latency. In his article Latency: The New Web Performance Bottleneck,5 Ilya Grigorik shows that simply increasing bandwidth on mobile doesnt lead to correspondingly faster page loading times. After a certain point, page loading time is nearly identical, no matter how fast the network. For example, upgrading from 5Mbps to 10Mbps results in a mere 5% improvement in page loading time. On the other hand, lowering network latency always leads to improved page loading times. So, what is latency? Latency is the measure of the amount of time between when a browser requests a resource from a server (such as a CSS le) and when it starts to receive the servers response. While a cable modem could experience an average latency of 20 milliseconds per resource request, a 3G connection could experience an average latency of 200 milliseconds per resource request.6 Thats 10 times more latency! To illustrate how quickly this lag can affect your Web pages performance, consider the following. On a cable modem, assuming a browser that can open four concurrent connections,7 latency will account for 0.4 seconds of the total download time of our average page and its 85 requests. That same page loaded over an average 3G connection? Latency alone will account for 4.5 seconds of the total download time.
5. Grigorik, Ilya. Latency: The New Web Performance Bottleneck, igvita.com, 19 Jul 2012,
smashed.by/igvita-latency. 6. Podjarny, Guy. The Mobile Difference in Numbers, SlideShare, 26 Jun 2012, smashed.by/mobile-difference. 7. On average, most modern desktop/mobile browsers open six concurrent connections, but four is a good number considering a number of legacy browsers. You can nd more data about it on Browserscope (smashed.by/browsers-connections).
178
OUR PERFORMANCE EXPECTATIONS DONT CHANGE JUST BECAUSE WERE ON MOBILE
Essentially, because of latency, the responsive website that youve built will take at least 10 times longer to download on a mobile network than on a wired connectionyou know, the kind of wired connection that you do all of your development and testing on. But the latency factor cant be that big of a deal, right? Users on mobile networks should realize that Web pages will take longer to download on mobile, and they should and will be more forgiving of that kind of thing. Bzzzt. Unfortunately, thats simply not the case. Equation Research found that 74% of mobile users expect a mobile website to load just as quickly as a desktop website.8 Two years prior, only 58% of users felt that way. Does your website drive business to you? In the same report, it found that 57% of users who had a problem with a website on their mobile phone, including slow loading, wouldnt recommend that website or service; 46% wouldnt return. The most striking statistic from the report is the one related to loading time. In 2009, 20% of survey respondents said that if a mobile website took longer than ve seconds to load, theyd leave. In 2011, a whopping 74% answered that theyd leave after the same amount of time. As we found earlier, latency alone would take up 4.5 seconds of that 5-second window when loading the average website. So, what do these numbers mean for us, designers and developers, as we develop responsive Web designs?
RWD: OUT OF SIGHT AND STILL DOWNLOADING
One of the ugly truths about RWD as a mobile development technique is that it can do a damn good job of hiding page weight. Some
8. Equation Research, What Users Want From Mobile, Compuware, Jul 2011,
smashed.by/gomezpdf. BY DAVE OLSEN | 179
developers approach RWD as if implementing the technique were simply a matter of sprinkling magical media-query pixie dust on their website and, voil, they would instantly have a mobile-friendly website. As Jason Grigsby writes:9
The way in which CSS media queries have been promoted for mobile hides tough problems and gives developers a false promise of a simple solution for designing for multiple screens.
With RWD, do you get a layout that is mobile-friendly? Sure. Can you provide a mobile user with a view of your website that shows less content and that is more focused? Yup. Have you delivered fewer assets and, therefore, less weight to the browser in this stripped down view? Sadly, you probably havent. From a Web performance perspective, the Achilles heel of RWD is over-downloading. Research by both Grigsby and Guy Podjarny shows that the mobile versions of many responsive layouts weigh the same as their full-blown desktop versions. The trap with responsive design is that, while the visual end product may be mobile-friendly, the page is not necessarily performance-friendly for mobile.
DISPLAY: NONE: THE DARK MATTER OF RWD While RWD helps to hide page weight in three areas, the most important technique is to use display: none to hide interface elements.
9. Grigsby, Jason. Performance Implications of Responsive Web Design, SpeakerDeck, 26
Jun 2012, smashed.by/performance-implications.
180
Are assets loaded per website page request on a mobile device larger than on a desktop view?
Jason Grigsby's research Guy Podjarny's research
FIGURE 5.2. These charts show Jason Grigsby (on the left) and Guy Podjarnys (on
the right) research on responsive website page sizes. Both graphs show whether the assets loaded per website load on mobile are larger or small than the full-blown desktop view. Usually, both have almost the same size.
#related-images { width: 100%; padding: 4px; background: #ccc; display: block; } @media screen and (max-width: 320px) { #related-images { display: none; } }
BY DAVE OLSEN
181
The truth is that, while those elements might not be visible to the end user, the HTML parser will still chunk through them and ll in their content. So, in the case of images included in your page with an img tag, they will still get downloaded, but neither you nor visitors to your website will be able to see them.10 Think of display: none as the equivalent of adding dark matter to your pages. Although the content wont be seen, its there, lurking behind the scene, compromising the performance of your website by invoking extra requests and causing longer download times (remember: latency!). The second technique of RWD is to scale images so that they can ex and t in a uid layout. The problem with this is that some developers size their images to look good at large screen resolutions but then scale those images down simply via CSS to t mobile resolutionsthereby forcing the mobile browser to download unnecessary kilobytes of data. The third technique is to put media queries within link tags. But it wont prevent browsers from downloading CSS les. Media queries simply help the browser decide the loading priority and then decide which styles to apply to the page. For example:
<link rel="stylesheet" media="screen and (max-width: 320px)" href="small.css"> <link rel="stylesheet" media="screen and (min-width: 320px) and (max-width: 760px)" href="medium.css"> <link rel="stylesheet" media="screen and (min-width: 760px)" href="large.css">
10. Tim Kadlec has presented some research on display: none in his article Media
Query and Asset Downloading Results (smashed.by/timkadlec2012). The conclusion is unambiguous: If youre going to hide a content image, dont do it with display: none. If you want to hide a background image, your best bet is to hide the parent element. To swap background images, dene them both inside of media queries.
182
On an iPhone, for example, the last CSS le would get the highest downloading priority, as well as have its styles applied to the Web page. The other two CSS les would be downloaded only after the rst one has completed. The good news is that they wouldnt block the rendering of the page.11 When building a responsive website, performance optimization needs to be baked into its design and implementation from the very beginning of the project. Some of these optimizations are quite simple to implement when building the website; others are more involved and will require time to rethink and reevaluate our common coding practices.
Learning Where to Trim the Fat

The solutions suggested in the next major section of this chapter (Mobile Optimization Techniques) generally fall into one or more of the following four performance-related categories:
Reduce page weight; Reduce the number of requests to the server (which addresses
latency!); Optimize when content is loaded so that your website becomes usable more quickly; Optimize JavaScript performance. In order to properly apply these techniques to your website, you will rst need to nd out which ones t your needs. I highly recommend four tools to better understand your websites needs.
11. Grigorik, Ilya. Debunking Responsive CSS Performance Myths, igvita.com, 14 Jun 2012,
smashed.by/perf-myths. BY DAVE OLSEN | 183
WEIGH YOUR WEBSITE WITH MOBITEST
There are many ways to weigh a website. In my experience, the easiest and most useful mobile-specic tool is Mobitest.12 It provides not only the average loading time and average size of your website as viewed on a real mobile device, but an actual video of your pages loading, which helps to visualize the performance of the website. It also provides an HTTP Archive le (discussed in the next subsection), which you can save locally to analyze later on.
FIGURE 5.3. Mobitest, a tool provided by Akamai, helps you discover and visualize
the loading issues for your website.
As of the time of writing, Mobitest has a few downsides. The devices that you can test on are limited to a few selected Android and iOS models. Also, the network connection cant be modied, so testing latency is out of the question. That said, its a great step forward for testing mobile performance. If youre familiar with WebPageTest,13 which Mobitest is built on, make sure to check out Andy Davies and Aaron Peters Velocity Europe talk, Web Page Test: Beyond the Basics.14 It provides some great tips and tricks for directly leveraging WebPageTest to your mobile performance testing needs.
12. smashed.by/mobitest 13. smashed.by/webpagetest 14. Slides: smashed.by/slideshare-test
184
WATERFALLS: UNDERSTANDING THE HAR FILE
If youre going to optimize your website, youll quickly realize that to get the most out of the process youll need to learn how to use an HTTP Archive (HAR) le. While this might sound daunting at rst, its actually not that hard. If youve ever worked with the Network panel in either Chrome or Safaris Web Inspector, then youve most likely already seen an example of a waterfall chart based on a HAR le. The following example uses a HAR le saved out of Chrome and uploaded to the PCAP Web Performance Analyzer.15
FIGURE 5.4. An example of a HAR le as viewed on the PCAP Web Per-
formance Analyzer website.
In looking at the overview above, its obvious why its referred to as a waterfall chart. The two vertical lines on the right should stand out. The blue line denotes the start of the rendering of the Web page. This is when the DOM is loaded and the Web page rst becomes available to the end user. It will most likely still shift around a bit as assets continue to be added and modied. The red line corresponds to when the page has nished rendering and the browsers onload event res. Lets look more closely at one of the loaded resources to get a better idea of what the HAR le tells us:
15. smashed.by/pcapperf
BY DAVE OLSEN
185
FIGURE 5.5. A close-up of the options available for an individual entry in a HAR le.
In this example, the blue bar shows the time that the browser took to look up the DNS information for the request. The green bar displays the time it took to connect to the server. The red line shows the time it took to send data to the server. The purple line represents the time that the browser waited to receive the rst byte of data back from the server. And the gray shows the rest of the data being downloaded for use. HAR les contain other useful information such as compressed and uncompressed sizes for assets, as well as request and response headers. The PCAP Web Performance Analyzer also provides aggregated performance statistics.
THE MOBILE PERFORMANCE BOOKMARKLET
Steve Souders, well known as a Web performance evangelist, has put together the ultimate mobile performance testing bookmarklet, Mobile Perf.16 He also lists a handy collection of Web performance bookmarklets that are useful and easy to use when evaluating performance on mobile, including YSlow,17 DOM Monster,18
16. smashed.by/mobileperf 17. smashed.by/yslow 18. smashed.by/dom-monster
186
SpriteMe19 and CSSess.20 Overall, these bookmarklets can go a long way in helping you not only to evaluate the performance of your mobile website, but to take steps to resolve any issues you might nd.
SIMULATING BANDWIDTH AND LATENCY CONSTRAINTS
Testing responsive designs on wired or wireless laptops can give a false sense of how well your page performs. In order to see how well your website will perform under the suboptimal constraints of mobile networks, use one of the two tools that will allow you to modify your network connection. The rst solution is Charles,21 a robust HTTP proxy and HTTP monitoring tool that also provides the ability to shape your network trafc. The best part of Charles, though, is that it allows you to capture and review the network trafc generated by your website. Similar to the previous example with Chrome, you can use it to save a HAR le and then use the PCAP Web Performance Analyzer to see where problems and bottlenecks might appear on higher-latency networks. As of this writing, Charles v3.6.5 costs $50. The second solution is Throttle.22 Throttle was developed at West Virginia University as a free and simple trafc-shaping tool that we could use in our company with Adobe Edge Inspect. Adobe Edge Inspect is a free tool that helps you to preview and remotely debug a responsive design on iOS and Android devices. While it doesnt currently provide a HAR le, it does give us a rough gauge of performance as we work with clients and designers across our organization.
19. smashed.by/spriteme 20. smashed.by/cssess 21. smashed.by/charles 22. smashed.by/throttle
BY DAVE OLSEN
187
Mobile Optimization Techniques

A lot of options are out there for improving the performance of your website. To help you decide which techniques would be most effective, Ive selected some and organized them into three groups:
1. The essentials, 2. Next steps, 3. Deep cuts.
Each set of techniques can be implemented in whole, in part or not at all. This is simply my way of organizing techniques in the order that I think would have the most benet for any given website. In my own workow, this categorization has served as a checklist to move through when considering various optimization techniques for our websites.
THE ESSENTIALS
Enabling le compression and caching headers on your server are two of the simplest things you can do to improve mobile performance. They really are must do performance tweaks, no matter what else you end up implementing. The techniques in this section will help you to:
Reduce page weight, Reduce the number of requests to the server (addresses latency!).
Because these two techniques are implemented on the server, they will immediately improve the performance of every page load. It doesnt get much easier than that.
188
Enable mod_gzip or mod_deflate to Compress Files In the same way that we compress les on our computers to make them easier and faster to send to clients for review, servers can compress Web les before sending them to browsers. Because our mobile users might be surng with limited bandwidth, we should make the les we send over it as small as possible. Accelerating the downloading of assets is an obvious win, but it also clears the downloads queue more quickly, thus speeding up the entire loading performance of the website. The two compression librar- At West Virginia University were using mod_deflate to compress ies for Apache, mod_gzip and our home page and its related mod_deflate, work best on text-heavy les such as HTML, JavaScript and CSS les. As of CSS and JavaScript. Image for- this writing, if those les were not compressed, a visiting user would mats such as JPEG are already need to download a total of 824K compressed, so the libraries in content. Instead, by compresswill have almost no effect on 23 ing the les, a client only needs to them. download 663K of content. Thats a One thing to keep in mind 20% savings in bandwidth use. when using mod_gzip is that it doesnt work well on les smaller than 500 bytes, nor on les larger than 500 KB. While it will compress small les, the savings are so negligible that the payoff isnt worth the effort of your server. Conversely, compressing large les on the server could take so long and delay the response of the website enough that, again, it might not be worth the effort. Enabling this feature is very easy. Below are simple configurations that you can use with Apache for mod_gzip and mod_deflates respectively:
23. Simple ways to further compress images are discussed in the Next Steps section of
this chapter. BY DAVE OLSEN | 189
-- MOD DEFLATE -<IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/plain text/ xml text/css application/javascript application/x-javascript application/rss+xml application/atom_xml </IfModule>
-- MOD GZIP -<IfModule mod_gzip.c> mod_gzip_minimum_file_size 500 mod_gzip_maximum_file_size 500000 mod_gzip_item_include file \.html$ mod_gzip_item_include file \.css$ mod_gzip_item_include file \.js$ mod_gzip_item_include file \.php$ mod_gzip_item_include file \.py$ mod_gzip_item_include file \.txt$ mod_gzip_item_include file \.xml$ mod_gzip_item_exclude file \.png$ mod_gzip_item_exclude file \.jpg$ mod_gzip_item_exclude file \.gif$ mod_gzip_item_include mime ^text/html$ mod_gzip_item_include mime ^text/plain$ mod_gzip_item_include mime ^text/xml$ mod_gzip_item_include mime ^text/css$ mod_gzip_item_include mime âpplication/javascript$ mod_gzip_item_include mime âpplication/x-javascript$ mod_gzip_item_include mime âpplication/rss+xml$ mod_gzip_item_include mime âpplication/atom_xml$ mod_gzip_item_exclude mime îmage/ </IFModule>
190
You can use RedBot 24 to see whether your website is already using compression. If youre interested in delving deeper into this topic, there is much more to learn about mod_gzip and mod_deflate on their respective websites.25
Make Sure Assets Are Cached by the Browser Whether CSS les, images or JavaScript les, the vast bulk of the content we create for our Web pages is static. Once weve launched a website, we tend to change these assets very rarely. For mobile, if we can make sure these static assets are downloaded once and then cached on the device, we get two wins: fewer total requests made in future page loads, and less total content to be downloaded. This way, on subsequent visits, these users will have a primed cache, and their experience will be that much faster and, consequently, better. The simplest trick to make sure users get the primed cache state for their browser is to make sure that your Web servers Expires header is set and, importantly, that its set to an appropriate date far into the future. This expiration date should be no sooner than one month and no longer than one year into the future. If you know that a particular resource will change every two weeks, then you can tweak the Expires header for that asset to make sure it gets refreshed more often. But this exception highlights a serious downside to this type of aggressive caching on the client. The better option would be to rename the resource when its updated, which would then generate a new request from the client. The following is a simple mod_expires conguration for Apache that you can use to cache your les for an appropriate length of time.
24. smashed.by/redbot 25. smashed.by/mod_gzip and smashed.by/mod-deate.
BY DAVE OLSEN
191
<IfModule mod_expires.c> ExpiresActive on ExpiresByType text/html "access plus 5 minutes" ExpiresByType image/jpg "access plus 6 months" ExpiresByType image/jpeg "access plus 6 months" ExpiresByType image/gif "access plus 6 months" ExpiresByType image/png "access plus 6 months" ExpiresByType text/css "access plus 6 months" ExpiresByType text/javascript "access plus 6 months" ExpiresByType application/javascript "access plus 6 months" ExpiresByType application/x-javascript "access plus 6 months" ExpiresByType application/x-icon "access plus 1 year" </IfModule>
The one limiting factor of this performance optimization technique for mobile devices is the size of the device cache itself. For the most part, and especially on older OSes and devices, the cache is relatively tiny. The total cache of Android 2.xs stock browser can hold only 5.7 MBs worth of content.26 iOS is better at 50 MB, but that pales in comparison to the kind of cache sizes we have on desktop, especially when you consider that a single website can take up to 4 MB worth of that 50 MB total. Still, attempting to cache les is better than not, especially as mobile browser- and device-makers beef up their cache sizes. One workaround for the cache size limitation is to use localStorage as a le cache. Well touch on this technique in more depth in the Deep Cuts section.
26. Joshua Bixby, Early ndings: Mobile browser cache persistence and behaviour,
Web Performance Today, 12 July 2012, smashed.by/webperformancetoday.
192
NEXT STEPS
File compression and browser caching are very good rst steps, but theyre merely thatrst steps. To get your website performing optimally, you can take more advanced steps that, while requiring more work, could have a much more dramatic performance gain for your users. The techniques in this section will help to:
Reduce page weight, Reduce the number of requests to the server (addresses latency!), Optimize when content is loaded so that your website becomes
usable more quickly. Two of these techniques, minication and concatenation, should probably only ever be implemented when you are moving from a development environment to a staging or production environment. They can be unwieldy when multiple and frequent updates are required.
Make Your Files Smaller With Minification Minifying code simply means removing extra bytes from a les size by taking out unnecessary things such as white space, line breaks and indentation. Of course these things make it easier for us to read a le but they arent actually necessary for browsers to parse and understand the code. With minication, the browser downloads less content, translating into quicker overall downloads and asset loading. Thus the rendering time for your Web page will also be faster. If youve used any popular JavaScript library (jQuery, for example), then youve most likely used the minied version. Because of this, many developers assume that minication can only be used with JavaScript, but, technically, it can be applied to any text-based resource. The most important asset we should consider minifying in production code is CSS.
BY DAVE OLSEN | 193
A number of resources are available for minifying CSS and JavaScript les. The oldest and possibly best is YUI Compressor27 by Yahoo. If youd rather not have to worry about downloading and installing it, you can also use an online version of it.28
One File to Rule Them All: Combine Multiple Files with Concatenation Minications performance twin is concatenation. If you know that a Web page will need a large number of JavaScript or CSS les, you can not only minify them into smaller individual packets, but also string them together into several larger les to increase performance. For example, rather than needing to download 10 JavaScript lestherefore requiring 10 connections to the serverusers might download only 4 separate les that are some combination of the original 10. After Expires headers, concatenation might be the single best technique for opening up latency bottlenecks on mobile networks. Unfortunately, it also comes with some downsides. As it turns out in practice, overoptimizing when using concatenation is possible, too. Unless your JavaScript or CSS les are very small, dont lump them all together into one big le. By keeping them partially separate, youll take advantage of the browsers capacity to download multiple les at once, on average up to six. Bryan McQuade does a good job of discussing this issue in his Velocity 2011 conference talk, Website Acceleration With Page Speed Technologies.29 Just as with minication, YUICompressor is a great resource for concatenating les. If your Web application uses PHP, you can use QuickConcat,30 developed by the Filament Group.
27. smashed.by/yui-compressor 28. smashed.by/yui-online 29. smashed.by/velocity2011 30. smashed.by/quickconcat
194
Minify: The PHP Minification and Concatenation Library As recommended earlier in this chapter, minify and concatenate les only when styles and code are production-ready. As we discovered recently, if you happen to use PHP, though, you can take advantage of the great library Minify,31 which minies and concatenates les on the y. Lets look at how were using Minify with our CSS les on West Virginia Universitys home page:
<link rel="stylesheet" href="/min/?b=css&f=base. css,supersized.css,supersized.shutter.css,layout. css,option-3.css">
Minify automagically compresses and minies the les that weve listed in request variable f. We can continue to modify these les as we normally would without having to worry about optimizing them. Minify is also available as a WordPress plugin.32
Inlining Small JavaScript and CSS Files If your website requires only a bit of JavaScript and/or CSS in order to work properly, then consider simply embedding the code on the page, rather than linking to it. Any extra requests are not worth the overhead, performance-wise, for anything less than 4 KB. Just make sure to place the inlined CSS in the head of your document and the inlined JavaScript at the end of your document. Image Optimization As shown earlier, images are the number one source of bloat on the Web. They account for 64% of the average weight of a Web page. If a developer or designer can reduce the footprint of their images,
31. smashed.by/minify 32. smashed.by/minify-wordpress
BY DAVE OLSEN
195
then theyve taken a big step in optimizing their Web pages performance. Image optimization is a two-step process. The rst thing to do to optimize your images is to choose the appropriate format. For almost all of your images, you can use PNG, with the color depth set to the lowest acceptable level. If youre optimizing a photograph, use JPEG. Again, focus on nding the lowest acceptable setting for quality. Dont just set it to some high-quality default. Even when an image is saved with something like Photoshops Save for the Web, it can contain extra information, such as unnecessary comments or incorrect color palettes, which makes the les size larger than it needs to be. To reduce an images size even further, the second thing to do is run it through an optimizer that strips out that extra information. The best Web-based tool for this, in my opinion, is kraken.io.33 Another good resource is Smush.it34 by Yahoo. If you need an image optimization utility that you can use ofine and youre on a Mac, check out ImageOptim.35 On Windows, one of the most helpful ofine tools is Radical Image Optimization Tool36 (RIOT). Make sure to play around with the settings to nd the combination that gives you both the best le size and the quality youre looking for. Another way to optimize images is to use sprites, which well cover in the Deep Cuts section. If youre really into image optimization, make sure to read Sergey Chikuyonoks two articles on the subject, Clever JPEG Optimization Techniques37 and Clever PNG Optimization Techniques,38 on Smashing Magazine. Both articles give great tips on how to deliver
33. smashed.by/krakenio 34. smashed.by/ysmushit 35. smashed.by/imageoptim 36. smashed.by/riot 37. smashed.by/jpeg-techniques 38. smashed.by/png-techniques
196
high-quality and highly optimized images, based on a deep understanding of how each format works.
Defer Loading of Content When Possible All of the techniques listed above, with the exception of concatenation, will help to reduce overall page weight. Another possibility is to prioritize the loading of assets. By prioritizing assets, we arent necessarily improving performance through a cache or bandwidth, but we can make the page appear to load faster. The easiest type of asset to defer is a JavaScript le, using the HTML5 defer and async attributes of the script tag.
<script defer src="script-1.js"></script> <scrypt async src="script-2.js"></script>
From a downloading and latency standpoint, the defer and async attributes behave very similarly. When the browser parses your Web page and encounters the script tag, it will attempt to download the referenced les. The defer and async attributes tell the browser that the linked les should be executed after the browser has nished loading all of the other content on the Web page. So, which one should we use? When deciding which attribute to use, the question to ask is whether order matters when loading the linked JavaScript les. If it does, then the defer attribute is better. All tags with that attribute will be executed in the same order as the script tags are listed. Suppose you reference two JavaScript les in order: the rst references jQuery, and the second references custom JavaScript that uses functionality from jQuery. Because the second script must be loaded after the rst, youd need to use the defer attribute on both in order for your website to work. If order doesnt matter, then you are better served by the async attribute.
BY DAVE OLSEN | 197
But what do you use if you need to support an older browser that doesnt support the defer and async attributes? Then, you can dynamically create script elements using JavaScript.
var js = document.createElement('script'); js.src = 'script.js'; var head = document.getElementsByTagName('head')[0]; head.appendChild(js);
Read more about this fallback in Stoyan Stefanovs article NonBlocking JavaScript Downloads.39 The defer attribute is supported by all major desktop and mobile browsers except for the Opera family of browsers.40 The async attribute shares a similar level of support, with the notable exception of Internet Explorer; async support was added in IE 10.41
DEEP CUTS
The previous two sections, Essentials and Next Steps, cover most of the traditional performance optimization techniques for responsive websites. Considering that RWD is itself rather cuttingedge, lets discuss now a number of HTML5-related and forwardlooking techniques that will improve the performance of your website in mobile browsers.
39. smashed.by/non-blocking 40. It is supported in IE7+, Firefox 14+, Chrome 21+, Safari 5.1+, iOS Safari 5.0+ and Android 3.0+,
but not currently in Opera or Opera Mini: smashed.by/defer-support. 41. Support is very similar to the support of defer outlined above. However, in IEs case, only IE 10+ supports it: smashed.by/async-support.
198
The techniques in this section will help to:

Reduce page weight, Reduce the number of requests to the server (addresses latency!), Optimize when content is loaded so that your website becomes
usable more quickly. The primary downside of the techniques listed in this section is a lack of support in some old mobile browsers. Unfortunately, there arent many workarounds for them (at least for now), so if you are primarily concerned with legacy mobile browsers, thoroughly study and research the techniques before applying them in your projects.
Correctly Ordering Your CSS and JavaScript Surprisingly, simply ordering your CSS and JavaScript correctly can have a large impact on the performance of your page. Because JavaScript can alter the content and layout of a Web page, in many browsers it will block the rendering of any content that appears after the referenced JavaScript le has been downloaded, parsed and executed. This includes even the downloading of certain content that appears after the JavaScript reference. Lets look at a quick example of this type of blocking in action. Here is the <head> of a typical website, where we are referencing two style sheets and a JavaScript le. Lets assume that in the <body>, we reference an image.
<head> <script src="jquery.js"></script> <link rel="stylesheet" href="small.css"> <link rel="stylesheet" href="big.css">
</head>
BY DAVE OLSEN
199
Here is the order in which the browser would download these les:
FIGURE 5.6. This waterfall chart shows the image download being blocked by the
JavaScript located in the head.
The JavaScript le blocks the downloading and, importantly, the parsing and rendering of the DOM elements that followin this case, an image. A better option would be to put the JavaScript just above the closing body tag. When we do that, we can see that the image loads at the same time as the JavaScript le.
FIGURE 5.7. This waterfall shows that the image is being downloaded in parallel to
the JavaScript le, now that the latter was moved to above the closing body tag.
The only time youd want to reference a JavaScript le higher up on the page would be if you were using document.write() to inject markup directly in the Web page.
Using localStorage as a Browser Cache As discussed in the Essentials section, using the Expires header is the best and simplest way to cache static assets in the browser. But big Web brands such as Google and Bing are now turning to a new technique, localStorage, to cache their static content in the browser. With Bing, Microsoft has reduced its footprint from 200
200 |
KB on the first file request to 30 KB for subsequent requests by using localStorage. localStorage is a part of the W3Cs Web Storage specication.42 Essentially, it is similar to browser cookies in that it enables developers to save data in key value pairs that persist in the browser even if its closed. Unlike cookies, data stored in localStorage will never be sent across the network to the server. Heres an example of how you can use localStorage right away. Suppose we want to load jQuery out of localStorage. When the user rst loads the Web page, we check to see whether jQuery has already been stored. If it has, then we simply get the data out of localStorage. If it hasnt, then we need to do an AJAX call to get the data from the server. Once we have it, we can push it into localStorage so that its available for future requests. We then push the code into the selected script tag, where it will be parsed.
 <script id=jquery></script>  <script> // set-up var to hold script var jqfile; // determine if the script has already been stored in localStorage if (jqFile in window.localStorage) { // it has so grab the file
jqFile = window.localStorage. getItem(jqFile); } else {
42. smashed.by/w3webstorage
BY DAVE OLSEN
201
// it hasnt, AJAX call to get the data from the server jqFile = getJQFile(); // push the data into localStorage
window.localStorage.setItem(jqFile ,jqFile); // insert the JavaScript into the appropriate script element document.getElementById(jquery).text = jqFile;
</script>
Easy, right? Note that localStorage can only store strings. This means that you can only cache an image if youve saved it as its Base64 string equivalent. localStorage is very easy to implement. I expect more and more JavaScript libraries and websites to take advantage of this feature. In the meantime, you can try it out by using a small library such as the Memcache emulator lscache43 or the script-loader basket.js.44 The former was written by Pamela Fox and enables developers to set an expiration time for items stored in localStorage. The latter was written by Addy Osmani and is a proof-of-concept script loader that caches downloaded JavaScript les.
Lazy Loading JavaScript If you have a JavaScript-heavy mobile website, consider implementing a lazy load technique to reduce its startup time. When a browser downloads a JavaScript le, it is also parsed and executed. As discussed earlier, the browser will block the rendering of the Web page until this process is done. In most cases, you probably dont require all of your downloaded JavaScript to be parsed and executed
43. smashed.by/lscache 44. smashed.by/basketjs
202
on page load, so it could impair For me, the most disappointing feature your websites performance for of HTML5 so far has to be AppCache. Considering that a W3C community no good reason. 45 group45 is dedicated to xing it, Im Traditionally, there are two obviously not alone in my feelings. ways to lazy load JavaScript. It used to hold great promise to help The rst method, shown earus address Web performance issues, lier, uses JavaScript to insert but it has never lived up to it. One script tags into a documents issue is that you cannot see any new <head> tag. The second methles added to the AppCache until od utilizes XmlHttpRequest after the page reloads, requiring the to download and evaluate entire cache to be downloaded before code. The primary downside to saving it, meaning that users on slow these techniques is that a user connections might never end up with might want to access a bit of a primed AppCache. Also, Appfunctionality that hasnt been Cache is not addressable for granular downloaded yet, so the page updates. Jake Archibald does a good might appear to break or to be job of breaking down other issues with broken already. In response AppCache in his article Application to this issue, the team behind Cache Is a Douchebag.46 My advice Gmail for mobile pioneered regarding AppCache for now is simple: stay away from it. And if you decide a new way to lazy load JavaSto use it, study the issues related to cript that makes a lot of sense 4647 mobile browser cache sizes.47 for mobile developers. With Gmails lazy load technique,48 your user will rst download all of the Java-Script needed to interact with the page, so all functionality is available on page load. The difference is that much of the downloaded code is commented out, so the browser wont parse it. Whenever the user
45. smashed.by/w3xing-appcache 46. smashed.by/appcache-douchebag 47. smashed.by/mobile-cache and smashed.by/mobile-cache-sizes. 48. smashed.by/google-codeblog
BY DAVE OLSEN
203
needs a particular feature that is commented out, the appropriate snippet of code is uncommented and evaluated. When the Google team rst tested the technique, they found that loading 200 KB of JavaScript and parsing it during page load added 2600 milliseconds of loading time. For an application like Gmail, which requires only a small subset of its downloaded JavaScript at page load, this delay in rendering was not only unnecessary, but undesirable. With its clever lazy load technique, that same 200 KB of JavaScript ended up adding only 240 milliseconds of time to the page load: a tenfold increase in page loading time! Here is an example:
<html> ... <script id="lazy"> // Make sure you strip out (or replace) comment blocks in your JavaScript first. /* JavaScript of lazy module */ </script> <script> function lazyLoad() { var lazyElement = document.getElementById('lazy'); var lazyElementBody = lazyElement.innerHTML; var jsCode = stripOutCommentBlock(lazyElementBody); eval(jsCode); } </script> <div onclick=lazyLoad()> Lazy Load </div> </html>
204
This technique probably only makes sense for projects with JavaScript-heavy mobile websites on which developers have done a good job of compartmentalizing their JavaScript.
The Two-Click Social Widget In the fall of 2011, German online magazine Heise rolled out a new set of social media icons. The difference between the new icons and old ones? The user is now required to click twice to Like a story, Tweet it or +1 it. Heise loads its own small icon by default, and loads the Facebook, Twitter and Google+ social widgets only when the user explicitly chooses to take that action to share the content. The primary purpose of this move was to make sure that social media networks cannot track their usersthereby keeping Heise in compliance with EU and German privacy laws. The technique has more applications than just addressing privacy concerns, though. This technique would work well with RWD for two reasons. First, it obviously cuts down on bandwidth usage. For example, at the moment of writing, Facebooks Like button requires approximately 120 KB worth of JavaScript and HTML. Secondly, it cuts down on latency. The Like button requires four separate requests, with each affected by our mobile network latency bottleneck. By cutting out the social media button overhead, Heises two-click social widgets49 go a long way to speeding up the initial page loading of content, while still allowing users to share content if they choose to. Embedding Images and Fonts Using the Data URI Scheme In my opinion, one of the most useful features implemented in modern browsers is the data URI scheme. It might be the most underutilized feature actually. The data URI scheme enables developers to embed binary data, such as images and fonts, directly in their Web pages and style sheets. The latter is shown in this example:
49. The code of Heises two-click social media widgets is open-sourced: smashed.by/heise.
BY DAVE OLSEN
205
#masthead { background-image: url(data:image/png;base64;iVBORw0KGgoA AAANSUhEUgAAAQwAAAAoCAYAAAALxsQHAAA...); }
The most signicant benet of data URIs is that we can reduce extra HTTP requests. Again, were trying to avoid the latency bottleneck whenever possible. That being said, this feature is only efcient for small les (less than a few KB) and for sprites that you use across all breakpoints. The Base64 encoding thats normally used with the data URI scheme leads to embedded image les that are larger in size than linked ones. Also, by embedding images in the CSS, they are downloaded whether the browser needs to render them or not. The other important downside to this method is that your images will need to be re-encoded and embedded every time theyre changed. Assuming you use this technique only with production websites whose sprites, icons and mini-graphics dont change very often, this shouldnt be that much of an issue. The Base64 Image Encoder50 is a handy online tool for converting images to Base64 encoding. And Font Squirrel offers a free tool51 to convert fonts to Base64 encoding.
Using Sprites to Concatenate Images JavaScript and CSS arent the only assets that we can concatenate to reduce the total number of requests. Of course, we can also join images together into sprites. Usually, using sprites is a good idea when either of the following is true:
50. smashed.by/base64-image 51. smashed.by/fontsquirrel
206
A set of images is always loaded together (for example, a set of
icons for actions in a Web application that need to be loaded together as a sprite);
Very small random images would, on their own, cause a lot of
overhead per request. Also, try to sprite images based on color palette. Basically, only sprite together images that share the same 256 colors or fewer. If a sprite image is made up of images that dont share the same color palette, it will end up being unnecessarily large because it would be saved with the PNG truecolor type, rather than a simpler color palette. Remember, if your sprite isnt overly large, you could also use the data URI scheme to embed it in your CSS, thereby eliminating another request. To create sprites, you can use an online service such as SpriteMe or CSS-Sprit.es.52
Avoid Browser Reflow One feature that often gets overlooked when addressing a websites performance is understanding how the browser paints a website in the browser window. Your CSS, JavaScript and inline objects (such as images) all provide the browser with information on how the page should be laid out. Performance problems crop up when we try to dynamically modify the layout too much. This forces the browser window to reow and recalculate where objects should be laid out as the page is loadedthereby slowing down the nal rendering of the page. The most important thing to do to limit the number of reows is to make the DOM elements and CSS as lean as possible. The cleaner the DOM is, the fewer the elements that will need to be recalculated and laid out during page loading. In a similar vein, the simpler the
52. smashed.by/css-sprites-gen
BY DAVE OLSEN
207
CSS rules are, the fewer number of times the DOM will need to be modied. But one trap that is often overlooked is that modifying styles via JavaScript can have a heavy-handed effect on reowing. Take the following bit of code:
var el = document.getElementById("foo"); el.style.color = "#fff"; el.style.backgroundColor = "#000"; el.style.borderColor = "#fc0";
This is how some developers might modify style attributes in their JavaScript. Unfortunately, each style declaration causes a reow. In our example, weve reowed and blocked the rendering of our page three times. A better solution would be to simply add a class name to the element:
var el = document.getElementById("foo"); el.className = "bar";
By doing this, the page requires only one reow. The only gotcha in this scenario is if youre trying to modify styles that youve dened using an ID selector with the newly applied class styles. Because the ID declaration is more specic than the class declaration, the latter wont overwrite the styles by default. You might need to add the !important declaration in your class styles. The reow issue is also affected by the dynamic addition of elements to the DOM. For example, rather than adding list items to an unordered list one at a time, we should instead add the list items to a document fragment and then insert that document fragment into the DOM only once.
208
KeeKim Heng does a good job of explaining how to properly accomplish this in his article Speeding Up JavaScript: Working With the DOM.53
Touching Is Better Than Clicking on Mobile As shown in the previous section, not all mobile performance issues are directly related to traditional factors such as bandwidth and latency. Some issues affect the perceived performance of our websites on mobile. One example of this is the 300-millisecond delay that WebKit browsers add to the execution time of onclick events. The purpose of this delay is to make sure that the user has a chance to nish a gesture such as a double-tap before the event res. To users who are used to the lightning-quick reaction of other touch events, this delay can prove irritating when the object theyre tapping on obviously requires only a single tap. To get rid of this delay, swap your onclick events for ontouch events on page load. A good resource to learn how to make the swap is Googles tutorial on creating fast buttons.54 It goes into depth on why youd want to make the swap and provides sample code so that you can easily implement it. Go Micro and Drop Big Frameworks Just because JavaScript is not the biggest contributor to todays explosion in page weight, it shouldnt be given a free pass when looking at areas to optimize for performance. Laying the blame entirely on projects such as jQuery, MooTools and other everything and the kitchen sink JavaScript libraries is a bit presumptuous. Without a good review, its difcult to say where all of the JavaScript-related weight has come from. That being said, developers should think critically about how theyre using these libraries and about whether smaller, more effective libraries are out there.
53. smashed.by/javascript-dom 54. smashed.by/fast-buttons
BY DAVE OLSEN
209
If you use jQuery merely as a selector tool (for example, $('element')), then you might want to consider libraries such as Zest and Qwery, which are designed specically for this task. 11 KB (versus 93 KB) can make quite a large difference to the overall weight of a page. Quite a number of these micro-frameworksavailable on Microjs55are focused and small (much smaller than 11 KB even) and might satisfy many of your needs. But page weight isnt everything, and there is another benet to using a micro-framework. As we discussed in the lazy load section above, when a browser downloads a framework like jQuery, the browser must parse it so that other scripts can use its functions. This parsing takes time and blocks the rendering of the Web page. By using a (literally) smaller framework, we can reduce the impact of this blocking. For instance, Stoyan Stefanov found that a microframework such as Zepto loads 56 times faster than jQuery on an iPhone 4 running iOS 5.1.1.56 Be critical when reviewing your JavaScript needs. The 11 KB selector micro-framework itself might be overkill, if document. getElementById()is all you really need.
Rethinking Mobile Optimization for RWD

While all of these traditional techniques, and even some of the newfangled ones, improve performance with RWD, they still dont necessarily address the dark matter of unnecessary styles, scripts and, most importantly, images. They also dont deal with the underlying structural performance problem of responsive design: that is, delivering to the end user a single dumb page of markup that may be loading third-party ads and social widgets or rich media such as video. The techniques outlined above will help to alleviate these performance issues, but they dont really solve them.
55. smashed.by/microjs 56. Stefanov, Stoyan. JavaScript Performance Patterns, smashed.by/javascript-patterns.
210
There is a new technique that can help us better address these issues. Rather than rely completely on the browser to determine which elements to show and which to load, we can resurrect a method that has been used forever to deliver mobile-friendly content.
INTRODUCING RESS: RESPONSIVE DESIGN + SERVER-SIDE COMPONENTS
Lets start with a case study. RWD has become the go-to mobile solution at West Virginia Universitya project that we have worked on recently. Its benets are obvious: the website will have one URL for mobile and desktop content; it tends to play well with content management systems; and the content manager is able to effortlessly deliver mobile-friendly content. Its easy on our clients and, for the most part, easy on us. That said, as Ive deployed complex responsive websites, Ive found that RWD presents its own challenges. Its also obvious that Im not the only one who runs into these problems. Every day you stumble upon new ways to smoothen out some of the rough edges of implementing websites with RWD. After seeing Stephanie and Bryan Riegers talk, Adaptation,57 at Breaking Development in September 2011 and playing with their Prole tool58 and, most importatly, learning that 82% of Alexas top 100 properties still use server-side detection to modify some amount of their content,59 I started to believe that maybe there was a different way to deliver responsive websites. The clincher for me, though, in deciding that server-side detection still holds value and can be combined with RWD was Luke Wroblewskis article RESS: Responsive Design + Server Side Components.60
57. smashed.by/slideshare-adaptation 58. smashed.by/github-prole 59. Cremin, Ronan. Server-Side Mobile Detection Used by 82% of Alexa Top 100 Sites,
CircleID, 11 Jan 2012, smashed.by/circleid. 60. smashed.by/ress BY DAVE OLSEN | 211
The principal concept that I found so intriguing in Lukes article is the following (emphasis added):
In a nutshell, RESS combines adaptive layouts with server side components (not full-page) optimization. So a single set of page templates dene an entire Website for all devices but key components within that site have device-class specic implementations that are rendered server-side.
Luke is suggesting that our overall layout may be governed by conventional RWD principles, but that, before sending it to the browser, we can intelligently insert small bits of customized content in the layout where appropriate. That way, the nal markup is as optimized as possiblethus combining responsive design and serverside components, as Luke describes the technique. The beauty of RESS is that, rather than forcing developers to choose one technique or another, it attempts to combine the best of both worlds. This enables developers to create unique and exible solutions by changing markup order, media and even functionality, making the most of the capabilities of the requesting browser. So, how would a website developed using RESS work?
AN EXAMPLE RESS SOLUTION: MODIFYING LAYOUT
The performance issues I keep returning to again and again are those related to images. RESS is the perfect tool for addressing these concerns. At its simplest, RESS can help you deliver le sizeoptimized images, but it can also be expanded to deliver completely different layouts and images when customized advanced content design is required. Lets look at a very simple example that addresses the latter use case.
212
The Problem Suppose a client has asked us to develop a website that prominently features three images that they want to be able to swap out on their own after launch (see the image below). The website is required to be mobile-friendly. Heeding the clients wishes, weve developed a design that does, in fact, feature three large images, and weve used responsive markup so that the images scale across various screen sizes. This has introduced two problems, though. The design calls for us to deliver desktop-sized images to mobile devices, which is suboptimal for performance (given the downloading and scaling issue we identied earlier), and because weve had to stack our layout so that the three modes of transportation remain highlighted according to our clients wishes, the page is feeling long. The client has directed us to rectify this.
FIGURE 5.8. Our desktop (left) and mobile (right) mockups.
With those constraints, weve developed two mockups. On the left is the traditional desktop mockup. On the right is the mobile mockup with the adjusted choreographed contentthe three other images of different sizes. Once theyre approved, we will obviously need to create different markup and templates for each. The thing is that the markup is really only different in that small bit involving the images. So, how should we go about delivering our responsive design with the markup for the images and with the images themselves, altered
BY DAVE OLSEN | 213
based on screen size? We have two options for the half of RESS dealing with server-side components: traditional browser detection, and the new kid on the block (discussed further below): server-side feature detection.
BROWSER DETECTION ISNT THE DEVIL
Upon hearing the suggestion that browser detection is a viable mobile solution, Im sure many of you (or at least more than several) are thinking that I cant be serious. Hasnt it been settled that useragent snifng is unreliable? Feature detection is the best solution! The fact of the matter is that browser detection is a tried and true technique when used for general browser classication. Is browser detection infallible? No. Should a browser-detection library be updated regularly just in case? Yes. Despite all the talk that keeping up with the user-agent strings for new browsers on the market is an arms race, feature detection can be plagued with a similar issue. For example, as of this writing, WebKit and Opera each has its own prefixed version of min-device-pixel-ratio that it implements differently (using the formats 1.5 and 3/2, respectively). Mozilla supports its own prexed version of min-device-pixel-ratio, which matches the WebKit version, but its moving to a new method, min-resolution, which Internet Explorer also supports. So, just as with browserdetection libraries, developers will need to maintain and update their feature-detection tests to stay on top of the latest changes to browsers. That being said, the most important criterion in determining the success of either browser detection or feature detection is not in how well either performs its particular type of detection without regular updates, but rather in how each fails and how a website handles that failure. One of the advantages of RESS when using browser detection is that, even if a browser is misclassied, the
214 |
fallback to the default responsive view shouldnt be so terrible that features are unworkable when presented to the end user. From commercial vendors like DeviceAtlas61 and 51Degrees. mobi62 to open-source projects like WURFL63 and the library that I contribute to, ua-parser,64 we have quite a few options to choose from that are proven, robust and continually updated. But browser detection isnt the only way to decide which template to deliver when using RESS. Server-side developers can also leverage feature detection to make that determination.
TAKING FEATURE DETECTION SERVER-SIDE
While WURFL can be used simply as a browser-detection library, it also offers a wealth of data on mobile devices. For example, a developer could use it to customize a mobile experience based on the availability of the Geolocation API for the visiting device. That said, WURFL tracks only so many device features. As noted earlier, it also requires periodic refreshing to ensure the data is up to date. There are good reasons why feature detection is now seen as the proper way to interrogate browsers. One interesting question that WURFL brings up regarding feature detection, though, is how often do we really need to run feature detection? In his article Cutting the Interrogation Short,65 Alex Russell suggests, Feature tests should only ever be run when you dont know what [user agent] youre running in. Essentially, for any particular version of a browser, the vast majority of the browsers features should not change from user to user. Rather than using feature detection on every page load, we could instead run those tests only once per browser session orto extend the conceptrun
61. smashed.by/deviceatlas 62. smashed.by/51degrees 63. smashed.by/wur 64. smashed.by/ua-parser 65. smashed.by/cutting-short
BY DAVE OLSEN
215
the tests only once per unique user-agent string, and then store that information on the server for later retrieval, to be used in our serverside code. Thus can we use server-side feature detection.
The Simple Server-Side Feature Detection Example: ServerSide Breakpoints One of the primary uses of media queries today is to provide breakpoints for RWD. For example, if a particular viewport is 380 pixels or narrower, then the developer might want to show a particular set of styles to make their pages more touch-friendly or to alter the layout in some way. Using that same viewport information, we could also enable the server to decide what type of markup to send or what kind of features to enable. Server-side breakpoints are very easy to set up. The rst thing well do is write a cookie, using JavaScript, that tells us the current width of the window. We need to do this only for the rst request. After weve gathered this information, we can redirect the user so that our server-side code is able to take advantage of the information.
var width = (window.innerWidth > 0) ? window.innerWidth: screen.width; document.cookie = "sitewidth=" + width; document.location.reload();
Im using PHP for this example, but any server-side language that can read a cookie and set a session is capable of taking advantage of this technique.
if (isset($_COOKIE["screenwidth"]) { } $_SESSION["screenwidth"] = $_COOKIE["screenwidth"];
216
With the screen width in hand, we can modify parts of our markup and include different types of templates.
if ($_SESSION["screenwidth"] <= "380") { include("includes/mobile-nav.inc.php"); } else { include("includes/desktop-nav.inc.php");
} For example, we could include templates for our transportationrelated images, thus addressing the problem we encountered earlier. While the session cookie makes for a very simple solution, it does require a reload for any visitor coming to your website who doesnt already have a browser session open.
The Robust Server-Side Feature Detection Example: ServerSide Modernizr Screen width is only so reliable when it comes to deciding on support for browser features. Having a large number of focused tests would help us make more informed decisions. One tool that many front-end developers use to directly test browser features is Modernizr. As pointed out by Alex, do we really need to run our Modernizr tests on every page load? James Pearce pioneered the use of Modernizr66 on the server in 2010 when he released his PHP library, modernizr-server.67 Using modernizr-server as a base and combining it with ua-parser,68 a browser-detection library, I released my own server-side Modernizr implementation, Detector,69 in January 2012.
66. smashed.by/modernizr 67. smashed.by/modernizr-server 68. smashed.by/ua-parser 69. smashed.by/detector
BY DAVE OLSEN
217
Detector is an attempt to realize Alexs suggestion. At its simplest, it uses Modernizr to prole each unique user agent that visits a website, stores the information on the server and then gives the serverside code access to the information. Future requests from browsers with that user agent can then rely on the stored data. A very simple way to use the Modernizr data server-side would be to present a YouTube video on the page according to browser support.
require("lib/Detector.php"); if ($ua->video->h264 || $ua->video->webm) { print $html5Embed; // YouTube's <iframe> code } else { print $simpleLink; }
In this simple example, weve use the video property to decide which type of YouTube video the end users browser supports. Alternatively, we could use it to solve our image template problem from earlier.
require("lib/Detector.php"); if ($ua->screenattributes->width > 320) { // our images for screens larger than 320px include("templates/desktop_images.html"); } else if ($ua->csstransforms) { // our art-directed images for 320px devices with a modern browser
include("templates/mobile_advanced_images.html"); } else { } // text links for basic mobile devices include("templates/mobile_basic_images.html");
218
By combining Modernizr with a logic-less template language such as Mustache, we can build intelligent and easy-to-maintain templates easily. A much longer explanation of how to combine both is available on Detectors GitHub wiki.70 Another benet of using Modernizr is that we can easily expand and modify feature detection as appropriate. There is no need to wait and hope that a centralized library will add the feature we want to do template switching with.
Remember the Vary Header When using RESS to modify markup based on the user agent yet serving content from the same URL, be aware of two issues. The rst is that content delivery networks (CDNs) could possibly cache content for user agent X and deliver it to user agent Y. The second is that Google has a mobile bot that it uses to index pages that it knows are mobile-friendly. To address both issues, make sure your server is sending the Vary header with the user-agent option turned on. You can use REDbot to review the response headers sent by your server to see if the server is appropriately setting that Vary user-agent option. If it isnt, simply modify your Apache conguration or .htaccess le with the following:
Header append Vary User-Agent
With this single line, CDNs will properly cache your content, and Google will know to crawl your website with its mobile bot.
70. smashed.by/detector-tutorial
BY DAVE OLSEN
219
RESS IS NOT JUST A MOBILE VS. DESKTOP SOLUTION
RESS does not have to be a mobile-only solution. Yes, it lends itself to mobile-related issues, but it can be used to deliver optimized experiences to any browser. In the same way that Modernizr.load can help provide polylls to older browsers, server-side feature detection and RESS can and do offer similar capabilities. They offer a very robust platform for server-side developers who build futurefriendly websites and applications.71 That said, there is still work to do to make these solutions as robust as possible.
ALSO, RESS IS NOT A SILVER BULLET
Just as RWD is not a silver bullet for delivering mobile solutions, I dont want to give the impression that RESS is either. It has its uses hopefully as shown as abovebut it certainly has its limitations. First, there is the maintenance aspect of the solution. If your RESS solution relies on browser detection, then it can be spoofed and will require updates to capture new browsers. Alternatively, if it incorporates feature detection, especially for cutting-edge features, youll have to make sure that those detections are also regularly reviewed and updated. Secondly, as pointed out throughout this chapter, avoid latency and extra requests at all costs. Depending on the exact solution you use, RESS might break that rule by requiring at least one extra page load and redirect to set up the system. In return for a more optimized experience throughout a users visit to a website, this seems like a reasonable tradeoff, but each developer should make that decision on their own. Thirdly, depending on how complicated your templates are, your data might need to be strongly separated from the presentation. This adds another level of complexity. With many content management sys-
71. smashed.by/future-friendly
220
tems, this probably happens anyway, but if youre looking to use this with a simple website, this could add overhead. But the primary issue for methe one that will affect adoption of this technique by the majority of developersis that its a serverside solution that requires different tools and skill sets than RWD. Because the technique is in its infancy, work is required in the short term to reinvent the RESS wheel in distinct environments. At the end of the day, for the server-side developer, RESS could be a boon for delivering mobile-optimized content. For the front-end developer who has little experience with languages such as (but not limited to!) PHP, Python and Ruby, this technique wont be as easy to take advantage of.
Wrapping Up
Improving Web page performance on mobile is not rocket science. The tried and true optimization techniques of the past, such as minication and le compression, are more important than ever. Image optimization needs to come back to the fore, and, luckily, great tools exist to help with it. HTML5 techniques such as localStorage and touch events show that there are new ways to optimize our websites and pages for speed. While designing for mobile rst has become the rage, as evidenced by developers embracing techniques such as RWD, we need to start thinking about optimizing performance for mobile rst, too. The former shouldnt happen without the latter.
BY DAVE OLSEN
221
ABOUT THE AUTHOR Dave Olsen works as a do it all at West Virginia Universitys Web unit, thinking about and delivering solutions based on new technologies. Although it sounds like a clich, the most important life lesson he has learned is Just do it. If you have an idea, just try it out, even if it seems silly. More often than not itll work and, more than likely, someone else will want to learn from your failures too.
222
UX Design For Mobile

vi. vii. Hands-On Design For Mobile Designing For Touch
CHAPTER SIX
BY DENNIS KARDYS
HANDS-ON DESIGN FOR MOBILE
hats the most difficult challenge of designing for mobile? Its a question Ive found myself returning to over and over again. Ive considered the types of challenges we face: inconsistent device sizes and capabilities, quirky browsers, irresponsible responsive images and so on. What Ive realized is that all of these challenges are technical in nature. They are all resolvable problemsproblems that well eventually work out. The bigger challenge is one that cant be solved in code. This challenge will need to be solved collectively, in our minds. We carry with us personal, intelligent technology thats always connected and always with us. These devices will inevitably continue to shape how we think and behave, transforming the way we access information and interact with the world around us. So, how do we go about recognizing the huge potential of these small devices that we hold in the palm of our hand? To unlock new ways in which mobile technology can serve us and improve our lives, we need to move beyond our inherited understanding of them.
BY DENIS KARDYS
| 225
To understand something is not to be able to dene it or describe it. Instead, taking something that we think we already know and making it unknown thrills us afresh with its reality and deepens our understanding of it. For instance, suppose there is a glass here. You might know about a glass. But what if you need to design one? The moment a glass is proposed as an object to be designed, you start thinking about what kind of glass you want to design, and you lose a bit of your understanding of glass. Arrayed in order before you are dozens of glass vessels of gradually varying depths, from glass to dish. What if you are asked to clarify the exact boundary point between one and the other? Faced with the objects, youre at a loss. And again you become a little less sure of your knowledge of a glass. However, this doesnt mean that your knowledge has been overturned. Indeed, its just the opposite. Youve become more keenly conscious of glasses than before, when you understood them by simply unconsciously calling them all by the term glass. Now you actually understand glasses more realistically.1 Kenya Hara goes on to say in Designing Design that, The more rmly were convinced that weve identied an object, the less precisely we understand it. Absent design scrutiny, a concept such as mobile can feel quite tangible and clear. But examined through a design lens, its denition quickly becomes clouded. Arrayed before you are dozens of devices of gradually varying size and capability, from feature phone to tablet. Does your denition of mobile depend on a particular class of device, a viewport size or its context of use? As the people hired to design for mobile, we are responsible for dening iteven if that means explaining why the answer is, It depends.
1. Hara, Kenya. Designing Design, Lars Muller Publishers, 2008, smashed.by/hara-design.
226
Were the ones who must verbalize and visualize both the boundaries and opportunities provided by mobile. However hard it may be, communicating this to clients and team members is very important. This realistic, shared understanding of mobile is what creates the possibility for design innovation, and it could reveal yet-tobe-discovered potential in these ultra-connected, always-with-us devices. But without this depth of understanding, were doomed to remain constrained by the conventions and processes that weve inherited from other media.
FIGURE 6.1. The concept of mobile seems easy to fathomuntil we try to de-
ne it. What constitutes a mobile experience, and where or when does it end?
This chapter is about how we dene what we design. Its about the challenges we face in trying to communicate our design intentions. Finally, its about implementing and selling processes that support a realistic understanding of what it means to design with mobile in mind.
Dening the Unknown

Tempting as it may be to begin designing with what you know, there is merit in setting aside all presumptions and taking a fresh look. Many design discussions and, ultimately, decisions stem from unvalidated, inaccurate assumptions. Were all susceptible to this. When it comes to estimating how much we know, were pretty bad at it. When it comes to predicting what others know, or how they will behave, were even worse. In Thinking Fast and
BY DENIS KARDYS
| 227
Slow,2 psychologist Daniel Kahneman talks about the errors in judgment we commonly fall victim to. Some of the more common ones are the overcondence effect, which is the tendency to inate our estimation of how much we know, and the false consensus effect, which is the inclination to believe that our own behaviors are the norm and, so, to expect that others will act and think the way we would. Coupled, they induce us to blindly believe that we understand the motives and needs of our target audience. Worse still, we might feel as though were representative of the target audience, imposing our own needs and biases onto them. The harm here is that some of these innocent assumptions can set you up for a rude awakening later on, once your app or website is released in the wild. To avoid being misled by assumptions early on, expose as many unknowns as you can at the beginning of the project. Watch out for a few in particular. While misconceptions about these exist in all domains, the following are particularly nasty for mobile because they cater to our inherent biases and inherited mental models.
1. Canvas
We believe there is a standard page size on which we can base our designs.
2. Capability
We assume that most people use devices similar to, or with capabilities equal to, our own.
3. Context
We make design decisions based on edge cases, rather than realistic contexts of use.
2. Kahneman, Daniel. Thinking Fast and Slow, Farrar, Strauss and Giroux, 2011,
smashed.by/kahnemann-thinking
228
WE THINK OF THE CANVAS AS A PAGE
The paradigm of print, in which design is anchored to the determinate bounds of a page, still manages to inuence how we design for the Web, a medium that has evolved well past its infancy. To this day, I get asked by clients what the current standard width for Web pages is. Why do they ask this? Probably because we Web designers have an inglorious history of dening (and redening) for our clients what that size has been. (I confess to being quite guilty of this myself!) The proliferation of large desktop displays gave us a false sense of security. Our users were able to control their browser size and adjust windowsand even change the default resolution. On mobile, were not afforded this luxury. We cannot, regardless of any context, count on a standard predetermined screen size or pixel density. Even in more predictable environments, such as a native application for a particular device, the screen size will inevitably change as the hardware evolves. When it comes to devices, viewports come in all sizes. This issue of canvas-as-page goes beyond our inability to predict screen dimensions. The term page itself is loaded with over a thousand years of baggage. It implies a point of existence for each piece of information and an inextricable link between content and predened layout. This is an outdated model. The information we display in app and Web interfaces isnt stored on screens; its stored in databases. It can be shared and distributed across any number of views simultaneously; different devices pull the information into different containers, which are dynamically assembled into layouts determined by each environment. Trying to dene every possible permutation of content can be a futile quest. Pages must give way to systems.
WE ASSUME THAT MOST DEVICES ARE AS CAPABLE AS OUR OWN
Flash back to the year 2009. The Nokia 2700 was just released, and Nokia would go on to sell 20 million of the devices. It featured FM
BY DENIS KARDYS
| 229
radio, Bluetooth connectivity, multimedia playback, a 2 MP camera and several Web-based applications, including chat, email and a very basic Web browser. If youve never heard of this phone, no one would blame you. Most the tech worlds attention was on the iPhone 3S, with its 3 MP camera, multi-touch screen and voice control. Fast forward to today. Both of these phones still exist and are in use! If you happen to own a newer smartphone, perhaps the iPhone 5 or Nokia Lumia, these devices from four years ago might feel like worthless relics. Because of the exponential rate of technological advancement (Moores Law),3 features that blow our mind today will in short time be reduced to basic expectations at best or, at worst, become completely obsolete. For example, as location-based technology advances, well see tremendous opportunity to design smarter, more contextually aware experiences. We should pursue these possibilities, continually endeavoring to explore new methods of interaction. At the same time, we need to stay mindful that not all mainstream devices will have the same degree of sophistication. We should remain wary of designing apps and websites that depend entirely on such features when it risks alienating users of assistive technology, those with less capable devices and those who, because of fragmentation, might be running outdated versions of the native OS. Thinking to the future, we should consider not only deprecated smartphones, but also other types of less capable Internet-enabled devices. What form might they take in the years to come?
WE CONFUSE EDGE CASES WITH CONTEXT OF USE
Stop me if youve heard this one: We need a mobile app for our users on the go. Its easy to get hung up on the notion that our users are perpetually mobile. Frequently, we conclude that because a user
3. Wikipedia, Moores Law, smashed.by/moore-law.
230
might be busy and on the go, that they must be. Dont allow edge use cases to drive design decisions. Your average mobile user is not likely a distracted person using their mobile phone with one hand, standing in the aisle of a speeding train, holding a baby. Similarly, being on a non-handheld device in no way implies that the user is chained to a desk, deeply focused on interacting with your website. So, if we cant rely on either case, how do we determine the context of our mobile users? The short answer is that we cant; its an unknown. There is no way to know the environmental factors surrounding our users during every interaction. This doesnt mean were in the dark either. We can model realistic use cases and scenarios by conducting ethnographic research and directly observing our users. At the very least, try to gather information about how mobility affects the priority of tasks that people carry out. Again, dont let assumptions about a users situation lead you to presume what they will or will not do. As Brad Frost wisely reminds us, Mobile users will do anything desktop users will do, provided its presented in a usable way.
Embracing the Unknown

Believing we can predict screen size, type of device and context of use is comforting. Weve deluded ourselves into thinking that we have access to this information. In fairness, weve managed to get along pretty well so far. Weve been steadily raising the caliber of digital experiences and improving user experiences well beyond where they were just years ago. Except that, instead of platforms converging, mobile has swept in like a force of nature, fracturing any semblance of sameness in terms of where and how people rely on technology to engage with companies, products and services. The very things we dont knowcanvas, capability and context are perhaps the things we as designers crave the most. Knowing them would give us more control over the experiences we want to
BY DENIS KARDYS
| 231
enable. Letting go of these assumptions is hard; I still struggle with it daily. Acknowledging the limited amount of contextual information we have access to is scary, too. But Ive got news: if its intimidating for you, imagine how terried your client must feel. Your client, whether an external or internal stakeholder or your boss, is now confronted by the reality that you must essentially design for the unknown. What started out with the simple phrase We need an app has now become a seemingly insurmountable burden on their shoulders. In their terms, this equates to a potentially expensive project with a questionable promise of successnot exactly the reassurance they had hoped for. Can you blame them, then, for demanding extensive and incremental reviews and sign-offs at each and every stage of the project? If you can relate to this burden of the unknown, dont fretembrace it! You have become a little less sure of your knowledge of mobile. However, this doesnt mean that your knowledge has been overturned. Indeed, just the opposite. Youve become more keenly conscious of mobile than before. Now, your understanding of mobile is more realistic.
Setting Basic Expectations

Basic expectations are another form of baggage that mobile designers are plagued by. Basic expectations are the conventions we take for granted, the familiar features and processes that have been adopted so widely that we dont question them. For example, many of the tools that we use to design interfaces, such as Photoshop, originated as tools for producing print documents. When you open a new document, the rst thing Photoshop does is prompt you to set a canvas size, a step were so familiar with that we dont question it. Its no surprise then that, prompted to set our canvas, we begin to think in terms of a xed canvas. The software and its Save for Web feature then inuence us to produce static
232
| HANDS-ON DESIGN FOR MOBILE
images. We might believe philosophically in concepts such as mobile rst, but if the tools we use are inuencing us to make design decisions in a single context, and we are exporting static mockups for our clients to review, then we are reinforcing the very expectations that we need to be resetting! In other words, we must make sure that each part of our process and every deliverable that we produce set proper and realistic expectations. So, lets look at two parts of our process in which we may be unintentionally sabotaging ourselves:
1. Static design documents, 2. Assembly-line design processes.
Tell me if this rings a bell. Your UX team pours over research and user data, producing blueprints for an application. In the course of this, you continually discuss the proposed plans with stakeholders. During these skirmishes, informed recommendation battles subjective opinion, and data-driven scenarios duke it out with hypothetical use cases. Once all stakeholders have been satisced, sign-off is obtained, and the approved design documents are passed on to the UI designer or whoever is next in line. The process repeats itself, until a nished portrait of the design is approved and development can begin. A while back, the company where I work was hired to build a mobile Web app for a large enterprise technology company. The company had been working closely with its creative marketing partner for months on the design. We became responsible for the development and CMS integration. We inherited a robust stack of documents: source PSDs, annotated wireframes, written specications. The designs had been reviewed and discussed thoroughly and had made it through the clients rigorous internal approval process. Despite the design documentation being quite in depth (sometimes
BY DENIS KARDYS
| 233
FIGURE 6.2. Designs conceived in a single context often reveal
aws once they are tested in multiple modes or contexts.
granularly so), problems with the design were revealed right off the bat as we began the programming. For example, the design mockups were shown in the context of an iPhone in portrait mode. Tabbed navigation was xed to the left side of the screen, but there was no indication of how the navigation should be repositioned if the devices orientation was changed to landscape. Notes indicated that a sub-navigation panel should y out when each tab was tapped, but no cues were given as to what should happen if an item had no sub-navigation or if the panels contained more links than could t in the visible connes of the viewport. In retrospect, these considerations might seem obvious, but, in defence of the creative team, none of them were apparent in the single context that the team was designing for. All of the teams involved learned a hard lesson: even with annotation, static illustrations of a single context are ineffective at communicating something as complex and variable as the mobile environment. The linear process we were following made things even more complicated. Change orders were required in order to introduce design modications during the development stage, post-approval.
234
For many designers, me included, the scenario above is a brutally realistic portrait of the design process. Surely, there must be a better way! I believe there is, but lets start by pinpointing some particular problems with the conventional process and gure out some productive alternatives.
STATIC DESIGN DOCUMENTS SET FALSE EXPECTATIONS
From the earliest stages of design exploration, the documents we typically share to help communicate our design intentionsfrom wireframes to highly detailed renderings of the proposed interfaceare static. Because they arent clickable, tappable or resizable, interaction can only be hinted at. This means that each information architecture diagram, wireframe and PSD needs to be accompanied by succinct annotation and lengthy phone or in-person walkthroughs to describe the systems intended behavior. Consider for a moment the time and effort required by both parties to translate these documents. Its not just your time being spent trying to communicate the implied interactive properties of the design; its also the clients time trying to reinterpret them. Perhaps the biggest issue I have with static deliverables and linear processes is that they build false expectations of the design. You know how when you unwrap fast food, it never looks like the photo that triggered your appetite? The discord felt with that mismatch is the same feeling our clients experience when they make the leap from seeing a static JPG of their website to seeing it in the browser or on the actual device. Each stage of the design process achieves a higher level of delity, leading everyone involved to believe that what you show them at the end of the process is exactly what theyll see in the nished document. But unless youre showing them HTML in the browser (or natively rendered content), then its failing to reect rather major design considerations, including things such as pixel density, variBY DENIS KARDYS
| 235
able viewport size, CSS support and the annoying nuances of Web or device font rendering. When designing specically for mobile, the effects are exacerbated. Envisioning how a Photoshop document will translate to an HTML page in a desktop browser requires a fairly light amount of cognitive effort. We can map it pretty easily. But mapping a design from a Photoshop document to a handheld touch-enabled device, where only the slightest portion of the pages full content is visible at any one time, requires a bit more effort. It can generate more questions than answers. It relies too much on your stakeholders imagination. I dont know about you, but that sounds like trouble. All in all, these deliverables seem better suited to a single context than to a multi-channel, multi-layout system. They tether the design to pages and prearranged layouts, not to reusable modular components. The process plays out like a telephone game, with bits of the intended message making it through at each turn. The lack of cross-role collaboration can lead to siloed thinking and page-centric deliverables. Asking clients to imagine the interactivity makes early design decisions more likely to be based on discussions of hypothetical use.
Design As Hypothesis Any time you present a design, youre simply presenting a hypothesisyoure putting forward your guess at the best solution for the challenge at hand. Considering the number of moving pieces, the likelihood that your proposed designs will nail everything is extremely low. When changes to the hypothesis are driven by debate or personal preference, rather than by user testing or structured critique, then we risk signing off on designs prematurely. Unless your process embraces iteration, the shared goal will likely become to not make any changes! The truth is that, whether you spend three days or three months ponticating on hypothetical use cases, theres
236
really no way to tell what will work and what wont until the designs are actually testedthrough use! Unfortunately, many projects stall on hypothetical debates. How much time gets wasted by disagreement over what users might do or what users might not see? There is a gap between implied use and actual use; naturally, we ll this gap with assumptions about usage, colored by our own biases. Does this mean that all deliverables are bad, that we need to put an end to wireframing and uninstall Photoshop? Not at all. Design artifacts are still invaluable. Robert Hoekman puts it best:4 The purpose of a design artifact, whether a wireframe, prototype or sketch, is to illustrate our thinking. Regardless of what type of design document youre producing, stay focused on its core purpose in your workow and on what you intend for it to communicateequally important, make sure to clearly articulate what it isnt intended to communicate.
ASSEMBLY-LINE DESIGN PROCESSES LIMIT SOLUTIONS
On the design assembly line, every person is assigned a role and, ideally, assigned clearly dened parameters for where their work begins and ends. Although there may be team brainstorming sessions, each individual is ultimately responsible for the production of whatever deliverables are assigned to them. In this model, every task depends on the work thats been generated in earlier stages. Once design decisions are approved, the appropriate documents are handed off to the next team members. These documentswireframes, mockups, etc.become the equivalent of IKEA assembly manuals. Once theyre used, they are archived or simply discarded. Although a positive outcome of this model is the potential for clear ownership of each deliverable, ownership of the design is a little more
4. Hoekman, Robert. The Big Think: Breaking the Deliverables Habit, Smashing Magazine:
smashed.by/deliverables-habit.
BY DENIS KARDYS
| 237
amorphous. This occurs in situations in which multiple designers are assigned to different roles, all contributing to the end product. We love to champion the ideal that design is not decoration, but we designers are as guilty as anyone of assigning the role of decorator to the UI specialist, who may very well be a keen graphic designer with superior visual communication skills. Similarly, we assign the role of implementer to the front-end developer, who, chances are, might have a masterful understanding of grid systems and design as well. The further into the process each designer is introduced, the more removed from design decision-making they end up being. Lets say that users are confused by the behavior of a particular menu on small-screen devices, and your client wants to explore an alternative solution. Could the front-end developer simply swap the menu, or do any changes need to originate from the original UX designer? How far up the chain do you need to go to push through a simple design change? The front-end developer might be able to quickly take care of all the design and code that is needed. But if that happens, what does it mean for the UX designer who later nds that their plans have been altered? So, while a clear sense of territory is a positive outcome of this model, its possibly outweighed by the models rigidity, and it is not very conducive to change or cross-discipline collaboration. Because this model is based on sign-offs and hand-offs, making changes to a design that has already been approved could involve a lot of people, which translates to a cumbersome, time-consuming and expensive process. Naturally, this encourages all of the decisions to be made early on and deters changes as the project evolves, creating a funnel-shaped process.
238
DESIGN FUNNELS A design funnel is a process that loads all of the ideation into the early stages of the project, quickly narrowing multiple concepts down to whats perceived to be the most viable one. Each subsequent stage focuses on rening the initially selected design.
FIGURE 6.3. In the conventional design funnel (Pughs Funnel), the op-
tions are quickly narrowed down, and then the chosen idea is rened in each successive iteration.
FIGURE 6.4. Buxtons variation introduces the idea of alternating between con-
cept generation and concept reduction throughout the convergent process.
In Sketching User Experiences,5 Bill Buxton proposes a variation based on a simple concept: alternate between concept generation and controlled convergence. Unlike a traditional funnel, which en-
5. Buxton, Bill. Sketching User Experiences, Morgan Kaufmann,
smashed.by/buxton-sketching.
BY DENIS KARDYS
| 239
courages ideation only in the earliest phases of a project, this model embraces exploration during each stage. Concept convergence also occurs in each stage, whereby ideas are ltered down by measuring against explicitly dened design goals and principles. Controlling ideation with structured critique moves the design discussion towards actionable, productive feedback. This approach is healthy because it allows a greater number of ideas to be suggested, proposed, and questioned.6 The concept that no idea is sacred and that alternative, potentially better ideas may be introduced later in the process can only lead to a stronger product. Because the assembly-line processes that result in a traditional design funnel have to kill so many ideas before they can be explored, there is a danger that theyll come back to haunt you later. A stakeholder who is soured by the feeling that their idea wasnt given due consideration might resist alternatives or seek to work in their idea at a later stage. Buxtons variation, on the other hand, is more accommodating and ts well in a more iterative workow. So, what does all this talk about assembly lines and funnels have to do with designing for mobile? Simple: I dont believe we can front-load all of the necessary design decisions at the beginning of a project for any platform, least of all for mobile. This approach is an unfortunate remnant of industrial-era thinking, when products could be sequentially manufactured. We need to guide our clients to a shift in thinking about how we design and build software systems. We need to be able to make critical decisions about how an application behaves in the appropriate context, at different times throughout the project. In her presentation The Mobile Frontier, Rachel Hinman says, Throughout the design process, our work should be situated in the
6. If youre interested in learning how to craft effective design principles and goals, Adam
Connor and Aaron Irizarris blog, Discussing Design (smashed.by/discussing-design), is an indispensable resource, lled with tips on managing feedback and facilitating critiques.
240
contexts where it will be used.7 I agree. In the past, we may have been able to get sign-off with a picture of a website meant for the desktop and then go build it, but that wont cut it for mobile. She continues, Our work needs to be conceived of and eshed out in the real context of use. Now thats an idea I can get on board with!
MORE PURPOSEFUL DELIVERABLES
Lets step back and ask why we are spending time creating anything that is not the actual product: i.e. a mobile website or application. At a very high level, we have two major goals: to create something that satises a need of whoever will use it, and to satisfy the objectives of whoever is paying for it. In order to meet both of these goals, there needs to be a shared vision. We use design artifacts to articulate our ideas and as a tool for discussion. In Communicating Design,8 author Dan Brown cites three reasons for producing deliverables:
1. Consistency of vision
Make sure that everyone on the team is on the same page so that they can make worthwhile contributions.
2. Accountability
Make sure that everyone understands the decisions that have been made and the implications of those decisions.
3. Traceability
Track the collective history of decisions in the project, to serve as a reminder of the design rationale at crucial points in the projects evolution.
7. Hinman, Rachel. The Mobile Frontier, Breaking Development Conference, April 2012:
https://vimeo.com/44265965. 8. Brown, Dan. Communicating Design, New Riders, smashed.by/comm-design. BY DENIS KARDYS
| 241
If we consider interactive prototypes, I would add a fourth item:

4. Validation
A deliverable acts as a proof of concept, validating or disproving design decisions. Using these as a guide, we can start to make more rational decisions about what types of design documentation to use for different types of projects. A native application and a responsive website would likely need drastically different sets of deliverables, even though a person might access both through the same device. We can now measure documentation against slightly more formal criteria: What is the purpose of this deliverable? What is it intended to communicate? And which communication goal does it satisfy?
Every Design Deliverable Should Have A Core Purpose When design deliverables get a bad wrap, its usually because too much is invested in them. I am a rm believer in doing the least to communicate the most. Time and again, I see needless documentation listed as a requirement in RFPs, or I see painfully bloated deliverables produced to satisfy a fools quest to solve every single problem up front. For example, how many times have you seen a project slow to a crawl because wireframes were burdened to serve too many different purposes? Ive seen wireframes that serve as a specication document for content, layout, interface patterns and interactive behavior. In a funnel where any deviation from the approved document requires a change order or is met with resistance, is it any wonder that every element of the design is scrutinized under a microscope? Lets start by demanding that each document were tempted to produce can justify its own existence. Then, lets set some clear boundaries for what that document should dene and what it
242
should merely suggest. By articulating the core purpose of a document, we narrow the focus of the conversation surrounding it. Anything indicated in the document beyond whats dened as its core purpose is simply a cuea suggestion that will do until a better alternative is revealed. Youll nd a lot of articles about process and workow, but the reality is that none may t your exact needs. Instead of preaching about what to do when planning the mobile user experience, Ill cover some techniques and tools that weve found useful, and Ill establish criteria for when and why to use them. To begin, lets categorize them:
Concept generation
Figuring out what to build Content planning Figuring out what information to show Designing and rening Working out the interface(s)
Concept Generation
To develop any sort of mobile application, you need to begin by conceptualizing what you should build: what will this product do, and who should it serve? Basically, you need ideas, and, fortunately, everyone has those! When youre starting a new project, although it might feel like youre starting with a blank canvas (or viewport), you really arent. You cant see it, but that canvas is lled with expectationsincluding your own! The point of concept-generation techniques is to bring all of those ideas and expectations to light, sucking them from the minds of all involved parties and materializing them in a way that exposes them to discussion and critique. So, when we look at methods and tools for concept generation, we can dene a couple of their core purposes:
BY DENIS KARDYS
| 243
Generate as many ideas as possible.
The ideas generated need not all be viablesome may be entirely implausible. The point is to shoot for the maximum number of ideas. Bad ideas are sometimes stepping stones to great ones. In line with Bill Buxtons variation on the design funnel, the more concepts you have to explore, the better equipped youll be to help realize the projects potential. Because you are looking for quantity over quality in ideation, you certainly want to include as many different informed perspectives as possible. Youll have opportunities for controlled convergence later.
Break existing mental models.
The invisible expectations described above are actually mental models. Theyre a persons mental image of how something will work or function, and theyre based on that persons prior experience with similar systems or devices and on their assumptions and biases. Mental models start to form from the moment that team members begin to envision the project. As planning and discussion go on, the mental images become more dened. This can lead to situations in which you nd yourself designing for whats in the clients head, instead of designing for the projects goals and the users needs. In order to get people to accept new ideas, you need to exorcise the old ones. This is where sketching comes in. We often think of sketching as a way to generate and communicate ideas, but it can also be a weapon to dismantle them. The goal of sketching in this case isnt to produce drawings that inform the nal design; we are not replacing the internal UX process. The goal is to drive out those stubborn, thorny ideas and make room for new ones. Only then can we look anew and achieve a deeper understanding of what were designing.
244
FIGURE 6.5. Sketching is a powerful way to exorcise festering ideas that
could derail a design later on.
SKETCHING TECHNIQUES
Two excellent lightweight activities for simultaneously exploring new concepts and purging ideas that can lead a project astray are sketching and paper prototyping. In Drawing Is Thinking, Milton Glaser says, Art seems to affect us beneath the surface of our rational or logical mind. It basically moves the mind to action on a different
BY DENIS KARDYS
| 245
level, one that is more profound and less describable.9 He goes on to suggest that drawing is a form of meditation and that it brings the drawer to a greater state of attentiveness. This state of focused attention is what I believe makes sketching such a powerful tool for ideation and communication. Mental models, especially those that pertain to visual interfaces, can be quite difcult to articulate verbally. There is a much freer connection between the hand and the mind, however, which facilitates the translation of ideas from mind to paper. In these cases, a picture truly can be worth a thousand words. The ability to sketch, though, is not the same as the ability to render. With just a few basic shapes and symbols, anyone can develop their ability to sketch. Designer Peiter Buick has written a fantastic article on sketching technique, titled The Messy Art of UX Sketching,10 lled with useful information for both those new to sketching and seasoned pros.
COLLABORATIVE SKETCHING
While sketching can certainly be a solitary, meditative ideation activity, it also works well as a collaborative brainstorming exercise. Group sketching facilitates the rapid exchange of ideas between team members, providing opportunities for immediate feedback. Although the participants in a sketching workshop might not think of themselves as artists, this depth of focused consideration of the design challenge is crucial. Below are some group sketching exercises that have been particularly helpful in reframing how we think about mobile and device-agnostic design.
9. Glaser, Milton. Drawing Is Thinking, Overlook Hardcover, smashed.by/glaser-drawing. 10. Buick, Peiter. The Messy Art of UX Sketching, Smashing Magazine:
smashed.by/sketching.
246
Stick-Figure Comic Strips

Stick-gure comics are simple to do. Break your group up into teams of two. Give each team a piece of paper lled with square panels, and ask them to draw a crude comic that depicts a member of the target audience opening the website or app and completing an activity. We used this technique recently when planning a responsive redesign for a university website. To give our burgeoning cartoon artists a little more direction, we specied, Begin your comic strip with a character who is representative of your target audience. Your characters story does not begin on your website (or in your app). Think of a place where the story begins. What motivates them to visit your website, and what actions do they take when they get there? What device are they using?
FIGURE 6.6. Drawing comics is a fun way to imagine new scenarios, whimsical
though they may be.
In the university workshop, one team described the story of a teen who is at a coffee shop talking about colleges with her friend. At her friends suggestion, she pulls up the universitys website on her
BY DENIS KARDYS
| 247
smartphone and explores. She bookmarks the URL and retrieves it later on her tablet, doing a little more research and then, noticing an upcoming group tour date, registering for a visit. Weeks later, while visiting the campus, she uses her phone to take photos and share them to her Facebook page, asking others in her network what they think of the university. These storyboard-type comics are great because they make people turn lists of needs and objectives into narratives. Layers of abstraction peel away as participants give detailed accounts of how they envision individuals using the website. This also moves the conversation in the right direction: instead of focusing on how to arrange content so that it ts on a tiny (or medium or large) screen, they start thinking about behavior. What particular activities do they want to encourage? What situations do they want to account for? In the example above, instead of thinking about a user completing a task in a single session or context, the team describes a scenario in which the website connects experiences in the characters life that span multiple locations, devices and applications. This type of cross-channel experience is precisely what we want our clients to think about in these exercises.
Sketching Task-Based Interactions The scenarios described in the comic-strip exercise usually get stakeholders excited about the prospect of purposeful interactions with the website or application. Suddenly, instead of a faceless visitor, weve got pages of sketches of people with names trying to complete actions. Its a great time to investigate the following question: What activities do you want your website to support? Ask your group to come up with a short list, focusing only on critical activities. Out of those, select one to work on (you can come back to the others, or you could simply take note and explore them with the rest of your design team as part of your internal process).
248
Typically, a single activity, such as register for an event, comprises multiple tasks. Identify those tasks, and list them somewhere for everyone to see. If youre building a native application, your sketched template should mimic the hardware and screen proportions of the device its being designed for. In the case of a mobile Web app or responsive design, you can use a standard 6-up template or download mobile sketch templates, which are freely available.11 (For the more serious sketcher, UI Stencils12 sells pads of mobile templates and drawing stencils.) Give each person ve minutes to sketch the different views needed by a user to complete the interaction. Five minutes, you ask?! The extremely short time seems completely unrealistic, Ill admit. In fact, when participating in this exercise, I almost never complete all six sketchesand thats OK! When the purpose of a sketching exercise is to ideate, keeping the time limit tight is advantageous. Paradoxically, the more time you give people, the harder they think, causing them to censor their ideas more. Tight time constraints encourage participants to quickly put down any idea that comes to mind. After the time is up, dont dive into discussion. Instead, immediately pair up each participant, ideally with someone who they dont work closely with on a daily basis. Ask each person to spend a few minutes reviewing their partners ideas, and then spend the next 20 minutes or so collaborating on a new, more detailed sketch that outlines the activity and sub-tasks. Once all of the teams have completed this, go around the room and give each team three minutes to present their concept. Keep the time for feedback equally short (three to four minutes), to keep the conversation on track and to remain focused on critiquing rather than ideation.
11. UX Sketching and Wireframing Templates for Mobile, Smashing Magazine:
smashed.by/templates-mobile. 12. smashed.by/uistencils
BY DENIS KARDYS
| 249
Creating Sketchboards Sketching workshops can generate an immense quantity of ideas in a relatively short amount of time. What do you do with them all? As people present their ideas during the course of the workshop, we have them tape them up to a large wide sheet of paper pinned to the wall. This sheet is our sketchboard. As participants critique, we add notes directly onto the paper. At the end of the day, you can just pull down the sketchboard, roll it up and bring it back to your team for discussion. As with all group sketching, the purpose isnt to replace your design team or UX teams responsibilities, but to share knowledge and contribute new ideas to the pool.
PAPER PROTOTYPES AS A VALIDATION TOOL
Sketching exercises generate a lot of ideas. Confronted with a wall full of sketches, youll probably have your personal favorites, and other stakeholders will likely have their own. Assuming youre not going to move forward with every appealing idea, youll need some type of controlled convergencesome way to lter the ideas. This is when an extremely versatile tool such as paper prototypes comes in quite handy. If youre not familiar with them, paper prototypes are cut-out paper models of your website or application, usually with repositionable elements. When I rst learned about them, I made the mistake of writing them off, assuming they were impractical and less effective alternatives to HTML prototypes. I changed my tune after seeing them in action. When youre designing for mobile, paper prototypes offer some serious advantages over other forms of prototypes, such as sketches, wireframes and HTML. These advantages include the following:
People can actually pick up, hold and interact with paper mod-
els.
250
FIGURE 6.7. Paper prototypes are an easy way to test ideas in the eld. They
enable you to make changes quickly based on immediate feedback.
Theyre portable, freeing you to test and validate design deci-
sions in the eld. Paper prototypes are easy to alter, allowing for immediate changes based on user feedback. We recently had an opportunity to redesign the intranet for an airline in Canada. Pilots and ight crew, we learned, carry around heavy dufe bags lled with tiny laptops and bulky ight manuals and folders of paperwork that they need to ll out prior to ying. Mobile is changing the way they work, as manuals are transitioning from paper to electronic format, and their required ight forms can be lled out and submitted online. The airlines intranet is the hub for these tasks. They also spend a lot of time waiting in airports and lodging overnight in hotel rooms in various cities away from home. Booking hotels, bidding on shifts, checking memos: they
BY DENIS KARDYS
| 251
need to be able to access the intranet from anywhere and everywhere. Carrying around tiny laptops certainly does not dene their futuremobile technology does. Meanwhile, the same intranet is being used by maintenance workerspeople on the oor in hangars repairing jets. Some of their procedures are routine, such as changing tires on planes. For these routine tasks, many of the workers have printouts that they carry around every day to refer to. When an unusual incident occurs, such as when they detect an unfamiliar leak, the worker needs to leave the oor and nd a shared work terminal where they can look up the appropriate procedure. How could mobile access change the way these people work? We spent an afternoon with the project team, doing rounds of sketching exercises. We had a lot of ideas about what might work for the pilots, ight attendants and maintenance crew. We also recognized that assuming that our ideas were the right ones would be extremely naive. Quick paper prototypes helped us move from brainstormed sketches to tangible artifacts that we could use to validate our ideas in interviews with our target audiences. Using paper prototypes was extremely liberating here. We had the advantage of being able to eld test without getting bogged down by technical issues related to, say, the interviewees device or Internet connectivity. Instead, we were able to focus on how each person might complete the task at hand, and even pick up cues on the more ergonomic aspects of the design.
Making Paper Prototypes Creating paper prototypes can be quite easy. The easiest way is simply to take some bristol board or heavyweight card stock and create a sleeve, cutting out a frame for the viewport. Keep the top and bottom of the sleeve open so that you can slide longer sheets of paper (the screens) up and down through the sleeve. You can sketch
252
the interface directly on the screen, although youd have a more useful tool if you broke up the content into individual components and adhered them to the page with a low-tack adhesive such as StudioTac, which is available at most art and hobby stores.
12cm.
14.5cm.
Starting with a heavy cardstock cut out the device along the solid lines.
Fold along the dashed lines, adhering the flap to the backside of the prototype.
account ID
password
sign in
Add any important hardware controls or other device specific details.
With users, slide interface mock-ups into the window, testing different screens, flows and application states.
FIGURE 6.8. Building paper prototypes is not as daunting as it seems. You can
make one in no time with some common supplies and in a few simple steps.
StudioTac has enough tack to keep your items in place, while remaining repositionable. You could also simply use tape or even sticky notes. If you arent the handiest person in the world, the UX-
BY DENIS KARDYS
| 253
FIGURE 6.9. Interface Origami, a simple technique to recreate common interactions in
native and Web applications.
Pin Mobile Kit for iPhone13 provides a notepad of iPhone templates, along with a collection of generic UI elements on sticky paper, making prep time much quicker than if you were to build each kit yourself. If you feel like youve graduated beyond simple cut-and-pasted paper prototypes, Juan Sanchez of Tack has written an article titled Interface Origami,14 describing ways to recreate complex paperbased interactions that mimic conventional design patterns (such as accordions) and gestural interactions (such as swiping, pinching and zooming).
Content Planning and Information Architecture

In a perfect world, wed all be working alongside content strategists in each project. But that is simply not the case for many of us, for whatever reason. Whether there is a strategist or not, your project still needs content, and your client still wants to preview it before committing to approval. When a project lacks formal content
13. UX Pin Mobile Kit for iPhone: smashed.by/kit-iphone. 14. Sanchez, Juan. Interface Origami, smashed.by/origami.
254
strategy documents, such as inventories and page tables, the burden of communicating content decisions is placed on other deliverables. As those requirements sneak silently into other design documentation, the latters purpose is confused. Im sure weve all seen cases in which wireframes end up picking up too much of the slack of communication. The wireframe becomes the focal point of conversations about content, labeling, navigation structure, layout, interactive states and even task ows. When a single deliverable is left to resolve so many things, it becomes more and more massive, and discussions surrounding it seem to go on forever. For the sake of approval, our sanity and the future, we need to put more emphasis on managing and prototyping content, independent of layout systems and interaction diagrams. Without digging too far into the realm of content strategy, we can identify a few types of deliverables that will help us communicate what content needs to be shown and how that content will map to different templates and devices.
PAGE TABLES
In Content Strategy for the Web, Kristina Halvorson describes a page table as a Word document or other text le that tells you everything you need to know about the content on a specic website page (or content module)from the objective and source content to the content recommendations and their implications, including requirements for creation, delivery and maintenance.15 Essentially, what you are doing is liberating content from presentation, which, as it happens, is a rather future-friendly strategy. Lets say your client is a global provider of machine parts for heavy-equipment manufacturers. Their parts catalog, knowledge
15 Kristina Halvorson, Content Strategy for the Web, smashed.by/halvorson-strategy.
BY DENIS KARDYS
| 255
base, specication documents, videos and corporate information need to be distributed across many channels. Their content needs to be available on the Web in a format accessible to a wide range of (mobile) devices. In order to avoid duplication of effort in the
FIGURE 6.9. Page tables are a tool for planning how to adapt content to different
device types and screen sizes.
256
creation and management of content, you will need to make pieces of this content reusable, shared with native product-nder applications designed for the iPhone and iPad. Within a year, another version of the application will be deployed to support Android. Without content strategy documents such as inventories and page tables (as well as some system for content management), the majority of your information architecture decisions could end up being made specic to a device or screen size. Decisions about what information to show will conveniently and almost magically seem to match the amount of visible space available on that particular device. Weve seen this tendency manifest itself in the stereotypical mobile website, where the smaller screen seems to urge people to present smaller amounts of content. Correct me if Im wrong, but Im pretty sure that no studies have shown any direct correlation between a persons situational goals or information needs and the size of their mobile device! Its precisely for this reason that we need to evaluate content and the priority of information objectively, beyond the inuence of any one platform. This isnt to say that platform considerations dont come into playthey denitely do. In the example above, imagine how you might handle a product listing page. On a device with a large screen, you might have room to display the products title, a medium thumbnail and a 200-word description. On a smaller screen, the lengthy descriptions might be cumbersome, so showing only a brief 225-character description might make more sense. But a truncated description would not likely be of much use to anyone. Page tables can aid in the process of planning how to structure, input and deliver your content in a way that adapts intelligently to a range of platforms and screen sizes.
BY DENIS KARDYS
| 257
CONTENT REFERENCE WIREFRAMES
If a page table represents the available content and its objectives, then a content reference wireframe exists as the key that maps content to the different contexts in which it will appear. Stephen Hay compares these to thumbnail sketchesexplorations of what should go where. A content reference wireframe is nothing more than a crude approximation of a page, comprising gray boxes with labels that refer to different content items. These boxes are roughly positioned to indicate their general placement on the screen. Because they are quick to produce, you can easily explore variations in layout resulting from breakpoints, device state and application state. Essentially, these are ultra-low-delity wireframes whose core purpose is to communicate and validate what content should be present on individual screens in the website or application.
FIGURE 6.10. Youll have plenty of opportunity to ne-tune the details of the interface
later. Content reference wireframes can be used to map content to templates, allowing you to focus on what content to show, rather than on its exact presentation.
258
Page tables and content reference wireframes are just two of many different types of documentation you might use to plan the content and information architecture. Im not bringing them up here to paint the ideal workow (Stephen Hay does that pretty well in his chapter in Smashing Book 3, Workow Redesigned: A FutureFriendly Approach),16 but rather to demonstrate the value of keeping deliverables (and design decision-making) focused on one area at a time. With consensus gained on what information should be displayed in an interface, you the designer have a lot more leeway to suggest which tool makes the most sense to develop the design with: whether it be higher-delity wireframes, interactive HTML prototypes or something else entirely.
TO WIREFRAME OR NOT TO WIREFRAME?
Earlier I mentioned problems with static deliverables such as wireframes. Does this imply that they should be nixed from the design process? Certainly not. Instead, consider the criteria you use to determine whether, when and how much to wireframe. Wireframes are one of those basic expectations that exist in the conventional design process. But they are easily abused when their purpose is not clearly dened. When dealing with an enterprise client, for example, a design team might be required to create highly detailed wireframe decks with hundreds of pages. However, that level of detail would confuse the client about the type and breadth of feedback that the team is soliciting, making the line between what should and should not be critiqued extremely fuzzy. Lets set aside the issue of client-mandated design documentation for a moment and examine the end deliverable. Under what circumstances, if any, does it make sense to invest that amount of resources into creating that many annotated pictures of boxes and arrows?! In
16. Hay, Stephen. Responsive Workow: A Future-Friendly Approach, Smashing Book 3, Smashing Media, 2012, smashed.by/smb3. BY DENIS KARDYS
| 259
his article Ditch Traditional Wireframes,17 Sergio Nouvel explains the cost of this:
At this point, lots of design hours have been invested, and chances are that almost none of the underlying decisions have been properly validated with users: incremental steps done in delity. You are basically performing (and sweating) work that is very likely to be completely undone when user feedback arrives.
Wireframing For Responsive Design Mobile view, tablet view, desktop viewwireframing can easily get out of hand when you are planning a design that is intended to display differently across multiple devices. Showcasing content hierarchy and position can quickly become a daunting and timeconsuming task. Depending on the number of breakpoints in your design, each page could end up requiring three or four unique layouts. Its easy to see how wireframe decks become so bloated. An alternative here would be to start thinking about precisely what needs to be shown in order to communicate layout. For a website with hundreds, even thousands, of pages, trying to create a static representation of each page layout and breakpoint variation is impractical. So, why do we still sometimes do it? On the one hand, you most likely have very interested, invested stakeholders clamoring to see what particular pages will look like. On the other hand, at the risk of being cynical, many agencies arent going to say No to a client whos willing to pay more for additional documentation or specications. If youre the lucky individual whos been tasked with creating this grimoire of wireframes, take a step back rst. Instead of focusing on all of the different pages and variations that will exist,
17. Nouvel, Sergio. Ditch Traditional Wireframes, UX Magazine, smashed.by/uxmag-ditch.
260
identify the key pages and page templates that need to exist on the website. Identify the components that will be reused across the application. Create a simple library, modularizing these components, so that you can refer to them in your other documents. Let the key pages serve as archetypes for the others. Highly detailed wireframes with actual content can show in depth how a fully constructed page might appear. Between page models and modular components, content reference wireframes can indicate how your other pages might be dynamically assembled. Continually question how much you actually need to show, in order to communicate the greater systems behavior. Perhaps most importantly, remain focused on the purpose of wireframes, and avoid getting bogged down trying to mock up every piece of content. Wireframes are for planning the design system, not for managing content; content management systems are for managing content and assembling pages.
Wireframing For Mobile Websites And Apps

Wireframing can help to document the different screens of an app or dedicated mobile website, although Ive struggled to justify their use in some recent projects. Recently, we were working on a mobile website for a law school. We were able to explore screen layouts and ows using sketches, and then we moved directly from sketches to HTML prototypes. The HTML prototypes took on the traditional role of the wireframe, with the advantage of also allowing us to focus on layout and interactive behavior simultaneously. This was one of our rst projects in which we abandoned wireframes, and we didnt ditch them lightly. While we were able to speed up the process and use the time saved to iterate, we were essentially losing a specication document. Fortunately, in this particular case, the self-explanatory nature of the prototypes and the limited number of content views made the HTML prototypes a completely viable substitute.
BY DENIS KARDYS
| 261
In cases where interaction is complex and sketches are too rough, but you need more specication about the systems intended behavior in order to build a prototype, you might want to explore supplementing sketches with use cases. Use cases are step-by-step instructions on how users will interact with an application, complete with exceptions and conditions.
Designing and Rening With Prototypes

Todd Zaki Warfel denes prototypes as a representative model or simulation of the nal system. Unlike requirements documents and wireframes, prototypes go further than show and tell and actually let you experience the design.18 Prototypes serve a very specic purpose: to encourage feedback based on use. They exist to disprove or validate design hypotheses. They take many different forms but generally share certain qualities, including the following:
They are collaborative, intended to be used outside of any silo
you may be designing within. They should be easy to alter, allowing for rapid changes based on immediate feedback. They cut down on the need for descriptive functional annotation and detailed explanation. They exist as proofs of concept and are a tool to help sell your idea. They are meant to be used, enabling you to test your designs. Aza Raskin, former creative lead at Firefox, says it well:19
262
|
The goal of prototyping is to convince yourself and others of an idea.
18. Warfel, Todd Zaki. Prototyping, Rosenfeld Media, smashed.by/warfel-prototyping.
19. Aza Raskin, How to Prototype and Inuence People, smashed.by/inuence-people.
Given the advantages of prototyping, its easy to see that there are some immediate benets. Namely, compared to static deliverables, the time that the design team has to dedicate to explaining intended behavior is reduced tremendously. It also cuts down on the amount of time that stakeholders have to spend reviewing and interpreting the designs. I suggest getting into prototypes as early in the process as possible. Until your stakeholders or test users actually interact with a prototype of some sort in their hands, most of the feedback youll gather will be based on how people think users will act, not on how they will actually act. We talked about paper prototypes earlier. Although paper prototypes do offer cues about content, layout and interactive behavior, their primary purpose (at least in how weve been using them) is to validate ideas, helping us decide which ideas are worth pursuing. Through whichever methods you use to determine a direction for your proposed design, youll probably want some way to mock it up and test your theories. Then again, there is the alternative: BDUF big design up front. Proponents of BDUF argue that, with enough research and planning, enough insight exists to spec, design and build it, all in one swoopdo it once and do it right! If youre wondering whether this is the right approach, ask yourself, During the development process, have I ever found the opportunity to make changes to the design that would dramatically improve the quality of the nal product? If the answer is No, then BDUF might just be the process for you! On the other hand, if information has been uncovered that has guided the design forward, then you should already recognize the value of prototyping! Prototypes help to identify those opportunities as early as possible, while the project is still in a crude enough state to be altered without a signicant impact on time or development.
BY DENIS KARDYS
| 263
Because prototypes come in all avors, Ive categorized the ones Im describing according to their intended purpose: behavior and style.
PROTOTYPING BEHAVIOR
If you are prototyping behavior, then youre not overly concerned with details of aesthetics, such as typography and visual style. Rather, these typically low-delity prototypes demonstrate functionality and interactive behavior. They might showcase interactivity at the process levelfor example, the screens that a user will need to interact with in order to complete a mobile transaction. Or they might demonstrate how a single component works, such as a navigation pattern or a swipeable image carousel. Focusing on the visual aspects of a design can be tempting for clients and designers alike. I call this design voyeurism, whereby judgments about the quality of a design are made from afar, irrespective of the actual experience of engaging with it. If you were transpose this to architecture, it would be akin to critiquing an edice as you approach it. The factors that would immediately shape your judgment of it are the visual qualities, its shape and form, the different surfaces, and how it relates visually to surrounding buildings. Think about how this differs from the perspective you would have as an active participant in the space. The same goes for Web designand, in the case of mobile-specic design, its intensied. Being able to look beyond the surface and evaluate the design as an active end user might engage with it introduces a whole new perspective. A toggle menu navigation pattern might look great on an iPhone, for example, where all of the text ts nicely in the viewport. But what happens on smaller screens where the menu links dont all t the viewport? At the beginning of this chapter, I mentioned a scenario in which static visuals for a mobile Web app were accompanied by poorly
264
written specication documents, leaving critical aspects of the design undetermined. By the time the problem revealed itself, the design was so far along the process that revisions would potentially require rethinking the UI. How could using prototypes have revealed the issues sooner or prevented the problematic elements from having made it into the design in the rst place? The reason why the obvious question What happens if you turn it sideways? never came up is because both teams had been staring at a picture of phone, xated on the pros and cons of what they were seeing in that particular context. With a prototype, the design team could have crudely mocked up that initial idea into something tangible that could be picked up and held by the teams. Testing it in that context would have revealed the issue, prompting the design team to spend a little more time working out that component of the systems behavior. So, what does it take to move from static deliverable to interactive prototype? Surprisingly little!
Interactive Wireframes Adding even a small amount of interactivity to your wireframes can go a long way toward reducing the amount of annotation and conversation needed to convey how your proposed design is intended to function. Interactive wireframes can also be used for basic usability testing. The process of creating an interactive wireframe can be insanely simple. Imagine that youre planning a simple native application. In your wireframing tool of choice (mine is InDesign), create a page for each screen or application state that you want to demo. Export your wireframe to PDF. Using Acrobat, you can create rectangular hotspots anywhere on the screen. Then, assign a link to each hotspot, cross-linking it to another page in the PDF. In doing so, you can easily simulate task ows and test the positioning of icons, buttons and other parts of the interface.
BY DENIS KARDYS
| 265
There are a couple of things to consider with this approach. First, PDF hyperlinks dont work reliably on most mobile devices, so you might end up being limited to testing the mobile design in Acrobat or Reader on the desktop. Not being able to view it in the context of a device in hand, and having to click rather than tap links and buttons, will make this approximation of the actual mobile experience somewhat inaccurate. That being said, its a step in the right direction. If youre not currently prototyping as part of your normal design process, you could use a simple technique like this to ease into, and to start gathering buy-in for, more advanced prototyping techniques or software.
Native Application Prototypes If youre designing a native application, you might be better off using a different set of tools than you would use for a Web-based mobile application. One of the underlying goals of prototyping is to simulate the nal system not only as closely as possible, but also as quickly as possible. You dont want to waste time recreating buttons, sliders, switches, toolbar icons and other platform-specic design conventions. Not only is recreating the wheel time-consuming, but whenever you break from device conventions in a native application, you risk confusing both your developers and users! For popular UX software such as OmniGrafe, platform-specic stencils and UI libraries are widely available. These are great for mocking up different views, but they wont get you much further than where youd be had you shared any other type of document formatted as a PDF. Luckily, some great apps are available to help you quickly put together prototypes of any level of delity. FluidUI20 is a subscription-based service (with a free plan as well) for prototyping iOS and Android apps for phones and tab20. FluidUI, smashed.by/uidui
266
FIGURE 6.11. FieldTest App, one of the many browser-based applications for
rapidly prototyping mobile apps: smashed.by/eldtest.
lets. It comes with a full library of UI elements and gestural support, and it works equally well for demonstrating screen ows and on-screen interactivity. It also has built-in features for sharing mockups and collecting feedback. FieldTest App is another browser-based application for rapidly prototyping mobile apps. Upon uploading images of your different screens, you can superimpose hotspots that respond to different types of device interaction. More advanced and better for testing than interactive PDFs, it pretty much eliminates the need for Acrobat.
HTML Prototypes The main difference between HTML prototypes and interactive wireframes, Flash-based prototypes (which Ive deliberately left out of this chapter) and any other methods that people use to simulate mobile or Web application experiences is that the former are created in the same medium that the end product will ultimately be rendered in. You could certainly introduce HTML prototypes at any
BY DENIS KARDYS
| 267
point in the process, but if you are building a mobile Web application or a website (mobile, responsive or otherwise), I cant stress enough the importance of getting into HTML early on. A word of caution, though. Building and writing the HTML and CSS can be problematic if you dont yet have a clear sense of direction, a rm grasp of the content and a well-planned information architecture. Without this foundation, you could get caught up ddling around with ideas but not making much progress, or you could end up arbitrarily ping-ponging between concepts. If you have a shared vision of the goals of the project and general agreement about the priorities of content, then HTML prototyping can be a very valuable tool. HTML prototyping makes ideas less hypothetical than any other method, allowing your design decisions to be tested in the actual context that they are being designed for. For the mobile Web, you can get an actual, exact indication of the extent to which the content will t in any particular viewport at any given time. For touch-enabled applications, you can hold, tap or swipe the interface on an actual handheld device! A recurring theme here has been purposeful deliverables. When you show a client or stakeholder a static design deliverable and then invite feedback on interactive behavior, youre undercutting your own design argument. Instead of giving your design decisions a chance to stand on their own and prove their effectiveness, youre putting them on the chopping block, just waiting for somebody to make a remark like, But Im just not sure people will know to click it. We experienced a case like this while working on wireframes for a project just recently. Our client wanted their audience members to be able to self-select their role, in order to reveal a menu of relevant links and targeted calls to action. We approached it in a few ways and ultimately proposed a standard select box to display role types.
268
Once the user has selected a role, a panel would reveal the targeted links and content. We spent 45 minutes on one call and another 20 on a follow-up call debating the likelihood that a person visiting the website would realize that they could (or should) tap the select box control to reveal more information. To be fair, both we and our client had valid points, so it wasnt a matter of which option was right, but rather a matter of recognizing futility. Seven people spent 65 minutes, for a total of 455 combined minutes, debating the imaginary behavior of website users. An observation: it would not have taken 455 minutes to run a simple test, using an HTML prototype to determine whether people would nd the select box to be intuitive. The best place to decide about interaction is in the medium where that interaction will occur. HTML prototypes also enable you to test a design more rigorously. Designing components that look perfect and behave seamlessly at predened screen sizes is relatively easy. But what happens when the design is shown in a different-sized viewport? HTML prototypes enable you to test the awkward spaces between breakpoints; for example, how the design will hold up on screens smaller than 320 480 pixels or bigger than 480 800. A mobile view of a website sometimes has a drastically different design than a desktop view. Depending on how youve set up the media queries, the design would switch from the desktop to mobile view at a particular breakpoint. On paper, this works ne, but the HTML prototypes will reveal any awsany places where the design looks incongruous and out of place. Identifying design aws early on allows for smarter development and resource allocation later on in the project. In fact, these prototypes are your best tool for validating or disproving your design hypothesis. In the event that your design turns out to have problemswhich it inevitably willHTML prototypes are also an extremely malleable format for making changes. Because you are
BY DENIS KARDYS
| 269
prototyping in the same medium that browsers render in, prototyping can continue (if desired) well into the development phase.
HTML Prototyping Tools HTML prototyping can be a bit daunting for those who dont spend the majority of their time writing front-end code. Critics of HTML prototyping argue that its too cumbersome to be practical. The perception by many is that, in order to prototype in HTML effectively, you need advanced front-end development skills. While it wouldnt hurt for a designer to develop those skills, HTML and CSS expertise is certainly not a prerequisite. Software such as Axure21 will help you build an interface by dragging and dropping components into a mobile template. You can then export the project to HTML and test it in the browser or on an actual device. If you arent intimidated by code, then dive right in. Starting completely from scratch every time you want to build something in code doesnt make a lot of sense. Most front-end developers have some sort of prebuilt or custom-built package they use when starting a new project. Frameworks such as Bootstrap22 and Foundation23 provide all of the boilerplates and snippets of code that you need to copy and paste your prototype together. The frameworks are robust and customizable enough to be used to build production-ready HTML for your mobile Web project. If youre condent enough in your (or your coworkers) abilities to handcode everything, then you might be able to build your own framework from scratch or build on a solid base. Mobile Boilerplate24 is a helpful baseline template that you can use for your mobile website or application. If youre focused on creating task-based
21. Axure, smashed.by/axure 22. Bootstrap, smashed.by/bootstrap 23. Foundation, smashed.by/foundation 24. Boilerplate, smashed.by/boilerplate
270
mobile Web applications and want to retain some of the elegance of a native interface, then youll also want to spend some time exploring jQuery Mobile.25 All of these options will get you pretty far along, but you can still take it a lot further. If youre serious about putting together your own framework, then familiarizing yourself with OOCSS and SMACSS might be helpful. Nicole Sullivan coined the term OOCSS, object-oriented CSS, to refer to the practice of breaking your HTML and CSS into reusable, customizable objects. Both her framework and Jonathan Snooks SMACSS, scalable and modular architecture for CSS, emphasize scalable and modular code. The beauty of these methods is that they tie in so nicely with the concepts weve been talking about: device and layout independence. By using HTML and CSS patterns, you create more modular code, meaning that components exist independent of any particular context. Any component should be able to adapt to t any space on the screen. Sure, building your code might take a little more time than using prototyping software that outputs HTML, but it could save you time in the long run. Using a framework (custom or otherwise) makes it easy to swap out elements in the design, which is important in the prototyping process. It also improves collaboration between roles. Setting rules for naming conventions, structuring your HTML into reusable chunks and keeping separate CSS les for layout, style, patterns and behavior make it possible for anyone on your team to work on the code at any point, with a shared understanding on how everything is set up. With the markup being turned into reusable shared building blocks, and with the CSS that controls the aesthetics being separate from the CSS that controls the patterns and layout, it becomes possible to prototype the style and layout independently.
25. jQuery Mobile, smashed.by/jquerymobile
BY DENIS KARDYS
| 271
PROTOTYPING STYLE
Prototyping style is a reaction against BDUF and assembly-line processes. When visual design is relegated to the last step in the design process, before production begins, its impact on the overall design and experience is limited by the extent of what can be achieved by selecting typefaces and picking colors. When approved blueprints that describe content, layout and interaction are handed off to the frontend or UI designer, what leeway do they have for visual exploration? Visual design is more than just icing on the cake, yet thats not how it gets treated in our conventional processes. To realize the value that UI and style exploration can contribute to our designs, we must adopt processes that embrace it earlier on, when it can still have an impact.
Sttyle Tiles, Pattern Libraries And Prototypes It would be counterproductive to get overly literal with the UI at the onset of a project, while content and layout are still being eshed out and evaluated. Getting a jumpstart on the UI is still possible, though, if you go a bit more abstract with what you are presenting. You might even nd that you are able to have equally (if not more) productive conversations with stakeholders about their preferences. Discussing the design of the system as a whole, before attempting to present the design as it appears in a single context, is an approach that has been gaining a lot of momentum. An early advocate of this is Samantha Warren, who proposes Style Tiles26 as a means of building consensus around aesthetics and style. A style tile is a design deliverable consisting of swatches of color, typographic pairings, patterns and any other elements that help convey a visual theme. They do an excellent job of focusing conversation on the broader aspect of the visual designsuggesting possibilities for an overall global theme. Early agreement on thematic direction can
26. Samantha Warren, Style Tiles, smashed.by/styletiles
272
FIGURE 6.12. How much or little do you need to show in order to convey the
look and behavior of a design? The team at Sparkbox has been experimenting with Style Prototypes (left) as a means of exploring and communicating design direction before creating fully developed pages (right).
facilitate and speed up the transition to prototyping later. As the products we design begin to reach more and more contexts, our visual designs must become more resilient than ever. We need to consider how the aesthetics we introduce support a cohesiveness that transcends any one device or channel.
BY DENIS KARDYS
| 273
To achieve this cohesion, others have approached the idea of abstraction from a totally different angle. Jeremy Keith suggests using a Pattern Primer27an interactive guide that documents a website or applications core components, showing both the UI and the code used. By focusing on the design of these components, you style the bits that ultimately get assembled into the nal product. Because theyre created in HTML, they can be demoed in the browser or on a device and can even include interactive behaviors. Building on these ideas, others have experimented with ways to pool together the best aspects of both approaches. The team at Sparkbox uses a deliverable called a Style Prototype to explore stylistic options.28 Its similar to a Style Tile in how it presents a visual story for each concept being pitched, but its put together with HTML and CSS, so that basic interactions and responsive behavior can be demoed. Built in code, this document can be presented in the browser, ideally setting realistic base expectations for any stakeholders who preview it. In our own experimentation, trying this out on content-heavy responsive websites, weve found that more detail is sometimes needed. In these cases, with each iteration of the Style Prototype that we deliver, well increase the range of what we show. As additional components are added, the Style Prototype evolves. To get constructive feedback, though, we have had to show some elements in some degree of context. Layout is implied only to the extent that it reects the templates overall structurethus, identifying that there is a header region or icon bar, a main content region and so on. The details within each need not be exact yet. The context that is shown need not be a components relationship to the page layout, but rather its relationship to other chunks of content. At the most basic level, its the difference between showing h1 to h5 headings in a sequential vertical list, as you might see in a style
27. smashed.by/patternprimer 28. smashed.by/style-pro
274
FIGURE 6.13. By introducing additional components during each iteration,
you show how modular elements can come together harmoniously.
BY DENIS KARDYS
| 275
guide, and placing your h1 next to introductory text, or clustering masthead elements in a realistic way. Because this method allows for exploration independent of the nal layout, visual design does not have to happen in its normal sequential order, directly following wireframes. In a recent project where we tried this new approach, the client dropped a new brand requirement on us halfway through the design process. In a linear process, this could have caused a ripple effect of changes to the layout, causing deviation from the already approved wireframes. To make things trickier, the implications of the new branding seemed minor at wider breakpointsthus, getting approval on a static comp (showing the desktop view) would have been easy. But because we were in HTML, we immediately saw that incorporating this new logo would mean trouble at certain mid-range screen sizes. This approach made it easy to explain the issue (by showing it) and to come to a resolution. In the past, the new logo would have been awkwardly shoehorned in, looking like an afterthought at certain screen sizes. By not showing the full designs of particular pages, we reinforce the notion of designing for a system. Because producing style prototypes takes less time, we can present a greater volume of concepts, soliciting feedback and exploring more options during each round of design. At each new iteration, we reveal a bit more and explore a bit more, all while converging conceptuallylike Buxtons variation on the design funnel. Conversely, when the rst design concept you show your client is a polished design, its inevitable that any critique or change requested by the client will feel like a compromise that waters down your concept. Better to adopt a format that encourages testing and concept generation at each stage, so that each new iteration feels like an evolution.
276
In practice, when designing for a wide range of screen sizes and devices, this approach seems to work well as a replacement for static design comps. We are advancing the style and component UI to the point that it converges seamlessly with other more functional and layout-specic HTML prototypes. While this approach shows early promise, it does have some drawbacks as well. The biggest issue is that nding the happy medium between literal and abstract can be very challenging. If it becomes too representational, your audience will focus on critiquing it as a page; too abstract, and your audience will be confused as to what exactly they are evaluating.
PROTOTYPING FOR NATIVE APPLICATIONS Although you may nd some use for Styles Tiles and interactive interface guides when designing native applications, they might also be overkill. Native applications often have their own devicespecic interface patterns and conventions to be followed. The same browser-based tools used to prototype behavior could also be used to mock up nished high-delity interfaces. PSD template libraries lled with iOS and Android UI elements are abundantly available for downloading on the Web, including a robust one from Teehan + Lax.29 Regardless of how you opt to mock up your native application designs, always eliminate anything that could set the wrong expectation, and do as much as you can to reveal the different modes of your app. An interface challenge that I continually struggle with when designing any app that needs to be supported on multiple platforms is whether to lean toward consistency with the devices native conventions or lean toward consistency with the application itself across devices. When you are focusing on a single platform, using the stencils and UI kits makes a lot of sense. By following inherited
29. Teehan + Lax, smashed.by/tlax
BY DENIS KARDYS
| 277
IDEATION Collaborative sketching

Good for: most projects.
Paper prototyping
Good for: most projects.
Generate a high volume of concepts. Break mental models and reset expectations. Build consensus around design direction.
Narrow down concepts. Validate or disprove concepts and scenarios. Collect real-time feedback.
PROTOTYPING BEHAVIOR Low-delity HTML prototypes

Good for: responsive design, Web apps
Software-based low-delity
prototypes Ideal for: native apps Test system and component behavior and task ows. Quickly model native device conventions. Build consensus around features and functionality.
Test system and component behavior and task ows. Evaluate design decisions. Build consensus around features and functionality.
HIGH-FIDELITY PROTOTYPING HTML prototypes Good for: responsive Software-based prototypes

design and Web apps Good for: native and Web apps
Simulate the behavior and appearance of the nal product. Test designs in a realistic context. Gain approval or sign-off for full development.
Recreate and simulate native device functionality and behavior. Test designs in a realistic context. Gain approval or sign-off for full development.
278
CONTENT PLANNING Page tables

Good for: content-driven websites and apps
Content reference wireframes

Good for: responsive design
Medium-delity wireframes
Audit page content.
Identify page archetypes (templates).
Map content to templates. Audit component variations. Model key pages. Suggest system and component behavior.
Prioritize information. Establish global templates. Suggest layout breakpoints.
PROTOTYPING STYLE Style Tiles

HTML pattern libraries

HTML style and
interface guides
Rapidly explore and compare aesthetic alternatives. Establish visual style before investing in higher-delity prototypes.
Develop a visually consistent interface system, independent of layout or device. Map reusable components to modular snippets of code.
Rapidly explore stylistic options in a realistic context. Build consensus around design direction. Demonstrate basic interaction.
FIGURE 6.14. Clearly dene the purpose of each deliverable that you produce in order
to sharpen the focus of design critiques and smoothen the approval process.
BY DENIS KARDYS
| 279
conventions of the platform, you match the users existing mental models of the system. If you know that what youre designing will be deployed across multiple platforms, then you may have a case for some of the more device-agnostic design approaches.
Putting It All Together

Weve covered a lot of territory so far. Given the unique needs of any project, you would not likely need (or want) to t every technique into every project. Knowing how to decide which tools to use and how to pitch them is key, so lets put on our project-manager hats for a moment and get logistical. What practical considerations do we need to make when implementing some of these techniques for a non-sequential, iterative project?
EXAMINING ALL OF THE PIECES AND THE PURPOSE
You may have noticed a recurring theme throughout this chapter: liberating content from layout, and prototyping behavior independent of style. With every deliverable described, the emphasis has been on identifying its core purpose and restricting the range of what its being used to communicate. This may seem a bit counterintuitive, since were narrowing the focus of our design artifacts and asking for feedback on pieces rather than on the whole. All of this deconstruction might even seem to y in the face of holistic design! Id argue to the contrary. Its just another shift in how we perceive what were building. Rarely do our websites and applications exist in a single context, even applications designed for a particular platform. So, unless we can guarantee that our designs will be presented in a single context, we can no longer evaluate our designs in a single context and call them holistic.
280
By establishing a particular purpose for every design artifact you produce, you move toward a more modular process, one in which you use or lose different parts of the process when it makes sense to. Making them modular also makes them more quantiable in terms of how much time you need to spend with each technique. Most importantly, modularity fosters collaboration, since you can more easily assign different people to work concurrently on different pieces of a design, everyone moving towards the same goal.
CONVERGING PROCESSES
Before examining a complex model of how this might work, lets start with an extremely basic but effective example of a nonlinear design process: building with LEGOs. Think back to building with LEGOs as a kid, or with your kids if youre a parent like me. Now, imagine for a moment imposing a linear design process onto your LEGO-building workow. It seems crazy, right?! This is because were all familiar with how fun and fast the real LEGO workow is. Everyone has a shared idea of whats being built. The pieces themselves are a mixture of predened components and custom ones, making it easy for anyone to just start grabbing pieces and buildingcontinually swapping out pieces until things t just right. When a partially constructed idea starts to show signs of instability, weak parts are swapped out for sturdier ones. As the section that each person is working on evolves, others in the group see and take note, adjusting their design to facilitate the impending assemblya tower, village, starship or whatever has been imagined. This is an ideal example of a convergent process! It includes ideation, concept exploration, prototyping, testing, revision, collaboration and assembly. We build things that are a bit more complex than LEGO towers, to be sure. But doesnt it make sense for the different specialists who comprise a design team to work concurrently rather than sequentially?
BY DENIS KARDYS
| 281
After all, unlike architects who build with steel and concrete, we work in the extremely malleable medium of pixels and code. When coordinating tasks for a project, instead of thinking about a relay of hand-offs, consider dumping all of the projects pieces in front of the team at the beginning. How could the pieces be organized in a way that allows tasks related to layout, style and behavior to be carried out concurrently?
WORKING WITH YOUR CLIENT
For all intents and purposes, your boss and client are one and the same when it comes to the practical implications of changing or adopting new design methods. There need to be reliable expectations of the outcome, and there need to be reliable expectations of time and cost. If you cant set those expectations, youll be ghting a losing battle. In theory, prototyping is great. In reality, BDUF is practical. If you want to blur the lines a bit and move away from a BDUF or waterfall process, expect some resistance. Youll need to address some very pragmatic considerations. Most payment schedules are tied to milestones in a project. In order for your company to get paid, the client must acknowledge in writing that satisfactory progress has been made. In order to maintain steady revenue, those milestones might need to be reached at certain points in the projects timeline; for example, the beginning, middle and end. These periodic approvals also serve to prevent scope creep and wishy-washy decisionmaking. And these logistical considerations ensure that projects can be protable and be delivered on time and on budget. If you want people to adopt the new approaches that youre proposing, dont wait around expecting others to gure out the logistics. Sell your ideas in a way that ts the existing business models and if thats not feasible, then consider proposing new ones.
282
So, what can we say are the benets when selling an appealing alternative to BDUF?
1. It gives the client more opportunities to provide input and feed-
back on the design throughout the process.

2. It shortens the projects duration by running tasks concurrently
and eliminating needless artifacts. 3. It guides the project to better results by taking a test-driven approach to design decisions. Build on this by suggesting that the pieces that make linear processes so sensible can still exist in a more iterative workow. You simply need to nd a way to do the following:
1. Redene what your client will need to sign off on at different
points in the process. 2. Allow for iteration and changes to occur later in the project, while limiting the number of revisions in scope. 3. Make sure that changes are controlled and methodical, so that you dont end up investing superuous resources.
Getting Buy In
Some of the ideas mentioned in this chapter, such as incorporating collaborative design workshops into your workow, might not be met with much resistance. Aside from time, they pose very little risk to anyone. Few would dispute that by weeding out assumptions and implementing a more collaborative ideation process, youre setting up for a better outcome to the design. But gaining support of some of the other ideas presented, such as making heavy use of prototypes and even going so far as to replace or diminish the role of static deliverables, might require a bit more tact. Wireframes and design mockups have been staples of the
BY DENIS KARDYS
| 283
interaction and visual design process for many years, and clients and bosses have grown to expect them. In some cases, payment schedules are even tied to particular design hand-offs and sign-offs, so tampering with the process could have implications under the surface. Prototyping also makes people on both sides nervous, because their entire existence revolves around disproving design decisions that others have approved into the design. This leads to inevitable changes, and changes take time, which translates directly to dollars.
UNDERSTANDING THE CLIENTS RESISTANCE TO CHANGE
Adoption of or resistance to change in a process is not purely a logistical matter. There are other reasons why clients and bosses will continue to clamor for static deliverables. Being able to see a nished design early in the project makes the entire process seem more stable. Resolving the most contentious aspect of a projecti.e. what the design will look likebrings a feeling of security. By signing off on this, the client is able to denitively know what theyll be getting and can make sure that others in their organization know it as well, adding another layer of assurance. Assuming that your goal is to deliver the best experience possible to mobile users and not just get sign-off, the question then becomes, How do we instill such condence and a sense of security in any new process that we propose? Here are some tips on getting your bosses and other stakeholders on board:
1. Show that its viable.
Can you produce a nal product thats equal to or better than what you would have produced through a conventional process, with the same timeline and budget? Although it might take a little guesswork the rst couple of times, you should eventually be able to calculate how much time and cost are required by your new methods.
284
2. Bring clarity to the process.
If a client or boss cant envision how the process will work or what types of deliverables theyll be able to show their colleagues, then theyll have trouble committing to any new approach. In the face of uncertainty, people retreat to the security of convention. Show working examples of prototypes and any other deliverables you want to include.
3. Inspire them.
Explain the potential that mobile devices afford the client to connect with their audience. Remind them of the shortcomings of our conventional processes.
4. Start small.
This could mean starting with something like interactive wireframes, or moving straight from sketching to HTML in a small project. Once you have a few quick wins under your belt, you might nd that others in your or your clients organization are championing this more hands-on approach. In our last six months, weve already seen a handful of clients eagerly accept our proposition to move away from an assembly line of static deliverables and to get on board with a more hands-on prototype-driven approach. I believe that the reason clients and bosses cling so tightly to conventional processes and deliverables is simply that no one has pitched them a practical business case for a better way to communicate design. But mobile is a powerful wedge here. By promising the client more collaboration, more active involvement in the process and a prototype-based approach to design, we alleviate many of the fears that weigh on the minds of the projects team members. Will I like how it looks? Will it address the issues we hope it will? Were
BY DENIS KARDYS
| 285
essentially proposing to cut out inefcient documentation (which drives up costs), give the client more choices and increased involvement (through ideation and prototyping), and schedule tasks concurrently (modular and convergent processes), thus saving time and yielding a more accurate, tappable and testable version of the interface sooner. Who would argue with that?
Designing for Interconnectivity

No single workow works for every person or every project, although I sincerely hope that some of the techniques described here will be helpful to you in upcoming projects. The reality is that the technology we design for changes almost daily, so new tools and methods will always be in demand. We preach the value of uidity in design, and yet we stick with the same rigid processes that weve been using for years. Its time to apply our design scrutiny to our own processes, ruthlessly abandoning elements that are outdated or inefcient and bravely exploring new ideas. Each document we produce should contribute to a better understanding of the bigger system its a part of. We must be careful how we communicate our design intentions. The default choice is to proceed along the same path, opting for status-quo deliverables that continue to hinder our understanding of mobile. Or we could take a step back and ask these questions:
Do we have a system in place that enables each member of the
team to contribute to their fullest? Or does our workow needlessly limit people by chaining them to an assembly line? What expectation does the design documentation being produced set for the recipient? Does the documentation encourage design testing, or does it tempt them to hypothesize?
286
Do the techniques we employ reinforce our understanding of
mobile, or do they provoke new insights into interaction and interconnectivity? We are designers in a time of incredible opportunity. The line that divides us and the technology we surround ourselves with is blurring. Mobile devices make it possible for us to, on a whim, pluck nearly any piece of information we desire out of the air almost instantaneously. They have sensors capable of giving us feedback about our actions and capable of storing pictures and sounds of the experiences we accumulate. Even though we understand that they are simply computers and, thus, entirely replaceable, we still covet them, petting and tapping them, keeping them near our beds at night. The technology is a shell, but weve found ways to extend ourselves through it. During a keynote speech by futurist and inventor Ray Kurzweil at SxSW Interactive earlier this year, a man in the audience asked him at what point he thought that man and machine might converge. Kurzweil paused momentarily, reached into his jacket breast pocket and pulled out his iPhone. Looking at it thoughtfully, he said something along the lines that, to him, the distinction between whether this technology exists in our pockets or under our skin is relatively inconsequential at this point. And so where does that leave you and mepeople who spend their days designing for mobile, repeatedly learning and unlearning what we know about it so that our understanding of it becomes ever keener? We are the ideators who help others appreciate its potential. We are the designers who mould the task processes that these devices enable. Were the builders who make it all ubiquitous. With such immense potential, think of all the good thats possible. Now, its just up to you to communicate it.
BY DENIS KARDYS
| 287
ABOUT THE AUTHOR
Dennis Kardys had no experience in HTML and CSS or designing for the Web when he startet at the Web design agency WSOL, so he ended up having to gure it out quite quickly. His passion is to use design to unlock the Webs potential to enrich the lives of people and to help businesses ourish. The biggest lesson he has learned in his career is not to get attached to your ideas. Be prepared to kill your darlings. It can be extremely hard to move beyond a good idea and recognize that even though sometimes it might be a great idea, doesnt mean its the right idea.
288
CHAPTER SEVEN
BY JOSH CLARK
DESIGNING FOR TOUCH
ouch changes everything. Fingers and thumbs turn desktop conventions on their head, with touchscreens upending whole swaths of settled interface practice. Done right, touch interfaces create the sensation of interacting directly with information, of nudging and manipulating data as if it had actual physical properties. This trick of the eye and mind demands new methods: interface metaphors shift; content itself becomes the interactive control; traditional buttons, menus and tabs become secondary; and the familiar physics of the everyday world intervene. All of this means that the best touch interfaces look and behave differently from those driven by mouse and keyboard. Dennis Kardys wrote earlier that when we design for mobile we have to turn away from familiar conventions. But to what? Best practices continue to evolve as we feel our way through this Wild West era of mobile. Ive got some clear ideas of where its headed, but the best place to start is with a new perspectiveone that focuses less on visual experiences and more on physical ones.
BY JOSH CLARK
| 289
Visual designers often discuss the look and feel of their interfaces. When the touchscreen is your palette, the feel takes on literal importance. Touch design introduces genuine ergonomic issues. That means your job as a designer has fundamentally changed.
Youre Not Just A Visual Designer Anymore

When you venture into touch, you step into the world of industrial design. We typically consider user interface (UI) work to be a pursuit of visual, graphic and information design. All of those disciplines remain central to touchscreen UI, sure, but theres a crucial new physical dimension. Its not only how your pixels look, but how they feel in the hand. There are distinct similarities between designing a touch interface and designing a physical device. Because your design is stretched across a physical object and explored by human hands, your work denes how those hands interact with the hardware. You have to consider basic concerns of physical ease and comfort. Fat ngers require more forgiving controls, and they have a pesky habit of blocking the view, too. As the designer, you need to make way for them. So lets start there, with the limitations of that age-old input device, the nger. Or more specically: the thumb. The thumb turns out to be the most crucial digit in handheld touchscreen design, no matter how large or small the device.
The Rule of Thumb

The phone is unique among other touchscreen gadgets because there are a blessedly limited number of ways to hold the thing. It has three essential grips, and thats it. You can hold it in one hand and tap away with the other, you can hold it in two hands and work it with your thumbs or you can hold it in just one hand.
290
DESIGNING FOR TOUCH
Of those three fundamental handholds, the one-handed grip is at once the most freeing and the most limiting. Its freeing because it lets you do things with the other handwrite, sip coffee, hold a babya fact that makes it the most common grip. But its limiting because working a phone one-handed means working it with your thumb. The opposable thumb is a marvelthey say its what separates us from the beastsbut when it comes to driving software, thumbs lack both reach and dexterity. This peculiar combination of freedom and constraint means you should optimize smartphone designs for the one-handed grip. Its used most often but also requires specic design concessions. Those concessions focus almost entirely on thumb span. While a thumb can manage to sweep most of the screen on all but the most oversized phones, only about a third of the screen is in truly effortless territoryat the bottom of the screen on the side opposite the thumb. When holding a phone in the right hand, for example, the thumb falls naturally in an arc at the bottom left corner of the screen. Place primary tap targets in FIGURE 7.1. The thumbs hot this thumb-thumping hot zone. zone is the arc of your thumb This is a big reason why the best span on the screen. Favor this designs typically pin toolbars and area for primary controls. navigation to the bottom edge of phone interfacesprecisely the opposite of typical desktop layouts. Desktop software conventions put menus at the top of the screen or window, and websites traditionally position primary navigation at the top of the page. Our limited thumb spans, however, ip that convention on
BY JOSH CLARK
| 291
its head, sinking navigation and primary tap targets to the bottom of phone screens. This preference for screen bottom is more important than left versus right. Were models of ambidexterity when slinging our phones. Right-handed users often favor their left hands (or switch to the left when writing, for example), and lefties likewise often go with their right. A modest majority of users do go with their right hand a bit more often, but its not a strong enough trend for designers to fret over. And besides: optimizing for one hand naturally penalizes the other. When in doubt, offer equal-opportunity access with full-width buttons or central placement for primary controls.
FIGURE 7.2. Were a exible lot when it comes to left- vs. right-handed phone use. On
iPhone, Evernotes full-width buttons (left) and Instagrams centered Photo button (right) cater to left and right hands equally.
292
DESIGNING FOR TOUCH
The screen-bottom rule of thumb, however, applies no matter which hand you use, and it gives you hints about how to organize the visual hierarchy of tap targets. Frequently used buttons should occupy the bottom of the screen for easy tapping, while other controls should be nudged out of harms way. Its often an especially good idea to push controls that post or change data outside of the thumb zone. Its a convention in iOS, for example, to place Edit buttons at the top right, within easy view but just enough of a stretch so that accidental changes are less likely. Its the same reason that Twitter puts its New Tweet button up there, and why Foursquare puts its Check In button there, too. Its not only simple comfort and convenience that drive screen-bottom conventions, but also the awkward fact FIGURE 7.3. Like many iOS apps, that ngers obscure the screen. Pushthe app Things places its Edit ing controls below the content keeps button outside the thumb zone. hovering hands out of the way. Content on top, controls on bottom: this time-tested, common-sense principle of industrial design keeps the display in clear view no matter what your hands are up to. Its a layout thats familiar to most physical devicesiPods, calculators, cell phones, bathroom scales, you name it. Keep the meat out of the way of the display.
BY JOSH CLARK
| 293
FIGURE 7.4. Content on top, controls on bottom a basic staple of industrial design.
The Robot Always Wins

The top/bottom rule is simple enough, but its complicated by your application environment. Android, for example, beats app designers to the bottom of the screen with the system buttons hugging the bottom of every Android gadget. (Prior to the Android 3.0 Honeycomb release, these were always physical buttons; starting with Android 4.0 Ice Cream Sandwich, they became virtual buttons.) For all the reasons already discussed, Android does the right thing in pushing those buttons to screen bottom, but it puts them into nger-bafing competition with app controls. As an app designer, if you follow your instinct to put controls below the content, you wind up stacking them on top of Androids system buttons. This invites mistaps. Avoid stacking controls at screen bottom. Piling controls is always a bad idea in touch interfaces, but its messiest at screen bottom. In this high-trafc area where a hovering thumb blocks the view, button collisions are inevitable.
294
DESIGNING FOR TOUCH
Unfortunately, the x for Android apps is to place controls at the top of the screen to avoid crowding the system buttons. Its not ideal: this puts navigation outside the thumb zone. And when you tap a button, the hand covers the entire screen. But these compromises are better than the bottomstacking alternative, which invites fatnger errors. For Android phones, app navigation and controls should oat to the top. This is the reverse of the convention for iPhone, whose physical Home button doesnt create the same kind of competition as Androids system buttons. Platform-specic compromises are common in touch design. While the content on top, controls at bottom rule FIGURE 7.5. This Android always applies, it depends who gets there home-screen layout, with rst. For Android, the operating system application buttons stacked gets there rst, and apps have to give way. directly above the system In iOS, apps have the freedom to claim the buttons, results in frequent tap errors. screen bottom unless its a Web app.
Websites Are Apps Inside An App

Heres an inconvenient fact: websites and Web apps operate within the connes of another app, the browser. Many mobile browsers have buttons and controls, creating their own UI friction for Web navigation. In Mobile Safari for iPhone, for example, browser controls live in a toolbar at screen bottom. In that case, pinning your website navigation to screen bottom would stack it on top of the browser toolbaragain, a bad thing.
BY JOSH CLARK
| 295
Dont pin Web navigation to screen bottom. This guideline is conveniently reinforced by the fact that position:fixed isnt evenly supported across mobile browsers, making it challenging to consistently glue a toolbar to screen bottom in the rst place. Unlike Android, the solution is not to move Web navigation to the top. Because browser chrome is already eating real estate in some mobile browsers, the last thing you should do is crowd out content even more by choking the top of the page with navigation options. That unfortunate mistake is common in responsive designs, which too often follow the lead of desktop layouts by leaving navigation at the top. In that ill-advised pattern, the rst screen of every page is an identical list of navigation links, and you have to scroll before seeing any signicant content. Too many mobile Web experiencesstart the conversation off with a list of navigation options instead of content, writes Luke Wroblewski1 in his book Mobile First.2 Time is often precious on mobile and downloads can cost money, so get people to what they came for as soon as you can. Web experiences should lead with content and conne primary navigation to page bottom. Thats page bottom, not screen bottom. This is the footer anchor navigation style that Brad Frost introduced in his Responsive Design Patterns chapter. Although there are many alternatives, this is the navigation layout I routinely recommend as best practice. You can see it at work in the Ad Age mobile website3 where all navigation is tucked behind a Menu button in a toolbar at the top of the screen. Tap the button and the entire screen lls instantly with navigation options. The menus appearance is instant and feels like an overlay has appeared, but in reality, its actually an anchor link to navigation at the bottom of the page.
1. smashed.by/lukew 2. smashed.by/mobile-rst 3. smashed.by/madage
296
DESIGNING FOR TOUCH
FIGURE 7.6. Ad Age employs a simple anchor link to reveal navigation. The Menu but-
ton at the top of the page (left) hops you down to navigation at page bottom (right).
Tap the Back button to return to the top of the page. Luke favors this pattern, too:
This design uses a minimum amount of navigation elements (just a single link at the top), gives people an opportunity to pivot and explore when they get to the end of content, doesnt duplicate the content of another menu, and (best of all) only requires a simple anchor link to work. Thats right: no fancy JavaScript, overlays or separate navigation pages to maintainjust an anchor that links to the bottom of the page. Thats like HTML.
Content on top, controls on bottom is simple enough, but as youve seen, it has varying outcomes for app designers when the operating
BY JOSH CLARK
| 297
system or the browser claims this premium real estate rst. In the end, it works like this for phones:
On iPhone, put app controls at screen bottom. On Android, put app controls at screen top. For the Web, favor navigation at page bottom (not screen bottom).
The specics of every software platform shifts layout guidelines, and so does hardware form factor. When designing touch interfaces, you must pay careful attention to where hands come to rest. That changes according to the shape, size and weight of the gadget. So what happens when the touchscreen gets larger? With the iPad and other tablets, the rules change yet again.
Take Two Tablets and Call Me in the Morning

Tablets create entirely new headaches (and opportunities) for touchscreen designers, e.g. the iPad relies upon entirely different ergonomics than the iPhone. Remember how the phone has just three basic grips? No such luck with tablets, which we grab, tilt, lean, cradle and clench in a whole variety of embraces, many of which depend upon stance. The rule of thumb still applies to iPad, except that the thumb zone changes. The special headache here is that the thumb zone isnt consistent even for individual devices; it changes depending on posture. Standing up, you use two hands to tap away on a large tablet like iPad. You likely hold it halfway up the sides for leverage (hold it too close to the bottom, and the thing goes oppy). Or perhaps you have one arm wrapped around it like a clipboard while you tap with the other hand. Sitting at a table, youre likely to prop a tablet with one hand at the lower third and tap with the other. Reclining in an armchair, you tend to rest it in your lap and tap with the other hand. Lying down or reclining, you rest the thing on your
298 |
DESIGNING FOR TOUCH
belly or nestled in a blanket, propping it with one hand, tapping with the other. In all of these grips, ngers fall in different places on the device. On top of that, each stance results in the device being held at varying distances. We tend to hold the iPad closest while standing, for example, and furthest while lying down or reclining. See whats happening here? When it comes to tablets, were all hands. We roam all over the thingsall over, that is, except the top and bottom edges. As varied as tablet grips can be, two things are true for all of them. First, we tend to hold tablets at the sides; though the specic location wanders up and down, thumbs tend to settle at the middle to top third of the screen. Second, the larger the screen, the harder it is to take in the whole thing at a glance as you can on a phone. On larger tablets, as with print design, our visual attention naturally focuses FIGURE 7.7. Because the tablet grip is typically on the top of the tablet, and at the side edges, the tablets thumb zone is the designs information hiervery different from the phones. archy should reect that. These factors mean eyes and thumbs naturally occupy the top half of tablets, with thumbs straddling the edges. Spreading navigation and primary controls across the bottomthe standard pattern for phonesturns out to be ergonomically hostile on tablets. Sometimes the bottom isnt even visible at all. In the laziest and perhaps most common of positionslying down or recliningthe bottom bezel tends to disappear into blankets, sweaters and soft bellies.
BY JOSH CLARK
| 299
FIGURE 7.8. iPad apps Instapaper (left) and Twitter (right) both show good alternative
placement of controls in the tablet thumb zone. Instapaper puts its article tools in the top left and right corners, while Twitter puts its main navigation along the left edge.
Tablet navigation and other frequent controls should hug the sides or top corners for easy thumb access. Avoid forcing people to lift and haul their entire arms over to the top or bottom edges for frequent touch targets. Some arm lifting is of course inevitable. Tablets are thumb and index-nger devices, with the index nger driving interaction inside the tablets canvas. You have to move your arm for that, no way around it, but focusing navigation around the thumb as the anchor at least means that you can spare your arm the most frequent taps. The top corners are within thumb striking distance while also remaining in the tablets primary visual area.
300 |
DESIGNING FOR TOUCH
FIGURE 7.9. The Dailys scrubber bar
reveals page thumbnails, only to have your nger block them from view. As with most touchscreen interfaces, the center top of the screen is a poor place for controls on tablets.
Avoid placing tablet controls at the top center. Touching the top middle requires you to cover the screen and all its content. Here again we see the prime directive of industrial design: controls should never go immediately above the content they aim to affect. The Daily for iPad, for example, offers a sliding scrubber bar at top center to scan through the issues pages, but when you do that, the hand covers the thumbnails (see previous page). You have to resort to weird hand contortions to even see the thumbnails while working the slider.
The Bottom Line for Tablets

The Dailys misstep uncovers an exception to the top-corner guideline for tablet controls. In some cases, controls should go to the bottom edge, even though its less thumb-friendly than the sides and top corners. When controls display or aect content, place them below or to the side of that content, never above. The Sydney Morning Heralds iPad app, for example, has a novel way to quickly scan all of the articles in the days issue by dragging your nger along an index of page indicators at screen bottom. Because that control reveals a tall list of headlines, its appropriate to place those controls at screen bottom; placing them at the top would mean that your hand would cover the list when you touched the controls.
FIGURE 7.10. The Sydney Morning
Heralds iPad app lists the pages headlines when you tap the pageindicator dots at screen bottom. The controls position leaves the headlines unobscured.
BY JOSH CLARK
| 301
So is it top or bottom? Heres the difference: The iPads top corners are ideal for navigation buttons and onetap tools for actions like sharing, favoriting or deleting. The bottom of iPad apps is best for controls that browse or preview content in the canvas above. This is why page thumbnails for browsing books or magazines are best placed at bottom. Similarly, if you designed a map-building app that included a palette of landmarks to drag into your map, that palette should go at the bottom so you can interact with your map without constantly covering it with your whole arm.
The Hybrids
As I write this very chapter, a whole new category of touch devices has just ooded the consumer market in coordination with the release of Windows 8: touchscreen laptops and tabletkeyboard combos. Some of these so-called hybrids allow you to pluck off the screen and use it unburdened of its keyboard, like a regular tablet, but its the combination of touch and keyboard that create a new ergonomic environment and fresh demands on designers. The new wrinkle: hybrids require us to move our hands back and forth between the keyboard and the touchscreen just behind it. Before this new onslaught of hybrids arrived, many (including a dismissive Steve Jobs) criticized the concept as untenable: people wouldnt want to shuttle their hands back and forth to point at the screen. The effort would be too much, too inefcient, and the result would be the fatigue of gorilla arms. Its a criticism leveled at Minority Report-style interfaces of science ction, too: who wants to work with your arms constantly in the air? Early returns suggest those initial worries were unfounded. People do embrace touch with these hybrids, but they do it by barely lifting their arms. In usability studies by John Whalen of Brilliant
302 |
DESIGNING FOR TOUCH
Experience4 and by Intel,5 newcomers shifted naturally to interacting directly with the touchscreen, ignoring any mouse or trackpad. Despite the availability (and greater precision) of these time-tested pointers, people said the touchscreen felt more intimate and direct. The hand became their preferred pointer for buttons, scrolling, you name it. Even expert users accustomed to tabbing between elds switched to independently selecting form elds by touch. There seems to be something irresistible about the touchscreen, even when more precise or efcient options are available. But what about those gorilla arms? John Whalens research found that people avoid raising their arms with hybrids by instead resting them alongside the keyboard, keeping a loose grip at the bottom corners of the screen. (Among other things, this grip helps to steady a sometimes oppy laptop screen when you tap at it.) Here again, the rule of thumb calls the shots. Placing primary controls and navigation in easy reach of bottom-corner thumbs means you avoid gorilla arms. The result is a vertically ipped version of the thumb zone we saw for standalone tablets.
FIGURE 7.11. The hot zone for thumbs on hybrid devices is nearly opposite the hot
zone for index ngers.
4. smashed.by/brilliantexperience 5. smashed.by/intel-study
BY JOSH CLARK
| 303
Not everyone adopts the bottom grip, though. Others (especially newcomers) go freeform, jabbing their index nger at the screen. This approach unhinges the hands from the screen edges, giving freedom to roam the interface, though the center of the screen tends to be an easier touch than the corners. Trouble is, this nger hot zone is exactly the reverse of the thumb zone. The upshot: optimizing for thumbs means a subpar experience for the index ngerand vice versa. One layout has to win, though, and as with every other touch device, the winner should always be the thumbs. As it turns out, hybrid users begin to prefer thumb use over time, with expert users going nearly all thumbs, reaching them in and out of the screen from the edges to drive interaction. Once again, thumbs are the primary utility pointer. Cluster primary controls and gestures for hybrid screens around the bottom corners and sides. Thats one reason Windows 8 uses edge gestures to summon system and app controls. A swipe from the right edge conjures the system charms, and a swipe from the bottom edge brings up a shelf of app tools. Both are easy thumb gestures.
A Touching Problem for Responsive Design

What all of this adds up to: input type and grip should drive the placement of controls, not screen size. For Web designers in particular, this is a big headache. For most of its short history, Web design practice has focused on the visual, on screen size. Its not yet in our industrys DNA to consider physicality and environment in our layouts. Thats why many are still surprised at the idea that they cant just use their legacy desktop layout on iPad, even though the screen size is the same. The layout looks good, sure, but that rarely means its also nger-friendly.
304
DESIGNING FOR TOUCH
The rise of the hybrids means touch is no longer the sole province of phones and tablets. Its arrived on desktops and laptops, too. Most desktop website layouts, however, are not optimized for touch. They challenge our clumsy ngers and thumbs with small touch targets for links and menus, or they lean on hover interactions that cant be triggered by touch at all. Few websites place primary navigation in easy reach of the thumb zone for either tablets or hybrids; they favor cursor-friendly screen-top navigation instead. Ideally, we would all tweak our CSS to accommodate a range of input types in the same way responsive design has encouraged us to accommodate a range of screen sizes. Responsive Web designers have so far used screen size as a proxy to assume support for touch. If its a small screen, its touch. If its a big screen, its mouse-driven. That distinction was already in trouble with large tablets like the iPad, and hybrids break that approach even more. Unfortunately, we dont yet have media queries to specically target touch devices, but that may change soon. Recent draft proposals for CSS4 include a pointer media query6 to target gadgets with ne or coarse pointing tools. A mouse, trackpad, stylus or any other precision accessory would be a fine pointer, while ngers would be coarse. This would allow you to create specic rules to pamper fat ngers:
/* Make input fields taller for touch */ @media (pointer:coarse) { input[type="text"] { min-height:44px; } }
6. smashed.by/mediaqueries
BY JOSH CLARK
| 305
This will get us part of the way, though its not clear whether a browser with a keyboardmouse and a touchscreen should identify itself as coarse or fine. Even better would be targeting the combination specically. As weve already seen, the layout for a touch keyboard hybrid should be different from that of a touch-only tablet, because the ergonomics are different. That makes it important to identify not only the availability of touch but whether its combined with other input types. It would be helpful if media queries could target additional input types. While were at it, it would be great to have HTTP headers that announce to the back-end server what type of device its dealing with: Hi, Im a touchscreen! Howdy, Im a touchkeyboard hybrid. Greetings, I have no screen at all Until we get these Hello, my name is name tags in CSS or HTTP, we have to make do. Theres only one sensible way to do that: Assume that every screen your website serves is a touchscreen. If a device can be used for touch, its interface should be nger-friendly. This isnt a problem thats specic to touch, either. A new desktop design language is needed, one that replaces cursor-only interactions with conventions exible enough to handle any of several potential input styles. For the moment, that means covering touch-only, keyboard and mouse or these new touch keyboard hybrids. It wont stop there; even more input methods are on their way. Windows 8 is one of the rst ambitiousand imperfectefforts to try to address this thorny issue. Its the rst attempt at an operating system whose interface can handle any input (from handwriting to speech to touch) and any output (screens of any size or noscreen spoken experiences). Thats a hard problem, and Microsoft is
306 |
DESIGNING FOR TOUCH
wrestling with it early, but its a problem the rest of us will have to address in the very near future. How do we build this new touch-and-every-other-input desktop experience? This is The Mobile Book, not The Reimagined Desktop Book, and spelling out entirely new desktop strategies stretches the mission a bit. But here are a few quick wins that will make desktop designs work for both cursor and touch.
Pin controls to the left and right edges for easy thumb access on
both tablets and hybrids. Favor the left for primary controls. Most index-nger users use their right hand for poking the canvas, leaving the left hand in place for thumb navigation. Treat hover as an enhancement, not a requirement. Make sure all touch targets are large enough to accommodate fat ngers.
Too Big to Fail

Everything discussed here so far has to do with how you hold the touchscreen. The way you handle a device dictates placement of controls, but its your nger size that decides how big those controls should be. Touch designers need to make tap targets too big to fail, chunky targets that we can tap without crossing our eyes in concentration. Just how big is big enough when it comes to tap targets? The answer starts with a more fundamental question: whats the size of a ngertip? All the platforms offer guidance here, but as usual Apple is the most opinionated in design matters, offering what I consider to be the best tap-size guideline. The iOS Human Interface Guidelines7 suggest that all touch targets should be at least 44 points, or
7. smashed.by/apple-hig
BY JOSH CLARK
| 307
about 1/4 inch or 7 mm. Points are Apples own measure for iOS apps (not to be confused with the familiar points and picas from print measurements), but 44 remains the magic number for the Web, too. Way back before third-party apps were allowed on the iPhone, Apple published Web app guidelines calling for 44-pixel tap targets, and the advice remains solid. Make tap targets a minimum of 44 pixels. For those of us accustomed to designing for precision pointers like mouse and cursor, controls this big feel enormous and toylikealmost ridiculous. Embrace it. Humongous buttons and gigantic tap targets are not only easy to hit but theyre also easy to see for the occasionally distracted mobile user. While 44 should be your working minimum, its okay to go biggersometimes much biggerto provide effortless tap targets, particularly for larger screens. Like Apple, Microsofts design guidelines for Windows apps8 recommend a 7 mm minimum for touch targets but also suggests moving up to 9 mm (or 50 pixels) for times when you cant afford accidental taps. You might do this if touching the wrong target would require more than two gestures, ve seconds or a major context change to correct. On the other hand, sometimes youre forced to go smaller. In a perfect world, all tap targets would be a minimum 44 44, but alas, compromise is sometimes necessary. Even the iPhones standard controls fudge Apples 44 rule from time to time. In the iOS keyboard, for example, keys are 44 points tall but only 30 points widesimilarly, in landscape view, the buttons are 44 points wide but 38 points high. Apple doesnt have much choice here; its crucial to include the full QWERTY keyboard in this view, but all the keys just wont t as 44 44 buttons. Somethings gotta give.
8. smashed.by/msdnapps
308
DESIGNING FOR TOUCH
When limited space puts the squeeze on tap targets, heres the rule Ive found works best: as long as a tap target is at least 44 points/ pixels in one dimension, you can squeeze the other as small as 30 points/pixels if you really must. That means: the practical minimum size for any tap target is 44 30.
Dont Crowd Me
Your faithful author spent many years of his misspent youth with a svelte Casio calculator watch strapped to his wrist before nally retiring it in 1985. The problem wasnt just its tiny controls or its dampening effect on my prom-king prospects. The buttons were too close together. Youd aim for a ve, but come up with a two or an eight, who knowsit was more Wheel of Fortune than calculator. Button size, in other words, isnt the only determining factor of tap accuracy; you have to consider spacing, too.
FIGURE 7.12. The trouble with my beloved Casio Databank Gold wasnt just its
small buttons; its that they were too close together. Photo by Jon Rawlinson: smashed.by/ickr-photos.
BY JOSH CLARK
| 309
When designing for small screens, youll inevitably be tempted to deal with that challenge by crowding the interface. Ill just nudge these a little closer. Ill just add one more button to this toolbar. To quote a popular phrase of the calculator-watch heyday: Just say no. The closer you squeeze buttons together, the larger those buttons should be. Consider a pair of VoIP calling apps for iPhone, Skype and Call Global. Both jam their keypad buttons close together, but they compensate by making them much larger than the 44 44 minimum. Despite their close proximity, the buttons remain easy to hit.
FIGURE 7.13. Call Global (left) and Skype (right) crowd their buttons but make them
bigger to compensate. Call Global, however, invites mistaps with the skinny buttons stacked above the navigation tab bar.
310
DESIGNING FOR TOUCH
Where the two apps differ, though, is at screen bottom. Both apps stack buttons right on top of the navigation tab bar which, as discussed above, is never ideal. But because those buttons are so big in Skype, the problem is mitigated. In Call Global, though, the buttons hugging the top of the tab bar are too skinny, and their proximity means that mistaps are likely. Even though theyre technically larger than the 44 30 minimum, the lack of spacing and the errorprone stacking at screen bottom invite trouble. The layout calls for bigger buttons or more generous spacing. While it might seem counterintuitive, the success of even smallscreen touch interfaces relies on big elements, chunky buttons and airy spacing. The screens may be tiny, but our ngers (and often, our attention spans) are not. Design with fat ngers in mind. Making your design comfortable for hands and ngers is important but still only half the battle, merely the mechanical part of your design. The subtle work happens when you turn to the interaction.
A New Kind of Illusion

Every digital interface is illusion, a thin layer of magic stretched over the churn of ones and zeroes below. For the rst time, though, touchscreens present the opportunity to create the illusion that there is no illusion. When you remove the cursor and the mouse, these prosthetics that have driven devices for 25 years, all that seems to remain is you and the device, or better you and the content. This shift brings with it a set of psychological, cognitive, ergonomic and even emotional considerations that are entirely new and specic to touch design. All of them require fresh perspective for designers and a new set of design patterns. Touch will help us sweep away decades of buttons, menus, folders and tabsall the administrative debris weve accumulated over three decades of desktop computingto work directly with content. Greg Nudelman explores
BY JOSH CLARK
| 311
this concept in his extra chapter with the focus on immersive apps that shoulder aside interface chrome to make way for content. This isnt change for changes sake. New metaphors and interactions are necessary, in part, for simple comfort and ergonomics, the topics that have dominated this chapter. Touchscreen buttons demand both physical and cognitive effort to hit, and that effort grows with the size of the screen. That tiny button in the top left of so many iPad apps is not easy enough to hit, for example, yet Im asked to hit it all the timeto go back, to browse an apps hierarchy, and so on. I have this big expansive screen, but Im constantly required to focus my activity on this tiny little patch of pixels in the top left corner. Fitts law9 comes into play here. Fitts law describes how long it takes to hit a target with a tool or pointer, or move an object to a target. The whole thing boils down to a common-sense conclusion: the smaller the target and the further away it is, the harder it is to hit. (This is why golf is such a miserable sport.) Fitts law originally described hitting targets in the physical world, and its underlying mathematical models were found to t screen interfaces, too. Turns out it applies to touchscreens, too; the bigger the touchscreen, the more closely the model applies. On phones, the problem is not so pronounced. You can sweep the entire screen with your thumb. Buttons throughout iOSwhether on iPad or iPhoneare the exact same size, yet on iPad, theyre harder to use because of the screen size. iPad buttons ask for concentration and effort, because you have to heave the giant meat pointer called your arm up and over. Dont make people concentrate on hitting little buttons. Let us swipe at the whole screen, not just a little tiny plot of it. Big screens demand big gestures.
9. Wikipedia, Fitts Law, smashed.by/ttslaw.
312
DESIGNING FOR TOUCH
Do You Even Need Buttons?

Pinball HD is a simple example of this. Its a game for iPad, and the entire screen is a button. Or really two buttons. Tap anywhere on the left to trigger the left ipper, tap anywhere on the right to trigger the right. And it makes for much better gameplay than having to grip the iPad at a specic place on the device. Think: where are opportunities to eliminate buttons? Its not that you should never use buttons. Particularly as we stagger toward a common gesture vocabulary, well need visible controls or hints to help people, especially to express and trigger abstract actions (Send to Twitter). But we can have supplementary gestural alternatives, too. Oer gesture shortcuts to supplement common button presses. Thats what Apple did in iPads Mail app in iOS 5, for example, adding a gesture that lets you swipe left to right anywhere on the screen to pull out the message drawer. You can still hit the Back button to do the same thing, but now you can also paw at the whole FIGURE 7.14. Pinball HD sure plays a screen, no matter where your mean pinballno buttons required. hands might rest on the device. More ngers naturally multiply the possibilities. A two-nger swipe becomes a fast forward to the next section or chapter of a content app or website, not just the next page. A ve-nger touch might toggle between my Sent mail and my Inbox in an email app. Reeder, an iPad RSS feed reader, offers a useful and increasingly common example. If youre browsing a specic feed, theres a Back button to return to your list of feeds, but you can also pinch the
BY JOSH CLARK
| 313
screen to return to the menu directly. Its a fast, quick action that uses the entire screen as a control instead of a small portion of it. Its also a clever metaphor that plays on the familiar pinch/spread gesture to zoom in or out of maps or photos with the illusion of direct physicality. Here, though, you zoom in and out of the information hierarchy, pinching a detail view to close it and reveal the list of detail items in the parent category. The UI bestows physicality to the underlying information architecture. This semantic zoom is an emerging convention thats set to become much more popular thanks to its widespread use throughout Windows 8.
FIGURE 7.15. Reeder supplements the Back button with a pinch gesture to close a
detail view and return to a list of feeds, letting you use the entire screen as a control instead of a single button.
314
DESIGNING FOR TOUCH
As handy (ahem) as these multi-touch gestures might be, there are obstacles, too. Accessibility is a big one: not everyone has full mobility of hands and ngersor even all their ngers for that matter. Discoverability is another: how are we supposed to know when abstract actions like a three-nger swipe are even available? (Ill turn to strategies for revealing and teaching gestures in a moment.) For both reasons, its best to treat more abstract multi-touch gestures as alternatives, supplements to more traditional interactions. Gestures are the keyboard shortcuts of touch. Theyre expert actions that let you move rapidly through the interface without mashing buttons. Zipping through time-consuming actions is the motivation behind most custom gestures in nearly all non-game apps. What makes them especially time-saving is the fact that you can just slap at the whole screen: coarse gestures instead of ne-tuned tapping. Ive been talking about this in the context of ergonomics and concentration, but thats not the whole story. Theres also a more fundamental conceptual issue at stake here.
Buttons Are A Hack

Hacks arent all bad. In fact, the best hacks are touched by genius, and thats true of buttons, too. Buttons are an inspired hack, a clever workaround for a very real problem in both the real and virtual worlds. We invented electrical switches and buttons over a century ago to control objects at a distance. From the start, these switches were mere messengers, interactive middle men carrying our intent to its true destination. They necessarily introduce a layer of separation between us and the thing we want to affect. A light switch over here to turn on a light over there is not obvious. It has to be discovered, learned, explained. When I walk into a new hotel room, it takes me a minute or two of trying switches to gure out how to turn on that
BY JOSH CLARK
| 315
one light. But that minor inconvenience is far better than going into a dark room with a ladder and climbing up to screw in the light bulb. Its an inspired hack. Its a similar story for buttons in our virtual interfaces. We created buttons and tabs and sliders as the skeuomorphic middle men to work with digital information and actions that were beyond reach or easy representation. The button-laden graphical user interface (GUI) of the desktop is a metaphor born from the need to manipulate information with keyboard and mouse. Buttons are often necessary, and you should embrace them when you need them, but recognize that they remain workarounds. As we get new interaction models like touch, speech, natural gestures and facial recognition, its worth asking: do I still need that hack? Is there an opportunity to manipulate content more directly? Touch helps us reduce complication by getting rid of visual abstractions to work with content directly. Our brains evolved to navigate physical space, to work directly with objects. Dont get trapped by the abstract metaphors of this temporary and arbitrary alternate universe of the desktop computer interface. Design for humans; design for direct interaction. Stephanie Rieger pointed out earlier that weve had the touchscreen for 40 years but have only begun to work out the ne points of using it for fun and effortless experiences. How does this work in practice? How do we start designing for this? What does an interface without buttons look like?
Information As Physical Object

A crucial step of designing a forward-looking touch interface is to identify how to reimagine your information and data as a physical object, something you can slide and stretch and manipulate directly. How would this information behave if I could poke at it under glass? If youre choosing a date range, maybe you can set aside the
316 |
DESIGNING FOR TOUCH
familiar desktop solution of using two date pickers. Instead, you might represent the date range itself as a physical objectand just stretch it. No buttons required. Twitters original iPad app eliminated the Back button entirely. The app was designed to encourage wide-ranging exploration, to drill a long way through tweets, proles, URLs, hash tags. Each one of those contexts, each slice of your content journey, was represented as a panel that you could physically slide. You could literally paw through your history. No need for a Back button, you could just swipe each panel aside to ip through your history.
FIGURE 7.16. The original Twitter app represented your browsing history physically,
with each stop shown as a panel. Here, the panel for the previous stop, a list of tweets, peeks out from behind the current moment, a detail view of one tweet. To go back, just swipe the panel out of the way.
BY JOSH CLARK
| 317
Every popular touch-based operating system operates on a card metaphor, ipping and swiping through views, each card representing a frozen moment in your history. Thats the Webs longstanding metaphor, too, for that matter. Mixing buttons into that interaction confuses the metaphor. When was the last time you ipped cards or pages in the real world by hitting a button?
FIGURE 7.17. Adobe Proto borrows the paper sketch notation of wireframing to make
digital wireframes. Here, drawing a big wavy line prompts Proto to insert a Lorem Ipsum header.
318
DESIGNING FOR TOUCH
Let the real world be your guide. One route to a gestural interface is to adopt gestures we already know. Adobe Proto is a wireframing app for iPad and Android tablets, and the app goes even further by adapting gestures from common written notation. You draw interface elements using squiggles familiar to information architects drawing paper sketches. Lay in some text with a wavy line, a video with a triangle or an image with a big X. This may not be any more efcient than creating a wireframe using Visio or OmniGrafe on a desktop, but its certainly the most efcient way to do it on a touchscreen. These uid sketch-like gestures create layouts much faster than you could tapping through panels of controls. The Proto example (see previous page) borrows directly from the way we work a familiar interfacepaperbut you dont have to be so literal. You can also apply real-world physics to more abstract digital objects. Our brains naturally understand and reFIGURE 7.18. Clears all-gesture interface relies on simple notions spond to these virtual elements when of physicality. To insert a list item, they behave so predictably. Clear, for example, is a to-do list app just spread two items apart to make room. for iPhone that doubles as an elegant proof of concept for representing simple data objects with physical characteristics. Lists and their items can be moved like building blocks. To insert a new item into a list, just spread your ngers between two other items to make room. Cross off items by, well, crossing them off with a swipe. Pinch a list to close
BY JOSH CLARK
| 319
it. These are simple gestures for simple physical actions, all of them mapping naturally to how you might rearrange list items if they were arranged physically on the desk in front of you. Making the digital behave physically requires coming at design problems from a new perspective. TouchUp, for example, is an iPad app that applies lters or visual effects on photos. The simplest example is just painting a color on the photo, using your nger as a brush. But what if you want to change the brush size? The traditional solution for the desktop is provide either a slider or a brush palette to choose a new size. Thing is, you already have a brushyour ngerand it doesnt change size. Offering a setting to change the impression the nger leaves on the screen would introduce uncertainty. If it doesnt match your touch, then you have no idea what will happen until you touch the screen. The game shifts from direct interaction to abstract guesswork. TouchUp handles it differently. Instead of changing the brush size, you change the canvas size. Pinch/spread to zoom in/out. And then draw your next stroke. The nger always keeps its same physical size on the screen. When you deal with touch, you have to rethink familiar solutions. With every solution, ask yourself: does the old way still make sense, or does direct interaction demand a new approach?
Whither The Web?

For the moment, the best touch interfaces are native apps. This new class of touchscreen devices creates interaction expectations that browsers arent yet very good at. For now at least, browsers dont play well with gestures, and there are a couple of reasons for this. First, JavaScript gives front-end developers only the most primitive, building-block touch events: touchstart, touchend and touchmove. That makes it easy enough to detect a touch or maybe a swipe, but anything trickier starts to get complicated. Have fun cod320 |
DESIGNING FOR TOUCH
ing a rotate or three-nger swipe. It would be ideal if we could get events for common gestures on any DOM element: pinch, long tap, swipe, rotate and more. For now, we have to build them ourselves from scratch. And thats for the browsers that even support touch events at all. On touch devices running older operating systems like Windows Phone 7 or Symbian, the browsers dont support touch events at all. The second and more vexing problem is that the browsers claim useful gestures for themselves. Like any app, the browser has its own controls and conventions, including gestures. Pinch/spread already has meaning in the browser, as does the long tap and other gestures. To use these gestures within a Web app, youd have to override the browsers standard behavior, a usability no-no. Both of these factors mean browsers hem in Web designers, practically limiting touch interactions to tap and swipe. The good news is that swipes are easy enough to implement, and were starting to see more and more websites embrace the swipe for next/previous navigation. A few website examples:
Visit Flickr on iPad, and you can swipe through the photo gal-
lery. The New York Times has a front-page carousel that you can swipe through (on desktop, you use buttons), and you can swipe to the next and previous articles from article pages. Google Images lets you swipe through search results. You can denitely do more than that in the browser, but its harder work. A fun example is Browser Ninja,10 a clone of the game app Fruit Ninja, in which pieces of fruit (or, in this case, browser icons) y up in the air, and you swipe the screen to slice them. So you can
10. smashed.by/github-ninja
BY JOSH CLARK
| 321
build multi-touch gestures from the primitive touch events JavaScript gives you, though its not easy work. Despite this progress, Web gestures remain a big challenge. For now, native apps are the real interaction sandbox, and those proprietary environments are where most innovation will occur until standards catch up, which they no doubt eventually will.
Nice Gestures: The Standards You Can Rely On

Native apps may be more technically capable than browser-based apps, but they still lack a rich gesture vocabulary. It will take time for a more sophisticated range of gestures to become common knowledge. In the meantime, only a handful of foundational gestures are common across platforms, and these are your gestural building blocks.
FIGURE 7.19. The iOS Maps app uses the double-tap technique to substitute for
what would be a hover display in a cursor-driven interface. Here, tapping on a pin displays a brief description. Tapping again on that description takes you to a detail view describing the location. 322 |
DESIGNING FOR TOUCH
Tap. This is, of course, the click of the touch universe, the allpurpose action to interact with any screen element. Importantly, its also a hover replacement. Many designers from the desktop environment regret the loss of hover from their interactive toolkit, and of course theres no such thing as hover on the touchscreen. The best you can do is use a tap to peek into an object and a second tap to actually open or activate it. As it turns out, this is also how most touchscreen Web browsers handle mouseover events and CSS :hover states, triggering mouseover/hover on the rst touch and a proper click on a second touch. Swipe. Like tap, swipe is so familiar that its uses seem obvious and limited: scroll and next/previous. Over time, however, some subtlety has crept into the gestures use. Its used to reveal hidden panels, for example, like Androids swipe-from-top to reveal statusbar notications, or the edge gestures mentioned earlier in Windows 8 to reveal the charms panel or app controls. Even better, a swipe is also ideal for a style of defensive design I call gesture jiujitsu. This technique employs a swipe instead of a tap as proof of user intent, a little bit of extra effort for actions you dont want to trigger by accident. Swipe to unlock the phone, swipe to answer a call, swipe to delete. Swipes are faster, less annoying and at least as effective as are you sure? conrmation dialogs. Long tap. This is the right click of touchscreens, typically summoning either a contextual menu of available actions or a preview of detail content. This convention is not evenly used among all operating systems. Its more commonly used in Android apps than in iOS apps, for example. Its uneven use in iOS means the long tap is typically discovered there only by expert or curious users, so its best to use it as a shortcut alternative to going to a detail screen. For the Web, most browsers already use the long tap for contextual menus for links and images. This means Web apps must override default browser behavior to put the long tap to useagain, almost always a bad idea for usability reasons.
BY JOSH CLARK
| 323
FIGURE 7.20. A long tap typically conjures a contextual menu with actions for the se-
lected element. In Twitterric for iPad, a long tap on a tweet offers options for copying the tweet or visiting its Web page.
Pinch and spread. Perhaps the most directly physical gestures, pinch and spread typically shrink and enlarge images, maps and Web pages. As noted earlier, though, pinch and spread are increasingly used for semantic zoom, zooming in and out of the information hierarchy. In that case, pinch is used to close the current view and navigate up to the level above, while spread is used to explode an element into a view that displays its member elements. Double tap. Like pinch and spread, double tap is most frequently used to zoom in and out. It has few conventional uses beyond that, making the gesture ripe for experimentation. Boston Globe,11 for example, lets subscribers double-tap a headline to save the article for later reading. Even more ripe for experimentation: multi-nger gestures. Two- and three-nger swipes, a full-hand pinch, a ve-nger
11 smashed.by/bostonglobe
324
DESIGNING FOR TOUCH
touch the sheer variety of multi-touch combinations means a slew of options for speeding through an interface. Just touching the screen with several ngers at once opens up lots of possibilities: ten ngers for ten modes. Heres the trouble: with the exception of pinch and spread, theres no mainstream meaning attached to any multi-nger gestures. In part, thats because most people are only just beginning to encounter the rst truly multi-touch devices: tablets. While phones have been multi-touch for years, we havent used them that way. One-handed use and small screens have encouraged us to tap away with a single nger or thumb. The size and weight of larger tablets, however, require you to use two hands or rest the tablet on your lap, so you always have at least one full hand free. That means tablets always have ve ngers available for gestures. Now we just have to gure out what to do with them. Standards have been slow to emerge here, and part of the problem is that as designers weve done a poor job of communicating the availability of these more abstract gestures.
Finding What You Cant See

Gestures are unlabeled, invisible. To discover them, we rely on visual clues or, even more usefully, past experience. If an interface element looks or behaves like a physical object, people will try to interact with it like one. Likewise, the less a gesture resembles a physical action, the more difcult it is to nd. This explains the effectiveness of skeuomorphic designs, interfaces that clone physical objects as digital interfaces. If an interface looks like a book, it instantly suggests that we should use it like one, swiping through pages to advance through the content. Many designers poo-poo aping real objects for aesthetic reasons, however, and its true that this approach can quickly veer into kitsch. But the intuitive teaching value of this approach cant be denied.
BY JOSH CLARK
| 325
Dont go for looks like if you cant pull o acts like. Skeuomorphic design runs into trouble as a teaching device only when the designer doesnt embrace the metaphor. For the rst 18 months of the iPad, for example, the Calendar apps leather-bound datebook didnt behave like a datebook: you couldnt turn its pages. The same is true of Contacts for iPad, only worse: swiping the screen to try to turn the address books pages actually starts deleting content. This dangerous case of misdirection shows the damage when visual design doesnt match interaction design. Be aware not only of the interactive opportunities your interface metaphor proposes but the opportunities it promises. Dont make me mash buttons to browse if your design promises that I can ip pages.
FIGURE 7.21. Oops. Swipe across the page in Contacts for iPad, and
you start deleting content.
Mouse-driven experience informs expectations, too. In Maps for iOS, newcomers easily discover that tapping twice zooms in. Thats
326 |
DESIGNING FOR TOUCH
not something they know from the physical world but from the desktop, from double-clicking in Google Maps. But you run into trouble with gestures that have no context or history. Nobody ever gures out that you can do a two-ngered single tap in iOS Maps to zoom out. Theres no experience from either physical or software maps that would suggest even to try it. Abstract gestures require visual hints. Gestures are useful only if people can nd them. Otherwise, theyre just easter eggs, hidden treats for the lucky or determinedand most users are neither. If the interface doesnt obviously suggest a gesture, then you have to teach it explicitly to your users. Everything we know is taught, learned, observed. From our earliest age, we rely on cues in the environment to help us until we obtain mastery. As our industry turns the corner into a new style of touch-driven computing, designers need to embed similar cues to help people learn the advanced moves. All too often, designers turn to manuals, FAQs and elaborate cheatsheet overlays to perform this education about the niceties of three-nger swipes and ve-nger pinches. While these are useful as references, theyre terrible learning tools. When were presented with too much detail too soon, the result is often overwhelming, giving us the impression that the app or website is more complicated than it actually is. A better approach is to teach gradually and contextually by adding a kind of teaching layer to your application or website. Theres a great way to learn how to do this.
Play More Video Games

Video game designers are great at teaching unfamiliar interfaces. In many games, you dont even know the goal of the game, let alone your capabilities or the obstacles you might encounter. How do you learn this stuff as a player? Not from reading a manual or from watching a screencast. You learn from playing the game. The game itBY JOSH CLARK
| 327
self teaches you how to play, drawing you in and showing you more advanced techniques as you demonstrate youve mastered more basic ones. Among other techniques, games lean on three tools to get this done: coaching, leveling up and power-ups.
COACHING
Telling how to do something is not nearly as effective as showing, and thats especially true of physical interfaces (which touchscreen UIs certainly are). You dont learn to play an instrument or serve a tennis ball by reading a book. Instead, someone shows you, and then you imitate and practice. We learn by doing, and we learn best in the moment. Thats what coaching is about, and thats what the best self-teaching interfaces do.
FIGURE 7.22. An overlay in Dead Space provides dead-simple coaching to tell
you how to move your character in the rst screen of the game. Once you start moving, the overlay goes away.
328
DESIGNING FOR TOUCH
In the iPad version of the game Dead Space, the very rst screen teaches you how to move, applying an overlay as a demonstration of what to do, inviting you to try it yourself. After you demonstrate that youve learned the lesson, the overlay goes away; one of the most important parts of coaching is knowing when a skill has been learned and when to move on to new skills. Coaching doesnt have to be so blatant and direct; it can also be hinted with subtle animation. When the rst USA TODAY app for iPhone was released, it featured a dial at the top of the screen to navigate main FIGURE 7.23. Adding an animasections. Trouble is, too many people tion to USA TODAYs dial-style didnt realize the dial moved and navigation control dramatically instead thought the app had only improved user awareness of how a handful of content sections. The the thing worked. designers added an animation: every time you visited the apps main screen, the dial zipped in from the right. Hey, that moves, maybe I can move it, too. It worked. With the app demonstrating the motion of the control, confusion melted away and users started using the dial as intended. Even better, the USA Today app stopped running this animation after you showed youd learned the lesson by moving the dial on your own. The best teaching interfaces mark your learning progress and adapt their coaching accordingly. Thats where leveling up comes in.
LEVELING UP
Dont teach everything all at once. We learn best by getting it in doses, building on the basics and then revealing more as we get better. Games often do this literally, dividing progress into explicit
BY JOSH CLARK
| 329
levels that typically focus on teaching a new skill in the game. Likewise, when people rst encounter a feature in your app is when you should offer coaching about gestures or other functionality. Most application and website experiences arent as linear as games, but the learning curves work the same. Teach the basic interactions rst, and, once someone demonstrates theyve learned them, move on to more complex and abstract gestures. (Its not that people cant use those advanced gestures whenever they like, its just that you dont specically teach them right away.) Were most motivated to learn a new skill at the moment we discover we need itlike, for example, when you encounter a gigantic and hugely scary guy with an enormous sword. Innity Blade is an iOS game with a wildly sophisticated combat system, but they make it easy to learn by breaking down the elements, teaching one step at a time. The game pauses at incredibly convenient moments to teach
FIGURE 7.24. Innity Blade pauses at incredibly convenient times to offer
instruction and demonstration.
330
DESIGNING FOR TOUCH
you a relevant skill. Just when the youre about to get your head knocked off, the game stops the action in freeze frame and offers to teach you to block or dodge. Again, the emphasis here is on both demonstration and practice. The game shows you the gesture or control to use and then waits for you; when you use the new gesture, the action continues and your rst interaction is a success. Now youre ready to try it out on your own. Interaction demonstrations should encourage imitation and guarantee success the rst time out. When the interaction is important enough, its okay to stop the action and force people to try the gesture in order to continue. This is the same approach that Apple used when it introduced OS X Lion, a software update that changed the way scrolling works. They turned virtual gravity upside down, so that you now moved the mouse or trackpad in the reverse direction to what you were accustomed to. To teach this change, Apple showed a little dialog right when you installed the software, explaining what was different and inviting you to try scrolling to test it out. In fact, you had to scroll because thats the only way to get to the Continue button. Scroll, click the button and BOOM: you just beat level one of Apples operating system. Think about your app as levels. Just like the best games, you want to motivate and enable people to move from novice to expert to master. How do you teach the basics and, once thats done, the advanced maneuvers? All too often we treat our apps and websites as just one level. We do a quick introduction and then release our users into the cold wilderness of our software. Embracing the concept of leveling up means you follow and teach people throughout their journey to mastery. And every so often, you should give a reward for their progress.
BY JOSH CLARK
| 331
POWER-UPS
In games, as you get better, you earn power-ups, little advantages that turbo-boost your game through some extra speed or special ability. If gestures are the shortcuts of touch, then power-ups are the shortcuts of video gamesusable by anyone but especially efcient in the hands of an expert. They not only unlock new abilities but theyre rewards, too, markers of your progress as you move through the games levels. Teaching an advanced or abstract gesture is like delivering a power-up, and it gives users a similar thrill of satisfaction that game players get from learning a new game skill. Twitters ofcial iPhone app offers a great example of where designers should have used a power-up to teach an abstract gesture. When TwitFIGURE 7.25. This simple mockter overhauled its app in late 2011, up shows how Twitter could it moved access to direct messages improve discovery of its Direct (DMs) off of the main navigation, Messages gesture shortcut. burying them a level deeper in the After tapping the DM button apps Me tab. For heavy DM users, ten times, the app should show that meant two taps every time they an instructional message with a wanted to check direct messages. To gesture animation. ease this burden, Twitter thoughtfully provided a gesture for easier access: swipe up from the Me tab to go directly to your direct messages. Trouble is, they never told anyone about it, so most people dont know the option is there.
332 |
DESIGNING FOR TOUCH
Its useful to let people learn the slow way before you teach shortcuts. In the case of Twitter, learning to tap the Me tab and then the Direct Messages button reinforces the apps mental model, teaching people where DMs live inside the app. But after doing that ve or ten times, youve demonstrated that youve learned that route. What Twitter should do at that point is deliver a power-up. After the tenth time tapping the Direct Messages button, the app should reveal the gesture shortcut with an animation to demonstrate, and then make you do the gesture in order to continue. The fact that Twitter and other apps need to teach this kind of gesture in the rst place only points up the fact that we dont yet have many common standards for gestural interfaces. Thats even more true for multi-touch gestures. That makes it both an exciting and overwhelming time for designers and consumers alike. Were all exploring this new realm of touch interaction together.
This Is A Time To Be Generous

As weve seen over and over again in the last few years, the growing range of devices and platforms continues to make our work both more exciting and more challenging. That means our job is getting harder, but its also our job, period. The ideal of the Web, after all, is a platform that can be accessed from any device, no matter what its input or output method. Like any period of invention and experimentation, sharing is more important than ever. We are, all of us together, crafting the future of a new kind of interaction with information and services: direct manipulation by touch. Opportunities for this kind of invention dont come along very often. Much of this is new, and everyones ying by the seat of their pants. We need conventions as soon as possible but no sooner. Its dangerous to lock in on ideas before theyre fully baked.
BY JOSH CLARK
| 333
That means its more important than ever to try new things, to throw everything weve got at the drawing board. As designers, we need to talk to each other, examine each others work, share ideas for gestural conventions and commit to establishing them. We have our own coaching and leveling up to do here. Throughout, its important to remember that insightful work is part technical know-how (44-pixel touch targets!), but its empathy, imagination and an expansive worldview that generate breakthroughs. Grab your touchscreens, think big and go make something amazing.
ABOUT THE AUTHOR
Josh Clark is specialized in mobile strategy and UX. He is the founder of Global Moxie, a company which helps organizations build tapworthy mobile apps and effective websites. The most important lesson he has learned in his career: Technical knowledge doesnt stand up for long. Values, principles, and ideas are what count. Figure out what matters to you, why youre in this business, and hold on tight to that. The rest will follow.
334
DESIGNING FOR TOUCH
INDEX
accessibility, 315 accordions, 145f. AMOLED, 70f. Android, 27, 294 app caching, 191 bandwidth, 150 behavior, 154 big design up front (BDUF), 263, 282f. browser caching, 193 browser detection, 49, 214 browser icons, 321 browser reow, 207 browser-centric workow, 113 buttons, 95, 100, 326 caching, 191 canvas-as-page, 229 card emulation mode, 76 card metaphor, 318 column drop, 133 complex navigation, 142f. concatenation, 193ff. conditional loading, 146 connected fridges, 60 connected things with screens, 59 connected TVs, 59 content choreography, 114 content planning, 243, 254, 279 content reference wireframe, 258ff. data tables, 169ff. data URI, 205ff. databases, 229 default browser, 36f. design funnel, 239f. design hypothesis, 269 device lab, 45ff. device market, 20, 29 device vendors, 12, 18 differentiation, 26ff. discoverability, 315 discovery service, 69 display: none, 180ff. downloadable browser, 36f. dual-screen behavior, 59 e-paper, 70ff. fast buttons technique, 209 fat-nger errors, 295 nger-friendly, 306 Fitts law, 312 exbox, 120 exible AMOLED displays, 71 exible grids, 93f. exible images, 97 uid typography, 125 y-out navigation, 136 forms, 167 fragmentation, 10, 26f. front-end style guide, 127, 130 full browsers, 34 group sketching, 246 hardware layer, 30 heads-up displays (HUD), 73f. high-delity prototyping, 278 HTML prototyping, 268ff. HTTP Archive (HAR) le, 185f. hybrids, 302ff. hypothesis, 236 icon fonts, 153 icons, 152f. image aspect ratios, 97 image optimization, 100, 195f. information architecture, 254, 268 installed base, 21, 25f. interactive wireframes, 265, 285 Internet of Things, 59, 67 intrinsic ratio, 98f., 157 IoT technologies, 68 iPad, 156, 299ff. iPhone, 44, 55ff. JavaScript libraries, 50 jQuery plugins, 98, 125f.
latency, 178f. lazy loading, 202 localStorage, 200ff. maintenance, 220, 255 media objects, 157 media queries, 102, 134, 180 media queries, vertical, 108, 137 media query breakpoints, 105 minication, 193ff. mobile network, 51, 178 mobile operators, 14 mobile optimization techniques, 188 mobile value chain, 12 molten leading, 127, 160 Moores Law, 230, 58 multi-layout system, 236 multi-toggle, 143 multi-touch gestures, 315, 322, 333 narratives, 248 navigation accessibility, 145 near eld communication (NFC), 56 network of content, 93, 111 network speed, 105 network-area storage (NAS), 64 ninja blocks, 81ff. object-oriented CSS (OOCSS), 271 open device labs, 46f. Opera, 39 operating system sales, 23ff. operating system vendors, 12 operators, 14ff. opt-out responsive design, 172 P2P mode, 76f. page table, 255ff. paper prototypes, 250ff. pattern libraries, 272 point-of-purchase (POP), 68 progressive disclosure, 165 prototyping behavior, 264, 278 prototyping style, 272, 279
proxy browsers, 34ff., 47 Pughs Funnel, 239 read/write mode, 76 resolution independence, 100 responsive breakpoint, 134 responsive image hierarchy, 122f. responsive Web design, 92 RESS, 211ff. RFID, 74ff. sales, 21ff. semantic zoom, 314, 324 sensors, 81 server-side breakpoints, 216 simulating bandwidth, 187 sketchboards, 250 sketching techniques, 245f. sketching workshops, 250 skeuomorphic designs, 325 Smart TVs, 59, 83 software layer, 30 Sonos system, 64f. sprites, 206f. stick-gure comics, 247 style prototype, 274 style tiles, 113, 131, 272 sub-navigation panel, 234 tabbed navigation, 234 tablets, 53 tap targets, 291ff., 308 thumb, 290 toggle, 140 toolbar icons, 266 vary header, 219 W3C Device APIs, 78ff. waterfalls, 185f. WebKit, 37f. webOS, 32 website weight, 176f. Windows Phone, 28f. wireframing, 260ff.

The Mobile Book PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Mobile Book PDF

Uploaded by

Copyright:

Available Formats

e Mo b i l e B o o k

THE MOBILE BOOK

Foreword by Jeremy Keith

PART ITHE MOBILE LANDSCAPE

PART IIRESPONSIVE WEB DESIGN

PART IIIUX DESIGN FOR MOBILE

The Mobile Landscape

8 | WHATS GOING ON IN MOBILE?

WHATS GOING ON IN MOBILE?

The Mobile Value Chain

BY PETER - PAUL KOCH |

BY PETER - PAUL KOCH |

16 | WHATS GOING ON IN MOBILE?

Operators can establish a consumers identity much more easily

Device Vendors and Hardware

18 | WHATS GOING ON IN MOBILE?

China Canada Japan China Korea US Varies -

Android BlackBerry Android Android Android Android Android, Symbian -

22 | WHATS GOING ON IN MOBILE?

BY PETER - PAUL KOCH |

SMARTPHONE OS SALES MARKET SHARES FOR Q2 OF THREE YEARS

All but Apple, Nokia, and RIM

iOS BlackBerry Symbian

Apple RIM Mainly Nokia

Apple RIM Nokia, some Japanese

19% 12% 16%

14% 18% 44%

Windows Phone bada MeeGo Other Phones sold (in millions)

Samsung Nokia Varies -

Samsung Nokia Many -

24 | WHATS GOING ON IN MOBILE?

Germany France Australia

Android iOS BlackBerry Symbian Windows Phone bada Other

57% 26% 11% 2% 4%

FIGURE 1.4. Source: ComTech, smashed.by/android-rules.

BY PETER - PAUL KOCH |

SMARTPHONE OS INSTALLED BASE FOR Q2 OF THREE YEARS

FIGURE 1.5. Source: Tomi Ahonen. smashed.by/2012-market, smashed.by/2011-nal-numbers.

26 | WHATS GOING ON IN MOBILE?

OS Vendors and Software

34 | WHATS GOING ON IN MOBILE?

3. The proxy server contains a rendering engine (Presto, in the case

38 | WHATS GOING ON IN MOBILE?

1. How does the statistics service

2. What is the geographic spread of

BY PETER - PAUL KOCH |

MOBILE BROWSER MARKET SHARES FOR Q2 OF 3 YEARS

Symbian browser and S40 Ovi proxy browser

UC* BlackBerry NetFront

For Samsung bada For Samsungs non-Android, non-bada phones

For Windows Phone A lot of minor browsers

42 | WHATS GOING ON IN MOBILE?

FIGURE 1.7. Source: StatCounter, smashed.by/statcount.

BY PETER - PAUL KOCH |

Iconic and game-changing, this phone needs no introduction.

Developing Mobile Websites

BY PETER - PAUL KOCH |

BY PETER - PAUL KOCH |

50 | WHATS GOING ON IN MOBILE?

Operators could handle identity and payments much more eas-

54 | WHATS GOING ON IN MOBILE?

THE FUTURE OF MOBILE

Trend: Everyone Will Be Connected