Road to Responsive

Responsive Web Design is not a fad or an option. It has become how we make websites. A look at other companies efforts to go responsive and how [Your Company] can get there.

1. The Road to Responsive Mike Aparicio
 User Interface Engineer maparicio@groupon.com
14. http://www.csszengarden.com/001/
23. http://alistapart.com/article/responsive-web-design
24. The Responsive Trinity Fluid Grid Flexible Media Media Queries
25. Flexible Grid
26. 20px 20px 20px 220px 220px 220px 220px 940px
27. 2% 2% 2% 23.5% 23.5% 23.5% 23.5% 100%
30. Flexible Media
31. http://slashfilm.com/
34. (viewport meta tag)
38. Media Queries
42. •width* •height* •device-height* •aspect-ratio* •device-aspect-ratio* •device-pixel-ratio* •color* •color-index* •monochrome* •resolution* •scan •grid Media Features * can be prefixed with [min/max-]
43. •all •aural •braille •handheld •print •projection •screen •tty •tv •embossed Media Types
44. Pixel Perfect ^ Proportion
45. target ÷ context = result
46. 980px (100%)
47. 460px (?%)
48. target ÷ context = result
49. 460px ÷ 980px = 46.938776%
50. 24px
51. 24px ÷ 16px = 150%
52. http://abookapart.com/products/responsive-web-design
53. http://responsivewebdesign.com/podcast/
54. Convincing Stakeholders
55. “We looked at how work was being done and thought that, despite our best efforts, things weren’t rolling out as fast enough, we weren’t always having the right functionality. You’re putting all this energy into this core experience but it’s not making its way to the other experiences, and you couple that with the trends that everybody in this industry sees—the growth of mobile, the growth of tablet—and you look at our conversion and our traffic, and we’re not getting it, and the traffic we are getting we’re not converting on.”
56. https://twitter.com/lukew/status/591265766823034880
58. Mobile First
59. “In 2014, we will double down on our progress over the past year, across 4 key areas by: Investing in growing our mobile customer base, accelerating activation and making Groupon a mobile first company…” - Eric Lefkofsky
 February 2014
61. “Our percent of mobile transactions continued to increase [...] including some countries that are approaching a mix that is well above 65% mobile. Spend for customers who buy through mobile remains significantly higher than for those who don’t.” - Eric Lefkofsky
 November 2014
62. “[Mobile First] is really about prioritizing and making sure that you know exactly what the people that are going to be using your site are looking for, where they expect to find it, what order makes the most sense for them to see it in, and accommodating for that.”
63. “When you’ve got limited screen real estate. It makes decision- making skills much more rigorous versus a desktop design, which is a lot more open to interpretation. When you’ve got a minimum screen width, you’re really forced to make tough decisions.”
64. “The end goal was that if we did this right for mobile, I think the benefits were actually going to trickle back to the desktop users as well. It was going to allow us to streamline a lot of the content we had across the website, and also simplify a lot of the pages.”
65. “If you design mobile first, you create agreement on what matters most. You can then apply the same rationale to the desktop/laptop version of the web site. We agreed that this was the most important set of features and content for our customers and business—why should that change with more screen space?” - Luke Wroblewski
 Mobile First
68. Mobile Web vs. Native App
69. “Mobile apps might work for some people but it seems to me that most people are probably consuming their content on, say Facebook, where they’re having this steady feed of content coming to them, and when they’re looking at it on Facebook’s mobile web, it just makes more sense to spend our time on that experience rather than splitting it with a mobile app that’s dedicated.”
70. “For the mobile website, we still have tons of new users joining every day and their first experience is likely not going to be installing an application, that’s a pretty big commitment. We have people clicking on links in email, we have people reading tweets, and we have people just discovering us and what we don’t want to do is send them to a three-year-old outdated experience that doesn’t even really tell you on the homepage what we do or what it is.”
71. “One of the things that kept coming up was “let’s build an app.” And after researching that a little bit we found that it could be a slippery slope. We had to build it for multiple channels, it’s going to be constantly changing, it could become very costly. We wanted to try to do something where we could basically write the code once and use it in multiple ways.”
72. Desktop vs. Mobile Users
74. “MOBILE CONTEXT”
75. http://www.lukew.com/ff/entry.asp?1943
76. “We pretty quickly landed on the idea that people want great content wherever they are and they want our best wherever they are. We looked at the Google Analytics that we had and we didn’t see much of a difference, in terms of our audience and how they were engaging with our content on different platforms and what kind of content they wanted. The splits just weren’t there.”
77. “Our data shows us quite plainly and clearly that the behavior of those on our mobile devices and the small screens is really not all that different than the behavior of those on the desktop. And the things they are seeking to do and the tasks they are seeking to accomplish are really quite the same.”
78. “All of the arguments for mobile versus desktop being different are entirely organizational change problems. They are organizations that want mobile and desktop to be different so each team can have their own little patch of turf to play on.” - Karen McGrane
 RWD Podcast
