Laying Pipe

The Pipeline inaugural podcast

Dan Benjamin and yours truly discuss the secret history of blogging, transitioning from freelance to agency, the story behind the web standards movement, the launch of A Book Apart and its first title, HTML5 For Web Designers by Jeremy Keith, the trajectory of content management systems, managing the growth of a design business, and more in the inaugural episode of the Pipeline.

Flash, iPad, Standards

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. Additional layers of Flash UX can then be optionally added in, just as, in proper, accessible, standards-based development, JavaScript UX enhancements are added only after we verify that the site works without them.

As the percentage of web users on non-Flash-capable platforms grows, developers who currently create Flash experiences with no fallbacks will have to rethink their strategy and start with the basics before adding a Flash layer. They will need to ensure that content and experience are delivered with or without Flash.

Developers always should have done this, but some don’t. For those who don’t, the growing percentage of users on non-Flash-capable platforms is a wake-up call to get the basics right first.

Whither, plug-ins?

Flash won’t die tomorrow, but plug-in technology is on its way out.

Plug-in technology made sense when web browsing was the province of geeks. It was a brilliant solution to the question of how to extend the user experience beyond what HTML allowed. People who were used to extending their PC via third-party hardware, and jacking the capabilities of their operating system via third-party spell checkers, font managers, and more, intuitively grasped how to boost their browser’s prowess by downloading and updating plug-ins.

But tomorrow’s computing systems, heralded by the iPhone, are not for DIYers. You don’t add Default Folder or FontExplorer X Pro to your iPhone, you don’t choose your iPhone’s browser, and you don’t install plug-ins in your iPhone’s browser. This lack of extensibility may not please the Slashdot crowd but it’s the future of computing and browsing. The bulk of humanity doesn’t want a computing experience it can tinker with; it wants a computing experience that works.

HTML5, with its built-in support for video and audio, plays perfectly into this new model of computing and browsing; small wonder that Google and Apple’s browsers support these HTML5 features.

The power shifts

Google not only makes a browser, a phone, an OS, and Google Docs, it also owns a tremendous amount of video content that can be converted to play in HTML5, sans plug-in. Apple not only makes Macs, iPhones, and iPads, it is also among the largest retail distributors of video and audio content.

Over the weekend, a lot of people were doing the math, and there was panic at Adobe and schadenfreude elsewhere. Apple and Adobe invented modern publishing together in the 1980s, and they’ve been fighting like an old unmarried couple ever since, but Apple’s decision to omit Flash from the iPad isn’t about revenge, it’s about delivering a stable platform. And with HTML5 here, the tea leaves are easy to read. Developers who supplement Flash with HTML5 may soon tire of Flash—but Adobe has a brief but golden opportunity to create the tools with which rich HTML5 content is created. Let’s see if they figure that out.

Discussion has moved to a new thread.

Posthumous Hosting and Digital Culture

THE DEATHS of Leslie Harpold and Brad Graham, in addition to being tragic and horrible and sad, have highlighted the questionable long-term viability of blogs, personal sites, and web magazines as legitimate artistic and literary expressions. (Read this, by Rogers Cadenhead.)

Cool URIs don’t change, they just fade away. When you die, nobody pays your hosting company, and your work disappears. Like that.

Now, not every blog post or “Top 10 Ways to Make Money on the Internet” piece deserves to live forever. But there’s gold among the dross, and there are web publications that we would do well to preserve for historical purposes. We are not clairvoyants, so we cannot say which fledgling, presently little-read web publications will matter to future historians. Thus logic and the cultural imperative urge us to preserve them all. But how?

The death of the good in the jaws of time is not limited to internet publications, of course. Film decays, books (even really good ones) constantly go out of print, digital formats perish. Recorded music that does not immediately find an audience disappears from the earth.

