Category Archives: Responsive Design

Frameworks

Posted by The fine folks at A List Apart |24 Nov 15 |

Over the past few years, we’ve been learning how to adapt our layouts to the infinite canvas of the web. Our sites can be viewed on any size screen, at any time, and responsive design is one approach that lets us accommodate the web’s variable shape. But with all of the challenges we’re facing and those yet to come, we need to begin building not just patterns, but principles for responsive design—principles that will allow us to focus not just on layout, but on the quality of our work.

If each part of your responsive interface is more or less self-contained—with its own layout rules, content needs, and breakpoints—then the code behind each element’s design is far less important than thinking carefully about how and why an element should adapt. In other words, how do we move beyond thinking in terms of columns and rows, and start talking about the quality of our responsive designs? And what would frameworks to support that look like?

Finding the words

Honestly, there’s no perfect answer to that question. But recently, a number of designers and organizations have started sharing the vocabulary they use to decide how and when their responsive designs should adapt. Vox Media, for example, thinks of their content as existing within a river—and in keeping with the metaphor, the flow of that content can be interrupted at certain points. Here’s how they describe the front pages of Vox.com:

Content flows around “rocks” and “breakers,” which are modules such as a “Most Commented” list or a row of “Popular Videos.” Many of these behaviors remain in the new layout system, but the key difference is an added contextual layer. Elements in the river are laid out to better highlight the diversity of content on Vox—articles, features, videos, editorial apps, card stacks, to name a few. Each one displays differently depending on its type and neighboring entries.

Note that the language they use to talk about the quality of their layouts doesn’t revolve around columns or rows. There’s nary a mention of grids. For Vox, the design process begins with content priority and evolves into a layout. By understanding the weight and importance of each piece of content that flows through the river, the Vox team can algorithmically generate a responsive layout that best reflects the importance of the information within it.

Starting with an abstract system of columns and rows would be wrong for them—and, I’d argue, for every web designer. After all, according to Mark Boulton, there are three fundamental benefits of a grid system:

  • Grid systems create connectedness. A well-made grid can visually connect related pieces of content or, just as importantly, separate unrelated elements from each other. In other words, they help us create narratives from our layout.
  • By establishing predefined alignment points, grid systems help designers solve layout problems.
  • A well-designed grid system will provide visual pathways for the reader’s eye to follow, and allow them to better understand a visual hierarchy.

As Boulton notes, we historically created grid systems by adopting a “canvas in” method. Working from the edges of a printed page, designers would subdivide a page into a system of columns and rows, and place images and text upon that grid in pleasing, rational arrangements. But the web doesn’t have any such boundary—after all, it’s the first truly fluid design medium. As a result, Boulton argues we should instead adopt a “content out” approach to designing our grids: to build more complex layout systems out from a foundation of small, modular pieces of content. And to do so, Boulton proposes three guiding principles:

  • Define relationships from your content. A grid for the web should be defined by the content, not the edge of an imaginary page.
  • Use ratios or relational measurements above fixed measurements.
  • Bind the content to the device. Use CSS media queries, and techniques such as responsive web design, to create layouts that respond to the viewport.

By understanding the shape of our content, we can create flexible layouts that support connectedness—not just between related pieces of information, but between our layouts and the device. We can make responsive grid systems that don’t just fit on an ever-increasing number of screens—they’ll feel at home, wherever they’re viewed.

Finding the seams

Principles are wonderful, of course, but we still have to find a means of implementing them: of translating those ideals into practical responsive patterns and layouts. For me, that “content out” process begins by looking at the smallest version of a piece of content, then expanding that element until its seams begin to show and it starts to lose its shape. Once that happens, that’s an opportunity to make a change—to introduce a breakpoint that reshapes the element and preserves its integrity.

But first, we need a method of finding an element’s seams, and understanding how it loses its shape. For me, that process begins by looking at four characteristics: width, hierarchy, interaction, and density.

Width

Width might be a little self-evident. As the width of a viewport changes, so does the width of a responsive design. But as the design gets wider or narrower, so will the elements within it, and as those modules expand or contract, there may be opportunities to add a breakpoint.

Images from Meagan Fisher’s responsive portfolio showing how different screen widths affect the typography.
On her stunning responsive portfolio, Meagan Fisher adjusts the typography of certain elements—not just their layout—as their width expands and contracts.

Hierarchy

Width is, I’m sure you’ll agree, the most common characteristic of a responsive design—but it’s not the only one. As the shape of an element changes, the hierarchy of elements may need to change as well.

Let’s take a quick look at a product page on Tattly’s responsive ecommerce site. When viewed on wider screens, the primary content area has two key pieces of information: a photo carousel of the product on the left, and a call to action to purchase the product on the right.

