Tweet
Tweet

Slide 1

Slide 1 text

Responsive Design is Inevitable Jason Grigsby • @grigs • cloudfour.com

Slide 2

Slide 2 text

Follow along at @grigs_talks http://bit.ly/grigs-epic2014

Slide 3

Slide 3 text

Got email from this guy... http://www.flickr.com/photos/corbett3000/2327165138/in/set-72157604094629546/

Slide 4

Slide 4 text

Mobile is Disruptive Technology http://www.flickr.com/photos/talkephotography/4523849236/ Creative Commons BY-NC-SA 2.0

Slide 5

Slide 5 text

10 20 30 40 50 60 Q1 Q3 Q5 Q7 Q9 Q11 Q13 Q15 Q17 Q19 Quarters Since Launch Subscribers (MM) iPhone + iTouch NTT docomo i-mode AOL Netscape iPhone + iTouch vs. NTT docomo i-mode vs. AOL vs. Netscape Users First 20 Quarters Since Launch Note: *AOL subscribers data not available before CQ3:94; Netscape users limited to US only. Morgan Stanley Research estimates ~39MM netbooks have shipped in first eight quarters since launch (10/07). Source: Company Reports , Morgan Stanley Research. Mobile Internet Outpaces Desktop Internet Adoption iPhone + iTouch Users = 8x AOL Users 9 Quarters After Launch Desktop Internet AOL* v 2.0 Launched 9/94 Mobile Internet NTT docomo i-mode Launched 6/99 Mobile Internet iPhone + iTouch Launched 6/07 ~57MM ~25MM ~7MM Desktop Internet Netscape* Launched 12/94 ~11MM 26 Source: http://www.morganstanley.com/institutional/techresearch/mobile_internet_report122009.html

Slide 6

Slide 6 text

http://www.opera.com/smw/ Not just smartphones. Opera Mini growing as well.

Slide 7

Slide 7 text

6.8 Billion Mobile phone for nearly everyone on the planet. Flickr photo by Pingnews: http://www.flickr.com/photos/pingnews/370061022/

Slide 8

Slide 8 text

Smartphone Usage = Still Early Stage With Tremendous (3-4x) Upside 0 1,000 2,000 3,000 4,000 5,000 6,000 Smartphone Mobile Phone Global Users (MM) Global Smartphone vs. Mobile Phone Users, 2013E Source: Morgan Stanley Research estimates. Note: One user may have multiple devices - actual number of actual smartphone + mobile phone devices in use (subscription numbers) may be higher than user numbers. 1.5B Smartphone Users 5B+ Mobile Phone Users 41

Slide 9

Slide 9 text

Note: *Japan data per Morgan Stanley Research estimate. Source: Informa. 2013E Global Smartphone Stats: Subscribers = 1,492MM Penetration = 21% Growth = 31% Smartphone Subscriber Growth = Remains Rapid 1.5B Subscribers, 31% Growth, 21% Penetration in 2013E 40 Rank Country 2013E Smartphone Subs (MM) Smartphone as % of Total Subs Smartphone Sub Y/Y Growth Rank Country 2013E Smartphone Subs (MM) Smartphone as % of Total Subs Smartphone Sub Y/Y Growth 1 China 354 29% 31% 16 Spain 20 33% 14% 2 USA 219 58 28 17 Philippines 19 18 34 3 Japan* 94 76 15 18 Canada 19 63 21 4 Brazil 70 23 28 19 Thailand 18 21 30 5 India 67 6 52 20 Turkey 17 24 30 6 UK 43 53 22 21 Argentina 15 25 37 7 Korea 38 67 18 22 Malaysia 15 35 19 8 Indonesia 36 11 34 23 South Africa 14 20 26 9 France 33 46 27 24 Netherlands 12 58 27 10 Germany 32 29 29 25 Taiwan 12 37 60 11 Russia 30 12 38 26 Poland 11 20 25 12 Mexico 21 19 43 27 Iran 10 10 40 13 Saudi Arabia 21 38 36 28 Egypt 10 10 34 14 Italy 21 23 25 29 Sweden 9 60 16 15 Australia 20 60 27 30 Hong Kong 8 59 31

Slide 10

Slide 10 text

Mobile Traffic as % of Global Internet Traffic = Growing 1.5x per Year & Likely to Maintain Trajectory or Accelerate 0% 5% 10% 15% 20% 25% 30% 12/08 12/09 12/10 12/11 12/12 12/13 12/14 % of Internet Traffic Global Mobile Traffic as % of Total Internet Traffic, 12/08 – 5/13 (with Trendline Projection to 5/15E) 0.9% in 5/09 2.4% in 5/10 15% in 5/13 Source: StatCounter Global Stats, 5/13. Note that PC-based Internet data bolstered by streaming. 32 6% in 5/11 10% in 5/12 Trendline E E

Slide 11

Slide 11 text

0 10,000 20,000 30,000 40,000 50,000 60,000 0 1 2 3 4 5 6 7 8 9 10 11 12 Global Unit Shipments (000) Quarters After Launch iPad iPhone 0 20,000 40,000 60,000 80,000 100,000 120,000 140,000 160,000 0 1 2 3 4 5 6 7 8 9 10 11 12 Global Unit Shipments (000) Quarters After Launch iPad iPhone First 12 Quarters Cumulative Unit Shipments, iPhone vs. iPad Source: Apple, as of CQ1:13 (12 quarters post iPad launch). Launch Dates: iPhone (6/29/07), iPad (4/3/10). Tablet Growth = More Rapid than Smartphones, iPad = ~3x iPhone Growth 44

Slide 12

Slide 12 text

Global Smartphone + Tablet Installed Base Should Exceed PC Installed Base in Q2:13E Global Installed Base of Desktop PCs + Notebook PCs vs. Smartphones + Tablets, 2009-2015E Note: Notebook PCs include Netbooks. Assumes the following lifecycles: Desktop PCs – 5 years; Notebooks PCs – 4 years; Smartphones – 2 years; Tablets – 2.5 years. Source: Katy Huberty, Ehud Gelblum, Morgan Stanley Research. Data and Estimates as of 9/12. 0 500 1,000 1,500 2,000 2,500 3,000 2009 2010 2011 2012E 2013E 2014E 2015E Global Installed Base (MMs) Desktop PCs Notebook PCs Smartphones Q2:13E: Projected Inflection Point Smartphones + Tablet Installed Base > Total PCs Installed Base Tablets 26

Slide 13

Slide 13 text

