EW Resource

Newsfeeds

There's a huge resource of Newsfeeds on the Net which brings up-to-date information and content on a wide range of subjects.

Here are just a few relating to web development.



A List Apart: The Full Feed
  • Container Queries: Once More Unto the Breach 

    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.

    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 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:

    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:

    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.

  • Create a Content Compass 

    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.

  • On Our Radar: Precious Humans 

    Molly Holzschlag is a great educator, tough fighter, and vital friend of what folks are now calling “the open web,” and she needs our help.

    Molly Holzchlag and Jeffrey Zeldman
    Molly Holzchlag and Jeffrey Zeldman.

    She took over as project leader when I left The Web Standards Project in 2002. In that role, Molly did hugely important (and often thanklessly unheralded) work bringing improved compliance, plus a renewed respect for web standards, to some famously intractable browser companies. She also directed The Web Standards Project’s important and multi-dimensional educational outreach effort.

    Between those efforts, her two decades of public speaking, and the dozens of web development books she has written, Molly has contributed meaningfully to the foundational thinking and understanding of tens of thousands of web developers, designers, and engineers. If you don’t know her name and her work, you don’t fully understand this industry.

    Molly has been diagnosed with chronic pancytopenia, a life-threatening blood disorder, and her insurance is about to disappear. She’ll need the support of friends and strangers to afford lifesaving blood treatments and medications. Pray for her, chant for her, help her if you can. —Jeffrey Zeldman, founder and publisher

  • Your weekend reading

    1. I’m a big fan of the Library of Congress Flickr feed (mostly for the old-timey photographs of the type that Shorpy cleans up and posts) and recently they’ve been posting old graphic posters from the collection. Like this poster for a 1938 photography exhibition in New York City. The description for each piece links back to the Library of Congress, where they often have very high-resolution images available to download. —Mike Pick, creative director and designer
    2. This week, Wired talked up new startup Doxa, which aims to use an “OKCupid-like” algorithm to match women with tech companies where they’re likely to thrive. It’s an interesting approach to getting beyond “diversity” percentages, and it’s nice to see Wired lead with the truth: “Tech has a diversity problem.” But I was more convinced by Danilo Campos’s take: that “shoving underrepresented people into the existing startup order”—even using smart algorithms—won’t make those organizations actually ready to support diverse employees. “If you’re serving at a place where no one in leadership understands your needs, getting accommodation for those needs can become challenging—or even alienating, when you’re misunderstood,” he writes. In other words, crunching survey data to help women find a better fit might be nice, but real change happens when leadership teams are as diverse as the people they’re trying to hire. —Sara Wachter-Boettcher, editor-in-chief
    3. Richard Rutter has Kickstarted a book he’s writing on web typography. I remember first reading an article Richard wrote for us on the topic back in 2007, and this book has been in the works since before then. Richard lives and breathes this stuff: he helped set up Fontdeck, and has also run several installations of Ampersand Conference. I have a feeling this book is going to be the canonical reference on web typography for years to come. —Anna Debenham, technical editor
    4. I was doing some reading on SVG this week for a project we’re working on. I came across Jake Giltsoff‘s SVG on the Web, a single-purpose site outlining the use of the SVG format. Giltsoff went into quite a bit of depth, addressing the use of SVG as an image type from a development perspective, and responsive approaches to using the format. It’s a bookmark-worthy resource for in-depth or at-a-glance referencing. —Erin Lynch, production manager
    5. I was privileged to hear Leslie Jensen-Inman speak last week, and she explained how adding a single question to the daily stand-ups at Center Centre has helped the team create an environment that is enthusiastically supportive of ongoing learning. “What is the most important thing I learned since the last time we met and how will what I learned change the way I approach things in the future?” In Leslie’s Meet for Learning, she goes into more detail about the ways this open-ended question has changed their work culture for the better. —Aaron Parkening, project manager

    Overheard in ALA Slack

    “I watched a chipmunk suck water out of my friend’s Camelback at the Grand Canyon.”

    Your Friday gif

    A glitchy image of a screen that says “Learn to Use the Internet, Level 2”
  • Rian van der Merwe on A View from a Different Valley: Unsuck the Enterprise 

    There’s something strangely appealing about trying to make enterprise software not universally despised. I guess I believe in a utopian vision where enterprise software is useful, usable, and (gasp!) enjoyable.

    But until we get there, I think we can all agree that enterprise software mostly still sucks. And I think it sucks mainly for two reasons:

    1. A lack of empathy for end users.
    2. Too much legacy.

    The lack of empathy issue is an understandable outcome of the process. See, we have this piece of software that we sell to company leaders, who care about things like control, configurability, compliance, and how many features the thing has. But the piece of software is mostly used by people who have very different needs.

    The people who use the software every day only care about one thing: getting stuff done effectively. And if they can’t do that, a really ugly death spiral happens. As more people realize they can’t get anything done with the software, fewer people want to use it, until eventually no one uses it anymore.

    In short, a buyer-focused product strategy builds for features and timelines. A user-focused product strategy builds for the Job-to-be-Done. Those are very different things.

    Second, there’s too much legacy that drags large corporations down. There are waterfall processes masquerading as “agile,” well-established and well-defended functional silos, and many layers of bureaucracy. The result is something Jon Kolko sums up well in “Dysfunctional Products Come from Dysfunctional Organizations”:

    The dysfunction in the organization becomes the dysfunction in the product, and that gets passed on to the customers.

    How can we unsuck this predicament? Four things have helped me, and continue to help me as we make this transition toward designing in leaner, more empathetic ways.

    Show the business value of design

    The 2014 Design Value Index report just came out, and it showed something quite compelling about design-led companies:

    The Design Value Index (DVI), a market capitalization-weighted index comprised of design-driven companies, shows … 10-year returns of 219% over that of the … S&P 500 from 2004 - 2014.


    Good Design Drives Shareholder Value

    From “Good Design Drives Shareholder Value” by Jeneanne Rae

    So we know design-led companies make more money. But is it also possible for design to save on development costs?

    This chart is based on data from the book Software Engineering: A Practitioner’s Approach, and it shows how much cheaper it is to make changes to software before or during development. This quote from Marty Cagan also makes the point really well:

    Instead of using one prototyper for a few weeks, [many companies] use the full engineering team for full release cycles to build the software that is then QA’ed and deployed into production systems. This is why it typically takes so many companies three or more releases over one to two years to get something usable and useful. They are using the engineering organization to build a very, very expensive prototype, and they use their live customers as unwitting test subjects.

    This is a way to tie user-centered design to both revenue increase and cost reduction. That’s an essential (and compelling) combination to get people to take design and user empathy seriously.

    Shrink user-centered design to fit

    The biggest reservation that teams at enterprise software companies usually have about research and user experience work is that it takes too long and costs too much. Our job is to show teams that we can still get enormous value from UX methods, even if the budget is relatively small.

    That’s the beauty of user-centered design: it shrinks to fit. Can’t do an ethnographic study? Do some phone interviews. Can’t build out a full HTML prototype? Make a clickable prototype in Axure, or heck, make a paper sketch. Can’t do a full usability study? Go to Starbucks Stumptown¹ and ask someone if you can buy them a coffee in exchange for some feedback:

    Turn sales into a product design function

    This is a big one. I’ve seen enough animosity between sales teams and product teams to last a lifetime. And both sides usually have legitimate points.

    Product teams usually complain that the sales team sells stuff that doesn’t exist in the product—and even worse, promises release dates—which means they have no flexibility to base their roadmaps on user feedback and strategic direction.

    Sales teams usually complain that product teams don’t see them as partners, and ignore their feedback constantly. This is a huge mistake, because sales teams often know the product’s capabilities and shortcomings the best of anyone in the organization. They should absolutely be part of the development process.

    How do you do this? What’s worked for me is to provide a framework that allows both teams to speak a common language. For me, that framework, is Jobs-to-be-Done, and more specifically, the Product Forces Framework.

    Product forces diagram, based on jobstobedone.org

    For someone to move from their existing behavior (a product they’re currently using) to new behavior (switching to a new product), there are two types of forces at work: progress-making forces, and progress-hindering forces.

    Progress-making forces move people from their existing behavior to the new behavior, and consist of the push of the current situation (things they’re not happy with in the current product) and the pull of the new idea (things that sound appealing about the new product).

    Progress-hindering forces hold people back from switching to new behavior. They consist of allegiance to the current behavior (things they really like about the current product) and the anxiety of the new solution (worries about learning curves and not being able to accomplish their goals with the new solution).

    For someone to switch from an existing product to a new product, the progress-making forces have to be stronger than the progress-hindering forces. This might seem obvious, but applying this model to your product planning can inject an extremely healthy dose of reality. Is the product really that much better than a current solution? What does the new product have to do to overcome people’s allegiance to what they’re currently using?

    This is not only a very good sales strategy, it’s also a good way to gather product feedback and come to agreement on what will make the product better (and help it sell better!).

    As for putting a stop to selling features that don’t exist yet… I’ll be honest, that can take some time. But the more the sales team and the product team collaborate (keep reading for more on that) and have a common language, the better this will get as well. There is hope.

    Break down silos through collaboration

    “Collaboration” has become a pretty overused word, and it’s now difficult to know exactly what we mean by it. So let’s be clear: just because you sat in a meeting with a different team doesn’t mean you collaborated. Collaboration, to me, means that you made something together. There is always some output during collaboration—from a solid idea that a designer can go work on, to personas that everyone worked on together, to piles of sticky notes that eventually become a customer journey map.

    This kind of collaboration is especially important in the enterprise, where a designer’s role is often mostly about facilitation.

    There are several techniques to encourage real product collaboration:

    • Product discovery aligns teams on the user needs, business goals, and core competencies of the organization. It then goes through a process of divergent thinking (trying as many options as possible to solve a problem) and convergent thinking (narrowing down to the best options). The process also lets a team build consensus about the most important things to work on. For more, see my A List Apart article “Usable yet Useless: Why Every Business Needs Product Discovery.”
    • Design studio gives teams an opportunity to try a wide variety of design options, and come to an agreement on the best solution to go with. It uses the entire team to iterate quickly to a hypothesis that can be prototyped and tested with users. For more on how to run a design studio, see Design Studio Workshop: Adding Up the Benefits.
    • User research might seem like a solitary sport, but it’s not. Taking team members along on field visits and usability testing gives them a real sense of how users interact with the product. It also has the power to make them depressed about how difficult something is to use. But most people break through that really quickly, and move on to solving the problem effectively.

    If I can further summarize a way to bring empathy-driven design to an enterprise, here are the methods that I try to communicate to teams I work with:

    1. Show them why it’s important.
    2. Show them it’s not going to make their lives difficult.
    3. Give them a framework that covers the whole product.
    4. Make them part of the process.

    So if you’re someone who works in enterprise software, come a bit closer—I need to tell you something…

    I know the work can be difficult. I know there are an infinite number of factors involved in getting product live, and sometimes what gets launched isn’t what you had in mind. I know there are sleepless nights about this sometimes. But don’t give up. Don’t think that enterprise design has to be boring or tasteless. With a little bit of effort and a lot of tenacity, it’s possible to create great enterprise product. We need you to make it happen, though. Who else is going to do it?

    Footnotes

    • 1. Gotta represent Portland!
  • This week's sponsor: Squarespace 

    Websites for designers, by designers. Our sponsor Squarespace is offering readers 10% off with code ALISTAPART.

  • Matt Griffin on How We Work: The Art of Creating Accurate Estimates 

    The estimates. Good gravy, people, the estimates. Is there anything more terrifying in this business than when you have to go on record saying how long it’s going to take to do a thing that (frequently) you’ve never done before? Estimates, after all, are the logical result of a series of questions that raise more questions. “How much will this cost?” leads to “What is it we’re doing?” which is followed by “How long will it take?”

    And no matter how risky it may seem to come up with answers to this last question, it’s an expected part of the client services business. How else would our prospective clients know what they’re going to have to pay us? Without this knowledge, they’d likely never take the leap and agree to become actual clients. (Which, as you may know, is kind of important to this whole thing we do.)

    Likewise, without good estimates, we can’t schedule our time. We wouldn’t know when projects end and when new ones can begin. Kind of crucial, right?

    So why does estimating incite such raging fear in our hearts?

    The problem of accuracy

    Quick show of hands: who thinks they’re really good at creating consistently accurate estimates? Yep, that’s what I thought.

    The quality of an estimate stems primarily from how closely it represents reality. There are several challenges to creating accurate estimates.

    My experience is that most estimates (particularly those that are written with less experience to back up their assumptions) come from a place of optimism. We imagine doing a series of tasks in the best possible circumstances. We ignore unknowns, and all the resultant extra work that may arise from them.

    Sadly, this is rarely representative of the world we live in, and leads to underestimating.

    On the other hand, perhaps we’ve had a very difficult experience with a similar task. Perhaps it was due to circumstances that, though they were truly miserable, are unlikely to be repeated. In that case, our historical anxiety comes rushing to the fore and unrealistically colors our expectations, causing us to estimate far too high.

    Or—as is often the case with unique and complex problems—if we have very little experience to draw on, we may simply take a shot in the dark. Have we estimated too high? Too low? Who could possibly know?

    There are, thank goodness, a few things we can do to alleviate these problems. So let’s look at two possible ways to go about it, which I’ll refer to as “scope to time” and “time to scope.”

    Scope to time

    The scope to time conversion is a pretty standard, traditional estimating exercise. Given some fixed scope of features and deliverables, how long will it take to perform each task? For websites, we try to understand scope-defining things like:

    • How many templates are we designing?
    • How many rounds of design revisions?
    • What are the development features (e.g. is there a newsletter sign-up, a t-shirt purchasing system, integration with a fulfillment house API, etc.)?
    • What are the limits of browser testing (e.g. IE6, IE7, IE8)?

    Once we think we understand all the things we’ll have to do, we try to make up numbers that represent how long it will take to do each thing. But before making a calculation (or guess), we must first think about what kind of timescale we want to work with.

    That timescale tho

    Timescales are lenses through which we can look at a task. I’ve found that which lens we choose can have a profound effect on our estimations.

    Consider a task such as creating an element collage for a new client. We could potentially estimate time in terms of minutes, hours, days, weeks, months, or even years. Let’s take the extremes first. How many minutes does it take? I don’t know. Lots. How many years? I don’t know. Some small fraction, I guess. OK, how many hours? 10? 15 maybe? 8? Those all sound kind of right. Days? Well, 2 to 3 sounds good.

    But 2 to 3 days at 6 hours each is 12 to 18 hours. Which is higher than 10 to 15. So which is right? My hunch is that when we think about an hour, we’re not looking at the right scale. Because the difference between a good hour and a bad hour can be wildly different. I’ve had an hour where I’ve accomplished almost nothing tangible. I tried things that failed; I got stumped on some problem to which an answer revealed itself only later; I was maybe just in a bad mental space at that time. I’ve had other hours where I’ve had great insights, closed ticket after ticket, made a huge dent in a project. The thing is that every day is made up of some of both of these hours. So when I think about what I can get done in a certain timescale, I remember that a day or a week is made of good and bad hours, and what that averages out to. What can I do in an hour? Somewhere between very little and a lot. In a day? A reasonable chunk of a thing.

    On the other hand, at very large timescales—say months or years—my brain starts telling me that the chunk of time is approaching infinity. What can I do in a year? Everything! Which of course is not true, and is in fact a very dangerous assumption to make. Even very big numbers have an end. And to find those ends, we need to ratchet down our timescale.

    This is why, in general, I find the middle timescales (days and weeks) the best for conceptualizing how much we can get done. Questions like “How many days will it take to build out a feature?” or “How many wireframes can I complete in a week?” tend to get me on the right path.

    In addition to that, experience can help a lot. The more work we complete in our careers, the more data we potentially have to check our assumptions.

    Condemned to repeat it

    So we think it takes two to three days to make an element collage. Great! But is this our first time at the rodeo? If we’ve done element collages before, and—here’s the kicker—if we’ve accurately tracked our time in the past, we can compare this estimate to our record of the actual hours we spent the last time.

    This is why I encourage a policy of tracking time spent on tasks. You can make a habit of running a timer (at Bearded, we use Harvest, but there are others, such as Freshbooks and TimeTracker), and switching that timer with every task switch. The motto is ABT—Always Be Tracking.

    Now if we think our mental model of how long it takes to do a thing is way off, we can confirm our hunch by looking at historical numbers, and correct that mental model for the future. It can keep us from under- or overestimating the same thing over and over again. Which is nice.

    Delta delta delta

    Another way to check our assumptions, especially in larger groups, is to compare independent estimates done by multiple people. Seth Brown, COO of Lullabot, explains how he employs this approach:

    Typically we try to work either on a retainer or an hourly basis, however clients often need to have an understanding of what the retainer length might end up being. We tend to decompose projects into bite-sized chunks, first epics, and then tasks, and then estimate those with a group of developers on our team. Each developer does a blind estimate for each task and then we compare everyone’s guesstimates. If the “delta” between each developer’s guess is large we discuss assumptions, ask questions if we have to, and then re-estimate.

    This approach can certainly minimize risk. If two independent people think a task is easy or hard, it’s more likely to be the truth. And if they disagree, then a deeper discussion will likely lead to a better definition of scope.

    Things fitting into things

    Some tasks scale up or down with the scale of the project. Project management and meetings are perfect examples. For instance, when we estimate an hourly project at Bearded, we like to add 15 percent for project management to the grand total estimate. That way, more project scope results in more hours to manage that scope. Seems reasonable, man.

    Time to scope

    Defining scope and converting that to an amount of time is one way to do things. But you can also go the other way, and there are some very good reasons you might want do that.

    Constraints are your friend

    When was the last time a client showed up on your doorstep with infinite weeks and infinite budget to complete a project? Usually at least one of these constraints is in place. Great! So if they only have eight weeks before some event requires the delivery of some solution, then that’s what you have to work with. You know how many people-hours you can devote in those eight weeks, and that time constraint determines the maximum effort and cost. The next question is: What’s the most valuable way for everyone to spend their time during that timeframe?

    Likewise if they have a budget of $100,000, just divide that by the team’s weekly rate and you know the maximum number of weeks they can afford. Then it’s time to answer that same question: How can we best spend our time to maximize value for that client?

    Talk it through

    Not surprisingly, this often becomes a conversation. Though sometimes a client is reluctant to divulge their budget (often out of the belief that a vendor is just trying to get the biggest number possible out of them), I find that telling them our weekly rate up front engenders some initial trust. At that point the mechanics of our cost are exposed, and we’re simply trying to figure out—together—how many weeks of our time they feel comfortable paying for.

    It’s all about trust

    In these scenarios, the scope and work products tend to be more open-ended. We’ll have a prioritized list of things to work on, and we’ll work our way down it—with the understanding that the list may change as we gain more knowledge and new facts present themselves throughout the project. Again, we’re always focused on maximizing our value to the client, so if something more important has appeared, we won’t just keep plugging away at a task because that’s what the contract has bound us to.

    This approach tends to bring us closer to an agile process, where our ship date is fixed, but the work product and deliverables are variable. This approach requires a certain amount of trust and empathy on both sides. Everyone needs to understand that none of us can guarantee exactly what’s going to be delivered at the end of the engagement. It may be scary, but this uncertainty is tempered by a different kind of increased control on the client side: they can continue to reprioritize and redirect us throughout the project, without negotiating change orders.

    That isn’t to say we rush into these projects with no plan. Far from it. But we admit that our plans are imperfect and subject to change. Frequently we begin these projects with a research phase to define the rest of the project (or perhaps to define a second phase).

    The big question in this kind of arrangement, then, isn’t “Will we ship that thing on time?” Rather, it’s “Is the work we’re doing worth more than the money our client is spending on us?” If the answer is yes, then the value is clear, and the details about the exact work product or deliverables become less important. If the answer is no, then it’s likely a bad match and you should shift your focus, or they should look for another vendor.

    Easing the pain

    It’s not just in estimating scope that we encounter trouble. As Woody Allen famously said, “If you want to make God laugh, tell him about your plans.” No matter how we go about making estimates of things, it’s rarely foolproof.

    So what else can we do to ease the pain of estimating?

    Plan for the fan to be hit

    For one thing, we can plan for what to do when things go worse than we imagined. In my experience, people who build things (web things included) are often optimists. Why else would we agree to dive into the unknown again and again with each project?

    Paul Ford’s epic article for Bloomberg, “What Is Code,” sums up the problem of estimation optimism fairly well:

    You ask the universal framing question: “Did you cost these options?”

    He gives you a number and a date. You know in your soul that the number is half of what it should be and that the project will go a year over schedule.

    Clearly, we must plan for when things go less than ideally.

    In hourly projects, we borrowed an idea from our friends at Sparkbox and include a 20 percent contingency budget on every project. The contingency budget is a line item like everything else, but we never track time against it. It just balances out against overages from other line items. It covers our butts when things take longer than expected.

    Likewise on weekly projects, it often makes sense to not densely pack every week of the schedule. Having a penultimate week on the project that’s focused on things like “polish” or “fit and finish” can keep you out of trouble when something goes awry. And if everything goes smoothly, great! When could you not use an extra week to tighten the screws, refine UIs and interactions, test on a few more devices, or create documentation for the client team and—heck—your future self?

    Reaching across the aisle

    Something that makes almost any project better—regardless of process or format—is good, open client communication. Why not extend this approach to the estimating process?

    Says Ben Callahan, president of Sparkbox:

    Lately we’ve been experimenting with an idea called “Collaborative Pricing.” It typically starts with an email from a potential customer where they’re answering a few key questions about budget, timeline, and scope. Our next step is to clarify any major questions we have based on the information we’ve been given. Then we’ll quickly put together a Google Spreadsheet that breaks down the work in a way we believe is reasonable given our current understanding… The idea is that we can work with our clients to find a budget, scope, and timeline that is mutually beneficial. We use Google Spreadsheets because it allows real-time collaboration but is also intuitive for anyone familiar with Excel or Numbers. The most helpful part of estimating in this way is that it makes the very first interaction we have with our customer one of collaboration.

    Sounds pretty great, right? It encourages our clients to start prioritizing their resources (us) from the beginning. Do they want to pour extra hours into one feature instead of another? Do they want to cut something that doesn’t seem worth it, so they can add more budget to another area? Can they take a section or set of tasks off our plate (for instance, usability testing recruiting or QA) because they can assign internal resources to cover it?

    Exposing the machinery of an estimate helps to demystify the process. It sets up a more collaborative relationship from the beginning, discourages adversarial behavior, and builds trust. These, my friends, are things of which a good client relationship is made.

    Yeah great but how much does it cost?

    Just as there is no single good way to set pricing, there is no single good way to estimate. You’ll need to do some trial and error to see what works for you, your communication style, your design and development process, and your clients.

    The web is always changing and so, it seems, is everything else in our industry. So don’t be afraid to experiment and try new things. If all goes well, you’ll have plenty of opportunities to try again, and refine your estimating process with each project. You may also find that as your organization grows, what worked before no longer does, and that a new approach is suddenly more suited to you.

    And oh hey, I’ll be damned if that doesn’t segue us quite neatly into the final installment in this series, where we’ll investigate how scale affects our web businesses. See you then!

  • This week's sponsor: O’Reilly 

    Internet of things + design + business. Sound interesting? Head to SF for Solid Conference, June 23-25, brought to you by this week’s ALA sponsor, O’Reilly​.

  • The Homepage Exception 

    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:

    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.  

    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:

    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:

    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:

    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.


    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 

    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.

  • This week's sponsor: Hack Reactor 

    Time to learn JavaScript? This week’s sponsor, Hack Reactor, offers a 12-week, immersive coding program. Check ’em out!

  • Learning New Tricks 

    At the beginning of this year, I switched my full-time focus in a pretty sizable way. I jumped from an environment where I had at least a bit of expertise and its associated advantages, into one where I had little to no foothold.

    Switching roles usually means adjusting to a new environment, new coworkers, and new problems to solve—things you might work through in a matter of weeks. But there I was, two, then three months in, and still feeling unadjusted.

    What I hadn’t realized was that jumping into a completely different side of the industry is disorienting. The new environment was similar enough to the old one that it still triggered my muscle memory, which was largely irrelevant for new tasks. There were only a few skills I could rely on during the transition—the basic workflow, programming principles, and methods of collaboration and feedback were all the same, but that didn’t always help with things like deploying applications to devices natively, or making decisions about how best to implement a platform-specific SDK.

    One of the biggest advantages of having expertise is understanding and implementing best practices, but they were often the biggest hindrance in learning something new. Applying best practices to a new area of focus from a related-yet-foreign area of expertise was destructive.

    This was most noticeable in the software architecture decisions I faced. Coming from the world of programming on the web, both server and client side, my mind defaulted to certain patterns of communication between pieces of an application—specifically notifications and callbacks. When sketching out a plan for a feature build, I would sometimes forget about the delegate pattern, which is a pretty heavily-relied upon pattern in Cocoa. In a lot of cases, that was the best fit for the feature in front of me, but my mind was trained otherwise.

    The other reason knowing best practices was destructive when learning something new: I was constantly focused on making sure what I built adhered to those patterns. That forced me to focus on optimizing a system before I’d even built or understood it. I was prematurely applying structure to something that I wasn’t quite sure even worked yet.

    I had to get back into beginner mode: make whatever it was I was building actually work, before deliberating on how it should be built. It sounds like an obvious thing, but it takes concentration to restrain yourself like that. The sad irony here is that I should’ve known this from the start. A few months ago I wrote about relying on intelligence rather than knowledge, and that’s how we should operate when learning new skills.

  • Antoine Lefeuvre on The Web, Worldwide: Designing for Post-Connected Users — Part 2, the Recommendations 

    In my last column, I explained what I see as the advent of the post-connected user. Neither hyper- nor dis-connected, they are looking for a more balanced relationship with the tools they use on the internet. It’s our responsibility as web makers to design services and interactions in response to these aspirations. It’s a big opportunity, too. Part two is therefore dedicated to what you can do—or at least what you can experiment with.

    Through the eyes of post-connected users

    When I was teaching UX, I found one key design principle influenced my students most: evaluate your design through the eyes of others. The gap between intended and real usage can be striking indeed.

    Try getting back to an application after a week or two of inactivity. If you recently returned from vacation, you already know the result: a massive user pain.

    I tried it, and it felt like all the applications and websites were yelling at me: You’re late! You’ve missed out on so much! Piles of notifications and unread messages pointed an accusatory finger at me: you shouldn’t have disconnected, you shall now suffer to get caught up.

    This is exactly what post-connected users hate. They feel—and rightfully so—that hyper-connection is forced upon them. They’re looking for applications that adapt to their tempo, not the reverse. Personal productivity and well-being books, such as the bestselling 4-Hour Workweek by Tim Ferris, recommend taking deep work periods which, just like deep sleep, are uninterrupted by external stimuli. If you try this healthy work habit, don’t expect much help from your mailer or team communication tool though. They hold to the dogma of synchronicity.

    Synchronous vs asynchronous

    Is synchronicity always a good thing? Given the huge success of chat applications, be it WhatsApp with friends or Slack at work, it seems the answer is yes. Yet synchronicity can create the online equivalent of walking into a colleague’s office to ask her a quick question. Sure it works—you get an immediate answer—but it has a disastrous side effect: the group’s rhythm becomes the only rhythm. Many individuals feel powerless to prevent interruptions so they need software to help them make work happen at work.

    Not all timely interactions are real-time. I’d argue that most are not.
    Jack Cheng, “The Slow Web

    Real-time is a designer’s magic wand. No need to face complex design issues, real-time solves it all, plus—icing on the cake—it sounds like a cool, modern solution. On the other hand, timeliness, as Cheng puts it, is much harder to achieve. Instead of delivering messages as they arrive to all users, each user’s behavior and preferences must be taken into account. For some, Twitter is at its best when it offers a short selection of personally curated tweets through the weekly email digest or the Highlights app.

    A great example of timeliness is Watchup’s daily newcast: just pick your preferred time of the day, Watchup composes a fixed-duration video digest and learns from your behavior to fine tune your experience.

    Watchup’s daily newscast.

    To design an asynchronous yet efficient tool like this, machine learning comes as a great aid indeed. I would even say that machine learning is a post-connected user’s best friend. Intelligently automated processes can be left to work in the background, helping post-connected users to fight the glut of information (let’s call it infobesity).

    The designer’s dilemma

    While some in the industry pushed the boundaries of how to build, a new younger group of professionals began to question why we build and who to build for.
    Cameron Sinclair, The Architect’s Dilemma

    Have we in the web industry focused too much on how to build? We get excited by new devices, better browsers, or the latest coding technique. We want to try them out, so we prefer to build something new, from scratch.

    And so do architects. In my hometown of Lyon, a major urban renewal program is in progress. Search for “Lyon Confluence” in Google Images or Flickr and you’ll see pictures of brand new, futuristic buildings. The program also includes the eco-friendly renovation of early 20th-century blocks of flats, but everybody associates La Confluence with these eye-catching bright orange and green new constructions.

    Web designers don’t renovate. We move on to the next new thing. But if we begin to question why we build and who we build for, we’ll realize we’re leaving behind many unsolved user problems and many users who don’t participate in a cycle of continuous adaptation to new tools.

    Actually, things are changing. Some start-ups have started to renovate old communications real estate, like email or even SMS. Not because it’s sexy (email isn’t, unless you like HTML 1.0), but because there are so many problems to solve: infobesity, lack of actionability, or poor interactions like `no-reply`.

    Renovated email by my start-up, Clubble.

    This is what post-connected users are after: less embellishment, more solutions to existing problems.

    Hasten slowly

    Hasten slowly, and without losing heart, put your work twenty times upon the anvil.

    Nicolas Boileau, 17th-century French poet

    Looking forward shouldn’t stop us from looking back. This is a solid UX principle after all: release, evaluate, rework. The industry will continue to invent new ways to make the web, much to our delight, but there will always be work for the web renovators as well. While people may be getting more reluctant to spend time or money on software as such, they are coming to see the value of a less noisy, more balanced working life. A growing public of post-connected users is waiting for you.

  • Content Modeling Phases 

    Most of my projects involve building content models, and I have a deep and abiding love for the process. I like teasing out the patterns and relationships in a big mess of content, then creating a structure that marries development, design, and business needs. I find it very satisfying, like putting together perfect rows in Tetris.

    I’ve worked on plenty of projects that have issues that warrant the creation of a content model: a client wants more efficient governance workflows, or to reuse pieces of content across channels, or they’re building a responsive site and need a cleaner separation of content and display code. They’ve learned, or been told, that the answer to the mess they’re in lies in a content model. The problem is that a content model isn’t actually an end game. It’s not a solution unto itself.

    A content model is an organizational tool. Expecting it to solve problems merely by existing is a bit like setting up a new filing cabinet in your office and being surprised when you come back a week later to a desk still covered in piles of receipts.

    My projects run more smoothly when my stakeholders understand the bigger picture of what’s involved in converting to a new content model, and I’ve started to talk about content modeling as having four phases:

    1. Auditing existing content and building the initial models

    This is what most of us picture when we think of content modeling. A structural audit is how I learn the shapes and patterns in the content, and I translate that understanding into diagrams and spreadsheets detailing content sections, fields, and relationships.

    2. Stress-testing the models

    I do two kinds of stress-testing, and both are kind of tedious and extremely important. The first kind involves literally sitting around a table with subject matter experts—representing the needs of the content, business, development, and design teams—and walking through each model. Field by field, section by section, we discuss issues and adjust the model to better meet everyone’s needs. It’s a little arduous, and absolutely necessary. Bring snacks.

    The second kind of stress-testing is a sample migration of roughly 10 percent of existing content to fit in the new models. The models are built based on a representative subset of real content, but a broader migration pilot project always reveals new issues that need to be addressed. A pilot migration also gives us solid statistics we can use to estimate time and energy needs for the full migration.

    In a recent project, we had assumed we’d be able to glean the content of a teaser field from the current site, but through the migration test we recognized the need for a copywriter to rewrite most of that information. That same migration pilot also helped us identify which sections could be migrated quickly by any team member, and which sections needed slow, careful attention from a subject matter expert.

    I think it’s important that this migration pilot is conducted by the team who will be creating and editing content moving forward. This gives them a head start in building their own intrinsic understanding of the content structure, and their insights about places the structure is falling short or is overbuilt are invaluable.

    3. CMS implementation

    I generally build CMS-agnostic models, meaning that I create fields and relationships in service of the content, without regard to how difficult those choices will be to implement in any particular CMS. Bully for me, but once a CMS is chosen, we’re all boarding the express train to Compromise City. During this phase I work closely with developers to make adjustments so the models can still do their jobs within the confines of the CMS’s capabilities.

    This phase also involves building customized help and content guidelines directly into the CMS interface, because that is my jam.

    4. Getting the content into the CMS

    This is the dirty secret of content modeling: someone actually has to move all the content from those dusty receipt piles into its new tidy home in the filing system. There are some nifty advances being made around extracting data using algorithms, but for now this work needs to be done by people. Given my druthers, I like to have the team move existing content directly into the models in the new CMS, which familiarizes the team with the new interface and helps us find places we could improve the authoring experience on their behalf.

    Having the team move old content directly into the new CMS is not always a realistic plan, because of scheduling and timing, and other complexities. So often we do half-measures, having the team move content into spreadsheets and then auto-importing those to the CMS, or hiring interns to do the bulk of the migration labor. This phase can take a long time, but content migration is a really great way for everyone to get familiar with the CMS administration and workflows long before launch.

    5. Shampoo, rinse, repeat

    I lied. I said “four phases,” but after those four are complete, the final, endless phase is maintenance, iteration, and improvement. In the same way we promote doing regular content, performance, and code audits, we should also work with our teams to do regular content model audits, reviewing the fields and relationships to make sure they’re still aligned with design, development, and business needs.

    I would love to be able to sketch out a content model, quietly close my laptop, and come back the next morning to find all the content humming along in a new and beautifully flexible CMS implementation. For the record, I would also like a mini-donk. Even without magical content gnomes (or tiny equines), recognizing the distinct phases of modeling work has helped my projects run more smoothly. I’m better at getting the right people at the table for the right discussions, and budgeting appropriate energy and time across the entire project. Talking about the phases also helps my stakeholders understand the larger picture of a long-haul content modeling initiative, and helps all of us make decisions that move us closer to meeting our business and content goals.

  • On Our Radar: We Need To Talk 

    Coax—Rachel and Travis Gertz’s digital magazine for people who run projects—will not stand idly by. It hits you with bold and brash graphics, late-night no-holds-barred conversations, and frank perspective from project managers, designers, developers, and artists out there in the trenches. It’s personal.

    A screenshot from Coax that says, “Time to spill your guts.”

    Check it out—the articles are infused with character and solid, professional statements about life in the creative and digital fields. —Mica McPheeters, submissions and events manager

    Your weekend reading

    1. “Don’t hire a junior developer if you don’t plan on investing in their future.” In “The Catch-22 of Being ‘Too Junior’,” Jennifer Wong offers straightforward advice on what to do (and what not to do) when hiring a junior developer. I thought this article was a great companion to Lyza’s recent column on practicing mentorship. —Yesenia Perez-Cruz, acquisitions scout
    2. If you would like to learn what it takes to never compromise, Richard Stallman’s computing habits are an excellent place to start. My favorite part: he browses the web by emailing requests to a program that visits the URL, scrapes the page, then mails the results back. If you’re lucky, he’ll open up your pages in a graphical browser like Konqueror, but he prefers to use Lynx. —Tim Murtaugh, technical director
    3. Design is all too often an afterthought when it comes to health technologies and systems. This week, I’ve been following a discussion on GHDonline about why that’s the case—both here in the US and around the world—and what exactly we can do about it. The discussion’s wrapping up, but give it a read and chime in this weekend if you’re interested in healthcare or implementing technology systems in low-resource and low-bandwidth settings. (Full disclosure: I spend my days managing the communities over on GHDonline, so I am a bit biased here, but I think you’ll find it’s been an interesting conversation.) —Marie Connelly, blog editor
    4. At TYPO Berlin last week, Typotheque’s Peter Bil’ak unveiled a new model for testing and licensing fonts. Developed over a couple of years by a handful of independent designers and programmers, Fontstand addresses the abiding tension between technology (type) and the legality (licensing) of that technology. Make some time for this talk—Fontstand is a pretty big deal. —Caren Litherland, editor
    5. File under kicking-myself-for-missing-it: a huge Twitter chat around #WOCinTech, where women of color in (and entering) the tech industry traded answers to questions like “What was something you learned about searching for a job in tech that no one told you?” and “What technologies or software products are you playing with?” Luckily for those of us who tuned in too late, Stephanie Morillo Storified the whole thing. Read through the responses and find new folks to follow. —Lisa Maria Martin, issues editor

    Overheard in ALA Slack

    “Why is it in code tags?”

    “Snarkup language.”

    Your Friday gif

    Where must we go, we who wander this wasteland, in search of our better selves?
  • Ask Dr. Web with Jeffrey Zeldman: No Good Can Come of Bad Code 

    In our last installment, we talked about how to build a great portfolio no matter what goes on at your job. This time out, we’ll discuss what to do when your boss is satisfied with third-party code that would make Stalin yak.

    My team builds stuff for other companies. We handle the server side and outsource the client side to a company that does a pretty ugly job, code-wise (although the look and feel is good). My team doesn’t seem to care what this means for development. For them, it’s a question of price: the product we provide is working, and the customer has no complaints. I don’t have any idea how to make them see my point of view. What can I do?
    Stuck in the 20th Century


    Dear Stuck:

    Oh boy, and I mean this literally, do I feel your pain. It’s the same pain I felt personally, on every single project, from 1997 until web standards finally went mainstream sometime in the mid-2010s. And even then, I would still feel it from time to time: such as this one time when a client who shall remain nameless insisted on using a third-party CMS that shall also remain nameless.

    The CMS makers assured us that they understood semantic markup and progressive enhancement, and that their product would deliver our painstakingly wrought and torture-tested templates intact. But in fact, the CMS delivered our templates in JavaScript. Web pages wouldn’t load without it. The fact that we’d built a progressively enhanced experience that could run on anything from the latest browser to a smartphone, with or without JavaScript, didn’t matter. You had to have JavaScript running to see this site that didn’t require JavaScript to run.

    Logic like that makes me wish I had a nice job in the sewers instead of in web design and development.

    I feel your pain every time I encounter a shop or company that brags about its full-stack expertise but writes markup like it’s 1999. Or, just as bad, like it’s 2003: all meaningless spans and divs, half of them there purely as visual hooks, and the other half there because the developers didn’t know what to cut out of the framework they used (and didn’t consider that a problem, figuring that gzipping everything would take care of the performance aspects).

    I feel your pain today worse than ever, as three quarters of our industry gets high on these bloated frameworks, and abandons core principles like progressive enhancement and building lean.

    It’s particularly troubling when the code schools turning out tomorrow’s coders by the tens of thousands neglect to teach their students the vital importance of separating structure from appearance and behavior; the overwhelming urgency of marking up content semantically so that it is accessible to any person, of any ability, using any device; the genius (and long-term viability) of designing with progressive enhancement instead of targeting specific devices as manufacturers spawn ever more of them; and other fundamental tenets of an open web designed and built with standards.

    It also kills me when these schools teach responsive design as a bloated, top-down enterprise rather than the lean, content-first experience its creator intended.

    I’ve seen agencies where an HR person who doesn’t understand the web hires designers and developers based on the candidates’ meeting a checklist of skill areas. The more tools and software the candidate knows, the likelier they are to get hired. Understanding of accessible, standards-based design doesn’t even enter the picture.

    And then there are places that exist by coding faster and cheaper. The clients of those companies want “something that works.” They need it yesterday and they don’t want to pay what it’s worth.

    Above all, the kind of “pretty design but bad code” you’re stuck with, dear Stuck, comes from stone age companies that heavily silo their employees. In such places, the developer’s job is to comply with a list of specifications as quickly and cheaply as possible. The designer’s job is to make it pretty. If there is a user experience person, her job is to create wireframes in isolation, and slip them under the designer’s door.

    More than a decade after we won the battle for web standards, too much code is still crap. So what do you do, if your company is satisfied with this crap?

    Ethan Marcotte and I dedicated 432 pages to providing rationales why accessible, semantically structured sites designed and built with web standards are the only kind of sites it makes business sense to create. I can’t summarize those 432 pages here, but they are available online and in almost every library in the world, and I humbly commend them to you.

    Mr. Marcotte then went on to create responsive web design, which takes these ideas to the next level. The whole world has embraced it, as you know, and there are now hundreds of places to read about it, including many in this magazine (where Ethan premiered it exactly five years ago on May 25).

    The future-friendly folks have a wide range of recommendations for the even wider range of devices serving today’s web—from watches to phones to desktop browsers to game consoles. “We want to make things that are future friendly,” they say. So does your company, surely. “By anticipating what’s next, we can react to today’s concerns but also build long-term value for people and businesses,” say the future-friendly folks, linking to articles and ideas you can bring to your boss.

    Remember: the future will come whether you design for it or not. If your company charges $300,000 for a website that won’t work on next week’s most popular device, your company won’t be able to stay competitive in this business. It might not even be able to stay in the business, period. After all, clients who pay for sites that break too soon will look elsewhere next time—leaving your company perpetually hunting for new clients in a downward spiral of narrowing margins and diminishing expectations.

    Your company’s survival is tied to the ability of the products it makes to work in situations you haven’t imagined, and on devices that don’t yet exist. This has always been the challenge of web design. It’s one A List Apart has taken seriously since we began publishing, and our archives are filled with advice and ideas you can boil down and present to your bosses.

    If none of this changes their minds (deep breath! ready?) you need a new job. Because the one you have now won’t last. And because the next one will be far more fulfilling—for you, for your company’s customers, and mainly for the people who use their sites and applications. And isn’t that what this is all about?

  • Resetting Agency Culture 

    The internet is full of stories of “dream” agency environments: Google’s “sleep pods,” Yelp’s KegMate, this place’s air hockey table, that joint’s Zen rock garden. They read well in viral articles intended to induce cognitive salivation—the 3 p.m. cubicle fatigue equivalent of a SkyMall Bigfoot Garden Yeti statue while flying coach.

    But the truth is this: there’s so much more to fostering investment and growth in our team members than gimmicky perks. A true dream office, then, is one that invests deeply in the success of its employees.

    While “investment” is often contextualized via finance-centric terminology, the way it anchors a healthy agency culture cannot be trivialized. Agency culture is the result of many factors and influences, but a healthy environment is one that encourages team members to speak up; that fosters inspiration through collective brainstorming and problem-solving; that doesn’t micro-analyze the way time is spent; and that enables employees to listen to and learn from one another.

    Sadly, many agencies support a model that’s more about draining workers of every available bit of brainpower. A team member is hired to work and contribute, clearly, but not at the expense of being devalued or dehumanized. Employees are not the equivalent of a dust-bunny-gobbling Roomba, careening from point A to point B with little to no direction. Thoughtful changes in approach—from the way people are brought into the team, to the approach to creativity and communication, to the support for professional development—can make a big difference in employees’ happiness and dedication.

    The new Day One

    With new hires, many agencies operate under the “jump right into it” methodology; I’m sure most of us have experienced this at some point in our own careers. On Monday, we commute into the new office, are greeted by a terse “Welcome” and a handshake, then get seated at a workstation and immediately lobbed into a project. But by then, the grandest of opportunities toward employee investment—acclimating them as a human rather than as a “worker”—has already been lost.

    To prevent that, I’ve created a different kind of onboarding experience at my agency, Nansen. We begin Day One on a Friday, and use the following process for new design hires (though with some adjustments, the experience can apply to any role):

    Acclimation

    The first half of the day is setup: coworker meet-and-greets, personalizing and configuring their laptop for their own level of comfort, and working with the appropriate team members to secure licenses and install the tools they need.

    Conversation

    The day in the office proper effectively ends around noon. Over an off-site lunch, there’s conversation: on design, on creative inspiration, on how our team functions within the organization, on current and future projects. The clock isn’t watched, judgy gazes aren’t cast, and implications of seniority or hierarchy are left off the table. Taking a team member out to lunch on their first day isn’t rocket science; how they’re engaged (constructive dialogue versus cell phone tunnel vision) is where we see the most value.

    Inspiration

    With questions answered, there’s only one expectation for the day: we make a visit to anywhere in the city that inspires the designer. While the role is contextualized by digital endeavors, inspiration has no such limitations. For some, it might take the form of Chicago architecture; for others, a museum’s collection. Understanding what has influenced them creatively, then, provides insight into their approach to visual communication that exceeds what folio work can yield.

    Reflection

    By this point, a first day of copious amounts of healthy discussion (and coffee, and walking) has served to establish a tone of humanized dialogue. By the business clock there’s typically not much time remaining; as such, the remainder of the day and weekend can be taken for thought and reflection on what was, very likely, a first day unlike any other previously experienced.

    Monday, then, remains the day to begin client and project understanding and familiarity. Now serving as Day Two, it has been prefaced by a tangible and immersive demonstration of how their thoughts and voice are valued, and how the creative team functions. While some of the day can be adjusted or tweaked per the role being filled, this process demonstrates our agency culture and fosters mutual respect and appreciation.

    A healthy dynamic

    It’s staggering how much relationship dynamics can, and will, undermine your team members’ collective confidence. Lack of constructive mentorship and supportive guidance, or leaders who elevate themselves above those whose skillsets they should be cultivating—these things are as poisonous as open hostility.

    In a junior role I occupied eons ago, the culture was openly hostile toward mistakes and subjective failure. Whenever I was given the opportunity to present my work to a client, leadership’s attitude was one of baited anticipation toward mistakes I might make (perceived or factual), combined with self-preservation of ego. After wrapping things up, I knew it was a toss-up as to whether management would simply leave the room without event (best case scenario), or if I’d get pulled into any of a handful of Herman Miller-furnished offices for denigration. This type of “leadership” behavior induces anxiety, inhibits confidence, and is tantamount to psychological abuse. No amount of employee compensation validates flaunting your own insecurity.

    In contrast, presenting work should always be an opportunity for employees to thrive and succeed. To that end, preceding any client-facing walkthrough of a project, I give my team some initial thoughts on what we should be covering—“Don’t assume the client knows what we know: why we did what we did and what the benefit is to the user and to the project’s goals”—and I clarify our presentation roles—“I’ll set the presentation up, and should I chime in during your walk-through, it’s to supplement your dialogue.”

    If your team member is junior and hasn’t presented their work before, give them the chance per their level of comfort. It can start small. On completion, have an open conversation without any implication of retribution. Dialogue is formed by feedback, not belittlement and threats. The ultimate goal is exposing them to the process, and giving them the (well-supported) chance.

    Providing and fostering an environment for open creativity and dialogue is valuable beyond measure. Value conversation over oration, collaboration over delegation.

    In practice, a step further

    One of the career development and employee investment perks we offer at my agency is sending our team members to a conference of their choice, anywhere in the US, all expenses paid. This is formally qualified on paper as: “Learn, contribute, and network at conferences of your choosing.”

    The one stipulation is that, upon their return, the attendee presents to the agency what they got out of the opportunity, and the (potential) worth to other team members in attending next year. Not a bad deal, right? By and large, it’s a strong demonstration that we see employees as much more than pure instruments of client project execution; it shows that we want our team members to grow and evolve. That said, it could be taken further.

    At Nansen a couple of years ago, we started a program called Wintercamp, with the goal of fostering active (over passive) learning. Everyone in our agency—all roles from our global locations—centralizes at a retreat in rural Sweden to create something together. We develop tools we can use in our daily process once back on home turf. We participate in open collaboration and non-adversarial discussion. We put faces to names of people only previously known from an email chain. Our titles are irrelevant; the teams we form, flat and collegial.

    When participants aren’t focused on work, they cook for one another, have endless discussions about their mutual craft(s), and enjoy the surrounding expansive grounds and leisure activities. At the end of each day, the various project teams present to each other what they’ve accomplished, what the pitfalls were, and solicit open and honest feedback.

    People return to their home offices recharged. Invigorated and inspired by their global coworkers, they can act as living embodiments of our culture and brand. The projects worked on at Wintercamp continue as formal entities once we’re back at our desks, which helps keep the momentum going. And teams function more effectively, having worked toward common goals and made deeper personal connections.

    To those who sign the checks, the grand total per person equals around a third of the cost of the standard “conference offering.” And we’re by no means the first, nor the only, team to do something like this; numerous agency retreats and “hackathons” already exist. Clearleft’s Hack Farm was very much the model by which we structured Wintercamp. Twitter’s quarterly internal Hack Week has yielded everything from practical functionality like the ability to archive your own tweets to the more fanciful open-source photo-tweeting birdhouse. Many organizations have seen the value of these types of internal retreats; the wins, they are aplenty.

    Let’s reset

    For many agencies, what I’m advocating represents a shift in thinking, a shift in process, a shift in how we track and value employees’ time. But we’ve made similar shifts before—like when we had to begin advocating for the user at the discovery level, bringing UX into the forefront of our approaches. Today, it’s exceedingly evident that time spent on UX is vital for a digital project’s livelihood; we need to apply that same reevaluation to time spent on employee success.

    Whether this serves as procedural affirmation or a wake-up call, team member advocacy is our obligation. If you’re in agency leadership and read this with head nods and all-knowing winks, the highest of fives to you, sir or madam. Conversely, if this all seems unfamiliar, even better—you have an opportunity to create a better environment, one that doesn’t use “being the last to leave the office” as your main metric of employee dedication (the norm in far too many agencies).

    To those currently in unhealthy, unsupportive, unengaging cultures: that feeling you get in the pit of your stomach come Sunday evening as the work week looms large needn’t be the norm. When the passion toward your craft isn’t fostered and equalled by your agency’s leaders, your options are self-evident: an open and honest discussion with the cultural stakeholder(s), or liberating yourself from your current role.

    If you’re looking toward new opportunities, taking the pulse of a potential new employer’s culture is a paramount step. Pay attention to a few key things:

    • What kind of story are they telling? Agency sites that tell a story are all the rage. Quite often, the result can reveal internal culture. For example, what’s the focus of their full-screen background video? Most importantly, what gut feeling does it give you?
    • What can you spot in the space? We all exercise hyper self-awareness during an interview. Was that handshake too hard? Am I speaking slowly enough? Do I have salad in my teeth? Once in the space of an agency you’re interested in, however, give awareness to your surroundings as well. A day in the life of that agency is effectively unfolding before your eyes, their culture revealing itself plainly and openly.

    Whether in a leadership role as the cultural advocate, or as a passionate and dedicated member of the team, we can agree: a happy and well-supported employee is a fueled, charged, inspired worker. Quality of work is elevated, quality of life is strengthened, and the agency’s brand becomes organically championed by the very people it supports. Our team members truly—no matter the size of the agency, the industry focus, or the specific role—deserve nothing less.

  • Crafting a Design Persona 

    Every product has a personality—whether it was deliberately designed to or not. Reddit is quirky, hyperactive, and sometimes sarcastic. Amazon is like a salesperson with an eidetic memory and amazing talent for statistics. And One Kings Lane evokes a sophisticated, well-dressed interior designer with a carefully curated library of style collages.

    But sometimes products have unpredictable, temperamental, or multiple personalities.

    At Weather Underground, where I worked until this May, we realized our website was suffering from personality problems while taking an inventory of all our products and pages before undergoing a design overhaul last year. For example, we used far too many exclamation marks when inviting users to join and contribute to our community (“Welcome! Join the Conversation! Start a Weather Blog!”). And we gave users very little indication when there was an error, much less an apology for it. (Our 404 page said simply, “An error has occurred.”) Overall, Weather Underground came across as unpredictable, awkward, and in need of a lesson on social graces.

    Weather Underground was the first weather website on the internet, so we wanted our new design to stay true to this history and even strengthen the “weather nerd” aspect of our personality. Yet we also wanted to modernize our visual design and make WU more enticing, welcoming, and friendly. In this moment of designerly tension, we realized Weather Underground’s product personality needed definition, and the best course of action was to articulate a design persona.

    Unlike a user persona, which characterizes your users’ goals, motivations, and desires, a design persona characterizes how your product should communicate and ultimately build rapport with your users. Both are articulated in terms of a fictional character, but they are used to solve different design problems. A user persona helps you understand your users’ existing relationship to your product, whereas a design persona helps you understand how your product can build a relationship with your users.

    In this article, I’ll show you how we came to think of our product as less of an “it” and more of a “someone” with an engaging, yet consistent, voice. I’ll also show how our design persona has become a continual source of product ideas.

    The persona party

    One of the most difficult aspects of creating a design persona (and arguably the most important) is to think of your product less like a collection of algorithms and more like a person. To achieve the right mindset, I asked our designers to imagine a fictitious “persona party” attended by all of our user personas, our key content creators, and, of course, our design persona. Here is the prompt I provided:

    Imagine that you are WU, the essence of Weather Underground, and you’re at a party. You see [one of our meteorologists] surrounded by a small audience of enthusiasts nodding sagely as he discusses the storm system moving toward Florida. A group of Personal Weather Station owners are hanging out together discussing the record extremes they’ve recorded. In one corner there is [our comedic videographer] drinking something out of a mason jar and cracking jokes about winter storm “Janus.” There is also a gaggle of Wunder Photographers eating all the cheese dip while they ogle and praise each others’ photos. These are your friends and they are all hanging out at YOUR party…

    I told the designers that if they found it difficult to imagine Weather Underground as a person, they could imagine how someone similar, like Neil deGrasse Tyson or Bill Nye, would act, and then ask whether WU would act the same or different.

    We then used scenarios to brainstorm our design persona’s potential reactions. For example: “Someone wanders up to you and asks, ‘Do you think I’ll need an umbrella today?’ How do you respond?”

    • Yes. It looks like you’ll need an umbrella today, because there is a 40 percent chance of rain after 3 o’clock.
    • Don’t say a word, just point at a graph.
    • It’s going to be sunny and warm outside today, so break out those jogging shoes! (This weather update brought to you by Nike.)
    • You’ll need a bigger umbrella than the one in your cocktail! (Haha!)
    • Get out your phone, we’ve got a great app for that!
    •  

    For each reaction, we debated how desirable it was and how true it was to our persona. For example, we realized that WU frequently displays graphs and tables of rich weather data, similar to the example response of “Don’t say a word, just point at a graph.” We decided that it would be much more approachable, friendly, and desirable to provide concise explanations of weather forecasts in addition to the detailed graphs and tables. However, several designers were quick to point out that WU shouldn’t be too friendly—for example, it would be off-putting and distracting to tell a joke when users are looking for the forecast.

    After going through a number of similar activities and debates, we noticed themes in WU’s personality that shaped our subsequent discussions. We decide that WU should:

    • Answer questions directly, but always back it up with rich data.
    • Speak in a colloquial and friendly tone, but never oversimplify explanations.
    • Occasionally use humor in a conversation, but never in discussing current or serious weather.

    These observations guided our definition of WU’s brand traits. Ultimately, we decided that WU is:

    • an advocate, but not an evangelist
    • intelligent, but not condescending
    • technical, but not unapproachable
    • playful, but not distracting

    We articulated our brand traits in a “this-not-that” format, similar to how Kate Kiefer Lee and Aarron Walter described their brand traits at MailChimp, because it allowed us to qualify them against brand enemies.

    These traits now act as design constraints for all projects, making consistent designs much easier to develop. They also provide heuristics for design reviews, allowing us to critique designs in terms of concrete, established goals.

    Responses in context

    While the brand traits highlight some of WU’s more admirable qualities, they do not identify WU’s approach to specific scenarios. Or, as Kate Kiefer Lee might put it, articulating our brand traits helped define WU’s voice, but now it was time to figure out WU’s tone.

    As the next step in our activity, we decided to create a personality map. Aarron Walter uses this tool in Designing for Emotion as a way to describe a personality on an x-y axis. On one axis, you have the degree to which the person is submissive or dominant in their interactions. You can think of a dominant person as one who takes charge and presents themselves as an authority, whereas a submissive person would rather follow someone else’s lead. On the other axis, you have the degree to which the person is affiliative or unaffiliative—interested in building a connection, or interested in maintaining distance. Aarron Walter uses the terms “friendly” and “unfriendly” here, but I think “unfriendly” conveys active meanness or abrasiveness, while “unaffiliative” simply conveys emotional or professional distance. For example, your doctor may act friendly toward you, but also make it clear with their behavior and demeanor that it would be inappropriate to ask them out for coffee later.

    A four-quadrant personality map, with different areas marked for WU’s personality in different moments.
    The WU personality map.
         

    When I asked everyone to pick the one place on the personality map that best represented WU, everyone picked distinctly different spots. And for each selection, there was a supporting story and context:

    • WU should be dominant while discussing the weather, because that is WU’s expertise.
    • WU should be submissive when apologizing for a server outage.
    • WU should be affiliative when discussing interesting weather events that have happened in the past, because we want our users to join the conversation.
    • WU should act affiliative and moderately dominant when introducing educational content, because we want to come off as a nerdy, friendly professor.

    We realized that people (and design personas) behave differently, and may assume a different identity, depending on who they are talking to and the context of the conversation. For example, your doctor may be dominant and unaffiliative while discussing medical treatments with you, but will become submissive and affiliative while discussing Thanksgiving dinner plans with their grandmother. We are never just one spot on a personality map; our design persona should act differently depending on the context, too.

    We decided that rather than picking a single spot on the personality map, we would draw out multiple points and context zones. For example, you can see that during “Severe Weather,” we want WU to sound and act like an authority. However, when we have a system failure and end up in the “Apology Zone,” we want to be conciliatory and apologetic.

    Debate the minutia

    The personality map was only the beginning of our many debates.

    For the next phase, I asked everyone to think of responses WU would give in specific website scenarios, such as welcoming a new user, telling a user their action was successful, and informing the that user an error had occurred. Each team member contributed a possible response, and we discussed how well each matched the brand traits we had defined and what we knew about our persona so far.

    These conversations led to a number of debates: should we ever address a user by name? (Verdict: Yes, but sparingly.) When, if ever, is it appropriate to use humor? (Occasionally, but we are always serious about the weather.) When and how should we apologize to users? (Always for technical errors, but not for incorrect forecasts.)

    Each debate added to our growing library of response examples and taught us more about the nuances of our personality. And while these debates seemed, at times, tedious and narrow, we were actually working through problems in product consistency that we had previously overlooked. We were learning that to have a consistent product personality, we needed to know how WU should present itself across product, design, content, copy, and branding.

    Let your light shine

    Now that we had a product personality that we thought would resonate with our user base, we needed to find ways to let that personality shine. For our final design activity, we decided to brainstorm ways to create opportunities.

    We started with a simple framework based off of Aarron Walter’s description of design personas in Designing for Emotion. We focused on:

    1. Creating interactions that inspire surprise and delight.
    2. Giving users a sense of anticipation.
    3. Rewarding users for their continued patronage.

    We generated no fewer than 35 unique ideas to delight or reward our users, from Easter eggs on Groundhog Day to redesigned 404 pages. One of the simplest, yet most powerful, ideas was enabling our users to thank their local Personal Weather Station owners for their weather data. The implementation details of this functionality are trivial: button click → thank-you message sent. But it has tremendous product engagement potential, because it simultaneously lets users know that their weather data comes from a real human who has generously added their data to the WU community, and thanks those owners for their contributions. The team is currently working on the final details of the PWS thank-you feature and hopes to release it in conjunction with a “PWS Owner Appreciation Day” marketing effort.

    Another idea that emerged was WunderPosters: artistic posters depicting interesting and beautiful natural phenomena created by one of our in-house designers. We released WunderPosters during Weather Underground’s twentieth anniversary, coupled with a contest where fans could submit ideas and vote on which weather conditions they would like to see turned into a poster. The project spanned departments (design, engineering, and marketing), and has engaged our users over multiple channels. It also speaks directly to the “weather enthusiast” aspect of our design persona.

    Ideas like these confirmed for us that a design persona is not just about keeping your copy and voice consistent—it also provides a source of design inspiration.

    Start your personality adjustment

    Disjointed product personalities can emerge in the best of websites when small, non-technical details are repeatedly neglected over time. But solving your product’s personality problems is as important as solving the technical ones.

    To start your own personality adjustment, gather a small group of people from throughout your company (including marketing, design, engineering, and product management) and take an inventory of existing copy, iconography, and content. Identify the points in which the tone of your product seems overly dramatic, familiar, brusque, formal, or odd. These will be the initial personality trouble points you solve after defining your design persona.

    As you go through activities like the ones I’ve outlined throughout this article, try using this worksheet I created to get everyone thinking about your design persona individually before discussing it as a group.

    Photo of a poster explaining Weather Underground's brand traits for internal staff.
    WU Brand Traits poster, hung on the back of a bathroom stall.

    Finally, make sure you record and summarize the insights, decisions, and examples you generate. At Weather Underground, we created a WU cartoon figure to represent our design persona and featured him with our other mascots on a series of posters. We then hung those posters in places where our coworkers were sure to see them—such as the back of bathroom stalls.

    Crafting a design persona is an intense exercise that requires the the time and involvement of team members throughout your company. While the work may seem daunting, it is well worth it. By investing in your product’s design persona, you are investing in future advocates of your product—and creating a source of design inspiration for your team.

  • Coming June 16: Pattern Language 

    The web hasn’t merely moved beyond the desktop in recent years; the web has vaulted right over the desktop. It’s not just about phones, laptops, tablets, or [deep breath] phablets anymore: our sites and services can appear on anything from smart watches to handheld gaming consoles, on living room televisions or cars on the highway. How can we possibly keep up?

    Well, responsive web design can absolutely help with some of these challenges—but it’s not enough by itself. Flexible layouts and media queries are great, but we also need to move beyond “pages.” Instead of building abstract grid systems of columns and rows, we need to embrace patterns: small components that can adapt independently of any interface, and that we can stitch together to create more complex responsive layouts.

    If you’re incorporating more pattern-driven design into your work, join us for our next ALA: On Air event on Tuesday, June 16. Our panelists will take a look at responsive patterns, share what they’ve learned, and discuss what’s next.

    Event details

    This event is free and everyone is welcome (though you’ll need to register to participate in the Q&A). Here are the details:

    Tuesday, June 16
    1–2 p.m. EDT
    via Google Hangout
    Register or get more details

    We’ll have 30 minutes of conversation between our panelists, and then open things up to questions from attendees. Like we did with our last event (“Sass Talk”) we’ll share the video the following afternoon, and will publish the full transcript a few days after that.

    Join our email list to get updates when new events, videos, and transcripts are posted.

    The panelists

    We’ve rounded up some stellar panelists:

    Big thanks to Pantheon

    Putting on events is a ton of work, and we couldn’t do it without the generous support of our sponsor Pantheon. Sign up for a demo to see Pantheon’s unified platform for building, launching, and running Drupal and WordPress sites.

  • This week's sponsor: MailChimp 

    Thanks to MailChimp for sponsoring A List Apart this week! MailChimp offers powerful features like a drag-and-drop email designer, A/B testing, and marketing automation. Try it today.

  • Picturefill Me In 

    If you started reading this hoping that I might bring more references to the excellence of Craig David’s early ’00s jams, the title is really the best I’ve got.

    Sorry.

    I’ll cut right to the chase: update your copy of Picturefill.

    npm update --save picturefill

    (or whatever the equivalent thing to do is in the way you’re managing your libraries). Go ahead and do that. Make sure you’re up on the newest in Picturefill hotness (2.3.1 as of when I was writing this). It’s important.

    How important?

    Older versions of Picturefill can net you broken images in both Microsoft Edge and Webkit Nightly. There’s already an issue logged for the problem.

    You may be sitting here thinking, “OK, Jeff. So what’s the big deal? Some people have some broken images on their sites—they’ll get up to fixing them at some point” and this is where I tell you the deeper problem. Let’s say you’re Microsoft and you’re working on your new awesome browser that people are getting excited about. It’s got support for some of the latest and greatest web technologies. Now, let’s say your new browser is rolling out support for responsive images and it just so happens that a polyfill that’s on thousands of websites, including quite a few that get a lot of traffic cough espn.com cough, throws an error in your browser that makes it so images don’t show.

    That’s a straight-up, first-class bad experience. You can’t have that. So, you remove the feature in your browser that collides with the error in Picturefill. Then, all it takes is another browser doing the same thing and all of us out here hoping this spec lands are worried that the functionality will get scrapped all together.

    You see why we’re all worried now?

    The good news is that you can help! We need this bug to hit the fewest number of people possible. Let’s get the sites out there using earlier versions of Picturefill upgraded. Upgrade your own. Let your people know about the need to upgrade. Evangelize this biz like you were born to do it (OK, I lied, there’s another Craig David reference after all).

    For more information, check out Mat Marquis’ post on CSS-Tricks.

  • We (Still) Have Work to Do 
    We’re here, and we’re on the record: the web industry has a diversity problem. It’s got a misogyny problem. It’s standing in the way of the web we want, and we are all—every one of us—responsible for changing that.

    I wrote these words one year ago today, at the peak of the #yesallwomen discussion. They’re just as true now as they were then. But as Nishant Kothary wrote in his column a couple weeks back:

    Even with its hundreds of contributors, columnists, and bloggers, ALA has very little to show for this aspiration in a year (interestingly, what it does have to show was contributed almost entirely by women).

    I make this point not to criticize ALA…but to highlight just how difficult it is to talk about difficult things even when you explicitly and publicly set the goal of doing so.

    So, what have we done? It’s a fair question, and one that’s worthy of a response. Because the answer is this: everything, and also not nearly enough.

    Over the past year, we’ve started discussing inclusivity constantly, across every facet of our work—the authors we encourage, the messaging on our website, the people we invite to events, the way we edit articles, the topics we cover.

    And yet, we screw up constantly. We cringe when we notice too late that we published an article with a biased example, or used words that defaulted to male. We struggle to include more people of color and non-native English speakers in our pages. We hear that our submissions copy feels alienating.

    We’re trying. But what we haven’t been doing is talking about it publicly—because it takes time, yes, but also because it’s scary to lay bare all our decisions, discussions, half-baked ideas, and partially executed plans. It’s scary to say, “we don’t know all the answers, but here’s where we’ve started.”

    That changes today.

    What we’re up to

    “We have work to do,” I began last year. And we still do. Sometimes, that work feels overwhelming. Mostly it’s exciting, because it reminds us why we’re here, and what we want this industry to look like in another year, in five years, in ten years.

    Here’s what we’re working on so far:

    More inclusive editing

    When we edit, we no longer just look for stuff that violates the style guide: website as one word, or 4g with a lowercase g. We also look for biases and non-inclusive language in the words our authors use, and we challenge them to come up with words that pack power without excluding readers.

    It’s not black and white: reasonable people have conflicting opinions on the use of you guys, for example. And some things are so deeply embedded in our culture—like calling things crazy or insane—that’s it’s tough, at first, to even recognize that they’re problematic.

    One change you may have noticed, if you’re as nerdy about words as we are, is our move to the singular they. Writing “he” or “she” is fine, if you’re talking about a person who goes by “he” or “she.” But when we talk about a person in general, or someone who doesn’t identify as male or female, they’re now a they.

    The most important part of this process is that it’s just that: a process. We haven’t “fixed” our editing style. We’re just having an ongoing conversation that gets more nuanced with time—and that everyone on the team is encouraged to participate in.

    Some people might find the prospect of hashing and rehashing language tedious (ugh, do we have to talk about this again?!). But I’ve found it incredibly rewarding, because every discussion forces me to challenge my beliefs and biases—and to be a little more willing to listen.

    Recruiting diverse authors

    When I joined A List Apart in 2012, every issue was a nail-biter: we were never sure until the last minute whether we’d be able to get the new articles together in time. I wanted to recruit and encourage diverse authors—I think everyone on staff did. But when everyone’s brain is stuck on “do we have something to publish?,” it’s hard to make space for questions like, “are we consistently presenting a realistic view of our industry?”

    We should have. It wasn’t until the end of 2014 that I stopped and looked—and I didn’t like what I saw. In 2013, for example, only about 25 percent of our feature articles (that is, not blog posts or columns) were by women. One in four!

    Last year’s numbers were more balanced: about 40 percent of our authors were women. But here’s the funny thing about that number: I thought we were publishing lots of women in 2014. Our pages seemed to be full of ’em! Which just goes to show how easy it is to normalize lack of diversity when you’re not paying attention: 4 in 10 feels like “a lot,” instead of “less than half.”

    That said, 40 percent is better, and we expect this year will be even more balanced—and more diverse in other ways as well. So what have we done? First, we invested in defining our acquisitions and editing process, making clearer decisions earlier about which articles we were accepting, and developing more specific expectations with both editors and authors about deadlines. This isn’t about diversity directly, but indirectly, it’s made a huge difference—because rushing around pushing articles out the door meant that we were never really building a solid pipeline. We were running ourselves ragged without addressing problems up the chain. Formalizing our acquisitions process and clarifying roles and responsibilities freed us up to spend time on bigger picture issues.

    We’re also actively reaching out to more prospective authors, and encouraging them to write—especially people of color and women who are just emerging in their fields. Oftentimes, these folks have viewpoints and ideas we haven’t heard before—but they’re more likely to think they’re not “experienced enough” to submit an article. There is no shortage of articles talking about why this happens. The problem is, many of those articles simply end up telling marginalized groups that they’re responsible for solving the problem: here’s the careful tightrope you need to walk in order to promote your ideas without coming off as “pushy,” they seem to say.

    We’re not buying it. Women and people of color—and particularly women of color, who often feel sidelined by the largely white “women in tech” movement—already have enough to deal with in this field. The least we can do is put in some effort to reach out to them, rather than complaining that they don’t come to us.

    Another area we’ve focused on is ensuring our ranks of bloggers and columnists—the people who write for us regularly—reflect the range of people in our industry. I don’t think we’re quite there yet, but we’re working on it—because the more often diverse faces show up on our site, the easier it is for everyone to imagine themselves there.

    It’s not easy to recruit diverse authors, and there are still lots of reasons smart, talented people from marginalized groups don’t want to expose themselves to the risks of writing publicly. But here’s the truth: finding diverse authors isn’t that hard, once you’ve started.

    Changing our tone

    In addition to changing our submissions and editing processes, we also took a look at how we were talking about ourselves, our authors, and the process of contributing to the magazine. Here’s what the copy on the submissions page used to say:

    So you want to write for A List Apart Magazine.

    What we’re looking for

    We want to change the way our readers work, whether that means introducing a revolutionary CSS technique with dozens of potential applications, challenging the design community to ditch bad practices, or refuting common wisdom about, say, screen readers.

    If your article can do that, we want to see it.

    “So…” So? That tiny word sets a tone of disbelief—like we might as well have added “then prove it” at the end. And don’t get me started on those verbs: challenge, refute, revolutionize. Why are we being so aggressive? What about articles that help our community grow, learn, or improve?

    We had good intentions here: we wanted to make readers feel like an ALA article was special—not just a post you whip out in an hour. But it wasn’t working. When I asked people whom I’d like to see submit what they thought, I got responses like, “sending something to ALA sounds scary,” or “that seems like a really big deal.”

    Oof.

    Writing publicly makes most people feel vulnerable, especially those who are just starting to put their ideas out there for the world—in other words, the very people we’re most interested in hearing from. You might get rejected. People might disagree with you. You might even get harassment or abuse for daring to speak up.

    We can’t remove all the risks, but what we can do is offer a more nurturing message to new writers. We started by overhauling our contribute page—in fact, we renamed it Write for Us, with an aim of making the message a little more human. Then we got feedback from a couple prospective authors, which led to another round of tweaks. Here’s what it says right now:

    Write for Us

    Yes, you. We’re always looking for new authors. If you’ve got an idea that will challenge our readers and move our industry forward, we want to hear about it. But you don’t need to wait for an idea that will redefine web design. Just aim to bring readers a fresh perspective on a topic that’s keeping you up at night.

    Rereading it now, I don’t think it’s quite right yet, either. It’s still got more of those aggressive verbs than it needs. But one thing I love about it is this:

    Yes, you.

    Those two tiny words speaks directly to someone who’s not sure they’re in the right place, not sure we really want to hear from them.

    Of course, there’s more to our tone than what’s on the submissions page. We’ve also started making other communications less aloof and a bit more approachable. We’re not some impenetrable entity in the sky, after all. We’re your peers.

    It’s funny to admit this, because it sounds so obvious. But one thing we’ve started doing just recently—as in, this spring—is tweeting about accepting new authors. Nothing fancy: just kindly, and regularly, reminding people that we’d love to hear from them.

    Why didn’t we do this years ago? The easy answer is that we just never thought about it. We are all busy, working on ALA on the side, and “social media strategy” has never been our top priority. But if we’re being honest with ourselves here, the real answer is this: we didn’t want to admit that incredible, mind-blowing, ready-to-publish content didn’t just come to us.

    But getting great articles about a big, changing industry simply isn’t easy, no matter who you are or how long you’ve been publishing. And, admittedly, our editing process isn’t exactly a walk in the park: we have high editorial standards, which means we don’t accept everything that comes our way, and we ask writers lots of tough questions even when we like their work. What that adds up to is that many submissions won’t pan out, and many already established authors aren’t looking for the kind of editorial commitment writing for us entails.

    So, now we do a better job of reaching out to the people who do want that commitment, and that opportunity to learn.

    All it took was swallowing some pride.

    Inclusion is a practice

    I wish I could say that all these changes have been easy for me. But wanting to be more inclusive and actually doing what it takes to be inclusive aren’t the same. Along the way, I’ve had to let go of some things I was comfortable with, and embrace things I was profoundly uncomfortable with.

    For example: I hated the singular they for years. It just didn’t sound right. That’s not how subject-verb agreement works, dammit. Our columns editor, Rose, suggested we start using it forever ago. I vetoed the idea immediately. I edited it out of articles. I insisted authors rewrite examples to avoid it. I stuck to my she and he like they were divinely prescribed.

    Only grammar isn’t gospel. It’s culture. Language changes constantly, adapting endlessly to meet the world’s new needs and norms. And that’s what we have right now: a cultural shift toward less gendered thinking, less binary thinking. I wanted the culture change without the language change.

    I was wrong.

    If someone has a problem with it, they can complain to me.

    What’s next

    Our process is evolving constantly, and I can’t tell you exactly where we’ll be this time next year. But I can promise this: we’re going to keep talking about it—inside of ALA, and, more often, publicly, too.

    We still have work to do. But our industry—our peers whose paths are more difficult than ours—deserve it. We hope you’ll join us.

  • This week's sponsor: Squarespace 

    Thanks to Squarespace for sponsoring A List Apart this week. Check out their tools to help you create beautiful websites.

  • Lyza Danger Gardner on Building the Web Everywhere: Mentorship for the Novice Expert 

    I have to admit something. I’m not very good at being a beginner.

    I’ve started riding a motorcycle again after six years. Riding is notoriously risky. There are usually seven dozen ways you are about to die at any moment. Every early morning when I get up for a practice ride, I’m all gelatinous with nerves.

    But as I start up the bike, it’s not visions of being obliterated by tractor-trailers I’m quaking about. It’s the through-the-curtains drowsy glares of neighbors when I have to adjust the choke to a louder place to get the idle stable. Not the fear of getting creamed, but a dread of getting honked at. It’s the shame of wobbly turns and leaving my turn signal on.

    And yet, I get up morning after clenched morning; I keep doing it because I believe the thing I’m working toward is important and relevant to the person I want to be.

    Being a beginner can be terrifying and embarrassing. But it’s worth it when it changes your life or someone else’s. Coming to understand this has slowly transformed 2015 into the year I become a mentor. It’s awkward and bumpy and I love how it is transforming me.

    I have no idea what I’m doing

    I dislike it when it’s obvious, in public, that I have no idea what I’m doing. The humiliation burns even hotter if the thing I’m flailing at feels like something I should have already mastered.

    I have long worried that I wouldn’t know how to be a mentor. This holds me back, and it makes me feel shallow. Early this year I metaphorically shook myself by my own shoulders and snapped, “Get over it, Gardner!”

    I had no idea what I was doing. But I was going to do it anyway.

    First, show up

    I started tentatively reaching out to colleagues and acquaintances. First I made sure I was attuned to little opportunities—helping someone debug a specific thing, or understand a particular feature of git.

    I had been operating under this illusion that mentors were sprung fully-formed at birth. Silly, of course. Much of the path to mentorship can be built with the basic skill of showing up. If I can tenaciously help someone find answers to questions, repeatedly, this steadiness can transition automatically into a mentorship-flavored relationship.

    Friendship with intent

    Mentoring relationships have different shapes. Many incorporate other facets: friendship, mutual interests, perhaps familial or professional ties. But all are personal.

    I’ve found that mentorship can be a successful bolt-on addition to an existing friendship. That part of your friendship now has structure. Mentorship is like friendship with intent.

    Intent means going further than vague suggestions of “Hey, we should talk about JavaScript sometime.” It means getting things on people’s calendars, and entering scheduled conversations with some goals about outcome. Success is manifest not just in your own performance, but in someone else’s ultimate success.

    Reaching out

    Having clarity and intent doesn’t mean we need to operate with an unbending focus on the end objective. For example, I might respond to an acquaintance’s online expression of technical woe with a message like:

    Hey, (friend)! I’ve so been there. It can feel wildly overwhelming, huh? Would you like to have lunch and talk through what is making you feel so stuck? Maybe we can tease out the confusing bits and look at them more closely. How about (day and time)?

    For both of us, this can be an informal lunch conversation, with venting and tangents. And food, yum. But I’ll be mentally present in an active way. This is the conversational equivalent of alert motorcycling through dense neighborhood traffic, versus the car-on-open-interstate languor of, say, weekend patio conversations. I’m relaxed but ready, on point.

    Curriculum follows later

    Another admission: what initially got me inspired about this was the idea that I might get to write a fun curriculum and explainers. Oooh! Sample exercises, even! I love explaining technology with words (writing Head First Mobile Web with Jason a few years ago was life-altering).

    This is, unsurprisingly, cart-before-horse territory. You’re not a professor; these won’t be packaged lectures. You don’t get to hand out a syllabus on the first day of class. Your mentee hasn’t even decided on a major, as it were.

    Mentorship, again, is a relationship. This is human, which means soft skills and flexibility. I run close alongside that stereotype of socially uncertain, slightly awkward technical people, so these skills sometimes aren’t well-honed for me.

    I have to knuckle down and concentrate on these interactions, especially shutting my trap and listening, listening, listening.  I am not always successful; when I get nervous I tend to fill gaps with words.

    But over time I try to come to an understanding of how a particular person learns best, what fires his or her imagination. I find great power in the use of questions. What feels like success to you? Do you feel more at home with theoretical or applied examples on this topic?

    I get answers, I get a more complete picture. And then sometimes they ask for sample exercises. Yes!

    Mentorship is vital in our industry

    Since the personal mental challenge of teaching content turned 2015 into a year of mentorship for me, I’ve become transfixed by the humanity, and how right this feels. There’s something about gifting knowledge to someone that transforms the giver. It bestows the wisdom of being a vulnerable beginner for a greater goal.

    On top of this is a glaring reality: our industry desperately needs mentors. Everywhere. The self-taught among us (yep, me, too!) are legion. Absent classrooms or clear curricula or obvious paths of study, wouldn’t a rich reserve of mentors among us be a great asset? Could we make mentorship part and parcel of our growth as technologists? Can mentorship roles be a default in our organizations?

    Triumph as a vulnerable beginner

    I have no idea what I’m doing and I’m nervous about messing up, but I keep doing this week after week because it feels important.

    Wobbly and inelegant I may be, but the terror of flaunting my inadequacy is eclipsed by the importance of what I’m after. I’m humbled by this opportunity.