Screenshot from Tattly’s responsive ecommerce site, showing a two-column grid on wider screens.
On Tattly’s responsive ecommerce site, the product content is laid out in a pleasing two-column grid on wider screens.

But that’s just one view of this particular part of the design, because as screens get narrower, we lose the ability to place multiple columns side by side. That’s where a question of hierarchy arises: in a single-column layout, which piece of content should appear first? Tattly opted, quite rightly, to lead with photos of the product—but you may answer hierarchy questions differently on your site.

Screenshot from Tattly’s responsive ecommerce site, showing how the product information shifts from two columns to one on narrower viewports.
On narrower viewports, the hierarchy of product information shifts from two columns to one.

Hierarchy is generally a reminder to be more vertically aware in our designs. After all, we have min-width and max-width media queries, but can also avail ourselves of min-height and max-height queries more often. I think the navigation menu for the Field Museum beautifully balances vertical and horizontal layouts.

Screenshot of the Field Museum’s responsive navigation in narrow and wide widths.
The Field Museum’s responsive navigation, which occupies the height of the design. Below a certain width, the navigation moves to the top of the screen to avoid cropping.

On wider screens, the navigation is anchored to the left edge of the design, and spans the full height of the viewport. You may notice that they’re using the flexible box model, or flexbox, an advanced CSS layout method we’ll look at later in this chapter. But since flexbox allows elements to automatically fill the space available to them, as the menu gets taller or shorter, the navigation elements resize vertically—but below a certain width or height, the menu is placed at the top of the page.

By minding the navigation’s vertical edges, the Field Museum was able to introduce alternate layouts to ensure the content inside their navigation menu was never concealed, obscured, or clipped. In other words, the breakpoints we introduce to our responsive designs aren’t tied to the shape of a device’s screen. Instead, our media queries defend the integrity of the content we’re designing.

Interaction

The way we interact with an element may change along with the design. Responsive navigation systems are probably the most obvious example of this. As we saw in Chapter 2, menus are often displayed in full at wider breakpoints but concealed at smaller ones, perhaps hidden behind expandable icons or links when space is at a premium.

Screenshots of Karen McGrane’s company site, showing a traditional navigation on wider screens and a toggled display at narrower widths.
Karen McGrane’s company site has a traditional-looking navigation at wider breakpoints, but on smaller viewports the user toggles the visibility of the menu. Same links, but a new interaction model.

But navigation isn’t the only kind of content that might require interaction changes. For example, take the responsive sports brackets designed by SB Nation. While they appear as complex-looking charts at wider breakpoints, a simpler, more linear view of the brackets is shown on smaller screens.

Screenshots showing SB Nation’s brackets: fully visible on wide screens, per-section carousels on narrower screens.
I don’t know from sports, but I know I like SB Nation’s responsive brackets: complex charts on wide screens, but a carousel of match-ups on smaller viewports. Same information, different interaction.

Along with the simplified layout, the brackets are presented as carousels in the smaller view, where real estate is more dear. Each of the four regions for the bracket are a single slide in the carousel, allowing the user to cycle through for details. The information in both visual states is the same, but the interaction model changes.

Density

Finally, the amount of information you’re showing in an element might need to vary over time—in other words, the density of information can change. The Guardian’s feature on the 2015 Oscars is full of examples of this, with responsively designed timelines displaying a significant amount of movie data. Above a certain width, thumbnail images are loaded in, slightly increasing the visual (and informational) density of the timeline.

Screenshots of the Guardian’s responsive cinematic timelines, displaying an extra image on wider views.
The Guardian’s responsive cinematic timelines gradually increase in density, displaying an extra image above a certain width.

Density is, as you might have guessed, an area where you should tread very carefully. As we’ve discussed before, removing or hiding information because it doesn’t fit can be problematic.

Screenshot of Tattly's navigation, hiding submenus on smaller screens.
Tattly hides its submenu entirely, reducing its navigation to a list of primary sections on smaller screens.

Personally, I think the Guardian’s timelines work so well because the images shown at wider breakpoints are enhancements: they’re not critical to understanding the information around them. Could they have designed alternate versions of the timelines to show images at all breakpoints? Possibly. But I think this is a wonderful example of density used to lighten the visual impact of a design, removing extraneous information without impeding access to the content.

Rolling Out Responsive

Posted by The fine folks at A List Apart |24 Nov 15 |

I wish I could tell you there was one true path to rolling out a responsive redesign successfully. But from talking to dozens of organizations, it’s clear that the process by which large organizations go responsive varies widely. Many different approaches will work—but you need to understand the benefits and risks of each approach.