Technology Cycles - Wealth Creation / Destruction New Companies Often Win Big in New Cycles While Incumbents Often Falter Mainframe Computing 1960s Personal Computing 1980s Desktop Internet Computing 1990s Mobile Internet Computing 2000s Mini Computing 1970s New Winners New Winners New Winners New Winners Note: Winners from 1950s to 1980s based on Fortune 500 rankings (revenue-based), desktop Internet winners based on wealth created from 1995 to respective peak market capitalizations. Source: FactSet, Fortune, Morgan Stanley Research. Microsoft Cisco Intel Apple Oracle EMC Dell Compaq Google AOL eBay Yahoo! Yahoo! Japan Amazon.com Tencent Alibaba Baidu Rakuten Digital Equipment Data General HP Prime Computervision Wang Labs IBM NCR Control Data Sperry Honeywell Burroughs 16 Source: http://www.morganstanley.com/institutional/techresearch/mobile_internet_report122009.html

Slide 14

Slide 14 text

Image Source: Computersciencelab.com, Wikipedia, IBM, Apple, Google, NTT docomo, Google, Jawbone, Pebble. Technology Cycles Have Tended to Last Ten Years Technology Cycles – Still Early Cycle on Smartphones + Tablets, Now Wearables Coming on Strong, Faster than Typical 10-Year Cycle Mainframe Computing 1960s Personal Computing 1980s Desktop Internet Computing 1990s Mobile Internet Computing 2000s Mini Computing 1970s Wearable / Everywhere Computing 2014+ Others? 49

Slide 15

Slide 15 text

Note: PC installed base reached 100MM in 1993, cellphone / Internet users reached 1B in 2002 / 2005 respectively; Source: ITU, Morgan Stanley Research. New Major Technology Cycles = Often Support 10x More Users & Devices, Driven by Lower Price + Improved Functionality 1 10 100 1,000 10,000 100,000 1960 1970 1980 1990 2000 2010 2020 Devices / Users (MM in Log Scale) 1MM+ Units 100MM+ Units 10B+ Units??? 10MM+ Units Computing Growth Drivers Over Time, 1960 – 2020E 1B+ Units / Users 50

Slide 16

Slide 16 text

http://www.flickr.com/photos/76074333@N00/317952268/ | http://futuristmovie.com Creative Commons BY-NC-SA 2.0

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

ME NEED IPHONE APP. http://www.flickr.com/photos/corbett3000/2327165138/in/set-72157604094629546/

Slide 24

Slide 24 text

2008 We must have an iPhone App! http://www.slideshare.net/jamesgpearce/html5-and-the- dawn-of-rich-mobile-web-applications-pt-1

Slide 25

Slide 25 text

2009 We must have an Android App! http://www.slideshare.net/jamesgpearce/html5-and-the- dawn-of-rich-mobile-web-applications-pt-1

Slide 26

Slide 26 text

2010 We must have an iPad App! http://www.slideshare.net/jamesgpearce/html5-and-the- dawn-of-rich-mobile-web-applications-pt-1

Slide 27

Slide 27 text

2011 We must have a... http://www.slideshare.net/jamesgpearce/html5-and-the- dawn-of-rich-mobile-web-applications-pt-1

Slide 28

Slide 28 text

http://www.slideshare.net/jamesgpearce/html5-and-the-dawn-of-rich-mobile-web-applications-pt-1

Slide 29

Slide 29 text

http://www.slideshare.net/jamesgpearce/html5-and-the- dawn-of-rich-mobile-web-applications-pt-1

Slide 30

Slide 30 text

http://www.flickr.com/photos/adactio/6301799843 Zombie apocalypse of devices

Slide 31

Slide 31 text

http://www.flickr.com/photos/ lukew/10412585943/

Slide 32

Slide 32 text

Responsive is the answer. http://www.flickr.com/photos/38208449@N00/7712219364

Slide 33

Slide 33 text

But not the way you’re thinking.

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

There are other paths you can take… http://www.flickr.com/photos/95572727@N00/4204913417

Slide 40

Slide 40 text

But they will lead you to the same place. http://www.flickr.com/photos/cuppini/2631488256

Slide 41

Slide 41 text

Responsive design is inevitable. http://www.flickr.com/photos/gwilmore/3848170723/

Slide 42

Slide 42 text

Content & Services Car sketch: http://www.flickr.com/photos/cloppy/5081768461/ HTML HTML HTML HTML HTML HTML HTML HTML NATIVE NATIVE NATIVE

Slide 43

Slide 43 text

Let’s say you’re going to build a separate site or app for specific form factor.

Slide 44

Slide 44 text

Lines between device classes are blurring Model Type Size Size Display Resolution Resolution Viewport Viewport W H W H W H Samsung Galaxy Note 2 Phone 3.17” 5.95” 5.5” 720 1280 360 640 Motorola RAZR HD Phone 2.67” 5.19” 4.7” 720 1280 360 519 Motorola Atrix HD Phone 2.75” 5.26” 4.5” 720 1280 540 812 HTC Droid DNA Phone 2.78” 5.5” 5” 1080 1920 360 640 Nexus 7 Tablet 4.72” 7.81” 7” 800 1280 600 793 Kindle Fire Tablet 4.72” 7.44” 7” 600 1024 600 819 Kindle Fire HD Tablet 5.4” 7.6” 7” 800 1280 533 731

Slide 45

Slide 45 text

640 px 600 px 519 px 640 px 622 px 533 px 812 px Which are phones and which are tablets?

Slide 46

Slide 46 text

http://www.flickr.com/photos/geatchy/8489505999

Slide 47

Slide 47 text

Technical challenges Being inevitable doesn’t make it easy. http://www.flickr.com/photos/presidioofmonterey/7025086135

Slide 48

Slide 48 text

PERFORMANCE

Slide 49

Slide 49 text

http://www.guypo.com/uncategorized/real-world-rwd-performance-take-2/ Most responsive sites are bloated 2013: 476 sites from mediaqueri.es tested

Slide 50

Slide 50 text

http://www.thefoxisblack.com/2012/10/02/the-design-thinking-behind-the-new-disney-com/

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

http://www.flickr.com/photos/beautyredefined/2643858323/

Slide 56

Slide 56 text

http://www.flickr.com/photos/puuikibeach/3654517679

Slide 57

Slide 57 text

Most responsive web designs are…

Slide 58

Slide 58 text

The resounding answer from the community: Mobile First Responsive Web Design

Slide 59

Slide 59 text

http://www.flickr.com/photos/localcelebrity/4831362933/ Different than Mobile First Design Theory

Slide 60

Slide 60 text

No content

Slide 61

Slide 61 text

Mobile First Design Principles Mobile First Responsive Design Forwarded by Luke Wroblewski Technical Approach for Responsive Design

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

*

Slide 64

Slide 64 text

*FIRST Content First Structure First Performance First API First Command Line First

Slide 65