Digital subscriptions were supposed to replace microfilm, but American libraries, which knew we were racing toward recession years before the actual global crisis came, stopped being able to pay for digital newspaper and magazine descriptions nearly a decade ago. Many also (even fancy, famous ones) can no longer collect—or can only collect in a limited fashion. Historians and scholars have access to every issue of every newspaper and journal written during the civil rights struggle of the 1960s, but can access only a comparative handful of papers covering the election of Barack Obama.

Thanks to budget shortfalls and format wars, our traditional media, literature, and arts are perishing faster than ever before. Nothing conceived by the human mind, except Heaven and nuclear winter, is eternal.

Still, when it comes to instant disposability, web stuff is in a category all its own.

Unlike with other digital expressions, format is not the problem: HTML, CSS, and backward-compatible web browsers will be with us forever. The problem is, authors pay for their own hosting.

(There are other problems: the total creative output of someone I follow is likely distributed across multiple social networks as well as a personal site and Twitter feed. How to connect those dots when the person has passed on? But let’s leave that to the side for the moment.)

A suggestion for a business. Sooner or later, some hosting company is going to figure out that it can provide a service and make a killing (as it were) by offering ten-, twenty-, and hundred-year packets of posthumous hosting.

A hundred years is not eternity, but you are not Shakespeare, and it’s a start.


Philadelphia is a happening little city, the cradle of liberty, and the site of Happy Cog East. It’s also a city that gets unfairly overlooked—like a beauty whose sisters are supermodels. But I have a plan.

I want to rebrand Philadelphia as !adelphia.

I can see the logo. I can see half a dozen ad campaigns, some of them even good. I see a decent theme-line and sense that a much better one is out there. I see commercials and bus posters, I hear tourist board tie-ins and radio spots. I see Kottke, Joe Clarke, and Design Observer trashing the campaign on various intellectual and typographic grounds. I see contests where designers submit how they would have done the logo.

Maybe it’s the meds talking, but I think we’re on to something. Viva !adelphia!

Why Standards Fail

Back in 2000, CSS co-creator Bert Bos set out to explain the W3C’s design principles—“to make explicit what the developers in the various W3C working groups mean when they invoke words like efficiency, maintainability, accessibility, extensibility, learnability, simplicity, [and] longevity….”

Eventually published in 2003, the essay, although ostensibly concerned with explaining W3C working group principles to the uninitiated, actually articulates the key principle that separates great design from the muck we normally wade through. It also serves as a warning to Bert’s fellow W3C wizards not to seek the dark magic of abstract purity at the expense of the common good. Tragically for these wizards, and for we who use their technologies, it is a warning some developers of W3C specifications continue to overlook.

Design is for people

In his introduction, Bert summarizes the humanistic value that is supposed to be at the core of every web standard:

Contrary to appearances, the W3C specifications are for the most part not designed for computers, but for people. … Most of the formats are in fact compromises between human-readability and computer efficiency….

But why do we want people to read them at all? Because all our specs are incomplete. Because people, usually other people than the original developers, have to add to them….

For the same reason we try to keep the specifications of reasonable size. They must describe a useful chunk of technology, but not one that is too large for an individual to understand.

Over the succeeding 25 web pages (the article is chunked out in pamphlet-sized pages, each devoted to a single principle such as “maintainability” and “robustness”) Bert clearly, plainly, and humbly articulates a series of rather profound ideas that are key to the web’s growth and that might apply equally admirably to realms of human endeavor beyond the web.

For instance, in the page entitled “Use What Is There,” Bert says:

The Web now runs on HTML, HTTP and URLs, none of which existed before the ’90s. But it isn’t just because of the quality of these new formats and protocols that the Web took off. In fact, the original HTTP was a worse protocol than, e.g., Gopher or FTP in its capabilities….

And that fact shows nicely what made the Web possible at all: it didn’t try to replace things that already worked, it only added new modules, that fit in the existing infrastructure. …

And nowadays (the year 2000), it may look like everything is XML and HTTP, but that impression is only because the “old” stuff is so well integrated that you forget about it: there is no replacement for e-mail or Usenet, for JPEG or MPEG, and many other essential parts of the Web.

