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

Road to Responsive

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.

Mike Aparicio

May 14, 2015
Tweet

More Decks by Mike Aparicio

Other Decks in Design

Transcript

  1. The Road to Responsive
    Mike Aparicio

    User Interface Engineer
    [email protected]

    View Slide

  2. 1996

    View Slide

  3. View Slide

  4. View Slide

  5. View Slide

  6. View Slide

  7. View Slide

  8. View Slide

  9. View Slide

  10. View Slide

  11. View Slide

  12. View Slide

  13. 2003

    View Slide

  14. http://www.csszengarden.com/001/

    View Slide

  15. View Slide

  16. View Slide

  17. 2007

    View Slide

  18. View Slide

  19. View Slide

  20. 2010

    View Slide

  21. View Slide

  22. View Slide

  23. http://alistapart.com/article/responsive-web-design

    View Slide

  24. The Responsive Trinity
    Fluid Grid
    Flexible Media Media Queries

    View Slide

  25. Flexible Grid

    View Slide

  26. 20px 20px 20px
    220px 220px 220px 220px
    940px

    View Slide

  27. 2% 2% 2%
    23.5% 23.5% 23.5% 23.5%
    100%

    View Slide

  28. View Slide

  29. View Slide

  30. Flexible Media

    View Slide

  31. http://slashfilm.com/

    View Slide

  32. View Slide

  33. View Slide

  34. (viewport meta tag)

    View Slide

  35. View Slide

  36. View Slide

  37. View Slide

  38. Media Queries

    View Slide

  39. View Slide

  40. View Slide

  41. View Slide

  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-]

    View Slide

  43. •all
    •aural
    •braille
    •handheld
    •print
    •projection
    •screen
    •tty
    •tv
    •embossed
    Media Types

    View Slide

  44. Pixel Perfect
    ^
    Proportion

    View Slide

  45. target ÷ context = result

    View Slide

  46. 980px
    (100%)

    View Slide

  47. 460px
    (?%)

    View Slide

  48. target ÷ context = result

    View Slide

  49. 460px ÷ 980px = 46.938776%

    View Slide

  50. 24px

    View Slide

  51. 24px ÷ 16px = 150%

    View Slide

  52. http://abookapart.com/products/responsive-web-design

    View Slide

  53. http://responsivewebdesign.com/podcast/

    View Slide

  54. Convincing Stakeholders

    View Slide

  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.”

    View Slide

  56. https://twitter.com/lukew/status/591265766823034880

    View Slide

  57. View Slide

  58. Mobile First

    View Slide

  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

    View Slide

  60. View Slide

  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

    View Slide

  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.”

    View Slide

  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.”

    View Slide

  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.”

    View Slide

  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

    View Slide

  66. View Slide

  67. View Slide

  68. Mobile Web vs. Native App

    View Slide

  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.”

    View Slide

  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.”

    View Slide

  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.”

    View Slide

  72. Desktop vs. Mobile Users

    View Slide

  73. View Slide

  74. “MOBILE CONTEXT”

    View Slide

  75. http://www.lukew.com/ff/entry.asp?1943

    View Slide

  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.”

    View Slide

  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.”

    View Slide

  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

    View Slide

  79. Culture

    View Slide

  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.”

    View Slide

  81. The Team

    View Slide

  82. View Slide

  83. View Slide

  84. View Slide

  85. View Slide

  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.”

    View Slide

  87. Frameworks &

    Pattern Libraries

    View Slide

  88. http://getbootstrap.com/

    View Slide

  89. View Slide

  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.”

    View Slide

  91. http://bradfrost.com/blog/post/atomic-web-design/

    View Slide

  92. View Slide

  93. Template
    Organism
    Molecule
    Atoms

    View Slide

  94. Prototyping

    View Slide

  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.”

    View Slide

  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.”

    View Slide

  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.”

    View Slide

  98. Performance

    View Slide

  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.”

    View Slide

  100. View Slide

  101. http://whatdoesmysitecost.com/

    View Slide

  102. View Slide

  103. https://gigaom.com/2014/12/29/the-overweight-web-average-web-page-size-is-up-15-in-2014/

    View Slide

  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

    View Slide

  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/

    View Slide

  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

    View Slide

  107. Responsive @ Groupon

    View Slide

  108. WHAT IF I TOLD YOU
    GROUPON.COM IS ALREADY RESPONSIVE

    View Slide

  109. Groupon To Go (GTG)

    View Slide

  110. Merchant Place Pages (MPP)

    View Slide

  111. WOAH.

    View Slide

  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

    View Slide

  113. Lessons Learned

    View Slide

  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

    View Slide

  115. Thank You!
    GO BULLS!

    View Slide