Category Archives: {categories backspace="2" show_group="3"}<a href="/topic/{category_url_title}">{category_name}</a>, {/categories}

Create a Content Compass

Posted by The fine folks at A List Apart |30 Jun 15 |

Project types

Chapter 2 mentioned that breaking off a small project might make sense, rather than tackling all the content across your organization at once. Make sure you remember where your project falls in your organization or client’s entire content universe.

Your project’s place in the organization’s content universe affects what you’re able to control or influence. It also is affected by the formal and informal strategies guiding content efforts throughout the organization.

Content strategy for an entire organization and across all channels is super complex and very steeped in business management and operations. For the purposes of this book, I focus on the three main project types I’ve encountered most: function, property, and subset.

Function

Function refers to a functional unit within an organization, such as sales, marketing, communications, customer service, or human resources. Of course, every organization is set up a bit differently, so yours could have different names for similar functions.

Very often, my client is a senior leader within one of these functions who wants help with content strategy across all the content types and delivery channels. Marketing is probably the most common.

Diagram showing that customer experience is an example of a functional unit within an organization.

Property

Property refers to a single digital destination, such as a website or an application, or even a social media channel, such as Facebook. Most of my digital property projects are for new website launches or existing website refreshes or redesigns. They could be a client’s primary web presence or a secondary web property for a product, service, event, or other singular purpose.

Other times, I’ll be asked to help specifically with a mobile site or mobile application. (Don’t get me started on mobile websites, but do read Karen McGrane’s book, Content Strategy for Mobile.)

Diagram showing how a website is an example of a single digital property targeted for a project.

Subset

Subset refers to any defined portion of content on a digital property. You can define that subset by where it lives in the site, such as the Help section or the About Us section. Or, you may define it by whom the content is for (current customers, prospective customers, and so on) or what the content is about (products, company information, area of expertise, and so on).

Diagram showing how the help section of a website is an example of a subset of digital content.

Core strategy statement

The core strategy statement is the central component of your content compass. It answers the fundamental questions for providing the right content, to the right people, at the right time, for the right reasons. Table 11.1 summarizes the four questions a core strategy statement must answer.

Content product What content should we produce, procure, curate, and share?
Audience Who, specifically, is that content for?
User needs Why do those audiences need or expect that content from us?
Business goals What outcomes does providing this content help us achieve?

Table 11.1 Core content strategy statement questions

What does a core strategy statement look like?

Core strategy statements come in many formats, and there’s no one right way to document one. A few key characteristics and concepts will help you craft an effective statement.

First, it must resonate with and be memorable for the people who need to know and use it so that they can apply the key concepts to make content decisions.

One way I’ve tested my statements is to present them to my colleagues with details about the four questions they answer and then ask them to recap the strategy. If people who don’t have much context for the project can get the gist and explain it back to me, it’s usually in pretty good shape.

Second, it needs to be prescriptive enough to allow you to say no. One way to check it is to look at your past 10 content projects. If you would have decided not to do some of those projects if you had had the statement at the time, it’s probably strong enough.

Let’s look at an example that my boss and CEO of Brain Traffic, Kristina Halvorson, has used in presentations (I changed it up a little).

To reduce customer service center costs, we will provide user-facing, task-based support content that makes our professional customers feel confident when configuring products for their clients.

Now let’s break that down a bit into the four key components. The business goal for this project is to decrease service center costs (by allowing people to self-serve). To do that, they’ll produce user-facing content that’s focused on tasks users want to complete. The content’s audience is the professional customers, meaning people who are quite experienced and who install the organization’s products for clients. The user need provides help with those installations.

The strategy statement with portions mapped to the business goal, the content product, the audience, and the user needs.

Next up, use the statement to make some content decisions. Use the list of content projects and ideas, such as in Table 11.2, and decide whether your organization should do them.

Yes No Idea
    Repurpose word-for-word content from the customer service call center knowledge base.
    Reorganize help content based on analytics data about frequency of use and search terms.
    Display an interactive timeline showing how product X was developed on the help landing page.
    Conduct user interviews of a survey with professional customers to find out if they are getting what they need from help content.
    Feature professional customer profiles throughout the help section.
    provide a video from our CEO about how important it is for customers to be able to self-serve on our site.

Table 11.2 Ideas for consideration

Here’s what I decided and why:

  • No to repurposing knowledge base content word for word because the internal knowledge-base content probably isn’t written in a user-facing way.
  • Yes to using analytics to reorganize the help section because that data can help ensure the content is organized the way users think about the content.
  • No to the interactive timeline because, while interesting, it would get in the way of tasks the user wants to complete while looking for support content.
  • Yes to doing some user interviews because finding out what’s working and not working from a user perspective could help make the content more useful.
  • No to featuring profiles about professional customers throughout the help section because it’s not the kind of information users would be coming to the help section to read.
  • No to the video message from the CEO because demonstrating the care for self-service is more important than talking about it.

How do you craft a core strategy statement?

The best part about putting together your core strategy statement is that you already have all the information you need from the discovery phase. Even better, your stakeholders have already agreed on the important aspects: who the content is for, why they need it, and what the organization is trying to achieve.

Now you just need to put all that together and add some specificity about the kind of content to produce, through either a collaborative or individual approach.

Collaborative approach

With the collaborative method to crafting a core strategy statement, you hand out a Mad Lib worksheet to the stakeholders. They then work individually to fill in the blanks. This is one I’ve adapted from a version Sara Wachter-Boettcher created:

Organization, Department, Property, Section> helps our company accomplish this goal> and this goal> by providing descriptive phrase> and descriptive phrase> content that makes this audience> feel this emotion or adjective> and this emotion or adjective> so they can complete this task> or complete this task>.

If I’m doing this exercise in-person, I have each person read their statement out loud with no discussion. Then, I’ll ask them to talk about the similarities and differences, the words or phrases that resonated most or didn’t seem quite right, and anything else that stood out to the group.

From there, I take a stab at combining everything into a single statement and getting agreement from stakeholders on the aggregated version. You don’t need to wordsmith it at this point; just get the concepts down. You can make it an editorial masterpiece later (or not).

If you have time, brainstorm a list of recent content projects, and ask participants to say whether they would still do the projects given the statement they just created together. This is a great way to demonstrate how it works and set expectations about how it might affect future work.

If you can’t get the group together, you can send the Mad Lib out via email to stakeholders. The first time I did this, I was skeptical, but it actually worked fairly well.

You don’t get the benefit of the resulting discussion with the email approach. But you can go back to stakeholders to work through disagreements before you.

Individual approach

Some projects don’t have enough days in the timeline or dollars in the budget to craft the statement collaboratively with stakeholders. That’s OK. You can do it yourself.

I’m more of an internal processor of information, so my method is typically to grab my notebook or insights spreadsheet and start reading through my notes. I jot down the things that stick out related to content, audience, business goals, and user needs. I’ll start writing multiple versions of the core strategy statement until I feel I nailed it. That usually involves several renditions and pieces from each getting pulled together, edited, discarded, and massaged.

That approach works for me, but sometimes I get stuck and need to do something a bit more methodological. In those cases, I still grab my notebook or insights spreadsheet.

But I transfer the key insights to sticky notes, note cards, or slips of paper. Then, I categorize those insights into the four categories: business goals, content product, audience, and user needs. Next, I review each category to see what key themes or ideas emerge. And finally, I take those themes and work out the core strategy statement, which typically goes through several revisions.

Diagram of the process of crafting a strategy statement, showing how stakeholder insights are categorized, enabling themes to emerge, which lead to the statement draft.

Messaging framework

A messaging framework clarifies what you want your audiences to know and believe about you, and tries to prove that this message is true.

As a component of your content compass, the messaging framework helps ensure that every piece of content you create supports the framework. If it doesn’t, it doesn’t belong or needs to be revised.

What does a messaging framework look like?

As with a core strategy statement, you can document your messaging framework multiple ways. I tend to create something somewhat visual to show a hierarchy or progression. Other practitioners I know use bulleted lists.

I write the framework from the user’s perspective. Other practitioners write it in the organization’s voice. It really doesn’t matter, as long as you adhere to the following:

  • Make sure everyone who needs it has it.
  • Actually use it to make decisions about content.
  • Keep in mind that the messages are for you and the people in your organization who work on content.

One of the reasons I like to write the messaging framework from the users’ perspective is because it’s a nice foil to the core strategy statement. The core strategy statement is primarily written for the business. By writing the messaging framework from the users’ mindset, you have a well-rounded compass by which to set the direction for content and stay on track over time.

