The Responsive Web (2015)
Part 2. Designing for the responsive web
Chapter 4. Responsive user experience design patterns
This chapter covers
· The origins and importance of design patterns
· Using two different design patterns to solve the same problem
The architect Christopher Alexander is famous for his theories on the use of patterns in design, and his work has influenced software developers since the late ’60s in various areas such as language design and modular programming.[1] His greatest influence has been on the development of software design patterns, popularized by Gamma, Helm, Johnson, and Vlissides in their 1995 book Design Patterns.[2] In building architecture, a design pattern is a way of documenting recurring problems and their solutions. In responsive design, design patterns help you avoid mistakes you’ve made in the past and establish familiar solutions to the common problems of web development.
1 Nikos Salingaros, “Some Notes on Christopher Alexander,” http://mng.bx/ZUdO.
2 Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional, 1995).
It would be impossible to list and create examples in this chapter for every responsive design pattern, primarily because these solutions are still being discovered, but also because doing so would fill an entire book.[3] Instead, I’ve opted to present two design patterns for navigation to show you how different solutions can achieve similar results. We’ll focus on navigation because we already established a navigation design pattern in chapter 2 (the off-canvas design pattern), and also because it’s a complex problem with multiple solutions.
3 A list of responsive design patterns can be found on This Is Responsive: http://bradfrost.github.io/this-is-responsive/patterns.html.
It’s important to explore the flexibility of the web and find accessible solutions to the specific challenges raised by your sites, so let’s do that before we go forward with building the site in HTML and CSS.
Designer insight: user experience and site navigation
This chapter covers some elements directly related to the user’s experience of a site. In some workplaces, you may have a specialist in user experience design. But whether you do or not, user experience is ultimately the responsibility of everyone involved in the project.
Navigation design is a very broad subject, and although the following chapters will present a few ways to approach it in a responsive site, educating yourself on the discipline of user experience is a good idea. A great starting resource is the book Don’t Make Me Think!, Second Edition, by Steve Krug (New Riders, 2005).
Developer insight: why build from scratch
Earlier I used Foundation to build a navigation prototype, but here we’re building one from scratch. Why? The reason for this is simple—every site is unique.
When I was a kid in shop class, my teacher taught me to use every saw in the room. Each saw had its own uses and added its own flair to a cut. By learning my tools and their uses, I expanded my ability to create. If you don’t diversify your toolset, you can’t diversify the kind of work you produce, and you begin to limit your creativity.
It’s easy to use a framework and make it work for the design you’ve been given; I’ve had to do that on multiple projects, mostly when time was an issue. But in most of my work, clients have a unique problem or need, and they come to me to solve it. Ultimately, knowing what’s going on under the hood will give you more control over what you can build. Conversely, depending on a third-party framework will limit the kind of work you can do. To become a mature and well-rounded front-end developer, you have to break free of your dependency on frameworks.
4.1. Single-level navigation
Typically, sites are navigated through a series of links or buttons that sit at the very top of a web page. Top-level navigation commonly serves as a portal throughout the site. Single-level refers to the fact that there’s no hidden or secondary navigation; there’s only one level of navigation (Home, About, Products, and Contact in figure 4.1).
Figure 4.1. An example of a site’s top-level navigation
The problem with this in a responsive site is that the links and logos could get broken up and jumbled when displayed on a phone or tablet. In chapter 2, we talked about using off-canvas navigation to solve this sort of problem, but that isn’t the only solution. Off-canvas navigation is a very common pattern and gives you some flexibility in adding layers to your horizontal spacing, but it can also be limiting; hiding all of the navigation for a site behind a toggle button introduces a single point of failure within the user experience. In spite of these shortcomings, it remains the dominant solution for responsive layouts due to its versatility and ease of use.
Designer insight: taking advantage of vertical space
One of the obvious reasons for using off-canvas navigation is to add some functionality to the very top of a page. This is useful because of the limited horizontal space in a mobile environment. Horizontal space is one of the defining characteristics of small screens; in development, we commonly set media queries strictly against the site’s width.
There’s an old publishing term that used to get thrown around a lot in web development: “above the fold.” It’s a reference to newspapers, where the top story and most expensive ad space are above the fold on the front page. If an article was really good or an advertiser paid the right price, that content would be placed above the fold.
In web design, this “above the fold” space manifested as the space on a page that’s visible without scrolling. This screen real estate has been prized and has led to the trend of placing a carousel module in this space, so that more content can claim to be above this metaphorical fold. Unfortunately, the fold is a myth. In reality, content below the fold is viewed a great deal more than content in the second slide of a carousel.
According to ClickTale, a heatmap service provider, users scrolled 76% of pages with a scroll bar, and 22% were scrolled all the way to bottom.[a] WeedyGarden reports that if a home page carousel is clicked, the first slide is clicked 84% of the time and the remaining clicks are split between the other slides.[b].
a “Unfolding the Fold,” ClickTale blog, http://mng.bz/8nBx.
b Erik Runyon, “Carousel Interaction Stats,” WeedyGarden, http://weedygarden.net/2013/01/carousel-stats/.
Web design offers many unique opportunities, but one of the less exploited is the availability of vertical space. A site has, literally, unlimited vertical space, but horizontal space is always dependent on the width of the browser window and is always a finite resource. Take advantage of this vertical space. Users will scroll down if your site looks good and loads quickly. Every meaningful visitor is there for a reason, and they’ll be happy to explore your site if there’s good content and a beautiful structure.
To solve the problem of top-level navigation in responsive design, let’s focus on a couple of design patterns: toggle navigation and select menu. After we look at these patterns, we’ll discuss the benefits and challenges of these two approaches and then move on to multilevel integration.
4.1.1. The toggle navigation pattern
The toggle navigation pattern is a method of displaying all of the top-level navigation below a menu button on smaller screens. The navigation toggles between the collapsed, inactive state and the expanded, active state when you tap the menu button. A good example of this can be seen on Starbucks.com, as shown in figure 4.2.
Figure 4.2. The responsive navigation on Starbucks.com
In single-level navigation, the menu on the desktop will mirror our earlier example in chapter 2. In a small-screen environment, the navigation will appear simply as a logo and a Menu button, with the content immediately below. Once the Menu button is tapped, the navigation expands downward and pushes the content further down.
Figure 4.3 shows a mockup of the default (collapsed) and expanded states. The default state is what you’d see when the page is first displayed. The expanded state is what you’d see after tapping on the Menu button.
Figure 4.3. A small-screen toggle navigation menu. On the left is the default, collapsed, “inactive” state; on the right is the expanded “active” state.
This design pattern has advantages in design as well as in development. As a design feature, this navigation is consistent in feel with the desktop version. The user looks to the same area for navigation in both desktop and mobile layouts, but because the navigation in the mobile layout is toggled behind a menu button, it has a smaller footprint. For the developer, this toggle navigation is easier to implement than some of the other navigation design patterns.
Coding the toggle navigation
To code the toggle navigation, we’ll use some HTML, CSS, and a little jQuery to toggle the expanded active state. First, here’s the HTML, which can be found in the source code, in the 4.1 directory:
This is some strictly bare-bones markup. By default, we’ll hide the navigation; we’ll reveal it if the class of is-expanded is applied. We’ll even animate it a little with a CSS transition. CSS transitions can help sell the effect of hiding and revealing the interface and give the user a little more context:
Now add a media query to remove the Menu button and display the navigation. This code can be found in the 4.2 directory:
@media(min-width:700px){
#logo {
width:200px;
}
#menu {
display: none;
}
nav, nav.is-expanded {
height:60px;
width:500px;
float: right;
}
ul {
width: 500px;
}
li{
width:25%;
}
article {
float:left;
}
}
This toggle navigation helps move relevant content up to the top of the page on an initial page load, so the page’s content takes priority and the user doesn’t have to scroll through navigation items. In a desktop view, the navigation returns to being fully visible and accessible.
This approach has the benefit of keeping the navigation isolated at the top of the page, so if more elements are added, the layout doesn’t break. It relies on a little bit of jQuery, but it could be converted easily to plain JavaScript to eliminate the need for a framework.
Here’s what it looks like using jQuery (a demo can be viewed in the 4.3 directory):
$('#menu').click(function(){
$('nav').toggleClass('is-expanded');
});
And here’s the JavaScript equivalent for modern browsers that support the standard addEventListener method (there’s a demo in the 4.4 directory):
document.getElementById('menu').addEventListener('click', function(){
var el = document.getElementById('nav');
el.className = el.className + 'is-expanded';
},false );
One of the biggest benefits of toggle navigation is that it easily scales up for a second level of navigation. This is useful if you have a complex site that requires a level of nested navigation; for instance, your site might have subpages within one section. Later in this chapter, we’ll look at an example of how you can build multilevel navigation with the toggle navigation pattern.
Toggle navigation is one way to solve the problem of responsive navigation. It’s great because it maintains a single codebase and can be rearranged to fit mobile and desktop environments. The biggest shortcoming of toggle navigation is that it limits the number of elements you can have in the top levels. I find this pattern to be most useful in sites with a small content management system (CMS), like a WordPress blog or a small personal site.
It’s a good idea to keep your top-level navigation direct and simple, but in a very complex site, such as an e-commerce site or a large-scale online magazine, toggle navigation becomes too limiting. In these cases, a combination of off-canvas navigation and toggle navigation can be successful, but in large-scale sites it’s crucial to evaluate the needs of the specific site before making a decision.
Another design pattern that helps solve the problem of responsive navigation is the select menu pattern.
4.1.2. The select menu pattern
The select menu pattern is one of the oldest responsive navigation design patterns; it provides simple interaction in a small space. This solution benefits the user in the same way that toggle navigation does, by reducing the vertical space the navigation occupies. When this navigation is triggered, the user engages with the browser’s default select menu interface.
Our goal is to create a single level of navigation in a mobile environment. When we scale down to the mobile viewport, we’ll see something a little different from the toggle navigation pattern. Here we’ll have a <select> dropdown list in place of a menu, as shown in figure 4.4.
Figure 4.4. A small-screen select menu. On the left is the collapsed state; on the right is the expanded, active state (using the iOS 5 default for the select menu).
Coding the select menu navigation
The code for the select menu navigation will be similar to the previous toggle navigation pattern, but instead of changing the format of the navigation code and hiding the menu, we’ll hide and show a select menu. The code for this is in the 4.5 directory.
Our header markup will look like this:
<header>
<div id="logo" class="l-half grey">Logo</div>
<select id="menu">
<option value="">Menu</option>
<option value="/home">Home</option>
<option value="/about">About</option>
<option value="/practice">Products</option>
<option value="/contact">Contact</option>
</select>
</header>
In menu, the value attribute will be the destination URL. Imagine that each option tag is an anchor; the href in the anchor would be the value in the option menu.
In the browser, this will do nothing by itself, so we need a little jQuery to make this work:
$("#menu").change(function onChange() {
window.location = $(this).find("option:selected").val();
});
With this little touch of jQuery, the user can navigate deeper into the site. The change method listens for the menu to change status and runs the onChange event handler once the event has taken place.
The main benefit of this pattern is that it uses a minimal amount of JavaScript. It saves space and uses the operating system’s user interface to display the navigation. This pattern is valuable when you’re dealing with a large number of links.
4.1.3. Toggle navigation versus select menu
There are several benefits and drawbacks to each of these design patterns. The toggle navigation pattern is effective at masking navigation elements and saving space in a small screen, but it suffers from a lack of versatility. The select menu is also compact and to the point, but it is, to be honest, a huge hack.
These are the immediate drawbacks of the select menu:
· It depends 100% on the browser’s support of JavaScript. If there’s no JavaScript, the user will be completely stuck.
· Select menus can be brutal to style across different browsers, and the creative graphic design can be compromised by the default styling. You’re very limited in your ability to control the presentation of the navigation.
· The select menu can’t be refactored for desktop views. If the user scales up to a desktop view, the select menu is completely ineffective and should be replaced with a desktop menu.
Toggle navigation also has several drawbacks:
· Toggle navigation favors simplicity and can lack the depth required for complex navigation patterns. If your site has multiple tiers of navigation, that might be difficult to maintain with toggle navigation.
· Toggle navigation takes advantage of vertical space. If you’re using a sticky header (you shouldn’t be, as I’ll explain shortly), the toggle navigation could end up getting cut off.
Developer insight: why you should avoid sticky headers
“The navigation should follow the user down the page. That way, if they need to move to another page, they can without scrolling up to the top.” (This is a quote from a UX guy I used to know.)
Here’s the problem with sticky headers: they take up too much space in mobile. I mentioned earlier how vertical space is an unlimited resource, but that’s not true if things are fixed on the page. When something is fixed on the page, it’s difficult to navigate around it, because its position is static. Fixed-size elements lack the fluidity required for changing viewports. The same problems start to arise when you apply a fixed position to anything on the page. When something is fixed, it’s not responding to its environment. Avoid fixed elements at all costs. (Modal pop-ups, I’m looking at you.)
These two navigation patterns meet varied needs and can be useful in different situations. Ultimately, I think the select menu pattern is good to use in a pinch, until you figure out something better. Whenever possible, though, I try to use toggle navigation or the off-canvas navigation that you saw in section 2.2.1.
4.2. Multilevel toggle navigation
We’ve covered a couple of basic navigation patterns in this chapter, but sometimes you need multiple tiers of navigation. In a select menu, these can simply be listed along with the other navigation elements, so an example isn’t very exciting, but toggle navigation can be expanded to accommodate a second tier, as shown in figure 4.5.
Figure 4.5. A desktop example of multilevel navigation
When you have a second tier in your navigation, you need to find ways to group navigation elements. In common desktop implementations, a navigation element is hovered over, and it reveals the second level of navigation. In a mobile implementation, the second tier can be shown between its parent element and the parent’s sibling, as you can see in figure 4.6.
Figure 4.6. Toggle navigation with nested elements. On the left is the usual expanded menu; on the right, the user has expanded the navigation one level deeper by tapping on Home.
In this figure, you can see an example of toggle navigation with a second tier. On the left, the navigation is one level deep, meaning that the user has expanded the menu using the Menu button. On the right, the user has expanded the navigation one level deeper by tapping on Home. This provides direct access to a subsection of pages.
Coding the multilevel toggle navigation
Here we have some HTML that displays a second menu level as an unordered list when its parent link is clicked. The code is available in the 4.6 directory:
Next, let’s style the multilevel navigation with some CSS, hiding the nested menus by default styling the subnav class:
The previous HTML and CSS will hide all the navigation at page load. In order to show the main navigation menu and subnavigation menus, you have to manipulate the navigation CSS classes with a little bit of JavaScript:
It’s important to limit the vertical space you’re using without removing important pieces of data or resources in small devices. With this code, you can achieve responsive multi-tier navigation that can adapt to small-screen devices. It’s yet another example of how you can adapt your sites to the responsive web.
4.3. Responsive user experience design pattern resources
As I mentioned at the beginning of the chapter, it’s really difficult to list all the patterns in a single chapter, in part because new patterns are always emerging. Brad Frost maintains a good repository of responsive patterns at the This is Responsive website seen in figure 4.7(http://bradfrost.github.io/this-is-responsive/patterns.html). This page provides an updated list of patterns that designers and programmers are using, classified by type: layout, navigation, images, media, forms, text, and modules (which are also called components in frameworks like Bootstrap).
Figure 4.7. An example of the list of responsive patterns available at the This Is Responsive website
The site also provides a comprehensive list of resources about responsive web design patterns (http://bradfrost.github.io/this-is-responsive/resources.html).
4.4. Summary
In this chapter, we’ve discussed responsive navigation patterns, and I’ve outlined two different approaches to top-level navigation in responsive designs. This is just the tip of the iceberg. There are patterns for page layouts, text elements, and modules, with new patterns being discovered and implemented every day.
I’ve presented these two patterns simply to show you that there can be multiple solutions to the same problem. By exploring the variety of possibilities, you can build, not according to trends, but to meet the specific needs of your site.
When attempting to solve the problem of responsive navigation, it’s important to keep the following questions in mind:
· What are the needs of this particular site? How is it going to be updated and how often?
· How can I take advantage of the space available in small-screen environments?
· Am I prioritizing the content and making sure the user has immediate access to what they came to this site for?
In the next chapter, we’ll dive into building site layouts using percentages. You’ll learn the fundamentals of working in percentages as opposed to using fixed-pixel layouts, and how to avoid making rigid websites.
4.5. Discussion points
· What commonly used web design patterns can you think of? For instance, this chapter deals with navigation, but what other patterns are frequently repeated in web design?
· When designing a site component that’s commonly used, how much do you rely on a pattern and how much do you innovate?