Can you redesign the entire site at once or do you need to stage the rollout over time? Are you going to retrofit the existing desktop site or start from scratch? Will you release a beta version of the site or do a “big reveal”? To find the right option for your organization, ask yourself these questions:

  • How worried are you about existing customers on the desktop site? Now, no one is going to answer, “Not worried even one tiny little bit.” But some organizations (say, publishers) redesign relatively frequently without launching a beta version—they just flip the switch. Other organizations (say, banks) know they can’t risk frustrating existing customers by introducing drastic changes without an adjustment period.
  • Are you redesigning a web application? Don’t let anyone tell you that web apps can’t be made responsive. They can—but it takes time and effort. If you have large tabular presentations of data, complex form-based transaction flows, or tricky integrations with legacy backend systems, be sure to build additional time into your process.
  • Do you plan to make changes to your content? A responsive redesign is a fantastic opportunity to clean up and pare down your existing content—you may never get a better chance to fix bloated content that isn’t doing its job. That said, many organizations find they can’t do everything at once, so they roll out the content cleanup in stages.
  • Do you plan to implement a new CMS or APIs? Many organizations report that the work they’ve done over the past few years to replatform their publishing systems makes going responsive much simpler. But you’ll need to decide whether to do the CMS or the redesign first. It’s riskier and more time-consuming to do them at the same time.
  • Are your stakeholders prepared for the review process? Some organizations use a responsive redesign to engage the entire organization in learning a new process. Others take a “better to ask forgiveness than permission” approach, rolling out the redesign first and fixing the inevitable broken pieces later.

Once you know the answers to these questions, consider your options for going responsive.

Retrofit

Doing a responsive retrofit means recoding the front end of the website with little or no change to the existing content and design.

I must confess: before I started talking to companies that launched a successful responsive retrofit, I was convinced this was the worst of all possible options, doomed to deliver a subpar experience to everyone involved. My philosophical beliefs about the “right way” to manage web processes don’t always survive their encounters with the real world: I concede that a retrofit works well in some scenarios.

In general, retrofits work best when at least one of the following statements is true:

  1. The content isn’t going to change (much).
  2. Complex web applications don’t need to be redesigned.
  3. A componentized framework is already in place.

Companies like Capital One, Marriott, and Nationwide Insurance have implemented responsive retrofits successfully. Doing a retrofit forced them to focus on the responsive aspects of the project without getting sidetracked by larger questions of redesigning the site, editing the content, or replatforming the CMS. For many websites, a retrofit also helps mitigate political concerns around changing or damaging the desktop experience, since it doesn’t change much.

Here’s how you roll out a retrofit right:

  • “Don’t touch the desktop” is a mandate often handed down to the responsive team, but this guideline is too limiting. It forces the team to work toward unnecessary design parity at the expense of making better design decisions for smaller screens.
  • “Do no harm to the desktop” is a more realistic and achievable ambition. This gives teams the flexibility they need to make adjustments to layout, design, navigation, or content.
  • Set realistic expectations with your team and develop a plan for making changes over the long term. Stakeholders may be surprised when they see how existing content and functionality shifts around on different screens.
  • Consider picking one section for a complete responsive overhaul. A fully edited and redesigned section can provide a useful point of comparison with the retrofit. Picking a section for a complete redesign will give teams experience with the process, show stakeholders what’s possible, provide insight into the level of effort that can inform future scoping processes, and offer real-world data about how a fully redesigned experience will perform compared to the retrofit.

Beta release

In recent years, popular web applications like Gmail, Flickr, and Delicious launched in beta—and stayed in beta. This “perpetual beta” approach was a precursor to the continuous deployment practices used by many applications today to support ongoing development and testing.

Today, when teams say they’re launching in beta, they often mean that users can opt out of the new site at any time and return to the “classic” version of the website. This “parallel beta” approach requires significantly more time and effort to develop and review, but in return delivers the ability to roll out the redesign slowly, gathering user feedback and analytics data along the way.

Companies like Fidelity, Beatport, and the Guardian have invested in parallel beta releases, which gave them a way to test and learn from the responsive design over time. Stephen Turbek, SVP, User Experience Design at Fidelity, said their decision to launch in beta was crucial to their success:

One of our first steps was to build a beta site that people could opt-in to, try out for a while, and return to the current site. The beta site was significant additional work, but iterating live on a site with millions of passionate customers would not have been the right approach. This enabled us to make changes faster and get lots and lots of user feedback.

Here’s what needs to happen to launch a successful beta:

  • A test-and-learn culture should already be established in your organization. Teams must be comfortable working in tight cycles of iteration and testing—most teams will need to run tests every six weeks, and even as frequently as every week or two. If you don’t already work this way, building a culture of learning from research will take time and add complexity.
  • Technical architecture and publishing infrastructure must be in place so users that can opt in and out, which can be costly.
  • Executive buy-in from stakeholders who see the value of the beta process and are willing to invest in maintaining two versions of the site—not to mention driving traffic to two different URLs—is crucial.
  • Quality assurance testing (QA) becomes exponentially more complex when testing on more form factors. Don’t underestimate the time or staff you’ll need to QA two versions of the site.
  • Rolling out the beta in stages will help control who can access it. Alex Breuer, Creative Director at the Guardian, said they found that showing the beta site to users coming in through search or social “was a gentle way of introducing the new Guardian experience.”
  • Assume early feedback will be negative if your beta site excludes content or functionality from the old site. Help stakeholders understand that negative feedback is not a sign of failure—in fact, getting these comments early is the whole point of the beta.

