Building Responsive Data Visualization for the Web E-Book

Bill Hinderman

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 404

Veröffentlichungsjahr: 2015

Beschreibung

Unchain your data from the desktop with responsive visualizations Building Responsive Data Visualization for the Web is a handbook for any front-end development team needing a framework for integrating responsive web design into the current workflow. Written by a leading industry expert and design lead at Starbase Go, this book provides a wealth of information and practical guidance from the perspective of a real-world designer. You'll walk through the process of building data visualizations responsively as you learn best practices that build upon responsive web design principles, and get the hands-on practice you need with exercises, examples, and source code provided in every chapter. These strategies are designed to be implemented by teams large and small, with varying skill sets, so you can apply these concepts and skills to your project right away. Responsive web design is the practice of building a website to suit base browser capability, then adding features that enhance the experience based on the user's device's capabilities. Applying these ideas to data produces visualizations that always look as if they were designed specifically for the device through which they are viewed. This book shows you how to incorporate these principles into your current practices, with highly practical hands-on training. * Examine the hard data surrounding responsive design * Master best practices with hands-on exercises * Learn data-based document manipulation using D3.js * Adapt your current strategies to responsive workflows Data is growing exponentially, and the need to visualize it in any context has become crucial. Traditional visualizations allow important data to become lost when viewed on a small screen, and the web traffic speaks for itself - viewers repeatedly demonstrate their preference for responsive design. If you're ready to create more accessible, take-anywhere visualizations, Building Responsive Data Visualization for the Web is your tailor-made solution.

Leseprobe

CONTENTS

Part ONE: Creating the Responsive Web

Chapter 01: The Mobile Web

How We Got Here

The Mobile Web Today

Mobile Web Design

Summary

Chapter 02: Responsive Web Design Tenets

The Gist

Adaptive vs. Responsive

Desktop-First vs. Mobile-First

Four Principles

Seven Points of Focus

Summary

Chapter 03: Working with a Flexible Grid

The Gist

Flexible Units

Using a Grid System

Creating a Reusable, Flexible Grid (in Five Easy Steps)

Summary

Try It

Chapter 04: Designing Responsive Layouts with CSS

The Gist

Responsive Layout Design

The Reusable Responsive Grid

Summary

Try It

Chapter 05: Enhancing with JavaScript

Using JavaScript

Responsive JavaScript

Limber Up

Summary

Try It

Part TWO: Creating Responsive Data Visualization

Chapter 06: Data Design: An Abridged History

Learning From Data

The Big Pile

What You Get from the Web

Summary

Chapter 07: Responsive Data Visualization Tenets

Designing Content-First

Revisiting Responsive Design Principles

Seven Points of Focus

Responding to Data

Summary

Chapter 08: Thinking Small

Designing for the Smallest Canvas: No Canvas

The Tiny Canvas

Enhancing Efficiently

Summary

Chapter 09: Asset Dependence

Dynamic Data

Tying Visualization to Screens

Summary

Try It

Chapter 10: Code-Driven Visualization

Unknown Inputs and Outputs

Using D3.js

Building Responsive Data Visualization for the Web

Driving Design with Data

Summary

Try It

Chapter 11: Building the Future-Friendly Web

The Future of Data Design

Embracing Uncertainty

Responsible Web Design

Summary

Part THREE: Additional Resources

Appendix A: Resources

Responsive Data Visualization

Grids

Infographic Design

Responsive Design

D3.js

More Resources Online

Titlepage

Copyright

Credits

Dedication

About the Author

About the Technical Editor

Acknowledgments

End-User License Agreement

List of Tables

Table 1-1

Table 4-2

Table 4-3

Table 5-1

Table 6-1

Table 7-1

Table 8-1

Table 8-2

Table 8-3

Table 10-1

Table 10-2

Table 10-3

List of Illustrations

Figure 1-1: The first website, now housed at http://info.cern.ch/hypertext/WWW/TheProject.html

Figure 1-2: PC sales from 1995–2007

Figure 1-3: Overview of mobile-related web markup languages

Figure 1-4: The iPhone: a game-changer

Figure 1-5: PC sales and mobile device sales from 1995–2013

Figure 1-6: In 2011, yearly mobile device sales outpaced PC sales.

Figure 1-7: The first website (1990), displayed on an iPhone (2014)

Figure 1-8: Each layer is built upon the preceding one, with the core idea as the foundation.

Figure 2-1: Without RESS to handle image size, this image is massive.

Figure 2-2: With RESS, you can cut the image’s payload by sending a smaller size from the server.

Figure 2-3: An adaptive layout at three screen widths between 320px and 1200px

Figure 2-4: A fluid responsive layout at three screen widths between 320px and 1200px

Figure 2-5: On the left is the process flow for designing desktop-first. On the right, you end up with a similar product to the end user, but the flow begins mobile-first.

Figure 2-6: The web

Figure 2-7: The mobile web (Spoiler: It’s the same.)

Figure 2-8: How your brain is trained to think about web design

Figure 2-9: Reality

Figure 2-10: The birthplace of web design

Figure 2-11: On the left, a static layout as the screen size changes. On the right, a layout with fluid measure at changing screen sizes

