Beyond Engagement: the content performance quotient

Recently, Josh Clark, Gerry McGovern and I have been questioning our industry’s pursuit of “engagement.” Engagement is what all our clients want all the time. It’s the № 1 goal cited in kickoff meetings, the data point that determines if a project succeeded or sucked wind. When our clients muse over their Analytics, they’re almost always eyeing engagement, charting its tiny variances with the jittery, obsessive focus of overanxious parents taking a sick child’s temperature.

Engagement is our cri de coeur. Our products, websites, and applications live and die by it. But should they?

For many of our products, websites, and applications, duration of page visit, number of our pages clicked through, and similar signs of engagement as it is traditionally understood may actually be marks of failure. If a customer spends 30 minutes on her insurance company’s site, was she engaged … or frustrated by bad information architecture?

For these products, websites, and applications, we need a new metric, a  new and different № 1 goal. Think of it as speed of usefulness; and call it content performance quotient—or CPQ if acronyms make you feel all business-y and tingly inside.

The content performance quotient is an index of how quickly you get the right answer to the individual customer, allowing her to act on it or depart and get on with her day. It is a measurement of your value to the customer. For many apps, sites, and products, the content performance quotient offers a new goal to iterate against, a new way to deliver value, and a new way to evaluate success.

For many sites, engagement is still a valid goal

To be fair as well as explicit, spending extra seconds on a web page, and browsing from one page to another and another, remains a desirable thing on deep content sites like A List Apart and The Washington Post — sites that encourage slow, thoughtful reading.

A List Apart isn’t a place to grab code and get back to your web development project; it’s a place to ponder new and better ways of designing, developing, and strategizing web content. And pondering means slowly digesting what you have read. The Washington Post isn’t a purveyor of ten-second talking points and memorable but shallow headlines—it’s a place for detailed news and news analysis. That kind of reading takes time, so it makes sense if the owners and managers of those publications peruse their Analytics seeking signs of engagement. For everyone else, there’s the CPQ. Or will be, once someone reading this figures out how to measure it.

There’s also a new design paradigm that goes hand-in-hand with this new goal: shrinking your architecture and relentlessly slashing your content. It’s an approach we’ve begun practicing in my design studio.

But first things first. What exactly is the CPQ?

The content performance quotient (CPQ) is the time it takes your customer to get the information she sought, and here, less is more—or better. From the organization’s point of view, CPQ can be the time it takes to for a specific customer to find, receive, and absorb your most important content.

Come to where the messaging is

 

Consider the Marlboro Man (kids, check the Wikipedia entry), a silent visual spokesman for Marlboro cigarettes, created by the Leo Burnett agency for an era when Americans expressed their optimism by driving two-ton be-finned convertibles along the new highways that bypassed the old cities and the old urban way of life.

It was a time when Americans looked back on their historical westward expansion un-ironically and without shame. Cowboys were heroes on TV. Cowboys were freedom, the car and the highway were freedom, smoking the right cigarette was freedom.

On TV back then, when commercials had a full 60 seconds to convey their messaging, and nearly all were heavy on dialog and narration, Marlboro TV commercials were practically wordless. They showed a cowboy riding a horse. You saw him in closeup. You saw him in long shot. There were slow dissolves. There was music. There were no words at all, until the very end, when a suitably gravel-voiced announcer advised you to “Come to where the flavor is. Come to Marlboro Country.”

But it was in billboards along the highway and at urban entrance points where the campaign really lived. There was a beautiful shot of the cowboy doing cowboy stuff in the distance. There were four words: “Come to Marlboro Country.” One of them barely counts as a word, and you didn’t have to read any of them to get the message.

The billboards had one or two seconds to tell you everything, and they worked. At a glance, and from repeated glances over time, you knew that Marlboro was the filtered tobacco cigarette of the independent man who loved liberty. It was not the smoke of the neurotic urban dwelling subway rider (even if, in reality, that was the customer). Marlboro was for the libertarian in chaps. For the macho individualist with no crushing mortgage to pay off, no wife and kids to infringe on his horse-loving freedom. You got it all, without even knowing you got it. That’s performance.

Targeting convertibles on the information superhighway

In hindsight, it sounds ridiculous, but the super-fast storytelling worked: when I was growing up, Marlboro was what every child in my middle school smoked.

Remove the cancer and the other ethical problems from this story and hold fast to the idea of conveying information as close to instantaneously as possible. The geniuses behind the Marlboro Man achieved it by reducing their messaging to only what was needed—only what could be conveyed to a person passing a billboard at 60 MPH.

