Category Archives: Responsibility

140 Characters is a Joke

THERE IS ALWAYS more to the story than what we are told. I am not omniscient. It is better to light a single candle than to join a lynch mob. Other people’s behavior is not my business. Truth is hard, epigrams are easy. Anything worth saying takes more than 140 characters. Blogging’s not dead. F____ the 140 character morality police.

Readlists: behind the scenes

FROM THE HOME PAGE of today’s newly announced, totally disruptive, completely free product powered by Readability: “What’s a Readlist? A group of web pages—articles, recipes, course materials, anything—bundled into an e-book you can send to your Kindle, iPad, or iPhone.”

For some time now, people who miss the point have seen Readability as an app that competes in the read-it-later space. That’s like viewing Andy Warhol as a failed advertising art director. Readability is a platform that radically rethinks how we consume, and who pays for, web content. It monetizes content for authors and its technology is available to all via the API. It scares designers, angers some advertisers. Its transformative potential is huge. Readlists are the latest free product to manifest some of that potential.

With Readlist, anyone can create ebooks out of existing web content. It’s easy. Sign in with your Readability account or sign up for one, and start making books of your favorite web articles.

There are still some bugs being worked out, but hey.

I was honored to beta test the product and create one of the first Readlists, along with Erin Kissane, Anil Dash, Aaron Lammer, David Sleight, and Chris Dary.

Disclaimer: I am on the advisory board of Readability and cofounded The Deck advertising network with Jim Coudal and Jason Fried. Readability removes clutter (including ads) from the reading experience; The Deck sells ads. Conflict of interest? Here’s another: I design content websites so as to make Readability unnecessary (because I design for readers); yet I strongly support Readability as a platform and above all as a web idea that is at least 15 years overdue. Either designers will design for their end-users, or third-party apps will remove designers from the transaction. As a designer, I’m not afraid of that. Rather, it inspires me.

Enjoy Readlists.

A List Apart: Responsive Images: How they Almost Worked and What We Need

RESPONSIVE WEB DESIGNERS, don’t miss Mat Marquis’ essential article in today’s A LIST APART, for people who make websites: Responsive Images: How they Almost Worked and What We Need. Mat shows why responsive images as we currently use them don’t quite cut it – and shares a way forward that involves the creation of a shiny new HTML element.


Illustration by Kevin Cornell for A List Apart Magazine.

State of the web: of apps, devices, and breakpoints

IN The ‘trouble’ with Android, Stephanie Rieger points out the ludicrous number of Android screen sizes on a typical UK client’s website and comes to this conclusion:

If … you have built your mobile site using fixed widths (believing that you’ve designed to suit the most ‘popular’ screen size), or are planning to serve specific sites to specific devices based on detection of screen size, Android’s settings should serve to reconfirm how counterproductive a practice this can be. Designing to fixed screen sizes is in fact never a good idea…there is just too much variation, even amongst ‘popular’ devices. Alternatively, attempting to track, calculate, and adjust layout dimensions dynamically to suit user-configured settings or serendipitous conditions is just asking for trouble.

I urge you to read the entire article—it’s brief yet filled with rich chocolatey goodness.

Responding to it, Marc Drummond concludes that responsive web design default breakpoints are dead and urges designers to “use awkwardness as your guideline, not ephemeral default device widths” and return to fluid design. (I believe he may actually be thinking of liquid layout—the kind we practiced back in the early mid-1990s when cross-platform and multi-manufacturer desktop screen sizes and pixel-per-inch ratios—not to mention strong user font, size, and color preference options—made fixed-width layout design challenging if not impossible. As I understand fluid design, it is merely another word for responsive design, in that it relies on CSS3 media queries set to breakpoints.)

We’ve lost our compass

Rieger and Drummond are hardly alone in feeling that “our existing standards, workflows, and infrastructure” cannot support “today’s incredibly exciting yet overwhelming world of connected digital devices” (futurefriend.ly) and that something new must be done to move the web forward. And of course ppk has been warning us about the multiplicity of platforms and viewports on mobile since 2009.