Figure 2-12: A layout built with absolute sizes, on three different sizes of device

Figure 2-13: A layout built with fluid sizing, on three different sizes of device

Figure 2-14: A layout with no nesting. On the left, there are no margins; on the right, you use CSS to apply margins.

Figure 2-15: A layout with nested containers. The HTML and CSS produce the same look. The nested container, although invisible, is highlighted in purple.

Figure 2-16: A nested layout with no endpoints. These sections will scale indefinitely. Notice that the sidebar gets tiny on smaller screens and huge on big screens.

Figure 2-17: Adding a max-width and min-width to the container. This caps the container’s width at 960px at the top, and 320px on the bottom, keeping the content and sidebar at a maintainable size.

Figure 2-18: Our layout without any breakpoints

Figure 2-19: The layout without a breakpoint at 768px, which is set as the width of your medium-sized device

Figure 2-20: On the left is an example of raster scaling; on the right, vector scaling. Notice that as large as the vector image gets, no crispness is lost.

Figure 3-1: A poster that includes the grid system as part of its visual design. Visible or not, it would be present.

Figure 3-2: Unstyled output of the example code

Figure 3-3: Client’s ideal mockup of what the heading and link should look like

Figure 3-4: Result after adding styles to the

<body>

and

<h1>

Figure 3-5: Finished output in the browser, using fixed-pixel values

Figure 3-6: Output of a first attempt at flexible font-size values. Notice the link size is incorrect.

Figure 3-7: Layout for the blog project

Figure 3-8: A 12-column grid overlaid on the blog layout

Figure 3-9: The 12-column grid, without the layout

Figure 3-10: The current blog design. Who knows what the code looks like?

Figure 3-11: The current blog design with the same 12-column grid as an overlay

Figure 3-12: The blog’s starting point, without any of the actual layout work done

Figure 3-13: A little math

Figure 3-14: More math

Figure 3-15: The quote is supposed to take up the content’s full width, but this breaks outside of the article’s boundaries.

Figure 3-16: The header’s internal padding keeps it in a column with the blog’s main content.

Figure 3-17: The five components of a reusable grid

Figure 3-18: The five components of a reusable grid overlayed on your previous blog project

Figure 4-1: Layout of an unstyled table in a browser. Notice that items line up by row and column.

Figure 4-2: Output of the styled list of links. Priority and specificity are in effect here.

Figure 4-3: Unstyled markup of the preceding code

Figure 4-4: The same markup, after the preceding styles are applied. Note that the link inherits some, but not all, styles from the heading.

Figure 4-5: Unstyled output of the preceding code

Figure 4-6: Designer’s mockup of what your blog should look like on a large screen

Figure 4-7: Your code’s output, which now matches the design. Hooray!

Figure 4-8: Your page on a tablet-size screen

Figure 4-9: Your page on a mobile-size screen

Figure 4-10: Your page on a tablet-size screen after changing the base font size to 1.5 em

Figure 4-11: Your page on a tablet-size screen after changing the base font size to 1em

Figure 4-12: Browsers being liars. The left shows a website without the correct viewport meta tag, the right with it.

Figure 4-13: Rules applied to an element on a mobile device using max-width overrides

Figure 4-14: Rules applied to an element on a mobile device using min-width overrides

Figure 4-15: Your list, with no styles applied

Figure 4-16: The designer’s desired output for the list of links

Figure 4-17: The list of links really doesn’t work on mobile screens.

Figure 4-18: For mobile devices, default the links to take up 100% width.

Figure 4-19: Once you have enough space, let the links take up 50%, floating next to one another in a 2x2 grid.

Figure 4-20: Finally, back at 960px, the links occupy 25%, again matching the designer’s wishes.

Figure 4-21: The Cocktail Guide’s list view on a mobile-size screen

Figure 4-22: The Cocktail Guide’s list view on a medium-size screen. The results now stack 3-up.

Figure 4-23: The Cocktail Guide’s list on a desktop-size screen. Not only do the results now stack, but the menu has moved to a left column sidebar.

Figure 5-1: Google’s instant search results in action

Figure 5-2: Doing the same search without JavaScript enabled removes all the instant search functionality.

Figure 5-3: Facebook without JavaScript enabled is entirely unusable.

Figure 5-4: The menu toggle on the top left of the Cocktail Guide

Figure 5-5: The Cocktail Guide’s menu

Figure 5-6: The menu attached to the left of the browser window

Figure 5-7: Both the menu and results are shown next to one another when there is enough screen space.

Figure 5-8: A subway-tracking website. All you populate at page load is the main list of route links.

Figure 5-9: Visual feedback of progress after a user selects the blue line but before its stops have been loaded

Figure 5-10: The line’s stops have been loaded dynamically into the page without a refresh.

Figure 5-11: Progress indicator while content is being fetched and AJAX-loaded in for an individual stop’s ETA information

Figure 5-12: An individual train stop’s data after successful loading

Figure 5-13: Just-in-time feature detection. The site asks for location services only if the user tries to use them. Notice the progress indicator on the Closest Stop button.

Figure 5-14: Successful location services used, and data loaded

Figure 6-1: Sign for a washroom your author should use

