Responsive web design from the future

855 views

Published on

Industry recommended best practices by Kyle Neath. Copyrights reserved by the author. Shared under Fair Use policy. Original source: http://warpspire.com/talks/responsive/

Published in: Technology, Design
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
855
On SlideShare
0
From Embeds
0
Number of Embeds
217
Actions
Shares
0
Downloads
2
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Responsive web design from the future

  1. 1. WEB DESIGN FROM THE FUTURE RESPONSIVE pushState. replaceState. Hashbangs!# AJAX. PJAX. Beets. Bears. Battlestar Galactica.
  2. 2. Kyle Neath is...
  3. 3. ~designer @
  4. 4. @kneath
  5. 5. warpspire.com
  6. 6. URL Design Partial Page Updates Let’s talk about
  7. 7. The future of the web is… HTML5 History API + Smart Partial Page Updates
  8. 8. The future of the web is… RESPONSIVE
  9. 9. How do you define responsive?
  10. 10. Resize the browser With an iPad / Playbook Responsive Web Design (lol/jk) “ ”
  11. 11. Fast pageloads Animates naturally Responds instantly Feels Faster™ click touch zoom scroll swipe type resize
  12. 12. Keyboard Shortcuts Back & Forward Buttons URL Hacking Browser Native
  13. 13. Technologies
  14. 14. @media queries Modernizr jQuery.hotKeys CSS3 Animations HTML5 History API XMLHTTPRequest mustache.js
  15. 15. @media queries Modernizr jQuery.hotKeys CSS3 Animations HTML5 History API XMLHTTPRequest mustache.js TOO MUCH FOR ONE DAY
  16. 16. … and how GitHub is stumbling through them
  17. 17. URL Design My recent love affair
  18. 18. URLs are sexy
  19. 19. Working with Terminal made me love URLs
  20. 20. Who needs directions if you can skip to the destination? URLs are like transporters
  21. 21. Everything should have a URL
  22. 22. A URL is an agreement
  23. 23. Can you see a future with hashbangs? #!/defunct
  24. 24. // Redirect legacy anchor-based issue urls to real URLs. var location_with_hash = location.pathname + location.hash var matches = location_with_hash.match(/#issue/(d+)(/comment/(d+))?/) if (matches) {   var issue_number = matches[1]   var comment_id = matches[3]   if (issue_number) {     if (comment_id) {       window.location = location_with_hash.replace(//?#issue/d+/comment/d+/     } else {       window.location = location_with_hash.replace(//?#issue/d+/, "/" + issue_     }   } } FOREVER
  25. 25. An <a> should behave like an <a>
  26. 26. ⌘ + click ⇧ + click Middle click
  27. 27. Be responsive! Browsers have windows & tabs
  28. 28. e.which == 1 && !e.metaKey && !e.shiftKey
  29. 29. Feels Faster™ Making people say
  30. 30. Welcome to the AJAX Generation
  31. 31. Welcome to the AJAX Generation iPhone Generation
  32. 32. Fast is about perception
  33. 33. = 1 billion SQL Queries 2 billion Memcache calls 3 billion Git calls
  34. 34. SLOW
  35. 35. Why are we focusing up here? This is the part that changes
  36. 36. Caching! …is really difficult
  37. 37. AJAX!
  38. 38. AJAX! loaders are not responsive
  39. 39. Only use loaders when requests are slow ~500ms Cache content for zero-request updates Think about the back button
  40. 40. There will always be full page loads
  41. 41. Serve all HTML (or JSON) in one request If you want fast…
  42. 42. Remember, page load time is about perception When can I: scroll, read text, click links?
  43. 43. Twitter: HTML + CSS + JS API Driven
  44. 44. Apply Science https://twitter.com/#!/kneath 4.7sec total load time 4.3sec timeline load Time to usable!
  45. 45. Apply Science https://github.com/kneath 3.4sec total load time 1.1sec HTML/CSS/JS loaded Time to usable!
  46. 46. Why is Twitter’s so slow?
  47. 47. SSL
  48. 48. Each domain is a new SSL Handshake twitter.com api.twitter.com
  49. 49. Handshakes and Waterfalls SSL twitter.com SSL api.twitter.com HTML, CSS, JS JSON Data
  50. 50. SSL Negotiation is our bottleneck 40ms backend response time 500ms blocking SSL Negotiation
  51. 51. Always favor science over theory
  52. 52. Be Responsive Client-Side Cache AJAX/JSON Request Full Page
  53. 53. Server or client side template rendering? So if we want partial page updates sometimes, full page updates other times…
  54. 54. Use the same templates Both! mustache.rb mustache.js Render HTML in AJAX/JSON partials are your friend
  55. 55. With SSL negotiation, server time is ~free One is simpler than two But…
  56. 56. URL Design + Feels Faster™
  57. 57. HTML5 History API makes me all tingly
  58. 58. pushState replaceState URL Change + back button stack URL Change only
  59. 59. Partial page updates with real URLs!
  60. 60. We can design for the back button!
  61. 61. Browser Support? 5.0 4.0Yes
  62. 62. Browser Support? 90%https://github.com
  63. 63. history.js balupton/history.js
  64. 64. Javascript redirects If you use hashbangs… two requests instead of one Confusing code paths some routing in server, some in js?
  65. 65. Some users get a slower experience Cost of History API But isn’t Chrome already faster than IE7?
  66. 66. Poison your URL structure Committing to nasty JS redirects FOREVER Manual anchor Javascript Cost of Hashbangs
  67. 67. Futuristic design This stuff is opening up
  68. 68. State? We can do that
  69. 69. ?milestone=3&sort=created&direction=desc&state=open
  70. 70. Save URLs in database replaceState on load but only if there aren’t any params already
  71. 71. Maintain state across pageviews Copy & paste URLs over IM / chat
  72. 72. Infinite Scroll? We can do that(correctly)
  73. 73. Facebook Tumblr Twitter Lots of websites are using infinite scroll
  74. 74. And they’re all broken
  75. 75. Infinite scroll is only better than pages if you can restore your position
  76. 76. http://warpspire.com/experiments/history-api
  77. 77. Happy Unix Enthusiasts Happy Grandmas Happy Developers Good URL Design + History API makes for…
  78. 78. warpspire.com/talks/responsive

×