Agreed: that is an exciting and challenging time; that fixed width layouts do not address, and adaptive layouts (multiple fixed-width layouts set to common breakpoints) do not go far enough in addressing, the challenges posed by our current plethora of mobile screen sizes, zoom settings, embedded views (i.e. “browser” windows inside app windows, often with additional chrome) and what Rieger calls “the unintended consequences” that occur as these various settings clash in ways their creators could not have anticipated.

As consumers, we’ve all had the experience of seeing the wrong layout at the wrong time. (Think of a site with both mobile and desktop versions—whether these versions are triggered by CSS3 media queries or JavaScript and back-end magic is beside the point because technology is beside the point—good user experience is all this is supposed to be about. On a Twitter app on a mobile device, the user follows a link; the link opens in the browser built into the Twitter app. Which version of the site does the user see? The mobile one or the desktop? Often it is the desktop, and that can be a problem if the app’s version of the browser does not permit zoom. Even if it is a mobile version, it may be the wrong mobile version, or it may not fit comfortably inside the app’s browser window.) Considering our own experiences and reviewing Rieger’s chart, it is easy to share Drummond’s conclusion that breakpoints are dead and that all sites should be designed as minimally as possible.

If breakpoints are dead, responsive design is dead

Of course, if breakpoints are dead, responsive design is dead, because responsive design relies on breakpoints both in creative workflow and as a key to establishing user-need-and-context-based master layouts, i.e. a minimal layout for the user with a tiny screen and not much bandwidth, a more fleshed-out one for the netbook user, and so on.

But responsive design is not dead; it has only begun. It is not a panacea but was never intended to be. It is simply the beginnings of an approach.

I respect those colleagues who say breakpoints are dead, understand how they reached this conclusion, and am eager to see where it takes them in the coming months as they experiment with new methods, perhaps developing wonderful and unforeseen best practices. I hope design will be a brilliant part of these new methods, not something that gets abandoned to create a bland but workable lightweight experience for all.

But I also believe it is possible to draw a different conclusion from the same data. It is even possible, I believe, to say the present data doesn’t matter—at least not in the long run.

Tale of the chart

There was a time in the late 1990s when industrious web designers showed how atrocious CSS support was in browsers. Eric Meyer’s Master Compatability Chart for Web Review, formerly at http://www.webreview.com/pub/wr/style/mastergrid.html, was one of the best, but is no longer available for your historical viewing pleasure—not even at the mighty Wayback Machine. That’s too bad, as it would have perfectly illustrated my point. The chart used a variety of colors to show how each detail of the entire CSS specification was or was not supported (and if supported, whether it was supported correctly and completely, partially and correctly, partially and somewhat incorrectly, or completely incorrectly) in every browser which was available at the time, including, if memory serves, close to a dozen versions of Netscape, Explorer, and Opera.

Looking at that chart induced nausea and vertigo. It was easy to draw the conclusion that CSS wasn’t ready for primetime. (That was the correct conclusion at the time.) It was also easy to look at the table and decide that table layouts and font tags were the way to go.

That’s what most designers who even bothered looking at Eric’s chart decided, but a few (Eric and me included) drew a completely other inference. Instead of trying to memorize all the things that could go wrong in each browser, we created general rules for what worked across all browsers (e.g. font-size in px, floats for layout) and advocated design based on the things that work. This, I believe, is exactly what the futurefriend.ly and Move the Web Forward folks are doing now: trying to figure out commonalities instead of bogging down in details. (This is why some in our community have labeled futurefriend.ly and Move the Web Forward “WaSP II.”)

The other inference Eric, I, and others in the 1990s drew from Eric’s chart was that browser makers must be petitioned to support CSS accurately and correctly. We and many of you reading this engaged in said petitioning, and thanks largely to help from with the browser engineering community (from people like Tantek Çelik and Chris Wilson and organizations like Mozilla) it came to pass.

Of mice and markets

We cannot, of course, petition all the makers of, say, Android devices to agree to a set of standard breakpoints, because there are over 500 different Android devices out there, many of which will fail in the coming months—or if not outright fail, simply be replaced in the course of planned obsolescence AKA upgrading that drives the hardware segment. And each new product will in turn introduce new incompatibilities (AKA “features”).

