Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Responsive Design is Inevitable

Responsive Design is Inevitable

Presentation for Epic Systems Developer Day

Jason Grigsby

April 25, 2014
Tweet

More Decks by Jason Grigsby

Other Decks in Technology

Transcript

  1. 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
  2. 6.8 Billion Mobile phone for nearly everyone on the planet.

    Flickr photo by Pingnews: http://www.flickr.com/photos/pingnews/370061022/
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 640 px 600 px 519 px 640 px 622 px

    533 px 812 px Which are phones and which are tablets?
  13. Mobile First Design Principles Mobile First Responsive Design Forwarded by

    Luke Wroblewski Technical Approach for Responsive Design
  14. *

  15. 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.
  16. We often dismiss as unlikely the idea that someone will

    want to use our service on a small screen.
  17. It’s fairly certain that the highest-value use will stay predominantly

    on desktop. —Jakob Nielsen http://www.flickr.com/photos/dplanet/82899080/
  18. 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
  19. 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
  20. TMI

  21. 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/
  22. 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/
  23. 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
  24. 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
  25. is difficult when we spend so much time on our

    PCs. http://www.flickr.com/photos/goobi/4021009835/
  26. 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
  27. 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
  28. 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
  29. 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
  30. Anyone see a challenge making this responsive? Eventually Flexbox will

    make this easy. But in the meantime, it requires a lot of DOM manipulation.
  31. 1. Discovery 2. Wireframes 3. Dynamic Mockups 4. Expansion +

    Iteration Cloud Four’s Responsive Design Process
  32. Discuss and document project goals and risks Inventory pre-existing interface

    patterns Prioritize patterns and interfaces Discovery
  33. 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
  34. 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
  35. 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
  36. 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/ “
  37. ! 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
  38. #1 Iterative processes replace waterfalls. Design and development must work

    together. No silos. Designing systems of responsive components. #2 #3
  39. 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
  40. 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
  41. And keyboard and mouse are what we envision work is.

    http://www.flickr.com/photos/royalsapien/2387707860
  42. We’ve started letting go of some of our mistaken assumptions.

    http://www.flickr.com/photos/paulocarrillo/124755065/
  43. = =

  44. We can no longer make assumptions about input based on

    screen size or form factor. And we probably never should have.
  45. 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.
  46. 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
  47. 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
  48. 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
  49. 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
  50. 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
  51. Amazing, but too new to know what, if anything, this

    technology will mean for the web.
  52. 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
  53. 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
  54. 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/
  55. 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
  56. 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
  57. 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.
  58. What about those who won’t let go of their “power”

    interfaces? http://www.flickr.com/photos/ecos/4092571213/
  59. 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
  60. 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
  61. 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
  62. The key benefit of this approach: You’re designing for user

    need not for a specific form factor or input.
  63. Learn how to let go of the illusions that comfort

    us. http://www.flickr.com/photos/garibaldi/303085857/
  64. 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
  65. If you don’t adapt, then you are ripe for disruption.

    http://www.flickr.com/photos/gsfc/7521155076/
  66. Thank You! Special thanks to Luke Wroblewski, Eric Bidelman and

    Flickr users for generously sharing their photos under creative commons license.