Slide 65 text

http://www.flickr.com/photos/leah8691/2184863624/

Slide 66

Slide 66 text

COFFEE FIRST! http://www.flickr.com/photos/leah8691/2184863624/

Slide 67

Slide 67 text

http://www.flickr.com/photos/gumption/3639682201/

Slide 68

Slide 68 text

But we’ve already got a desktop design and we can’t start over.

Slide 69

Slide 69 text

How do I make this responsive?

Slide 70

Slide 70 text

How do I make this responsive?

Slide 71

Slide 71 text

How do I make this responsive?

Slide 72

Slide 72 text

http://www.flickr.com/photos/ancphotos_/6728574731

Slide 73

Slide 73 text

Ok, let’s start from a clean slate http://www.flickr.com/photos/salendron/5569020488/

Slide 74

Slide 74 text

No content

Slide 75

Slide 75 text

What would the mobile version look like?

Slide 76

Slide 76 text

What would the mobile version look like?

Slide 77

Slide 77 text

What would the mobile version look like?

Slide 78

Slide 78 text

How does that map to desktop design?

Slide 79

Slide 79 text

How does that map to desktop design?

Slide 80

Slide 80 text

How does that map to desktop design?

Slide 81

Slide 81 text

How does that map to desktop design?

Slide 82

Slide 82 text

How does that map to desktop design?

Slide 83

Slide 83 text

How does that map to desktop design?

Slide 84

Slide 84 text

How does that map to desktop design?

Slide 85

Slide 85 text

How does that map to desktop design?

Slide 86

Slide 86 text

How does that map to desktop design?

Slide 87

Slide 87 text

How does that map to desktop design?

Slide 88

Slide 88 text

How does that map to desktop design?

Slide 89

Slide 89 text

How does that map to desktop design?

Slide 90

Slide 90 text

How does that map to desktop design?

Slide 91

Slide 91 text

How does that map to desktop design?

Slide 92

Slide 92 text

Can this desktop version be better using what we’ve learned from the mobile version?

Slide 93

Slide 93 text

No content

Slide 94

Slide 94 text

This is why Mobile First thinking is so powerful even on existing projects.

Slide 95

Slide 95 text

No content

Slide 96

Slide 96 text

Small screen assets Large screen assets Progressive enhancement based on screen size Mobile First Responsive Web Design is a technical approach for responsible responsive designs.

Slide 97

Slide 97 text

http://www.flickr.com/photos/soldiersmediacenter/6999691421 Yes, there are obstacles…

Slide 98

Slide 98 text

But the biggest challenge is us. http://www.flickr.com/photos/yamagatacamille/5434502250/

Slide 99

Slide 99 text

http://www.flickr.com/photos/hellogeri/6154034099/ A few years ago, Jeremy Keith talked about how…

Slide 100

Slide 100 text

http://www.flickr.com/photos/60415054@N00/14301113/ we told ourselves that the web was…

Slide 101

Slide 101 text

http://www.flickr.com/photos/60415054@N00/14301113/

Slide 102

Slide 102 text

http://www.flickr.com/photos/60415054@N00/14301113/ 640 px 480 px

Slide 103

Slide 103 text

640 px 480 px

Slide 104

Slide 104 text

No content

Slide 105

Slide 105 text

No content

Slide 106

Slide 106 text

No content

Slide 107

Slide 107 text

No content

Slide 108

Slide 108 text

1024 px 768 px

Slide 109

Slide 109 text

http://www.flickr.com/photos/adactio/6153481666/

Slide 110

Slide 110 text

http://www.flickr.com/photos/adactio/6153481666/ Then mobile came and made us realize…

Slide 111

Slide 111 text

that it was a consensual hallucination all along. http://www.flickr.com/photos/garibaldi/303085857/

Slide 112

Slide 112 text

The web never had a fixed canvas. http://www.flickr.com/photos/paulocarrillo/124755065/

Slide 113

Slide 113 text

Even our tools perpetuate the lie.

Slide 114

Slide 114 text

http://www.flickr.com/photos/69797234@N06/7203485148/ We’re making some progress.

Slide 115

Slide 115 text

We often dismiss as unlikely the idea that someone will want to use our service on a small screen.

Slide 116

Slide 116 text

It’s fairly certain that the highest-value use will stay predominantly on desktop. —Jakob Nielsen http://www.flickr.com/photos/dplanet/82899080/

Slide 117

Slide 117 text

Most complex tasks have vastly better user experience on the desktop and thus will be performed there… Yes, you might enter a stock trade with your broker's mobile app, but you'll research new mutual funds on the desktop. —Jakob Nielsen

Slide 118

Slide 118 text

http://www.flickr.com/photos/brunauto/5062644167/

Slide 119

Slide 119 text

80% during misc downtime 76% while waiting in lines 86% while watching TV 69% for point of sale research http://www.flickr.com/photos/carbonnyc/5140154965

Slide 120

Slide 120 text

TMI

Slide 121

Slide 121 text

39% use phone on toilet

Slide 122

Slide 122 text

http://techcrunch.com/2011/10/09/ebay-vp-steve-yankovich-en-route-to-4b-in-gross-mobile-sales-tctv/

Slide 123

Slide 123 text

How many cars are sold through eBay’s iPhone app each week? http://techcrunch.com/2011/10/09/ebay-vp-steve-yankovich-en-route-to-4b-in-gross-mobile-sales-tctv/

Slide 124

Slide 124 text

How many cars are sold through eBay’s iPhone app each week? 2,600 http://techcrunch.com/2011/10/09/ebay-vp-steve-yankovich-en-route-to-4b-in-gross-mobile-sales-tctv/

Slide 125

Slide 125 text

Each created and sold on a phone.

Slide 126

Slide 126 text

$265,000 $212,685 $212,685 Each created and sold on a phone.

Slide 127

Slide 127 text

In late 2008, after I had left the company, most of the eBay Mobile team was laid off or re-assigned to other parts of the company. Executives wanted to focus on the “core” of the business, and eBay Mobile was evidently not considered “core”. —Alan Lewis, Original developer of eBay iPhone App http://alanlewis.typepad.com/weblog/2011/01/ebay-for-iphone-why-it-almost-didnt-happen.html

Slide 128

Slide 128 text

But if there’s one thing I’ve learned in observing people on their mobile devices, it’s that they’ll do anything on mobile if they have the need. Write long emails? Check. Manage complex sets of information? Check. And the list goes on. If people want to do it, they’ll do it on mobile -especially when it’s their only or most convenient option. —Luke Wroblewski lukew.com/ff/entry.asp?1333

Slide 129

Slide 129 text

http://mobithinking.com/mobile-marketing-tools/latest-mobile-stats#mobile-only 25% of mobile web users in U.S. never or infrequently access the desktop web.