This example builds upon the core strategy statement and details the first impression you want professional customers to have when they visit the support section, why your support section is valuable to them, and how you’re demonstrating that value with your content. Notice that the proof statements are related to what the content communicates and how it’s organized (substance and structure).

Diagram showing an example of a messaging framework, progressing from first impression to value statement to proof.

How do you develop a messaging framework?

You probably won’t be surprised to read that you can do pretty much the same things you do for the core strategy statement. Like right down to the collaborative and individual approaches.

Mad Libs, again, work well in a collaborative setting. Some ideas for Mad Libs to have stakeholders fill out for each component of the framework include:

First impression
When a user first lands on the site, we want them to feel <blank> and <blank>.

Value statement
After spending a few minutes on our site, users should feel <blank> because they understand we provide <blank> and <blank>.

Proof
Our content demonstrates that we provide just what our users need because <blank>, <blank>, <blank>, and <blank>.

Once you’ve collected the Mad Libs, you can use the data to determine the patterns and themes and form those into the message framework. I go through that process in much the same way I create the core strategy statement—either processing the information in my head or using sticky notes to organize the data.

If you’re not able to get input from your stakeholders in the form of the Mad Libs, don’t worry. Chances are, you have all the information you need from your stakeholder interviews.

Grab your notebook or discovery insights spreadsheet. Better yet, do the Mad Lib and use your discovery insights to develop your messaging framework.

Show the way

Now that you have the two key components of your content strategy in place—core content strategy and messaging framework—you can tell your content people about them. Schedule some time with the key teams who work on content—from creating it to reviewing it to publishing it—to go over your content compass and how to use it.

The next chapter discusses developing a plan for measuring the effectiveness of your content strategy and resulting content efforts. Your content compass will help you decide what to measure.

Copyright © Brain Traffic, Inc. and Meghan Casey. All rights reserved by Pearson Education, Inc. and New Riders.

Create a Content Compass

Posted by The fine folks at A List Apart |30 Jun 15 |

Project types

Chapter 2 mentioned that breaking off a small project might make sense, rather than tackling all the content across your organization at once. Make sure you remember where your project falls in your organization or client’s entire content universe.

Your project’s place in the organization’s content universe affects what you’re able to control or influence. It also is affected by the formal and informal strategies guiding content efforts throughout the organization.

Content strategy for an entire organization and across all channels is super complex and very steeped in business management and operations. For the purposes of this book, I focus on the three main project types I’ve encountered most: function, property, and subset.

Function

Function refers to a functional unit within an organization, such as sales, marketing, communications, customer service, or human resources. Of course, every organization is set up a bit differently, so yours could have different names for similar functions.

Very often, my client is a senior leader within one of these functions who wants help with content strategy across all the content types and delivery channels. Marketing is probably the most common.

Diagram showing that customer experience is an example of a functional unit within an organization.

Property

Property refers to a single digital destination, such as a website or an application, or even a social media channel, such as Facebook. Most of my digital property projects are for new website launches or existing website refreshes or redesigns. They could be a client’s primary web presence or a secondary web property for a product, service, event, or other singular purpose.

Other times, I’ll be asked to help specifically with a mobile site or mobile application. (Don’t get me started on mobile websites, but do read Karen McGrane’s book, Content Strategy for Mobile.)

Diagram showing how a website is an example of a single digital property targeted for a project.

Subset

Subset refers to any defined portion of content on a digital property. You can define that subset by where it lives in the site, such as the Help section or the About Us section. Or, you may define it by whom the content is for (current customers, prospective customers, and so on) or what the content is about (products, company information, area of expertise, and so on).

Diagram showing how the help section of a website is an example of a subset of digital content.

Core strategy statement

The core strategy statement is the central component of your content compass. It answers the fundamental questions for providing the right content, to the right people, at the right time, for the right reasons. Table 11.1 summarizes the four questions a core strategy statement must answer.

Content product What content should we produce, procure, curate, and share?
Audience Who, specifically, is that content for?
User needs Why do those audiences need or expect that content from us?
Business goals What outcomes does providing this content help us achieve?

Table 11.1 Core content strategy statement questions

What does a core strategy statement look like?

Core strategy statements come in many formats, and there’s no one right way to document one. A few key characteristics and concepts will help you craft an effective statement.

First, it must resonate with and be memorable for the people who need to know and use it so that they can apply the key concepts to make content decisions.

One way I’ve tested my statements is to present them to my colleagues with details about the four questions they answer and then ask them to recap the strategy. If people who don’t have much context for the project can get the gist and explain it back to me, it’s usually in pretty good shape.

Second, it needs to be prescriptive enough to allow you to say no. One way to check it is to look at your past 10 content projects. If you would have decided not to do some of those projects if you had had the statement at the time, it’s probably strong enough.

Let’s look at an example that my boss and CEO of Brain Traffic, Kristina Halvorson, has used in presentations (I changed it up a little).

To reduce customer service center costs, we will provide user-facing, task-based support content that makes our professional customers feel confident when configuring products for their clients.

Now let’s break that down a bit into the four key components. The business goal for this project is to decrease service center costs (by allowing people to self-serve). To do that, they’ll produce user-facing content that’s focused on tasks users want to complete. The content’s audience is the professional customers, meaning people who are quite experienced and who install the organization’s products for clients. The user need provides help with those installations.

The strategy statement with portions mapped to the business goal, the content product, the audience, and the user needs.

Next up, use the statement to make some content decisions. Use the list of content projects and ideas, such as in Table 11.2, and decide whether your organization should do them.

Yes No Idea
    Repurpose word-for-word content from the customer service call center knowledge base.
    Reorganize help content based on analytics data about frequency of use and search terms.
    Display an interactive timeline showing how product X was developed on the help landing page.
    Conduct user interviews of a survey with professional customers to find out if they are getting what they need from help content.
    Feature professional customer profiles throughout the help section.
    provide a video from our CEO about how important it is for customers to be able to self-serve on our site.

Table 11.2 Ideas for consideration

Here’s what I decided and why:

  • No to repurposing knowledge base content word for word because the internal knowledge-base content probably isn’t written in a user-facing way.
  • Yes to using analytics to reorganize the help section because that data can help ensure the content is organized the way users think about the content.
  • No to the interactive timeline because, while interesting, it would get in the way of tasks the user wants to complete while looking for support content.
  • Yes to doing some user interviews because finding out what’s working and not working from a user perspective could help make the content more useful.
  • No to featuring profiles about professional customers throughout the help section because it’s not the kind of information users would be coming to the help section to read.
  • No to the video message from the CEO because demonstrating the care for self-service is more important than talking about it.

How do you craft a core strategy statement?

The best part about putting together your core strategy statement is that you already have all the information you need from the discovery phase. Even better, your stakeholders have already agreed on the important aspects: who the content is for, why they need it, and what the organization is trying to achieve.

Now you just need to put all that together and add some specificity about the kind of content to produce, through either a collaborative or individual approach.

Collaborative approach

With the collaborative method to crafting a core strategy statement, you hand out a Mad Lib worksheet to the stakeholders. They then work individually to fill in the blanks. This is one I’ve adapted from a version Sara Wachter-Boettcher created:

Organization, Department, Property, Section> helps our company accomplish this goal> and this goal> by providing descriptive phrase> and descriptive phrase> content that makes this audience> feel this emotion or adjective> and this emotion or adjective> so they can complete this task> or complete this task>.

If I’m doing this exercise in-person, I have each person read their statement out loud with no discussion. Then, I’ll ask them to talk about the similarities and differences, the words or phrases that resonated most or didn’t seem quite right, and anything else that stood out to the group.

From there, I take a stab at combining everything into a single statement and getting agreement from stakeholders on the aggregated version. You don’t need to wordsmith it at this point; just get the concepts down. You can make it an editorial masterpiece later (or not).

If you have time, brainstorm a list of recent content projects, and ask participants to say whether they would still do the projects given the statement they just created together. This is a great way to demonstrate how it works and set expectations about how it might affect future work.

If you can’t get the group together, you can send the Mad Lib out via email to stakeholders. The first time I did this, I was skeptical, but it actually worked fairly well.

You don’t get the benefit of the resulting discussion with the email approach. But you can go back to stakeholders to work through disagreements before you.

Individual approach

Some projects don’t have enough days in the timeline or dollars in the budget to craft the statement collaboratively with stakeholders. That’s OK. You can do it yourself.

