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.


Evolving Responsive Web Design

In What We Mean When We Say “responsive” and Defining Responsiveness, Lyza Danger Gardner and Jason Grigsby cut to the heart of a disagreement I had three years ago with Ethan Marcotte, the creator of Responsive Web Design and author of Responsive Web Design, a book I published in 2011.

Ethan told the world that Responsive Web Design required, and was defined by, fluid layouts, flexible images, and media queries. All three elements had to be present. If they weren’t using all three, you might be doing something interesting, but you were most definitely not doing Responsive Web Design.

Ethan invented all of this. Without him, we would likely be arguing whether it was time to consider 1280 pixels the new default fixed width for all desktop websites, and sending anything that wasn’t a desktop browser to a function- and content-limited “mobile site” whose URL began with the letter m. Ethan is a brilliant, multi-talented innovator; I am but the shadow of a hack. And yet, before he began creating his book, midway through the writing, and even a year after I published it, I continued to urge Ethan to rethink #RWD as “a bigger idea”—a concept rather than a single set of techniques.

I’m no genius. What I meant by “bigger idea” was limited to the notion that we’d one day be able to create responsive layouts with different techniques—so let’s not restrict the concept to a particular execution. I wasn’t thinking about other meanings of responsive, wasn’t considering problems of responsive content, and so on. I’m not that forward-thinking and it was three freaking years ago, come on.

I lost my gentle argument with Ethan, so the industry is having it now. And that’s just as it should be. Everything worked out for the best. Here’s why:

If Ethan hadn’t included three simple executional requirements as part of his definition, the concept might have quickly fallen by the wayside, as previous insights into the fluid nature of the web have done. The simplicity, elegance, and completeness of the package—here’s why, and here’s how—sold the idea to thousands of designers and developers, whose work and advocacy in turn sold it to hundreds of thousands more. This wouldn’t have happened if Ethan had promoted a more amorphous notion. Our world wouldn’t have changed overnight if developers had had too much to think about. Cutting to the heart of things and keeping it simple was as powerful a creative act on Ethan’s part as the “discovery” of #RWD itself.

We’ve only become ready to think about things like “responsible” responsive design, adaptive content, and a standard approach to responsive images now that we have built our share of first-generation responsive sites, and encountered the problems that led to the additional pondering. Baby steps. Brilliant baby steps.

Some commenters want to use initial-capped Responsive Web Design to mean responsive design as Ethan first defined it, and lowercase responsive design to mean an amorphous matrix of exciting and evolving design thinking. Lyza says soon we’ll stop saying Responsive altogether, a conclusion Andy Clarke reached three years ago.

Me, I like that Ethan stuck to his guns, and that the classical definition will always be out there, regardless of how web design evolves thanks to it. Kind of like there’s HTML 5, a defined and scoped W3C specification, and HTML living standard, an evolving activity. Our industry needs roots and wings, and, lucky us, we’ve got ‘em both.

It’s 2014. Is Web Design Dead?

IN A RECENT article on his website, Web Standards Killed the HTML Star, designer Jeff Croft laments the passing of the “HTML and CSS ‘guru’” as a viable long-term professional position and urges his fellow web design generalists to “diversify or die.”

The reason the Web Standards Movement mattered was that the browsers sucked. The stated goal of the Movement was to get browser makers on board with web standards such that all of our jobs as developers would be easier.

What we may not have realized is that once the browsers don’t suck, being an HTML and CSS “guru” isn’t really a very marketable skillset. 80% of what made us useful was the way we knew all the quirks and intracries of the browsers. Guess what? Those are all gone. And if they’re not, they will be in the very near future. Then what?

From my perspective, the web standards struggle consisted of two phases of persuasion: first we convinced browser makers that it was in their interest to support current HTML, CSS, and JavaScript specifications completely and accurately; then we evangelized the accessibility, findability, and portability benefits of lean semantic markup and progressive enhancement to our colleagues who made websites and their clients.

Evangelizing true compliance, not mastering workarounds for compliance failures, was always the point. Evangelizing was key. Browsers weren’t going to stay standards compliant if nobody made use of that compliance; likewise, W3C specifications weren’t going to advance unless designers seized hold of technologies like CSS to push type and layout on the web as far as they could go—and then complain that they didn’t go far enough.

It took a village of passionate browser engineers, designers, front-end developers, and generalists to bring us to the web we have today. Does the movement’s success mean that many of those who led it will become jobless, like Bolsheviks after the Russian Revolution?

Jeff Croft is correct when he says “the goal of the Web Standards Movement was for it to not have to exist.” But we should take this a step further. The goal of the web standards movement was to remove needless complexity and absurdity from the process of creating websites so we could focus our attention where it should be: on design, content, and experience. Evangelizing standards to browser makers and our fellow designers was not a career path, and was never intended to be—any more than aiding a wounded buddy turns a soldier into a physician.

Interestingly, once web standards made the web safe for design, content, and experience, the web’s capabilities—and, thus, the work required to create certain kinds of websites—started becoming more and more complex. To help cut down on that complexity, some front-end developers began sharing chunks of code (from Eric Meyer’s CSS Reset to Mark Otto’s Bootstrap) which paradoxically set in motion another level of complexity: as Jeff Croft points out, familiarity with these and dozens of other tools is now expected of job applicants who could once get hired on nothing more than a solid understanding of HTML and CSS plus a little JavaScript.