Your customer is not speeding past your messaging in a 1954 convertible, but she is speeding past it, and if you don’t optimize, she will miss it. For her to get your message, you have to work as hard as those evil ad wizards did. You must focus relentlessly on messaging (as well as design and site performance—but we’ll get into all that soon enough). Just as Leo Burnett cut their TV messaging to ten words, and their billboard to four, you must be willing to think twice about every word, every page. Mobile First taught us to focus above all else on the content the customer actually seeks. A better CPQ is what you get when you do that—particularly when you combine it with good design and optimal technical performance. 

Most business websites contain dozens of pages that were made to satisfy some long-ago stakeholder. They are pages that nobody visits. Pages that do nothing to help the customer or advance the business’s agenda. Putting all that junk online may have made for smooth meetings ten years ago, but it isn’t helping your business or your customer. Our sites, apps, and products must do both.

Content performance quotient: the secret sauce

Lately in my design practice I’ve been persuading clients to create sites that might superficially appear less effective if you’re going by engagement metrics alone, but which are actually far more successful because they are more instantly persuasive. At my urging, our clients have allowed us to relentlessly cut copy and chop sections nobody looks at, replacing them with a few pages that are there to do a job. We are lucky to have smart clients who are willing to jettison hundreds of hours worth of old work in favor of a streamlined experience that delivers value. Not every client has the courage to do so. But more will as this idea catches on. 

(By the way, don’t look for these projects on our studio’s website just yet; they are still in development.)

Serving only the content the customers actually need; streamlining and testing and fine-tuning the interaction to get the right customer to the right content precisely when they want it; wrapping the experience in an engagingly readable but also quickly scannable user interface; and doing everything in our power to ensure that the underlying web experience is as performant as possible—this, I believe, is the secret to increasing CPQ.

CPQ: the story so far

Designer Fred Gates, kicking it in Central Park, NYC.

 

The idea of delivering much less (but much better) first occurred to me while I was looking over a fellow designer’s shoulder. My friend Fred Gates of Fred Gates Design is working on a project for a client in the nonprofit education space. The client’s initial budget was not large, so, to be fair, they suggested Fred only update their homepage. But Fred being Fred, if he was only going to design a single page, he was determined to deliver tremendous value on it.

By focusing relentlessly on the objectives of the entire site, he was able to bring all the principal interactions and messages into a single performant homepage, essentially reducing a big site to a lean, fast, and more effective one.

Far from getting less, his client (and their customers) got much more than they expected.

Inspired by what my friend had achieved, I then proposed exactly the same approach to a client of ours. Not because their budget was a problem, but because streamlining was clearly the right approach … and a redesign is the perfect opportunity to rethink. When you repaint your living room, it gives you a chance to rethink your couch and divan. You’re most likely to consider changing your diet when you’ve begun a new exercise program. Clients are people, and people are most receptive to one form of change when they are already engaged in another.

Positioning CPQ as an aspect of technical performance is another way to overcome stakeholder skepticism. Lara Hogan has more on persuading peers and stakeholders to care about technical performance optimization.

We are a few weeks away from launching what we and the client are calling Phase I, a lean, performant, relentlessly message-focused web experience. But if we’ve done this right, we won’t have much to do in Phase II—because the “mini-site” we’re delivering in Phase I will do more for the company and its customers than a big site ever did.

I’ll be back with updates when we launch, and (more importantly) when we have data to share. Follow @DesignCPQ to stay on top of CPQ thinking.

 

Also published at Medium.

studio.zeldman is open for business. Follow me @zeldman.

CSS & Design: Blending Modes Demystified

A List Apart: Blending Modes Demystified. Illustration by Brad Colbow.

IN AN IDEAL world, we’d be able to modify a design or graphic for the web while keeping the original intact, all without opening an image editor. We’d save tons of time by not having to manually reprocess graphics whenever we changed stuff. Graphics could be neatly specified, maintained, and manipulated with just a few licks of CSS. Oh. Wait. We can do that! Justin McDowell gives us the lowdown: read Blending Modes Demystified in today’s A List Apart.


Illustration by Brad Colbow

A Helvetica For Readers

A Helvetica for readers–introducing Acumin.

ACUMIN by Robert Slimbach is a new type family from Adobe that does for book (and ebook) designers what Helvetica has always done for graphic designers. Namely, it provides a robust yet water-neutral sans-serif, in a full suite of weights and widths. And unlike the classic pressing of Helvetica that comes on everyone’s computers—but like Helvetica Neue—Acumin contains real italics for every weight and width.