I’m more of an internal processor of information, so my method is typically to grab my notebook or insights spreadsheet and start reading through my notes. I jot down the things that stick out related to content, audience, business goals, and user needs. I’ll start writing multiple versions of the core strategy statement until I feel I nailed it. That usually involves several renditions and pieces from each getting pulled together, edited, discarded, and massaged.

That approach works for me, but sometimes I get stuck and need to do something a bit more methodological. In those cases, I still grab my notebook or insights spreadsheet.

But I transfer the key insights to sticky notes, note cards, or slips of paper. Then, I categorize those insights into the four categories: business goals, content product, audience, and user needs. Next, I review each category to see what key themes or ideas emerge. And finally, I take those themes and work out the core strategy statement, which typically goes through several revisions.

Diagram of the process of crafting a strategy statement, showing how stakeholder insights are categorized, enabling themes to emerge, which lead to the statement draft.

Messaging framework

A messaging framework clarifies what you want your audiences to know and believe about you, and tries to prove that this message is true.

As a component of your content compass, the messaging framework helps ensure that every piece of content you create supports the framework. If it doesn’t, it doesn’t belong or needs to be revised.

What does a messaging framework look like?

As with a core strategy statement, you can document your messaging framework multiple ways. I tend to create something somewhat visual to show a hierarchy or progression. Other practitioners I know use bulleted lists.

I write the framework from the user’s perspective. Other practitioners write it in the organization’s voice. It really doesn’t matter, as long as you adhere to the following:

  • Make sure everyone who needs it has it.
  • Actually use it to make decisions about content.
  • Keep in mind that the messages are for you and the people in your organization who work on content.

One of the reasons I like to write the messaging framework from the users’ perspective is because it’s a nice foil to the core strategy statement. The core strategy statement is primarily written for the business. By writing the messaging framework from the users’ mindset, you have a well-rounded compass by which to set the direction for content and stay on track over time.

This example builds upon the core strategy statement and details the first impression you want professional customers to have when they visit the support section, why your support section is valuable to them, and how you’re demonstrating that value with your content. Notice that the proof statements are related to what the content communicates and how it’s organized (substance and structure).

Diagram showing an example of a messaging framework, progressing from first impression to value statement to proof.

How do you develop a messaging framework?

You probably won’t be surprised to read that you can do pretty much the same things you do for the core strategy statement. Like right down to the collaborative and individual approaches.

Mad Libs, again, work well in a collaborative setting. Some ideas for Mad Libs to have stakeholders fill out for each component of the framework include:

First impression
When a user first lands on the site, we want them to feel <blank> and <blank>.

Value statement
After spending a few minutes on our site, users should feel <blank> because they understand we provide <blank> and <blank>.

Proof
Our content demonstrates that we provide just what our users need because <blank>, <blank>, <blank>, and <blank>.

Once you’ve collected the Mad Libs, you can use the data to determine the patterns and themes and form those into the message framework. I go through that process in much the same way I create the core strategy statement—either processing the information in my head or using sticky notes to organize the data.

If you’re not able to get input from your stakeholders in the form of the Mad Libs, don’t worry. Chances are, you have all the information you need from your stakeholder interviews.

Grab your notebook or discovery insights spreadsheet. Better yet, do the Mad Lib and use your discovery insights to develop your messaging framework.

Show the way

Now that you have the two key components of your content strategy in place—core content strategy and messaging framework—you can tell your content people about them. Schedule some time with the key teams who work on content—from creating it to reviewing it to publishing it—to go over your content compass and how to use it.

The next chapter discusses developing a plan for measuring the effectiveness of your content strategy and resulting content efforts. Your content compass will help you decide what to measure.

Copyright © Brain Traffic, Inc. and Meghan Casey. All rights reserved by Pearson Education, Inc. and New Riders.

Container Queries: Once More Unto the Breach

Posted by The fine folks at A List Apart |30 Jun 15 |

We’re a perseverant crew, the RICG. Responsive images were dead and buried forever in particularly dramatic fashion—what—two, three times there? “Dead and buried forever” refused to stick, though, thanks to all of you. Every time responsive images were knocked down, they got up a little stronger than before.

It isn’t hard to see why the going was so tough. Changing up a feature as old—and in software terms, as stable—as the img element was no small request. But designers and developers had spoken: we wanted a feature that stood to save our users a tremendous amount of bandwidth, and we carved out a seat at the same table as browser representatives and long-established standards bodies to make that feature happen. It was a long and failure-riddled process, but it’s what got us to the solutions we have today: not just one new element, but a whole suite of enhancements to the img element as well. Now we have options for smarter asset delivery based on any combination of viewport size, pixel density, and file format support.

After all that hard-won progress, there was no sense in packing up our GitHub organization and going home. We’ve changed the “I” in “RICG” from “Images” to “Issues,” and set our sights high right out of the gate: we aim to change the way we all write CSS.

The trouble with media queries

Styling a module meant to occupy multiple containers with viewport-based media queries means scoping that module’s styles to all the containers that it might occupy. That sentence isn’t the easiest thing in the world to parse, but it’s something I’m betting we’re all familiar with in practice.

The ideal responsive website is a system of flexible, modular components that can be repurposed to serve in multiple contexts. Using pattern libraries and tools like Brad Frost’s Pattern Lab, we should be able to style the most fundamental parts of a website in a vacuum, assemble them into cohesive modules independent of the page, and then include them in the page layout in whatever contexts they were meant to occupy. But the reality isn’t as clear-cut as it might sound.

For the sake of discussion, let’s say we’ve been tasked with building a landing page for a store that sells Whitworth-based tools, a measurement system known only to those brave enough—or foolhardy enough—to own a very old vehicle of British make. I count myself among the latter group.


Wireframes showing four widths of a basic product page layout.

It’s a pretty simple design. The whole page is made up of product modules that occupy a large central container, and one identical “featured item” module that occupies a secondary container. The overall page layout only changes at a single breakpoint, where the “featured item” container shifts to a sidebar. Here’s a very sparse demo illustrating that layout change. The CSS for this is an easy read:

.col-a,
.col-b {
	clear: both;
	float: left;
}
@media( min-width: 960px ) {
  .col-a,
	  .col-b {
		clear: none;
	}
	.col-a {
		width: 70%;
	}
	.col-b {
		width: 27%;
		float: right;
	}
}

We really only have to deal with the modules in two different contexts, and only at our highest breakpoint: the primary container and featured containers are the same width until the featured container turns into a sidebar. We’ll put a class of .featured on that container so we can scope our styles to it later on.

Now that we have the page layout squared away, we can focus on the layout of the individual modules. They’ll switch between a vertical and a horizontal layout, whichever is best for the available space:


The vertical layout stacks the product name above the product image, and the description, price, and “add to cart” button fall below that. In the horizontal layout, the image is aligned to the left, while the product name, description, price, and other meta information are to the right of the image.

The vertical layout really doesn’t need much finessing in CSS. The natural flow of our markup does most of the work for us; we’ll just make a few small tweaks to constrain the size of our product images and center them beyond that size:

.mod img {
	display: block;
	margin: 0 auto;
	width: 100%;
	max-width: 250px;
}

The styles for the horizontal layout aren’t too much harder. For now, we’ll focus on the primary container—so we won’t scope these styles to our .featured class. Since we want the modules to go back to the vertical layout above 800px for the three-across layout, we’ll only apply the horizontal layout styles between 400px and 799px:

@media( min-width: 400px ) and ( max-width: 799px ) {
	.mod img {
		float: left;
		width: 30%;
		max-width: 999px;
	}
	.mod .mod-header,
	  .mod .mod-desc {
		float: right;
		width: 68%;
		padding-left: 2%;
	}
}

Here’s how those styles play out in a real page. They work just fine, up to a point—in our “featured item” container, where there will only ever be one module at a time, things fall apart a little at medium breakpoints:


Screenshot showing that, at medium breakpoints, the “featured” module is using the same vertical layout as the other modules on the page, but it’s much too wide. It has more than enough room to use the horizontal layout.

Not ideal, but fixable. We’ll just write a new media query to overlap with the one we wrote for the modules in the primary container, then scope all our styles to the .featured class we put on that secondary container element:

@media( min-width: 40em ) and ( max-width: 60em ) {
	.featured .mod img {
		float: left;
		width: 30%;
	}
	.featured .mod .mod-header,
	  .featured .mod .mod-desc {
		float: right;
		width: 68%;
	}
}

