Table of Contents for
Mastering Responsive Web Design

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Mastering Responsive Web Design by Ricardo Zea Published by Packt Publishing, 2015
  1. Cover
  2. Table of Contents
  3. Mastering Responsive Web Design
  4. Mastering Responsive Web Design
  5. Credits
  6. About the Author
  7. Acknowledgment
  8. About the Reviewers
  9. www.PacktPub.com
  10. Preface
  11. What you need for this book
  12. Who this book is for
  13. Conventions
  14. Reader feedback
  15. Customer support
  16. 1. Harness the Power of Sass for Responsive Web Design
  17. The basic concepts of Sass for RWD
  18. Summary
  19. 2. Marking Our Content with HTML5
  20. The
  21. The
    element
  22. The
  23. The
    element
  24. The
  25. The
  26. Using WAI-ARIA landmark roles to increase accessibility
  27. A full HTML5 example page with ARIA roles and meta tags
  28. Output screenshots for desktop and mobile
  29. Summary
  30. 3. Mobile-first or Desktop-first?
  31. Sass mixins for the mobile-first and desktop-first media queries
  32. Dealing with legacy browsers
  33. How to deal with high-density screens
  34. Sometimes RWD is not necessarily the right solution
  35. Retrofitting an old website with RWD
  36. Retrofitting with AWD
  37. Retrofitting with RWD
  38. Summary
  39. 4. CSS Grids, CSS Frameworks, UI Kits, and Flexbox for RWD
  40. CSS grids
  41. CSS frameworks
  42. UI kits
  43. The pros and cons of CSS frameworks for RWD
  44. Creating a custom CSS grid
  45. Building a sample page with the custom CSS grid
  46. Stop using CSS grids, use Flexbox!
  47. Summary
  48. 5. Designing Small UIs Driven by Large Finger
  49. The posture patterns and the touch zones
  50. The nav icon – basic guidelines to consider for RWD
  51. The navigation patterns for RWD
  52. Summary
  53. 6. Working with Images and Videos in Responsive Web Design
  54. Third-party image resizing services
  55. The element and the srcset and sizes attributes
  56. Replacing 1x images with 2x images on the fly with Retina.js
  57. Making videos responsive
  58. The Vector Formats
  59. Summary
  60. 7. Meaningful Typography for Responsive Web Design
  61. Calculating relative font sizes
  62. Creating a Modular Scale for a harmonious typography
  63. Using the Modular Scale for typography
  64. Web fonts and how they affect RWD
  65. Sass mixin for implementing web fonts
  66. Using FlowType.js for increased legibility
  67. Summary
  68. 8. Responsive E-mails
  69. Don't overlook your analytics
  70. Recommendations for building better responsive e-mails
  71. Responsive e-mail build
  72. Third-party services
  73. Summary
  74. Index

Chapter 3. Mobile-first or Desktop-first?

In my years of experience designing and building responsive websites, I've found that in order to have a better view of the content and the messages, it's easier to visualize things with a desktop-first approach during the wireframe and design phases.

As we are able to see more content in a given layout with a desktop-first approach, it allows us to translate the hierarchy of the content that was provided to us into a layout that represents said hierarchy. Doing this in a small canvas of 320 pixel width is more difficult than it needs to be.

When you accomplish that hierarchy, it will remain the same on small-screen devices, and the only thing that changes is the layout.

Best practices recommend building mobile-first, but many web professionals don't really know why we build mobile-first in the first place. Pun intended.

So, let's clear it up. The reason we build mobile-first is because of three principles mentioned by Luke Wroblewski, the author who actually coined the term mobile-first in 2009. You will notice that none of those principles are related to HTML, CSS, and/or JavaScript. In other words, you don't build mobile-first because of any advantage with HTML, CSS, or JavaScript. For more information, visit http://www.lukew.com/ff/entry.asp?933.

Consider the following points:

  • Mobile is exploding: Well, mobile has already exploded. This basically means that it's a lot easier, faster, and more convenient for people to use their mobile devices to access the web. So if you build your website to be compatible with mobile devices first, there's a better chance of providing a better user experience and being viewed by more people than if you have a desktop-only website/app.
  • Mobile forces you to focus: Since there's a lot less space on a mobile device's screen than on a desktop screen, there's a mandatory need to prioritize. This means that the most important tasks and/or messages need to be visible right away.
  • Mobile extends your capabilities: Mobile devices have features that a desktop device doesn't have: GPS, accelerometer, multitouch inputs, voice recognition, front and rear cameras, and so on. When going mobile-first, you can use these advanced technologies to create richer, more exciting experiences.

