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.
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.”
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
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
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.”
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.”
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.”
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
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.”
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.”
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.”
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.”
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.”
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
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.”
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.”
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.”
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.”
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.”
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.”
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.”
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
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/
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
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
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
peruvianidol
takumasaito
ashapiro
layerx
yomtsu
hiranotomoki
nicholaspegu
gdgmontreal
masayofff
cyberagentdevelopers
kamechi7222222
hjmkth
sig
mongodb
dougneiner
trishagee
jlugia
sugarenia
samlambert
chriscoyier
chrislema
smashingmag
danielanewman
addyosmani
jmmastey
![The Road to Responsive Mike Aparicio User Interface Engineer [email protected]](https://files.speakerdeck.com/presentations/e8425283d9e6479790e32933b236b6d1/slide_0.jpg){kind=link}
![“Our percent of mobile transactions continued to increase [...] including](https://files.speakerdeck.com/presentations/e8425283d9e6479790e32933b236b6d1/slide_60.jpg){kind=link}
![“[Mobile First] is really about prioritizing and making sure that](https://files.speakerdeck.com/presentations/e8425283d9e6479790e32933b236b6d1/slide_61.jpg){kind=link}