In the short run it’s going to be hell, just as the browser wars and their lack of support for common standards were hell. But it is the short run.

500 standards is no standard. Give a consumer 500 choices and the price-driven consumer picks what comes with her plan, while the selective consumer begins gravitating toward a handful of emerging market leaders. Eventually this nutty market will stabilize around a few winning Android platforms (e.g. Kindle Fire) and common breakpoints will emerge. What The Web Standards Project achieved with browser makers, the market will achieve with phones.

Until that time, designers certain can abandon breakpoints if they can find a way to do good design under purely fluid conditions—design that pleases the user, satisfies the client, and moves the industry forward aesthetically. But designers who persist in responsive or even adaptive design based on iPhone, iPad, and leading Android breakpoints will help accelerate the settling out of the market and its resolution toward a semi-standard set of viewports. This I believe.

When I see fragmentation, I remind myself that it is unsustainable by its very nature, and that standards always emerge, whether through community action, market struggle, or some combination of the two. This is a frustrating time to be a web designer, but it’s also the most exciting time in ten years. We are on the edge of something very new. Some of us will get there via all new thinking, and others through a combination of new and classic approaches. Happy New Year, web designers!

Say No to SOPA!

A LIST APART strongly opposes USHR 3261 AKA the Stop Online Piracy Act (SOPA), an ill-conceived lobbyist-driven piece of legislation that is technically impossible to enforce, cripplingly burdensome to support, and would, without hyperbole, destroy the internet as we know it.

SOPA approaches the problem of content piracy with a broad brush, lights that brush on fire, and soaks the whole web in gasoline. Learn why SOPA must not pass, and find out what you can do to help stop it.

A List Apart: Articles: Say No to SOPA.


Illustration by Kevin Cornell for A List Apart Magazine.

“Mobile” versus “Small Screen”

As we try to become more responsive with our designs, a lot of attention has been focused on providing “mobile” styles. We’ve all been adding viewport meta tags to our templates and @media screen and (max-device-width: 480px) to our stylesheets.

It’s very tempting (and scope-friendly) to tell a client that we can adjust their site for mobile users, when much of the time what we’re actually doing is simply adjusting a design for small screens.

…Simply adjusting a design for a smaller screen and calling it “mobile” does a disservice to both mobile users and developers. Making link targets bigger and image sizes smaller does help the mobile user, but it only addresses the surface issues of usability and readability. It doesn’t address their need to do things easily and quickly.

via It’s the Little Things – “Mobile” versus “Small Screen”.

You are all in publishing!

ON SUNDAY, while leading a discussion on the future of web design and publishing, I noticed a slightly confused look appearing on some faces in the audience. The discussion had been billed as “Jeffrey Zeldman’s Awesome Internet Design Panel,” and I thought perhaps there was a disconnect for some in the audience between “design” and such topics as where content comes from and who pays for it.

So I asked, “Who here is in publishing?”

A few hands were gently raised.

Uh-huh. “And how many of you work on the web?”

Every right hand in the room shot up.

“You are all in publishing,” I explained.

Now, I like a good rounded corner talk as much as the next designer. I’ve given my share of them. Also of line height and measure, color and contrast, how to design things that don’t work in old versions of Internet Explorer, and so on. In the practice of web and interaction design, there will always be a place for craft discussions—for craft is execution, and ideas without execution are songs without music, meaningless.

But right now (and always) there is a need for design to also be about the big strategic issues. And right now, as much as design is wrestling with open vs. proprietary formats and the old challenges of new devices, design is also very much in the service of applications and publishing. Who gets content, who pays for it, how it is distributed (and how evenly), the balance between broadcast and conversation, editor and user—these are the issues of this moment, and it is designers even more than editors who will answer these riddles.

2010: The Year in Web Standards