Well, okay. This works just fine—as you can see here—but it’s a little gross, code-wise. Not a DRY approach to writing CSS, by a long shot.

This is still bearable when we’re working with such a simple design, but it can get a lot worse when we start fine-tuning details. For example, the vertical layout calls for the “add to cart” button to appear on the right side of the module, but there isn’t enough room when we switch to the three-across layout at medium breakpoints:


Screenshot showing that the vertical layout pushes the “add to cart” and “quantity remaining” modules below the price.

If we finesse our styles so the “add to cart” and “quantity remaining” modules deliberately break below the product prices at these sizes—aligned to the left, instead of floating in space on the right—our stylesheet tangles a little more.

Switching between left and right alignment for these elements is simple in terms of the styles themselves: we’re really only dealing with text-align and float properties on the “quantity remaining” and the “add to cart” button. For the media queries that control those simple styles, though, we have a whole list of considerations to work around. We’ll need to add two breakpoints to both of the existing breakpoints that handle vertical alignment. Those styles will impact our “featured” module as well, so we’ll need to override those new styles using our scoping class, with media queries to match. Since the featured module has a little more space to work with than the modules lined up three-across, the “add to cart” button can move back to the right sooner in that context, at the highest breakpoint—yet another breakpoint. But wait, there’s more: these styles aren’t future-proof. If we should ever want to add a module to a new context, we’ll have to copy and paste all our styles over again, with a new scoping class and a fistful of new media queries. If the size of the page layout changes in any way—more or less padding, margins, any size-based styling change to the layout elements—we’ll have to adjust all of those many, many media queries. We now have to find a new viewport size where our breakpoints make sense. Our decisions are disconnected from our layout.

This page comes nowhere near the level of complexity we might encounter in a real project, but we already have a tough stylesheet to maintain.

Enter element queries

All this complication comes from our reliance on the viewport to make our styling decisions. Media queries work just fine for our high-level page layout, but they’re nowhere near as useful for modular components. What we really need is the ability to style page components based on the space they occupy rather than the size of the viewport.

“Element queries” assume a syntax that does exactly that. We’re accustomed to writing a media query for styles that apply only when the viewport is greater than 40em, like this:

@media( min-width: 40em ) {
}

Instead, imagine a syntax where the query itself is scoped to an element and populated with styles that only apply when that element is larger than 40em:

.mod:media( min-width: 40em ) {
}

Well, this would change almost everything we’ve written for our Whitworth page so far. We might still use media queries for our page’s one major layout change, where we go from a linear layout to a larger primary element and a sidebar; basing that on the viewport size makes sense. Once we started building our modules themselves, though, this new syntax would allow us to write all the styles they could ever need just once:

.mod img {
	display: block;
	margin: 0 auto;
	width: 100%;
	max-width: 250px;
}

.mod:media( min-width: 425px ) img {
	float: left;
	width: 30%;
	max-width: 9999px;
}
.mod:media( min-width: 425px ) .mod-header,
.mod:media( min-width: 425px ) .mod-desc {
	float: right;
	width: 68%;
	padding-left: 2%;
}

That’s it, those are all the styles our module layouts will need—see for yourself in this demo, which uses a JavaScript shim to make this theoretical syntax work for real. When the module is larger than 425px, the browser uses the horizontal layout. If the module is smaller than 425px, the browser uses the vertical layout. The styling is now 100% dependent on the container that the module occupies—if it has enough space for the horizontal layout, those are the styles that get used. If we changed the three-across layout to two-across with each module occupying half the container, or we introduced a completely new and unpredictable context for one of these modules, we wouldn’t need to change a thing about their styling. Imagine how much more useful a pattern library would be if we removed the contextual dependency from these kinds of standalone modules: you’d be able to grab any component from the page and move it to any container in the page, without needing to rework hundreds of lines of CSS—without reworking any CSS at all.

For fine-tuning details like the position of the “add to cart” button and quantity remaining, things wouldn’t really get any more complex. Since we wouldn’t be dealing with scoping or finessing module breakpoints to match the viewport-based layout breakpoints, we’d only have one concern: “Is the module too small to have the price and ‘add to cart’ button side by side?” A little experimentation tells us that there’s enough room for both elements as long as the module is larger than 320px, and that’s where we’ll put our module-based breakpoint:

.mod:media( min-width: 320px ) .mod-cost {
	float: left;
}
.mod:media( min-width: 320px ) .mod-buy {
	float: right;
}
.mod:media( min-width: 320px ) .buy-remaining {
	text-align: right;
}

From dozens of lines of redundant CSS, media queries, and overrides to nine lines containing the styles we need. More important, nothing would break if any other styles on the page should change. You can try this out for yourself by fiddling with styles in your browser’s dev tools in this demo, which is using a script that mimics element query behavior—it isn’t something you’d want to use on a production website, but it’s a great way to get your head around the concept.

If this syntax existed, we’d be finished with this Whitworth project in just a few lines of CSS.

But element queries can’t exist—at least, not the way we’d been thinking about them. Just like the first version of the picture specification, element queries are dead and buried forever. But like the search for responsive images, we’re not about to let that stick—not when we have such a clear problem to solve.

Exit element queries

This concept isn’t a hard sell—not for us developers, anyway—but neither were responsive images. Once we get into the gritty implementation details, though, things change.

The first step for the RICG was framing out a Use Cases and Requirements document for element queries, describing and diagramming the problem—not proposing a solution, just providing a clear problem to be solved. So far it’s shaping up to be a lot more focused than the Use Cases and Requirements document for responsive images because it really only sets out to solve one overarching issue.

As word of this document got around, people started thinking through the problem a little further, just like we’d hoped. That led many of us to the same conclusion, before we’d even started tinkering with a proposed specification: element queries can never work.

This has been documented in more detail elsewhere, but the gist is this: we’re using CSS to control CSS, and that means we can cause infinitely looping style changes. If we can tell an element to restyle itself using an element query, what happens if we use that element query to change the element’s width to one where the element query no longer applies?

.our-element:media(min-width: 500px) {
	width: 499px;
}

Well, since the query no longer matches, the new width is no longer applied. Since that new width is never applied, the element query would match again, so the new width would be applied, so the query would no longer match, so the new width wouldn’t be applied—and so on unto infinity. We’ve achieved a TARDIS-caliber paradox with just a few lines of CSS, and there’s no predictable way for the browser to handle it. Should the browser, upon encountering one of these situations, throw the element query styles away entirely? Only throw away the new width? Uninstall itself from the user’s machine? Start a small-to-medium-sized fire? Nothing sounds particularly appealing about any of this, least of all from a browser maker’s standpoint. They’ll never let something with this kind of error potential see the light of day. Game over.

Exciting news, right? We figured out that element queries were impossible in a fraction of the time it took to figure out that responsive images were impossible. The first time, I mean.

Okay, hear me out on this. “Element queries” are over, sure, but the problem hasn’t changed—the Use Cases and Requirements document isn’t going anywhere. This still needs to be solved, and now we know how not to solve it: elements can’t be restyled based on their own properties.

Enter container queries

To solve the problem outlined in the Use Cases and Requirements document, we need to reframe the way we talk about a potential solution. Since a solution can’t allow an element to restyle itself, we can build that constraint into the specification: queries attached to an element can only influence the styling of that element’s child elements.

Armed with our new knowledge of the impossible, the search for element queries has been reframed as container queries.

What would this change about our Whitworth project? Well, nothing—we were only styling the child elements of .mod anyway, not .mod itself. It might just mean a few behavioral changes in terms of how the browser treats these elements. The browser couldn’t allow an element with an attached query to be influenced by the size of its child elements, for example. We might end up with an implicit browser-level overflow: auto style on any element with a query attached, to prevent the infinite looping behavior—much more predictable than the browser picking and choosing bits of our stylesheets to avoid melting down.

So, how do we keep things moving forward from here? By finding the next impossible-to-solve issue. So far, “container queries” have held up to more scrutiny than “element queries” did—but talk is cheap. This recursion issue is a big one, but it still only scratches the surface of the potential issues we could run into as a solution starts to materialize.

We’ll make a lot more progress by experimenting with this pattern, which isn’t the easiest thing to do when we’re dealing with syntaxes that don’t exist yet. That’s how we ended up with the very first version of Scott Jehl’s Picturefill, lo those many years ago. Without tinkering—without actually using something resembling the picture markup pattern—we couldn’t make much sense of the spec we were just starting to write. So in the same vein, the RICG has started up a repository for container query demos, using the same shim as our Whitworth demos. Now we can all try this syntax out for ourselves, and help find the issues we’ll run into when using this kind of CSS pattern for real—the sorts of problems you can only find by building something. Clone the repo, copy the demo-template directory into /demos, give your demo a name, and build something using container queries. Be sure to let us know how it goes, whether good or bad.