Figure 6-2: Sign for a washroom your author shouldn’t use

Figure 6-3: A bar chart. Sets are described along the x-axis, while their measure is communicated on the y-axis.

Figure 6-4: A stacked bar chart. Both the sets themselves and the parts within them are represented.

Figure 6-5: A histogram. Like a bar chart, but for continuous data on one set

Figure 6-6: A pie chart. Each slice makes up a part of the whole.

Figure 6-7: A donut chart

Figure 6-8: A scatter plot. Two variables can be plotted against each other to identify otherwise unknown patterns and relationships.

Figure 6-9: A line chart. The y-axis represents a measurable variable, while the x-axis represents a time series.

Figure 6-10: A stacked area chart. Cumulated totals over time are shown.

Figure 6-11: A Dorling map. It can show at least three dimensions of data, based upon size, clustering, and the x,y location of a bubble.

Figure 6-12: A Venn diagram. Two sets of data and their overlapping items are represented.

Figure 6-13: A nested Venn diagram. The largest circle is the least exclusive set, while each smaller circle represents a subset.

Figure 6-14: A network diagram. Relationships between vertices (the dots) are shown as edges (the lines).

Figure 6-15: A cartogram. It’s a map, but shows a different kind of information.

Figure 6-16: A radar chart. Multiple variables can be charted from the same initial point to determine where patterns may exist among multiple data sets, and whether there are any obvious outliers.

Figure 6-17: A tree map. Data that is more prevalent takes up more space.

Figure 6-18: A heat map. Data points that cluster are shown with greater “heat.”

Figure 6-19: A timeline. Events are shown in chronological order.

Figure 7-1: The train tracker website you constructed in Chapter 5

Figure 7-2: The train tracker without any styling

Figure 7-3: A small fraction of the screen sizes for which you build

Figure 7-4: A summary view of flight prediction information

Figure 7-5: A detailed view of flight prediction information

Figure 7-6: Progress indicator showing a loading state in the train tracker

Figure 7-7: A layout with static (left) and fluid (right) measure

Figure 7-8: A static website that doesn’t properly reflow

Figure 7-9: A website with proper flow

Figure 7-10: A fluid layout with no end points

Figure 7-11: A fluid layout with end points

Figure 7-12: A breakpoint set at mobile changes this layout

Figure 8-1: A train stop in your train tracker application

Figure 8-2: The Apple Watch fitness app’s default screen

Figure 8-3: After interacting with any ring on the default screen (or swiping), one of these views is shown.

Figure 8-4: At an even more granular level, this view provides a timeline showing when activity took place throughout the day.

Figure 8-5: The cocktail guide’s drink page, on a small screen

Figure 8-6: The cocktail guide on a medium screen. Notice the content shifting next to the visualization.

Figure 8-7: The cocktail guide on an even larger screen. There is very little change to the visualization, because making it any bigger would ultimately distract from its meaning.

Figure 9-1: The outputted DOM from the D3 SVG insertion

Figure 9-2: The DOM created by your data-bound D3 code

Figure 9-3: The DOM after many elements have been added

Figure 9-4: The DOM after many elements have been added and removed

Figure 10-1: A data visualization is just another block of content on a page.

Figure 10-2: Ignoring the rest of the page, responding to data is a function of the elements within the visualization itself.

Figure 10-3: Result of the D3 code using the i parameter

Figure 10-4: On the left: An image that works well as a raster. On the right: An image that works well as a vector

Figure 10-5: A circle in SVG

Figure 10-6: The same SVG circle, styled by CSS

Figure 10-7: Two SVGs, both styled by CSS. Although their markup is the same, they have separate classes that result in different styling.

Figure 10-8: An SVG circle that changes color when the screen size exceeds 600px

Figure 10-9: The original four SVG squares

Figure 10-10: The four squares are now blue.

Figure 10-11: The four squares are now rectangles with random widths, based on the D3 function applied.

Figure 10-12: The rectangles now have widths backed by their bound data. Although primitive, this is a data visualization.

Figure 10-13: The rectangles now change size based upon both their bound data and their index in the selection array.

Figure 10-14: This isn’t right. The original squares didn’t change.

Figure 10-15: That’s more like it. By using both data and enter, the rectangles have been properly drawn.

Figure 10-16: After exit, only three elements remain.

Figure 10-17: A nonresponsive bar chart

Figure 10-18: Ungrouped data. Notice the oddly thick and jagged line.

Figure 10-19: Grouped data. Not only does it look slightly better, it is much less taxing on the browser.

Figure 10-20: A bar graph created manually

Figure 10-21: The server-side generated D3 SVG visualization

Figure 11-1: The future-friendly web badge

Figure 11-2: The simple view of progressive enhancement you began with

Figure 11-3: Progressive enhancement in the wild, with its additional inputs and outputs

Guide

Cover

Part ONE: Creating the Responsive Web

Chapter 01: The Mobile Web

Start Reading

Chapter 02: Responsive Web Design Tenets

Chapter 03: Working with a Flexible Grid

Chapter 04: Designing Responsive Layouts with CSS

Chapter 05: Enhancing with JavaScript