Now that you have a final design, you now need to implement that design into HTML, CSS, and JavaScript. For this phase, you should use the mobile-first approach and take into account the three reasons we mentioned earlier:

  • Building mobile-fist means your website/app can be seen by more people
  • It makes you prioritize the content
  • If you need to, it will allow you to use the advanced features and capabilities of mobile devices

In this chapter, we will cover the following topics:

  • Create your designs in a desktop-first view, but implement them with mobile-first.
  • Sass mixins for mobile-first and desktop-first media queries.
  • Dealing with legacy browsers.
  • How to deal with high-density screens.
  • Why RWD is sometimes not necessarily the right solution.
  • Retrofitting an old website with RWD.

Create your designs in a desktop-first view, but implement them with mobile-first

Let's look at some terminology so that we're on the same page:

  • Wireframe: This is a very basic visual representation of a layout using only outlines, in other words, in black and white. There are no colors, no branding, and no defined styles of any kind.
  • Design/Comp: This is a fleshed out wireframe with colors, branding, and styles. It's a very close representation (usually, say, 95 percent close to the final product) of the final page/site/app without going into markup or coding of any kind.
  • HTML mockup or HTML template: This is when the design has been implemented into an actual HTML page with CSS and—sometimes—JavaScript. It can only be viewed in the browser. It's practically an exact representation (99 percent close to the final product) of how the page/site/web app will look and work like.

With the terminology clear, let's continue.

Some professionals, including me, recommend using more modern and efficient techniques to create visual assets in order to optimize the time spent during the process of wireframing and creating designs/comps. Techniques such as style tiles, mood boards, element collages, and atomic design differentiate themselves from traditional wireframing and designs/comps methodologies. They offer the opportunity to explore layouts and styles, independent of screen widths, technologies, and even content creation.

For the scope of this book, we are going to focus on how a few things of the traditional wireframing and designs/comps methodologies can still be harnessed while maximizing the use of our time in these initial stages of mastering Responsive Web Design (RWD) with HTML5 and CSS3.

Why create designs in a desktop-first view?

The reason behind creating designs in a desktop-first view is simple: real estate (space).

As designers, we are required to reflect the hierarchy of the content in a visual way. To accomplish this, we use many design principles such as rhythm, proximity, whitespace, patterns, contrast, balance, grid, symmetry, and so on.

When the canvas on which we're creating a wireframe or design/comp is big enough to try different arrangements and layouts, we have the necessary flexibility to explore different ways that can represent the said content hierarchy.

For example, we're using a 12-column grid and the content we were provided with dictates the following content hierarchy:

  • The business wants users to be able to provide their e-mail IDs to receive our newsletter.
  • We want to display a featured post chosen by the editorial department.

With the preceding content hierarchy, we can immediately start picturing different layouts to convey this hierarchy:

  • For users to provide their e-mail addresses, we'll create a form with a heading, a paragraph, an input type e-mail, and a button. This form will be on the top-left corner below the header and it could have a width of three to four columns. I'm thinking that maybe four columns is too wide though, but let's wireframe it and see how that feels and what usability, accessibility, and legibility issues or benefits this could have.
  • For the featured post, we'll use the remaining columns. If the e-mail form is three-column wide, we'll use the remaining nine; if the e-mail form is four-column wide, we'll just use the remaining eight columns. The featured post has a lot more content, such as the heading, author, date, category, snippet, thumbnail, and a link to the full post.

With a wide canvas in our design/wireframing application, we can play with these different approaches and eventually end with a proposed layout that's sound and represents the content hierarchy as required by the business or stakeholders.

Creating a layout like this one with a mobile-first approach with a small canvas is practically impossible. The small real estate screen is incredibly restrictive and limited. But when things start to grow, we would need to make this exploration process each time we think of a specific breakpoint.

Tip

Actually, we shouldn't be thinking about breakpoints at this point (no pun intended), because the content—not specific device widths—is what dictates where a new breakpoint needs to be added.

Once we have a layout defined that reflects the content hierarchy, we will be in a good spot because when that content is rearranged on smaller screens, no matter which widths, the hierarchy will remain intact.

Why implement with mobile-first?

Let's clarify a term first: implement means create an HTML mockup with CSS and, if necessary, JavaScript, based on a wireframe or design/comp.

The reasons mentioned at the beginning of this chapter are the answer to the question why implement with mobile-first? Remember: mobile is exploding (well, it already did), mobile forces you to focus and mobile extends your capabilities.

None of those reasons could be accomplished with a desktop-first implementation, except maybe (that's a huge maybe) the second premise.

Let's change gears and move on to a subject a bit more technical that will help us understand how Sass mixins can help us master RWD for the mobile-first and desktop-first methodologies.

So, let's recap. Use desktop-first to create your designs and wireframes. Having a large canvas allows us to explore different layouts and properly arrange the hierarchy of the content. When it's time to implement (create HTML mockups), use mobile-first.