Slide 130

Slide 130 text

No content

Slide 131

Slide 131 text

Understanding mobile as the primary and sometimes only device… http://www.flickr.com/photos/e4a-2030/5106562313

Slide 132

Slide 132 text

is difficult when we spend so much time on our PCs. http://www.flickr.com/photos/goobi/4021009835/

Slide 133

Slide 133 text

Even the way we work as teams needs to change.

Slide 134

Slide 134 text

http://mashable.com/2012/12/11/responsive-web-design/ Common first approach: Mobile, Tablet, & Desktop Breakpoints

Slide 135

Slide 135 text

Resize until the page looks bad then…

Slide 136

Slide 136 text

Resize until the page looks bad then… BOOM! you need a breakpoint.

Slide 137

Slide 137 text

Major Breakpoint 1 (media query in document head) Major Breakpoint 3 (media query in document head) 320 px to 720 px wide 720 px to 1024 px major breakpoints Example major layout changes 320 720 Major Breakpoint 2 (media query in document head) nothing is here...but that’s ok! (P) = Portrait (L) = Landscape (L*) = Landscape w/ native viewport adaptation < 320 px wide and/or unable to understand further instructions 1024 iPhone (P) many Android (P) many BlackBerry S60 QWERTY Most S60 (L) S40 QWERTY some tablets most NetBooks many Desktops http://www.slideshare.net/yiibu/pragmatic-responsive-design

Slide 138

Slide 138 text

Major Breakpoint 3 (media query in document head) iPhone (L*) Android (L*) some Symbian touch (L) some tablets (L) some Symbian touch (L) 640 768 360 720 Major Breakpoint 1 (media query in document head) Major Breakpoint 2 (media query in document head) 720 px to 1024 px 320 px to 720 px wide nothing is here...but that’s ok! 320 minor breakpoints Example Symbian touch (P) (P) = Portrait (L) = Landscape (L*) = Landscape w/ native viewport adaptation iPhone (P) many Android (P) many BlackBerry S60 QWERTY Most S60 (L) S40 QWERTY < 320 px wide and/or unable to understand further instructions iPad (P) some Android tablets (P) Minor Breakpoint (@media) 1024 Minor Breakpoint (@media) Minor Breakpoint (@media) Minor Breakpoint (@media) 480 some tablets most NetBooks many Desktops content-related tweaks http://www.slideshare.net/yiibu/pragmatic-responsive-design

Slide 139

Slide 139 text

iPhone (L*) Android (L*) some Symbian touch (L) some tablets (L) Minor Breakpoint (@media) Major Breakpoint 3 (media query in document head) 480 640 768 360 Symbian touch (P) 720 Major Breakpoint 1 (media query in document head) Major Breakpoint 2 (media query in document head) 720 px to 1024 px 320 px to 720 px wide nothing is here...but that’s ok! 320 240 Minor Breakpoint for small devices w/media query support < 320 px wide and/or unable to understand further instructions ...and so on Example some Symbian touch (L) (P) = Portrait (L) = Landscape (L*) = Landscape w/ native viewport adaptation iPad (P) some Android tablets (P) 1024 TVs Minor Breakpoint (@media) Minor Breakpoint (@media) Minor Breakpoint (@media) iPhone (P) many Android (P) many BlackBerry S60 QWERTY Most S60 (L) S40 QWERTY some Android (P) many S40 (P) most S60 (P) some tablets most NetBooks many Desktops http://www.slideshare.net/yiibu/pragmatic-responsive-design

Slide 140

Slide 140 text

as you can see, this has the potential to get out of hand... iPhone (L*) Android (L*) some Symbian touch (L) some tablets (L) Minor Breakpoint (@media) some tablets (L) 640 768 360 Symbian touch (P) 720 Major Breakpoint 1 (media query in document head) Major Breakpoint 2 (media query in document head) TVs 720 px to 1024 px 320 px to 720 px wide nothing is here...but that’s ok! 320 240 Minor Breakpoint for small devices w/media query support some Android (P) many S40 (P) most S60 (P) < 320 px wide and/or unable to understand further instructions some Symbian touch (L) iPad (P) some Android tablets (P) Minor Breakpoints (@media) some tablets (L) 1280 800 Minor Breakpoint (@media) 600 some tablets (P) some tablets most NetBooks many Desktops 1366 many laptops Minor Breakpoint (@media) Minor Breakpoint (@media) Minor Breakpoint (@media) Major Breakpoint 3 (media query in document head) iPhone (P) many Android (P) many BlackBerry S60 QWERTY Most S60 (L) S40 QWERTY Minor Breakpoint (@media) 480 1024 http://www.slideshare.net/yiibu/pragmatic-responsive-design

Slide 141

Slide 141 text

What’s the point?

Slide 142

Slide 142 text

No content

Slide 143

Slide 143 text

Don’t go chasing waterfalls.

Slide 144

Slide 144 text

Don’t go chasing waterfalls.

Slide 145

Slide 145 text

Old Waterfall Process http://viljamis.com/blog/2012/responsive-workflow/

Slide 146

Slide 146 text

No content

Slide 147

Slide 147 text

No way to design for every breakpoint in PhotoShop!

Slide 148

Slide 148 text

New Responsive Design Process http://viljamis.com/blog/2012/responsive-workflow/

Slide 149

Slide 149 text

Older version of Marriott Search Results

Slide 150

Slide 150 text

No content

Slide 151

Slide 151 text

No content

Slide 152

Slide 152 text

No content

Slide 153

Slide 153 text

What if this was the design for the small screen version?

Slide 154

Slide 154 text

No content

Slide 155

Slide 155 text

No content

Slide 156

Slide 156 text

Anyone see a challenge making this responsive?

Slide 157

Slide 157 text

Anyone see a challenge making this responsive?

Slide 158

Slide 158 text

Anyone see a challenge making this responsive?

Slide 159

Slide 159 text

Anyone see a challenge making this responsive? Eventually Flexbox will make this easy. But in the meantime, it requires a lot of DOM manipulation.

Slide 160

Slide 160 text

No content

Slide 161

Slide 161 text

Another example of why design and development need to work closely.

Slide 162

Slide 162 text

1. Discovery 2. Wireframes 3. Dynamic Mockups 4. Expansion + Iteration Cloud Four’s Responsive Design Process

Slide 163

Slide 163 text

Discuss and document project goals and risks Inventory pre-existing interface patterns Prioritize patterns and interfaces Discovery

Slide 164

Slide 164 text

Use sketches, wireframes, etc. to rapidly explore design concepts Design openly with continuous feedback integration Determine UX direction for high-priority patterns and interfaces Wireframes