Part TWO: Creating Responsive Data Visualization

Chapter 06: Data Design: An Abridged History

Chapter 07: Responsive Data Visualization Tenets

Chapter 08: Thinking Small

Chapter 09: Asset Dependence

Chapter 10: Code-Driven Visualization

Chapter 11: Building the Future-Friendly Web

Part THREE: Additional Resources

Appendix A: Resources

Title Page

Front Matter

Dedication

End-User License Agreement

Pages

1

3

4

5

7

12

13

14

15

16

17

18

19

20

22

23

25

26

27

28

29

30

31

33

34

35

36

38

39

40

42

43

45

46

47

48

49

50

51

53

54

57

58

60

61

62

63

64

65

66

67

68

69

71

72

73

74

75

76

80

81

82

83

84

86

87

88

90

91

92

93

94

95

96

97

98

99

101

102

103

104

105

106

107

108

111

112

113

114

116

118

119

120

121

122

123

124

125

126

127

128

131

132

133

135

137

138

139

140

142

143

144

145

146

147

148

149

151

152

153

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

175

177

178

179

180

181

182

183

185

187

188

189

190

191

192

193

194

195

196

197

199

201

205

206

210

211

212

213

214

215

217

218

219

220

221

223

224

225

226

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

249

251

252

253

254

255

256

257

258

259

260

261

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

283

284

285

286

287

290

291

293

294

295

296

297

298

299

300

301

302

303

304

305

306

308

309

310

311

312

313

315

316

317

320

321

322

323

324

326

327

329

330

331

332

333

334

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

354

355

357

358

359

360

362

363

364

365

366

367

368

369

371

372

373

375

376

377

378

379

380

381

382

383

385

386

388

389

391

393

394

395

396

iii

iv

vii

ix

xiii

Part ONECreating the Responsive Web

Chapter 01: The Mobile Web

Chapter 02: Responsive Web Design Tenets

Chapter 03: Working with a Flexible Grid

Chapter 04: Designing with CSS

Chapter 05: Enhancing with JavaScript

Chapter 01The Mobile Web

Before discussing responsive data design, it is important to set the stage with a brief overview of how we got here. The evolution of the mobile web does not exist in a vacuum; it is built upon the foundation of 25 years of the Internet’s growth.

In this chapter, we’ll touch upon the beginning of the consumer Internet, and how it became commercialized. We will then move on to the shift from desktop computers to mobile devices as the primary way to access the web.

Finally, you will gain an understanding for what the mobile web’s landscape looks like today by exploring how the screens currently used came to be, and what will become their logical successors.

Plus, you will end up with great conversation starters for the world’s nerdiest cocktail party.

How We Got Here

Think about the device you have in your pocket or in your hand right now. You have an absolutely godlike amount of computing power inside a device the size, shape, and fragility of a toaster pastry. Not only can it do miraculous things like calculate your age from a picture of your belly button, but it can also talk to all of the other devices on the planet and shame you for missing your morning run.

Back in the 1950s, though, computers were massive room-filling calculators that couldn’t say anything to one another. Computer science labs across the United States, Great Britain, and France were working on that “couldn’t say anything to one another” part, though. Throughout that decade, and into the 1960s, packet networking systems (what humans call the Internet) had been contracted by the United States Department of Defense. The first ARPANET (what would become the first network to use the Internet Protocol) link was established between the University of California, Los Angeles (UCLA) and the Stanford Research Institute on October 29, 1969. The messages went as follows:

“We set up a telephone connection between us and the guys at SRI ...,” Kleinrock ... said in an interview: “We typed the L and we asked on the phone, ‘Do you see the L?’”

“Yes, we see the L,” came the response.

We typed the O, and we asked, “Do you see the O.”

“Yes, we see the O.” Then we typed the G, and the system crashed.

From Gregory Gromov’s Roads and Crossroads of the Internet History (www.netvalley.com/cgi-bin/intval/net_history.pl)

Access to the ARPANET was expanded in 1981 with the creation of the Computer Science Network. A year later, the Internet protocol suite (TCP/IP) became the standard networking protocol on that network.

The Web’s History

So, the history of the Internet begins in the late 1950s when those big computers couldn’t talk, and it takes 19 years for the first conversation. So, naturally, let’s begin our lesson in 1980, with the history of the web.

The web is a way of accessing information over the Internet. That is, it’s an information-sharing model that is built on top of the Internet, using a standard hypertext transfer protocol (HTTP).

Tim Berners-Lee was an English-born contractor working at the European Organization for Nuclear Research (CERN) in Switzerland. In 1980, he became fascinated with the concept of hypertext. In the simplest terms, hypertext is text displayed in a digital form that references and provides linked access to other text. Berners-Lee built ENQUIRE, a hypertext database system to catalog people and software models. If you’ve ever used a wiki, like Wikipedia, you can grasp the core of what he was building with ENQUIRE. It was a database of hypertext information within which other related information was accessible through hyperlinks.

Early Days

By the mid-eighties, Berners-Lee had left and returned to CERN, still working on a solution to a seemingly intractable problem: Physicists around the world lacked a way to communicate data uniformly. In 1984, TCP/IP protocols were installed on a few machines at CERN, making it, at the time, the largest collection of things that make the Internet the Internet in all of Europe.