Reading about the design challenges Slimbach set himself (and met) helps you appreciate this new type system, whose virtues are initially all too easy to overlook, because Acumin so successfully avoids bringing a personality to the table. Enjoying Acumin is like developing a taste for exceptionally good water.

Nick Sherman designed the website for Adobe, and its subtly brilliant features are as easy to miss at first look as Acumin’s. For starters, the style grid on the intro page dynamically chooses words to fit the column based on the viewport size. Resize your browser and you’ll see how the words change to fill the space.

Heaps of behind-the-scenes calculation allow the page to load all 90 (!) fonts without breaking your pipes or the internet. Developer Bram Stein is the wizard behind the page’s performance.

Nick uses progressively enhanced CSS3 Columns to create his responsive multi-column layout, incorporating subtle tricks like switching to a condensed font when the multi-column layout shrinks below a certain size. (This is something A List Apart used to do as well; we stopped because of performance concerns.) In browsers like IE9 and earlier, which do not support CSS3 Multiple Column specification, the layout defaults to a quite readable single column. Nick adds:

It’s the first time I’ve used responsive CSS columns for a real-world project. This was both frustrating and fun because the CSS properties for controlling widows and orphans are very far behind what’s possible in InDesign, etc. It also required more thinking about vertical media queries to prevent a situation where the user would have to scroll up and down to get from the bottom of one column to the top of the next. If the viewport is too short to allow for easy reading across columns, it stays as a single column.

He describes the challenges of creating the site’s preview tool thusly:

We had to do some behind the scenes trickery in order to get the sliders to work for changing widths and weights. It’s a good way to allow people to type their own text and get a feeling for how the family can be used as a system for body text and headlines (unlike Helvetica, which is more limited to the middle range of sizes). Chris Lewis helped out a lot with getting this to work. It even works on a phone!

Book designers have long had access to great serif fonts dripping with character that were ideal for setting long passages of text. Now they have a well-made sans serif that’s as sturdy yet self-effacing as a waiter at a great restaurant. Congratulations to Robert Slimbach, Adobe, and the designers and developers mentioned or interviewed here. I look forward to seeing if Acumin makes it into new website designs (perhaps sharing some of Proxima Nova‘s lunch), especially among mature designers focused on creating readable experiences. And I pray Acumin makes its way into the next generation of ebook readers.

(Just me? In both iBooks and Kindle, I’m continually changing typefaces after reading any book for any period of time. All the current faces just call too much attention to themselves, making me aware that I am scanning text—which is rather like making filmgoers aware that they are watching projected images just when they should be losing themselves in the story.)

@font-face and Web Performance

Some time in 2009, Firefox and Opera began shipping @font-face support with the former behavior: text would render with fallback fonts until downloadable font resources became available. But this choice frustrated many users (see the Firefox bug report) and was quickly dubbed FOUT, the Flash of Unstyled Text . Articles were written about fighting the @font-face FOUT. It wasn’t long before most browsers were hiding text while fonts downloaded. Unfortunately, the main issue with @font-face now is what many wanted to avoid years ago: the FOIT, or Flash of Invisible Text.

Source: The @font-face dilemma | Viget

You’re welcome: cutting the mustard then and now.

EVERY TIME I hear a young web developer cite the BBC’s forward-thinking practice of “cutting the mustard,” by which they mean testing a receiving web device for certain capabilities before serving content, I remember when my team and I at The Web Standards Project invented that very idea. It’s a million web years ago, by which I mean fourteenish human years ago, so nobody remembers but me and some other long toothed grayhairs, plus a few readers of the first edition of Designing With Web Standards. But I like you, so I will tell you the story.

Back then in those dark times, it was common practice for web developers to create four or more versions of the same website—one for each browser then in wide use. It was also a typical (and complementary) practice to send server-side queries to figure out which browser was about to access a site’s content, and then send the person using that browser to the site version that was configured for her browser’s particular quirks, proprietary tags, and standards compliance failings.

The practice was called “browser detection.” Nobody but some accessibility advocates had ever questioned it—and the go-go dot-com era had no time or care for those folks.

But we at The Web Standards Project turned everything on its head. We said browsers should support the same standards instead of competing to invent new tags and scripting languages. We said designers, developers, and content folks should create one site that was accessible to everyone. In a world like that, you wouldn’t need browser detection, because every browser and device that could read HTML would be able to feast on the meat of your site. (And you’d have more meat to share, because you’d spend your time creating content instead of crafting multiple versions of the same site.)