Slide 165

Slide 165 text

Render high-priority patterns as in-browser mockups Design responsively from the get-go using the web stack Finalize design direction for high-priority interfaces Dynamic Mockups

Slide 166

Slide 166 text

Extend mockup patterns into medium- and low-priority interfaces Iterate, refine and polish front-end for usability and performance Test and deliver high-quality, battle-hardened front-end code Expansion + Iteration

Slide 167

Slide 167 text

No content

Slide 168

Slide 168 text

Tiny Bootstraps, for Every Client Responsive deliverables should look a lot like fully-functioning Twitter Bootstrap- style systems custom tailored for your clients’ needs. These living code samples are self-documenting style guides that extend to accommodate a client’s needs as well as the needs of the ever-evolving multi-device web. —Dave Rupert, Responsive Deliverables http://daverupert.com/2013/04/responsive-deliverables/ “

Slide 169

Slide 169 text

http://daverupert.com/2013/04/responsive-deliverables/ Responsive Deliverables

Slide 170

Slide 170 text

No content

Slide 171

Slide 171 text

! download " view on github # view demo pattern lab documentation about resources demo on github pattern lab atoms molecules organisms templates pages create atomic design systems http://patternlab.io

Slide 172

Slide 172 text

No content

Slide 173

Slide 173 text

#1 Iterative processes replace waterfalls. Design and development must work together. No silos. Designing systems of responsive components. #2 #3

Slide 174

Slide 174 text

We need to learn to let go.

Slide 175

Slide 175 text

http://www.flickr.com/photos/cdm/51747860/

Slide 176

Slide 176 text

http://www.flickr.com/photos/rheaney/4397863376 It started with TVs.

Slide 177

Slide 177 text

Designing for a 10-foot UI is very different. http://www.flickr.com/photos/chrisbartow/5835428673

Slide 178

Slide 178 text

Larger text and fewer words.

Slide 179

Slide 179 text

Make up, down, left, right directions clear. http://images.dailytech.com/nimage/29122_large_amazon_prime_screen_5.jpg

Slide 180

Slide 180 text

How do we know what is a TV?

Slide 181

Slide 181 text

This is HDTV.

Slide 182

Slide 182 text

This is HDTV. 1980 px 1080 px

Slide 183

Slide 183 text

Resolution does not define the optimal experience.

Slide 184

Slide 184 text

Next came responsive web apps. https://twitter.com/freediverx/status/354698695041744896

Slide 185

Slide 185 text

How do I make this existing application responsive?

Slide 186

Slide 186 text

No content

Slide 187

Slide 187 text

mobile desktop THE ART OF WEB DEVELOPMENT THE ART OF WEB DEVELOPMENT Web widgets THE ART OF WEB DEVELOPMENT THE ART OF WEB DEVELOPMENT Mobile widgets

Slide 188

Slide 188 text

No content

Slide 189

Slide 189 text

No content

Slide 190

Slide 190 text

No content

Slide 191

Slide 191 text

No content

Slide 192

Slide 192 text

No content

Slide 193

Slide 193 text

No content

Slide 194

Slide 194 text

It’s not that we’re technically incapable, but adapting a phone UI to a tablet UI is not so dissimilar from trying to automatically adapt desktop UI to a phone. They are fundamentally different platforms with different usability considerations, and something that makes sense on phones may or may not belong on tablets. —Todd Anglin, Kendo UI http://www.kendoui.com/blogs/teamblog/posts/12-09-11/universal_mobile_apps_with_html5_and_kendo_ui.aspx

Slide 195

Slide 195 text

Sometimes it’s hard to envision a responsive version. http://demos.kendoui.com/web/grid/editing.html

Slide 196

Slide 196 text

http://www.flickr.com/photos/jesuspresley/384080245/ We want people to be productive…

Slide 197

Slide 197 text

and stay in the zone. http://www.flickr.com/photos/raccatography/8038855203

Slide 198

Slide 198 text

http://www.flickr.com/photos/shantellmartin/4543010568 Which seems very different from playing on an iPad.

Slide 199

Slide 199 text

For both the TV…

Slide 200

Slide 200 text

and the desktop web app…

Slide 201

Slide 201 text

input matters much more than screen size.

Slide 202

Slide 202 text

The grid is important to support d-pad interaction. http://images.dailytech.com/nimage/29122_large_amazon_prime_screen_5.jpg

Slide 203

Slide 203 text

http://www.flickr.com/photos/royalsapien/2387707860

Slide 204

Slide 204 text

And keyboard and mouse are what we envision work is. http://www.flickr.com/photos/royalsapien/2387707860

Slide 205

Slide 205 text

We’ve started letting go of some of our mistaken assumptions. http://www.flickr.com/photos/paulocarrillo/124755065/

Slide 206

Slide 206 text

But there is another consensual hallucination. http://www.flickr.com/photos/garibaldi/303085857/

Slide 207

Slide 207 text

No content

Slide 208

Slide 208 text

= =

Slide 209

Slide 209 text

No content

Slide 210

Slide 210 text

Supports hover and pointer events.

Slide 211

Slide 211 text

No content

Slide 212

Slide 212 text

No content

Slide 213

Slide 213 text

Keyboard and touch.

Slide 214

Slide 214 text

No content

Slide 215

Slide 215 text

No content

Slide 216

Slide 216 text

Even the iPhone can have a keyboard.

Slide 217

Slide 217 text

No content

Slide 218

Slide 218 text

No content

Slide 219

Slide 219 text

Are these laptops or tablets?

Slide 220

Slide 220 text

No content

Slide 221

Slide 221 text

No content

Slide 222

Slide 222 text

Desktop computer with 23” touch screen

Slide 223

Slide 223 text

No content

Slide 224

Slide 224 text

Luke Wroblewski nailed it. http://static.lukew.com/unified_device_design.png

Slide 225

Slide 225 text

No content

Slide 226

Slide 226 text

We can no longer make assumptions about input based on screen size or form factor. And we probably never should have.

Slide 227

Slide 227 text

http://www.flickr.com/photos/cblue98/7254221968

Slide 228

Slide 228 text

Input represents a bigger challenge than screen size. http://www.flickr.com/photos/cblue98/7254221968

Slide 229

Slide 229 text

http://www.flickr.com/photos/taedc/9278192929

Slide 230

Slide 230 text

And it is changing more rapidly than ever before. http://www.flickr.com/photos/taedc/9278192929

Slide 231

Slide 231 text

So let’s take a closer look…

Slide 232

Slide 232 text

Let’s start with futuristic input. http://www.flickr.com/photos/jdhancock/3714748769/

Slide 233

Slide 233 text

