Responsive times two: essential new books from Ethan Marcotte & Karen McGrane

Responsive Design times two! New books from the geniuses, Ethan Marcotte and Karen McGrane.

IT WAS the early 2000s. The smoke from 9/11 was still poisoning my New York.

Karen McGrane was a brilliant young consultant who had built the IA practice at Razorfish while still in her early 20s, and was collaborating with my (now ex-)wife on some large, exciting projects for The New York Public Library. Ethan Marcotte was a Dreadlocks-hat-sporting kid I’d met in Cambridge through Dan Cederholm, with whom he sometimes collaborated on tricky, standards-based site designs. The first edition of my Designing With Web Standards was in the can. I figured that, like my previous book, it would sell about 10,000 copies and then vanish along with all the other forgotten web design books.

Nothing happened as I expected it to. The only thing I got right besides web standards was the desire to some day work with Karen, Ethan, and Dan—three dreams that, in different ways, eventually all came true. But nothing, not even the incredible experience of working with these luminaries, could have prepared me for the effect Ethan and Karen and Dan would have on our industry. Even less could I have guessed back then the announcement it’s my pleasure to make today:

Ethan Marcotte’s Responsive Design: Patterns and Principles and Karen McGrane’s Going Responsive are now available in our A Book Apart store.

It was thrilling to bring you Ethan and Karen’s first industry-changing A Book Apart books. Being allowed to bring you a second set of absolutely essential works on responsive design from these two great minds is a gift no publisher deserves, and for which I am truly grateful.

Building on the concepts in his groundbreaking Responsive Web Design, Ethan now guides you through developing and using design patterns so you can let your responsive layout reach more devices (and people) than ever before.

Karen McGrane effortlessly defined the principles of Content Strategy for Mobile. She’s helped dozens of teams effectively navigate responsive projects, from making the case to successful launch. Now, she pulls it all together to help you go responsive—wherever you are in the process.

Ebooks are available immediately and paperbacks ship next week. Buy Responsive Design: Patterns and Principles and Going Responsive together and save 15%! (Learn more.)

Save “Save For Web”

TWENTY years or so ago, Adobe Photoshop was, as its name suggests, primarily a tool for professional commercial photographers. Strange though it may seem for a company that now sells its software via a “Cloud” subscription service, the web was not at all on Adobe’s radar in those days. “Save For Web” was not even a widely held concept, let alone a Photoshop menu option.

This vacuum created an opportunity for independent developers and designers. Which is how the very talented Craig Hockenberry of Iconfactory and I came to release Furbo Filters, an indie shareware product that let designers prepare images for the web. It did a few other things as well, such as offering garish, psychedelic treatments you could apply to any image—not unlike the far more expensive (and also far, far more developed) Kai’s Power Tools. (And you know what they say: if you’re old enough to remember Kai’s Power Tools, there’s a Drop Shadow in your closet. But I digress.) Some of you may have used DeBabelizer to manage your web color palettes in those days when Adobe and Photoshop ignored the web. Some may even have used Furbo Filters.

Then Adobe created a “Save For Web” option (in Photoshop 5.5), and Furbo Filters’s beautiful market was gone in a moment. All that remains as a memento of that time and that product is the domain name, which is where Craig keeps his blog.

I was reminded of this during a workplace discussion about the seeming disappearance of “Save For Web” from modern Photoshop.

To be clear, “Save For Web” still exists in Photoshop CC 2015. But it has been rather awkwardly deprecated, as revealed through both UX (“Save For Web” no longer appears in the part of the interface where we’ve been trained to look for it for the past twenty years) and language: when we stumble onto “Save For Web” hiding under Export, after not finding it where we expect it, we’re presented with the words “Save For Web (Legacy),” clearly indicating that the feature is no longer a recommended part of today’s workflow.

Adobe explains: “Because Save for Web is built on the former ImageReady product (now discontinued), the code is too antiquated to maintain and develop new features.” (If Furbo Filters and DeBabelizer didn’t resurrect dead brain cells for some of you, I bet “ImageReady” did. Remember that one? Also, how scary is it for me that half the tools I’ve used in my career only exist today as Wikipedia entries?)