HTML “gurudom” was never a career path for anyone, aside, maybe, from a couple of talented authors. Same thing with CSS trickery. Doing black magic with CSS3 can get you a slot on a web design conference stage, but it’s not a career path or proper goal for most web designers.

Fascinatingly, to me, anyway, while many of us prefer to concentrate on design, content, and experience, it continues to be necessary to remind our work comrades (or inform younguns) about web standards, accessibility, and progressive enhancement. When a site like Facebook stops functioning when a script forgets to load, that is a failure of education and understanding on the part of those who created the site; all of us have a stake in reaching out to our fellow developers to make sure that, in addition to the new fancy tricks they’ve mastered, they also learn the basics of web standards, without which our whole shared system implodes.

This doesn’t mean “go be an HTML guru.” It does mean cherish the lessons of the recent past, and share them with those who missed them (or missed the point). Wisdom is not a job, but it is always an asset.

Never fear, web design generalists: many companies and organizations require your services and always will—from universities still seeking “webmasters,” to startups seeking seasoned folks with multiple areas of understanding to direct and coordinate the activities of younger specialists. But if jack-of-all web work is feeling stale, now may be the time to up your game as a graphic designer, or experience designer, or front end developer. “Diversify or die” may be overstating things a bit. But “follow the path you love” will always be good advice.

This is a Website

LAST NIGHT at dinner, my friend Tantek Çelik (and if you don’t know who he is, learn the history of your craft) lamented that there was no longer any innovation in blogging—and hadn’t been for years. I replied by asking if anyone was still blogging.

Me, I regret the day I started calling what I do here “blogging.” When I launched this website in 1995, I thought of what I was doing as “writing and publishing,” which is the case. But in the early 2000s, after Rebecca Blood’s book came out, I succumbed to peer pressure. Not from Rebecca: Rebecca is awesome, and still going strong. The peer pressure came from the zeitgeist.

Nobody in the mainstream had noticed a decade of independent content producers, but they woke up when someone started calling it “blogging.” By the way, what an appalling word that is. Blogging. Yecch. I held my nose at the time. But I also held my tongue. If calling your activity blogging was the price of recognition and attention, so be it, my younger self said to itself.

Did Twitter and Facebook kill blogging? Was it withdrawal of the mainstream spotlight? Did people stop independently writing and publishing on the web because it was too much work for too little attention and gain? Or did they discover that, after all, they mostly had nothing to say?

Blogging may have been a fad, a semi-comic emblem of a time, like CB Radio and disco dancing, but independent writing and publishing is not. Sharing ideas and passions on the only free medium the world has known is not a fad or joke.

We were struggling, whether we knew it or not, to found a more fluid society. A place where everyone, not just appointed apologists for the status quo, could be heard. That dream need not die. It matters more now than ever.

Yes, recycling other people’s recycling of other people’s recycling of cat gifs is fun and easy on Tumblr. Yes, rubbing out a good bon mot on Twitter can satisfy one’s ego and rekindle a wistful remembrance of meaning. Yes, these things are still fine to do. But they are not all we can do on this web. This is our web. Let us not surrender it so easily to new corporate masters.

Keep blogging in the free world.

Blue Beanie Day is Coming!

A sea of blue hats

ALL IT TAKES is a toque and a dream.

Join your fellow web designers and developers around the world on Saturday, 30 November 2013, as we march in virtual solidarity in support of web standards.

The countdown to this worldwide celebration begins today, with the opening of the Blue Beanie Day 2013 photo pool on good old Flickr.com. Read more at the new official home of Blue Beanie Day online, bluebeanieday.tumblr.com.

The Lords of Vendorbation

Vendorbation
ven·dor·ba·tion
/ˈvendər-ˈbā-shən/

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.

A List Apart Issue No. 367: Apple’s Vexing Viewport

In A List Apart Issue No. 367, Peter-Paul Koch, Lyza Danger Gardner, Luke Wroblewski, and Stephanie Rieger explain why Apple’s new iPad Mini creates a vexing situation for designers and developers who create flexible, multi-device experiences.

Each week, new devices appear with varying screen sizes, pixel densities, input types, and more. As developers and designers, we agree to use standards to mark up, style, and program what we create. Browser makers in turn agree to support those standards and set defaults appropriately, so we can hold up our end of the deal. This agreement has never been more important.

That’s why it hurts when a device or browser maker does something that goes against our agreement—especially when they’re a visible and trusted friend of the web like Apple. Read Vexing Viewports and contribute to the discussion.

This issue of the magazine also marks the departure of Jason Santa Maria as creative director after seven years of brilliant design and support.

Jason’s elegant redesign of A List Apart and its brand in 2005, together with the master stroke of bringing in Kevin Cornell as illustrator, brought the magazine new fame, new readers, and new respect. Over seven great years, his attention to detail, lack of pretension, and cheerful, can-do attitude has made working on ALA a pleasure. Jason was also a key member of the strategic team that envisioned ALA’s upcoming content expansion—about which, more will be revealed when the site relaunches in January.

Jason will continue at ALA as a contributing writer and as designer of A Book Apart (“brief books for people who make websites”), of which he is also a co-founder.

In Search of a Genuine Web Aesthetic & Designing For High Density Displays

IN A VERY special issue of A List Apart for people who make websites, Paul Robert Lloyd asks us to put the “design” back in “responsive design” and seek out a genuine web aesthetic. And Dave Rupert shares ways to be thoughtful, not knee-jerk, about high-pixel-density displays, in Mo’ Pixels Mo’ Problems.


Illustration by Kevin Cornell for A List Apart