The Responsive Web (2015)

Part 2. Designing for the responsive web

Chapter 6. Adding content modules and typography

This chapter covers

· Adding a content module to the layout

· Building thorough demo content

· Adding web fonts using an external content delivery network

A few years ago, the American public broadcaster NPR began to expand its digital channels. At the time, they had a few iOS and Android apps, as well as a website. To serve content to these channels, they created an API that would feed content to a server; the websites and applications would then request articles from that server and pass them to the users as XML files (see figure 6.1).

Figure 6.1. NPR’s original and new API architectures (from http://blog.programmableweb.com/2011/04/18/what-we-did-wrong-npr-improves-its-api-architecture/)

By using this API, NPR only had to change the presentation layer to meet the needs of the different platforms, and they could rely on the XML feed for content. As a result, NPR has developed a robust library of applications that listeners can use to consume content in the format and on the device that they prefer.

Although this example is related to developing a suite of applications, the lesson is important. Content is the substance of everything we do online. Layout is the foundation for the content’s display, but it’s the content itself that the user is visiting for. The formats might change—it might be video, audio, text, or even some sort of experience—but ultimately every visitor is looking for some sort of content.

Designer insight: identifying what the user needs

In the example site we’ve been developing, the content is pretty clear. We’re creating a site to host blog articles. This is a luxury. Sometimes you won’t know what the content will be—I’ve often had clients come to me looking for “a website.” They aren’t really sure what they want to say or how they want to say it, so the obvious first step for me is to start building a website and then figure out where we need content and start plugging something in. I realize how counterintuitive this process is and how much harm it can do to the creation of a quality experience. Even if a site appears simple, it’s crucial to identify why somebody might be there and to build around that purpose.

At one point I was talking with a friend about a site I was building for a nearby restaurant. We talked about what the experience of the site should be and what images and interactions to use. I made the point that 90% of people just want to find a nearby restaurant and look at the menu. “Then that should be your site,” he told me. I argued that this would be too simple, that there should be more to it than that. “Why?” he asked me. “You just said that 90% of the visitors just want the menu and the location. Why can’t it just be that?”

My friend made a point that changed how I look at the content of the pages I build. If you know what people want, why waste time and money building something nobody will use?

What do users want from our blog site? The site is an outlet for writing and for sharing ideas on web development, so written content is our focus. We want the most recent article front and center when the user visits. A typical post includes an image, a headline, the publication date, and tags.

In this chapter, we’ll create a content area in a mobile view. All the techniques in this chapter can be applied to any responsive site you’re working on, because almost all sites have and need content.

6.1. Adding a content module

In the first two chapters, we discussed the benefits of designing sites for mobile first. When taking this approach, it’s important to identify the necessary components of the site and how their space needs are adjusted as the width of a site increases. Width is a fixed resource in the browser window, as we discussed in the previous chapters. This is one of the most visible driving factors behind the need for responsive websites, and it has the deepest effect on how you curate the content of your site.

Let’s get started with the coding of our content module.

Designer insight: space- and content-aware design

I have a close friend who is a talented painter and artist. When she sets up an art exhibit, she always goes to the space where the exhibit is being held so she can choose the right work to display. It’s crucial to the work that she curates her exhibits in the context of the space they will occupy. This is similar to the task that we as developers take on in building and designing our sites. Often our role is that of curator, but in order to properly curate our sites, we have to first be aware of the space our content will be displayed in. It involves more than simply making the content of the site bigger or smaller; it involves determining what’s important and how it is best consumed.

Each of our content modules is like a piece of art. Each has its unique properties and purposes. The content might be a video, a block of text, an image, or an experience, but more often than not it’s a combination of these.

6.1.1. Creating useful placeholder content

In our prototype (figure 1.8), we included a few paragraphs of placeholder text. Now we need to add a set of commonly used HTML elements into our placeholder article so we can start building a typographic base for our written content. You’ll want to see how inline elements, such as bolded text, links, and italicized text, as well as block elements, such as unordered lists and headlines within the article, use standard HTML tags.

This typographic base will be the beginning of a typographic standard for our site. Although we don’t want to start defining typefaces yet (we’ll do that later in this chapter using the typefaces specified in chapter 3’s style tile), we’ll put the elements in place so we can see how they look as the site expands and the layout changes.

The HTML markup will look something like this (it’s included in the 6.1 directory of this chapter’s source code):

This covers all the elements included in the prototype, as well as a good number of base-level typographical elements. There’s a lot of base level content here, and I’ve kept the use of classes to a minimum because, again, we’re only looking at the site’s core. We want to focus on this core because it gives us a large set of elements that we can anticipate using in our final product.

If we modeled our core around a single blog post, we couldn’t possibly anticipate all the content types we’d need as the site grows. For instance, one post might only need some paragraphs and an image, but another might need unordered lists and inline bold elements. When building a core for a site, it’s best to anticipate the various use cases early.

Now we have a lot of unstyled markup without any CSS to govern its layout. Without CSS in place, our content is going to look pretty rough. Take a look at the left side of figure 6.2.

Figure 6.2. Two versions of our content module. On the left, the content module is full and in place. On the right, the content within the module has some subtle changes applied with CSS.

As it stands, our page looks pretty raw, which is fine, but some pieces overlap and the layout needs to be put in place. We’re going to use CSS to tidy things up, and then we can start making some typographic decisions:

Now that we’ve put our content in place and the header and content are no longer overlapping, let’s apply some rules so we can govern the content’s positioning. We’re going to apply a light gray background and then add some sizing rules.

To review, our HTML looks like this:

</aside>

To position the aside elements, we’ll apply style and layout with the following CSS rules:

This produces the layout shown in figure 6.3.

Figure 6.3. Our sidebar in place, with the date and three tags. In the left version, the “article-data” aside is unstyled, and on the right the “article-data” aside has style and float applied to it, giving it the grey box and adjusting the content to the left side of the parent element.

We now have our content module laid out and we’re ready to start moving the scale up. This process will be similar to what we did in previous chapters when we adjusted the layout elements for larger screens, or where we adjusted the grid layout, so we won’t go through the layout tweaks for bigger viewports. What’s important here is how the content—specifically the typography—looks in the scaled-up viewports.

6.2. Typography in responsive design

Typography is the art of combining typefaces, font sizes, line lengths, white space, word spaces, line breaks, and all other elements that represent visual text. It’s an absolutely crucial part of web design, because most of the web’s content comes in the form of the written word.

It’s difficult for a designer to anticipate exactly what form that written content will take, particularly in a blog, where the content will vary from entry to entry. One of the most common problems occurs when a site is designed to house a finite amount of content. If design takes precedence over function and content, a site can be prone to breaking. For instance, a designer might mock up a headline in a layout based on some placeholder copy. When the design is adjusted for mobile, tablet, and desktop views, the placeholder copy remains the same. If the designer hasn’t allowed for variation, such as a headline that’s three lines long instead of the two in the mockup, the layout will need to be adjusted. Similarly, if the headline is only one line of text, it may leave a big open space where the design expects more headline to go.

When designing content areas, it’s absolutely crucial to keep this problem in mind. One of the ways to combat this is to set a character count for the articles, but this can be cumbersome to maintain. Imagine CMS builds where every text input has a minimum and maximum text length to keep the page consistent. It could take days of work, and in the end the client may find these constraints too limiting.

Because content is always being generated, and therefore is always evolving, producing prototypes and style tiles, then layouts, and finally applying the design is a better route than wedging content into a design. In this section, we’ll go over a few ways you can design content for the web and start to establish the visual identity of the site.

6.2.1. Embedding typefaces

In chapter 3 (figure 3.5), we set some typefaces in our style tile: Nunito for body copy and subheads and Lora for headlines. In order to render these fonts on the page, we’ll take advantage of Google Fonts (discussed in chapter 2). It’s free to use and hosts a wide variety of typefaces. There are other services available that charge for use, but for our purposes we’ll stick with Google.

Designer insight: web fonts

Web fonts offer a lot of options for designers and can make a site look great, but they’re also easy to abuse. It’s easy to use too many fonts, or fonts that aren’t available or licensed for web use.

First, you need to find the fonts in Google Fonts. This is as simple as visiting www.google.com/fonts and entering the font name into the search field on the left or browsing for a font that looks good. For this example, search for Nunito.

Once you’ve found the proper typeface, you need to include style variations (as in figure 6.4). To do so, click the Add to Collection button to add the default normal variation. To view and select other variations, click the Show All Styles icon and select the variations you want to include. The Normal and Bold styles are included in figure 6.4 (Normal 400 and Bold 700).

Figure 6.4. Selecting the styles to use. Be careful to only add the styles you need. Browsers do a good job of italicizing text on their own, but I recommend selecting a bold style if it’s available, because font weight can render awkwardly in the browser.

Do this again for the Lora typeface and you should have your collection. With Lora, you only need to add the bold style, because you’ll only use it for headlines.

Once you’re done, click Use and proceed to get the code needed. In this screen you can adjust the typefaces in use to reduce the page burden. A little further down, you’ll find the link to include the fonts on your page. It should be included in the head of your HTML document and should look like this:

The linked resource will include the three required font faces specified in the href link, right after css?: ?family=Lora:700|Nunito:400,700. The numbers after the font names are the font styles. For Lora the request is for the bold 700 style and for Nunito both normal 400 and bold 700 styles. This will be the typographic palette.

Your fonts are now ready to be used on the page. You can call the fonts in your CSS and start setting the typographic core for the site.

Developer insight: CSS file structure

In the code samples, all of the CSS is in a single stylesheet to keep things in one place for your reference. Personally, I like to use separate files for my typographic base and core layout styles.

I also like having all my CSS for the mobile site in a single stylesheet, which is the only stylesheet I serve to mobile devices. This keeps the mobile load time as low as possible.

Ultimately I like to maintain a working base of two or three files, depending on total site size: one file for core layout, type, and mobile CSS, another for mid-sized or tablet browsers (if necessary), and another for desktop browsers. Sometimes a separate tablet file isn’t necessary, depending on the variance between mobile and desktop.

6.2.2. Setting a typographic base

Because content is the absolute core of our page, setting the base for the site’s typography is a crucial step. In some cases you might find that your core content is video or images, but even in these cases the web requires a lot of written content. Setting the type is like setting the base melody in a symphony. Once you have your melody in place, you can start building upon that. The base may change at times or require some tweaking, but it serves as a nice foundation on which the site can grow.

Let’s start by adding the appropriate typefaces to the high-level selectors. Because almost all of the copy will rely on the Nunito typeface, you can set that as the body font with this line of CSS at the top of the stylesheet:

body{font-family:'Nunito', arial, sans-serif ;}

Now you can override this style on your h1 tags with this code:

h1{font-family: 'Lora', 'Times New Roman', serif}

Now that you’re using the fonts from Google, as seen in figure 6.5, you need to set the sizes. In chapter 1 we discussed using the em instead of pixels for font sizing. Let’s put this knowledge to use here.

Figure 6.5. The web fonts in action. As you can see, the site is beginning to take on a little more personality.

You want to find an easily readable size for your type—20 pixels is a good starting point. You can set the font-size on the body tag to 20px so you have a base to start with, and you can adjust from there:

body{

font-size: 20px;

font-family:'Nunito', arial, sans-serif ;

}

The h1 tag should contain the biggest font on the page (this could change in different content modules, but bear with me on this one). Remember, when setting em sizes, 1 em is always relative to the parent element’s font-size. In this case 1 em is 20 pixels. After some dabbling in the mobile view, I’ve found 1.75 em to be a nice starting point:

h1{

font-size: 1.75em;

font-family: 'Lora', 'Times New Roman', serif;

}

From here, you can start balancing out the headers. The header text sizes should get incrementally smaller, ending with an H6, which I like to make smaller than the body copy:

h2{font-size:1.6em;}

h3{font-size:1.4em;}

h4{font-size:1.25em;}

h5{font-size:1em;}

h6{font-size:0.8em;}

In figure 6.6, we’ve scaled down our headings, but with only one minor adjustment to the CSS. It’s important to keep in mind as you build your site that if you want a smaller headline, you should resist the temptation to scale down the tag using CSS. Instead, try using the proper tag for the size you want.

Figure 6.6. The headlines are now easily readable, and they size down nicely.

The process of writing utilitarian CSS also applies to creating classes for modules. Once you have a base, you might find that in another module you want a smaller typeface, such as for some thumbnails at the bottom of the page. You can keep your site styles consistent and change the size of the type contained across multiple objects by applying a class to the shared parent element. As a site evolves between viewports, type that might look great on one screen might be too small or big on another.

6.3. Summary

In this chapter we added a content module and filled it with content. We also discussed how to build a base typographic palette and include some sizing and styles. In doing this, we’re preparing the canvas for our content.

We started with a simple prototype and a style tile, and now we’ve got something that’s starting to look like a website. With a little more work, we’ll have something that looks even more like a well-designed website. In the next chapter, we’ll add graphics and apply more of our visual brand to the page.

6.4. Discussion points

· How does building modular CSS affect your build and design processes?

· When considering what typefaces to use for a design, what do you consider?

· If you use Photoshop or any other graphic editing program, does its user interface allow for designing modularly? If so, how?