In 1989, Berners-Lee wrote a proposal for a “large hypertext database with typed links.” He began creating this database on a NeXT computer workstation, and called the project the World Wide Web.

By the end of 1990, the World Wide Web was beginning to take shape as something similar to what we know today. Hypertext Transfer Protocol (HTTP) and Hypertext Markup Language (HTML) were in a working state, and the first HTTP server software and web server went online. Accompanying these were the first web pages, which described the World Wide Web project itself. Figure 1-1 shows the earliest known website. The first web browser also came online, as a project housed at CERN.

Figure 1-1: The first website, now housed at http://info.cern.ch/hypertext/WWW/TheProject.html

A pivotal moment came on August 6, 1991. Berners-Lee posted a short summary of what was then called the “World Wide Web” project on the alt.hypertext newsgroup. The summary’s opening was deceptively simple, considering its significance:

The WorldWideWeb (WWW) project aims to allow links to be made to any information anywhere.

Tim Berners-Lee

This summary marked the web’s introduction as a publicly available Internet service, rather than just a private project at CERN.

The Consumer Internet

The web was first made publically popular by the Mosaic browser, which was launched by a team at the National Center for Supercomputing Applications (NCSA) at the University of Illinois at Urbana-Champaign (in a building where I once spent eleven hours as an undergrad trying to get an MS Paint drawing of a mouse to solve a maze programmatically).

The browser was graphical (as opposed to strictly textual as in some previous browsers), and became popular due to its rapid feature growth and support of multimedia.

After graduating from the University of Illinois, the team’s lead, Mark Andreessen, formed Mosaic Communications Corporation to develop the browser in a commercial capacity. In April 1994, the company changed its name to Netscape, and the browser was renamed Netscape Navigator.

That same year, PC sales reached a respectable 59 million (M) units shipped.

The Rise (and Fall) of PCs

By 1996, that number had jumped to nearly 70M units sold per year—a trend that only escalated, reaching close to 150M PCs sold in 2000. And during this period, the web continued to expand and occupy a greater part of the digital landscape.

An entire industry grew out of the seemingly limitless potential of the web. The “dot-com bubble” refers to this period, from roughly 1997 through 2000, during which startup companies with entirely Internet-based businesses were formed and received venture capital, intending to change the world by ushering in a new renaissance—one in which we would all have golden toilets and hovercraft and a soda fountain in our kitchen…

Oh.

So it wasn’t limitless, but the companies that could survive did; and despite a one-year slowdown, PC sales continued to grow. Along with them, new browsers entered the market and gained popularity. Microsoft launched Internet Explorer, Mac had Safari, along with open-source projects such as Firefox and Opera. More recently Google Chrome has taken the lion’s share of the market. Figure 1-2 shows the amount of PCs sold annually from 1995 through 2007.

Figure 1-2: PC sales from 1995–2007

The Rise of Mobile Devices

During this time, it turns out we weren’t all in such awe of PCs and the Internet that we decided to stop making other technological advances. Cell phones were evolving from simple green-screened boxes, to sophisticated full-color screens used to play Snake, to machines that began to reach the web.

In the meantime, the web itself continued to grow and evolve. The basic timeline of web markup advances can be simplified to the graph shown in Figure 1-3.

You may have noticed that Figure 1-2 ends at 2007. Of course, the Internet didn’t end that year. The diagram stops there because something transformational emerged that year: the iPhone (see Figure 1-4).

From this point forward, mobile phones began to look and act much smarter, hence their new name “smartphone.” With these little pieces of glass, we could now interact with not just a subset of the web, or some web-like features, but the entire web.

Figure 1-3: Overview of mobile-related web markup languages

Figure 1-4: The iPhone: a game-changer

As shown in Figure 1-5, which illustrates the phenomenal trajectory of sales of these devices, we really wanted to do that.

Figure 1-5: PC sales and mobile device sales from 1995–2013

As you can see, mobile device sales beginning in 2007 had a few good years, and then several great years. We’re still in that great category. Mobile device sales have skyrocketed and, as of yet, show no sign of slowing.

The Mobile Tipping Point

In 2011, mobile device sales actually surpassed PC sales (see Figure 1-6). A market already saturated with smartphones received a further sales acceleration with the introduction of a third class of devices: tablets.

According to a Pew Internet survey (www.pewinternet.org/2012/06/26/cell-internet-use-2012/), 55% of Americans said they had used a mobile device to access the Internet in 2012. More shocking than that, 31% of these mobile users said that those devices are the primary way in which they access the web.

Mobile-Heavy Usage

An absolutely ludicrous misconception (that I hear nearly daily) about mobile devices is that it is totally fine for them to offer only a subset of the desktop version’s content. Misinformed product managers make the argument that users only need quick, focused tools on their phones. To determine whether this reasoning has any merit, we can look at numbers from some of the top-visited websites in the world.

Figure 1-6: In 2011, yearly mobile device sales outpaced PC sales.