WHAT A YEAR 2010 has been. It was the year HTML5 and CSS3 broke wide; the year the iPad, iPhone, and Android led designers down the contradictory paths of proprietary application design and standards-based mobile web application design—in both cases focused on user needs, simplicity, and new ways of interacting thanks to small screens and touch-sensitive surfaces.

It was the third year in a row that everyone was talking about content strategy and designers refused to “just comp something up” without first conducting research and developing a user experience strategy.

CSS3 media queries plus fluid grids and flexible images gave birth to responsive web design (thanks, Beep!). Internet Explorer 9 (that’s right, the browser by Microsoft we’ve spent years grousing about) kicked ass on web standards, inspiring a 10K Apart contest that celebrated what designers and developers could achieve with just 10K of standards-compliant HTML, CSS, and JavaScript. IE9 also kicked ass on type rendering, stimulating debates as to which platform offers the best reading experience for the first time since Macintosh System 7.

Even outside the newest, best browsers, things were better than ever. Modernizr and eCSStender brought advanced selectors and @font-face to archaic browsers (not to mention HTML5 and SVG, in the case of Modernizr). Tim Murtaugh and Mike Pick’s HTML5 Reset and Paul Irish’s HTML5 Boilerplate gave us clean starting points for HTML5- and CSS3-powered sites.

Web fonts were everywhere—from the W3C to small personal and large commercial websites—thanks to pioneering syntax constructions by Paul Irish and Richard Fink, fine open-source products like the Font Squirrel @Font-Face Generator, open-source liberal font licensing like FontSpring’s, and terrific service platforms led by Typekit and including Fontdeck, Webtype, Typotheque, and Kernest.

Print continued its move to networked screens. iPhone found a worthy adversary in Android. Webkit was ubiquitous.

Insights into the new spirit of web design, from a wide variety of extremely smart people, can be seen and heard on The Big Web Show, which Dan Benjamin and I started this year (and which won Video Podcast of the Year in the 2010 .net Awards), on Dan’s other shows on the 5by5 network, on the Workers of the Web podcast by Alan Houser and Eric Anderson, and of course in A List Apart for people who make websites.

Zeldman.com: The Year in Review

A few things I wrote here at zeldman.com this year (some related to web standards and design, some not) may be worth reviewing:

iPad as the New Flash 17 October 2010
Masturbatory novelty is not a business strategy.
Flash, iPad, and Standards 1 February 2010
Lack of Flash in the iPad (and before that, in the iPhone) is a win for accessible, standards-based design. Not because Flash is bad, but because the increasing popularity of devices that don’t support Flash is going to force recalcitrant web developers to build the semantic HTML layer first.
An InDesign for HTML and CSS? 5 July 2010
while our current tools can certainly stand improvement, no company will ever create “the modern day equivalent of Illustrator and PageMaker for CSS, HTML5 and JavaScript.” The assumption that a such thing is possible suggests a lack of understanding.
Stop Chasing Followers 21 April 2010
The web is not a game of “eyeballs.” Never has been, never will be. Influence matters, numbers don’t.
Crowdsourcing Dickens 23 March 2010
Like it says.
My Love/Hate Affair with Typekit 22 March 2010
Like it says.
You Cannot Copyright A Tweet 25 February 2010
Like it says.
Free Advice: Show Up Early 5 February 2010
Love means never having to say you’re sorry, but client services means apologizing every five minutes. Give yourself one less thing to be sorry for. Take some free advice. Show up often, and show up early.

Outside Reading

A few things I wrote elsewhere might repay your interest as well:

The Future of Web Standards 26 September, for .net Magazine
Cheap, complex devices such as the iPhone and the Droid have come along at precisely the moment when HTML5, CSS3 and web fonts are ready for action; when standards-based web development is no longer relegated to the fringe; and when web designers, no longer content to merely decorate screens, are crafting provocative, multi-platform experiences. Is this the dawn of a new web?
Style vs. Design written in 1999 and slightly revised in 2005, for Adobe
When Style is a fetish, sites confuse visitors, hurting users and the companies that paid for the sites. When designers don’t start by asking who will use the site, and what they will use it for, we get meaningless eye candy that gives beauty a bad name.

Happy New Year, all!