He then warns:

There is, unfortunately, a tendency in every standards organization, W3C not excluded, to replace everything that was created by others with things developed in-house. It is the not-invented-here syndrome, a feeling that things that were not developed “for the Web” are somehow inferior. And that “we” can do better than “them.” But even if that is true, maybe the improvement still isn’t worth spending a working group’s resources on.

Shrinkage and seduction

In his gentle way, Bert seems to be speaking directly to his W3C peers, who may not always share his and Håkon‘s humanism. For, despite what designers new to CSS, struggling for the first time with concepts like “float” and the box model may think, Bert and Håkon designed the web’s layout language to be easy to learn, teach, implement, maintain, and (eventually) extend. They also designed CSS not to overwhelm the newcomer with advanced power at the cost of profound complexity. (“CSS stops short of even more powerful features that programmers use in their programming languages: macros, variables, symbolic constants, conditionals, expressions over variables, etc. That is because these things give power-users a lot of rope, but less experienced users will unwittingly hang themselves; or, more likely, be so scared that they won’t even touch CSS. It’s a balance.”)

This striving to be understood and used by the inexperienced is the underlying principle of all good design, from the iPhone to the Eames chair. It’s what Jared Spool would call usability and you and I may consider the heart of design. When anything new is created, be it a website, a service, or a web markup language, there is a gap between what the creator knows (which is everything about how it’s supposed to work), and what you and I know (which is nothing). The goal of design is to shrink this ignorance gap while seducing us into leaping across it.

What were once vices are now habits

You can see this principle at work in CSS, whose simplicity allowed us to learn it. Although we now rail against the limitations of CSS 1 and even CSS 2.1, what we are really complaining about is the slow pace of CSS 3 and the greater slowness with which browser makers (some more than others) adopt bits of it.

Note that at one time we would have railed against browser makers who implemented parts of a specification that was still under development; now we admire them. Note, too, that it has taken well over a decade for developers to understand and browsers to support basic CSS, and it is only from the perspective of the experienced customer who craves more that advanced web designers now cry out for immediate CSS 3 adoption and chafe against the “restrictions” of current CSS as universally supported in all browsers, including IE8.

If CSS had initially offered the power, depth, and complexity that CSS 3 promises, we would still be designing with tables or Flash. Even assuming a browser had existed that could demonstrate the power of CSS 3, the complexity of the specification would have daunted everyone but Eric Meyer, had CSS 1 not come out of the gate first.

The future of the future of standards

It was the practical simplicity of CSS that enabled browser engineers to implement it and tempted designers to use (and then evangelize) it. In contrast, it was the seeming complexity and detachment from practical workaday concerns that doomed XHTML 2, while XHTML 1.0 remains a valid spec that will likely still be working when you and I have retired (assuming retirement will be possible in our lifetime—but that’s another story).

And yet, compared to some W3C specs in progress, XHTML 2 was a model of accessible, practical, down-to-earth usability.

To the extent that W3C specifications remain modular, practical, and accessible to the non-PhD in computer science, they will be adopted by browser makers and the marketplace. The farther they depart from the principles Bert articulated, the sooner they will peter out into nothingness, and the likelier we are to face a crisis in which web standards once again detach from the direction in which the web is actually moving, and the medium is given over to incompatible, proprietary technologies.

I urge everyone to read “What is a Good Standard?“, and I thank my friend Tantek for pointing it out to me.

[tags]W3C, design, principles, bertbos, maintainability, accessibility, extensibility, learnability, simplicity, specs, standards, css, markup, code, languages, web, webdesign, webstandards, webdevelopment, essays[/tags]

Web fonts, HTML 5 roundup

Over the weekend, as thoughtful designers gathered at Typecon 2009 (“a letterfest of talks, workshops, tours, exhibitions, and special events created for type lovers at every level”), the subject of web fonts was in the air and on the digital airwaves. Worthwhile reading on web fonts and our other recent obsessions includes:

Jeffrey Zeldman Questions The “EOT Lite” Web Font Format

Responding to a question I raised here in comments on Web Fonts Now, for Real, Richard Fink explains the thinking behind Ascender Corp.’s EOT Lite proposal . The name “EOT Lite” suggests that DRM is still very much part of the equation. But, as Fink explains it, it’s actually not.

EOT Lite removes the two chief objections to EOT:

  • it bound the EOT file, through rootstrings, to the domain name;
  • it contained MTX compression under patent by Monotype Imaging, licensed by Microsoft for this use.

Essentially, then, an “EOT Lite file is nothing more than a TTF file with a different file extension” (and an unfortunate but understandable name).

A brief, compelling read for a published spec that might be the key to real fonts on the web.

Web Fonts—Where Are We?”

@ilovetypography tackles the question we’ve been pondering. After setting out what web designers want versus what type designers and foundries want, the author summarizes various new and old proposals (“I once heard EOT described as ‘DRM icing on an OpenType cake.’”) including Tal Leming and Erik van Blokland‘s .webfont, which is gathering massive support among type foundries, and David Berlow’s permissions table, announced here last week.

Where does all of this net out? For @ilovetypography, “While we’re waiting on .webfont et al., there’s Typekit.”

(We announced Typekit here on the day it debuted. Our friend Jeff Veen’s company Small Batch, Inc. is behind Typekit, and Jason Santa Maria consults on the service. Jeff and Jason are among the smartest and most forward thinking designers on the web—the history of Jeff’s achievements would fill more than one book. We’ve tested Typekit, love its simple interface, and agree that it provides a legal and technical solution while we wait for foundries to standardize on one of the proposals that’s now out there. Typekit will be better when more foundries sign on; if foundries don’t agree to a standard soon, Typekit may even be the ultimate solution, assuming the big foundries come on board. If the big foundries demur, it’s unclear whether that will spell the doom of Typekit or of the big foundries.)

The Power of HTML 5 and CSS 3

Applauding HTML 5’s introduction of semantic page layout elements (“Goodbye div soup, hello semantic markup”), author Jeff Starr shows how HTML 5 facilitates cleaner, simpler markup, and explains how CSS can target HTML 5 elements that lack classes and IDs. The piece ends with a free, downloadable goodie for WordPress users. (The writer is the author of the forthcoming Digging into WordPress.)

Surfin’ Safari turns up new 3-D HTML5 tricks that give Flash a run for its money

Just like it says.

Read more

  • Web Fonts Now, for Real: David Berlow of The Font Bureau publishes a proposal for a permissions table enabling real fonts to be used on the web without binding or other DRM. — 16 July 2009
  • Web Fonts Now (How We’re Doing With That): Everything you ever wanted to know about real fonts on the web, including commercial foundries that allow @font-face embedding; which browsers already support @font-face; what IE supports instead; Håkon Wium Lie, father of CSS, on @font-face at A List Apart; the Berlow interview at A List Apart; @font-face vs. EOT; Cufón; SIFR; Cufón combined with @font-face; Adobe, web fonts, and EOT; and Typekit, a new web service offering a web-only font linking license on a hosted platform; — 23 May 2009
  • HTML 5 is a mess. Now what? A few days ago on this site, John Allsopp argued passionately that HTML 5 is a mess. In response to HTML 5 activity leader Ian Hickson’s comment here that, “We don’t need to predict the future. When the future comes, we can just fix HTML again,” Allsopp said “This is the only shot for a generation” to get the next version of markup right. Now Bruce Lawson explains just why HTML 5 is “several different kind of messes.” Given all that, what should web designers and developers do about it? — 16 July 2009
  • Web Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, in the form of Safari, has been a surprising force for good on the web, raising people’s expectations about what a web browser can and should do, and what a web page should look like. — 12 July 2009
  • In Defense of Web Developers: Pushing back against the “XHTML is bullshit, man!” crowd’s using the cessation of XHTML 2.0 activity to condescend to—or even childishly glory in the “folly” of—web developers who build with XHTML 1.0, a stable W3C recommendation for nearly ten years, and one that will continue to work indefinitely. — 7 July 2009
  • XHTML DOA WTF: The web’s future isn’t what the web’s past cracked it up to be. — 2 July 2009