Mobile-only responsive

Another rollout strategy—often but not always implemented in the context of a beta release—is to develop a responsive website that covers all sizes of smartphones and tablets, preserving the current fixed-width site for desktop users only. In a sense, this approach is a “responsive m-dot site,” but that word puzzle twists my brain into a knot, so let’s not call it that. We’ll call it a mobile-only responsive site.

A mobile-only responsive site buys an organization time to focus on larger, more complex issues. Companies know they need a site that serves mobile users, but they’re afraid to hurt existing desktop traffic. But they also know the site needs a complete redesign or major backend infrastructure improvements, so they don’t want to do a retrofit. In that sense, a mobile-only responsive design offers the best of both worlds. Teams can focus on getting the responsive design right, without dealing with the stakeholder politics and operational risks inherent in changing the desktop mothership.

But this approach is also the worst of both worlds—it allows stakeholders to keep believing that the desktop website is the “real” website, downplaying the large and growing population of mobile users. It also means, as with all m-dot sites, that smartphone and desktop users will suffer from the same performance hit due to server redirects.

Here’s what can you do to launch a successful mobile-only responsive site:

  • Treat it like a beta even if you’re not rolling it out in stages. Have a plan for gathering data, testing, and revising the responsive site. Over time, plan for a staged rollout to desktop users.
  • Make tough choices about content and functionality. This rollout strategy is most successful when it is used to clean up and pare down a site that’s gotten out of control. If you’re not prepared to make the hard decisions, just do a retrofit.
  • Educate your team on what makes a responsive website successful.
  • The risk with a skunkworks approach is that the “mobile” team will go off and do its own thing and the rest of the organization won’t learn from the experience.
  • Make it the real website. Set expectations that this process isn’t about building a “mobile” website—it’s about building a site that will eventually replace the desktop.
  • Know when to stop investing in the desktop site and shift resources to the responsive site. BBC News said that continuing to work on their desktop site “sucked resources and morale and that cost us dearly by delaying our strategic move to ‘Responsive News.’”

Section by section

Other organizations choose to start with a specific section—even one particular page or template type. Rather than doing the entire site at once, they choose to sandbox their efforts and give teams time to practice.

Which section should you start with? The answer to that question varies as widely as any other rollout approach. Some organizations report that they picked a section they knew they wanted to redesign. Celebrity Cruises started with their Destinations section, making it responsive as part of a larger effort to rewrite content and replatform the CMS. Other companies start with a less popular section, a section run by stakeholders who are excited about the process, or one that gets a disproportionate amount of mobile traffic.

And then there’s Microsoft, which started with their homepage. This Potemkin village approach to a responsive redesign can frustrate users—promising them a website that works well on mobile devices, only to betray those expectations on the first tap. But Chris Balt, Senior Web Product Manager at Microsoft, reported that it helped them get organizational buy-in on going responsive:

Other sites have taken different approaches, starting from the bottom up or with some out-of-the-way corner of the site. Our attempt to do it first with the homepage—and beautifully so, if I say so myself—was a good choice. It led to significant visibility that I don’t think we would have gotten if we had started with some second-level support site or something like that. So even though the experience for a user may have suffered—they are one click away from a non-responsive experience—the visibility that it obtained us politically, organizationally, both inside and outside the company, made it a great choice. I am very glad that we did it that way.

Here’s how you might go about rolling out a responsive redesign by section:

  • Choose a section that reflects the types of problems or design patterns you’ll find elsewhere on the site. Some sections, like “Investor Relations” or “About Us,” may be easier to implement because they have relatively simple content and layouts—but they won’t provide as much insight about how to handle more complex problems.
  • Focus on your core. As with Pilates, your core does all the work. Look at your traffic and usage data to identify the pages and sections of the site that matter the most to users. Put your energy there.
  • Make sure your first-round stakeholders are on board with the extra effort required to support the redesign. They’ll be asked to make unfamiliar decisions—and they’ll need to share and defend their rationale with the rest of the organization.
  • Track and document scope to inform future initiatives. Knowing how long certain processes take, where design and development teams ran into difficulty, and which decisions were challenging for stakeholders will help you plan the next phase of work.
  • Make global decisions with everyone in mind. Some choices really do affect everyone. Dealing with responsive images, designing navigation menus, identifying core content types, developing reusable modules as part of a design system—such topics require buy-in from more than just the people managing a particular page or section.