http://uncyclopedia.wikia.com/wiki/File:Man_yelling_at_computer.JPG VOICE

Slide 234

Slide 234 text

http://uncyclopedia.wikia.com/wiki/File:Man_yelling_at_computer.JPG VOICE

Slide 235

Slide 235 text

http://www.98ps.com/viewnews-15222.html

Slide 236

Slide 236 text

Siri gets all of the hype… http://www.98ps.com/viewnews-15222.html

Slide 237

Slide 237 text

but both Microsoft and Google have compelling voice input in their products.

Slide 238

Slide 238 text

No content

Slide 239

Slide 239 text

No content

Slide 240

Slide 240 text

No content

Slide 241

Slide 241 text

How should web pages change to support voice control?

Slide 242

Slide 242 text

No content

Slide 243

Slide 243 text

No content

Slide 244

Slide 244 text

Google voice search

Slide 245

Slide 245 text

You can use speech recognition too. http://www.google.com/intl/en/chrome/demos/speech.html http://www.moreawesomeweb.com/demos/speech_translate.html

Slide 246

Slide 246 text

Web Speech API Specification 19 October 2012 Editors: Glen Shires, Google Inc. Hans Wennborg, Google Inc. Please refer to the errata for this document, which may include some normative corrections. Copyright © 2012 the Contributors to the Web Speech API Specification, published by the Speech API Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available. Abstract This specification defines a JavaScript API to enable web developers to incorporate speech recognition and synthesis into their web pages. It enables developers to use scripting to generate text-to-speech output and to use speech recognition as an input for forms, continuous dictation and control. The JavaScript API allows web pages to control activation and timing and to handle results and alternatives. Status of This Document This specification was published by the Speech API Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Final Specification Agreement (FSA) other conditions apply. Learn more about W3C Community and Business Groups.

Slide 247

Slide 247 text

Please refer to the errata for this document, which may include some normative corrections. Copyright © 2012 the Contributors to the Web Speech API Specification, published by the Speech API Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available. Abstract This specification defines a JavaScript API to enable web developers to incorporate speech recognition and synthesis into their web pages. It enables developers to use scripting to generate text-to-speech output and to use speech recognition as an input for forms, continuous dictation and control. The JavaScript API allows web pages to control activation and timing and to handle results and alternatives. Status of This Document This specification was published by the Speech API Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Final Specification Agreement (FSA) other conditions apply. Learn more about W3C Community and Business Groups. All feedback is welcome. Table of Contents 1 Conformance requirements 2 Introduction 3 Use Cases 4 Security and privacy considerations 5 API Description 5.1 The SpeechRecognition Interface 5.1.1 SpeechRecognition Attributes 5.1.2 SpeechRecognition Methods 5.1.3 SpeechRecognition Events 5.1.4 SpeechRecognitionError 5.1.5 SpeechRecognitionAlternative 5.1.6 SpeechRecognitionResult

Slide 248

Slide 248 text

Please refer to the errata for this document, which may include some normative corrections. Copyright © 2012 the Contributors to the Web Speech API Specification, published by the Speech API Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available. Abstract This specification defines a JavaScript API to enable web developers to incorporate speech recognition and synthesis into their web pages. It enables developers to use scripting to generate text-to-speech output and to use speech recognition as an input for forms, continuous dictation and control. The JavaScript API allows web pages to control activation and timing and to handle results and alternatives. Status of This Document This specification was published by the Speech API Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Final Specification Agreement (FSA) other conditions apply. Learn more about W3C Community and Business Groups. All feedback is welcome. Table of Contents 1 Conformance requirements 2 Introduction 3 Use Cases 4 Security and privacy considerations 5 API Description 5.1 The SpeechRecognition Interface 5.1.1 SpeechRecognition Attributes 5.1.2 SpeechRecognition Methods 5.1.3 SpeechRecognition Events 5.1.4 SpeechRecognitionError 5.1.5 SpeechRecognitionAlternative 5.1.6 SpeechRecognitionResult Please refer to the errata for this document, which may include some normative corrections. Copyright © 2012 the Contributors to the Web Speech API Specification, published by the Speech API Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available. Abstract This specification defines a JavaScript API to enable web developers to incorporate speech recognition and synthesis into their web pages. It enables developers to use scripting to generate text-to-speech output and to use speech recognition as an input for forms, continuous dictation and control. The JavaScript API allows web pages to control activation and timing and to handle results and alternatives. Status of This Document This specification was published by the Speech API Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Final Specification Agreement (FSA) other conditions apply. Learn more about W3C Community and Business Groups. All feedback is welcome. Table of Contents 1 Conformance requirements 2 Introduction 3 Use Cases 4 Security and privacy considerations 5 API Description 5.1 The SpeechRecognition Interface 5.1.1 SpeechRecognition Attributes 5.1.2 SpeechRecognition Methods 5.1.3 SpeechRecognition Events 5.1.4 SpeechRecognitionError 5.1.5 SpeechRecognitionAlternative 5.1.6 SpeechRecognitionResult

Slide 249

Slide 249 text

Please refer to the errata for this document, which may include some normative corrections. Copyright © 2012 the Contributors to the Web Speech API Specification, published by the Speech API Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available. Abstract This specification defines a JavaScript API to enable web developers to incorporate speech recognition and synthesis into their web pages. It enables developers to use scripting to generate text-to-speech output and to use speech recognition as an input for forms, continuous dictation and control. The JavaScript API allows web pages to control activation and timing and to handle results and alternatives. Status of This Document This specification was published by the Speech API Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Final Specification Agreement (FSA) other conditions apply. Learn more about W3C Community and Business Groups. All feedback is welcome. Table of Contents 1 Conformance requirements 2 Introduction 3 Use Cases 4 Security and privacy considerations 5 API Description 5.1 The SpeechRecognition Interface 5.1.1 SpeechRecognition Attributes 5.1.2 SpeechRecognition Methods 5.1.3 SpeechRecognition Events 5.1.4 SpeechRecognitionError 5.1.5 SpeechRecognitionAlternative 5.1.6 SpeechRecognitionResult Please refer to the errata for this document, which may include some normative corrections. Copyright © 2012 the Contributors to the Web Speech API Specification, published by the Speech API Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available. Abstract This specification defines a JavaScript API to enable web developers to incorporate speech recognition and synthesis into their web pages. It enables developers to use scripting to generate text-to-speech output and to use speech recognition as an input for forms, continuous dictation and control. The JavaScript API allows web pages to control activation and timing and to handle results and alternatives. Status of This Document This specification was published by the Speech API Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Final Specification Agreement (FSA) other conditions apply. Learn more about W3C Community and Business Groups. All feedback is welcome. Table of Contents 1 Conformance requirements 2 Introduction 3 Use Cases 4 Security and privacy considerations 5 API Description 5.1 The SpeechRecognition Interface 5.1.1 SpeechRecognition Attributes 5.1.2 SpeechRecognition Methods 5.1.3 SpeechRecognition Events 5.1.4 SpeechRecognitionError 5.1.5 SpeechRecognitionAlternative 5.1.6 SpeechRecognitionResult