Exit container queries..?

As the first version of the container query spec comes together, well, its days may very well be numbered, too. The Use Cases and Requirements document isn’t going anywhere, though; the problem we need to solve is out there, looming, demanding that it be solved somehow.

The answer may be this very first proposal, for all we know. It might be something completely different—something we haven’t even begun to consider. But the RICG isn’t a decision-maker in the world of web standards, and we don’t aim to be one. We want to be a rallying point—to provide ways for designers and developers who might not want to wade through arcane listservs and IRC channels to get involved in the standards that affect their daily work.

There’ll be plenty more work to do after this, and we’ll need all of you to get it done. With your help—with thousands of designer and developer voices contributing to the search—it’s only a matter of time until we find the answer together. We’ve done it before, and we’ll do it again.

Stiffen the sinews; summon up the blood. Banish the phrase “element queries” from your vocabulary forever. Let’s get to work on container queries, regardless of what name or form they might take in the future.

Container Queries: Once More Unto the Breach

Posted by The fine folks at A List Apart |30 Jun 15 |

We’re a perseverant crew, the RICG. Responsive images were dead and buried forever in particularly dramatic fashion—what—two, three times there? “Dead and buried forever” refused to stick, though, thanks to all of you. Every time responsive images were knocked down, they got up a little stronger than before.

It isn’t hard to see why the going was so tough. Changing up a feature as old—and in software terms, as stable—as the img element was no small request. But designers and developers had spoken: we wanted a feature that stood to save our users a tremendous amount of bandwidth, and we carved out a seat at the same table as browser representatives and long-established standards bodies to make that feature happen. It was a long and failure-riddled process, but it’s what got us to the solutions we have today: not just one new element, but a whole suite of enhancements to the img element as well. Now we have options for smarter asset delivery based on any combination of viewport size, pixel density, and file format support.

After all that hard-won progress, there was no sense in packing up our GitHub organization and going home. We’ve changed the “I” in “RICG” from “Images” to “Issues,” and set our sights high right out of the gate: we aim to change the way we all write CSS.

The trouble with media queries

Styling a module meant to occupy multiple containers with viewport-based media queries means scoping that module’s styles to all the containers that it might occupy. That sentence isn’t the easiest thing in the world to parse, but it’s something I’m betting we’re all familiar with in practice.

The ideal responsive website is a system of flexible, modular components that can be repurposed to serve in multiple contexts. Using pattern libraries and tools like Brad Frost’s Pattern Lab, we should be able to style the most fundamental parts of a website in a vacuum, assemble them into cohesive modules independent of the page, and then include them in the page layout in whatever contexts they were meant to occupy. But the reality isn’t as clear-cut as it might sound.

For the sake of discussion, let’s say we’ve been tasked with building a landing page for a store that sells Whitworth-based tools, a measurement system known only to those brave enough—or foolhardy enough—to own a very old vehicle of British make. I count myself among the latter group.


Wireframes showing four widths of a basic product page layout.

It’s a pretty simple design. The whole page is made up of product modules that occupy a large central container, and one identical “featured item” module that occupies a secondary container. The overall page layout only changes at a single breakpoint, where the “featured item” container shifts to a sidebar. Here’s a very sparse demo illustrating that layout change. The CSS for this is an easy read:

.col-a,
.col-b {
	clear: both;
	float: left;
}
@media( min-width: 960px ) {
  .col-a,
	  .col-b {
		clear: none;
	}
	.col-a {
		width: 70%;
	}
	.col-b {
		width: 27%;
		float: right;
	}
}

We really only have to deal with the modules in two different contexts, and only at our highest breakpoint: the primary container and featured containers are the same width until the featured container turns into a sidebar. We’ll put a class of .featured on that container so we can scope our styles to it later on.

Now that we have the page layout squared away, we can focus on the layout of the individual modules. They’ll switch between a vertical and a horizontal layout, whichever is best for the available space:


The vertical layout stacks the product name above the product image, and the description, price, and “add to cart” button fall below that. In the horizontal layout, the image is aligned to the left, while the product name, description, price, and other meta information are to the right of the image.

The vertical layout really doesn’t need much finessing in CSS. The natural flow of our markup does most of the work for us; we’ll just make a few small tweaks to constrain the size of our product images and center them beyond that size:

.mod img {
	display: block;
	margin: 0 auto;
	width: 100%;
	max-width: 250px;
}

The styles for the horizontal layout aren’t too much harder. For now, we’ll focus on the primary container—so we won’t scope these styles to our .featured class. Since we want the modules to go back to the vertical layout above 800px for the three-across layout, we’ll only apply the horizontal layout styles between 400px and 799px:

@media( min-width: 400px ) and ( max-width: 799px ) {
	.mod img {
		float: left;
		width: 30%;
		max-width: 999px;
	}
	.mod .mod-header,
	  .mod .mod-desc {
		float: right;
		width: 68%;
		padding-left: 2%;
	}
}

Here’s how those styles play out in a real page. They work just fine, up to a point—in our “featured item” container, where there will only ever be one module at a time, things fall apart a little at medium breakpoints:


Screenshot showing that, at medium breakpoints, the “featured” module is using the same vertical layout as the other modules on the page, but it’s much too wide. It has more than enough room to use the horizontal layout.

Not ideal, but fixable. We’ll just write a new media query to overlap with the one we wrote for the modules in the primary container, then scope all our styles to the .featured class we put on that secondary container element:

@media( min-width: 40em ) and ( max-width: 60em ) {
	.featured .mod img {
		float: left;
		width: 30%;
	}
	.featured .mod .mod-header,
	  .featured .mod .mod-desc {
		float: right;
		width: 68%;
	}
}

Well, okay. This works just fine—as you can see here—but it’s a little gross, code-wise. Not a DRY approach to writing CSS, by a long shot.

This is still bearable when we’re working with such a simple design, but it can get a lot worse when we start fine-tuning details. For example, the vertical layout calls for the “add to cart” button to appear on the right side of the module, but there isn’t enough room when we switch to the three-across layout at medium breakpoints:


Screenshot showing that the vertical layout pushes the “add to cart” and “quantity remaining” modules below the price.

If we finesse our styles so the “add to cart” and “quantity remaining” modules deliberately break below the product prices at these sizes—aligned to the left, instead of floating in space on the right—our stylesheet tangles a little more.

Switching between left and right alignment for these elements is simple in terms of the styles themselves: we’re really only dealing with text-align and float properties on the “quantity remaining” and the “add to cart” button. For the media queries that control those simple styles, though, we have a whole list of considerations to work around. We’ll need to add two breakpoints to both of the existing breakpoints that handle vertical alignment. Those styles will impact our “featured” module as well, so we’ll need to override those new styles using our scoping class, with media queries to match. Since the featured module has a little more space to work with than the modules lined up three-across, the “add to cart” button can move back to the right sooner in that context, at the highest breakpoint—yet another breakpoint. But wait, there’s more: these styles aren’t future-proof. If we should ever want to add a module to a new context, we’ll have to copy and paste all our styles over again, with a new scoping class and a fistful of new media queries. If the size of the page layout changes in any way—more or less padding, margins, any size-based styling change to the layout elements—we’ll have to adjust all of those many, many media queries. We now have to find a new viewport size where our breakpoints make sense. Our decisions are disconnected from our layout.

This page comes nowhere near the level of complexity we might encounter in a real project, but we already have a tough stylesheet to maintain.

Enter element queries

All this complication comes from our reliance on the viewport to make our styling decisions. Media queries work just fine for our high-level page layout, but they’re nowhere near as useful for modular components. What we really need is the ability to style page components based on the space they occupy rather than the size of the viewport.

“Element queries” assume a syntax that does exactly that. We’re accustomed to writing a media query for styles that apply only when the viewport is greater than 40em, like this:

@media( min-width: 40em ) {
}

Instead, imagine a syntax where the query itself is scoped to an element and populated with styles that only apply when that element is larger than 40em:

.mod:media( min-width: 40em ) {
}

Well, this would change almost everything we’ve written for our Whitworth page so far. We might still use media queries for our page’s one major layout change, where we go from a linear layout to a larger primary element and a sidebar; basing that on the viewport size makes sense. Once we started building our modules themselves, though, this new syntax would allow us to write all the styles they could ever need just once:

.mod img {
	display: block;
	margin: 0 auto;
	width: 100%;
	max-width: 250px;
}

.mod:media( min-width: 425px ) img {
	float: left;
	width: 30%;
	max-width: 9999px;
}
.mod:media( min-width: 425px ) .mod-header,
.mod:media( min-width: 425px ) .mod-desc {
	float: right;
	width: 68%;
	padding-left: 2%;
}

That’s it, those are all the styles our module layouts will need—see for yourself in this demo, which uses a JavaScript shim to make this theoretical syntax work for real. When the module is larger than 425px, the browser uses the horizontal layout. If the module is smaller than 425px, the browser uses the vertical layout. The styling is now 100% dependent on the container that the module occupies—if it has enough space for the horizontal layout, those are the styles that get used. If we changed the three-across layout to two-across with each module occupying half the container, or we introduced a completely new and unpredictable context for one of these modules, we wouldn’t need to change a thing about their styling. Imagine how much more useful a pattern library would be if we removed the contextual dependency from these kinds of standalone modules: you’d be able to grab any component from the page and move it to any container in the page, without needing to rework hundreds of lines of CSS—without reworking any CSS at all.

For fine-tuning details like the position of the “add to cart” button and quantity remaining, things wouldn’t really get any more complex. Since we wouldn’t be dealing with scoping or finessing module breakpoints to match the viewport-based layout breakpoints, we’d only have one concern: “Is the module too small to have the price and ‘add to cart’ button side by side?” A little experimentation tells us that there’s enough room for both elements as long as the module is larger than 320px, and that’s where we’ll put our module-based breakpoint:

.mod:media( min-width: 320px ) .mod-cost {
	float: left;
}
.mod:media( min-width: 320px ) .mod-buy {
	float: right;
}
.mod:media( min-width: 320px ) .buy-remaining {
	text-align: right;
}

From dozens of lines of redundant CSS, media queries, and overrides to nine lines containing the styles we need. More important, nothing would break if any other styles on the page should change. You can try this out for yourself by fiddling with styles in your browser’s dev tools in this demo, which is using a script that mimics element query behavior—it isn’t something you’d want to use on a production website, but it’s a great way to get your head around the concept.

If this syntax existed, we’d be finished with this Whitworth project in just a few lines of CSS.

But element queries can’t exist—at least, not the way we’d been thinking about them. Just like the first version of the picture specification, element queries are dead and buried forever. But like the search for responsive images, we’re not about to let that stick—not when we have such a clear problem to solve.

Exit element queries

This concept isn’t a hard sell—not for us developers, anyway—but neither were responsive images. Once we get into the gritty implementation details, though, things change.

The first step for the RICG was framing out a Use Cases and Requirements document for element queries, describing and diagramming the problem—not proposing a solution, just providing a clear problem to be solved. So far it’s shaping up to be a lot more focused than the Use Cases and Requirements document for responsive images because it really only sets out to solve one overarching issue.

As word of this document got around, people started thinking through the problem a little further, just like we’d hoped. That led many of us to the same conclusion, before we’d even started tinkering with a proposed specification: element queries can never work.

This has been documented in more detail elsewhere, but the gist is this: we’re using CSS to control CSS, and that means we can cause infinitely looping style changes. If we can tell an element to restyle itself using an element query, what happens if we use that element query to change the element’s width to one where the element query no longer applies?

.our-element:media(min-width: 500px) {
	width: 499px;
}

Well, since the query no longer matches, the new width is no longer applied. Since that new width is never applied, the element query would match again, so the new width would be applied, so the query would no longer match, so the new width wouldn’t be applied—and so on unto infinity. We’ve achieved a TARDIS-caliber paradox with just a few lines of CSS, and there’s no predictable way for the browser to handle it. Should the browser, upon encountering one of these situations, throw the element query styles away entirely? Only throw away the new width? Uninstall itself from the user’s machine? Start a small-to-medium-sized fire? Nothing sounds particularly appealing about any of this, least of all from a browser maker’s standpoint. They’ll never let something with this kind of error potential see the light of day. Game over.

Exciting news, right? We figured out that element queries were impossible in a fraction of the time it took to figure out that responsive images were impossible. The first time, I mean.

Okay, hear me out on this. “Element queries” are over, sure, but the problem hasn’t changed—the Use Cases and Requirements document isn’t going anywhere. This still needs to be solved, and now we know how not to solve it: elements can’t be restyled based on their own properties.

Enter container queries

To solve the problem outlined in the Use Cases and Requirements document, we need to reframe the way we talk about a potential solution. Since a solution can’t allow an element to restyle itself, we can build that constraint into the specification: queries attached to an element can only influence the styling of that element’s child elements.

Armed with our new knowledge of the impossible, the search for element queries has been reframed as container queries.

What would this change about our Whitworth project? Well, nothing—we were only styling the child elements of .mod anyway, not .mod itself. It might just mean a few behavioral changes in terms of how the browser treats these elements. The browser couldn’t allow an element with an attached query to be influenced by the size of its child elements, for example. We might end up with an implicit browser-level overflow: auto style on any element with a query attached, to prevent the infinite looping behavior—much more predictable than the browser picking and choosing bits of our stylesheets to avoid melting down.

So, how do we keep things moving forward from here? By finding the next impossible-to-solve issue. So far, “container queries” have held up to more scrutiny than “element queries” did—but talk is cheap. This recursion issue is a big one, but it still only scratches the surface of the potential issues we could run into as a solution starts to materialize.

We’ll make a lot more progress by experimenting with this pattern, which isn’t the easiest thing to do when we’re dealing with syntaxes that don’t exist yet. That’s how we ended up with the very first version of Scott Jehl’s Picturefill, lo those many years ago. Without tinkering—without actually using something resembling the picture markup pattern—we couldn’t make much sense of the spec we were just starting to write. So in the same vein, the RICG has started up a repository for container query demos, using the same shim as our Whitworth demos. Now we can all try this syntax out for ourselves, and help find the issues we’ll run into when using this kind of CSS pattern for real—the sorts of problems you can only find by building something. Clone the repo, copy the demo-template directory into /demos, give your demo a name, and build something using container queries. Be sure to let us know how it goes, whether good or bad.

Exit container queries..?

As the first version of the container query spec comes together, well, its days may very well be numbered, too. The Use Cases and Requirements document isn’t going anywhere, though; the problem we need to solve is out there, looming, demanding that it be solved somehow.

The answer may be this very first proposal, for all we know. It might be something completely different—something we haven’t even begun to consider. But the RICG isn’t a decision-maker in the world of web standards, and we don’t aim to be one. We want to be a rallying point—to provide ways for designers and developers who might not want to wade through arcane listservs and IRC channels to get involved in the standards that affect their daily work.

There’ll be plenty more work to do after this, and we’ll need all of you to get it done. With your help—with thousands of designer and developer voices contributing to the search—it’s only a matter of time until we find the answer together. We’ve done it before, and we’ll do it again.

Stiffen the sinews; summon up the blood. Banish the phrase “element queries” from your vocabulary forever. Let’s get to work on container queries, regardless of what name or form they might take in the future.

The Homepage Exception

Posted by The fine folks at A List Apart |16 Jun 15 |

Everyone wants beautiful homepages. It doesn’t matter who’s running the organization, what industry they’re in, what design trend is hot, or what CMS is being used. A homepage is the front door to an organization, and organizations want homepages that reflect their sparkling missions and content.

Obviously this is where we, the web professionals, come in. We identify patterns in a company’s content and design. We build an ordered system to manage the site, with content stored in structured fields and cross-referenced by neatly stacked taxonomic containers. We build drool-worthy designs into pretty template patterns, into which a CMS can automagically flow that content. Relax, humans! The computer robots have got this.

And, of course, the robots drive homepage content, too. A common type of homepage—which I see a lot in my work with nonprofit organizations, but can be found in any industry—is a mix of somewhat static, explanatory content, with dynamic chunks populated by the most recently published content from a CMS. When these organizations are on tight budgets, often without a lot of staff and resources, it seems like a good idea to code the static parts and automate the dynamic parts. That way, staff doesn’t have to fuss with edits, updates, or technical interfaces, and the organization can focus on doing important work helping people. Homepage: done.

