2. From the Content Out
“I know many, many people who would rather stab themselves in the eye with a pencil than be responsible for a large-scale content inventory. Me, I’m weird. I love ’em.”
—KRISTINA HALVORSON
The first step in the responsive design workflow is to create a content inventory. Even if you’re familiar with content inventories, allow me to explain how I approach the idea of structured content. You’ll probably find that the content inventory I propose differs from what you’re accustomed to.
It’s often said that content is king. I tend to disagree. Designer Paul Rand described design as the “method of putting form and content together.” Rand’s statement confirms my opinion as a designer that content and form can either strengthen or damage one another. That said, structured content can stand on its own. Form (composition, color, imagery, and typography)—and the design that comes from combining it with content—can make information more accessible, understandable, and readable; it can make user interfaces feel easy to use.
Thus, I feel that design—as content and form combined—is king. Structured content is a very high-level official. This structure need not (and should not) be represented in a solely visual manner, but rather via metadata available in the medium in which it’s presented: markup languages such as HTML or structural elements of a word processor, for example.
Structured content is semantic; it’s about what the individual pieces of content are. This is a heading. This is a paragraph. This is a table cell that corresponds to a certain table heading. HTML, while not perfect, is now the primary way we structure our content on the web. We attempt to use the markup language semantically in order to describe what each element is. Where no element is available, we rely on HTML attributes such as class, de facto standards and conventions such as Microformats, or other metadata standards such as RDFa and Microdata.
Microstructure vs. modular structure
For the sake of naming things, let’s say that text-level semantics compose a microstructure, as these tend to be the smallest elements of a web page. We can’t break down text-level semantics much further, provided that structure has been accurately described. There are larger levels of content structuring possible. Let’s take a login form as an example.
The login form in Figure 2.1 is a structural element built from the smaller structural elements grouped within it. Some would call larger grouping elements modules or components. This form component consists of some basic HTML elements:
• A heading
• A label and input field for a username
• A label and input field for a password
• A checkbox for remembering the user’s login data
• A button
• A link for registering and for retrieving a forgotten password
See what we’ve done here? The above list is a very simple content inventory. We’ll come back to this later, but remember this example for when we do.
On a web page or on a screen within a web application, components are often built from smaller components or elements. For the purposes of this book, we’re concerned with the components of a page, rather than the microstructure of HTML building blocks that these components are made of. For example, we’re more interested in the “main navigation” component than the <li> or other elements it’s constructed from. We’re more interested in the login form block than the input fields and buttons. We’re primarily interested in components where elements are combined to work together as a whole (for example, the form elements combine to create a login form).
The lazy person’s content inventory
Jeff Veen has called content inventories “A Mind-Numbingly Detailed Odyssey Through Your Web Site.”1 Content inventories often list existing content. They’re also usually exhaustive. We don’t want that—it’s way too much work. The first step in our responsive design workflow is to inventory only the things that need to be on the page, whether or not they exist yet. And by “inventory,” I mean make a simple list. This version of the content inventory is not meant to replace traditional content inventories. We’re simply borrowing the idea of a content inventory and using it as a starting point for design.
1 Jeffrey Veen, “Doing a Content Inventory (Or, A Mind-Numbingly Detailed Odyssey Through Your Web Site)”. Adaptive Path. http://www.adaptivepath.com/ideas/doing-content-inventory.
Note
When I say “page,” I also mean “screen,” just in case you’re a web application designer or developer who happens to be allergic to the word “page.”
Remember the content inventory of the login form? This type of content inventory is the first step in the responsive design workflow: a simple list of the larger, meaningful components that need to be on the page. Think about the first page you’d normally want to visualize in an image editor like Photoshop. Think about the major content components you’d need on the page. That’s the starting point for your list. Since there’s a good chance you’re not the person who’ll decide which content goes where, it’s a good idea to talk to that person before designing. Even though you’ll just be creating design comps, you can only produce an appropriate design if you consider real content. Some of the necessary content may be listed on a traditional content inventory somewhere. If so, great! Try to use some of that actual content later in the design process.
Our universal example: This book’s website
Throughout this book, we’ll use a relatively simple example project to explain and illustrate each step in the responsive design workflow. The book’s website (www.responsivedesignworkflow.com) contains everything you’ll need for each step, and it’s simple enough that the basic concepts won’t be clouded by the size of the project. But don’t let the simplicity fool you: I’ve used this same workflow successfully on large projects for large organizations. Once you’ve gone through all the steps, you’ll start to see ways to implement the ideas on your own projects, both big and small. I encourage you to either walk through the creation of the book website, or if you prefer, to apply each step to a project of your own.
Every project starts with goals, with reasons to be. The book’s website provides a specific and central place to promote the book, while offering various ways to purchase it. It also serves as a repository for errata and other news regarding availability, translations, and other useful information.
Progressive enhancement as design principle: The zero interface
Before we continue, I want to explain one of my governing design principles: the zero interface. I introduced this principle during a college lecture I gave several years ago and it became so integral to my thinking that I named my consultancy after it.
The zero interface is precisely what it implies: no interface at all. There’s nothing between the user and the information that user wants, or the result the user is trying to achieve. The zero interface lets the user order something from Amazon.com simply by thinking about ordering it. Think, done. I’d like that new book by David Sedaris. Think, done. I’d like everything I need to know about renewing my passport. Think, done.
Of course, this kind of user interface doesn’t exist—yet. But that’s not the point. When we design as if it does exist, it can help us make better choices.
The key thing to remember is this: anything you add to the zero interface is perhaps one step too many. It might exclude certain users or break your application on certain platforms. It might convolute the message or confuse your users. It might distract users from what they’re trying to do.
If you use the zero interface as a design principle, you’ll find yourself asking the same questions every time you’re tempted to add an element to your site or app, whether it’s a drop shadow, an entire section, or new functionality: Who needs this? Why do they need it? Are there more effective alternatives? Does it help reach the goals for this site? Since the ideal of “think, done” is not currently possible, what step or component is absolutely necessary for the user to accomplish her primary task?
Note
Websites are notorious for offering content that users don’t need and lacking content that they do. This discussion is both outside the scope of this book and often not solely the designer’s responsibility. If you want to read more on the subject, check out Indi Young’s great book, Mental Models: Aligning Design Strategy with Human Behavior (Rosenfeld Media, 2008).
For example, web designers often start by developing an idea for a general page layout. Navigation is one of the first things they draw in. But it’s important to think critically: how do you know you need navigation? This is a shady example, since you’ll most often need navigation. Base the choice on need rather than common practice. Take a footer, for instance. Do you really need one for your specific site? Get into the habit of thinking critically and challenging perceptions, even if—especially if—you’re considering an often-used design pattern.
The reality is that as designers and front-end developers we don’t often have the luxury of making these decisions on our own. Many of us are expected to just shut up and do the work we’ve been asked to do. This is unfortunate, but it’s a fact of life we have to deal with. That doesn’t mean you have to execute your work as a mindless drone. Anyone involved in the broader design process, from content strategists to visual designers to front-end developers, can think critically, and come up with more effective solutions to pitch to the decision makers.
Creating the example content inventory
Remember that, for our purposes, a content inventory is just a list. It’s a good idea to number each item on the list, so it’ll be easier to refer to specific items later. Again, we’re looking for essential functionality and content; we’re thinking about content components as opposed to microstructure (HTML elements) or layout areas (header, footer, illustrious “main content,” and “sidebar”).
So what about the book website? In this case, it’ll only be one page. This might change in the future, and if it does, then that will justify design changes as well. Regardless, the process of creating a content inventory remains the same.
Here’s a preliminary list:
1. Title
2. Book synopsis/description
3. Purchase options and available formats
4. Errata
5. Publisher information
The goal is not to create an exhaustive inventory of the site’s content, but simply to enumerate the content of the page you’re going to visualize. You’ll want to do this for each page you mock up. This example is the entire site, so that’s killing two birds with one stone—you get the idea.
Since the inventory is just a list, you can make it in whatever format you prefer: a plain-text file, a spreadsheet, a mind map, or whatever fits your way of working. Then add a little more information about each item, similar to what you might find in a traditional content inventory. Note that in the following example, the descriptions are relevant to this particular website (and thus don’t apply to every book website):
1. Title
The title of the book won’t be a logo, but the book’s cover uses a specific font; the typographical treatment of the title should be consistent with that of the book.
This should include an image of the book and perhaps an image of a spread.
3. Purchase options and available formats
You’ll need to get more information from the publisher about this. For now, you can steal the basic format from other book sites by the same publisher. This will give you something to discuss and refine. (See “Instigating Discussion.”)
4. Errata
Obviously, this will be empty since this book contains no mistakes whatsoever. Well, one can hope, right?
5. Publisher information
This could include contact information, but will it be enough to remain a separate element in this inventory? That’s another one to discuss with the publisher.
Let’s imagine that you discussed our little content inventory with the project editor and he gave you some feedback. First of all, he said it’s quite common to include author information, such as a short bio and a photo. He also agreed with the single-page idea and that the purchase/format options would be the same as the publisher’s other books, except for the price—which you can safely leave as a variable for now. However, he mentioned that since the book will contain code examples and various software is discussed, links to software and any necessary code should be included in the page. Also, it turns out that no extra section is needed for publisher information, since that will be part of the book description section.
This is valuable information, so you’ll need to add it to the content inventory:
1. Title
The title of the book won’t be a logo, but the book’s cover uses a specific font; the typographical treatment of the title should be consistent with that of the book.
2. Book synopsis/description
This should include an image of the book and perhaps an image of a spread. It will also include publisher information, including ISBN numbers, number of pages, and so on.
3. Purchase options and available formats
The book will be available in at least one e-book format and as a printed paperback. Buttons or links will bring the user to the book page on a website (either the publisher’s website or a website like Amazon.com) where the book can be purchased. A sample chapter will be available for download.
4. Resources
This will include categorized—and when necessary, annotated—links to resources named in the book. Links can be to anything from articles to books. Any necessary code will also be available for download; demos will be linked to.
5. Errata
Errata will be published for each reprint or new edition of the book sorted with the newest edition first.
This is detailed enough for right now. While it’s important to design based on real content, it’s important to remember that you’ll be creating a mockup, not a website, so the smallest details can come later. There’s no exact formula for determining what must be included at this stage. Generally, if you find yourself stuck because there are unanswered questions about content, then you need to get answers to those questions. But if you’re obsessing about details that have little or no influence on your overall design, then you could probably prune your content inventory a bit, or put the details in the notes.
In the next chapter, we’ll start creating responsive wireframes with the help of this content inventory.
Try it out
After reading through this chapter, you’re probably seeing some problems with using this approach with your company or team. For example, as a visual designer, you might be handed wireframes from an interaction designer. You’re not expected to think about (or question) content; that’s already been set for you. This essentially demotes you to a color-by-numbers decorator, but what can you do? Well, if you’re open to a new approach, go ahead and try creating a content inventory even if it’s not expected of you. It’s good practice and will help you spot potential holes in the content, which you can then take to your team. Ideally, content strategists, interaction designers, visual designers, and even front-end developers should all be involved in the process of creating this content inventory. If there’s one recurring theme in this book, it’s that we need to stop working in isolation. Websites should not be built as automobiles on an assembly line. We need to accept that our disciplines overlap, and that we should embrace this overlap and work together. Whatever you can do to move your team in that direction will be all to the good.
At the basic level, content inventories are relatively easy to make. The first iteration should be done quickly, similar to a list of ideas in a brainstorming session. With each person thinking critically from his or her own expertise, the first iteration will probably be better than you think. In an ideal world, we’d have content strategists on every design or redesign project, doing the footwork on these inventories and persistently asking questions of clients in order to get the information we need.
Create an inventory only for pages that will be visualized in the form of a mockup. In other words, if you’d normally create a Photoshop comp of it, it’s a candidate for a content inventory.
Note
When I refer to “Photoshop comp,” I mean traditional static comps, regardless of the tool used, including comps made using Illustrator and InDesign.
You can try it out now if you like. If you’re a visual designer, think about any page you might be designing and create a simple content inventory following the process outlined in this chapter.
If you’re a developer and have received a Photoshop comp for a recent project, look at it critically and see if it all makes sense. See if you can reverse engineer a content inventory from what you see. If you’re a designer, see if you can do the same with a wireframe you’ve been given. Try to identify the major content components of the page and analyze where the design or wireframe handles these well and where it doesn’t.
If you’re an interaction designer, you create the content inventory, adding interaction notes to each component, describing possible interactions and any other considerations for the designers and developers.
And leave your intricate wireframes at home, because old-school wireframes are back. And this time, they’re pissed.