Slide 250

Slide 250 text

Please refer to the errata for this document, which may include some normative corrections. Copyright © 2012 the Contributors to the Web Speech API Specification, published by the Speech API Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available. Abstract This specification defines a JavaScript API to enable web developers to incorporate speech recognition and synthesis into their web pages. It enables developers to use scripting to generate text-to-speech output and to use speech recognition as an input for forms, continuous dictation and control. The JavaScript API allows web pages to control activation and timing and to handle results and alternatives. Status of This Document This specification was published by the Speech API Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Final Specification Agreement (FSA) other conditions apply. Learn more about W3C Community and Business Groups. All feedback is welcome. Table of Contents 1 Conformance requirements 2 Introduction 3 Use Cases 4 Security and privacy considerations 5 API Description 5.1 The SpeechRecognition Interface 5.1.1 SpeechRecognition Attributes 5.1.2 SpeechRecognition Methods 5.1.3 SpeechRecognition Events 5.1.4 SpeechRecognitionError 5.1.5 SpeechRecognitionAlternative 5.1.6 SpeechRecognitionResult Copyright © 2012 the Contributors to the Web Speech API Specification, published by the Speech API Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available. Abstract This specification defines a JavaScript API to enable web developers to incorporate speech recognition and synthesis into their web pages. It enables developers to use scripting to generate text-to-speech output and to use speech recognition as an input for forms, continuous dictation and control. The JavaScript API allows web pages to control activation and timing and to handle results and alternatives. Status of This Document This specification was published by the Speech API Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Final Specification Agreement (FSA) other conditions apply. Learn more about W3C Community and Business Groups. All feedback is welcome. Table of Contents 1 Conformance requirements 2 Introduction 3 Use Cases 4 Security and privacy considerations 5 API Description 5.1 The SpeechRecognition Interface 5.1.1 SpeechRecognition Attributes 5.1.2 SpeechRecognition Methods 5.1.3 SpeechRecognition Events

Slide 251

Slide 251 text

Please refer to the errata for this document, which may include some normative corrections. Copyright © 2012 the Contributors to the Web Speech API Specification, published by the Speech API Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available. Abstract This specification defines a JavaScript API to enable web developers to incorporate speech recognition and synthesis into their web pages. It enables developers to use scripting to generate text-to-speech output and to use speech recognition as an input for forms, continuous dictation and control. The JavaScript API allows web pages to control activation and timing and to handle results and alternatives. Status of This Document This specification was published by the Speech API Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Final Specification Agreement (FSA) other conditions apply. Learn more about W3C Community and Business Groups. All feedback is welcome. Table of Contents 1 Conformance requirements 2 Introduction 3 Use Cases 4 Security and privacy considerations 5 API Description 5.1 The SpeechRecognition Interface 5.1.1 SpeechRecognition Attributes 5.1.2 SpeechRecognition Methods 5.1.3 SpeechRecognition Events 5.1.4 SpeechRecognitionError 5.1.5 SpeechRecognitionAlternative 5.1.6 SpeechRecognitionResult Copyright © 2012 the Contributors to the Web Speech API Specification, published by the Speech API Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available. Abstract This specification defines a JavaScript API to enable web developers to incorporate speech recognition and synthesis into their web pages. It enables developers to use scripting to generate text-to-speech output and to use speech recognition as an input for forms, continuous dictation and control. The JavaScript API allows web pages to control activation and timing and to handle results and alternatives. Status of This Document This specification was published by the Speech API Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Final Specification Agreement (FSA) other conditions apply. Learn more about W3C Community and Business Groups. All feedback is welcome. Table of Contents 1 Conformance requirements 2 Introduction 3 Use Cases 4 Security and privacy considerations 5 API Description 5.1 The SpeechRecognition Interface 5.1.1 SpeechRecognition Attributes 5.1.2 SpeechRecognition Methods 5.1.3 SpeechRecognition Events

Slide 252

Slide 252 text

Special thanks to Eric Bidelman http://moreawesomeweb.com Speech Recognition API Support ?

Slide 253

Slide 253 text

No content

Slide 254

Slide 254 text

Gestures?

Slide 255

Slide 255 text

No content

Slide 256

Slide 256 text

No content

Slide 257

Slide 257 text

No content

Slide 258

Slide 258 text

No content

Slide 259

Slide 259 text

Amazing, but too new to know what, if anything, this technology will mean for the web.

Slide 260

Slide 260 text

Let’s come back from the future and look at something much Dumber. Dumber

Slide 261

Slide 261 text

Dumber

Slide 262

Slide 262 text

Dumber

Slide 263

Slide 263 text

-pad remote controls D

Slide 264

Slide 264 text

-pad remote controls D

Slide 265

Slide 265 text

-pad remote controls D

Slide 266

Slide 266 text

http://www.flickr.com/photos/stewc/6669743035/

Slide 267

Slide 267 text

http://www.flickr.com/photos/stewc/6669743035/ TVs browsers that support d-pad, send arrow key events.

Slide 268

Slide 268 text

http://www.wasdkeyboards.com/index.php/catalog/product/gallery/id/7164/image/343/

Slide 269

Slide 269 text

If then http://www.wasdkeyboards.com/index.php/catalog/product/gallery/id/7164/image/343/

Slide 270

Slide 270 text

No content

Slide 271

Slide 271 text

is undetectable. This is a recurring theme for input.

Slide 272

Slide 272 text

Sensors and camera http://www.flickr.com/photos/retrocactus/2170677056

Slide 273

Slide 273 text

Sensors and camera Camera http://www.flickr.com/photos/retrocactus/2170677056

Slide 274

Slide 274 text

GPS http://www.flickr.com/photos/3dking/149450434

Slide 275

Slide 275 text

GPS GeoLocation http://www.flickr.com/photos/3dking/149450434

Slide 276

Slide 276 text

No content

Slide 277

Slide 277 text

Gyroscope & Accelerometer

Slide 278

Slide 278 text

http://www.flickr.com/photos/chrisjagers/4694134078

Slide 279

Slide 279 text

Back to today’s problems. http://www.flickr.com/photos/chrisjagers/4694134078

Slide 280

Slide 280 text

No content

Slide 281

Slide 281 text

Hover state No hover state

Slide 282

Slide 282 text

Hover state Typing easier for many No hover state Typing often more difficult

Slide 283

Slide 283 text