79. Culture
80. “One of the great things about working at NPR is the upper management really putting their trust in the folks who are building these products and trusting the team nature of that experience to emerge with the right answers. There’s certainly adjustments from above and direction given on information sharing that they have, but we’re really not a place where every design needs to go up and be seen by twelve executives.”
81. The Team
86. “Designers are also changing as well. More and more, designers really need to know a little bit of front-end code so when they produce even just early visual mockups, if it can be done in code, it’s so much easier. …As we were developing our structure, it became very pointless to design in flat, so we really quickly moved to designing in browser. Designers, UX designers, and devs were working closely together to test and build structures and content patterns in code, obviously because we needed to see it at all breakpoints at all times.”
87. Frameworks &
 Pattern Libraries
88. http://getbootstrap.com/
90. “It was a lot of collaboration between our information architects, our front-end development team and as well, our design team. As part of that we created a framework first. It created a common language for us to rally around as a design team and a development team.”
91. http://bradfrost.com/blog/post/atomic-web-design/
93. Template Organism Molecule Atoms
94. Prototyping
95. “I think some of the stuff that we’ve been able to do though is get to what something real looks like a lot faster, and then even putting a real live prototype in front of our executives at our monthly meetings can change the conversation.”
96. “A prototype is currency and everything we do is try to get it in the browser as quickly as we possibly can to assess feel, to assess space. Every discussion becomes a practical one instead of a theoretical one about “how is this going to change or shift or move?” You can see it real time.”
97. “Going with responsive designs, when we created responsive prototypes, it was so much easier to be able to test that on different devices with the users in the usability labs. You could see the difference. We could make a little bit of change, and we could test that right away with the users. So the designers and the product people also saw that, and they slowly started understanding that going responsive, at least as a base, is a much better option.”
98. Performance
99. “You see a tweet to one of our stories and you click it and you open it up and it’s in that, the little Twitter browser, and how that loads and what that experience is. If people start to learn that it takes awhile for that to load, they’re maybe not clicking as much.”
101. http://whatdoesmysitecost.com/
103. https://gigaom.com/2014/12/29/the-overweight-web-average-web-page-size-is-up-15-in-2014/
104. • Set a performance budget 
 (Time to first paint, time to page complete, speed index) • Determine baseline performance, make it “not terrible,” optimize • Optimize images (appropriate sizes + picture element) • Load JS only when needed (Do we need social sharing widgets?) • Consider perceived performance vs. actual Performance Tips
105. 1.Optimize an existing feature or asset on the page. 2.Remove an existing feature or asset from the page. 3.Don’t add the new feature or asset. Staying on Budget http://timkadlec.com/2013/01/setting-a-performance-budget/
106. “I think it’s come around by the organization sort of admitting that performance is a feature that they need to incorporate and plan for, it’s a design consideration. What’s more, performance is really not just a technical issue, it has to be an organizational- wide priority. It’s everyone’s responsibility.” - Ethan Marcotte
 RWD Podcast
107. Responsive @ Groupon
108. WHAT IF I TOLD YOU GROUPON.COM IS ALREADY RESPONSIVE
109. Groupon To Go (GTG)
110. Merchant Place Pages (MPP)
111. WOAH.
112. Groupon Interface Guidelines (GIG) • A CSS (and JS) framework shared across iTier apps • Includes common styles, UI patterns and modules • (Think Twitter Bootstrap) • Includes a fluid grid and support for flexible images • Fluid grid is scoped under a body class called “responsive” • iTier apps can trigger this class with a feature flag • Shared Layout Service provides a responsive header/footer
113. Lessons Learned
114. • Get stakeholders involved early and often (including devs) • Get in the browser as quickly as possible • Deliver prototypes, not pictures of websites • Make a framework that’s useful to designers and developers • Think atoms before pages • Start with the smallest view, then largest • Hire specialists to bridge the design/dev gap • Design for performance + set a budget • Monitor performance (speed + traffic/conversion) to measure success Lessons Learned
115. Thank You! GO BULLS!