In 2009, less than two years after the mobile tipping point, Facebook’s mobile users accounted for roughly 13% of its total traffic (20M of 150M). Even in that short time frame, that is not a negligible number. However, by mid-2012, mobile users accounted for more than 50% of Facebook’s traffic. As of summer 2015, a staggering 78% of monthly U.S. Facebook traffic comes from mobile devices (newsroom.fb.com/company-info/#statistics). The other social media giant, Twitter, asserts that 80% of its entire user base is primarily using mobile devices (https://about.twitter.com/company).

Outside of social networking, move than half of all YouTube views now come from mobile devices (www.youtube.com/yt/press/statistics.html). In 2015, year over year mobile revenue on YouTube is up 100%.

Pew Research has reported that 50% of teenage (13–17) smartphone owners use the Internet mostly or exclusively on that device (www.pewinternet.org/2015/04/09/teens-social-media-technology-2015/). Similarly, 45% of adults between the ages of 18–29 mostly use the Internet on their mobile devices.

Mobile Commerce

“But wait,” you may be thinking, “those are only multi-billion-dollar social networks that changed the way we interact on a daily basis. What about e-commerce?” Here’s the thing:

In 2011, $4 billion of eBay’s gross sales came from mobile shoppers. In 2012, this number grew to $13B. In a rather ballsy fashion, eBay expected this trend to hold, and projected that 2013 sales from mobile would reach $20B (techcrunch.com/2013/01/16/ebay-and-paypal-expect-to-do-20-billion-each-in-2013-mobile-commerce/, techcrunch.com/2011/10/09/ebay-vp-steve-yankovich-en-route-to-4b-in-gross-mobile-sales-tctv/). They were pleasantly surprised by an extra $2B in mobile sales on top of that.

Moreover, not only were sales from mobile browsing astronomical, 36 million of eBay’s incremental accounts and users registered on mobile, accounting for 40% of new users (www.mobilecommercedaily.com/ebay-downplays-offline-retail-play-as-mobile-volume-swells). In 2013, I couldn’t name a single person who hadn’t either

had an eBay account for at least five years, or

decided they were never going to need one.

A property then owned by eBay, PayPal, experienced a similar surprise. They, too, projected mobile sales volume to reach the $20B mark in 2013. Actual sales numbers, however, were comfortably at $27B (http://bankinnovation.net/2014/01/paypal-processed-27-billion-in-mobile-payments-in-2013/ ) instead. PayPal takes 2.9% of each sale, plus 30 cents. If we estimate the average transaction amount of these sales at a conservative $25, that means that PayPal made a surprise extra $287M off of those $7B in mobile sales that outpaced their own projections.

In August 2014, the founder and CEO of Shopify, an e-commerce platform that powers more than $5B in annual gross merchandise volume, posted this to the company’s blog:

Last week represented the first time in history that more people used mobile phones and tablets to visit online stores than using computers. Looking at data from over 100,000 ecommerce stores that use the Shopify platform, we saw 50.3% of traffic coming from mobile (40.3% from mobile phones, 10% from tablets) and just 49.7% from computers.

Tobi Lütke (Founder, CEO, Shopify)

Clearly, web creators can no longer afford to ignore mobile device users, because in doing so they will be ignoring the majority of their users.

The Mobile Web Today

In April 2013’s “Communications of the ACM (Association for Computing Machinery),” web technologist Nicholas C. Zakas wrote that mobile phones, at present, were more powerful that the Apollo Guidance Computer used in the 1969 lunar landing of Apollo 11. However, despite their power, the mobile devices of 2013 still suffered from web performance and connection problems similar to those of the early (~1996) stages of the consumer Internet.

Zakas continues, explaining that mobile devices have “high-latency connections, slower CPUs, and less memory” than their desktop counterparts. These devices have slower download request and response times, and need to account for the latency of wireless data transmission.

As a result, we, as developers and designers, must rethink web applications, which were previously geared toward these desktop experiences with wired connections, fast CPUs, and almost endless memory.

Mobile Web Considerations

In terms of building apps for this evolving state of the web, you should keep several considerations in mind. The following sections describe not so much rules or limitations, but rather ergonomic “tent poles” that should guide and support how you craft the user’s web experience.

Small Screen Size

Let’s start with the most obvious: Phone screens are considerably smaller than computer monitors. Although it’s impossible to pick a standard mobile screen size, a good rule of thumb is to start supporting content around 320px (20em at 16px) wide, and grow upward as the content can support it.

Navigation

Coupled with small screen size for any main content is the lack of real estate available for all the navigational tools we take for granted when using big screens.

Compared to a desktop screen, every scrollbar, notification, or menu that remains fixed on the page takes up a much higher percentage of total available space. As such, we must find new navigation patterns to smartly hide content while keeping it discoverable when necessary.

Speed

Mobile devices, when not connected to Wi-Fi, run on far inferior networks than their desktop older siblings. While these devices have improved and will continue to improve, we cannot assume parity between mobile and desktop browsing. As such, large images, heavy JavaScript libraries, or piles of content being forced onto the user will cause painful slowdowns.

People expect their web browsing to be fast. We have gotten used to the speed afforded us on broadband networks. In fact, Nielsen Norman Group research (www.nngroup.com/articles/response-times-3-important-limits/) has shown that:

1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.

Google suggests that people expect websites to load in under two seconds (googlewebmastercentral.blogspot.com/2013/08/making-smartphone-sites-load-fast.html), and that site abandonment rates skyrocket as load times climb past this number. Speed is actually ranked as the number one reason for abandonment on e-commerce websites.

As an example: I live in Chicago, which is not a tiny city. Twice a day, during my commute, I have no Internet connection while I am underground. Despite this relatively short inconvenience, I regularly notice myself becoming very annoyed that I can’t refresh my tweets.

Bandwidth Limitations

When data providers have faster networks, it’s safe to say that they will charge for them. Access and bandwidth charges (or overages) can be crippling, and, as with speed, every kB you add to your web experience has a tangible cost to the user.

JavaScript and CSS Support

Mobile browsers have gotten much more advanced in the past few years, and a large portion now run a version of Webkit—an open-source browser rendering engine. However, as with any web development, testing on a real device is the best way to determine support.

Mobile User Context

Finally, the physical environment of a mobile user is far less standardized than that of a desktop user. In the case of the latter, they are at a desk, or perhaps at a coffee shop, pretending to work on their manuscript.

Conversely, the mobile device user could be anywhere—at that same desk as the desktop user, trying to give directions to a cab driver, checking a map while mountain climbing, or looking up stock quotes while lying in bed.

To wit: When was the last time you went to the bathroom without your phone?

Benefits of the Mobile Web

As you have seen in the preceding sections, there are a number of unique challenges in designing for the web. As more classes of device, more screen sizes, and more capabilities show up and disappear in devices, it’s up to you to decide just how much time and money your team is willing to put into optimization.

Take a breath, though. There is a whole slew of benefits unique to the mobile web. Just as the rise in devices has complicated our lives as designers and developers, it has also unlocked the Internet itself to a massive amount of consumers, and grown the medium into something far greater than the hypertext pages of 1990.

Interaction Support

Let’s start with the obvious again: There are many more intuitive, built-in ways to interact with a smartphone than with a computer. Every way that you can touch, pinch, swipe, and tap a screen can be mapped to a different interaction, or behavior.

More important, these devices have been enabling more and more of their hardware to access browsers in recent years, including the camera, the microphone, accelerometers, and notification systems.

Lower Barrier to Entry

Internet-enabled mobile devices are also leaps and bounds cheaper than the total running cost of owning a desktop computer, broadband service, and a place to put said computer with said service.

To that point: In early 2012 I was doing research for a medical software company in rural India. In my two weeks there, I never saw a computer outside of the hotel or one of the hospitals that I visited. However, even in a farming village two hours outside of Chennai, I would have been hard-pressed to find anyone without some level of smartphone, and other members of the trip remarked that 2G service was everywhere.

Mobile User Context Information

Let’s now reconsider the mobile user’s context. We don’t know for certain where they are located. However, that’s not relevant to us.

We do know that they are using a device with a smaller screen (where real estate is scarce), somewhere between an edge cellular network and Wi-Fi, potentially dealing with bandwidth premiums. Building their experience, we can start to take all of these limitations as inputs to the user’s end goal. We know that they are on a specific website to do a specific task, and we have at our disposal a large variety of interaction and navigational tools with which to help them do that thing as quickly and efficiently as possible.

Who cares if they’re in the bathroom?

Building for the Most Users

Mobile device users now represent the majority of all users. Those of us who work with data visualization sometimes assume that a large portion of our content can still be tailored to larger, more capable screens, but we do so at our own peril.

The visualizations we create and the web applications in which they live are now consumed on devices from 320px of width to massive 5120px-wide retina screens. Therefore, we have to ensure that our content is consumable on as many devices as possible.

Because it isn’t possible to service all of them, it’s important to identify the ones that matter most to your own subject. I encourage you to do some tracking of your own website’s most frequent user agent and screen resolution ranges. Focus on optimizing for 80% of your user base, or even 50%. It may be smaller than you assume.

Mobile Web Design

For years, web teams have designed and built for the desktop. Mobile, if considered, was an afterthought, or a port of the desktop version. The truth is, this made perfect sense for a long time—users weren’t yet there, browsing the web on mobile phones was painful, and carriers controlled access to the web on their devices. What’s more, network speeds were so abysmal at first that it was nearly impossible to load anything more complicated than text.

Over the past few years, however, the web landscape has shifted so dramatically that an awareness of mobile as equal to, or even greater than, desktop means greater opportunities for growth, and a better user experience.

The Way To Build Today

The web has always been a mix of simultaneous (and often competing) priorities: performance, design, marketing, advertising, and SEO. With the mobile web overtaking desktop browsing, a new contender has appeared: device diversity. Table 1-1 displays the fragmentation of mobile device platforms (www.gartner.com/newsroom/id/2335616).

Table 1-1: The popularity of mobile device platforms by the end of 2012

Platform

Market Share End of 2012

Shipments in Q3 2012

Installed Base End of 2012

Android

53%

129 million

710 million

iOS

19%

27 million

260 million

Symbian

14%

4 million

190 million

BlackBerry

8%

8 million

104 million

Bada

> 2%

5 million

30 million

Windows Phone

< 2%

4 million

20 million

While there is a clear front-runner here, no single group can be reasonably ignored. Keep in mind, though, that these are global figures. Regional market share can differ immensely. China, for example, is the largest smartphone market in the world, and Android holds a market share of over 90% there.

The pie-in-the sky goal is obvious: How do we create an experience that works for everyone everywhere? The reality: How do we create an experience that works for the most people possible?

The Separate Mobile Web

Another frequently used solution for mobile is to create an entirely new mobile web experience. Instead of scaling down the desktop website, teams create what is known as an m.website.

For some time, this was the standard. It required extra work, but allowed for a uniquely mobile version of a website to become reachable by users. This methodology became so popular, in fact, that the Internet Corporation for Assigned Names and Numbers (ICANN) created the .mobi top-level domain in July of 2005. It was sponsored by some huge names in the web, including Google, Microsoft, and Samsung.

One person rather important to the web expressed the opposite opinion:

It is fundamentally useful to be able to quote the URI for some information and then look up that URI in an entirely different context. For example, I may want to look up a restaurant on my laptop, bookmark it, and then, when I only have my phone, check the bookmark to have a look at the evening menu. Or, my travel agent may send me a pointer to my itinerary for a business trip. I may view the itinerary from my office on a large screen and want to see the map, or I may view it at the airport from my phone when all I want is the gate number.

Dividing the web into information destined for different devices, or different classes of user, or different classes of information, breaks the web in a fundamental way.

I urge ICANN not to create the “.mobi” top-level domain.

Tim Berners-Lee

Download the App

Another way to handle the mobile web is to encourage (read: force) an app download when users reach your website on a mobile device.

Apps are a terrific way to utilize all of the rich functionality offered by feature-rich smartphones, and they enable you to leverage all of the hardware available.

However, every mobile operating system requires a separate development team, and 100% overlap in development work for every new feature.

Eyes Closed, Ears Plugged

The simplest way to handle any problem is to not handle it. A desktop website with desktop conventions and desktop sizing will show up on mobile.

If you believe that your web application will never (or at least rarely) end up being used on mobile, this is the path you should take.

Also: thank you for accidentally buying this book.

Responsive Web Design

Responsive web design (RWD) is an approach to web creation that aims to optimize the user experience on any device without resizing, cropping, panning, or being shunted to an app. A responsive website adapts the layout to the device on which it is viewed using CSS media queries, fluid grids, and flexible multimedia.

Spoiler: The entire next chapter is about this approach.

A Taste of Progressive Enhancement

Figure 1-7 shows Tim Berners-Lee’s first website once again, but this time on a screen from 2014. As you can see, it looks totally fine—perhaps a bit small, but no content is missing, no styles are broken, and everything is there.

In this case, all we really have is content. CSS didn’t exist. JavaScript didn’t exist. It’s due to this lack of current technology that the website still works on a device so different from what it was designed for. However, we can glean an important lesson from this: The basic need of a user is to read and write to a website. Anything more than this is nice, but not necessary.

This concept is called progressive enhancement. It is based on this core idea that the fundamental purpose of a website is to convey its content; everything else builds upon that, enhancing this purpose of meeting a user’s “needs.”

Figure 1-7: The first website (1990), displayed on an iPhone (2014)

The absolute minimum experience is always text. There is no technical or design thought given to this level of a website. In addition, HTML is fault-tolerant in various browsers; and as such, the textual content of a website will always be available in this basic form.

The next level of the user experience comes from the page markup itself. HTML semantics provide additional meaning, or meta information, to provide context to the textual content. For example, even though paragraphs and quotes may be displayed in the exact same way, a <p> tag represents a paragraph of text to a browser, while a <quote> tag represents a quote.

The third level can simply be called design. This is where CSS styling, images, and multimedia come into play. As with HTML, browsers are fault-tolerant with respect to CSS, so they can simply ignore rules that are either malformed or that the browser does not support. This is where you can differentiate the style of headings from paragraphs from quotes from links, and so on, thereby turning an informational experience into a beautiful one.

At the next level we layer on interaction. This is where JavaScript comes into play, and we enhance the aforementioned behavior to clarify, speed up, or delight the end user. Distilled, the principles of progressive enhancement look like this (see Figure 1-8):

Basic content must be accessible to any browser.

Semantic markup contains all web content.

Layout and design are provided by externally linked CSS.

Behavior enhancement is provided by unobtrusive JavaScript.

Figure 1-8: Each layer is built upon the preceding one, with the core idea as the foundation.

Summary

The Internet itself is shockingly old—a military invention from the middle of the last century, but the web that we know today is just pushing 25. That web has come a long way since Tim Berners-Lee’s research in the 1980s and first website in 1990. On the back of this technological shift, entire industries have been born, and with it, the medium of the web has grown tools that let us create complicated, beautiful, and all-inclusive experiences.

All of this history has led to a point at which thousands of different devices can get on the web. For many of these, we can create something unique and beautiful using HTML, CSS, and JavaScript. However, the layers of a web project need to be thought of in exactly that order:

HTML as markup

CSS for design

JavaScript for rich interaction