Instead of Save For Web, we’re to use Export: Export As…, which Adobe has built on its Generator platform. Stephen Nielson, writing on Jeff Tranberry’s blog for Adobe, explains:

Adobe Generator is a new, modern, and more efficient platform for exporting image assets from Photoshop. We have been building new capabilities on top of this platform for the past two years, including the new Export As and Device Preview features. The Generator platform allows us to build new, streamlined workflows and incorporate more efficient compression algorithms like PNGQuant into Photoshop.

The new Export As workflows are a complete redesign of how you export assets out of Photoshop. Export As has new capabilities like adding padding to an image and exporting shapes and paths to SVG. We also introduced the Quick Export option, which allows you to export an entire document or selected layers very quickly with no dialog.

Going forward, we will no longer develop new features in Save for Web, which is why it now is labeled as “Legacy”. Don’t worry; no features have been removed from it and we know there are critical workflows that still require Save for Web. However, Save for Web does not support, for example, new Artboard documents.

—Jeff Tranberry’s Digital Imaging Crawlspace, “Save for Web in Photoshop CC 2015

While I believe the Export As function is built on newer code, and I get that Adobe is committed to it, after months of use, I still spend a tremendous amount of time searching for Save For Web whenever I use Photoshop. And when I make myself use Export As, I still don’t feel that I’m getting the speed, power, and options I loved and came to depend on in Save For Web. This is a subjective reaction, of course, and “users hate change” is not a truth to which designers are immune—but I’ve yet to meet a designer who prefers the new tool and doesn’t feel confused, frustrated, and bummed out about the switch.

What I’m saying is, Craig, let’s talk.

Designing For Touch

Designing For Touch, by Josh Clark, new from A Book Apart

DESIGN’S future is in your hands. Designing For Touch by Josh Clark (foreword by Brad Frost) guides you through the new frontier in design.

I’ve been a fan of Josh Clark’s since before he was “Josh Clark”—back when he invented Couch to 5K, and gave it away with no strings (or copyrights or trademarks or patents, Lord help us) attached. And I’ve followed Josh’s career as an interaction design consultant, public speaker, and author. Guy’s got it all: intelligence, perspective, and the ability to not just communicate, but persuade. He’s a down-to-earth futurist with old-fashioned showmanship. And all that Josh Clark goodness has found its way into his new book.

Josh genuinely wants designers to not only keep up with the touchscreen but also to reimagine it. Designing For Touch will teach novice and seasoned designers alike about ergonomic demands (and rules of thumb), layout and sizing for all gadgets, an emerging gestural toolkit, and tactics to speed up interactions and keep gestures discoverable. You’ll get the know-how to design for interfaces that let your users touch—stretch, crumple, drag, flick—information itself. And the inspiration to take touch to the next level.

Our little publishing company proudly presents Designing For Touch by Mister Josh Clark. Go get your hands on it.

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 =

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 =
// -->

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