To hasten that world’s arrival, in 2001 we launched a browser upgrade campaign. Those who participated (example participant here) employed our code and content to send their users the message that relatively standards-compliant browsers were available for every platform, and inviting them to try one. Because if more people used relatively standards-compliant browsers, then we could urge more designers and developers to create their sites with standards (instead of quirks). And as more designers and developers did that, they’d bump against still-unsolved standards compliance conundrums, enabling us to persuade browser makers to improve their standards compliance in those specific areas. Bit by bit, stone by stone, this edifice we could, and would, erect.

The code core of the 2001 browser upgrade campaign was the first instance of capability detection in place of browser detection. Here’s how it worked. After creating a valid web page, you’d insert this script in the head of your document or somewhere in your global JavaScript file:

if (!document.getElementById) {
window.location =
"http://www.webstandards.org/upgrade/"
}

We even provided details for various flavors of markup. In HTML 4 or XHTML 1 Transitional documents, it looked like this:

<script type="text/javascript" language="javascript">
<!-- //
if (!document.getElementById) {
window.location =
"http://www.webstandards.org/upgrade/"
}
// -->
</script>

In STRICT documents, you’d either use a global .js file, or insert this:

<script type="text/javascript">
<!-- //
if (!document.getElementById) {
window.location =
"http://www.webstandards.org/upgrade/"
}
// -->

You could also just as easily send visitors to an upgrade page on your own site:

if (!document.getElementById) {
window.location =
"http://www.yourdomain.com/yourpage.html"
}

Non-WaSP members (at the time) J. David Eisenberg, Tantek Çelik, and Jim Heid contributed technical advice and moral support to the effort. WaSP sysadmin Steven Champeon, the inventor of progressive enhancement, made it all work—under protest, bless him. (Steve correctly believed that all web content should always be available to all people and devices; therefore, in principle, he disliked the upgrade campaign, even though its double purpose was to hasten the arrival of truly standards-compliant browsers and to change front-end design and development from a disrespected world of hacks to a sustainable and professional craft. ((See what I did there? I’m still respectfully arguing with Steve in my head.)))

Discovering rudimentary DOM awareness or its absence in this fashion was the first time web developers had tested for capabilities instead of chasing the dragon in a perpetual and futile attempt to test for every possible browser flavor and version number. It was the grandparent, if you will, of today’s “cutting the mustard.” And it is analogous as well to the sensible responsive design practice of setting breakpoints for the content, instead of trying to set appropriate breakpoints for every possible device out there (including all the ones that haven’t been invented yet).

Which reminds us that the whole point of web standards was and is forward compatibility—to create content that will work not only in yesterday’s and today’s browsers and devices, but in all the wonderful devices that have yet to be invented, and for all the people of the world. You’re welcome.

—CHICAGO, Westin Chicago River Hotel, 1 September 2015


Hat tip: John Morrison

On Web Performance

Lara Hogan

GET READY for Lara Hogan, author of Designing For Performance, as she shares pretty much about everything you’ll need to know to design optimally performant front-end web experiences. It’s one of twelve essential sessions that make An Event Apart Austin 2015 the Southwest’s don’t-miss web design and development event of 2015.

Publishing v. Performance—or, The Soul of the Web

MY SOUL is in twain. Two principles on which clued-in web folk heartily agree are coming more and more often into conflict—a conflict most recently thrust into relief by discussions around the brilliant Vox Media team, publishers of The Verge.

The two principles are:

  1. Building performant websites is not only a key differentiator that separates successful sites from those which don’t get read; it’s also an ethical obligation, whose fulfillment falls mainly on developers, but can only happen with the buy-in of the whole team, from marketing to editorial, from advertising to design.
  2. Publishing and journalism are pillars of civilized society, and the opportunity to distribute news and information via the internet (and to let anyone who is willing to do the work become a publisher) has long been a foundational benefit of the web. As the sad, painful, slow-motion decline of traditional publishing and journalism is being offset by the rise of new, primarily web-based publications and news organizations, the need to sustain these new publications and organizations—to “pay for the content,” in popular parlance—is chiefly being borne by advertising…which, however, pays less and less and demands more and more as customers increasingly find ways to route around it.

The conflict between these two principles is best summarized, as is often the case, by the wonderfully succinct Jeremy Keith (author, HTML5 For Web Designers). In his 27 July post, “On The Verge,” Jeremy takes us through prior articles beginning with Nilay Patel’s Verge piece, “The Mobile Web Sucks,” in which Nilay blames browsers and a nonexistent realm he calls “the mobile web” for the slow performance of websites built with bloated frameworks and laden with fat, invasive ad platforms—like The Verge itself.