[tags]@font-face, berlow, davidberlow, CSS, permissionstable, fontbureau, webfonts, webtypography, realtypeontheweb, HTML5, HTML4, HTML, W3C, WHATWG, markup, webstandards, typography[/tags]

“Google Bets Big on HTML 5”

While the entire HTML 5 standard is years or more from adoption, there are many powerful features available in browsers today. In fact, five key next-generation features are already available in the latest (sometimes experimental) browser builds from Firefox, Opera, Safari, and Google Chrome.

Tim O’Reilly: Google Bets Big on HTML 5

Striving to avoid the mistake Microsoft made when it bet on binary applications over the web, Google is counting on HTML 5 adoption to expand the capability of web applications. Tim O’Reilly describes Google’s strategy and lists five key HTML 5 features that are already supported in Safari, Firefox, Opera, and Chrome.

[tags]HTML5, Google, O’Reilly, TimO’Reilly, canvas, browsers, webapps, web applications, webstandards[/tags]

Web fonts now (how we’re doing with that)

THE WEB Fonts Wiki has a page listing fonts you can legally embed in your site designs using the CSS standard @font-face method. Just as importantly, the wiki maintains a page showing commercial foundries that allow @font-face embedding. Between these two wiki pages, you may find just the font you need for your next design (even if you can’t currently license classics like Adobe Garamond or ITC Franklin and Clarendon).

The advantages of using fonts other than Times, Arial, Georgia, and Verdana have long been obvious to designers; it’s why web design in the 1990s was divided between pages done in Flash, and HTML pages containing pictures of fonts—a practice that still, bizarrely, continues even in occasionally otherwise advanced recent sites.

Using real fonts instead of pictures of fonts or outlines of fonts provides speed and accessibility advantages.

Currently the Webkit-based Apple Safari browser supports @font-face. The soon-to-be-released next versions of Opera Software’s Opera browser, Google’s Webkit-based Chrome, and Mozilla Firefox will do likewise. When I say “soon-to-be-released,” I mean any day now. When this occurs, all browsers except IE will support @font-face.

IE has, however, offered font embedding since IE4 via Embedded OpenType (.EOT), a font format that enables real fonts to be temporarily embedded in web pages. That is, the reader sees the font while reading the page, but cannot download (“steal”) the font afterwards. Microsoft has “grant[ed] to the W3C a perpetual, nonexclusive, royalty-free, world-wide right and license under any Microsoft copyrights on this contribution, to copy, publish and distribute the contribution under the W3C document licenses,” in hopes that EOT would thereby become a standard. But so far, only Microsoft’s own browsers support EOT.

Thus, as we consider integrating real fonts into our designs, we must navigate between browsers that support @font-face now (Safari), those that will do so soon (Opera, Chrome, Firefox), and the one that possibly never will (IE, with a dwindling but still overwhelming market share).

The person who figures out a designer-friendly solution to all this will either be hailed as a hero/heroine or get rich. Meanwhile, near-complete solutions of varying implementation difficulty exist. Read on:

CSS @ Ten: The Next Big Thing

“Instead of making pictures of fonts, the actual font files can be linked to and retrieved from the web. This way, designers can use TrueType fonts without having to freeze the text as background images.” An introduction to @font-face by Håkon Wium Lie, father of CSS.

Real Fonts on the Web: An Interview with The Font Bureau’s David Berlow

Is there life after Georgia? To understand issues surrounding web fonts from the type designer’s perspective, I interview David Berlow, co-founder of The Font Bureau, Inc, and the first TrueType type designer.

The W3C: @font-face vs. EOT

A discussion that shows why the W3C may not be able to resolve this conflict. (It’s kind of like asking the Montagues and Capulets to decide whether the Montagues or the Capulets should rule Verona.)