Until the request inevitably comes: the board of directors needs a slider because they want a way to highlight more than one post at a time. Furthermore, they need each slide to be able to feature a blog post OR a donate page OR an about page OR their gift catalog. And it’s important to the executive director that all static blurbs be wordsmithed especially for the homepage, and the blurbs may need to be tweaked during peak fundraising months. My easy homepage publishing system just left the building.

Maybe the robots shouldn’t win

After having this conversation about 242 times, I’ve realized that the homepage is almost always a giant exception to the rest of the ordered system for a reason. It’s the most human page on the site, where the potential helpfulness of computer robots collides with the messy reality of humans.

The homepage is a company’s elevator pitch that must telegraph an organization’s priorities and values as succinctly as possible. The fundraising department, program staff, and board members may feel anxious about ensuring their interests are visible on this valuable real estate. These internal forces, or the politics of partner organizations or funders, will affect what is presented on a homepage, even if it may not be the most logical choice for content, design, or structure.

Instead of wishing for (the ever-elusive) Total & Complete Control, it’s more useful to accept this human foible. Rather than fighting it, let’s build something specific to handle this exception better, in a way that’s least likely to break down the road.

Of blobs and chunks

Here’s a homepage I am currently rebuilding for Small Can Be Big, a non-profit project of the marketing agency Boathouse. Small Can Be Big works with Boston-area partner charities to help keep local families from slipping into homelessness. Let’s break it down:


A screenshot of the Small Can Be Big homepage, showing the first two sections of the design.

  1. Hero area: the organization wants to be able to put anything they want here. This content and its design are unique to the homepage.
  2. “How it Works”: three quick points about the organization’s process. These are also unique to the homepage.

  3. A screenshot of the Small Can Be Big homepage, showing sections further down the page.

     

  4. “How it Makes a Difference”: A list of brief highlights about the organization’s impact. Blurbs very similar to these live on an “Impact” landing page of the site, and could be pulled in automatically. The content admin, however, needs to be able to wordsmith these blurbs specifically for the homepage, so they are unique.
  5. A newsletter subscribe form: this form may get used elsewhere on the site, so it will be stored in a sitewide-accessible block or a widget and then displayed on the homepage and on other pages as needed.
  6. The latest blog post: This will be automatically populated.
  7. A custom call to action with supporting content, just for the homepage.

So, we’ve got one sitewide, global element here (the subscribe form), and one systematized, auto-populating region (the latest blog post). How do we let this organization custom-craft the other pieces of this page?

One way to approach this is to create this page in a single body field, and give the client a WYSIWYG with which to maintain it. This offers the ultimate flexibility. But as anyone who’s written a goodly amount of HTML knows, giving content admins a big WYSIWYG blob can lead to broken code, elements that aren’t accessible or semantic, failures in the responsiveness of the page, and content that doesn’t fit within the constraints of the design. This can quickly lead to a schlocky-looking (that’s a technical term) homepage.

A better approach is to break the page up into little custom WYSIWYG chunks (blocks, panes, or custom text widgets). You assemble them on the homepage via whatever best methods your CMS offers, and the client maintains each and every little snippet in its own block.

The advantage is that the homepage gets broken down into components, reinforcing—at least somewhat—the separation of the content from its layout and design. For example, the “How it Makes a Difference” chunk might be built as four separate blocks or custom text widgets, floating next to each other:


A close-up screenshot of the Small Can Be Big homepage, showing three icons and blurbs under How It Makes a Difference.

The downside is more complicated management over time: the containers holding these chunks are generic tools, wired together in a front-end display. Each chunk may be maintained at a different URL. Specific help text can be tricky to include. And lots of small bits in the backend can be difficult for content admins to track, especially if there aren’t editorial guidelines and a strong governance plan in place. Eventually, the quality of the homepage, and the site, can start to degrade.

Let’s embrace the exception!

What I’ve been increasingly doing is making a content type that exists for one purpose: to serve as a structured form for homepage content entry and maintenance. This can feel weird from an information architecture perspective. Content types are generally reserved for pieces of content that share common attributes, implying that there is more than one instance of that content. As one of my colleagues said the first time I suggested this: “A whole content type for one piece of content?! That’s not what content types are for!”

But here’s exactly when we need to check back in with the goals of building CMS content structures in the first place: robots are here to serve humans, not the other way around. If this exception is needed, let’s embrace it rather than fight it. A single form to edit all of the custom content on the homepage can make things easier on the content admin, and helps enforce design cohesion and content consistency.

In breaking down the content type for the Small Can Be Big homepage, I looked for logical content and design patterns so I could group fields in a helpful way. For example, the three “How it Works” blurbs are there to inform donors about how their contributions work:


A close-up screenshot of the Small Can Be Big homepage, showing three icons and blurbs under How It Works.

It’s logical for this sort of element to live on a homepage, and it will likely always be needed for this site. So I built it as a list of three items, and called it exactly what it is: How it Works. In the CMS, it looks like this:


A close-up screenshot of the CMS homepage edit form, open to the How It Works tab.

I included help text about what HTML goes into each field, and some sample content. If the homepage changes in the future, these fields can be tweaked, or deleted and replaced with something else. But if the content structure remains the same, the design and/or layout can easily change to restyle this same three-item list. Either way, this setup is flexible.

The homepage edit form is your oyster

How you break down a homepage into a content type is dependent on the kind of content and design you’re working with. In the Small Can Be Big example, I’ve broken the form itself into the different content and design areas of the homepage: the lead feature (hero) section, the impact section, etc. This makes the form a lot less overwhelming to edit.


A screenshot of the CMS homepage edit form, open to the hero edit tab.

The breakdown is also dependent on your client’s staff resources. In my example, the client has a dedicated technical person on staff to edit homepage content. We collaborated with the content admins throughout the development process; we know the homepage content admin knows HTML well, and when we asked him what editing tools he wanted, he requested no WYSIWYG. I wrote help text to remind him of the HTML elements that are allowed and expected in the field (if he tried to put messier HTML in there, it’d get stripped out by the CMS), and provided him with a quick inline example or reminder of the content that should go there.

For a less technically savvy admin, I might make more fields, rather than fewer. Fields could be made to hold icons, images, and alt text. I could put WYSIWYG editors on each of the text fields, customized for the expected markup. Alternatively, I could make every element its own field: image fields with clear, descriptive help text for the icons, and plain text fields for the H3 headers and paragraph blurbs. I would then output those values into customized HTML templates, giving me complete control of the markup around the content.

The homepage edit form is a fantastic opportunity to add helpful UI elements for content administrators. It’s also a very good idea to add a general help text block, like I did in the example, linking off to the site documentation. You could also link here to the site’s style guide, if it has one, or add voice and tone notes.

Of course, how far you can take this is also a function of your project budget and timeline. If possible, it’s wise to build time into ongoing project budgets for regular adjustments to these customizations, to ensure they continue to be helpful for content admins in everyday use. But even adding a little structure and help text can go a long way.

Let the humans win

My job is to map messy human communications onto computer systems to help make it easier for people to manage those communications. That means that I need to balance the boolean realm of computer code with the far more ambiguous needs of organizational communications. By creating a structured exception for the very human homepage, I can better ensure the consistency I crave as a developer while giving content admins the flexibility they need.

Adding more logic and structure to homepage editing has another benefit as well: it encourages people to evaluate the meaning of their homepage content, making them plain old better. Rather than concentrating solely on visual “wow!”, and putting up icons and copy “because it just needs a little something there,” a structured edit form can force people to inventory what’s there, and identify that “little something’s” purpose. This encourages conversation around the role of the homepage, and keeps it from becoming a pretty parking lot subject to the whims of the boardroom.

The homepage exception is just one example of the many kinds of accommodations that human beings need in the coded, structured systems we build for them. It’s our job to adapt computer systems to their needs, not the other way around. If we don’t, then our robot overlords have won. If we expect, plan for, and even celebrate these messy, human exceptions to our logical systems, we get closer to making a web that works for both people and machines.

Understanding the Emotional Response

Posted by The fine folks at A List Apart |16 Jun 15 |

If you work on the web, you’ve likely seen heated emotional outbursts in the office. When someone barks at you because their business process must change or you’ve presented a concept that doesn’t match their mental framework, it’s easy to take their words personally and get agitated. But people have a right to experience emotions. They might not always cope in healthy ways (and you don’t always have to accept the resulting behavior), but it’s part of our job to hear them out.

