Introduction to Responsive and Adaptive Design

What is Responsive and Adaptive Design?

• As smartphones have become more and more how people view information online, it has become essential to create web experiences that are optimal for those devices.
• For many websites, the smartphone usage is now around 55-60 percent, with tablets usually 5-7 percent, and the desktop/laptop users the remainder.
• Responsive design is our primary focus. With a responsive design, your CSS adjusts how the page displays based on the width of the device screen or window (referred to as the viewport). Every device loads the same code (the same page).
• Adaptive design takes a different approach. With adaptive design you create multiple versions of a web page. For example, you would have one for smartphones, one for small tablets, one for large tablets, one for desktop/laptop, etc. The version that the user receives would be determined based on their device, so there would need to be programming to determine which code to send.
• There are various reasons to favor responsive design over adaptive design:
  • There are so many devices in use with varying dimensions (height and width of display) that creating different designs for them in an adaptive design setup would be a lot of work, and you would still have people experiencing horizontal scrolling and other undesirable outcomes because their screen dimensions wouldn't be an ideal fit for the options you created.
  • A user on a desktop/laptop may resize their browser window, so the version loaded no longer works well at the new browser window size.
  • The necessity of programming for the adaptive design increases the complexity of that approach.
• The grid-based CSS frameworks (e.g., Bootstrap) have breakpoints established for different devices, which mean that at a specific window/viewport width different styles are applied. The limitations of these approaches is their rigidity - they require your design to conform to their grid. Reality doesn't play well with that, necessitating additional CSS to make the design respond properly at various viewport sizes that don't match up with their grid.

Design Principles

When creating any responsive web experience there are certain principles that should always be followed for an ideal user experience:

• Avoid horizontal scrollbars: A horizontal scrollbar appearing in your browser window is very likely the first thing you will run into when creating a responsive design.

  You have to start by identifying which elements are triggering the scrollbar. Typically I will right-click on the empty space that you can see when scrolling to the right and choose Inspect Element (or whatever equivalent option is in your browser's context menu), which triggers your browser's Inspector Tools. You can then examine what is occupying that space.

  How do you solve this issue? If there's an element with a fixed width, switch that width to a percentage (perhaps 100%) or width: auto if it's a block-level element and you just want it to occupy the available space. 100% width, for example, would run into issues if padding and/or border was adding to that and the default box model was in use (so you would also need to change the box model via box-sizing: border-box).

  Another scenario is a series of items in a row, with the far-right item(s) extending off the viewport. You may need to wrap those far-right item(s) to a new line, so in that case you might end up displaying those item(s) as block (display: block) to get them to move to a new line.

  While it's possible to eliminate the horizontal scrollbar in the browser window by setting overflow-x: hidden on body, that's equivalent to masking the symptoms of an illness and claiming you're cured. It isn't addressing the root cause, and it's liable to cause you trouble down the road. For example, there may be useful content off the right edge of the viewport and now you don't have any way of reaching it, because you suppressed the scrollbar.

• Flow from Multiple Columns Down to One Column: The widest displays will easily support multiple columns, while smartphones typically have enough room to display one column (with two columns possible in some cases). For desktop/laptop your layout has four columns, which shrink down to 2 columns on tablet-sized devices, and down to 1 column on smartphones.
• Remove/Replace Content With Caution: There are occasions when it is appropriate to hide / remove content on smartphones, and potentially replace it with something else, but these are relatively rare cases.

  For example, there is a carousel on your home page that occupies the width of the screen. As the viewport shrinks, the carousel's height and width scale down too. On smartphones it is barely readable. That's a case where you might decide to hide the carousel and display a static image in its place. The drawback here is that in a responsive design (as compared to an adaptive design), you are still downloading the code for the carousel and the carousel images.

  The criteria for removing/replacing content revolves around the question of: is this information still readable or usable on this device?

  Note that this design guidance applies strictly to screen displays. When it comes to print-friendly output you want to hide everything that isn't relevant to the printed page/experience (such as navigation bars).

• Favor Native Controls for Lengthy Navigation / Option Lists: When working on a responsive design, navigation can prove tricky. While it is common to use a "hamburger menu" (an icon showing three lines stacked vertically), which displays a box containing choices when clicked/tapped, those do not work well if you have more than ~20 items. This is primarily because you don't want the menu to be taller than the viewport on the user's phone. In cases where you have a lot of items, a standard <select></select> menu with option tags is preferable, as those use the device's native controls (on iOS, for example, it would be a spinner control).
• Image Implementation Depends on the Desired Experience: When it comes to responsive design and images, a common question is whether you are using an <img> element or a CSS background image.

  Using <img> is essential if you always want the entire image to be shown. Typically these have max-width: 100%; height: auto; for their CSS, as that scales down the image while keeping its aspect ratio correct (thanks to the auto height). The drawback is that the image may become very small. If your image is 2000 pixels wide and 150 pixels tall, which makes it look great on desktop/laptop, on a phone any text in it is unreadable because the height is now 30-40px.

  CSS background images avoid this scaling/readability issue, but be sure to set the background to background-size: cover to ensure that it fills its containing element. The drawback with this approach is that you won't see the entire photo if the viewport is too small, so you'll be experimenting with different background-position values; often I am centering the background but sometimes I have to start it from a corner (depending on what part of the image is most important to keep visible for as long as possible).

Responsive Design Interface Changes Walkthrough

Media Types and Media Queries

CSS2 introduced the concept of media types, which have been expanded further in CSS3.

You can specify different CSS rules for different types of media, by querying what media type (and other media details) fit for the user's device. Other articles explore the Media Query details.

* In the original CSS2 specification this was named aural; CSS2.1 changed it to speech

In practice, screen and print are used the most. There were a variety of properties added for speech, but browser support has always been weak.

Viewport Control

• The default smartphone / tablet browser behavior when viewing a web page is to attempt to shrink the entire layout and content display (zoom them out), in order to fit them into the available space.
• This happens because the browser lacks instructions about how to calculate its viewport display area. Think of the viewport as the "window" you have into the web page; it is the height and width of what you can see at any one time.
• In order to prevent the zooming out from occuring we must set the viewport width to the device's width; this is done via the following meta tag, which should be added to all pages:

  <meta name="viewport" content="width=device-width" />
  

• There are other viewport properties that can be set inside the content attribute, although I recommend not setting them.
  • initial-scale - This is the initial zoom amount and width of the viewport. Defaults to a value of 1.
  • minimum-scale - Minimum zoom level; users cannot zoom out past this amount. Setting this creates usability and accessibility concerns.
  • maximum-scale - Maximum zoom level; users cannot zoom in past this amount. Setting this creates usability and accessibility concerns.
  • height - Not well-supported; this is supposed to define the viewport height.
  • user-scalable - If set to no, this prevents all zooming. A major usability and accessibility concern; please do not disable zooming.

Sizing Based on Viewport

Beyond the usual sizing units (em, rem, px, etc.), CSS3 has also added sizing-related properties related to the viewport.

Read about how these sizing units can be used

Text Size Adjustment

• If you experience text size being distorted on a smartphone display (some text is bigger than it should be or much smaller than it should be), the text-size-adjust property may be needed.
• Typically, you instruct the browser to text-size-adjust: none in those cases.