Higher precision with mouse means smaller targets possible Hover state Less precise than mouse and requires larger touch targets Typing easier for many No hover state Typing often more difficult

Slide 284

Slide 284 text

Higher precision with mouse means smaller targets possible Hover state Less precise than mouse and requires larger touch targets Typing easier for many No hover state Typing often more difficult Right clicking and “power” tools Single and multi-touch gestures

Slide 285

Slide 285 text

No content

Slide 286

Slide 286 text

No content

Slide 287

Slide 287 text

http://www.flickr.com/photos/28096801@N05/5012309802

Slide 288

Slide 288 text

I got this. Detect touch. http://www.flickr.com/photos/28096801@N05/5012309802

Slide 289

Slide 289 text

No content

Slide 290

Slide 290 text

Whatever you may think, it currently isn't possible to reliably detect whether or not the current device has a touchscreen, from within the browser. —Stu Cox, You Can’t Reliably Detect a Touch Screen http://www.stucox.com/blog/you-cant-detect-a-touchscreen/

Slide 291

Slide 291 text

Chrome has entertained idea of enabling touch by default. https://code.google.com/p/chromium/issues/detail?id=159527 https://docs.google.com/a/cloudfour.com/presentation/d/1-n1qyzewpagREbzW2zm0wOalq33UhbtbSkWf9mEdly8/edit#slide=id.gc2d80e5b_171

Slide 292

Slide 292 text

No content

Slide 293

Slide 293 text

Detect a mouse? Not reliably.

Slide 294

Slide 294 text

No content

Slide 295

Slide 295 text

No content

Slide 296

Slide 296 text

Surely we can detect a keyboard?

Slide 297

Slide 297 text

Surely we can detect a keyboard? NOPE

Slide 298

Slide 298 text

No content

Slide 299

Slide 299 text

Input is dynamic.

Slide 300

Slide 300 text

Input is dynamic.

Slide 301

Slide 301 text

No content

Slide 302

Slide 302 text

No content

Slide 303

Slide 303 text

http://www.flickr.com/photos/lyza/7382235106 Maybe we need to be more zen about input.

Slide 304

Slide 304 text

No content

Slide 305

Slide 305 text

After poking at this problem for a few weeks, my conclusion is: every desktop UI should be designed for touch now. When any desktop machine could have a touch interface, we have to proceed as if they all do. —Josh Clark http://globalmoxie.com/blog/desktop-touch-design.shtml

Slide 306

Slide 306 text

No content

Slide 307

Slide 307 text

http://ie.microsoft.com/testdrive/ieblog/2011/Sep/20_TouchInputforIE10andMetrostyleApps_1.png http://www.w3.org/TR/pointerevents/ http://blog.webplatform.org/2013/02/pointing-toward-the-future/ New Pointer Events spec normalizes touch and mouse Pointer Events builds on the DOM event model to offer a new way to handle input on the web, enabling developers to build touch-first experiences that work with mouse, pen, and other pointing devices as well…They are also designed from the ground up to allow modern browsers to accelerate the touch-surface performance, leading to a smoother user experience.

Slide 308

Slide 308 text

What about those who won’t let go of their “power” interfaces? http://www.flickr.com/photos/ecos/4092571213/

Slide 309

Slide 309 text

http://www.flickr.com/photos/scarygami/5689980135/ One option: give them a choice.

Slide 310

Slide 310 text

No content

Slide 311

Slide 311 text

Display density settings

Slide 312

Slide 312 text

Th Dream Experience - … Uploaded 2 years ago More Of The Dream Exp… Uploaded 2 years ago The Dream Experience -… Uploaded 2 years ago The Dream Experience … Uploaded 2 years ago The Love King Breaks It… Uploaded 2 years ago War Paint for Trees From Lincoln Motor Company Join Log In Create Watch Upload Search s [ ] – VIDEOS Vimeo Couch Mode

Slide 313

Slide 313 text

Couch Mode + See all Centric TV’s videos / Recently viewed / Related videos Th Dream Experience - … Uploaded 2 years ago More Of The Dream Exp… Uploaded 2 years ago The Dream Experience -… Uploaded 2 years ago The Dream Experience … Uploaded 2 years ago The Love King Breaks It… Uploaded 2 years ago PROMOTED War Paint for Trees From Lincoln Motor Company Join Log In Create Watch Upload Search s [ ] – VIDEOS Vimeo Couch Mode

Slide 314

Slide 314 text

Couch Mode + See all Centric TV’s videos / Recently viewed / Related videos Th Dream Experience - … Uploaded 2 years ago More Of The Dream Exp… Uploaded 2 years ago The Dream Experience -… Uploaded 2 years ago The Dream Experience … Uploaded 2 years ago The Love King Breaks It… Uploaded 2 years ago PROMOTED War Paint for Trees From Lincoln Motor Company Join Log In Create Watch Upload Search s [ ] – VIDEOS Couch Mode + See all Centric TV’s videos / Recently viewed / Related videos Th Dream Experience - … Uploaded 2 years ago More Of The Dream Exp… Uploaded 2 years ago The Dream Experience -… Uploaded 2 years ago The Dream Experience … Uploaded 2 years ago The Love King Breaks It… Uploaded 2 years ago PROMOTED War Paint for Trees From Lincoln Motor Company Join Log In Create Watch Upload Search s [ ] – VIDEOS Vimeo Couch Mode

Slide 315

Slide 315 text

Vimeo Couch Mode

Slide 316

Slide 316 text

No content

Slide 317

Slide 317 text

The key benefit of this approach: You’re designing for user need not for a specific form factor or input.

Slide 318

Slide 318 text

Responsive is the answer. http://www.flickr.com/photos/38208449@N00/7712219364

Slide 319

Slide 319 text

We need to be responsive. http://www.flickr.com/photos/cdm/147947664/

Slide 320

Slide 320 text

Learn how to let go of the illusions that comfort us. http://www.flickr.com/photos/garibaldi/303085857/

Slide 321

Slide 321 text

No content

Slide 322

Slide 322 text

No content

Slide 323

Slide 323 text

No content

Slide 324

Slide 324 text

This is the web as it should be. As it wants to be. The web in its natural state. http://www.flickr.com/photos/25062265@N06/6069101123

Slide 325

Slide 325 text

It is what our customers expect. http://www.flickr.com/photos/johanl/6798184016

Slide 326

Slide 326 text

If you don’t adapt, then you are ripe for disruption. http://www.flickr.com/photos/gsfc/7521155076/

Slide 327

Slide 327 text

No content

Slide 328

Slide 328 text

Thank You! Special thanks to Luke Wroblewski, Eric Bidelman and Flickr users for generously sharing their photos under creative commons license.