The Verge’s Web Sucks,” by Les Orchard, quickly countered Nilay’s piece, as Jeremy chronicles (“Les Orchard says what we’re all thinking”). Jeremy then points to a half-humorous letter of surrender posted by Vox Media’s developers, who announce their new Vox Media Performance Team in a piece facetiously declaring performance bankruptcy.

A survey of follow-up barbs and exchanges on Twitter concludes Jeremy’s piece (which you must read; do not settle for this sloppy summary). After describing everything that has so far been said, Mr Keith weighs in with his own opinion, and it’s what you might expect from a highly thoughtful, open-source-contributing, standards-flag-flying, creative developer:

I’m hearing an awful lot of false dichotomies here: either you can have a performant website or you have a business model based on advertising. …

Tracking and advertising scripts are today’s equivalent of pop-up windows. …

For such a young, supposedly-innovative industry, I’m often amazed at what people choose to treat as immovable, unchangeable, carved-in-stone issues. Bloated, invasive ad tracking isn’t a law of nature. It’s a choice. We can choose to change.

Me, I’m torn. As a 20-year-exponent of lean web development (yes, I know how pretentious that sounds), I absolutely believe that the web is for everybody, regardless of ability or device. The web’s strength lies precisely in its unique position as the world’s first universal platform. Tim Berners-Lee didn’t invent hypertext, and his (and his creation’s) genius doesn’t lie in the deployment of tags; it subsists in the principle that, developed rightly, content on the web is as accessible to the Nigerian farmer with a feature phone as it is to a wealthy American sporting this year’s device. I absolutely believe this. I’ve fought for it for too many years, alongside too many of you, to think otherwise.

And yet, as a 20-year publisher of independent content (and an advertising professional before that), I am equally certain that content requires funding as much as it demands research, motivation, talent, and nurturing. Somebody has to pay our editors, writers, journalists, designers, developers, and all the other specialtists whose passion and tears go into every chunk of worthwhile web content. Many of you reading this will feel I’m copping out here, so let me explain:

It may indeed be a false dichotomy that “either you can have a performant website or you have a business model based on advertising” but it is also a truth that advertisers demand more and more for their dollar. They want to know what page you read, how long you looked at it, where on the web you went next, and a thousand other invasive things that make thoughtful people everywhere uncomfortable—but are the price we currently pay to access the earth’s largest library.

I don’t like this, and I don’t do it in the magazine I publish, but A List Apart, as a direct consequence, will always lack certain resources to expand its offerings as quickly and richly as we’d like, or to pay staff and contributors at anything approaching the level that Vox Media, by accepting a different tradeoff, has achieved. (Let me also acknowledge ALA’s wonderful sponsors and our longtime partnership with The Deck ad network, lest I seem to speak from an ivory tower. Folks who’ve never had to pay for content cannot lay claim to moral authority on this issue; untested virtue is not, and so on.)

To be clear, Vox Media could not exist if its owners had made the decisions A List Apart made in terms of advertising—and Vox Media’s decisions about advertising are far better, in terms of consumer advocacy and privacy, than those made by most web publishing groups. Also to be clear, I don’t regret A List Apart’s decisions about advertising—they are right for us and our community.

I know and have worked alongside some of the designers, developers, and editors at Vox Media; you’d be proud to work with any of them. I know they are painfully aware of the toll advertising takes on their site’s performance; I know they are also doing some of the best editorial and publishing work currently being performed on the web—which is what happens when great teams from different disciplines get together to push boundaries and create something of value. This super team couldn’t do their super work without salaries, desks, and computers; acquiring those things meant coming to some compromise with the state of web advertising today. (And of course it was the owners, and not the employees, who made the precise compromise to which Vox Media currently adheres.)

Put a gun to my head, and I will take the same position as Jeremy Keith. I’ll even do it without a gun to my head, as my decisions as a publisher probably already make clear. And yet, two equally compelling urgencies in my core being—love of web content, and love of the web’s potential—make me hope that web and editorial teams can work with advertisers going forward, so that one day soon we can have amazing content, brilliantly presented, without the invasive bloat. In the words of another great web developer I know, “Hope is a dangerous currency—but it’s all I’ve got.”


Also published in Medium.

A byte saved is a follower earned: Web Performance Then And Now

A List Apart wreathFIFTEEN years ago this month, a plucky ALA staffer wrote “Much Ado About 5K,” an article on a contest created by Stewart Butterfield that challenged web designers and developers to build a complete website using less than five kilobytes of images and code.

As one group of modern web makers embraces mobile-first design and performance budgets, while another (the majority) worships at the altar of bigger, fatter, and slower, the 5K contest reminds us that a byte saved is a follower earned.

More in 15 Years Ago in ALA: Much Ado About 5K.