During my time managing content strategy at a university, I witnessed tears and frustration over font colors, training requirements, form fields, and access levels. It took me years of studying human behavior to realize it was my responsibility to accept the emotions. I could no longer chalk it up to people “not getting the web” or “not seeing the big picture.” Those excuses weren’t getting me anywhere when furious folks showed up in my office unannounced. And those excuses weren’t fair. I needed to be a better partner.

So how do we turn challenging outbursts into productive conversation?

Look for the signs and pick your strategy

Validating emotions isn’t a glorified psychological process. It’s about being a real, authentic human being who empathizes with another’s emotional state. And, guess what, that’s damn hard.

Instead of releasing a defensive remark, refocus and try to understand what’s fueling the outburst. Psychiatrist Dan Siegel believes that by naming our emotions we have a shot at removing ourselves from their grasp. I’m certainly no psychiatrist, but after years of watching humans build web products together, I’ve noticed most people get wound up over four core issues:

  • Security
  • Freedom
  • Identity
  • Worth

If we look for signs that indicate what’s behind fierce comments, we can attempt to defuse and move forward.

Calming insecurity

Working on the web involves a lot of change. We test new technologies, try out different processes, take on diverse clients, and integrate new best practices. It’s easy to feel a few steps behind. Anyone who provides direct support knows what it’s like when people experience something new and unfamiliar.

“I NEED THIS FIXED NOW.”

“I DON’T KNOW WHAT’S GOING ON!”

“I KEEP TRYING THAT AND IT’S NOT WORKING. THIS IS BROKEN.”

Perhaps a CMS user is struggling to make updates. Maybe a sales rep is trying to pull a new analytics report for a client. If not handled well, these emails are followed up by phone calls or drive-by office visits. In my experience, they can even lead to high-level meetings with angry department heads voicing concerns about how the web team doesn’t care.

These hectic reactions often indicate that people feel insecure. They’re a step or two outside their day-to-day domain and they don’t feel confident. Ultimately, they’re experiencing fear of the unknown. And fear releases adrenaline bombs launching us into fight-or-flight mode, which is why we love scaring ourselves and why people get hot and hung-up.

Witnessing this type of response is our cue to scan the context to identify what’s driving the insecurity. Did we move to a new CMS and now a colleague is struggling to relearn their job? Is a marketing specialist preparing quickly for a meeting and they’ve forgotten how to pull the right report? When we read through their emotions, we can identify their basic needs, and then:

Avoid blame. Steer the conversation away from what they’re doing wrong or what they don’t understand. Instead, let them know you’re happy to help and together you can make it happen.

Tailor language to make people feel comfortable. Using insider jargon is the fastest way to make someone outside our field feel even more insecure. Instead, see the conversation as an opportunity to help colleagues or clients boost their confidence.

Give away your knowledge. Beyond simply making a fix or giving a brief explanation, try digging up a few resources to help someone understand your field even better. I worked with a designer who’d respectfully send me links to articles after we worked through heated challenges. Instead of protecting his expert knowledge, he’d direct me right to his source so I could feel more confident in the future.

Addressing the fight for freedom

No one likes being told they can’t do something. But web work, be it enterprise content management, development, or design, involves lots of saying no. Workflows dictate who can and can’t publish pages. Browsers and devices constrain our key strokes. Content templates confine layout flexibility. Like I said, lots of no. And inevitably our saying no is going to stir up opposition.

In enterprise contexts, we sometimes encounter those who push back because they want more personal independence. In my higher ed days, I came across professors and department staff who refused to attend CMS training or neglected our architecture standards. They openly challenged these governance practices because they wanted to manage their sites without conforming to institutional process.

In agency environments, enforcing well-intentioned web standards can make others feel like they’ve failed. When we say no to requests that come from our sales or client reps, their frustration with our restrictions is less about personal freedom and more about wanting to deliver. They don’t want to let the client down so they’ll insist it’s absolutely necessary.

When it comes to freedom issues, we can start by asking questions like:

  • What are you trying to accomplish?
  • How do our restrictions keep you from doing your job?
  • What alternatives do we have?

Then, we need to pop open the hood to show them exactly what we’re up against. If a client rep makes a last-minute request to add a content chunk that will change the functionality of an entire template, we can bring up the CMS, show them how the template works, and outline what their change would entail. Or, if a renegade web editor repeatedly breaks basic usability best practices, we can call a meeting, walk through examples of the user experience we’d like to create (and avoid), and brainstorm other ways to meet their goals.

It’s respectful to offer our full knowledge and shoot for shared understanding instead of hiding behind the technical veil. Also, don’t be afraid to change your mind. If you understand their motivations, logic, and rationale, you might decide to adjust your processes or tactics. That’s okay. You don’t always need to defend your ground as the expert.

Affirming the identity-seeker

Some of the most delicate emotional responses we run into surface when people experience identity issues. A new hire wants to solidify their role. A new team lead wants to redirect the project because of their years of experience. A company goes through rebranding and longtime writers have to find a new voice.

“Well, I’ve used Drupal for over 10 years. I don’t understand why that wasn’t the obvious choice.”

“Of course I know QR codes. I’ve used them. That’s why we need a QR code.”

“That’s something my strategy team does. It’s not your job.”

Working as a contractor and consultant, I prepare myself to hear these types of comments from those trying to reposition when I join a team. I don’t blame them. They simply want to be seen as a valuable contributor. So do I.

Instead of shooting them down by defending my expertise, I reinforce their identity by inviting them to share their knowledge and experience. A helpful phrase is Kristina Halvorson’s “tell me more about that” line:

“We’re glad you’re on this team. We need your expertise. Tell me more about what you know.”

or

“Sounds good. Tell me more about how a QR code will help us drive traffic.”

Affirming others by asking them to share their experience doesn’t mean you need to go along with their ideas. But it helps you calm their defensive posture, not look like an opponent, and move the conversation to productive ground.

Restoring value and worth

Emotions don’t always manifest in loud declarations or snippy emails. Sometimes people just check out. At the university, I noticed a once oppositional stakeholder had grown silent. But just because I no longer heard his clamoring didn’t mean everything was cool. He had disengaged and wasn’t keeping his site up to date, to the detriment of his users. I realized it was our failure because we hadn’t been listening to him.

Withdrawal usually happens when people don’t feel heard, repeatedly. Maybe in a large organization, a department head’s project keeps getting shoved to the end of the queue, so they give up. Or maybe a junior developer feels overshadowed by seniority. They’re not chiming in because they believe it doesn’t matter.

The good news is we can boost worth with seemingly simple things like listening and letting people be themselves. Margaret Wheatley, known for her organic approach to organizational behavior, believes it’s more about being present than formulaic strategies:

We spend so much time in complex group processes focused on team building, problem-solving, effective communications, etc. But what happens when we forget about technique and just try to be present for each other? Have you experienced what happens in you and others when we really listen to each other?

So what’s the takeaway? We need to make an intentional effort to be present and recognize people as we go about our daily bustle. How do we do it?

Invitations. Draw others into your conversations. If a developer seems quiet in a meeting, ask for their opinion (even if it’s not about development). If you’re working on a new approval workflow, grab coffee with one of your more challenging web contributors and ask them how a process change could make their job easier.

Specific praise and appreciation. In their book How the Way We Talk Can Change the Way We Work, researchers Robert Kegan and Lisa Laskow Lahey advise us to put more power in our compliments if we want people to know their worth. Instead of saying:
 
“Thanks, Greg! You’re doing great work.”

Take a few seconds to think about why Greg’s work is great. And then tell him directly:

“Thanks, Greg! I like the way you programmed that content type. It’s smart development. I think it will make maintenance a lot easier for our client. And I appreciated the way you advocated for that in our meeting.”

Access. If you work in large systems, offering a clear, reliable support channel provides all stakeholders with equal access to be heard. Or holding open meetups can give your web colleagues regular face time and an avenue for bringing up concerns.

Ultimately, listening and recognizing others takes time, and in the fast-moving chaos of web development, strategy, or production, we don’t have the cycles to acknowledge someone who’s not asking for our immediate attention. So we need to get intentional about being present.

See the common sense above the struggle

These arguments might seem like common sense. And honestly, they are. It’s easy to step back objectively when we’re not under the gun. But, at our core, we’re not logical beings. We get swept in and stir things up. It’s difficult to stay levelheaded.

So when strong emotional reactions spike, we have to do our best to accept them and not make it personal. Only from a non-defensive stance can we accurately assess what’s triggering the reaction. If we can pinpoint the issue, be it security, freedom, identity, or worth, we have a chance to turn the conversation around. So next time someone barks, temper your hackles, draw a deep breath, and be present.