<script type="text/javascript">
<!-- //
if (!document.getElementById) {
window.location =
// -->

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

if (!document.getElementById) {
window.location =

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

Who’s Afraid of the Big Bad Medium?

IN 2003, long before he was a creative director at Twitter, Douglas Bowman wrote articles about design, posted case studies about his design projects, and shared his photography on his personal/business site,

A year previously, Doug had attained instant fame in standardista circles by recoding using CSS for layout. That sounds nonsensical nowadays, but in 2002, folks like me were still struggling to persuade our fellow web designers to use CSS, and not HTML tables, for layout. Leading web designers had begun seeing the light, and there had been a sudden profusion of blogs and personal sites that used CSS for layout, and whose markup strove to be semantic and to validate. But nobody had as yet applied web standards to a large commercial site—giving rise to the charge, among Luddite web designers, that standards-based design was “okay for blogs” but had no business on the “real” web.

Then Doug recoded with CSS, Mike Davidson did the same for, and all the old reactionary talking points were suddenly as dead as Generalissimo Franco—and the race was on to build a standards-compliant, open web across all content and application sectors.

IN THE PROCESS of helping to lead this sea change, Douglas Bowman became famous, and anybody who was anybody in web design began passionately reading his blog. And yet.

And yet, when Doug had a really big idea to share with our community, he published it on A List Apart, the magazine “for people who make websites.”

Did he do so because blogging was dead? Because the open web was in trouble? Of course not. He did it because publishing on A List Apart in 2003 allowed Doug to share his innovative design technique with the widest possible audience of his peers.

PUBLISHING in multiple venues is not new. Charles Dickens, the literary colossus of Victorian England, did it. (He also pioneered serial cross-cutting, the serial narrative, and the incorporation of audience feedback into his narrative—techniques that anticipated the suspense film, serial television narratives like Mad Men, and the modification of TV content in response to viewer feedback over the internet. But those are other, possibly more interesting, stories.)

Nobody said the open web was dead when Doug Bowman published “Sliding Doors of CSS” on A List Apart.

Nobody said the blog was dead when RSS readers made it easier to check the latest content from your favorite self-publishing authors without bothering to type their personal sites’ URLs into your browser’s address bar.

Forward thinkers at The New York Times did not complain when Mike Davidson’s Newsvine began republishing New York Times content; the paper brokered the deal. They were afraid to add comments to their articles on their own turf, and saw Newsvine as a perfect place to test how live reader feedback could fit into a New York Times world.

When Cameron Koczon noticed and named the new way we interact with online content (“a future in which content is no longer entrenched in websites, but floats in orbit around users”), smart writers, publishers, and content producers rejoiced at the idea of their words reaching more people more ways. Sure, it meant rethinking monetization; but content monetization on the web was mostly a broken race to the bottom, anyway, so who mourned the hastening demise of the “web user manually visits your site’s front page daily in hopes of finding new content” model? Not many of us.

By the time Cameron wrote “Orbital Content” in April of 2011, almost all visits to A List Apart and were triggered by tweets and other third-party posts. Folks were bookmarking Google and Twitter, not And that was just fine. If you wrote good content and structured it correctly, people would find it. Instead of navigating a front-page menu hierarchy that was obsolete before you finished installing the templates, folks in search of exactly your content would go directly to that content. And it was good.

So just why are we afraid of Medium? Aside from not soliciting or editing most of its content, and not paying most of its authors, how does it differ from all previous web publications, from Slate to The Verge? Why does publishing content on Medium (in addition to your personal site and other publications) herald, not just the final-final-final death of blogging (“Death of Blogging III: This Time It’s Personal”), but, even more alarmingly, the death of the open web?

You may think I exaggerate, but I’ve heard more than one respected colleague opine that publishing in Medium invalidates everything we independent content producers care about and represent; that it destroys all our good works with but one stroke of the Enter button.

I’ve even had that thought myself.

But isn’t the arrival of a new-model web publication like Medium proof that the web is alive and healthy, and spawning new forms of creativity and success?

And when the publisher of a personal site writes for Medium, is she really giving up on her own site? Couldn’t she be simply hoping to reach new readers?

(If she succeeds, some of those new readers might even visit her site, occasionally.)

Thanks to Bastian Allgeier for inspiring this post.

This piece was also published on Medium.

This article has been translated into Chinese.

Big Web Show № 127: Those Who Can Teach with Jared Spool

Jared Spool of Center Centre and User Interface Engineering

IN EPISODE № 127 of The Big Web Show, Jared Spool of User Interface Engineering and I discuss the goals and workings of Center Centre, a new school Jared cofounded with Dr Leslie Jensen Inman to create the next generation of industry-ready UX designers. Topics include “teaching students to learn,” what schools can and can’t do, working with partner companies, “Project Insanity,” and designing a program to make students industry-ready.


Center Centre
User Interface Engineering
UX Mobile Immersion
Unicorn Institute
Brain Sparks (UX writing by Jared and others)
All You Can Learn

Achieving Empathy for Institutions with Anil Dash

Anil Dash

IN BIG WEB SHOW № 115 on Mule Radio, I talk with Anil Dash, a hugely influential entrepreneur, blogger, and web geek living in NYC.

Things we discuss include:

How government, media, and tech shape the world, and how we can influence them in turn. Our first meeting at SXSW in 2002. How selling CMS systems teaches you the dysfunction at media companies and organizations. Working for the music industry at the dawn of Napster. RFP-EZ. The early days of blogging.

Designing websites for the government—the procurement problem. If we’re pouring all this time into social media, what do we want to get out of it? How big institutions work and how to have an impact on them. Living in “Joe’s Apartment.”

Why, until recently, federal agencies that wanted a blog couldn’t use WordPress or Tumblr and how the State Dept got on Tumblr. Achieving empathy for institutions. Being more thoughtful about what I share and who I amplify on social media. The launch of Thinkup, and a special offer exclusively for Big Web Show listeners.

Enjoy Big Web Show № 115.

Sponsored by An Event Apart, the design conference for people who make websites. Save $100 off any 2- or 3-day AEA event with discount code AEABWS.

Big Web Show № 98: Designer Debbie Millman

Debbie Millman

I CHAT with internet radio pioneer, design author, and brand maven Debbie Millman about broadcasting, writing, teaching, publishing, learning to be happy in your own skin, and the importance of early failure to long-term success and happiness. Enjoy Debbie Millman on The Big Web Show.

(Want more Debbie? Check Observer Media–Debbie’s legendary audio interviews with the likes of Jessica Walsh, Milton Glaser, Massimo Vignelli, Maria Popova, Stefan Sagmeister, Dave Eggers, Jen Bekman, Gary Hustwit, Tina Roth Eisenberg, Erik Spierkermann, Jessica Hische, and many more.)

The Lords of Vendorbation


noun : Unusable web-based intranet software foisted on large populations of users who have no say in the matter. For example, the “dynamic” website for your kid’s school, on which you can never find anything remotely useful—like her classroom or the names and email addresses of her teachers. Merely setting up an account can be a Borgesian ordeal minus the aesthetics.

Tried updating a driver’s license, registering a name change after a marriage, or accomplishing pretty much any task on a local, state, or federal website? Congratulations! You’ve been vendorbated. In ad sales? In publishing? Travel agent? Work in retail? Y’all get vendorbated a hundred times a day. Corporate America runs, not very well, on a diet of dysfunctional intranets sold by the lords of vendorbation.

Terrible food kills a restaurant. Terrible music ends a band’s career. But unspeakably terrible software begets imperial monopolies.

Wholesale contractual vendor lock-in between vendors of artless (but artfully initially priced) web software and the technologically unknowing who are their prey (for instance, your local school board) creates a mafia of mediocrity. Good designers and developers cannot penetrate this de-meritocracy. While they sweat to squeeze through needle’s eye after needle’s eye of baffling paperwork and absurd requirements, the vendorbators, who excel at precisely that paperwork and those requirements, breeze on in and lock ‘er down.

Vendorbation takes no heed of a user’s mental model; indeed, the very concept of a user’s mental model (or user’s needs) never enters the minds of those who create vendorbatory software. I say “create” rather than “design,” because design has less than nothing to do with how this genre of software gets slapped together (“developed”) and bloated over time (“updated”).

Vendorbatory product “design” decisions stem purely from contingencies and conveniences in the code framework, which itself is almost always an undocumented archipelago of spaghetti, spit, and duct tape started by one team and continued by others, with no guiding principle other than to “get it done” by an arbitrary deadline, such as the start of a new school year or the business cycle’s next quarter.

Masturbation, or so I have read, can be fun. Not so, vendorbation. It is a nightmare for everyone—from the beleaguered underpaid lumpen developers who toil in high-pressure silos; to the hapless bureaucrats who deserve partners but get predators instead; from the end users (parents, in our example) who can never do what they came to do or find what they want, and who most often feel stupid and blame themselves; to the constituents those users wish to serve—in our example, the children. Will no one think of the children?

Cha-ching! Like a zombie-driven un-merry-go-round spinning faster and faster as the innocents strapped to its hideous horses shriek silently, the vendorbation cycle rolls on and on, season after bloody season, dollar after undeserved dollar, error after error after error after error in saecula saeculorum.

Think it’s bad now? Wait till the lords of vendorbation start making their monstrosities “mobile.”

Doff of the neologist’s toque to Eric A. Meyer, whose cornpensation helped crystalize what to do with the bad feelings.