sIFR 2.0: Rich Accessible Typography for the Masses

Mike Davidson’s scalable and accessible remix of Shaun Inman’s pioneering use of Flash and JavaScript to replace short passages of HTML text with Flash movies of the same text set in a real font. The Flash movies are created on the fly. If JavaScript or images are turned off, the user “sees” the HTML text; text set in sIFR can also be copied and pasted. sIFR was a great initial solution to the problem of real fonts on the web, but it’s only for short passages (which means the rest of the page must still be set in Georgia or Verdana), and it fails if the user has a Flash block plug-in installed, as half of Firefox users seem to. It’s also always a pain to implement. I don’t know any designer or developer who has an easy time setting up sIFR. In short, while sIFR is an awesome stop-gap, real fonts on the web are still what’s needed. Which also leads us to…

Cufón – Fonts for the People

Simo Kinnunen’s method of embedding fonts, regardless of whether or not a browser supports @font-face.

Combining Cufón And @Font-Face

Kilian Valkhof: “Everyone wants @font-face to work everywhere, but as it stands, it only works in Safari and the upcoming versions of Firefox and Opera. In this article I’ll show you how to use Cufón only if we can’t load the font through other, faster methods.”

Adobe, Web Fonts, and EOT

Why Adobe supports Microsoft’s EOT instead of @font-face.

Introducing Typekit

Update May 28, 2009: Working with Jason Santa Maria, Jeff Veen’s company Small Batch Inc. introduces Typekit:

We’ve been working with foundries to develop a consistent web-only font linking license. We’ve built a technology platform that lets us to host both free and commercial fonts in a way that is incredibly fast, smoothes out differences in how browsers handle type, and offers the level of protection that type designers need without resorting to annoying and ineffective DRM.

Read more

  • Web Fonts, HTML 5 Roundup: Worthwhile reading on the hot new web font proposals, and on HTML 5/CSS 3 basics, plus a demo of advanced HTML 5 trickery. — 20 July 2009
  • Web Fonts Now, for real: David Berlow of The Font Bureau has proposed a Permissions Table for OpenType that can be implemented immediately to turn raw fonts into web fonts without any wrappers or other nonsense. If adopted, it will enable type designers to license their work for web use, and web designers to create pages that use real fonts via the CSS @font-face standard. — 16 July 2009

[tags]fonts, webfonts, webdesign, embed, @font-face, EOT, wiki, css, layout, safari, opera, firefox, chrome, browsers[/tags]

Customer service, not Ruby on Rails

Among developers, 37signals has achieved a cult following for giving us web applications like Basecamp, Highrise, and Campfire, and the Ruby on Rails platform. But the real secret of their success is as old fashioned as your great grandfather’s Victrola. It’s customer service.

We opened a HighRise account to manage our A List Apart author contacts and then didn’t use the account for whatever reason.

This morning I cancelled my account with two clicks of a button.

The messaging clearly explained that canceling the account would mean losing the contacts, and provided an opportunity to rethink the decision.

When I chose to go ahead with the cancellation, it happened instantly, and I was taken to this page, which reassured me that the account was closed and that I would stop receiving product-related emails. Smart. I was instantly satisfied and had no more questions. How often does that happen when closing, say, a phone or cable or internet account?

The page also offered me the opportunity to try another 37signals product or to provide customer feedback in a survey. If I had quit using the product because of dissatisfaction with it, I would have been able to use the survey to tell 37signals everything I disliked about my experience. If I liked the product but found it wasn’t right for me for whatever reason, I could tell them that (which could help them focus on their core audience’s needs).

All smart, businesslike, and yet inoffensive and un-pushy.

37signals not only constantly fine-tunes their products, they also think about the customer experience even when the customer is leaving.

I find that instructive, educational, and inspiring.

Disclaimer: Jason Fried is my friend, and I do business with 37signals through The Deck advertising network, so I’m not impartial. Just impressed.