Author: Tim Murtaugh
Date: 2012-07-10T04:00:00+00:00

ALA 2012 Summer Reading Issue

ALA's favorite articles from 355 issues of A List Apart.

A Dao of Web Design
http://www.alistapart.com/articles/dao/

What Zen was to the 70s (most famously with motorcycle maintenance), the Tao Te Ching was to the 90s. From Piglet and Pooh to Physics and back, many have sought sense in applying the Tao Te Ching…

What Zen was to the 70’s (most famously with motorcycle maintenance), the Tao Te Ching was to the 90’s. From Piglet and Pooh to Physics and back, many have sought sense in applying the Tao Te Ching to something (the Tao of Physics), or something to the Tao Te Ching (the Tao of Pooh). It can be a cheap trick, but lately it has struck me that there is more than a little to be understood about web design by looking through the prism of the Tao.

Daoism is a philosophy, like Buddhism, a way of living, of being in the world, which stems from a text of great antiquity, the Tao Te Ching, whose 81 “chapters” enigmatically sweep across human experience, but with a strong common theme, that of harmony.

For the last couple of years, for better or worse, my life has revolved more than a little around style sheets. I write software, tutorials, and guides for them; I’ve answered too many questions to count about them on newsgroups and via email; I’ve fought for their adoption with The Web Standards Project. And slowly I’ve come to understand web design entirely differently because of them, and to see a strong association between design and the Tao.

What I sense is a real tension between the web as we know it, and the web as it would be. It’s the tension between an existing medium, the printed page, and its child, the web. And it’s time to really understand the relationship between the parent and the child, and to let the child go its own way in the world.

Same old new medium?

“Well established hierarchies are not easily uprooted;
Closely held beliefs are not easily released;
So ritual enthralls generation after generation.”
Tao Te Ching; 38 Ritual

If you’ve never watched early television programs, it’s instructive viewing. Television was at that time often referred to as “radio with pictures”, and that’s a pretty accurate description. Much of television followed the format of popular radio at that time. Indeed programs like the Tonight Show, with its variants found on virtually every channel in the world (featuring a band, the talk to the camera host, and seated guests), or the news, with the suited sober news reader, remain as traces of the medium television grew out of. A palimpsest of media past.

Think too of the first music videos (a few of us might be at least that old). Essentially the band miming themselves playing a song. Riveting.

When a new medium borrows from an existing one, some of what it borrows makes sense, but much of the borrowing is thoughtless, “ritual”, and often constrains the new medium. Over time, the new medium develops its own conventions, throwing off existing conventions that don’t make sense.

If you ever get the chance to watch early television drama you’ll find a strong example of this. Because radio required a voice – over to describe what listeners couldn’t see, early television drama often featured a voice over, describing what viewers could. It’s a simple but striking example of what happens when a new medium develops out of an existing one.

The web is a new medium, although it has emerged from the medium of printing, whose skills, design language and conventions strongly influence it. Yet it is often too shaped by that from which it sprang. “Killer Web Sites” are usually those which tame the wildness of the web, constraining pages as if they were made of paper – Desktop Publishing for the Web. This conservatism is natural, “closely held beliefs are not easily released”, but it is time to move on, to embrace the web as its own medium. It’s time to throw out the rituals of the printed page, and to engage the medium of the web and its own nature.

This is not for a moment to say we should abandon the wisdom of hundreds of years of printing and thousands of years of writing. But we need to understand which of these lessons are appropriate for the web, and which mere rituals.

Controlling Web Pages

The Sage

“… accepts the ebb and flow of things,
Nurtures them, but does not own them,”
Tao Te Ching; 2 Abstraction

Spend some time on web design newgroups or mailing lists, and you’ll find some common words and ideas repeated time after time. Question after question, of course, is “how do I?”. But beneath questions like “how do I make my pages look the same on every platform” and “how can I make my fonts appear identical on the Macintosh and Windows” is an underlying question – “how do I control the user’s browser?” Indeed, the word control turns up with surprising frequency.

Underpinning all this is the belief that designers are controllers (think about the implications of the term “pixel mechanic”). Designers want to override the wishes of users, and the choices that they have made about their viewing experience (by “fixing” font size, for instance). Designers want to second guess platform differences, caused by different logical resolutions (for instance the Macintosh’s 72dpi, versus the standard Windows 96dpi). Designers are all-knowing, and will not tolerate anything less than a rendering on every browser that is pixel perfect with the rendering on their own machine.

Of course, this exaggerates the case, but not greatly. A very strong example of this is the often expressed disappointment of developers when they learn that style sheets are not “DTP for the web”. And if you are a Mac user, you will be acutely aware of just how many really major sites abuse style sheets to make their pages illegible. Chances are they are using points as a measure of font size. Underlying this choice is the “designer is controller” philosophy.

Where does this idea come from? I believe it flows from the medium of print. In print the designer is god. An enormous industry has emerged from WYSIWYG, and many of the web’s designers are grounded in the beliefs and practices, the ritual of that medium. As designers we need to rethink this role, to abandon control, and seek a new relationship with the page.

Why does it matter?

“A newborn is soft and tender,
A crone, hard and stiff.
Plants and animals, in life, are supple and succulent;
In death, withered and dry.
So softness and tenderness are attributes of life,
And hardness and stiffness, attributes of death.”
Tao Te Ching; 76 Flexibility

Perhaps the inability to “control” a page is a limitation, a bug of the web. When we come from the WYSIWYG world, our initial instinct is to think so. I admit that it was my first response, and a belief that was a long time in going. But I no longer feel that it is a limitation, I see it as a strength of a new medium.

Let’s look at this through the other end of the microscope. The fact we can control a paper page is really a limitation of that medium. You can think – we can fix the size of text – or you can think – the size of text is unalterable. You can think – the dimensions of a page can be controlled – or – the dimensions of a page can’t be altered. These are simply facts of the medium.

And they aren’t necessarily good facts, especially for the reader. If the reader’s eye sight isn’t that of a well sighted person, chances are the choice the designer made is too small to comfortably read without some kind of magnification. If the reader is in a confined space, a train to work, an airplane, the broadsheet newspaper is too large. And there is little the reader can do about this.

The control which designers know in the print medium, and often desire in the web medium, is simply a function of the limitation of the printed page. We should embrace the fact that the web doesn’t have the same constraints, and design for this flexibility. But first, we must “accept the ebb and flow of things”.

Adaptability is Accessibility

“The best of man is like water,
Which benefits all things, and does not contend with them,
Which flows in places that others disdain,
Where it is in harmony with the Way.”
Tao Te Ching; 8 Water

There are those who think that dao is fatalistic. A simplistic reading is that one should wander, without plan, allowing for things to happen and to respond to them. I think of it as saying we should not be fixed in our outlook, with goals far ahead, rather we should be adaptable, not fixed in our views or direction.

“As observing detail is clarity,
So maintaining flexibility is strength;
Use the light but shed no light,
So that you do yourself no harm,
But embrace clarity.“
Tao Te Ching; 52 Clarity

The flexibility I’ve talked about so far I think of as “adaptability“. Everything I’ve said so far could be summarized as: make pages which are adaptable. Make pages which are accessible, regardless of the browser, platform or screen that your reader chooses or must use to access your pages. This means pages which are legible regardless of screen resolution or size, or number of colors (and remember too that pages may be printed, or read aloud by reading software, or read using braille browsers). This means pages which adapt to the needs of a reader, whose eyesight is less than perfect, and who wishes to read pages with a very large font size.

Designing adaptable pages is designing accessible pages. And perhaps the great promise of the web, far from fulfilled as yet, is accessibility, regardless of difficulties, to information. It’s an important belief of the World Wide Web Consortium, and is becoming an imperative of web design, as web pages will be required by law to provide universal access, just as building codes around the world require access to buildings.

It sounds an impossibility, designing the universal page. Perhaps now it remains an aspiration, with browsers so broken, and many of the devices through which we will access the web in their infancy, or not yet born. But there is a lot we can do now which will set the foundations for pages which adapt to the users wishes and needs, and so will be accessible.

The Way

“The Way is shaped by use,
But then the shape is lost.
Do not hold fast to shapes
But let sensation flow into the world
As a river courses down to the sea.”
Tao Te Ching; 32 Shapes

So what can be done to design for adaptability, and so accessibility? Firstly, there are a couple of ways of thinking which might be helpful. Then I have some practical suggestions about steps you can take to avoid making your pages inaccessible.

Firstly, think about what your pages do, not what they look like. Let your design flow from the services which they will provide to your users, rather than from some overarching idea of what you want pages to look like. Let form follow function, rather than trying to take a particular design and make it “work”.

A cornerstone of this idea is to separate the content and its appearance. You’ve probably heard this a hundred times, but it is perhaps the most important step you can take. Let’s look at a simple example. On a page there is some text which is italicized. Why is it italicized? It might be for emphasis. It might be a citation. It might be a foreign word used in English. In traditional publishing, the form follows from function. The advantage of web publishing is we can make explicit what is implicit in the appearance on paper. If the reason for italics is emphasis, why mark up your page with the <i> element? Use the <em> element, and so browsers other than PC based web browsers can handle the element appropriately.

On the larger scale, don’t use HTML for presentation. No <font> or <b>, <i> and other presentational elements. Where HTML provides an appropriate element, use it. Where it doesn’t, use classes. And of course, use style sheets for your presentational information. It’s time to look to the future, not cling to the past.

If you use style sheets properly, to suggest the appearance of a page, not to control the appearance of a page, and you don’t rely on your style sheet to convey information, then your pages will “work” fine in any browser, past or future. Browsers which don’t support style sheets simply present pages that look a little on the plain side. Our biggest concern is browsers which have buggy style sheets support. Today this is an issue. Not too long from now, it won’t be much of an issue. For now, you can limit yourself to a subset of CSS which is well enough supported, and still have more presentational effect than using presentational HTML. I’ve written quite a bit about this elsewhere, so I won’t repeat myself here.

In practical terms, there are some things you should and some things you shouldn’t do when designing style sheets that will impact on the adaptability of your pages. Above all, don’t rely on any aspect of style sheets to work in order for a page to be accessible. Absolute units, like pixels and points are to be avoided (if that comes as a surprise, read on), and color needs to be used carefully, and never relied on.

Fonts

Typically, a Windows, Macintosh, or other system will have only a handful of fonts installed. There is little overlap between the default installed fonts on these various systems. Already with many browsers, and increasingly in the future, readers will be able to decide on the fonts they want to view web pages with. With CSS, you can suggest a number of fonts, and cover as many bases as possible. But don’t rely on a font being available regardless of how common it is.

More important still is font size. You may be aware that the same font, at the same point size on a Macintosh “looks smaller” than on most Windows machines. In a nutshell, this is because the “logical resolution” of a Macintosh is 72dpi, while the Windows default is 96dpi. The implications of this are significant. Firstly, it guarantees that it is essentially impossible to have text look identical on Macintoshes and Windows based systems. But if you embrace the adaptability philosophy it doesn’t matter.

What? If you are concerned about exactly how a web page appears this is a sign that you are still aren’t thinking about adaptive pages. One of the most significant accessibility issues is font size. Small fonts are more difficult to read. For those of us with good eyesight, it can come as a shock that a significant percentage of the population has trouble reading anything below 14 point times on paper. Screens are less readable than paper, because of their lower resolution.

Does that mean the minimum point size we should use is 14 pts? That doesn’t help those whose sight is even less strong. So what is the minimum point size we should use? None. Don’t use points. This allows readers to choose the font size which suits them. The same goes even for pixels. Because of logical resolution differences, a pixel on one platform is not a pixel on another.

You can still suggest larger font sizes for headings and other elements. CSS provides several ways of suggesting the size of text in such a way as to aid adaptability. We’ll look at just one to get an idea.

With CSS you can specify font size as a percentage of the font size of a parent element. For example, headings are inside the BODY of the page. If you don’t set a size for the text in the BODY, then the text of the BODY will be the size that the reader has chosen as their default size. Already we are aiding adaptability of our page, simply by doing nothing!

You might say “but the text looks too big” if I just leave it like that. Make it smaller then. But in your browser. And your readers will then have the option to make it bigger or smaller in their browsers too, depending on their tastes, or their needs.

We can make headings and other elements stand out using font size by specifying that headings of level 1 should be say 30% larger than the body text, level 2 should be 25% larger, and so on. Now, regardless of the size that the user chooses for their main text, headings will be scaled to be proportionally bigger than the main text. Similarly text can be scaled to be smaller than the body text, however, this can give rise to situations where the text can be illegibly small, so use with caution.

We’ve done very little really, just avoided using absolute font sizes, and used proportional sizes for headings, and we’ve already made our pages much more adaptable and accessible.

Layouts

Margins, page widths and indentation are all aspects of page design which can aid readability. The web presents difficulties for the designer with each of these. Browser windows can be resized, thereby changing the page size. Different web devices (web TV, high resolution monitors, PDAs) have different minimum and maximum window sizes. As with fixed font sizes, fixed page layout can lead to accessbility problems on the web.

As with fonts, layout aspects of a page can be designed using percentages to create adaptable pages. Margins can be specified as a percentage of the width of the element which contains them.

Using percentages (or other relative values) to specify page layout in CSS automatically creates adaptive pages. As browser windows widen and narrow, the layout of an element adapts to maintain the same proportions, and so the whole page layout adapts. Readers can choose the window size they find appropriate to their needs.

Margins, text indentation and other layout aspects can also be specified in relation to the size of the text they contain, using the em unit for specifying margins, text indentation and other layout aspects. If you specify

p {margin – left: 1.5em}

you are saying that the left magin of paragraphs should be 1.5 times the height of the font of that paragraph. So, when a user adjusts their font size to make a page more legible, the margin increases proportionally, and if they adjust it to make it smaller, the margin adapts again.

Colors

The web is by and large a more colorful medium than the printed page. Color is cheaper on the web. Color can be ornamental, can help to establish a visual identity, and can have practical value (red might draw attention to important information). But color poses difficulties to accessibility as well.

Did you know that in many countries (if not all) people with red green color blindness are unable to obtain an aircraft pilot’s license? That is, regardless of any other ability, because warning information is almost invariably conveyed using red for danger and green for safety. It’s a shame that warning lights aren’t simply adaptable.

Do your web pages exclude people in a similar way? It would be a shame, as in the near future most web browsers will provide simple ways for readers to adjust the color of elements on a web page, via user style sheets, which can override your style sheets. (You can do this now with IE5 Macintosh edition.)

How to avoid these problems? Use style sheets, rather than the HTML <font> element. And avoid relying on color combinations to alone convey meaning.

The Journey

“Yet a tree broader than a man can embrace is born of a tiny shoot;
A dam greater than a river can overflow starts with a clod of earth;
A journey of a thousand miles begins at the spot under one’s feet.”
Tao Te Ching; 64a. Care at the Beginning

Changing our ways of thinking and acting isn’t easy. “Closely held beliefs are not easily released”. But I’ve come slowly to realize that much of what I took for granted needed to be reassessed. Judging by what I see and read and the conversations I’ve had, the email I’ve read over the last couple of years, many hold these beliefs closely, and need to rethink them too.

Now is the time for the medium of the web to outgrow its origins in the printed page. Not to abandon so much wisdom and experience, but to also chart its own course, where appropriate.

The web’s greatest strength, I believe, is often seen as a limitation, as a defect. It is the nature of the web to be flexible, and it should be our role as designers and developers to embrace this flexibility, and produce pages which, by being flexible, are accessible to all.

The journey begins by letting go of control, and becoming flexible.

Translations
Russian (Webmascon.com)
French (Pompage.net)

Tao Te Ching quotes from the GNL’s not Lao Tao Te Ching Copyright © 1992, 1993, 1994, 1995 Peter A. Merel.

Understanding Web Design
http://www.alistapart.com/articles/understandingwebdesign/

We get better design when we understand our medium. Yet even at this late cultural hour, many people don’t understand web design. Among them can be found some of our most distinguished business and cultural leaders, including a few who possess a profound grasp of design—except as it relates to the web.

Some who don’t understand web design nevertheless have the job of creating websites or supervising web designers and developers. Others who don’t understand web design are nevertheless professionally charged with evaluating it on behalf of the rest of us. Those who understand the least make the most noise. They are the ones leading charges, slamming doors, and throwing money—at all the wrong people and things.

If we want better sites, better work, and better-informed clients, the need to educate begins with us.

Preferring real estate to architecture

It’s hard to understand web design when you don’t understand the web. And it’s hard to understand the web when those who are paid to explain it either don’t get it themselves, or are obliged for commercial reasons to suppress some of what they know, emphasizing the Barnumesque over the brilliant.

The news media too often gets it wrong. Too much internet journalism follows the money; too little covers art and ideas. Driven by editors pressured by publishers worried about vanishing advertisers, even journalists who understand the web spend most of their time writing about deals and quoting dealmakers. Many do this even when the statement they’re quoting is patently self-serving and ludicrous—like Zuckerberg’s Law.

It’s not that Zuckerberg’s not news; and it’s not that business isn’t some journalists’ beat. But focusing on business to the exclusion of all else is like reporting on real estate deals while ignoring architecture.

And one tires of the news narrative’s one-dimensionalism. In 1994, the web was weird and wild, they told us. In ‘99 it was a kingmaker; in ‘01, a bust. In ‘02, news folk discovered blogs; in ‘04, perspiring guest bloggers on CNN explained how citizen journalists were reinventing news and democracy and would determine who won that year’s presidential election. I forget how that one turned out.

When absurd predictions die ridiculous deaths, nobody resigns from the newsroom, they just throw a new line into the water—like marketers replacing a slogan that tanked. After decades of news commoditization, what’s amazing is how many good reporters there still are, and how hard many try to lay accurate information before the public. Sometimes you can almost hear it beneath the roar of the grotesque and the exceptional.

The sustainable circle of self-regard

News media are not the only ones getting it wrong. Professional associations get it wrong every day, and commemorate their wrongness with an annual festival. Each year, advertising and design magazines and professional organizations hold contests for “new media design” judged by the winners of last year’s competitions. That they call it “new media design” tells them nothing and you and me everything.

Although there are exceptions, for the most part the creators of winning entries see the web as a vehicle for advertising and marketing campaigns in which the user passively experiences Flash and video content. For the active user, there is gaming—but what you and I think of as active web use is limited to clicking a “Digg this page” button.

The winning sites look fabulous as screen shots in glossy design annuals. When the winners become judges, they reward work like their own. Thus sites that behave like TV and look good between covers continue to be created, and a generation of clients and art directors thinks that stuff is the cream of web design.

Design critics get it wrong, too

People who are smart about print can be less bright about the web. Their critical faculties, honed to perfection during the Kerning Wars, smash to bits against the barricades of our profession.

The less sophisticated lament on our behalf that we are stuck with ugly fonts. They wonder aloud how we can enjoy working in a medium that offers us less than absolute control over every atom of the visual experience. What they are secretly asking is whether or not we are real designers. (They suspect that we are not.) But these are the juniors, the design students and future critics. Their opinions are chiefly of interest to their professors, and one prays they have good ones.

More sophisticated critics understand that the web is not print and that limitations are part of every design discipline. Yet even these eggheads will sometimes succumb to fallacious comparatives. (I’ve done it myself, although long ago and strictly for giggles.) Where are the masterpieces of web design, these critics cry. That Google Maps might be as representative of our age as the Mona Lisa was of Leonardo’s—and as brilliant, in its way—satisfies many of us as an answer, but might not satisfy the design critic in search of a direct parallel to, oh, I don’t know, let’s say Milton Glaser’s iconic Bob Dylan poster.

Typography, architecture, and web design

The trouble is, web design, although it employs elements of graphic design and illustration, does not map to them. If one must compare the web to other media, typography would be a better choice. For a web design, like a typeface, is an environment for someone else’s expression. Stick around and I’ll tell you which site design is like Helvetica.

Architecture (the kind that uses steel and glass and stone) is also an apt comparison—or at least, more apt than poster design. The architect creates planes and grids that facilitate the dynamic behavior of people. Having designed, the architect relinquishes control. Over time, the people who use the building bring out and add to the meaning of the architect’s design.

Of course, all comparisons are gnarly by nature. What is the “London Calling” of television? Who is the Jane Austen of automotive design? Madame Butterfly is not less beautiful for having no car chase sequence, peanut butter no less tasty because it cannot dance.

So what is web design?

Web design is not book design, it is not poster design, it is not illustration, and the highest achievements of those disciplines are not what web design aims for. Although websites can be delivery systems for games and videos, and although those delivery systems can be lovely to look at, such sites are exemplars of game design and video storytelling, not of web design. So what is web design?

Web design is the creation of digital environments that facilitate and encourage human activity; reflect or adapt to individual voices and content; and change gracefully over time while always retaining their identity.

Let’s repeat that, with emphasis:

Web design is the creation of digital environments that facilitate and encourage human activity; reflect or adapt to individual voices and content; and change gracefully over time while always retaining their identity.

She walks in beauty

Great web designs are like great typefaces: some, like Rosewood, impose a personality on whatever content is applied to them. Others, like Helvetica, fade into the background (or try to), magically supporting whatever tone the content provides. (We can argue tomorrow whether Helvetica is really as neutral as water.)

Which web design is like that? For one, Douglas Bowman’s white “Minima” layout for Blogger, used by literally millions of writers—and it feels like it was designed for each of them individually. That is great design.

Great web designs are like great buildings. All office buildings, however distinctive, have lobbies and bathrooms and staircases. Websites, too, share commonalities.

Although a great site design is completely individual, it is also a great deal like other site designs that perform similar functions. The same is true of great magazine and newspaper layouts, which differ from banal magazine and newspaper layouts in a hundred subtle details. Few celebrate great magazine layouts, yet millions consciously or unconsciously appreciate them, and nobody laments that they are not posters.

The inexperienced or insufficiently thoughtful designer complains that too many websites use grids, too many sites use columns, too many sites are “boxy.” Efforts to avoid boxiness have been around since 1995; while occasionally successful, they have most often produced aesthetically wretched and needlessly unusable designs.

The experienced web designer, like the talented newspaper art director, accepts that many projects she works on will have headers and columns and footers. Her job is not to whine about emerging commonalities but to use them to create pages that are distinctive, natural, brand-appropriate, subtly memorable, and quietly but unmistakably engaging.

If she achieves all that and sweats the details, her work will be beautiful. If not everyone appreciates this beauty—if not everyone understands web design—then let us not cry for web design, but for those who cannot see.

Good Designers Redesign, Great Designers Realign
http://www.alistapart.com/articles/redesignrealign/

Halfway through 2004, I openly predicted incessant redesigning would become somewhat cessant by the same year’s end:

Forward thinkers understand content is still king and focus on such while deploying minimal upgrades, rather than relying on skillful makeovers that gain short-lived traffic spurts following award listings but offer downright weak content.

How wrong I was. Apparently the Incessant Redesign is far from extinction.

Like a kid in a candy store, we creatives redesign like it’s the new black. Why do we possess such an insatiable desire to refresh and remake? Why do we thrive on renewal? What tempts us to be seduced by the sway of renaissance?

While this article won’t analyze the psychological ambitions of right-brained elites and their innate desire to recreate, it will attempt to describe the difference between redesigning and realigning, as well the advantages of one over the other.

If iLife Falls in the Forest…

In January 2005, Apple’s iLife ’05 was announced from Macworld Expo in San Francisco. The ensuing conversation offered plenty of feature-laden jargon regarding the upgraded suite of “digital lifestyle applications.”

Virtually absent from the discussion was any mention of the rebranded iLife packaging. With little fanfare, Apple introduced a refreshed identity—let’s call it a “redesign” for now—for its suite of lifestyle tools, and an unexpected hush seemed to fall over the crowds that might have otherwise discussed the shift in packaging design.

It was almost immediately following the release of iLife ’05 that the idea for this article was spawned. Something clicked. The new iLife packaging wasn’t just a redesign for the sake of redesigning. It seemed to represent much more than that. Personal computing was no longer something done to accomplish something else more efficiently, but rather a part of everyday life, even critical to communication and social interaction. The iPod, for example, was no longer only for the technorati; it was quickly becoming mainstream for coder and soccer mom alike. And that’s what the new packaging seemed to portray—less about technology, more about people. The camera, keyboard, and similar objects subtly remain from the previous packaging, but the organic styling and seed metaphor—a perfect representation of “life” itself—steal the show.

So was the new iLife packaging merely another redesign to satisfy creative hunger pangs, or was it an attempt at something greater? Perhaps it wasn’t even a redesign after all, but rather a shift in positioning—a realign instead of a redesign.

Redesigners vs. Realigners

By now it’s apparent that I’ve split us, the creatives, into two camps—and equally apparent that I prefer to wear Realigner team colors. Allow me to indulge in team bias by comparing the two.

The “redesigners”

The Redesigners often rely on emotional responses to aesthetics in justifying a redesign. You’ll typically hear statements like these:

It’s been 2 years since our last redesign.
Our current stuff just looks old.
A redesign would bring new traffic to the site.

Too often, look and feel, color scheme, layout, and identity are presented as solutions to problems discussed in these conversations long before regard is given to other less-aesthetic issues that may very well be the root of the problem. The old warning against treating symptom rather than cause comes to mind.

The “realigners”

In direct contrast to the Redesigners, the Realigners cite strategic objectives and user needs as reasons to consider a site overhaul:

Market trends have shifted. Should our website be adjusted accordingly?
Our users’ needs have changed. Do we need to adapt?
We’ve added 3 new sections and a slew of new content to the site over the last 12 months. Are we presenting content as effectively as we can?
Our current website does little to convey the strength of our product offering.
Does our online presence enhance or devalue our overall brand perception?

Thus, the differences between Redesigners and Realigners might be summarized as follows: The desire to redesign is aesthetic-driven, while the desire to realign is purpose-driven. One approach seeks merely to refresh, the other aims to fully reposition and may or may not include a full refresh. (Note that by “reposition,” I mean strategy and not physical location or dimensions.)

Don’t get me wrong—I too have played the role of typical Redesigner at times. We’re all entitled to throw caution to the wind and redesign as a means of staying on top of one’s game (e.g. redesign contests and portfolio sites). And besides, we can’t bear the full brunt of the blame—we’re creatives first, strategists (and info architects and project managers and coders and everything else under the sun) second. But I worry persistent redesigning with little cause often serves to promote only proprietary creativity, doing much to educate one in the hows of redesigning but little in the whys of realigning.

Just say no

Perhaps the best way to educate one’s self in the whys of realigning is to start by saying no. Strategy is often just as much about saying no as it is about saying yes. So is realigning.

Considered by many as the godfather of strategy, Michael Porter says it best in his Harvard Business Review article, “What is Strategy?” (emphasis mine):

The essence of strategy is choosing what not to do.

Thank you, Godfather Michael. You’ve given us reason to question redesigning and begin thinking about realigning, simply by first saying no to the typical whims of gratuitous refresh and renew.

But enough about strategy and other conceptual banter. Let’s talk practical application.

Proof Is In the Pixels

So who’s already riding the Realigner bandwagon? A few brief case studies follow.

31three

Though we’ve never met in person, I consider Jesse Bennett-Chamberlain one of my closest friends. While authoring initial ideas for this article, I was given a peek at the upcoming redesign—er, realign—of Jesse’s studio site, 31Three.

Jesse had no idea I was penning thoughts on this subject, yet the instant I saw his nascent layout in raw format I knew I had my first case study. After literally years of begging him to do so, Jesse was finally heeding the call to jump from tables to standards, as well as adding a blog to the site. Accordingly, the site needed to be updated, yet an all-out redesign wasn’t necessary. He already had a solid design, so following a few minor color, grid, and typography changes he was well on his way to becoming a Realigner.

Gorgeous, isn’t it? Final score: Realigners 1, Redesigners 0.

SimpleBits

Like most other sites of age, Dan Cederholm’s SimpleBits has changed over the years. But not as one might expect. Take a look at the sequence of screen grabs below:

Notice any sweeping changes from year to year? Neither did I. Dan has managed to tune, tweak, and adapt his site in response to growth and changes in positioning, while maintaining a skeleton that bears similarities with each passing phase. As I’ve watched Dan launch new versions over the years, he’s done so with an eye toward purpose-driven improvements. Chalk up another one for the Realigners.

“But Cameron,” you interject, “these are a pair of small studio sites you’re spoon-feeding us. What about realigning on a larger scale?”

Not so fast, honey. Keep reading.

Philanthropic realignment

Over the summer, I had the pleasure of doing contract work for March of Dimes. Founded by Franklin D. Roosevelt in 1938, March of Dimes seeks to reduce premature births through research and fundraiser events such as WalkAmerica. Following a generous referral from Nick Finck, they came to me in need of a new homepage.

As typical with other projects, I was provided an RFP before being selected for the project. Here’s the opening statement from that RFP:

In September of 2002 we launched our parent website, www.marchofdimes.com. Since then, we’ve built several other websites, our page views have grown exponentially, we’ve built an online fundraising tool from the ground up that raised over $12 million this year, and gained tremendous credibility and interest from within the foundation itself… To support all of these initiatives and continue our growth into other online communities (message boards and blogs), we need to re-address and redesign our homepage.

Bingo. They nailed it. That’s the thinking of a Realigner—purpose-driven retooling. There’s virtually no mention of aesthetics, but plenty of talk about responding to growth and new opportunities.

And so began the realignment of the March of Dimes homepage. In fact, we were to realign only the homepage; all other pages would remain intact. The homepage, therefore, would not only need to address the issues mentioned in the RFP, but it would also need to integrate aesthetically with the rest of the site. This fact alone silenced any desire for a full makeover.

It’s probably no surprise, then, that the realigned homepage (shown at right above) will not be entirely different from the existing homepage. The new homepage is scheduled to be released in the coming weeks and is still under final review at time of publication (note the filler headline, for example).

The full-refresh disclaimer

By now I hope I’ve recruited you to join me on the Realigner sidelines. However, be aware that I don’t shun the full refresh in all its aesthetical glory when necessary. It’s perfectly fine to refresh the entire design from the ground up if there’s good reason to do so, and especially if it’s the cause and not merely the symptom of your site’s woes.

In fact, this very site (A List Apart) underwent a similar transformation only weeks ago, based on a need to adapt to the new identity, brand extensions (A Book Apart, An Event Apart), and other necessary improvements. So by all means, bring on the full refresh should it be warranted.

Converting to realignism

Ready to embrace the paradigm shift from redesign to realign? Consider the following when making the leap of faith to Realignism:

1. Ensure a “raison d’être” exists. What are the reasons/objectives/purpose for realigning? I typically reserve a line in my clients’ project summaries specifically for this item, What is the raison d’être for this project? Remember to say no just as much as you say yes. Greg Storey’s ALA foray on a similar topic is worth a read: “Never Get Involved in a Land War in Asia (or Build a Website for No Reason)”.

2. Determine what level of realignment is required. Will minimal changes suffice, or is a total revamp necessary? A solid raison d’être will aid in answering this question.

3. Evaluate user switching costs. What will the impact be to users of the site? How will they be forced, enticed, or encouraged to mentally “switch” to the realigned design and any changes to the user interface, navigation, color scheme, etc.? How painful or painless will the switch be? Will this affect the level of realignment required?

4. Determine the impact on launch plans. Answers to steps 2 and 3 will set the stage for launch and will likely determine such issues as whether a phased rollout or a single deployment is necessary.

Go get ’em, kids. As Mom used to say, “make something of yourself.” Team Realigner is a great place to start.

To Hell With Bad Browsers
http://www.alistapart.com/articles/tohell/

If the design of this site looks relatively coherent, congratulations! Your browser does a good-to-excellent job of supporting web standards like CSS-1, HTML 4.01/XHTML 1.0, and scripting languages. If this site is readable and usable but looks as plain as an Amish coat, your browser does not support web standards. Fortunately, you can easily upgrade to one that does. Before you start shrieking, perhaps you’ll hear us out.

What have you done?

We’ve upgraded the design of A List Apart to comply with web standards, some of which (like CSS1) date back to 1996. This, of course, is the year 2001.

Why doesn’t it work in old browsers?

They were not built to comply with web standards. The content of this site will be accessible in any browser, but the design will only work in browsers that support CSS1.

Why have you done this terrible thing?

For years, the goal of a web that was accessible to all looked more like an opium dream than reality. Then, in the year 2000, Microsoft, Netscape, and Opera began delivering the goods. At last we can repay their efforts by using these standards in our sites. We encourage others to do the same.

To do so, check The Web Standards Project’s Browser Upgrade initiative for tips and support. You can also do this on your own by validating your markup and courteously alerting your visitors to the existence and location of standards-compliant browsers. The Browser Upgrade initiative simply makes it easier for you.

Designing in accordance with these standards does not necessarily mean ending support for old browsers. It does mean looking long and hard at what that support entails. If you are deliberately deforming your markup to accommodate an increasingly small percentage of users, and if that deformation locks out other users (such as people with disabilities, or those who use Palm Pilots, Lynx, screen readers, and other non-traditional browsing devices), you might consider upgrading your standards compliance even if the resulting sites look fairly ho-hum in old browsers. If your site is compliant and the content is accessible to all, you may well have done the right thing.

Why now?

The standards have been around for years. Browsers that support them have been around for six months to a year. If not now, when?

It typically takes 18 months or longer for web users to upgrade their browsers. Many still use browsers, like Netscape 4, that date back to 1997. These folks will only upgrade if we give them a reason to do so.

If enough of us do this, the 18 month pregnancy might be shortened, ushering in a web built on common standards that much sooner. Seems like a worthy goal to us.

Think your crummy design is worth all this?

This is not about graphic design. It’s about the separation of presentation from structure, which will allow us to do amazing things. Like redesign an entire site in hours instead of months. Stop authoring and debugging stupid, browser-specific markup. And support non-traditional browsers and devices, from Palm Pilots™ to screen readers, without building multiple versions of every page. All pretty good stuff.

Who cares?

If you’re a web designer, you do. In six months, a year, or two years at most, all sites will be designed with these standards. (Or they will be built with Flash 7.) We can watch our skills grow obsolete, or start learning standards-based techniques now.

Given the dot-com economy’s recent woes, counting on your existing skills to keep you employed does not look like a promising strategy. Learning to work with emerging technologies is probably a much better plan. We’d like to see all ALA readers stay gainfully employed and productive over the coming years. Paying attention to these issues could help you do that.

If that isn’t enough, consider the new laws about web accessibility. Separating structure from presentation via semantic (X)HTML and CSS layout can help you comply with these laws. Sticking with hacks and workarounds makes compliance that much harder. The temporary downside is that standards-compliant sites may not look great in older browsers. But most users can upgrade their browsers far more easily than people with disabilities can upgrade their eyes, ears, or limbs.

Can 4.0 browsers read your Style Sheet?

Yes, but they bungle it so badly that we’ve used link trickery to turn off styles in these browsers, using the @import directive to link to our style sheet. A Designer’s Journey explains how we did this.

Why can’t you offer backward compatibility?

Old software does not support standards. Didn’t we mention that already? It would be swell if we could have backward compatibility and pure standards compliance. But we can’t. We have to choose. For years, most of us have chosen backward compatibility. But is this really the best choice?

For years, we’ve been taught to be good little web designers, building sites that work in browsers that don’t. Each site we build the old-fashioned way becomes one more dung heap of bad code, one more web destination that will eventually stop working as browsers and standards evolve.

The longer we do it, the more doomed sites proliferate. Thousands of new sites premiere every day. Most of them are built to support bad browsers intead of standards. It’s an epidemic. Enough already. We finally have good browsers. Let’s use them.

Let’s push these new browsers for all they’re worth, discover the remaining holes in their standards compliance, and help browser manufacturers make them even more compliant. Flash designers do this. They push Flash as hard as it will go, butt their heads against its limits, and tell Macromedia how to make it better. As a result, Flash keeps improving. Shouldn’t we be doing the same for the tools that deliver 90% of web content and functionality (i.e., web browsers)? The WaSP thinks so and ALA thinks so, too.

My company has “standardized” on a 4.0 browser.

We realize that many of you are stuck in that predicament. Consider this an opportunity to alert your boss or your IT department to the fact that 1997 browsers are holding back the web. Make them think upgrading was their own idea. That often helps. (If you can’t persuade them to upgrade to a post-1997 browser, and therefore can’t even consider switching to full CSS layout at this time, you can at least use limited CSS to control typography and colors, use as many structural tags and as few nonsemantic tables as possible, and validate your markup and style sheets.)

I can’t afford a new computer, and my old one can’t handle these newfangled browsers.

Standards-compliant browsers need not be bloated and processor-intensive. Many require less computing power than the 4.0 browsers did. We don’t want to name names, but if you check the WaSP’s Browser Upgrades page, you may find one or more browsers that can run on your existing system just fine.

Say what you want, these new browsers won’t work on my 286 machine with 4MB RAM.

Probably not. Then again, if we hasten the adoption of common web standards, we’ll make the web more accessible to all – and encourage the makers of low-cost Internet devices and workstations to support those same standards in their new and affordable products.

Meanwhile, this site complies with standards and works in any browser. It looks better in CSS-compliant browsers, but the content is accessible to any browser or device. It’s also a low-bandwidth design (and even lower now that we can discard 6K of nested table cells), which makes it friendlier for those with slow connections and older equipment.

This site will work in any device that reads HTML. It doesn’t get more user-friendly than that.

JavaScript is evil!

Thank you for sharing. Turn JavaScript off if you like; the site will still work.

Why didn’t you use XHTML?

Laziness, and the need to finish redesigning the site in time for the WaSP’s Browser Upgrades launch. Also, last time we checked, HTML 4.01 was a valid web standard. {Ed. – After one or two HTML 4.01 issues, ALA converted to XHTML.}

Are you on crack, or do you really expect other sites to do this?

Which question would you like us to answer first?

Do you really expect other sites to do this?

Well, we’ve done it. And longtime ALA affiliate the Babble List has just done it too. Numerous site builders have already told us they plan to follow suit. Will your site be next?

You’d be in good company. Many sites are already using Style Sheets extensively – including CNN, ESPN, and Hewlett-Packard. These sites use code that figures out which Style Sheet is best for your browser, and then loads it dynamically. What we’ve done instead is write one style sheet that will work in any browser with good CSS support.

We recognize that not every site can make this change now, and we don’t expect them to. But as more of us begin doing this, others will join. One man with a club is a hooligan. A thousand men with clubs are a regiment.

Why would any sane client agree to this?

Why would any sane client spent half a million dollars on a Flash site without even requesting an HTML version? Beats us, but we can name a dozen companies who’ve done that in the past month alone.

Why would any sane client agree to a site that works only on one platform? Hell if we know, but we’ve seen it happen and so have you.

Supporting standards at the cost of downgrading the visual experience in old browsers makes more sense to us than either of the two practices we’ve just mentioned.

And don’t forget, you’re not limited to sane clients.

Actually, over the past few weeks, some of our sanest, smartest clients have requested or been persuaded to consider standards-compliant designs that separate presentation from structure. Will every client want this immediately? Undoubtedly not. It is a question of audience needs and goals. But starting from the premise that no client will want to do this is defeatist and probably wrong. In our experience, generalizing about clients is as pointless as generalizing about snowflakes. Every client and every project is different.

How do you do this?

Funny you should ask. This week’s companion article explains how we made the transition from an HTML table-based layout to one built with two divs and a style sheet. You might find it useful.

You can also learn about standards here at ALA (start with the articles or topics listed in our sidebar) and from swell publications like Builder.com, Webmonkey, Webreference, XML.com, or straight from the horse’s mouth.

Are you saying that HTML tables are dead?

No. There are good and bad uses for HTML tables. The best use is the intended one: to present tabular data such as might be found in a spreadsheet. But during this transitional period, when some users are stuck with old browsers and new browsers are still perfecting their standards compliance, you might sometimes use tables for layout.

One fair use might be to create a multi-column layout. ALA was able to do a two-column layout without tables, but a three-column layout is not particularly easy to do with CSS alone, though it is planned for CSS-3. Undoubtedly there are ways to create three-column layouts with the CSS support we have now; we just haven’t figured them out yet.

On the other hand, using nested tables to simulate a one-pixel border around an area, or using a table to create a background color for text, is no longer necessary once you use style sheets. And frankly, it’s much easier to type <div id="menu"> than to spend your life debugging HTML table cells.

Have you tried updating a production site like Yahoo! or Amazon to separate the content from the presentation?

We were kinda busy this week. But ALA’s David Eisenberg gave it a shot. After two hours, he had partially converted Yahoo! Weather. Download the zipped, Yahoo Weather file if you’re interested, and don’t say we never gave you anything.

Note to the litigious: we’re not claiming to be associated with Yahoo (we’re not associated with Yahoo), nor do we intend trademark or copyright infringement. The zipped file is merely a teaching exercise, using a well-known (and lovely!) site to see if it can be converted by standards-compliant design methods. We adore Yahoo and weep with admiration for Yahoo’s lawyers. We wish Yahoo’s laywers and their families a thousand years of health and prosperity. It’s good you wished those bad men into the corn field.

Two hours, huh? And it’s still unfinished?

If you’re implying that switching from old-style web design methods to new ones isn’t always easy or automatic, you’re right. Mostly this is because few of us understand CSS on a truly deep level. Even those of us who think we get it still have our training wheels on.

Working with HTML tables, though a demented process, is now second nature to most of us. Understanding and manipulating the CSS box model, and using CSS techniques such as float to control positioning, requires learning and patience. It also helps if you’re willing to forego slavishly duplicating an existing table-based layout, and let CSS be CSS. Above all, be willing to experiment, and don’t curse the new simply because it is different.

Have you rebuilt the entire ALA site?

No, we are merely using CSS layout as we go forward from this issue.

You suck, and you’ve just lost a reader.

We’re sorry you feel that way. Before you leave, why not share your feelings in the ALA discussion forum associated with this article?

{This editorial was concocted by Zeldman, with kibbitzing from J. David Eisenberg. This magazine was redesigned by Zeldman with massive power thrust assistance from Anonymous Donors A and B. Keep Watching the Skies.}

Translations
Russian (Webmascon.com)
French (Pompage.net)

They Shoot Browsers, Don’t They?

http://www.alistapart.com/articles/theyshootbrowsers/

Proprietary innovations by browser vendors are nothing new. Internet Explorer alone has given us XMLHttpRequest, innerHTML, and colored scrollbars. In each instance, we were free to use or ignore these non-standard extensions. Now Internet Explorer is introducing a new proprietary technology in the shape of version targeting. But this time, the only way to opt out of using the technology is, perversely, to use it.

Ball of confusion

When I first read about version targeting here in the hallowed pages of A List Apart, one point confused me. At the end of Eric’s heartfelt article detailing his reaction to the proposal, the final section seemed to suggest that IE8 would, by default, behave identically to IE7. “That can’t be right,” I thought. Surely I was misreading Eric’s words. To clarify the situation, I asked Chris Wilson what would happen if IE8 were to encounter a valid, well-formed document with a strict DOCTYPE. My worst fears were realized when he confirmed that the browser would behave exactly as if it were its predecessor.

This is gobsmackingly audacious. Imagine a new version of Word that behaves exactly like the old version of Word unless the document it is processing contains a hidden instruction to unlock any new features. That’s what Microsoft is demanding that web developers implement. Unless you explicitly say otherwise, IE8 (and IE9 and IE10, ad infinitum) will behave exactly like IE7.

My incredulity couldn’t be assuaged by the obvious explanations for this behavior—that Microsoft was being stupid or “evil.” The Internet Explorer team is made up of good standards-savvy developers. They must have a good reason for proposing a solution which, on the face of it, appears so crazy.

Destroying the web to save it

Microsoft’s proposal was triggered by a traumatic event: the upgrade from IE6 to IE7. Internet Explorer 6 languished in the doldrums of non-development for many years. Eventually, spurred on by the encroaching market share of rival browsers, Microsoft released Internet Explorer 7 sporting far better CSS support than the previous version.

Because IE6 stagnated for so many years and because it remained the market leader, a whole generation of websites had emerged that were coded to the quirky but predictable vagaries of that browser. These websites appeared to “work.” That is, they looked fine in the most popular browser on the market. But when IE7 was released, these websites were inevitably rendered differently. IE7, with its improved support for Web Standards, rendered these sites in much the same way as any other standards-compliant browser. Despite a concerted campaign to encourage developers to use conditional comments instead of browser-specific hacks, Microsoft received a barrage of complaints from website owners upset at the way that IE7 had changed the game. This is what the Internet Explorer team are referring to when they talk about “breaking the web.”

That’s a loaded phrase that doesn’t stand up to closer scrutiny. Firstly, what’s at issue here is not “the web” but “some websites”. Secondly, rather than “breaking”, it’s more accurate to say “displaying differently.” Finally, it’s important to remember that we are talking about how websites are displayed in one browser: when the IE team talk of “breaking the web,” what they really mean is that their browser will display documents in much the same way as other modern browsers do. Would that really be such a bad thing?

Won’t somebody think of the children?

On the face of it, being the market leader is something to aspire to. But think of how much responsibility that entails. Would you really want to innovate and push the boundaries when even the smallest changes could cause disruption for thousands of your customers? This is exactly the kind of paralysis that Microsoft is trying to break out of. The version targeting proposal is a good solution to this deadlock. With the addition of one meta element, websites can specify exactly how they should be rendered (in one browser).

Furthermore, had Microsoft implemented the X-UA-compatible instruction in IE7, they could have saved themselves a whole mess of trouble. Instead of requiring developers to revisit their style sheets and strip out their browser-specific hacks, they could have instead told website owners to simply add one line to the head of their documents. While it’s hard to imagine that the move from IE7 to IE8 will cause the same upheaval, it’s reassuring to know that Microsoft has thought ahead. Version targeting allows site owners to freeze rendering (for one browser) to a specified browser version. That’s a good thing. While it probably won’t affect standards-savvy developers like you or me, it offers a simple solution for site owners who don’t want to worry about the future. Better still, the fact that the X-UA-compatible instruction can be sent as a header means that this issue can be taken care of by sysadmins with one small tweak to their server configurations.

But even that is asking too much, according to Microsoft. Instead of asking that developers who want to opt out of future improvements do so with the addition of a meta element or header, Internet Explorer expects standards-savvy developers to actively opt out of version targeting… by using version targeting.

The reasoning here is that less savvy developers shouldn’t have to worry their little heads about adding one extra line to their documents. Instead, they should be encouraged to continue to write to the quirks of one specific browser version from the market leader. That their documents will “break” in other browsers is not Microsoft’s problem. The counterpoint to this condescending worldview is that standards-aware developers are the ones best placed to add a single line of markup to their documents—though, for some unexplained reason, the instruction for up-to-date rendering (IE=edge) is strongly discouraged.

This strategy is doomed to failure. Standards-aware developers, by their very nature, will object to adding a line of unnecessary markup to their documents just to get one single browser to behave as it should by default.

Fear of drowning

While most of the web development community saw the release of IE7 as a welcome return to form, within the corridors of Redmond it was viewed as a failure. Microsoft simply cannot afford a repeat of the IE7 upgrade. Version targeting is a technology born of fear. A fear of “breaking the web”—which really means “rendering some websites differently in one browser”—has prompted the draconian default behavior.

Whether this fear is well-founded or not depends on just how drastically IE8 is going to “break” existing websites. Personally, I’m rather puzzled: what exactly are they planning to add in the next version of their browser to make the web asplode? If IE8 is going to differentiate itself from its predecessor by having better standards support, then surely we can assess how it will render websites by simply viewing those websites in a standards-compliant browser like, say, Firefox, Safari or Opera.

Lonely at the top

There was a time when Friendster was the biggest social networking site on the web—MySpace and Facebook were little more than distance glimmers on the horizon. There was a time when Netscape Navigator was the undisputed king of browsers and Internet Explorer was laughable challenger playing catch-up. On the World Wide Web, the status quo is a mutable, shifting thing. The proposed default behavior for version targeting is predicated on events that took place during a short span of years when Microsoft, having emerged as the top dog, pulled the plug on its own browser. There is an unspoken assumption that the only meaningful way the web is experienced is through one browser: Internet Explorer.

We are being told that the default version targeting behavior is necessary because without it, the web will turn into a messy crime scene of breakage (in one browser). If Microsoft are to be believed, the self-crippling default behavior of IE8+ is necessary to save the web (in one browser). Whether you agree or disagree with the default behavior comes down to faith: faith in Microsoft accurately foretelling the impact that IE8 will have.

I would much rather base my judgement on facts. There is an easy way for Microsoft to prove the necessity of mandatory version targeting: release a beta version of IE8 with version targeting disabled by default. Then we can see just how badly the web breaks some websites render differently in one browser.

I’ve listened to and understood all of the arguments in favor of the proposed default behavior: all of them assume that without self-crippling, IE8 will make a mess of a significant portion of the web. If that fear is borne out by an uncrippled beta release of the browser, I will back the proposed default behavior. Until then, I ask that Microsoft honor their promise from many years ago and allow their browser to render a valid, well-formed document with a current DOCTYPE to the best of its abilities.

Future imperfect

Version targeting is not a bad idea. The choice of delivery mechanisms—meta element or server header—is inspired. As an optional feature, this could prove to be a real lifesaver in some development environments. As a mandatory millstone however, it strikes a blow against progressive enhancement. [1]

The proposed default behavior for version targeting in Internet Explorer solves the problem of “breaking the web” in much the same way that decapitation solves the problem of headaches. In its current state, version targeting is a cure that will kill the patient. Version targeting could have been an opportunity for Microsoft to demonstrate innovation. Instead, the proposed default behavior demonstrates a fundamental misunderstanding of the World Wide Web, a place that according to its creator, Sir Tim Berners-Lee, will always be “a little bit broken.”

Footnote

[1] On the plus side, as-yet unpopular DOCTYPEs such as HTML5 can be used to trigger up-to-date rendering from future versions of Internet Explorer. That’s reassuring for the future but HTML5 is not ready for use today—any DOCTYPE that still includes the FONT element still has some issues that need to be worked out. Besides, once HTML5 is widely deployed, Internet Explorer will probably freeze its rendering for those documents too.

Where Our Standards Went Wrong
http://www.alistapart.com/articles/whereourstandardswentwrong/

A few years ago, Joe Clark famously wrote the following:

If your site has valid code or something trivially close to same, you are working with, and within, Web standards.

If you serve up tag soup or any document with myriad validation errors, you are merely using CSS layout….The matter is now settled.

Almost exactly one year later, Doug Bowman had a different take (emphasis mine):

We don’t point out validation errors on public redesigns anymore. We know a valid site is such a tiny part of any overall measure of success. Validation is something I only do on my own work now.

Here we have two well-known standardistas, both of whom have done (and will do) more for the adoption of standards than this author ever will. Yet both have different takes on what role validation plays in designing for the web. In fact, they perfectly represent the division that exists between standards advocates today. You probably find yourself taking one of two positions on validation:

1. You take a hardline stance, rightly stating that if we fail to follow the conventions of a language, then we’ve produced something altogether different and, well, invalid.

2. You take a pragmatic view, rightly stating that the invalid code generated by broken tools and third-party code shouldn’t negate one’s overall commitment to web standards.

So if both views are right, where does that leave us?

The problem at hand

We can all agree that the realities of the web make it hard to build a standards-compliant site. Once the client’s CMS, outdated WYSIWYG editors, and third-party advertising code have finished with once-valid markup, things begin to look ever-so-ugly under the hood; this leads many to suggest, like Bowman, that an insistence on validation is at odds with commercial web design. Given that most of these invalid sites look fine in a browser, the amount of time and money required to produce perfectly valid final code seems not only prohibitive, but pointless.

Valid markup has become equated with two things nobody wants: impracticality and implausibility.

Refining the message

If it weren’t for the early days of standards advocacy, for sites like the CSS Zen Garden, Wired News, or Fast Company, we wouldn’t be as far along as we currently are; heck, I’d probably still be a self-hating spacer.gif slinger. Despite those successes, our fractured take on validation stems partly from the wonderful evangelism that got us here.

Whenever I conduct a training session, I poll the room to see why the audience uses or plans to use web standards. The responses typically read like a doctrine that my generation of web designers have been raised on. Namely, that building with web standards can…

- shorten development cycles, as we no longer have to slog through through six layers of nested tables to build site templates.

- lower maintenance costs, as the CSS Zen Garden showed us.

- decrease page weight, which in turn reduces page load times and dramatically lowers bandwidth costs (we’ve Mike Davidson’s excellent ESPN.com interview to thank for those metrics).

These are, I think, the “sexier” benefits of web standards, the bulletpoints we’d use to sell prospective clients on CSS-/XHTML-driven designs. And with good reason: these are all excellent, compelling points. No sales pitch should leave home without ’em.

Noticeably absent from the list is any mention of why we should adopt standards, or what that process actually entails. I mean, I’m sure we can list benefits of producing valid code, such as:

- A proven increase in a site’s accessibility,

- The promise of device independence,

- The presence of a metric against which an individual or a team’s production can be measured, and

- The knowledge that your site is future-proof, displaying in any standards-compliant browser yet to be invented.

But the sum total of those points doesn’t exactly scream “compelling business case.” When you’re speaking to a mid-level marketing executive about standards, which would you rather lead with: saving terabytes of bandwidth, or investing in device independence?

Yeah. That’s what I did, too.

Yet while the benefits of valid code may not be glamorous, we can—and should—talk about them. Validation isn’t an end result or a final deliverable; it’s an ongoing process that continues long after a site launches. If we don’t put the proper tools and commitment in place, our work will start looking like a late ’90s throwback, and if we don’t provide guidance and education on validation, the polished, perfect pages we produced will be snapped into software that’ll produce tag soup in seconds flat.

So how can we speak about validation in a way that’s compelling to our clients?

The hidden cost

Validation might not have been the sexiest selling point for standards, but it does have very real fiscal benefits. In the past couple years of running my own practice, I’ve become slightly obsessive about tracking my time, especially when it’s spent dealing with bug reports. When an issue comes in, I note the error and the account, and start the timer. Once it’s resolved, I note the cause, stop the timer, and move on.

Toward the end of my first year in business, I noticed that more and more of my time was spent working around invalid code. Layout issues that would have been trivial to fix in a valid, error-free template would take significantly longer to debug in a live page that had a few hundred validation errors. It was a matter of figuring out which parts of the page weren’t causing the errors, so I could focus on fixing the problematic section. But when the page’s markup has three or four hundred validation errors, this process quickly becomes a time sink. A necessary one, but a sink nonetheless.

So by year’s end, I found that approximately fifteen percent of my time was spent mired in invalid code. As an independent designer/developer/something, I’m grateful for all the work my clients send me. Still, what if I was a salaried employee? If IT departments conducted a similar audit, I’m confident they’d find similar numbers. And this kind of auditing needs to happen. Invalid sites may look the same as those built on a foundation of valid, well-formed code, but in my experience, they invariably cost more to maintain. This is the silent weight of invalid code, a hidden cost we don’t discuss nearly enough.

Web two-point-next

None of this changes the here and now. To be honest, the pragmatists are right: that for the most part, validation and commercial web design are polar opposites. But the tools are evolving to the point where we can begin moving beyond validation as a roadblock, and CMSes like WordPress and Slashcode are dedicated to producing standards-compliant code; visual editors such as Dreamweaver and (more recently) Microsoft Expression Web almost stubbornly refuse to produce invalid markup. So where do we go from here?

Pitch process, not code

In recent months, I’ve been relearning how to sell standards. I still touch on the exciting bits (the lighter pages, the lower maintenance costs, and so on), but I don’t shy away from selling validation’s role in unlocking the real savings of web standards. And it’s been an easier sell than I’ve thought: once you’ve shown a client how standards can improve their sites’ accessibility, keep it future-proof and device independent, and lower maintenance costs, they’re usually ready to listen.

And that’s where the real conversation begins. By considering your client’s production workflow and the software that supports it, you and your client will be better able to identify what could break your joint commitment to standards — and as a result, they’ll be better able to fix these issues themselves.

Shop smart: shop standards

Companies like Adobe and Microsoft have recognized the growing market for standards compliance, and openly tout their products’ W3C-friendliness in the sales material. But despite that silver lining, most CMS tools and online advertising companies are spewing out code that would make Netscape 3 proud.

This is where the lone consumer can move mountains. When meeting with a prospective vendor, our clients need to ask if the product is standards-compliant, much as they might ask if an ad serving solution provides targeting information, or if a CMS is J2EE compliant. Standards should be an equally weighted part of any decision-making process—and if we remind our clients of the financial benefits of validation, it will be.

Same sandbox, same struggles

But in all honesty, the real work begins with us. Regardless of whether we find validation impractical or imperative, the infighting in the standards community is the biggest obstacle to real progress. Instead of trying to understand what factors make both sides agitated, we’ve vilified the people on the other side of the argument. We need to identify what’s making 100% validation so expensive and difficult, and work on removing those factors.

As our contribution to that effort, we’ll be discussing common validation killers and ways around them in an upcoming A List Apart article. You can contribute by using this article’s forum to bring up common obstacles to validation and the workarounds or process changes you’ve used to get past them.

Samuel Johnson once said, “Where there is no difficulty there is no praise.” Personally, I think that Sam would’ve sung a different tune three minutes into debugging his first CSS layout, but the man has a point: we can’t fall prey to complacency.

In a perfect world, clumsy software and bad workflows wouldn’t break our code, and validation would just happen. But until I also get that magical flying pony I asked for, we’ve got some work to do. After all, true standards compliance is only as impractical or implausible as we make it. Given how far we’ve come in the past few years, this next challenge seems like a trivial one indeed.

Let’s get to work.

Prefix or Posthack
http://www.alistapart.com/articles/prefix-or-posthack/

As CSS browser support increases, including impressive strides by the IE9 team, more and more authors are plunging into CSS3. As they do so, they’re facing vendor prefixes—the -*- properties like -moz-border-radius, -webkit-animation, and so on.

Perhaps inevitably, there’s been some grumbling about these prefixes. There have been calls to drop them, or to collapse all the vendor-specific prefixes into a single prefix like -beta-. The primary pushback is that nobody really wants to write the same thing four or five times in a row just to get, say, rounded corners on an element.

While such grousing is understandable, it is exactly the inverse of what should be happening. We ought to praise vendors for using prefixes, and indeed encourage them to continue. Beyond that, I hold that prefixes should become a central part of the CSS standardization process. I do this not for the love of repetition, but out of a desire to see CSS evolve consistently. I believe that prefixes can actually accelerate the advancement and refinement of CSS.

Look back in horror

To understand why we have vendor prefixes at all, it’s instructive to look back at the box model, which almost killed CSS before the turn of the millennium. Inconsistent box model implementations created a crisis. To escape the danger, we had to build an entirely new behavior on top of a markup feature and invent a whole class of hacks.

For the young whippersnappers in the audience who missed all the fun, what happened was this: In the first round of browsers that supported CSS, Netscape implemented the box model found in the CSS specification. That meant that width and height referred to the width and height of the content area. But Internet Explorer implemented the intuitive box model, which meant that width and height declared the dimensions of the box’s outer border edge.

Whichever of the two you think better, the fact remained that there were two major browsers with large user bases that were completely incompatible with each other. It was the late 1990s, we were fighting like hell to leave behind the morass of “this site best viewed in…” badges, and here we had a situation where a layout that worked fine in one browser could completely fall apart in another.

Compounding the problem was that neither browser could change its behavior to mirror the other. Assume for a moment that the IE team decided to change their CSS support to reflect the specification. To do so would mean that tens, even hundreds of thousands of sites that worked in IE would break—would quite literally fall apart, visually speaking—in the “fixed” version. While the standards community would have applauded the move, the rest of the world would have written off the browser as unusable. And even if the Working Group decided to change the specification to match IE’s behavior, Netscape would then have faced exactly the same problem.

Thus DOCTYPE switching was created. The entire regime of “standards mode” and “quirks mode” was born of this problem. The solutions to other problems were rolled into DOCTYPE switching, but the box model triggered it. Think about it: because two vendors did things differently, browsers now have to maintain two different primary rendering models and choose which to use based on an SGML declaration that says nothing about rendering.

Furthermore, the first wave of CSS hacks were devised to address exactly the same problem. The classic example of the genre gives it away in the title: The Box Model Hack. In fact, the hack itself was based on flaws in syntactical parsing of voice-family values, but nobody ever called it “the voice-family hack.”

The funny part is that this wasn’t the only instance where a box model inconsistency led to trouble. Not long after DOCTYPE switching saved CSS, the Explorer team implemented some features of CSS positioning. One of the properties they implemented was clip. Having learned their lesson with the box model brouhaha, the engineers at Microsoft paid very close attention to the specification and did what it said.

Shortly after they shipped it publicly, the CSS Working Group massively changed the way clip worked. The syntax looked exactly the same, but yielded very different results.

Once more, the specification clashed with the behavior of a publicly available browser (or, if you prefer, vice versa). The eventual resolution was to revert to the earlier behavior and drop the new behavior entirely. That renders clip effectively useless on any element with unpredictable height and width—which is to say, any normal-flow, non-replaced element such as a div or a paragraph. Although other solutions were proposed, they never came to pass, and clip withered away.

Imagine a different outcome

Suppose that instead of implementing clip, the IE team had implemented -ms-clip. In that case, a behavior change in a later specification wouldn’t have been so difficult to overcome. Because a vendor prefix marks a property as “in progress,” it’s much easier for a vendor to go back and change it. Thus the IE team could have changed the way -ms-clip worked in their next release, explaining to developers that they were updating their experimental implementation to match changes to the specification.

Even if they had decided that that was impossible to do, the damage of the “bad” implementation would have been quarantined in the prefixed version of the property. Other vendors could have implemented the new version of clip (using their own prefixes), unaffected by what the IE team had done. A single vendor could not pin the specification and other vendors in place by their actions.

This is the promise that prefixes provide: A way to mark properties as “in progress,” and so not necessarily guaranteed to always act the same in future releases; an out for vendors who need to make those changes; and a defense against bad or premature implementations that happen to ship first. They add sorely needed flexibility to the advancement of CSS.

Of course, we could just say: “When a browser is wrong according to the specification, then they have to change even if it breaks the layout of web sites.” With prefixes, that’s a lot easier to accomplish, thanks to the warning that prefixes embody. Without prefixes, it’s very difficult or even impossible. Microsoft never did change the way it handled width and height in legacy pages—instead, it used DOCTYPE switching to behave differently on new (theoretically more “standards compliant”) pages. It was a useful and necessary trick, but that kind of trick only works once.

Even now we suffer

Lest you think that all this silliness is an artifact of history, here are two cases of inconsistency happening right now:

- Mozilla and WebKit browsers render box-shadow blurring very differently, and neither fully conforms to the specification. As I write this paragraph, a lengthy and heated debate is raging on the www-style mailing list. At least one, and possibly both, implementations will have to change the way they handle shadow blurring to achieve interoperability. The same holds true for any Microsoft or Opera implementations.

- Mozilla and WebKit browsers both support gradients, but they use radically different syntaxes to achieve the same basic result. Now imagine a world where the vendors had implemented gradients without the prefixes. You would have three choices:

1. Pick which browser gets a gradient and which one doesn’t.

2. Use CSS hacks or browser sniffing to serve up different styles to different browsers.

3. Walk away from using gradients entirely.

And there are three choices here only because the gradients use wildly different value syntaxes, thus opening the door to option number one. In a case where two implementations use the same value syntax but have very different effects—as was true with clip—then there are really only the last two options: hack and sniff to send totally different styles, or just walk away.

We’ve seen this movie played out many times over the history of CSS. There’s no reason to want to see it again. It was bad enough the first dozen times.

Prefix or posthack

But are prefixes really any better? After all, it’s been said that vendor prefixes are the new CSS hacks. As Aaron Gustafson pointed out in a recent article, this:

-moz-border-radius: 10px 5px;
-webkit-border-top-left-radius: 10px;
-webkit-border-top-right-radius: 5px;
-webkit-border-bottom-right-radius: 10px;
-webkit-border-bottom-left-radius: 5px;
border-radius: 10px 5px;

…is reminiscent of this:

padding: 10px;
width: 200px;
w\idth: 180px;
height: 200px;
heigh\t: 180px;

In terms of repetition and annoyance, yes, the two are very much alike. But they’re fundamentally different in this way: Prefixes give us control of our hacking destiny. In the past, we had to invent a bunch of parser exploits just to get inconsistent implementations to act the same once we found out they were inconsistent. It was a wholly reactive approach. Prefixes are a proactive approach.

Furthermore, prefixes are a temporary hack. As time goes on and implementations become consistent, browsers will drop the prefixes. From then on, authors will be able to write one line for border-radius instead of six-plus lines of CSS. Without them, we’re just waiting for the next botched implementation that forces us to support it through hacks for years upon years.

That’s why creating a unified prefix, such as -beta- or -w3c-, is at least half a step backwards. It would preserve vendors’ ability to mark properties as “in progress” and make changes as needed. Unfortunately, it would completely rob authors of the ability to excise, or even feed a different value to, one particular browser if it has a botched implementation. From an author’s point of view, a unified prefix is no better than a world without prefixes.

I sometimes feel the same way about pre-processor methods to handle prefixes, whether on the server side (using tools like Less) or client side (any number of JS frameworks). When using these tools, it’s possible to just write border-radius declarations and have the tool expand that into the requisite list of prefixed declarations. On the one hand, they’re a very useful way to reduce typing and keep the authoring neat and clean. On the other, they’re just like a unified-prefixed or unprefixed world: one bad browser implementation away from breaking pages.

The advantage is that if something goes haywire, any author can go back, disable the pre-processor, and write out the prefixes by hand. Alternatively, the pre-processor can be updated to handle the problem. Either way it’s a little more cognitive overhead for the author, but not too much.

The downside is more philosophical, but it’s no less important for that: By hiding the prefixed properties behind a processor, authors may forget that what they’re using is experimental and subject to change. Cognitively, they may start to treat what they’re using as settled and stable when it may be nothing of the kind.

Make prefixes really matter

I believe so firmly that vendor prefixes are a good thing that I’m prepared to take the next logical step: Vendor prefixes should be made more central to the standards process. They should be required of newly implemented properties and should be the mechanism by which interoperability is declared.

Here’s what I mean: Suppose someone invents a new property called text-curl. Immediately, three vendors implement it. Each of them should be required to add a vendor prefix to their implementation. Thus, we’d see things like this:

h1 {
-webkit-text-curl: minor;
-moz-text-curl: minor;
-o-text-curl: minor;
text-curl: minor;
}

Over time, the vendors refine their implementations in response to bug reports and clarifications by the Working Group. Eventually, the Working Group decides that two of the three are fully interoperable. Those implementations then get to support the bare text-curl. The third does not.

At that point, authors might decide to simplify their styles like so:

h1 {
-webkit-text-curl: minor;
text-curl: minor;
}

Instead of hacks proliferating over time, they’re peeling away. Eventually, we’ll only need a single text-curl line.

So what happens when a new implementation debuts? It uses the prefix in its first release, no matter how many interoperable implementations already exist. That might mean that we’d have to go back and change the CSS to say:

h1 {
-ms-text-curl: minor;
text-curl: minor;
}

Then, as soon as the Working Group deems the implementation of -ms-text-curl interoperable, the prefix can be dropped in the next release of IE. At that point the CSS can be reduced to a single, unprefixed line. Again, the number of hacks dwindles over time.

Of course, each of those vendors will continue to support the prefixed properties, so even if we don’t prune the prefixed lines, each supporting browser will recognize the unprefixed property and use it (since it comes after the prefixed declaration). For any browser that implements a prefixed version that doesn’t manage to get to an unprefixed state, its own prefixed property will still work. Even if the CSS is never touched again, it will continue to function.

Having said that, return for a moment to the time when the Working Group said that two implementations were interoperable and could thus drop the prefixes. That serves two purposes. First, as I said before, it marks a property as having enough interoperability to allow progress in the standards process.

But the other thing it does—and this is arguably more important—is force the vendors and the Working Group to work together to devise the tests necessary to determine interoperability. Those tests can then guide those who follow, helping them to achieve interoperable status much faster. They could literally ship the prefixed implementation in one public beta and drop the prefix in the next.

This reverses the way things are done now. As it stands, the process is set up so that when any CSS module reaches the Candidate Recommendation stage, vendors can drop the prefixes from properties in that module. But that just opens us up to the possibility of another botched implementation and a future of hacks to work around the error.

As proposed here, a module would be permitted to reach Candidate Recommendation once all of its properties had at least two unprefixed implementations in the wild. Any implementations that came after would start prefixed and drop the prefix once they had proven, in the wild, that their prefixed implementation matched the existing unprefixed implementations. Instead of being a minor gamble, unprefixed properties would come as close to a guarantee as anything we’ve seen to date.

Conclusion

If the history of web standards has shown us anything, it’s that hacks will be necessary. By front-loading the hacks using vendor prefixes and enshrining them in the standards process, we can actually fix some of the potential problems with the process and possibly accelerate CSS development.

So the next time you find yourself grumbling about declaring the same thing four times, once for each browser, remember that the pain is temporary. It’s a little like a vaccine—the shot hurts now, true, but it’s really not that bad in comparison to the disease it prevents. And in this case, you’re being vaccinated against a bad case of multi-year parser hacking and browser sniffing. We suffered through that long plague once already. Prefixes will, if used properly, ward off another outbreak for a long time to come.

Translations
Italian (italianalistapart.com)

Web Standards for E-books
http://www.alistapart.com/articles/ebookstandards/

The internet did not replace television, which did not replace cinema, which did not replace books. E-books aren’t going to replace books either. E-books are books, merely with a different form.

The electronic book is the latest example of how HTML continues to win out over competing, often nonstandardized, formats. E-books aren’t websites, but E-books are distributed electronically. Now the dominant E-book format is XHTML. Web standards take on a new flavor when rendering literature on the screen, and classic assumptions about typography (or “formatting”) have to be adjusted.

HTML isn’t just for the web

It’s for any text distributed online.

Technology predictions can come back to haunt you, but this one I’m sure about: The fate of non-HTML formats has been sealed by HTML5 and the iPad. People are finally noticing what was staring them in the face all along—HTML is great for expressing words. The web is mostly about expressing words, and HTML works well for it. The same holds true for electronic books.

- E-books are usually not “websites.” You can post your book copy as web pages, but the E-book as a logical entity is not a website.

- ePub, the international E-book standard, is HTML (XHTML 1.1 with minor exclusions). Two other formats – certain kinds of “true” XML and DTBook – have equal status in ePub; most developers will use XHTML.

- Every E-reader under the sun except the Amazon Kindle can display ePub electronic books. (A Kindle can show you its own variant, .AZW, of a variant of HTML [Mobipocket]; that’s two steps removed from the real thing. A Kindle can also convert HTML to displayable format, presumably AZW.)

It may be unseemly to dance on graves, but HTML wins again.

HTML doesn’t work for all documents, since it lacks important structural features. (HTML5 addresses some of those deficiencies but won’t help today’s E-books.) HTML does work for huge numbers of documents, many of which we call books. Bet against HTML for online distribution and you’ve backed the wrong horse.

Philosophical digression

Every article on electronic books must ritually address the concept of book and the relation of form to book. In this case I will acknowledge the remarks of internet pioneer Jaron Lanier, who warns in his book You Are Not a Gadget that early software decisions can dramatically constrain what later becomes possible. (Others have stated the same thing—the type designers at LettError complained a decade ago about how software tools constrain ideas.)

I am articulating an HTML-triumphalist view of E-book production. By backing what I feel is obviously the right horse, I am contributing to the strangulation of new or uninvented forms of the book. Advocacy of one digital format is always a process of eugenics; other formats will never be born or will die prematurely. I’m doing that right now by downplaying the importance of XML and DTBook variants of ePub.

I am happy to contribute to the death of “vooks” and other multimedia websites masquerading as books. (I do not want a rectangle of video yammering at me while I’m trying to read.) They’re like animated popunder ads in that no actual “user” wants them, but somebody with an agenda does. Exterminating that species is something to which I am proud to contribute. For other forms of books, advocating strict HTML markup will cause as-yet-unknowable harm.

I nonetheless maintain that typical works of fiction, and many works of nonfiction, can be expressed very well indeed in HTML E-books. To attain this degree of expression, we have to rid ourselves of print conventions that do not work in electronic media.

Another way of saying this is that books should be as bookish as possible under the circumstances. Printed books need to take advantage of everything print has to offer (resolution, tactility, portability, collectibility), while electronic books must do likewise for their own form (economy, copyability, reflow, searching and indexing, interlinking).

Two problems to be solved

If HTML is the dominant markup language for most E-books, then web standards come into play. Frankly, I don’t want to relive the late 1990s and early 2000s, in which standardistas had to come up with one slightly different way after another to convince developers to code their sites properly. You still don’t see valid HTML very often on real-world sites, but tables for layout are largely a thing of the past and semantics are hugely improved. Maybe pure web standards did not “win,” but whatever web standards aren’t definitely lost.

It would be overconfident to assume that this success will immediately replicate itself with E-books. Publishers (there are barely any “developers” in the E-book sphere) will not automatically do the right thing, and so far they seem to be doing exactly the wrong thing.

If we want publishers’ code in E-books to be as good as standardistas’ code on actual websites, we’ve got two problems to solve.

Semantics

The underlying code for typical ePub electronic books is XHTML 1.1. That means you need valid code with no errors: the ePub standard requires XML error handling, so you can’t get away with HTML 4.0–style tag soup.

Novels and many nonfiction books are semantically simple. Most can get by with a tiny range of tags:

- P (but don’t mark up everything as a paragraph)

- Headings (arguably H1 should be reserved for the title of the book)

- Emphasis (perennial debates over semantics of CITE vs.EM vs. I may hereby resume)

- Lists
- BLOCKQUOTE
- Images (with mandatory alternate text)

Even nonexperts can be readily trained to recognize simple structures like these. But people untrained in even the simplest markup are the problem.

Production methods

For E-books to have good code, good code has to be found at every stage of the production process. That is not how things are done right now.

Thin spaces between dots in an ellipsis become question marks. For more examples of typographic tragicomedy in E-books, see this article’s Sidebar.

Hundreds, if not thousands, of commercially available E-books from legacy publishing houses were converted to “electronic format” by scanning printed books and turning the resulting OCR book copy into text files. (Indeed just text files, not structured markup.) Copy errors are so rampant that E-books are the first category of book in human history that could actually be returned as defective. This in turn has led to the equally rampant mythology that E-books are all about “formatting.” (They aren’t: they’re about structured text with styles attached.)

Why would publishers scan hardcopies? Aren’t all books produced on computers these days? Yes, but do publishers own those files, or do various freelance designers? Can anybody even find the files? What if they were saved in an old version of Quark Xpress or Ventura Publisher? Instead of rooting around in files resident on computers they don’t really understand anyway (these are book people), publishers find it easier to just send print books out to low bidders for scanning.

Now there’s a cottage industry selling conversion services for E-texts. One competitor in the E-book “space,” Kobo (né Shortcovers), promises conversions for “as little as $29… per title.” Another competitor, eBook Architects, converts (“to Mobipocket/Kindle first”) for about $400 in typical cases. The New York Times estimated that to “convert the text to a digital file, typeset it in digital form and copy-edit it” costs a mere 50¢.

Fees this low are unsustainably low and cannot possibly lead to good markup and clean copy.

This isn’t hypothetical. We have countless examples to look at right now (see sidebar).

Race to the bottom

E-books are barely beginning to catch on and already the most important parts of an E-book—copy and markup—are suffering from a race to the bottom.

What’s the solution? The canonical format of a book should be HTML. Authors should write in HTML, making a manuscript immediately transformable to an E-book. A manuscript could then be imported into that fossil the publishing industry refuses to leave behind, Microsoft Word. (MS Word’s Track Changes feature has become a kind of methadone for an addicted publishing industry.)

To typeset a print book from this source, translating twice (HTML → Word → InDesign) is a proven workflow with the added advantage of outputting tagged PDFs with good semantics.

Now, the foregoing is so optimistic as to be ridiculous. Authors are not going to start writing in HTML, let alone the full-on XML that Ben Hammersley has called for. Book copy will continue to be saved as MS Word, Xpress, and/or InDesign files. Though mangled and inadequate, such copy will then be “exported” for E-book “formatting.”

Instead of avoiding errors to begin with, the publishing industry may choose to fix errors after they’re made—but only if authors, especially big-name authors with ruthless literary agents, complain loudly until publishers have entire imprints’ E-books repaired. This will not result in authors writing good strong HTML for new books, but will clean up part of the mess.

Ongoing E-book experiments

There’s a lot of activity in the electronic-book “space,” from virtual think tanks like the Book Oven to crowdsourced copy-editing at Bite-Size(d) Edits, to name two sites comanaged by impresarios Hugh McGuire and Stephanie Troeth. Two other projects are working on the possibilities of standardized structured code in the E-book process.

- ePub Zen Garden aims to do for electronic-book layout and type what CSS Zen Garden did for web design, which was a lot. The new Zen Garden could benefit from the experience of the old Zen Garden by offering more than one canonical text to style, but the concept is a proven winner. (You can help by contributing.)

- Simon Fraser University’s Thinkubator is slowly developing a project that expands on InDesign’s ability to save a complete round-trip representation of an InDesign file as XML. Converting XML output to ePub XHTML may not be trivial, but it isn’t impossible and could be automated.

At that point, we wouldn’t have to retrain authors to write in HTML; we’d just have to retrain desktop publishers to use structural, not presentational, style names (Heading 2, Emphasis, Blockquote) for later translation. For code-competent authors, this same production method accepts XHTML as a source file, which can then be translated to a native InDesign document or PDF without intermediary files.

Separation of content and structure has never been more important
ePub uses XHTML 1.1 as a markup language. You may also associate stylesheets—explicitly CSS2, not any other version. As such and as ever, markup must be separated from presentation.

But E-book creators come from the publishing business. They’re writers, editors, desktop publishers. They will naturally attempt to hack and deform code and text to reproduce features from print layouts that should really be governed by CSS, handled by the E-book reader, or forgotten about entirely. In some cases, you actually have to alter the text of a book to make it work as an E-book; in other cases you must not do that.

Tasks CSS must handle

- Drop caps. It’s easy to find commercial E-books the first word of which has an error: The word is written as its first letter followed by a space and the rest of its letters. It’s an artifact of drop caps, which in desktop publishing are usually rendered as a separate letter disconnected from the rest of the word. In standards-compliant E-books, you have to forget about drop caps or use a CSS selector (:first-letter).

The same goes for type treatments on the first words (often the first n words) of a chapter or section. Maybe the first five words use small caps or bold. There is no way to do that in CSS as yet, though you can style the entire first line of a paragraph. You might have to wrap the first n words in a SPAN with a classname (which may then carry over into Word and InDesign for later styling).

- Small caps. Software that renders HTML (not just web browsers) has a hard time with small capitals. The CSS is easy enough to declare—font-variant: small-caps. But even if the software has access to a font with genuine designed small caps, it usually won’t use them. It will use fake small caps instead (regular capitals at a smaller point size). Fake small caps are usually too short, almost always too light, and often spaced too close together.

E-books must use CSS to specify small caps. But what you’ll end up seeing for now is fake small caps, not real ones.

- Columns. Despite what former Microsoft researcher Bill Hill may think, multicolumn continuous text makes no sense in a window that can resize and/or scroll. (Do you want your columns continuously redrawing themselves before your very eyes?) Columns may make sense in a screen that stays fixed and immobile. For that purpose, CSS3 columns module can be attempted, though real-world use may show its weaknesses, as with positioning illustrations, column-spanning headings, and callouts.

- Indents. One of the simplest (also least followed) conventions of book typography, indenting the first line of a paragraph that follows another paragraph but nothing else, has never been simpler to set up than in CSS: p+p { text-indent: number }.

Blank lines between paragraphs are a Microsoft Word artifact that are additionally widely used in onscreen text. In book typesetting, they’re a mistake (but don’t tell that to O’Reilly, the computer-book publisher that loves this “format”). If you really want a blank line between paragraphs, add a margin-bottom to P. Source copy should not be polluted with extraneous carriage-return characters, which are difficult to suppress.

Tasks the reader software must handle

- H&J. Everyone complains about full-justified text in E-readers (text with straight left and right margins). It’s harder to read because letterspacing and wordspacing are worse, causing rivers of whitespace. The reason? E-readers tend not to hyphenate words. Hyphenation is complex and still has not been perfected even for languages where there’s a strong market incentive to do so, like English.

To use the industry jargon, this issue is all about H&J (hyphenation and justification). Authors need to resist the temptation to add soft-hyphen characters to E-texts. Hyphenation is purely a display convention. Hyphenation changes when the layout changes (like switching from tall view to wide view).

E-book hyphenation should be carried out by computer algorithms and dictionaries. In print publishing, informed human proofreaders can override a system’s H&J decisions, but when you’re reading an E-book you don’t have one of those informed proofreaders seated alongside you. E-reader software has to implement hyphenation; nobody else should touch it.

- Ligatures. One of the very first things anyone with an interest in typography learns about is the use of ligatures—usually f followed by f, i, or l. Joining the letters together into ligatures avoids unpleasant collisions, like the top of an f hitting the dot of an i.

As with hyphenation, ligatures are purely a display artifact. Your rendering engine needs to put them in. Do not pollute your source text with ligature characters. (What if I want to capitalize large blocks of text? What if I want to search the text, or look up a word containing a ligature character in a dictionary? Of course you could program very intelligent software to overcome the problem. It’s easier to avoid the problem.) Rarer ligatures, like ct and st, are also an issue for display engines, not underlying text.

When you need to actively prevent ligature use, as in an URL that includes the letters fi or fl, there seems to be no way around adding a zero-width nonjoiner character between the letters. (There is no CSS declaration to turn ligatures on and off, though a CSS3 proposal would let you do that.)

- Hanging (or hung) punctuation. Typesetting some punctuation marks, like quotation marks and dashes, slightly outside the margin makes printed text look better and may also make onscreen text look better. This too is up to the display engine, not the text or its author.

Alterations to book text

Pure separation of structural markup and presentation will be impossible to achieve in books more often than on websites. Common book-typography features can be adequately expressed in E-books only by the sacrilege of altering the source manuscript.

- Dashes. As commonly used in print books, em dash (—) with no spaces on either side does not work in onscreen text. Rendering engines may be too dumb to break a line before or after the em dash. Of course that may be solved someday. But in any event the character fails at its intended function – to break up text, as for appositives and parenthetical statements. En dash (–) surrounded by spaces avoids linebreak problems and works better at the intended purpose. (Stated concisely: Nospace-emdash-nospace doesn’t work; space-endash-space does.)

- Space characters. You absolutely can use space characters wider and narrower than a standard word space. Em, en, and thin spaces are all defined in Unicode, along with many others, and display support is quite good and improving. A standard word space or a nonbreaking word space is the wrong character in many constructions, as between nested levels of quotation marks or apostrophe adjacent to quotation mark:

- “I’ve Got Chills. They’re Multiplyin’ “
(apostrophe; thin space; end double quote)

- “Technical is something techies do. ‘I’m a creative—I don’t touch that!’ ”
(end single quote; thin space; end double quote)

- It’s a nod to the “ ’80s New Wave” sound of the Cars and Blondie
(open double quote; thin space; apostrophe)

- Superiors, inferiors, fractions. In theory any character can be typeset as a superscript or subscript, usually changing the meaning (πr² and πr2 are two different things). Fonts often come equipped with pre-designed superior and inferior characters, typically digits (⁰¹²³⁴⁵⁶⁷⁸⁹) and letters used in ordinals (13th, 13e) and salutations (Mlle, Sra.). Fonts often have more superscripts and subscripts than are defined in Unicode, but where a Unicode superior or inferior exists, use it instead of SUB or SUP markup.

Math is a separate discussion. (It always is.) Nonetheless, don’t try to fake out fractions as though you were using a typewriter. The small number of Unicode characters for vulgar fractions should be used in all cases. There is no reliable method in HTML and CSS to construct fractions from superiors and inferiors and fraction slash, nor a method to create stacked fractions.

Sections. HTML’s single biggest deficiency for long documents is its lack of sections. They exist in HTML5, but ePub doesn’t use HTML5. Sections in nonfiction books may sometimes be differentiable through the use of headings, but the classic book-design paradigm of leaving extra space between sections (with different type on initial words of the new section) simply can’t be marked up in HTML. (In uncommon cases, section breaks like these occur right at the bottom of a printed page and have to be inferred.)

There is another tradition in book composition that can be adapted — typesetting a fleuron or dash between sections. It’s functionally equivalent to the use of HR, which can, with difficulty, be styled to be less intrusive. Nonetheless, you are still merely suggesting that sections have changed; what you are not doing is definitively encapsulating sections in their own markup.

Special note about tables

Over and over again, tables are held up as something E-books pretty much cannot do. I read this as an admission that people doing E-book “conversion” don’t understand table markup. Horrendously complex tables can be marked up in HTML. (What they might really be complaining about is how much width a table takes up—perhaps more than a certain E-reader display natively has.)

Conclusion

Experimenting with the form of the book is one thing, but E-book structure is not something we should make up as we go along. We shouldn’t pretend there aren’t any rules, nor should we import print-book concepts that do not work in onscreen books. The dominant E-book format of the future, ePub, can benefit from our nearly ten years’ experience building standards-compliant websites.

A List Apart
http://www.alistapart.com/articles/fluidgrids/

Early last year, I worked on the redesign of a rather content-heavy website . Design requirements were fairly light: the client asked us to keep the organization s existing logo and to improve the…

Early last year, I worked on the redesign of a rather content-heavy website. Design requirements were fairly light: the client asked us to keep the organization’s existing logo and to improve the dense typography and increase legibility. So, early on in the design process, we spent a sizable amount of time planning a well-defined grid for a library of content modules.

Over the past few years, this sort of thinking has become more common. Thanks to the advocacy of Mark Boulton, Khoi Vinh, and others, we’ve seen a resurgence of interest in the typographic grid, and how to use it on the web. And frankly, the idea’s been a smash hit: a million CSS frameworks have bloomed, with sundry tools to complement them, each built to make grid-based design even more accessible to the average designer. And why not? After a few minutes of griddy thinking, the benefits become clear: designers gain a rational, structured framework for organizing content and users gain well-organized, legible sites.

However, our client had one last, heart-stopping requirement: the design had to be fluid and resize with the browser window. Normally, this would cause me to rejoice both noisily and embarrassingly. Fluid layouts are an undervalued commodity in web design. They put control of our designs firmly in the hands of our users and their browsing habits. They’ve also utterly failed to seize the imagination of web designers.

Minimum screen resolution: a little white lie

Instead of exploring the benefits of flexible web design, we rely on a little white lie: “minimum screen resolution.” These three words contain a powerful magic, under the cover of which we churn out fixed-width layout after fixed-width layout, perhaps revisiting a design every few years to “bump up” the width once it’s judged safe enough to do so. “Minimum screen resolution” lets us design for a contrived subset of users who see our design as god and Photoshop intended. These users always browse with a maximized 1024×768 window, and are never running, say, an OLPC laptop, or looking at the web with a monitor that’s more than four years old. If a user doesn’t meet the requirements of “minimum screen resolution,” well, then, it’s the scrollbar for them, isn’t it?

Of course, when I was coding the site, I didn’t have the luxury of writing a diatribe on the evils of fixed-width design. Instead, I was left with a sobering fact: while we’d designed a rather complex grid to serve the client’s content needs, the client—and by extension, the client’s users—was asking for a fluid layout. As almost all of the grid-based designs I could list off at that time were rigidly fixed-width, I was left with a prickly question: how do you create a fluid grid?

As it turns out, it’s simply a matter of context.

Do I really have to thank IE for this?

Faced with an insurmountable problem, I did what I do best: avoid it altogether. Temporarily putting aside the question of how to get a grid to behave in a non-fixed layout, I coded the stuff I knew: styles first for color and backgrounds, and then for setting the type.

You may already know about Internet Explorer’s well-documented problem with resizing fonts set in pixels—or rather, its utter refusal to do so. Set a paragraph in 16px Georgia, and no matter how much the user tries to increase or decrease the size of the text, it remains at 16px in IE. IE7 and onward do allow the user to scale the entire page, but simple resizing of px-based fonts is still largely verboten in Internet Explorer. So to give our users the most flexibility, we standards-savvy designers have usually opted to sidestep the pixel entirely, and have taken to sizing type with relative units, be they keywords, percentages, or my personal favorite, ems.

If you’ve ever worked with relative units such as the em, you know that it’s all about context: in other words, the actual size of an element’s em is computed relative to the font-size of its parent element. For example, let’s say we’re working from the following design comp:

An example of some basic text sized using pixels.

Nothing fancy: some paragraphs set in 16px Helvetica, an unordered list that’s been slightly downsized to 14px, and an h1 at the top in 24px Georgia. Sexy, no?

What’s doubly sexy is that one simple rule allows us to get most of this in place:

body {
font: normal 100% Helvetica, Arial, sans-serif;
}

With a font-size of 100%, all the elements in our page are sized relative to the browser’s default type size, which in most cases is 16px. And thanks to the browser’s default stylesheet, the h1 is big, bold, and beautiful—but still in Helvetica, and much too large. So while it’d be easy enough to slap on a font-family to fix the header’s Helvetica problem, how do we size the text to 24 pixels? Or accurately reduce the size of that list?

With ems, it’s easily done. We take the target value for each element’s font-size in pixels and divide it by the font-size of its container (that is, its context). We’re left with the desired font-size, expressed in relative, em-friendly terms. Or to put it more succinctly:

target ÷ context = result

If we assume the body’s default type size to be 16px, we can plug each desired font-size value into this formula. So to properly match our header to the comp, we divide the target value (24px) by the font-size of its container (16px):

24 ÷ 16 = 1.5

So the header is 1.5 times the default body size, or 1.5em, which we can plug directly into our stylesheet.

h1 {
font-family: Georgia, serif;
font-size: 1.5em; /* 24px / 16px = 1.5em */
}

To size the list to the em-equivalent of 14px, we can use the same formula. Assuming again that the body’s font-size is roughly 16px, we simply divide that target by the context:

14 ÷ 16 = 0.875

And we’re left with a value of 0.875em, which we can again drop into our CSS.

ul {
font-size: 0.875em; /* 14px / 16px = 0.875em */
}

With those two rules, our sample page is looking a lot closer to the comp, and will be practically pixel-perfect after some slight cleanup. All with the help of our target ÷ context = result formula.

So after a few hours spent cleaning up relative type styling for our client, I realized I’d stumbled upon the answer. If we could treat font sizes not as pixels, but as proportions measured against their container, we could do the same with the different elements draped across our grid.

After all, it’s not “The Golden Pixel”

As before, let’s start with a fairly unsexy straightforward layout:

Sure, our “design” is pretty modest. But those simple styles are draped over a well-defined grid: namely, seven columns of 124px each, separated by 20px-wide gutters, all of which totals up to a width of 988px. But hey, let’s forget about those nasty pixels. Proportions are the new black, right? Let’s get fluid, baby.

To start, let’s treat our comp like any other, fixed or fluid: before we start coding, let’s look at the design, and assess the different content areas. Thankfully, it’s a pretty short inventory.

On the highest level, we’ve got a title at the top, a content area that spreads across six columns, and some contextual information in the leftmost column. From this diagram, we can flesh out some skeleton markup that keys into our content inventory, both structurally and semantically:

<div id="page">
<h1>The Ratio Revolution Will Not Be Televised</h1>

<div class="entry">
<h2>Anyone else tired of Helvetica?</h2>

<h3 class="info">A <a href="#">Blog</a> Entry:</h3>

<div class="content">
<div class="main">
<p>Main content goes here. Lorem ipsum etc., etc.</p>
</div><!-- /end .content -->

<div class="meta">
<p>Posted on etc., etc.</p>
</div><!-- /end .meta -->
</div><!-- /end .main -->
</div><!-- /end .entry -->
</div><!-- /end #page -->

And with some type rules applied, we’ve got a respectable-looking starting point. However, the #page container doesn’t have any constraints on it, so our content will simply reflow to match the width of the browser window. Let’s try to rein in those long line lengths a bit:

#page {
margin: 40px auto;
padding: 0 1em;
max-width: 61.75em; /* 988px / 16px = 61.75em */
}

We’ve used margins and padding to ventilate our design a bit, and establish a gutter between it and the window edges. But in the last line of our rule, we’re using a variant of our font-size formula to define the maximum width of our design. By dividing the comp’s width of 988px by our base font-size of 16px, we can set a max-width in ems to approximate the pixel-based width from our mockup, which will prevent the page from exceeding our ideal of 988px. But since we’ve used ems to set this upper limit, the max-width will scale up as the user increases her browser’s text size—a nifty little trick that even works in older versions of Internet Explorer, if a small CSS patch is applied.

So with our design properly cordoned off, let’s begin working on each element in our design inventory, beginning with the page’s title. In the comp, it spans five columns and their four gutters, with a total width of 700px. It’s also removed from the left-hand edge of the page by one column/gutter pair, making for a nice 144px offset. And if we were working in a fixed-width design, our job would be pretty straightforward:

h1 {
margin-left: 144px;
width: 700px;
}

Since we’re working in a fluid context, though, fixed measurements don’t quite cut it. And as I was working on relative font sizing, that’s when it hit me: every aspect of the grid—and the elements laid upon it—can be expressed as a proportion relative to its container. In other words, as in our type resizing exercise, we’re looking not just at the desired size of the element, but also at the relationship of that size to the element’s container. This will allow us to convert our design’s pixel-based widths into percentages, and keep the proportions of our grid intact as it resizes.

In short, we’ll have a fluid grid.

Everything old is new again

So, how do we begin?

target ÷ context = result

That’s right: it’s the return of our trusty type formula. We can use the same proportional analysis to transform pixel-based column widths into percentage-based, flexible measurements. So we’re working from a target value of 700px for the page’s title—but it’s contained within a designed width of 988px.

Converting our pixel-based title to percentages.

As a result, we simply divide 700px (the target) by 988px (the context) like so:

700 ÷ 988 = 0.7085

And there it is: 0.7085 translates into 70.85%, a width we can drop directly into our stylesheet:

h1 {
width: 70.85%; /* 700px / 988px = 0.7085 */
}

Can we do the same with our target margin of 144px? Oh, I do so love a leading question:

144 ÷ 988 = 0.14575

Once again, we can take that 0.14575, or 14.575%, and add that directly to our style rule as a value for the title’s margin-left:

h1 {
margin-left: 14.575%; /* 144px / 988px = 0.14575 */
width: 70.85%; /* 700px / 988px = 0.7085 */
}

And voilà. By measuring the title’s margin and width in relation to its container, we’ve successfully translated the ratios from our grid into CSS-friendly percentages. The title’s proportions will always remain intact, even as it reflows to fit the size of the browser window.

We can even perform the same simple division to wrap up the layout for the entry itself, sized at 844px in our comp, with some 124px-wide marginalia to the left of it. For the entry:

844 ÷ 988 = 0.85425

And for the informational column:

124 ÷ 988 = 0.12551

These two quick divisions net us some percentages that we can drop into our stylesheet, fleshing out our layout even more:

.entry h2,
.entry .content {
float: right;
width: 85.425%; /* 844px / 988px = 0.85425 */
}

.entry .info {
float: left;
width: 12.551%; /* 124px / 988px = 0.12551 */
}

And with that, our fluid grid shapes up a bit further.

Changing the context

So far we’ve got the big content areas sorted, but we’ve yet to touch the inner area. Currently, the blog entry’s main copy and its contextual info occupy the full width of the entry, and are stacked on top of each other. But in our initial comp, the main copy inside the blog entry only spanned five columns, with the ancillary info slotted neatly into the rightmost column.

Sharp readers will have noticed that, as it’s currently designed, the entry’s body is the same width as the page’s title (700px), and the marginalia is the same width as the leftmost column we styled earlier (124px). So while we’re working with some dimensions we’ve previously calculated, we can’t reuse the same formulas: the context has changed.

Since we’re working inside a new container, we need to use its width as our context.

Whereas before we were calculating percentages relative to the 988px-wide #page, we’re currently working within .entry .content, which is noticeably smaller. So as a result, we need to redefine our context, and work off the designed width of .entry .content as our reference point. So to define the percentage-based width of the main copy, we take its designed width of 700px, and divide it by 844px:

700 ÷ 844 = 0.82938

And for our 124px-wide column on the right, we can use the same reference point:

124 ÷ 844 = 0.14692

We can now take each of these measurements, and plug them into our CSS:

.entry .main {
float: left;
width: 82.938%; /* 700px / 844px = 0.82938 */
}

.entry .meta {
float: right;
width: 14.692%; /* 124px / 844px = 0.14692 */
}

And with that we’ve finished our work, our fluid grid complete.

A note on rounding

As you may guess from the lack of CSS patches above, I’ve had very few cross-browser issues with this technique. I would highly recommend John Resig’s excellent article on Sub-Pixel Problems in CSS. It explains how different browsers handle percentage-based widths, and the mechanics by which they reconcile sub-pixel measurements.

As John explains in his article, if modern browsers are presented with four 25%-wide elements within a 50px-wide container, they can’t actually render the elements at 12.5px; instead, most will round the columns down or up as best fits the layout. Internet Explorer, as it happens, will simply round all of those sub-pixel values up, which breaks layouts.

If you’re working with sufficiently generous margins in your grid, this shouldn’t be an issue. But if IE causes undue wrapping with your percentage-based columns, reducing the target value by one pixel can help. So if, for example, our left-hand marginalia was too wide for IE (Internet Explorer), you might change your calculation from:

124 ÷ 988 = 0.12551

to a lower target of 123px:

123 ÷ 988 = 0.12449

Plug that width of 12.449% into your IE-specific stylesheet, and your layout woes should clear right up.

A grid for all seasons

The above is, of course, a starting point: there are myriad other challenges that face the liquid web designer, most of which arise when you introduce fixed content (such as images, Flash, and so forth) into a fluid framework. I’ve been experimenting with a few possible solutions on my blog, but other, better workarounds are still out there.

And finally, I don’t pretend that design is easy, whether it’s fixed or fluid. But given all that we’ve achieved over the past few years—moving past tables, evangelizing standards in our companies and in our shared industry, demanding better standards of our browsers and our peers—I do wish we’d bend some of that ingenuity to break out of our reliance on “minimum screen resolution.” After all, our users’ browsing habits aren’t as fixed as our comps would suggest. I hope the promise of fluid grids has fired your imagination, and I’m excited to see how you improve on the technique. Our users will be, too.

Additional reading

As you may have gathered from my introductory crazed rant digression, two passions of mine are fluid web design and, more recently, the importance of a well-considered grid. Both of these have been fueled by the following, though this isn’t an exhaustive list:

And finally, at the end of a talk I gave last August on designing for fluid grids, someone pointed out the Fluid 960 Grid System. If you’re using a public CSS framework such as 960 Grid System already, the fluid “port” might be of interest to you.

Responsive Web Design
http://www.alistapart.com/articles/responsive-web-design/

The control which designers know in the print medium, and often desire in the web medium, is simply a function of the limitation of the printed page. We should embrace the fact that the web doesn’t have the same constraints, and design for this flexibility. But first, we must “accept the ebb and flow of things.”

John Allsopp, “A Dao of Web Design”

The English architect Christopher Wren once quipped that his chosen field “aims for Eternity,” and there’s something appealing about that formula: Unlike the web, which often feels like aiming for next week, architecture is a discipline very much defined by its permanence. A building’s foundation defines its footprint, which defines its frame, which shapes the facade. Each phase of the architectural process is more immutable, more unchanging than the last. Creative decisions quite literally shape a physical space, defining the way in which people move through its confines for decades or even centuries.

Working on the web, however, is a wholly different matter. Our work is defined by its transience, often refined or replaced within a year or two. Inconsistent window widths, screen resolutions, user preferences, and our users’ installed fonts are but a few of the intangibles we negotiate when we publish our work, and over the years, we’ve become incredibly adept at doing so.

But the landscape is shifting, perhaps more quickly than we might like. Mobile browsing is expected to outpace desktop-based access within three to five years. Two of the three dominant video game consoles have web browsers (and one of them is quite excellent). We’re designing for mice and keyboards, for T9 keypads, for handheld game controllers, for touch interfaces. In short, we’re faced with a greater number of devices, input modes, and browsers than ever before.

In recent years, I’ve been meeting with more companies that request “an iPhone website” as part of their project. It’s an interesting phrase: At face value, of course, it speaks to mobile WebKit’s quality as a browser, as well as a powerful business case for thinking beyond the desktop. But as designers, I think we often take comfort in such explicit requirements, as they allow us to compartmentalize the problems before us. We can quarantine the mobile experience on separate subdomains, spaces distinct and separate from “the non-iPhone website.” But what’s next? An iPad website? An N90 website? Can we really continue to commit to supporting each new user agent with its own bespoke experience? At some point, this starts to feel like a zero sum game. But how can we—and our designs—adapt?

A flexible foundation

Let’s consider an example design. I’ve built a simple page for a hypothetical magazine; it’s a straightforward two-column layout built on a fluid grid, with not a few flexible images peppered throughout. As a long-time proponent of non-fixed layouts, I’ve long felt they were more “future proof” simply because they were layout agnostic. And to a certain extent, that’s true: flexible designs make no assumptions about a browser window’s width, and adapt beautifully to devices that have portrait and landscape modes.

Huge images are huge. Our layout, flexible though it is, doesn’t respond well to changes in resolution or viewport size.

But no design, fixed or fluid, scales seamlessly beyond the context for which it was originally intended. The example design scales perfectly well as the browser window resizes, but stress points quickly appear at lower resolutions. When viewed at viewport smaller than 800×600, the illustration behind the logo quickly becomes cropped, navigation text can wrap in an unseemly manner, and the images along the bottom become too compact to appear legible. And it’s not just the lower end of the resolution spectrum that’s affected: when viewing the design on a widescreen display, the images quickly grow to unwieldy sizes, crowding out the surrounding context.

In short, our flexible design works well enough in the desktop-centric context for which it was designed, but isn’t optimized to extend far beyond that.

Becoming responsive

Recently, an emergent discipline called “responsive architecture” has begun asking how physical spaces can respond to the presence of people passing through them. Through a combination of embedded robotics and tensile materials, architects are experimenting with art installations and wall structures that bend, flex, and expand as crowds approach them. Motion sensors can be paired with climate control systems to adjust a room’s temperature and ambient lighting as it fills with people. Companies have already produced “smart glass technology” that can automatically become opaque when a room’s occupants reach a certain density threshold, giving them an additional layer of privacy.

In their book Interactive Architecture, Michael Fox and Miles Kemp described this more adaptive approach as “a multiple-loop system in which one enters into a conversation; a continual and constructive information exchange.” Emphasis mine, as I think that’s a subtle yet powerful distinction: rather than creating immutable, unchanging spaces that define a particular experience, they suggest inhabitant and structure can—and should—mutually influence each other.

This is our way forward. Rather than tailoring disconnected designs to each of an ever-increasing number of web devices, we can treat them as facets of the same experience. We can design for an optimal viewing experience, but embed standards-based technologies into our designs to make them not only more flexible, but more adaptive to the media that renders them. In short, we need to practice responsive web design. But how?

Meet the media query

Since the days of CSS 2.1, our style sheets have enjoyed some measure of device awareness through media types. If you’ve ever written a print style sheet, you’re already familiar with the concept:

<link rel="stylesheet" type="text/css" href="core.css"
media="screen" />
<link rel="stylesheet" type="text/css" href="print.css"
media="print" />

In the hopes that we’d be designing more than neatly formatted page printouts, the CSS specification supplied us with a bevy of acceptable media types, each designed to target a specific class of web-ready device. But most browsers and devices never really embraced the spirit of the specification, leaving many media types implemented imperfectly, or altogether ignored.

Thankfully, the W3C created media queries as part of the CSS3 specification, improving upon the promise of media types. A media query allows us to target not only certain device classes, but to actually inspect the physical characteristics of the device rendering our work. For example, following the recent rise of mobile WebKit, media queries became a popular client-side technique for delivering a tailored style sheet to the iPhone, Android phones, and their ilk. To do so, we could incorporate a query into a linked style sheet’s media attribute:

<link rel="stylesheet" type="text/css"
media="screen and (max-device-width: 480px)"
href="shetland.css" />

The query contains two components:

1. a media type (screen), and

2. the actual query enclosed within parentheses, containing a particular media feature (max-device-width) to inspect, followed by the target value (480px).

In plain English, we’re asking the device if its horizontal resolution (max-device-width) is equal to or less than 480px. If the test passes—in other words, if we’re viewing our work on a small-screen device like the iPhone—then the device will load shetland.css. Otherwise, the link is ignored altogether.

Designers have experimented with resolution-aware layouts in the past, mostly relying on JS-driven solutions like Cameron Adams’ excellent script. But the media query specification provides a host of media features that extends far beyond screen resolution, vastly widening the scope of what we can test for with our queries. What’s more, you can test multiple property values in a single query by chaining them together with the and keyword:

<link rel="stylesheet" type="text/css"
media="screen and (max-device-width: 480px) and (resolution: 163dpi)"
href="shetland.css" />

Furthermore, we’re not limited to incorporating media queries in our links. We can include them in our CSS either as part of a @media rule:

@media screen and (max-device-width: 480px) {
.column {
float: none;
}
}

Or as part of an @import directive:

@import url("shetland.css") screen and (max-device-width: 480px);

But in each case, the effect is the same: If the device passes the test put forth by our media query, the relevant CSS is applied to our markup. Media queries are, in short, conditional comments for the rest of us. Rather than targeting a specific version of a specific browser, we can surgically correct issues in our layout as it scales beyond its initial, ideal resolution.

Adapt, respond, and overcome

Let’s turn our attention to the images at the base of our page. In their default layout, the relevant CSS currently looks like this:

.figure {
float: left;
margin: 0 3.317535545023696682% 1.5em 0; /* 21px / 633px */
width: 31.121642969984202211%; /* 197px / 633px */
}

li#f-mycroft,
li#f-winter {
margin-right: 0;
}

I’ve omitted a number of typographic properties to focus on the layout: Each .figure element is sized at roughly one third of the containing column, with the right-hand margin zeroed out for the two pictures at the end of each row (li#f-mycroft, li#f-winter). And this works fairly well, until the viewport is either noticeably smaller or wider than our original design. With media queries, we can apply resolution-specific spotfixes, adapting our design to better respond to changes in the display.

First of all, let’s linearize our page once the viewport falls below a certain resolution threshold—say, 600px. So at the bottom of our style sheet, let’s create a new @media block, like so:

@media screen and (max-width: 600px) {
.mast,
.intro,
.main,
.footer {
float: none;
width: auto;
}
}

If you view our updated page in a modern desktop browser and reduce the size of your window below 600px, the media query will disable the floats on the design’s major elements, stacking each block atop each other in the document flow. So our miniaturized design is shaping up nicely, but the images still don’t scale down that intelligently. If we introduce another media query, we can alter their layout accordingly:

@media screen and (max-width: 400px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%; /* 21px / 633px */
width: 48.341232227488151658%; /* 306px / 633px */
}

li#f-watson,
li#f-moriarty {
margin-right: 0;
}
}

Our figures can responsively change their layout to better suit smaller displays.

Don’t mind the unsightly percentages; we’re simply recalculating the widths of the fluid grid to account for the newly linearized layout. In short, we’re moving from a three-column layout to a two-column layout when the viewport’s width falls below 400px, making the images more prominent.

We can actually take the same approach for widescreen displays, too. For larger resolutions, we could adopt a six-across treatment for our images, placing them all in the same row:

@media screen and (min-width: 1300px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%; /* 21px / 633px */
width: 13.902053712480252764%; /* 88px / 633px */
}
}

Now our images are working beautifully at both ends of the resolution spectrum, optimizing their layout to changes in window widths and device resolution alike.

By specifying a wider min-width in a new media query, we can shift our images into a single row layout.

But this is only the beginning. Working from the media queries we’ve embedded in our CSS, we can alter much more than the placement of a few images: we can introduce new, alternate layouts tuned to each resolution range, perhaps making the navigation more prominent in a widescreen view, or repositioning it above the logo on smaller displays.

By designing responsively, we can not only linearize our content on smaller devices, but also optimize its presentation across a range of displays.

But a responsive design isn’t limited to layout changes. Media queries allow us to practice some incredibly precise fine-tuning as our pages reshape themselves: we can increase the target area on links for smaller screens, better complying with Fitts’ Law on touch devices; selectively show or hide elements that might enhance a page’s navigation; we can even practice responsive typesetting to gradually alter the size and leading of our text, optimizing the reading experience for the display providing it.

A few technical notes

It should be noted that media queries enjoy incredibly robust support among modern browsers. Desktop browsers such as Safari 3+, Chrome, Firefox 3.5+, and Opera 7+ all natively parse media queries, as do more recent mobile browsers such as Opera Mobile and mobile WebKit. Of course, older versions of those desktop browsers don’t support media queries. And while Microsoft has committed to media query support in IE9, Internet Explorer currently doesn’t offer a native implementation.

However, if you’re interested in implementing legacy browser support for media queries, there’s a JavaScript-tinted silver lining:

- A jQuery plugin from 2007 offers somewhat limited media query support, implementing only the min-width and max-width media properties when attached to separate link elements.

- More recently, css3-mediaqueries.js was released, a library that promises “to make IE 5+, Firefox 1+ and Safari 2 transparently parse, test, and apply CSS3 Media Queries” when included via @media blocks. While very much a 1.0 release, I’ve personally found it to be quite robust, and I plan to watch its development.

But if using JavaScript doesn’t appeal, that’s perfectly understandable. However, that strengthens the case for building your layout atop a flexible grid, ensuring your design enjoys some measure of flexibility in media query-blind browsers and devices.

The way forward

Fluid grids, flexible images, and media queries are the three technical ingredients for responsive web design, but it also requires a different way of thinking. Rather than quarantining our content into disparate, device-specific experiences, we can use media queries to progressively enhance our work within different viewing contexts. That’s not to say there isn’t a business case for separate sites geared toward specific devices; for example, if the user goals for your mobile site are more limited in scope than its desktop equivalent, then serving different content to each might be the best approach.

But that kind of design thinking doesn’t need to be our default. Now more than ever, we’re designing work meant to be viewed along a gradient of different experiences. Responsive web design offers us a way forward, finally allowing us to “design for the ebb and flow of things.”

Translations

French
Italian
Portugese
Romanian

Put Your Content in My Pocket
http://www.alistapart.com/articles/putyourcontentinmypocket/

Unless you’ve been hiding in a cave with Osama bin Laden, you know that Apple is selling an iPhone and that it’s a hit. Apple is well on its way to selling ten million mobile Internet devices by the end of 2008. Besides being a great phone, the iPhone also includes a sophisticated new Safari browser. This version is touted as “the most advanced web browser on a portable device” and from what I’ve seen, it deserves this accolade.

So what does this mean for you? Millions of visitors accessing your content on a small display with very high resolution. At some point in the near future, you’re going to want to take a look at your current site design to make sure that it looks good and works well on this new device and its Mobile Safari browser.

(Note: For the remainder of this article, I’ll refer to this new browser as Mobile Safari to avoid confusion with its desktop sibling.)

In this first of two articles on bringing your content to the iPhone, I’ll explain what your options are and give you some guidance for tuning your site and making changes that enhance your users’ experience. In the second part of this series, I’ll examine some of the pitfalls and problems with this new web development environment.

While these articles are specifically targeted at the iPhone, many of the ideas and concepts I’m presenting can be useful and effective with other mobile devices. The processing power of these devices will continue to increase, bringing an end to the “dumbed down” mobile web, and it’s likely that the iPhone is just the beginning of an exciting new chapter in the storied life of HTML.

Time to clean up

The iPhone developers did a really smart thing—they designed the iPhone so that you really don’t need to do anything with your site for it to display correctly. So why am I writing this article? Well, you don’t really need to bathe periodically, either. But dealing with a clean person is much more palatable than one who hasn’t touched a bar of soap for several months. So it is with the iPhone: clean up a few things and your visitors will love you for it.

The first thing you’ll want to do is check your site for compatibility. After that, you can begin to make some simple changes that adapt your content to the iPhone. Finally, you may wish to make a version of your site that is targeted directly at the iPhone: a site fully optimized for the device.

Keep in mind that, like most things on the web, adding support for the iPhone is an evolutionary endeavor: you don’t need to completely change your site overnight. Many of these changes can be done incrementally without adversely affecting the other parts of your site.

Compatibility

First, you’ll want to make sure that your site is accessible by the iPhone. As I said earlier, it’s likely that you won’t need to do much—for the most part, compatibility just happens.

If you’ve been using web standards to develop your site, you’ll find that Mobile Safari works just as you’d expect. Because it uses the same Web Kit rendering engine as Safari on the desktop, it supports—with a few exceptions—the latest versions of HTML/XHTML, CSS, JavaScript, and the W3C DOM. (While Part I of this series will provide an overview of iPhone-friendly development, Part II will detail the iPhone’s deficiencies and limitations, including those exceptions.) Many of the AJAX technologies, including getElementById and XMLHttpRequest, work just like their counterparts on the desktop.

Still, there are some areas in which Mobile Safari will work differently or not at all.

Trouble with the plug-in

The omission causing the most grief for developers is that the Flash plug-in is not supported. If your site relies on Flash, all iPhone visitors will see is a blue Lego-style brick with question marks.

If you rely on Flash for navigation or multimedia, you have a few options, only one of which is truly compelling:

- Wait, possibly in vain, for Apple to add Flash support. It is likely that Flash is not being included due to performance and battery life problems.

- Use browser detection. Those of us who remember the halcyon days of the late 90s, and a web before standards, will know that maintaining different site versions based on browser type is more trouble than it’s worth.

- Rely on web standards. If actions speak louder than words, note that Apple has replaced Flash with web standards on its own corporate website.

Safari for everyone

Developers on both Mac and Windows can use the Safari browser as a proxy for web development on the iPhone. For the most part, the way Safari renders content is identical to the way it’s rendered on the phone. There are some differences and caveats, which I’ll cover in the second article of this series.

Apple also has a website dedicated to web development on the iPhone. The Apple site is a great place to look for the latest news and information: if I’m having a problem with some aspect of iPhone web development, their “Web Development Guidelines” are the first place I look.

The iPhone works well with non-Flash multimedia content—a special version of the QuickTime plug-in is available using normal <object> and <embed> tags. Mobile Safari, however, behaves differently than Safari on the desktop. Embedded movies or audio only display a “play” button which opens the media in a separate window that overlays your content (referred to as “playback mode”). Additionally, you don’t have any control over this playback mode with JavaScript.

Because of these differences, Apple recommends that you add a poster image when you embed multimedia content (Line wraps marked » —Ed.):

<embed src="poster.jpg" href="movie.mov" »
width="456" height="123" ...>

The poster image is displayed until the user clicks on it to play the multimedia content. This gives a consistent user experience for both mobile and desktop visitors.

Adapting

After you’ve verified that your site is compatible with the iPhone, you’ll want to focus on some simple changes that give your visitors the best possible experience.

In my opinion, you’ll need to have an iPhone for this type of development. As noted above, you can use the desktop version of Safari to preview content, but the types of changes I’m going to talk about now consist of fine-tuning that content. Unless you are holding a phone in your hand, you can’t tell whether or not your changes are effective. Remind yourself (or your boss) that the IRS would consider the iPhone a valid business expense and pick one up.

The iPhone makes prominent a little-discussed web development concept: the viewport. To deal with the problem of fitting a relatively large web page onto a small phone display, the iPhone’s developers use a viewport to select the part of the page you are viewing.

Conceptually, the viewport is like a loupe whose magnification is adjustable. When you open a page in Mobile Safari, it will render a 980-pixel-wide section of your website (Apple chose this size to accommodate the largest number of websites). The magnification of the loupe, or scaling factor, is set to shrink these 980 pixels to the iPhone’s 320-pixel-wide screen.

As you pinch or spread your fingers, you are effectively changing the magnification of the loupe (and adjusting the scaling factor). Likewise, double-tapping on a page element, such as a <div>, will adjust the scaling factor so that the viewport is optimized for viewing the element.

Thanks to a new <meta> tag recognized by the iPhone, you can control the behavior of the viewport. Imagine a site whose <body> content is exactly 808 pixels wide. By specifying the following <meta> tag, we can tell Mobile Safari how big to make the initial viewport:

<meta name="viewport" content="width=808" />

This cuts the number of pixels the iPhone has to squeeze onto its screen from 980 to 808. It may not seem like much, but when you consider that the phone’s display width is just 320 pixels, it makes a big difference. In the case of my personal site, it makes the title of each posting readable on the first view—a huge usability improvement.

You also need to be aware that the iPhone adjusts text sizes as the viewport changes. The font size increases automatically to make text as readable as possible. Sometimes this negatively affects elements that use absolute positioning or fixed sizes (especially when using pixels to specify page coordinates). If you find that this causes overflow or other unsightly results, you can easily turn it off using the following CSS rule:

-webkit-text-size-adjust: none;

Alternatively, you can use ems to specify coordinates. Sizes specified this way will increase along with the text size.

In some cases, you may want to use this feature to increase font size for important information on your page. As an example, you could increase type size in a header tag used for a weblog title with a rule like this:

h1 {
-webkit-text-size-adjust: 200%;
}

Styling for the iPhone

Before pursuing further adaptions, consider the hardware we’re dealing with—that of both the phone and our bodies. The screen on the iPhone squeezes 160 pixels into every inch of display space—and you’re using your finger to access that display. If you press your finger against the edge of a ruler, you’ll see it uses somewhere between 1/4” and 1/2” at the point of contact. That corresponds to anywhere between 40 and 80 pixels of display space.

Now, look at your web page. How many pixels are between the items on your navbar? If you answer less than 40, then you’re effectively asking your visitor to play Russian roulette: their 40-80 pixel finger isn’t going to hit your 20 pixel link effectively.

When you use iPhone specific styles, it improves accessibility for someone working on a high-density mobile device. My rule of thumb is to double important elements: bumping a font-size from 18px to 36px, for example. You’ll want to focus both on interactive elements (such as <a> and <input>) and navigational indicators (such as section titles and bread crumb trails).

So how do you use styling rules that apply only to the iPhone? The answer is to use a media query on a <link> tag. The following rule is recommended by Apple:

<link media="only screen and (max-device-width: 480px)"
href="iPhone.css" type="text/css" rel="stylesheet" />

Other browsers will ignore iPhone.css since they have a maximum device width greater than 480px.

Integrating your site with the rest of the iWorld

As you continue to adapt your site to the iPhone, you’ll want to think about how Mobile Safari integrates with other services on the phone. It’s easy to have your page pass information to the Mail, Maps, and Phone applications—all you need to do is craft special hrefs for your links.

A link with a mailto: in the href works as expected—it opens the iPhone Mail application using the specified parameters. You can specify some HTML markup in the body, but I’d advise against it since not all mail clients will handle it correctly. For example, the following will work fine on the iPhone (Line wraps marked » —Ed.):

<a href="mailto:zippy@example.com?subject=Sarcasm&body=I »
<b>love</b> %26lt;html%26gt; mail!">Hi!</a>

And create a message that looks like this:

To: zippy@example.com
Subject: Sarcasm

I love <html> mail!

However, most other mail clients will create a message with a body that looks like this:

I <b>love</b> &lt;html&gt; mail!

Mobile Safari handles links to Google Maps differently than other browsers, too. It checks to see if a link href begins with “http://maps.google.com/maps” and will automatically load the remaining part of the URL into the Maps application instead of a new web page. The normal ?q=location and ?saddr=start&daddr=destination map queries will be handed by Maps from that point on. Note that since you’re switching applications, the user will have to click the Home button, then the Safari icon to return to your web page from the Maps application. Be judicious when using map links as this can be a disruptive context switch for the user—in most cases it would be wise to provide a map preview on the link so the user can get basic directions without loading the interactive Maps.

The sexiest links ever

Now to the newest and most interesting linking feature on the iPhone: clicking on a link to make a call.

Say you have the following hCard microformat on your contact page:

<div id="hcard-Ernestine" class="vcard">
<span class="fn">Ernestine</span>
<div class="tel">555-1212</div>
</div>

By default, the iPhone will turn the 555-1212 into a clickable link. It will take whatever styling has been specified for the parent (i.e. there isn’t any way to specify an id or class for the automatically generated link).

If you’d like more control over the link that is generated, you can use markup like this:

<a class="call" href="tel:555-1212">Call Me</a>

When the user clicks on the link, it will initiate a call to the number specified. You need to be careful with these links. Many browsers will display an error message because they don’t recognize the tel: protocol. You’ll probably want to hide these links in your site-wide CSS.

a.call {
display: none;
}

And then use your iPhone-specific CSS, to show them with the following:

a.call {
display: inline;
}

Going deeper: designing for the iPhone

After taking care of the structural and presentational aspects of your page, you may want to examine some of your design decisions.

One thing that’s important to remember when working with Mobile Safari web pages is that they will often be served over the EDGE network. This network, based on cell phone technology, is much slower than broadband networks. It also has higher latency—it takes longer for your HTTP requests to reach a server and for the responses for the request to arrive back at the phone.

The feeling is very similar to the days when the 56K modem reigned supreme. And like those days, it’s important to keep an eye on the size of what’s on your server:

- HTML—Leverage web standards to keep markup and page size to a minimum.

- CSS—Use media queries to ensure that a minimum number of rules are loaded and parsed.

- Multimedia—Use QuickTime H.264 encoding and pay attention to bit rates. Reference movies allow you to serve up different sized content using the same HTML.

- Images—Use iPhone-specific CSS to load lower resolution images.

- JavaScript—Be careful about including large JavaScript frameworks—loading hundreds of KB of scripts to show and hide a <div> doesn’t make sense.

Finally, remember the width of the iPhone screen: 320 pixels (for portrait) and 480 pixels (for landscape). Content that fits naturally within these sizes works best and will require less scrolling by the user. Likewise, content that does not span across multiple columns will be easier for the iPhone user to access.

Targeting

Now let’s talk about taking the big plunge: creating a separate part of your website that is dedicated to iPhone users.

Why would you want to do this?

Again, before we can answer this question, we need to take a high-level look at the surroundings for our web designs. We’re all familiar with the current desktop and the browsers that run in this environment—so much so that we take its high density for granted.

The desktop allows us to do many things at once: browsing, e-mail, multimedia, chat, etc. There’s enough space for us to move our attention between many disparate tasks.

Now look at your iPhone. Typically, you’re only doing one thing at a time—making a call, finding a restaurant, or checking your appointments. The interfaces for these tasks are much simpler, making it much easier for you to focus on the work at hand.

Your website probably has functionality for many different use cases. Some of that functionality may be inappropriate for someone who’s on the go, and this is a great reason to make a site targeted towards the iPhone. If you have e-commerce or other transactional functionality, you may find that your current interface makes transactions cumbersome on the iPhone—and making it easy for people to give you money can be a direct benefit, even if that means streamlining your existing site or creating an iPhone-specific site. Other types of sites, like blogs, with their low information density, don’t need this kind of special treatment.

Once you’ve decided that you want to customize your site for the iPhone, there are things you need to keep in mind:

- Simplify—On the iPhone, less is more. Let the user focus on your content. Use one column layouts instead of two or three columns.

- Size—Bigger is better. Make it easy for the user to manipulate your content. Element sizes should start at 40 pixels and go up from there.

- Emulate—Designs that mimic the iPhone user interface will be more successful. The user doesn’t have to learn new conventions when dealing with your content.

Emulation and frameworks

Let’s take a quick look at some of the tools you can use to help emulate the iPhone UI. Since you’re only worried about this working in Mobile Safari, you can utilize features that aren’t available in other browsers. You don’t have to worry about how a design looks in Internet Explorer—dreams do come true!

- Use the <canvas> tag for drawing dynamic images and graphics.

There are also JavaScript-based frameworks being developed to ease the development of iPhone-specific interfaces. One of the more advanced and popular ones is Joe Hewitt’s iUI. If you’ve used the iPhone, you already know how to use his examples.

One final thing to keep in mind when you start this kind of development: make it an addition to your existing site. Don’t force an iPhone to use this special section of your site—it’s an enhancement, not a jail. Likewise, if a user without an iPhone wants to look at this part of your site, don’t block them with some “for iPhone only” nonsense. Remember that the web always works best when it’s open and developers don’t try to outsmart their visitors.

Summary

I realize that a lot of information has been presented in this article—there’s a lot to learn about this new device. But don’t be overwhelmed: much of what I’ve presented can be done incrementally. Start by setting up the <meta> tag with the viewport information and then experiment and test your ideas and changes. In the end you’ll end up with a site whose content is much more accessible from the iPhone. I, and millions of other visitors, will thank you.

Apps vs. the Web
http://www.alistapart.com/articles/apps-vs-the-web/

Pull the iPhone out of your pocket and look at the home screen. Likely, you’re seeing some well known brands on the web: Facebook, Flickr, and Google to name just a few. You’ll also see companies like Amazon, Target, and Walmart which sell a lot of products via the web.

Like you, these sites and companies know how to build an effective website using the latest and greatest web technologies. The iPhone’s Safari browser also supports HTML5 markup with CSS3 styling and is powered by a fast JavaScript engine. So why is there a proliferation of apps instead of web pages that can do the same thing?

Longtime A List Apart readers may remember the Put Your Content in My Pocket articles I wrote soon after the iPhone launched. Recently, I published a book that explains how to create products for the iPhone App Store. With this article, I’d like to share my experiences with both mobile web and software development to guide your future developments on the iPhone platform.

Apple

From Apple’s point of view, iPhone OS and web technologies share equal footing. When you visit their developer site, the Safari Dev Center is prominently displayed. The iPhone gets all the press, but when you click on Safari Dev Center, there’s a ton of great information that explains how to use HTML, CSS, and JavaScript on an iPhone.

When you look back on your first experiences with the iPhone, one app stands above the others: The Safari web browser. Suddenly you were free from a mobile internet full of crappy CSS support or dumbed down presentation-like WAP. The iPhone’s real browser and the fact that it was in your pocket changed how you used the web.

Apple continues to invest heavily in the development of the WebKit browser engine used in Safari on the iPhone, Mac, and Windows. The result is a browser that excels in HTML5 and CSS3 support.

Apple also views HTML5 support as an important part of its marketing message for both consumers and developers.

Because it’s open source, the WebKit rendering engine also powers browsers for many other mobile platforms. If you’re surfing the web with a Blackberry, Android, or Symbian phone, you’ll find that your content looks just as good as it does on the iPhone. The only holdout is Microsoft’s Windows mobile platform which uses a browser based on the IE rendering engine.

With great HTML, CSS, and JavaScript support, developers are doing amazing things with the iPhone. Here are a few notable examples:

Pie Guy by Neven Mrgan

Pie Guy uses HTML5’s offline application cache so that it works correctly when you’re not connected to the internet, as well as CSS animations and transforms for the game’s effects. Neven also keeps track of developments in this area via the HTML5 Watch website.

Showtime by Nial Giacomelli and Benjamin Gordon

Showtime is a simple app that allows you to keep track of when your favorite TV shows are on. It uses a jQuery plugin by David Kaneda that provides many of the controls and effects that you see in standard iPhone applications.

Every Time Zone by Amy Hoy and Thomas Fuchs

Every Time Zone is a very simple, but effective, view of times throughout the world. The slider that lets you pick the time works very well on a touch screen. This web application looks particularly good on an iPad display.

With such great tools available and talented developers that know how to exploit them, the iPhone should be overflowing with web applications, right? Actually, the opposite is true: there are over 100,000 titles on iTunes and only a handful of popular applications have been created with web standards.

Apple has promoted both the App Store and web browser as ways for developers to get their creations into the hands of customers. They even gave the web a year-long head start before beginning to sell apps in the store. Clearly there’s more at play here: what attracts developers to iTunes instead of the web?

Going native

Before looking at the motivations of the move toward iTunes, we need some definitions. Developers have come to categorize the two iPhone development technologies as “native” and “web.” Web apps use HTML, CSS, and JavaScript that loads in Safari. All the examples above are “web apps.”

“Native apps” are created using the Xcode development environment in a language called Objective-C. These are the same tools used to create Apple’s own built-in apps like Mail, iPod, and even Safari itself.

Creating native apps is much different than the process you use to build web apps. Luckily, many of the underlying concepts are the same. Many web developers find that making the switch isn’t that hard:

- Like JavaScript, the Objective-C language is a descendent of C. In addition to sharing similar syntax, both languages are object oriented. If you’re comfortable with JavaScript, you’ll feel equally at ease with Objective-C.

- Native and web apps share some familiar design elements. On the web, you’re used to breaking an application’s functionality into pages, creating a series of <div> elements to organize the content on that page, and using XMLHttpRequest to update that content. With Cocoa Touch, “view controllers” are used like pages, “views” provide the building blocks for your content, and NSURLConnection objects act as your link to the internet.

- Frameworks handle much of the hard work. Just as you rely on jQuery or Prototype when working in JavaScript, you’ll find yourself doing the same thing with Cocoa Touch when you work in Objective-C. Both languages also benefit from a vibrant developer community that is happy to share development tricks and source code.

- If you’re a Flash developer who’s frustrated because there’s no way to play your creations on the iPhone, you’ll be happy to learn that ActionScript, like its predecessor JavaScript, shares the same lineage with C. The mechanisms for creating animation and other visual effects are different on the iPhone, but the concepts are the same. The recently announced Sparrow framework can help ease this transition, especially if you’re using Flash to develop games. It’s also a great example of the kinds of contributions made by your fellow iPhone developers.

To give you an idea of how similar things are, take a look at this snippet of Javascript code:

var beAwesome = true;
var myString = "chocklock";
if (beAwesome) {
myString = myString.toUpperCase();
}

Now, compare it to the same thing in Objective-C:

BOOL beAwesome = YES;
NSString *myString = @"chocklock";
if (beAwesome) {
myString = [myString uppercaseString];
}

In Objective-C, the variable definitions are different and function calls are replaced with stuff in square brackets. In a larger context, these are minor details. You can still see the logic that to be awesome, you just convert your string to uppercase letters.

One of the goals for my book about iPhone app development was to make this new environment accessible to people coming from other backgrounds. I dedicated an entire chapter of the book to explaining those square brackets in familiar terms.

The motivation

Learning how to use new development tools will take some effort. So why should developers go through this hassle when they could just bank on the web skills they already have?

Some of the motivation is purely selfish: Native applications give the developer more control over the mobile environment. The other incentive is altruistic: a native app is generally easier for the rest of us to use.

- Speed: JavaScript performance has increased dramatically in the past few years, but as an interpreted language, it will never be as fast as compiled code that runs directly on the processor. In a mobile environment where processors run slower to conserve power, every clock cycle counts.

- Data Management: Cocoa Touch has several mechanisms that make it easy to store your application’s data. This is important because caching information retrieved from a network can greatly improve a mobile application’s ease of use. The persistent data storage in HTML5 provides simple key/value access or raw database access using SQL. Core Data on the iPhone provides a much more sophisticated system where relationships between your data objects are managed automatically.

- Animation: One of the hallmarks of both web and native iPhone applications is animation that reinforces a user’s actions. CSS3 provides ways to animate page elements, but much more sophisticated effects are possible when you access the underlying Core Animation framework with native code.

- Resources: Mobile developers never have enough memory, network speed, or CPU power. These limited resources are much harder to control when they’re being managed by JavaScript or the browser. It’s easier for native applications to detect these situations and adapt the user experience accordingly.

- Usability: iPhone users feel most comfortable when they’re using the standard controls they’ve become accustomed to in Apple’s built-in apps. HTML abstracts controls like <input> and <textarea> so they can work in many different environments. JavaScript frameworks, like jQTouch mentioned above, do a fantastic job extending these basic control mechanisms, but an iPhone user will still notice that they feel a bit different than platform-native controls.

- Productivity: From the developer’s point of view, it’s typically easier to build complex user interfaces using Cocoa Touch: The frameworks do much of the heavy lifting and allow you to focus on the problem rather than its implementation. With the limited amount of screen real estate on a mobile device, a simple form on the desktop often turns into multiple views whose state needs to be managed by your application. Apple developed Cocoa Touch specifically to deal with this situation.

- Integration: An iPhone has many capabilities that are beyond the reach of the web browser. Some simple examples are the user’s contacts, the photo library, voice recording, and device movement. Cocoa Touch frameworks are the only way to access this information.

As the web has matured, its applications have naturally split into two parts: The front end and the back end. Back end services manage the user’s data and are typically powered by racks of powerful servers. The front end of a web app takes this information and presents it in the browser: HTML, CSS, and JavaScript are all about user experience. In most cases, this front end is a fairly thin layer on top of the much larger back end.

With iPhone apps, this thin presentation layer is replaced. The access to REST-based APIs implemented by the back end is exactly the same. Yes, you’re duplicating the efforts of any front end development you’ve already done for the browser, but this extra effort comes with the benefits mentioned above.

In practice

There are as many approaches to development as there are apps in iTunes. Every product and the people who created it are different. That being said, the evolution of a product from the web to the iPhone typically goes something like this:

1. Design the product. No matter what platform you’re targeting: Be it the web or a smartphone, your first step is always to think about the problem you’re trying to solve. Figure out what your users want before you get anywhere near implementation specifics.

2. Implement the product using web standards. Use the tools that you’re most familiar with. This way, you also end up with a solution that has the widest reach and can be viewed on any platform with a standards-compliant browser. Think about using CSS and Javascript that optimizes the experience for users on mobile devices (including the iPhone, Android, and BlackBerry).

As a starting point, check out Put Your Content in my Pocket and Put Your Content in my Pocket, Part II.

As you implement this product, pay close attention to how the front end user interface communicates with the back end services. Try to use a REST API that third parties and eventually your own more platform-specific solutions can use.

3. Launch the product. Get your work into the hands of users as soon as possible. As people begin to use your creation, they’ll start giving you feedback. This starts the virtuous cycle of iteration and refinement.

4. Run into problems. Eventually, you’ll encounter situations that can’t be solved with web standards. Maybe it’s something like feature requests from users who want to upload photos or access their list of contacts. Some users will explicitly ask for an iPhone app because so many of their other favorite sites have customized solutions.

There can also be internal pressures from your own designers and developers. They’ll find that navigation and data management are more difficult as the scope of the application increases. When you start to feel like you’re reinventing the wheel, sometimes it’s best just to use the wheel that Apple’s already built.

5. Translate product design into an iPhone app. You’ll find that many of the decisions you made while implementing web pages were done in the name of platform neutrality. As you enter the iPhone’s platform-specific world, you’ll want to re-evaluate some decisions. Layouts and user interaction should be tailored to make them feel at home in a native app.

6. Launch product on iTunes. After developing the app for the iPhone, you’ll now have an important new way for users to find your content or service. Which leads to the next section…

Takin’ care of business

The other attraction for developers looking at native apps is simple: There are over 100 million customers in iTunes who can buy your app with a single button tap. They can also pay for your content with the same ease. If you’re running a business, there are some distinct advantages to building apps in addition to your website.

Brand marketing

For brand marketers, the App Store is another important channel to get a product or service in front of millions of eyeballs. The big brands mentioned at the beginning of this article continue to have a strong web presence: their iPhone app supplements their position.

Many of these companies look at a native iPhone app as a cheap form of advertising: 30 seconds during primetime can cost upwards of half a million dollars. An iPhone app will cost much less and when a marketer sees their icon appear in iTunes, it’s better than Christmas morning.

Smaller developers can also use the App Store to find new audiences and fine tune the experience for current users. You’ve already done the hard work with your back end, so the effort and expenses to build a new front end are usually minimal.

Media matters

Many websites have found it difficult to charge for access to content. The root of this problem is a lack of a convenient payment mechanism for the end user. There’s also a history of free access to information on the web. As a result, many sites rely on advertising to pay the bills.

iTunes offers you a simple way to charge users for content. It can be a one-time payment via app purchase, or a recurring payment (such as a subscription) with in-app purchases. In either case, a customer only has to tap on a buy button and enter their password. Apple handles all the payment processing and accounting. You just wait for bank deposits from around the world at the end of each month.

With the recent release and popularity of the iPad, publishers both large and small are finding it profitable to repurpose content for the iPhone OS. Wired magazine’s recent debut on the App Store generated 24,000 sales in the first 24 hours. At five dollars a copy, it doesn’t take a financial genius to realize that there is some serious consumer demand for innovative content delivered via iTunes.

If you think about it a little further, it makes complete sense from a customer’s point of view. You’re used to buying music and video from iTunes. Now with iBookstore, you can get mainstream titles delivered electronically. Adding your own content to this mix makes sense for you and your customers.

Proceed with caution

Getting your content into the App Store also includes a step that you’re probably not used to in the wilds of the web: Third-party review. Anything you submit to iTunes will be checked and can be rejected at Apple’s discretion. Every app you see in iTunes has gone through this process.

The iTunes review tends to err on the side of caution: At one point political cartoons were not allowed because they ridiculed a public figure. Apple has since eased that restriction, but there are still limits that you need to be aware of. These conditions, and other nuances of iTunes, are explored further in my book.

If your content contains nudity or any of the other areas that are disallowed, you’ve just wasted your time reading this article. Things aren’t all bad though, because you can still use Safari to circumvent the entire curatorial process.

Wrap up

So there you have it: A quick summary of what iPhone apps mean to today’s web content producers. Hopefully the information in this article is enough to determine if a dedicated mobile application is right for your site. If you decide to head down this development path, I hope you’ll find that my book is a helpful guide that explains the process from start
to finish.

Translations:
Italian (italianalistapart.com)
Arabic (arabicalistapart.com)

CSS Sprites: Image Slicing’s Kiss of Death
http://www.alistapart.com/articles/sprites/

Back when video games were still fun (we’re talking about the 8-bit glory days here), graphics were a much simpler matter by necessity. Bitmapped 2-dimensional character data and background scenery was individually drawn, much like today’s resurgent pixel art. Hundreds and later thousands of small graphics called sprites were the building blocks for all things visual in a game.

As game complexity increased, techniques developed to manage the multitude of sprites while keeping game play flowing. One variation saw sprites being plugged into a master grid, then later pulled out as needed by code that mapped positions of each individual graphic, and selectively painted them on the screen.

And what does this have to do with the web?

Everything old is new again, and though the rise of 3D games has made sprite maps obsolete, the concurrent rise of mobile devices with 2D gaming capabilities have brought them back into vogue. And now, with a bit of math and a lot of CSS, we’re going to take the basic concept and apply it to the world of web design.

Specifically, we’re going to replace old-school image slicing and dicing (and the necessary JavaScript) with a CSS solution. And because of the way CSS works, we’re going to take it further: by building a grid of images and devising a way to get each individual cell out of the grid, we can store all buttons/navigation items/whatever we wish in a single master image file, along with the associated “before” and “after” link states.

How do CSS Sprites work?

As it turns out, the basic tools to do this are built into CSS, given a bit of creative thinking.

Let’s start with the master image itself. Dividing a rectangle into four items, you’ll observe in this master image that our intended “before” link images are on the top row, with “after” :hover states immediately below. There’s no clear division between the four links at the moment, so imagine that each piece of text is a link for now. (For the sake of simplicity, we’ll continue to refer to link images as “before” images and the :hover state as “after” for the rest of this article. It’s possible to extend this method to :active, :focus, and :visited links states as well, but we won’t go into that here.)

Those familiar with Petr Stanicek’s (Pixy) Fast Rollovers may already see where we’re going with this. This article owes a debt of gratitude to Pixy’s example for the basic function we’ll be relying on. But let’s not get ahead of ourselves.

On to the HTML. Every good CSS trick strives to add a layer of visuals on top of a clean block of code, and this technique is no exception:

<ul id="skyline">
<li id="panel1b"><a href="#1"></a></li>
<li id="panel2b"><a href="#2"></a></li>
<li id="panel3b"><a href="#3"></a></li>
<li id="panel4b"><a href="#4"></a></li>
</ul>

This code will serve as a base for our example. Light-weight, simple markup that degrades well in older and CSS-disabled browsers is all the rage, and it’s a trend that’s good for the industry. It’s a great ideal to shoot for. (We’ll ignore any text inside the links for the time being. Apply your favorite image replacement technique later to hide the text you’ll end up adding.)

Applying the CSS

With those basic building blocks, it’s time to build the CSS. A quick note before we start — because of an IE glitch, we’ll be tiling the after image on top of the before image when we need it, instead of replacing one with the other. The result makes no real visual difference if we line them up precisely, but this method avoids what otherwise would be an obvious “flicker” effect that we don’t want.

#skyline {
width: 400px; height: 200px;
background: url(test-3.jpg);
margin: 10px auto; padding: 0;
position: relative;}
#skyline li {
margin: 0; padding: 0; list-style: none;
position: absolute; top: 0;}
#skyline li, #skyline a {
height: 200px; display: block;}

Counter-intuitively, we’re not assigning the before image to the links at all, it’s applied to the <ul> instead. You’ll see why in a moment.

The rest of the CSS in the above example sets things like the dimensions of the #skyline block and the list items, starting positions for the list items, and it turns off the unwanted list bullets.

We’ll be leaving the links themselves as empty, transparent blocks (though with specific dimensions) to trigger the link activity, and position them using the containing <li>s. If we were to position the links themselves and effectively ignore the <li>s, we’d start seeing errors in older browsers, so let’s avoid this.

The <li>s are absolutely positioned, so why aren’t they at the top of the browser window? A quirky but useful property of positioned elements is that all descendent elements contained within them base their absolute position not off the corners of the browser window, but off the corners of the nearest positioned ancestor element.The upshot of this is that since we applied position: relative; to #skyline, we’re able to absolutely position the <li>s from the top left corner of #skyline itself.

#panel1b {left: 0; width: 95px;}
#panel2b {left: 96px; width: 75px;}
#panel3b {left: 172px; width: 110px;}
#panel4b {left: 283px; width: 117px;}

So #panel1 isn’t horizontally positioned at all, #panel2b is positioned 96px to the left of #skyline’s left edge, and so on. We assigned the links a display: block; value and the same height as the <li>s in the past listing, so they’ll end up filling their containing <li>s, which is exactly what we want.

At this point we have a basic image map with links, but no :hover states. See the example. It’s probably easier to see what’s happening with borders turned on.

Hovers

In the past we would have applied some JavaScript to swap in a new image for the after state. Instead our after states are in one image, so all we need is a way to selectively pull each state out for the appropriate link.

If we apply the master image to the :hover state without additional values, we make only the top left corner visible — not what we want, though clipped by the link area, which is what we want. We need to move the position of the image somehow.

We’re dealing with known pixel values; a little bit of math should enable us to offset that background image enough both vertically and horizontally so that only the piece containing the after state shows.

That’s exactly what we’ll do:

#panel1b a:hover {
background: transparent url(test-3.jpg)
0 -200px no-repeat;}
#panel2b a:hover {
background: transparent url(test-3.jpg)
-96px -200px no-repeat;}
#panel3b a:hover {
background: transparent url(test-3.jpg)
-172px -200px no-repeat;}
#panel4b a:hover {
background: transparent url(test-3.jpg)
-283px -200px no-repeat;}

Where did we get those pixel values? Let’s break it down: the first value is of course the horizontal offset (from the left edge), and the second is the vertical.

Each vertical value is equal; since the master image is 400 pixels high and the after states sit in the bottom half, we’ve simply divided the height. Shifting the whole background image up by 200px requires us to apply the value as a negative number. Think of the top edge of the link as the starting point, or 0. To position the background image 200 pixels above this point, it makes sense to move the starting point -200px.

Likewise, if the left edge of each link is effectively 0, we’ll need to offset the background image horizontally by the width of all <li>s prior to the one we’re working with. So the first link doesn’t require an offset, since there are no pixels before its horizontal starting point. The second link requires an offset the width of the first, the third link requires an offset of the combined width of the first two links, and the last requires an offset of the combined width of all three previous links.

It’s a bit cumbersome to explain the process, but playing around with the values will quickly show you how the offsets work, and once you’re familiar it’s not all that hard to do.

So there you have it. Single-image CSS rollovers, degradable to a simple unordered list.

Buttons

There’s no reason why we have to leave the links touching each other, side-by-side as they were in the previous example. Image maps may be convenient in some spots, but what about separating each link into its own stand-alone button? That way we can add borders and margins, let the underlying background show through, and generally treat them as separately as we need to.

In fact, the building blocks are already in place. We really don’t need to modify our code too radically; the main change is in creating a new background image that doesn’t continue from link to link like the last example did. Since we can’t rely on the <ul> for placing the original background image, we’ll end up applying it to all <li>s instead and offsetting each the same way we offset the after states in the prior example.

With an appropriate image and a bit of spacing between each <li>, we’ve got buttons.

Note that in this example we’ve added 1px borders which, of course, count toward the final width of the links. This affects our offset values; we’ve compensated by adding 2px to the offsets where appropriate.

Irregular shapes

Up till now we’ve focused only on rectangular, non-overlapping shapes. What about the more complex image maps that image slicers like Fireworks and ImageReady export so easily? Relax, we’ve got you covered there too.

We’ll start the same way as the first example, by applying the background image to the <ul> and turning off list item bullets and setting widths and so forth. The big difference is where we position the <li>s; the goal is to surround each graphical element with a box that tightly hugs the edges.

Again, because of the ability to use absolute positioning relative to the top left corner of the <ul>, we’re able to precisely place our links exactly where we want them. Now all that’s left is to set up the hover states.

Worth noting is that in this case, a single set of before and after images wasn’t enough. Because of the overlapping objects, relying on only one after state would show pieces of surrounding objects’ after states. In fact, it would show precisely the pieces that fall within the link’s borders. (Easiest to just see it in action.)

How to avoid this? By adding a second after state, and carefully selecting which objects go where. The master image in this case has split the purple and blue objects into the first after state, and the green, orange and yellow objects into the second. This order allows boxes to be drawn around each object’s after state without including pieces of the surrounding objects. And the illusion is complete.

Benefits and pitfalls

A couple of final thoughts. Our new CSS Sprite method tests well in most modern browsers. The notable exception is Opera 6, which doesn’t apply a background image on link hover states. Why, we’re not sure, but it means that our hovers don’t work. The links still do, and if they’ve been labeled properly, the net result will be a static, but usable image map in Opera 6. We’re willing to live with that, especially now that Opera 7 has been around for a while.

The other concern is familiar to anyone who has spent time with FIR. In the rare cases in which users have turned off images in their browsers but retained CSS, a big empty hole will appear in the page where we expect our images to be placed. The links are still there and clickable, but nothing visually appears. At press time, there was no known way around this.

Then there’s file size. The natural tendency is to assume that a full double-sized image must be heavier than a similar set of sliced images, since the overall image area will usually be larger. All image formats have a certain amount of overhead though (which is why a 1px by 1px white GIF saves to around 50 bytes), and the more slices you have, the more quickly that overhead adds up. Plus, one master image requires only a single color table when using a GIF, but each slice would need its own. Preliminary tests suggest that all this indicates smaller total file sizes for CSS Sprites, or at the very least not appreciably larger sizes.

And lastly, let’s not forget that our markup is nice and clean, with all the advantages that go along with that. HTML lists degrade wonderfully, and a proper image replacement technique will leave the text links accessible to screenreaders. Replacing the sprite imagery is dead simple, since all of our dimensions and offsets are controlled in a single CSS file, and all of our imagery sits in a single image.

Sliding Doors of CSS
http://www.alistapart.com/articles/slidingdoors/

A rarely discussed advantage of CSS is the ability to layer background images, allowing them to slide over each other to create certain effects. CSS2’s current state requires a separate HTML element for each background image. In many cases, typical markup for common interface components has already provided several elements for our use.

One of those cases is tabbed navigation. It’s time to take back control over the tabs which are continually growing in popularity as a primary means of site navigation. Now that CSS is widely supported, we can crank up the quality and appearance of the tabs on our sites. You’re most likely aware that CSS can be used to tame a plain unordered list. Maybe you’ve even seen lists styled as tabs, looking something like this:

What if we could take the exact same markup from the tabs above, and turn them into something like this:

With simple styling, we can.

Where’s the Innovation?

Many of the CSS-based tabs I’ve seen suffer from the same generic features: blocky rectangles of color, maybe an outline, a border disappears for the current tab, a color changes for the hover state. Is this all CSS can offer us? A bunch of boxes and flat colors?

Prior to a more widespread adoption of CSS, we started seeing a lot of innovation in navigation design. Creative shapes, masterful color blending, and mimicry of physical interfaces from the real world. But these designs often relied heavily on a complex construction of text-embedded images, or were wrapped with multiple nested tables. Editing text or changing tab order involved a cumbersome process. Text resizing was impossible, or caused significant problems with page layout.

Pure text navigation is much easier to maintain and loads more quickly than text-as-image navigation. Also, even though we can add alt attributes to each image, pure text is even more accessible since it can be resized by users with impaired vision. It’s no wonder that pure text-based navigation, styled with CSS, is leaping back into web design. But most CSS-based tab design so far is a step back in appearance from what we used to do — certainly nothing to be included in a design portfolio. A newly adopted technology (like CSS) should allow us to create something better, without losing the design quality of previous table hacks and all-image-based tabs.

The Sliding Doors Technique

Beautifully crafted, truly flexible interface components which expand and contract with the size of the text can be created if we use two separate background images. One for the left, one for the right. Think of these two images as Sliding Doors that complete one doorway. The doors slide together and overlap more to fill a narrow space, or slide apart and overlap less to fill a wider space, as the diagram below shows:

With this model, one image covers up a portion of the other. Assuming we have something unique on the outside of each image, like the rounded-corner of a tab, we don’t want the image in front to completely obscure the image behind it. To prevent this from happening, we make the image in front (left-side for this example) as narrow as possible. But we keep it just wide enough to reveal that side’s uniqueness. If the outside corners are rounded, we should make the front image only as wide as the curved portion of the image:

If the object grows any larger than the width shown above, due to differing text or type size changes, the images will get pulled apart, creating an ugly gap. We need to make an arbitrary judgment about the amount of expansion we’ll accommodate. How large do we think the object might grow as text is resized in the browser? Realistically, we should account for the possibility of our tab text increasing by at least 300%. We need to expand the background images to compensate for that growth. For these examples we’ll make the back image (right-side) 400x150 pixels, and the front image 9x150 pixels.

Keep in mind that background images only show in the available “doorway” of the element to which they’re applied (content area + padding). The two images are anchored to the outside corners of their respective elements. The visible portions of these background images fit together inside the doorway to form a tab-like shape:

If the tab is forced to a larger size, the images slide apart, filling a wider doorway, revealing more of each image:

For this example, I used Photoshop to create two smooth, slightly three-dimensional, custom tab images shown at the beginning of this article. For one of the tabs, the fill was lightened and the border darkened — the lighter version will be used to represent the “current” tab. Given this technique’s model for left and right tab images, we need to expand coverage area of the tab image, and cut it into two pieces:

The same thing needs to happen with the lighter current tab image. Once we have all four images created, (1, 2, 3, 4) we can jump into the markup and CSS for our tabs.

Tab Creation

As you explore the creation of horizontal lists with CSS, you’ll notice at least two methods for arranging a group of items into one row. Each comes with its own benefits and drawbacks. Both require dealing with rather funky aspects of CSS which quickly become confusing. One uses the inline box, the other uses floats.

The First Method — and possibly the more common — is to change the display of each list item to “inline”. The inline method is attractive for its simplicity. However, the inline method causes a few rendering problems in certain browsers for the Sliding Doors technique we’re going to discuss. The Second Method, which is the one we’ll focus on, uses floats to place each list item in a horizontal row. Floats can be equally frustrating. Their seemingly inconsistent behavior circumvents all natural logic. Still, a basic understanding of how to deal with multiple floated elements, and the means to reliably “break out” of floats (or contain them) can achieve wonders.

We’re going to nest several floated elements within another containing floated element. We do this so that the outer parent float completely wraps around the floats inside. This way, we’re able to add a background color and/or image behind our tabs. It’s important to remember that the next element following our tabs needs to reset its own position by using the CSS clear property. This prevents the floated tabs from affecting the position of other page elements.

Let’s begin with the following markup:

<div id="header">
<ul>
<li><a href="#">Home</a></li>
<li id="current"><a href="#">News</a></li>
<li><a href="#">Products</a></li>
<li><a href="#">About</a></li>
<li><a href="#">Contact</a></li>
</ul>
</div>

In reality, the #header div might also contain a logo and a search box. For our example, we’ll shorten the href value in each anchor. Obviously, these values would normally contain file or directory locations.

We begin styling our list by floating the #header container. This helps ensure the container actually “contains” the list items inside which will also be floated. Since the element is floated, we also need to assign it a width of 100%. A temporary yellow background is added to ensure this parent stretches to fill the entire area behind the tabs. We also set some default text properties, ensuring everything inside will be the same:

#header {
float:left;
width:100%;
background:yellow;
font-size:93%;
line-height:normal;
}

For now, we also set all of the default margin/padding values of the unordered list and list items to “0”, and remove the list item marker. Each list item gets floated to the left:

#header ul {
margin:0;
padding:0;
list-style:none;
}
#header li {
float:left;
margin:0;
padding:0;
}

We set the anchors to block-level elements so we can control all aspects without worrying about the inline box:

#header a {
display:block;
}

Next, we add our right-side background image to the list item (changes/additions are bolded):

#header li {
float:left;
background:url("norm_right.gif")
no-repeat right top;
margin:0;
padding:0;
}

Before adding the left-side image, we pause so we can see what we have so far in Example 1. (In the example file, ignore the rule I’ve applied to the body. It only sets up basic values for margin, padding, colors, and text.)

- - -

Now we can place the left-side image in front of the right by applying it to the anchor (our inner element). We add padding at the same time, expanding the tab and pushing the text away from the tab edges:

#header a {
display:block;
background:url("norm_left.gif")
no-repeat left top;
padding:5px 15px;
}

This gives us Example 2. Note how our tabs have begun to take shape. At this point, a word of acknowledgement to confused IE5/Mac users, who are wondering, “What’s going on here? The tabs are stacked vertically and stretch across the entire screen.” Don’t worry, we’ll get to you soon. For now, do your best to follow along, or temporarily switch to another browser if one is handy, and be assured we’ll fix the IE5/Mac issue shortly.

- - -

Now that we have the background images in place for normal tabs, we need to change the images used for the “current” tab. We do this by targeting the list item which contains id="current" and the anchor inside it. Since we don’t need to alter any other aspects of the background, other than the image, we use the background-image property:

#header #current {
background-image:url("norm_right_on.gif");
}
#header #current a {
background-image:url("norm_left_on.gif");
}

We need some kind of border along the bottom of our tabs. But applying a border property to the parent #header container won’t allow us to “bleed” the current tab through this border. Instead, we create a new image with the border we want included along the bottom of the image. While we’re at it, we also add a subtle gradient so it looks like this:

We apply that image to the background of our #header container (instead of the yellow color we had), push the background image to the bottom of the element, and use a background color matching the top of this new image. At the same time, we remove the padding from the body element I originally inserted for us, and apply 10 pixels of padding to the top, left, and right sides of the ul:

#header {
float:left;
width:100%;
background:#DAE0D2 url("bg.gif")
repeat-x bottom;
font-size:93%;
line-height:normal;
}
#header ul {
margin:0;
padding:10px 10px 0;
list-style:none;
}

To complete the tab effect, we need to bleed the current tab through the border, as mentioned above. You might think we would apply bottom borders to our tabs matching the border color in the #header background image we just added, then change the border color to white for the current tab. However, doing this would result in a tiny “step” visible to pixel-precision eyes. Instead, if we alter the padding of the anchors, we can create perfectly squared-off corners inside the current tab, as the magnified example below shows:

We do this by decreasing the bottom padding of the normal anchor by 1 pixel (5px - 1px = 4px), then adding that pixel back to the current anchor:

#header a {
display:block;
background:url("norm_left.gif")
no-repeat left top;
padding:5px 15px 4px;
}
#header #current a {
background-image:url("norm_left_on.gif");
padding-bottom:5px;
}

The change allows the bottom border to show through for normal tabs, but hides it for the current tab. This brings our code up to Example 3.

Finishing Touches

Keen eyes may have noticed white tab corners showing up in the previous example. These opaque corners are currently preventing the image in the back from showing through the left corner of the image in front. In theory, we could attempt to match the corners of the tab images with a portion of the background behind them. But our tabs can grow in height, which pushes the background behind them lower, shifting the background color we tried to match. Instead, we change the images, making the corners of our tabs transparent. If the curves are anti-aliased, we matte the edges to an average of the background color behind them.

Now that the corners are transparent, a piece of the right-side image shows through the corner of the left-side image. To compensate for this, we add a small amount of left padding to the list item equivalent to the width of the left-side image (9px). Since padding was added to the list item, we need to remove that same amount from the anchor to keep the text centered (15px - 9px = 6px):

#header li {
float:left;
background:url("right.gif")
no-repeat right top;
margin:0;
padding:0 0 0 9px;
}
#header a {
display:block;
background:url("left.gif")
no-repeat left top;
padding:5px 15px 4px 6px;
}

However, we can’t leave it at that either, because our left-side image now gets pushed away from the left tab edge by the 9 pixels of padding we just added. Now that the inner edges of the left and right visible doorways butt up against each other, we no longer need to keep the left image in the front. So we can switch the order of the two background images, applying them to opposite elements. We also need to swap the images used for the current tab:

#header li {
float:left;
background:url("left.gif")
no-repeat left top;
margin:0;
padding:0 0 0 9px;
}
#header a, #header strong, #header span {
display:block;
background:url("right.gif")
no-repeat right top;
padding:5px 15px 4px 6px;
}
#header #current {
background-image:url("left_on.gif");
}
#header #current a {
background-image:url("right_on.gif");
padding-bottom:5px;
}

Once we do this, we arrive at Example 4. Note that the tweaks required to make the corners transparent creates a small dead space on the left side of the tab where it’s not clickable. The dead space is outside the text area, but it is slightly noticeable. Using transparent images for each side of our tabs is not required. If we prefer not to have the small dead space, we need to use a flat color behind the tabs, then use this color in the corner of our tab images instead of making them transparent. We’ll keep the new transparent corners for now.

- - -

For the remaining tweaks, we make a slew of changes all at once: bold all tab text, change normal tab text to a brown color, make current tab text a dark gray color, remove link underlines, and change the text color for the link hover state to the same dark gray. We see all additions and changes so far represented in Example 5.

One Hack for Consistency

After Example 2, we acknowledged a problem with IE5/Mac where each tab stretched across the entire browser width, forcing each one to stack vertically on top of each other. Not quite the effect we were intending.

In most browsers, floating an element will act sort of like shrink-wrapping it — it gets shrunk to the smallest possible size of the contents it contains. If a floated element contains (or is) an image, the float will shrink to the width of the image. If it contains only text, the float will shrink to the width of the longest non-wrapping line of text.

A problem enters the picture for IE5/Mac when an auto-width block-level element is inserted into a floated element. Other browsers still shrink the float as small as possible, regardless of the block-level element it contains. But IE5/Mac doesn’t shrink the float in this circumstance. Instead, it expands the float and block-level element to full available width. To work around this problem, we need to float the anchor also, but only for IE5/Mac, lest we throw off other browsers. First we’ll set the existing rule to float the anchor. Then we’ll use the Commented Backslash Hack to hide a new rule from IE5/Mac which removes the float for all other browsers:

#header a {
float:left;
display:block;
background:url("right.gif")
no-repeat right top;
padding:5px 15px 4px 6px;
text-decoration:none;
font-weight:bold;
color:#765;
}
/* Commented Backslash Hack
hides rule from IE5-Mac \*/
#header a {float:none;}
/* End IE5-Mac hack */

IE5/Mac browsers should now display the tabs as intended, according to Example 6. Nothing should have changed for non-IE5/Mac browsers. Note that IE5.0/Mac suffers from a lot of rendering bugs that were fixed in the upgrade to IE5.1. Because of this, the Sliding Doors technique suffers in version 5.0 beyond a point I’m willing to hack. Since the upgrade to IE5.1/Mac has been readily available for some time now, the percentage of OS 9 Macs still running IE5.0 should be tapering off to almost nothing.

Variations

We just walked through the Sliding Doors technique for creating tabbed navigation with pure text, marked up with an unordered list of links, altered with a few custom styles. It loads fast, is simple to maintain, and text within can be scaled up or down significantly in size without breaking the design. Need we mention how flexible the technique can be for creating any type of sophisticated-looking navigation?

Use of this technique is only limited by our imagination. Our final example represents just one possibility. But we shouldn’t let an example place boundaries on our ideas.

For instance, tabs aren’t required to be symmetrical. I quickly created Version 2 of these tabs, which avoids the shaded 3-D look in favor of flat colors, angular edges, and a wider and more detailed left-side. We can even switch the order of left/right images, depending on the design, as Version 2 shows. With some careful planning and clever image manipulation, the bottom border could be abandoned in favor of matching the tab images with the background running behind them, as shown in my Deco-inspired Version 3. If your browser supports alternate style sheet switching, you can even view this master file, and switch between the three different versions by alternating between style sheets.

Other effects we don’t cover here could be added on top of this technique. In the example I ran through, I changed the text color for the hover state, but entire images could be swapped out to create interesting rollover effects. Wherever two nested HTML elements already exist in the markup, CSS can be used to layer background images for effects we haven’t even begun to imagine yet. We created a horizontal row of tabs in this example, but Sliding Doors could be used in a many other situations. What can you do with it?

Translations
Italian (gdesign.it)
Russian (id-as.com)

The Next Big Thing
http://www.alistapart.com/articles/cssatten/

CSS is ten years old this year. Such an anniversary is an opportunity to revisit the past and chart the future. CSS has fundamentally changed web design by separating style from structure. It has provided designers with a set of properties that can be tweaked to make marked-up pages look right—and CSS3 proposes additional properties requested by designers.

Many CSS properties, both old and new, deal with text: they describe text color, position, style, and direction. This is all very good—after all, text fills most of our screens. But in order for properties to reach their full potential, we need a good selection of fonts. And fonts are sorely missing from the web.

Consider the fine designs in the CSS Zen Garden. What makes them so exciting to look at? In part, it is the variety of fonts. Fonts convey design messages and create effect, and while in traditional print design there are a plethora of fonts available, fonts have been in limited supply on the web. Web designers depend on ten or so universally available fonts for their designs, and are reduced in large part to using Verdana and Arial over and over again. A typical CSS Zen Garden design, on the other hand, uses a hand-picked font to render text and aligns the glyphs to a pixel-perfect degree…and then uses that text as a background image.

A background image!

There are many reasons why background images should not be used to convey text. Images are expensive to transmit and hard to make. Imagine trying to translate a web page into 15 languages and having to produce a set of images for each language. Additionally, the quality of printed web pages suffers as images don’t scale to the resolutions offered by modern printers. Using background images is currently the only way designers can use their favorite fonts on the web. But shouldn’t web designers have access to a wider selection of fonts and be able to use them without having to resort to creating background images?

There is a way: web fonts. 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.

A brief history of web fonts

This is not a new idea. In 1998, CSS2 described a way to link to fonts from style sheets, and both Microsoft and Netscape added support for web fonts in their browsers. However, neither vendor supported the most widely used font format, TrueType. Instead, they each picked a different, little-used format with few tools to support it (EOT and TrueDoc, respectively). And so web fonts disappeared from the designer’s toolbox.

Better news

It’s a pleasure for me to announce that web fonts are back! Here are some recently generated examples that show how a familiar document can be rendered when TrueType web fonts are available:

Screenshot of web page using real TrueType fonts. PDF (via Prince). HTML (via your browser).

Screenshot of web page using real TrueType fonts. PDF (via Prince). HTML (via your browser).

Screenshot of web page using real TrueType fonts. PDF (via Prince). HTML (via your browser).

The PDF (and image) examples shown in this article have been produced by Prince 6, a web-to-PDF-through-CSS renderer. (The Macintosh version must be installed via Terminal. Instructions are included in a ReadMe file. —Ed.) Prince is currently the only program that supports TrueType web fonts, but it provides the proof of concept we need to begin thinking seriously about web fonts—and to begin advocating for their implementation in common web browsers. Before we get to that, though, let’s take a look at the code beneath these examples.

(Disclosure: I’m on the board of YesLogic, the company behind Prince. Being on the board is a neat way of pushing for your favorite features to be implemented.)

The examples are coded in HTML and CSS only; no images are involved. CSS3 multi-column layouts and rounded borders have been added for good measure, but they are not essential to the designs. Each example uses four different web fonts. The style sheets point to web font files which are fetched before the documents are rendered.

Web fonts: the code you’ll use

Here is a simple example of how to use web fonts (Line wraps marked » —Ed.):

@font-face {
font-family: "Kimberley";
src: url(http://www.princexml.com/fonts/larabie/ »
kimberle.ttf) format("truetype");
}
h1 { font-family: "Kimberley", sans-serif }

Those familiar with CSS syntax will recognize the last line. The @font-face construct may not be familiar, however it’s easy to explain: as the “Kimberley” font is requested, the font file is fetched from the specified URL. The syntax is described in the CSS2 specification.

To avoid long lists of @font-face declarations in the style sheet, they can be hidden using @import (Line wraps marked » —Ed.):

@import url(http://www.princexml.com/fonts/ »
larabie/index.css) all;
h1 { font-family: Goodfish, serif }

The TrueType files used in the examples above are designed by Ray Larabie. He is a renowned font designer who has made hundreds of interesting TrueType fonts freely available for use on the web. His fonts are elegant, decorative, and playful.

Dieter Steffmann is another great font designer. He, too, has made many beautiful fonts available for anyone to use. Below are some examples that use his fonts:

Screenshot of web page using real TrueType fonts. PDF (via Prince). HTML (via your browser).

Screenshot of web page using real TrueType fonts. PDF (via Prince). HTML (via your browser).

Screenshot of web page using real TrueType fonts. PDF (via Prince). HTML (via your browser).

Getting more complicated

When browsers start supporting web fonts, designers will be tempted to adjust more properties than just font-family. In the examples shown above, line-height, letter-spacing, word-spacing, and absolute positioning have been tweaked. This adjustment of other properties works well when the specified fonts are fetched from the web. However, it may have unexpected results in browsers that don’t support web fonts, and web designers should always be make sure their pages degrade gracefully.

The most obvious way to ensure graceful degradation is to specify a list of similar font families. For example, Ray Larabie’s “Primer Apples” is a charming, stitched font. You can see it used in this example:

Screenshot of web page using real TrueType fonts. PDF (via Prince). HTML (via your browser).

“Primer Apples” has no obvious replacement in the list of fonts normally used on the web. However, the font metrics are quite similar to the ubiquitous “Trebuchet” font which can be specified as an alternative (Line wraps marked » —Ed.):

font-family: "Primer Apples", "Trebuchet MS", »
sans-serif;

In a legacy browser without support for web fonts (or multi-column layouts or rounded borders), the second example will look like this:

Screenshot of web page without support for web fonts.

The stitching is gone, but the degradation is graceful.

A proposal to the W3C: a media query for web fonts

To further limit degradation, it would be useful to have a media query for web fonts. Consider this example:

h1 {
font-family: "Trebuchet MS", sans-serif;
letter-spacing: 0.1em;
}

@media all and (web-fonts: "truetype") {
h1 {
font-family: "Primer Apples", sans-serif;
letter-spacing: 0.2em;
}
}

As a result of the media query in the example above, the actual letter-spacing will depend on whether web fonts are supported or not. It is also necessary to specify, in the media query, that support for TrueType is required. The “web-fonts” media query is not in the W3C’s current Media Queries specification and it has not been implemented by anyone. But it’s a great idea, and very doable.

What does this mean in the real world?

While Prince offers a neat proof-of-concept, common web browsers must also add support for web fonts in order for them to become the next big thing. So why haven’t they done so already?

The arguments against web fonts are mostly legal. Fonts are intellectual property and therefore, the argument goes, cannot be published on the web. Although the legal status of font shapes is uncertain, font names are probably covered by copyright law. As such, fonts are similar to copyrighted images and text. To publish copyrighted material on the web, you need permission from the copyright holder. There is a lot of text and images on the web because copyright holders allow it, even encourage it. Likewise, many font designers (including Ray Larabie and Dieter Steffmann, whose fonts I use as examples in this article) allow their fonts to be freely used on the web.

The best argument against web fonts, however, isn’t legalities—it’s aesthetics. Do we want to wade through web pages displayed in third-rate fonts put together by designers who once used the <blink> tag and created backgrounds with animated GIFs? Probably not. Once web fonts are available, make sure you use a browser in which author style sheets can be turned off. (Another disclosure: That would be Shift+G in Opera.)

Aesthetics also provide a strong argument for web fonts. There are many beautiful and interesting fonts that can improve aesthetics and increase visual variety on the web. Just as I am sometimes stunned by beautiful book designs, I want to be overwhelmed by beautiful web pages. And, I don’t want those beautiful pages to be made up of background images.

You can help!

Two things must happen before web fonts can take web design to the next level. First, we must ensure the validity of the approach. Is the subset of CSS2 that has been implemented sufficient? Do we like the CSS code? The best way to help is to play with the existing implementation and report back on your experience.

Second, we must convince browser makers to add support for web fonts. This can be difficult. Browser vendors have lots of specifications and well-intended improvement proposals to choose from. Some of them are also busy fixing bugs. In order for new functionality to make it onto the roadmaps, a compelling story must be told, and a critical mass of developers must voice their support. We can make it happen.

CSS has been around for ten years, and is likely to be around for another decade. Let’s finally give it some fonts to work with!

Real Web Type in Real Web Context
http://www.alistapart.com/articles/real-web-type-in-real-web-context/

Now that browsers support real fonts in web pages and we can license complete typefaces for such use, let’s move past the hype of web type and think pragmatically about how to use real fonts in our web projects. Several experiments with the CSS @font-face property, including some preliminary work with the much-anticipated Typekit, have led me to a single, urgent conclusion: I need to know how my type renders on screens, in web browsers. To that end, I created Web Font Specimen, a handy (free) resource web designers and typographers can use to see how typefaces will look on the web.

Markup-and-style samples for testing purposes are nothing new. You probably already have a go-to resource bookmarked, be it the W3C’s HTML element sampler or something homegrown. Web Font Specimen is very much like the sample files we find or make for ourselves, with two important distinctions: its sole purpose is to exercise a typeface, and it is ours to share.

Web Font Specimen is available under a Creative Commons Attribution 3.0 license. I welcome and look forward to your adjustments, iterations, and improvements. We’ll return to this issue in the context of buying and selling type.

Let’s quickly go over what Web Font Specimen looks like and how to use it. Afterward, we’ll discuss ways of paying closer attention to web type rendering—as well as how this approach will influence type sellers, type designers, and web designers.

Web Font Specimen

Head over to Web Font Specimen, download the .zip file, and preview the HTML in a browser. You should see something like this example. Rendering will vary depending on your setup, but the example specimen should come through just fine (it’s plain old Georgia—most of you should have it installed, and it was designed to look good on screen).

Scroll down and you’ll see Georgia exercised in headings, lists, and with varying emphasis. There’s a body size comparison, different leadings (line-heights), a showcase of glyphs, different measures (widths), different sizes with uppercase and sentence case, grayscale text, light-on-dark text, and, an assortment of color combinations. Reasons for including each of these in the specimen are listed alongside a labeled screenshot at Web Font Specimen.

Fig. 1. Glyphs at 42px.

Fig. 2. Headings, lists, emphasis, and leading.

Fig. 3. Grayscale and color, light on dark.

Kick the tires

Next, you will replace Georgia with the typeface you want to test. See the README file in the download for instructions on how to do this. For additional information, see two of my posts at Nice Web Type—“Where to get web fonts” and “How to use CSS @font-face.”

You may notice that Web Font Specimen is built atop Nathan Smith’s 960.gs, which is a great resource for quick layouts. Just as I have done with Nice Web Type likes reviews, the text.css file that comes with 960.gs has been replaced by one that is more streamlined for our needs.

All that’s left to do is test the result and decide for yourself whether the way your typeface renders across operating systems and browsers is, indeed, acceptable.

What this means for type sellers

Part of the reality of type sellers’ changing business is that they suddenly have a huge new market for their goods and services. Sure, we web designers have always used type in our sites: Replacement techniques, images with alt text, and fonts summoned with CSS have yielded some incredible typographic experiences (these and more are detailed at Typesites). However, we’ve rarely dealt with type the way print folks regularly do, because our experiences in web typesetting have always had more to do with the means than the end.

No more kiddie table

For years, web designers have yearned to embrace typography in its fullest aesthetic and traditional capacities while bringing to bear all that we know about sound markup and universal accessibility. But the nature of our technical means for getting fonts into websites has acted as a barrier to setting realistic expectations for the appearance of web type on screens.

We’ve been so busy getting type into our sites, we haven’t had a chance to figure out why it looks the way it does when it gets there. As a result, web type rendering has largely remained a mystery. Rather than try to sort things out, we’ve simply treated web typography as a lesser art (with some wonderful exceptions), and our grumbles of dissatisfaction have reverberated.

Show us real type

As web designers mentally overcome the print-is-better-than-web inferiority complex, type sellers know that a throng of new customers will expect to be treated fairly when browsing, sampling, and using type. Web Font Specimen is great when the typefaces we want to sample are in our possession. But when typefaces are locked within font delivery services, or behind a type seller’s shopping cart, how will we judge whether they are suitable for use in our web projects?

Type sellers need to provide some way to show the type they license for use with the CSS @font-face property in its actual intended context. They are certainly welcome (cordially and legally invited, even) to use Web Font Specimen as part of a try-before-you-buy experience. I hope they will, and not only because of our need to see how typefaces will look on the web, but because their type adjustments, iterations, and improvements will make Web Font Specimen better. Web designers will be watching to see how type pros think type should be exercised, and we will adjust our toolbox specimen to take advantage of their advice—if they haven’t already done so for us by re-releasing a better iteration of Web Font Specimen.

What this means for type designers

If type sellers are unable to or reluctant to find ways to show their type in context on the web, type designers will not be able to showcase the nuances they have worked so hard to achieve in their fonts. To meet web designers’ type rendering expectations will be a significant challenge. The lasagna of complexity between the beautiful letters type designers draw and the type we all see on websites is largely undocumented and full of variables.

From glyphs to web type

Working through several Typophile threads with folks knowledgeable on the subject, I have tried to envision the gauntlet type must endure on its journey from type designers’ mathematical points and curves to Web Font Specimen’s grid-fitted shapes made of light. Here is my working list of steps, which has been improved with several suggestions and blessed by David Berlow as “pretty good overall.”

1. A glyph starts as a bezier-based shape.

2. This shape is made in or brought into a font-creation program such as FontLab.

3. Settings such as UPM (units per em), key dimensions (for vertical measurements such as x-height, cap height, ascenders and descenders), and metrics (for horizontal measurements such as sidebearings and kerning) determine how the letterform will act as a glyph in a font—e.g., how much room it will occupy at a given size, how close other letters may live.

4. Hinting or instructions are added (automatically and/or manually) which can provide directions to conserve the font’s design character in environments where less-than ideal output is to be employed.

5. The glyph is exported as part of a font, in either OTF or TTF format (in this context, I am ignoring all other formats—let me know if I shouldn’t). TrueType hints are ditched if the font is OTF.

6. The glyph is confronted by operating-system-level and browser-level rendering algorithms. I am still trying to list these combinations for myself. I would want to cross-reference technologies such as Quartz and ClearType with headings such as OS rendering engine, browser rendering engine, result of combination (overrides, any ignored font data).

7. User settings in various places (browser preferences, OS preferences) can modify how and when the rendering engines interact with font files. Windows users can turn ClearType on or off. Users can turn antialiasing off altogether. Certain preferences can limit the size at which antialiasing is applied. Listing these variables is another item on my to-do list.

8. Finally, there are the physical qualities of a user’s hardware, such as the kind of monitor they use, its resolution, whether they run it at native resolution or not, and their settings for color and luminosity.

Steps four through six are important and must not be overlooked. These factors may be the bane of type designers—especially independent shops. In the eyes of a new audience that will judge typeface quality by on-screen rendering alone, the way a typeface looks across different operating systems and browsers is critical.

Without getting into specifics (let’s save them for the discussion forum), the possible rendering algorithm combinations most often conclude in one of two ways: 1) the rendering engine ignores hints from type designers and does its own thing, remaining as true as can be to typeface design, usually with a good-looking result (this is Apple); or 2) the rendering engine relies upon complex hints from type designers, tries to use that information for ideal readability, and only looks good if the type is designed and hinted to suit this aim (this is Microsoft).

What can type designers do? Well, three things. They can prepare their typefaces to look good across different setups (even though it’s quite difficult and time consuming), they can wage a campaign for type rendering standards, or they can lose business. These are awful options.

Should type designers decide upon something like a Type Standards Project, however, I’m sure they would find skilled advocates and passionate allies on this side of the shopping cart.

What this means for web designers

Already we have read about some roles web designers can play. We must move past web typography’s stigma of subordination by embracing realistic expectations for the appearance of web type and, if type designers think it worthy, we might once again bring change to a situation (typeface rendering on screens) in which standards would help.

Meanwhile, we have to make sure type looks good in our sites today.

If we run our favorite typeface through a copy of Web Font Specimen, test it across browsers, and we like how it looks, then great! That’s the typeface we will use. But what if we don’t like the way it looks? What do we do next? What are our options?

If your type renders poorly

If we (and our visitors) are lucky, we might be able to look for a different typeface that does render well on screen. Despite the foreboding aspects of type design in this emerging market, thoroughly-hinted typefaces already exist that render very well in different situations—and more are on the way. For though many type designers will be disadvantaged by not having the experience or resources to augment their work with fine-tuned hinting, many others will thrive.

Disappointing as it might be at times to have to choose a typeface other than the one we seek, at other times it could be devastating. If your project is entirely dependent on the use of a particular typeface, such as when following brand-based guidelines, we may still be stuck with replacement hacks.

Unless something changes about how many typefaces are rendered across operating systems and browsers—whether that change comes from rendering agents that accept standards of some kind, or from a greater selection of thoroughly-hinted typefaces—these are the realistic choices many of us will face when we decide to use real fonts with @font-face:

- use some kind of conditional logic to serve different typefaces to different visitors,

- allow our type to render in an unsatisfactory way for some visitors, and

- continue using replacement techniques.

Go forth and spec type

To make change, the best thing we can do is argue for a better way by first understanding the challenges we face. To see how typefaces will look on the web, we just need a good specimen. I hope this article and Web Font Specimen make these activities easier and more fun for you, and that you find something of value here and use it to our collective advantage—for the betterment of typographic style and practice.

This article is available in Russian.

On Web Typography
http://www.alistapart.com/articles/on-web-typography/

There are many books and articles on typography, but considerably few explore typeface selection and pairing. With the floodgates poised to open and the promise of many typefaces being freed up for use on websites, choosing the right face to complement a website’s design will need to become another notch in the designer’s belt. But where do we start?

Until now, using any typefaces beyond those installed with computer operating systems by default meant using images, Flash, or some other workaround. But browser makers have put the ball in our court by implementing the @font-face CSS property, which allows designers to link to any font file and pull it into their pages.

This exposed the elephant in the type foundry: Type makers have largely refused to license their raw typefaces on webpages out of concerns about piracy. The @font-face implementation has brought this concern to the forefront, prompting all parties to figure out a mutually copacetic solution. And many solutions are either available or in the works, ranging from augmented font end-user license agreements to hosted third-party font services such as Typekit, Typotheque, and Kernest. Web designers get more options for type, and foundries and type designers make money off of their creations. Problem solved, right? Sorta.

Brave new world

We’ve been spoiled. Until now, chances are that if you dropped some text onto a webpage in a system font at a reasonable size, it was legible. What’s more, we know the ins and outs of the faces we’ve been forced to use. But many faces to which we’ll soon have access were never meant for screen use, either because they’re aesthetically unsuitable or because they’re just plain illegible.

The technical problems with web type also run deep. Inconsistent rendering across browsers and platforms is a substantial hurdle, as are the problems inherent in serving a font file, or more likely a font family: Page sizes can easily jump to 100k and higher. But let’s assume for a moment that these problems will get smoothed out in short order so that we can focus on what to do after that happens.

There’s a serious possibility that by gaining access to the world’s font libraries, we’re opening Pandora’s Box. Many people working on the web today have some knowledge of typography, but my hunch is that many designers are about to feel quite baffled by the new challenges they face.

Context and meaning

Being a web designer will soon require a deeper understanding of typography and how typefaces work. As we move in this direction, our options may be limited at first, but the pool of choices will steadily grow. And as we know, with great power comes great responsibility. Just because you can use the font that looks like it’s wearing bellbottoms, doesn’t mean you should.

The system fonts we commonly use such as Georgia, Verdana, and Arial have become so ubiquitous that any associations we might have with them other than “web” are pretty much gone. The aesthetic expression we were unable to achieve due to scant selection afforded us time to hone legibility on a grand scale. This has largely made the web a “set it and forget it” world, in part due to the rapid state of publishing, but also because we don’t have the fine control over typography that we have in print design.

Picky, picky

Using a typeface because it looks interesting might yield acceptable results, but really practicing the art of typography involves understanding typefaces and what they mean. Picking a good-enough face isn’t that hard, but choosing an appropriate one that fits comfortably within societal and technical concerns can be tough.

Notable type designer Zuzana Licko once said “We read best what we read most.” This notion rings true in our learned behavior, but also reveals the reason for the typographer’s toughest challenge: Reading is a personal and relative act. Reading a long passage in a blackletter face that was considered “readable” centuries ago would take us considerably more time than if that passage was set in a basic serif face. Most of what we read now is set in simple serif and sans serif typefaces, whether in print or online.

Beyond the question of readability, much of typography comes down to contrast and form. The details of a typeface can inject meaning into a design: Soft lines and stroke weights, for example, can be useful for delicate material or to give an air of elegance and dignity. Those same attributes can be juxtaposed with unexpected content to produce an ironic effect.

Here’s a list of qualities and methods to keep in mind as you venture into the widening world of web type.

The drop dead guide to choosing and pairing typefaces

As we look to our coffers for new selections of typefaces, the smart money stays true to what we know: Find typefaces that are in our general realm of readability—the ones we use and read on a daily basis. Anything that hits on those points on the “legibility spectrum” (possibly a four quadrant graph) will be best, and will be easier to read. The farther we veer away from that, the more difficult our designs will be to read. That’s not to say there isn’t a wide gray area of legibility.

Contrast

Contrast is probably the most important thing to keep in mind. When pairing typefaces, it’s important to be able to tell that there are two distinct typefaces in play, but contrast has other uses as well. Very different typefaces can play off of each other in complementary ways or resist each other to create a bit of tension, while typefaces that appear too similar can weaken the message and confuse a design’s visual language.

The basics of body text

Bobulate.com using TypeTogether’s Skolar, served via Typekit.

When choosing typefaces, I like to start by picking a text face for body copy, as this is what a reader will spend the most time looking at. For body copy, look for typefaces that are sturdy and legible at smaller sizes, and for those that have a healthy contrast between characters.

The best text faces generally have some personality, but not so much that it distracts us from the content or experience of reading. Typefaces that have a lot of personality are better reserved for display sizes, as they can become cumbersome to read in longer passages.

Read me

As text gets smaller, a slightly larger x-height and contrast can go a long way.

The usual conventions to selecting type apply for on screen use too, but due to the disparity in quality between the screen and a printed page, those conventions should be followed even more closely on screen, and possibly even exaggerated a little. High x-heights and a strong character body help keep your texts legible, even at small sizes. For instance, Verdana and Georgia, both proven screen typefaces, have a larger x-height and a bit more space between the letters so that text retains clarity even at small sizes.

What’s the message?

This movie poster from the double feature, Grindhouse, uses lots of different typefaces and styles, but does so in imitation of the kinds of posters that were emblematic of late 1970s exploitation films.

One helpful way to understand what you are designing for is to write down a general description of the qualities of the message you are trying to convey, and then look for typefaces that embody those qualities. If you are designing something serious, a playful handwritten display typeface probably won’t work. But a sturdy typeface such as Franklin Gothic could convey stability and strength while imparting an air of importance.

One typeface can be enough to say what you need to say, and two is usually plenty. If you are using more than that, have a good reason—like trying to achieve a certain aesthetic—such as replicating the look of an old boxing, film, or music poster, for example.

One sans, one serif

Bodoni and Futura have very different looking letterforms, but their structure is based on the same basic geometric principles.

One of the easiest ways to quickly create balance and contrast in typography is to choose a serif and sans serif pairing. It’s a simple, easily managed combination that can produce a cohesive look to the text if you select the right typefaces.

It’s not a hard and fast rule, but typefaces from the same designer can sometimes work very well together. As in two paintings from the same artist, sometimes you can see the designer’s hand in two typefaces they’ve made. Eric Gill’s Perpetua and Gill Sans work well together because they share some of the same strokes and curves. Similarly, typefaces that were made to be paired, like Meta Sans and Meta Serif, often work well together.

Combining more than one display or script typeface is usually a bad idea. There are exceptions to every rule, but these typefaces usually have so much personality that one is plenty and two could confuse the mood of the text.

Look for typefaces that were designed on similar principles. For instance, despite looking quite different, Futura and Bodoni can make a great pair because they were both inspired by simple geometric forms.

Baskerville and Futura, “old” juxtaposed with “new.”

Alternatively, finding two divergent typefaces can create new meaning or an interesting juxtaposition, as long as the contrast is strong. Pairing a transitional typeface like Baskerville with a more modern face like Futura could create an interesting statement on the idea of old vs. new.

Explore different styles

Type families such as Mark Simonson’s Proxima Nova contain a variety of weights which can be helpful in creating a design with diverse and flexible typographic possibilities.

Choosing typeface families with a good selection of weights and styles gives you more flexibility without needing to introduce more typefaces. Play a bold off of a light or italic weight for contrast, or try all caps or small caps with a bit of letter-spacing for a subhead. If you choose typefaces that only contain a single weight, you may find it very difficult to create the contrast that a passage requires to adequately distinguish sections visually.

To the library!

Many typefaces have an inherent connection with a cultural period or subculture. Depending on what you’re creating, this could be an advantage or a disadvantage. It’s always best to follow up on potential typeface choices by finding out where and when, and for what purpose they were made. Sometimes a typeface can have the right “look” but evoke the wrong connotations. For instance, Trajan has been appropriated as the typeface of choice for epic, thriller, romantic, comedy, and well, any kind of film, despite being nearly 1900 years old and Roman. Blackletter typefaces have long been a staple of heavy metal bands or anything that needs to feel “scary” or “dark.” Understand these cultural implications so that you can either avoid them or use them intelligently to bring clarity to your viewers.

Money, honey

We’ve been so accustomed to using system fonts that many web professionals balk at the idea of paying for fonts. But even when you use the typefaces that come with your computer, you’re using typefaces that you’ve paid to license—those costs are included in the price of your operating system. There are many free fonts out there, but most of them are free for a reason: They’re often fine at display sizes, but kerning and hinting might not be up to snuff and many aren’t complete or robust enough to be used in a serious way. Solid typefaces, like almost anything else of quality, usually cost money.

Trust your gut

Sometimes a pair of typefaces just looks or feels right together, even though you’re not sure why. These are guidelines, not laws: there are a myriad of types and styles, and sometimes you’ll be surprised what typefaces work together even when logic says they shouldn’t.

Ever forward!

The number of typefaces available to us increases every day. If your favorite font isn’t available yet, chances are it will be soon enough, though the problem of licensing, delivering, and selecting web fonts won’t be figured out overnight.

As more typefaces hit the scene, we need to understand how they can best serve our designs, and to push ourselves to move beyond mere novelty in our selections. If much of the web is made up of text—and it is—web typography can be a very powerful tool indeed.

Further Reading on Web Fonts

More Meaningful Typography
http://www.alistapart.com/articles/more-meaningful-typography/

We have all heard of the golden mean (also known as the golden ratio or golden section): the self-replicating page with a proportion of 1:1.618 that is said to be found in everything from the design of ancient Greek architecture to the growth patterns of plants. This and other meaningful ratios rooted in geometry, music, nature, and history can be expressed as modular scales and put to work on the web.

Fig 1: A simple modular scale: 10@1:1.618

Fig 2: Our example page, designed using a modular scale.

A modular scale is a sequence of numbers that relate to one another in a meaningful way. Using the golden ratio, for example, we can produce values for a modular scale by multiplying by 1.618 to arrive at the next highest number, or dividing by 1.618 to arrive at the next number down.

By using culturally relevant, historically pleasing ratios to create modular scales and basing the measurements in our compositions on values from those scales, we can achieve a visual harmony not found in layouts that use arbitrary, conventional, or easily divisible numbers.

Let’s start by looking at what modular scales are, and how they apply to web design. Next, we’ll dive into this example and go over my reasons for starting with certain numbers, choosing particular proportions, and and applying my scale’s numbers to specific CSS measurements. Finally, we’ll think about how designing with modular scales fits into current workflows, and where we might go from here.

Modular scales and how they apply to web design

A modular scale, like a musical scale, is a prearranged set of harmonious proportions.
—Robert Bringhurst

Making a modular scale is easy. You start with a ratio (for example, 1:1.618) and a number (like 10), then multiply and divide to get many resonant numbers:

- 10.000 * 1.618 = 16.180
- 16.180 * 1.618 = 26.179
- 26.179 * 1.618 = 42.358
- 42.358 * etc.

- 10.000 / 1.618 = 6.180
- 6.180 / 1.618 = 3.819
- 3.819 / 1.618 = 2.360
- 2.360 / etc.

I made a calculator to help us do this math. It has options for creating double-stranded modular scales like the one below, which require at least two starting ratios or two starting numbers to generate what amounts to two separate modular scales mashed together in sequence. Double-stranded scales tend to provide more measurement options (they include more numbers, and usually fill one another’s gaps).

Fig 3: A double-stranded modular scale: 10@1:1.618, 20@1:1.618

Using a modular scale on the web means choosing numbers from the scale for type sizes, line height, line length, margins, column widths, and more. So it makes sense that modular scales are most effective when the inputs—the starting ratios and starting numbers that beget the entire scale—are meaningful to a project’s design, content, or both.

One way to ensure this effectiveness is to start with type. By choosing a text face at the beginning of a project—before making decisions about layout or typesetting—we can use the size at which body text looks most crisp as the basis for a project’s modular scale. If 16px Adobe Caslon is readable and renders well, we’ll multiply and divide from 16 to create our scale. Thus, an entire system of harmonious measurement can be grounded in a visual decision—body text size—that designers routinely make with confidence, and that resonates throughout the experience.

But of course, this starting number is only one element in a multi-stranded modular scale. In the next section, as we look at our example in detail, I’ll explain not only how I chose a starting type size, but also how I decided on a ratio and a second “important” number for this project’s modular scale.

Creating a modular scale for web design

Our example began as an exploration in pairing Minion with Myriad Condensed, so my typeface choices were established. I had a text ready (a few thoughts on typesetting I’d been meaning to share), and I made a quick sketch to plan the composition. In a nutshell, I had the ingredients for web typesetting. Now, for the recipe.

Minion was to be my text face, so I looked carefully at its Web Font Specimen to find a size that would work for my design goals and look crisp. Sizing type on the web is tricky because of the limited resolution involved. One pixel of font-size up or down can completely change how a typeface—and thus a whole text—looks. But once I found the size I liked, 18px, I had a number upon which to base my modular scale. Next, I needed a ratio.

I chose the golden mean (1:1.618). It is a beautiful proportion with historical and cultural connections that make sense for the typefaces I’ve chosen and the text I’m setting. Although it is a contemporary design, Minion draws upon Renaissance ideals, in everything from its humanist structure to the ways in which parts of letters reveal a history in pen and ink.

Page and textblock proportions in Renaissance works were based on the golden mean, too, and because the subject of my text is about the craft of typesetting and looking to tradition for guidance, it made sense to use a proportion meaningful to our typographic roots.

Next, I took my text size (18) and ratio (1:1.618) and plugged them into the calculator at modularscale.com. I also decided to include a second, “important” number, because I wanted the flexibility of a double-stranded modular scale.

I’ve found that a variety of things can serve as an important number. The size at which caption text looks best, for instance, or a large number like the width of a piece of media—if the project at hand mandates ads or embedded videos, for instance—ensures that something about those elements resonates with the layout as a whole.

To find my important number, I marked up the h2 (“Typesetting”) and applied some basic styles according to my sketch. I knew I wanted this headline to be large and have enough presence to anchor the composition, but I didn’t want it to be overpowering. So I played with the text a bit, and the resulting font-size, 190px, became my important number. Here’s the finished scale.

Now let’s look at the CSS I wrote to apply this scale’s numbers to actual measurements in my composition.

Applying a modular scale in web design

Having marked up my text, and with my scale at my side, I applied CSS rules to our example, grabbing an exact number from my scale for each decision. Throughout the process, I made educated guesses that built a harmonious composition, one measurement at a time.

Let’s walk through the CSS. The declarations below have been streamlined so we can study modular scale math more easily; these rules all appear in the full CSS, but are organized differently (for reasons I explain at the end of this section).

/*
-----------------------------------------------
Typesetting for ALA
Author: Tim Brown
Date: 21 Apr 2011

http://modularscale.com/scale/?px1=18&px2=190&ra1=1.618
18px @ 1:1.618
190px @ 1:1.618

http://alistapart.com/articles/more-meaningful-typography/
----------------------------------------------- */

The first thing you’ll notice is a comment up top, where I’ve left a note about my scale. This serves two purposes: first, it lets people know I’m using a modular scale; and second, it provides a means of recreating the scale, so that my decisions can be studied and my measurements can be accurately changed and built upon. Just visit the URL to see the exact modular scale I used while working.

body {
font-family: "Minion-Pro-1", "Minion-Pro-2";
font-size: 18px; /* Scale origin */
}

Here I applied a base font-size (the text size from which my scale originated) to the body element.

.main {
float: right;
width: 497.406px;
}

p {
margin: 1em 0;
line-height: 1.54;
}

Next I chose a number from my scale for the width of the main column of text. I often think of this as my paragraphs’ measure (another term for line length), rather than width. Years ago, when designers sent written instructions to typesetters, their shorthand went something like this: size/leading × measure. Today, CSS font property shorthand reflects only two-thirds of that traditional notation; yet, measure is still critical to achieving a balanced text block.

So, having previously determined my font size, I tried many different numbers for measure and line-height before settling on 497.406 pixels and 1.54, respectively.

For me, balancing a text block always involves lots of trial and error. I alternate between CSS editor and browser, checking to see how each value looks. I keep an eye on the overall density of my paragraphs (typographic color) and the readability of the text as a whole. I am especially wary of line spacing that feels too tight or too loose. Tight line spacing is extremely distracting to readers, pulling their attention to pieces of text above and below the line they’re trying to read. Loose line spacing is wasteful, ugly, and dilutes negative space such that margins and pauses elsewhere in a composition are less effective.

body {
font-family: "Minion-Pro-1", "Minion-Pro-2";
font-size: 18px; /* Scale origin */
color: #031634;
}

Continuing to think about a balanced text block, I tried a few different colors for my text. Silly as it may sound, color can have an effect on how smooth the text looks: pixels are made of color, so color can change type rendering. I decided on a dark blue to keep the contrast high—useful for getting the most fidelity out of Minion’s details, especially because the background color isn’t bright white.

h1, h2, h3, p.intro {
text-rendering: optimizeLegibility;
}

Next, I worked on the headings. The first thing usually I do with headings is apply text-rendering: optimizeLegibility. In Firefox 3, Safari 5+, and Chrome 4+, this property-value pair enables a font’s native kerning instructions, which means that letters will be spaced exactly as the type designer intended. Use this with care: optimizeLegibility may have performance drawbacks, but I’ve found them to be negligible. Your mileage may vary.

h2 {
margin-left: 20px; /* Optical alignment of T stem to left edge of »
.side */
font-family: "Myriad-Pro-Condensed-1", "Myriad-Pro-Condensed-2";
font-size: 190px; /* Scale origin */
line-height: 1;
font-weight: 600;
text-transform: uppercase;
letter-spacing: -2px;
color: #033649;
}

As you’ll recall, the font-size of my h2 (190px) was one of the starting values on which my modular scale is based. Setting the text in all caps strengthens and helps anchor the composition, and because it’s so large I tightened up the letter-spacing (note: this is different than kerning, because all letters are tightened or loosened at the same time, in the same way). The left margin was added later, to align the stem of the “T” with the left edge of my sidebar; this value does not come from my scale, but rather emerged from the lay of the letterforms as I worked. It’s okay to improvise, as we’ll discuss below.

’Typesetting’ uses the semibold weight of Myriad Pro Condensed (font-weight: 600). I tried other weights, but this one felt best. I chose a dark blue for the color, then decided to use different colors for individual letters with Lettering.js.

h1 {
margin: 44.856px 0 0 307.420px;
font-size: 29.124px;
line-height: 1;
font-weight: 300;
font-style: italic;
}

The h1, “Markup & Style,” is sized and spaced using numbers from my scale. Again, I tried a few different numbers before landing on the right one. While my first instinct was to center-align this heading, I found the off-center placement more engaging.

.group {
width: 845.479px;
margin: 0 auto 18px;
}

.side {
float: right;
width: 274px; /* horizontal photos in this col are 190px high »
uncropped */
margin: 27.723px 29.124px 0 0;
}

Before tackling sidebar specifics, I worked out my container, floats, and clearfix.

I sought a number from the scale for the width of my container, .group, making sure it was wide enough for my h2 to fit, and then I chose a width for my sidebar. After trying a few different numbers from the scale, I wasn’t happy with the way things looked. 199.603px was too narrow, and 307.420px was too wide.

So I went about it a different way: I resized the image of my notebook and pen, trying various numbers from the scale for its height. At 190px tall (a number from which my scale originated) and 274px wide, this key visual in my sidebar seemed to resonate in the composition—and that size gave me a column width (274px) that looked great.

.side p {
font-family: "Minion-Pro-Caption-1", "Minion-Pro-Caption-2";
font-size: 15px; /* Improvisation! It's okay! */
line-height: 1.54;
}

I wanted the type in my sidebar to be smaller than that of the main text, for two reasons: I wanted it to recede visually because it’s less important than the main text, and I wanted to make sure I could set lines of a comfortable length. Having predefined a fairly narrow measure by basing my column width on the dimensions of my image, I had to make the font-size a bit smaller to get more characters per line. The big question was, how much smaller?

After trying a few numbers from my scale for sidebar font-size and not liking the results, I remembered that Minion Pro has an optical version made for smaller sizes, called Caption. Minion Pro Caption is slightly beefier than normal Minion Pro, so it was exactly what I needed. I kept trying different font-size values to find one I liked, and ended up improvising. The number 15 isn’t in my modular scale, but 15px Minion Pro Caption sure looks good next to 18px Minion Pro.

That’s right, I improvised.

Modular scales are a tool, they’re not magic. They’re not going to work for every measurement, and that’s okay. Math is no substitute for an experienced designer’s eye, but it can provide both hints and constraints for decision making. Consider the scale’s numbers educated suggestions. Round them if you like (22.162 becomes 22). Combine them (3.56 + 16 = 19.56). Or as we saw me do here, break from the scale entirely.

/* Intro
----------------------------------------------- */
/*p.intro {
margin: 0.809em 0;
font-size: 22.250px;
line-height: 1.309;
}*/

p.intro {
margin: 0.952em 1.54em 0.952em 0;
font-size: 21.178px; /* 27.723 - 6.545 */
line-height: 1.394; /* 1.54 - 0.146 */
}

The decisions I made in setting the two p.intro paragraphs are further evidence of improvisation, and also touch on what I’m calling “comment math,” something I feel is important for sharing our work with clarity and efficiency.

Here I had a whole set of measurements I liked (these are now commented out). But at some point, I realized I had no idea where they came from. They’re not numbers from my scale. I suspect that one late night when I sat down to work on this (before the modular scale calculator made bookmarkable URLs), I plugged the wrong numbers into the calculator and kept on working. But it looked good! In the spirit of improvisation, I could have kept the numbers as they were. But I wanted to explain another technique I use.

To get numbers close to the ones I liked while still using the correct scale, I combined scale numbers. The font-size of these intro paragraphs, 21.178, is not from my scale; but, it’s the result of combining two numbers that are. Whenever I add or subtract to arrive at values that did not originate from my scale, I do some comment math. That helps me remember, and it helps other people see what I did.

One final thing of note: because I’ve based my layout on a modular scale derived partly from a specific size of a specific typeface, my measurements are not meaningful unless that typeface is used. So when my ideal fonts are not present, which can happen for any number of reasons (a slow connection, an old browser/OS, a user preference that disables web fonts, etc.), generic fonts—and generic measurements take over. In fact, for the sake of progressive enhancement, I specify baseline fonts and generic measurements first—followed by preferred fonts and ideal, scale-based measurements. View our example’s stylesheet in full for the details. You can read more about this technique in this series of articles by Sean McBride. (Also note: I arrived at these particular baseline fonts with help from Josh Brewer’s Ffffallback.)

Where does this fit with how we already work?

In some ways it’s different from how we already work, but it feels more natural. Going from content out, rather than canvas in, to paraphrase Mark Boulton, is a more web native way of designing. Folks like Mr. Boulton, Andy Clarke, and Luke Wroblewski have for years prophesied an inversion in how we approach designing for the web, and now is the time to make it happen.

Using modular scales to build an experience outward from type can be a bit disorienting if you normally design websites (as I used to) by drawing boxes and filling them with content. The arbitrary dimensional choices I used to make had nothing to do with my intended designs’ underlying meaning. At best, I chose ballpark measurements in CSS, command-tabbed over to my browser, and eyeballed the results. If what I ended up with looked decent and the page was still functional, it was good enough for me.

Recognizing type as the atomic element in web design affords us the opportunity to make better design decisions that resonate upward and outward into the experience. But it also challenges us to eschew conventions like the use of prefabricated frameworks and reusable templates, and to accept a new balance in our schedules—that we put forth greater investment and effort for the sake of more meaningful typography.

Viewport sizes are good to know, but setting a composition’s width to one of these exact values and pouring in text is not ideal. Easily divisible numbers are only good for being easily divisible—fine for sketching—but as professionals we should aim higher. Let’s instead choose numbers because they fit, because they look good, and because they serve the meaning of the design.

Reset stylesheets like the one found in HTML5 Boilerplate matter a lot when designing with modular scales. We need to make sure the mathematic decisions we’re making are reflected accurately in the browser, and as consistently as possible across different browsers.

In fact, many popular practices dovetail nicely with modular-scale-based measurement. Designing with modular scales does not preclude grid-based or responsive design. Smaller numbers from a scale can be used as a grid’s column width; or, a large number from a scale can be divided into columns (rounding the numbers first helps). When building toward a responsive design reference point—a carefully measured layout for one particular setting—we can use numbers from a modular scale and then convert to percentages as we normally would.

Conclusion

Designing with modular scales is one way to make more conscious, meaningful choices about measurement on the web. Modular scales work with—not against—responsive design and grids, provide a sensible alternative to basing our compositions on viewport limitations du jour, and help us achieve a visual harmony not found in compositions that use arbitrary, conventional, or easily divisible numbers.

As we’ve seen in this article, though, modular scales are tools—not dogma. The important thing for our readers, our craft, and our culture is that we take responsibility for our design decisions. Because in so doing, we’ll make better ones.

Further Reading

- The Elements of Typographic Style: I cannot recommend highly enough Robert Bringhurst’s The Elements of Typographic Style—particularly the section called “Shaping the Page.” This is where I learned about the power of modular scales, how to build them, how they differ from grids, and how their flexibility can help us to strike a natural balance between typographic exactitude and educated improvisation.

- More Perfect Typography: Starting with type and using modular scales were the subjects of a half-hour talk I gave at Build in November of 2010. You can watch the whole talk online, if you like. It’s a good supplement to this article—more inspiration than information. I talk about Aldus Manutius, explain my method of evaluating type for body text, and share another layout like the example in this article.

Orbital Content
http://www.alistapart.com/articles/orbital-content/

We are on the cusp of a complete overhaul of the way in which we interact with online content, and I think you should be a hell of a lot more excited than you currently are. Bookmarklet apps like Instapaper, Svpply, and Readability are pointing us toward a future in which content is no longer entrenched in websites, but floats in orbit around users. This transformation of our relationship with content will force us to rethink existing reputation, distribution, and monetization models—and all for the better.

Content today

Most online content today is stuck. It has roots firmly planted in one of the many sites and applications around the web. Because content is rooted, we are forced to spend precious time recording its location in the hopes of navigating back. We bookmark websites. We favorite tweets. We create lists in text files.

In this system, the sites are the gravitational center and we, the users, orbit them, reaching out for a connection whenever we want to interact with the content. This is a fine system, but as users spend more time on consumption-oriented devices like iPads and mobile phones, new demands are being put on content.

Websites have responded quickly to these new demands. Media queries and the responsive design movement have enabled designers to tailor the experience of a site to whichever device a user happens to be using. Flexibility at this macro level of the site is important, but the real breakthroughs will come when we enable the same flexibility at the micro level with individual pieces of content.

Publishers have had the ability to make their content flexible for over a decade. RSS makes it easy to share content feeds with subscribers, saving them the trouble of constantly checking back in. Recently, a series of bookmarklet apps have been slowly transferring the responsibility of making content flexible from the publisher to the user. Leading the charge of this transfer is Instapaper, which has garnered a great deal of praise for doing something called “content shifting.”

Content shifting

…I am certain people want to shift content from discovery oriented devices (laptop, satellite radio, etc.) to consumption oriented devices (tablet, sonos, etc.), and I am certain that we will see this get easier and easier in the coming years.

—Fred Wilson

Content shifting allows a user to take a piece of content that they’ve identified in one context and make it available in another. Perhaps the most popular content shifter is Instapaper, which allows users to easily shift interesting articles they find on the web. With one click of the “Read Later” bookmarklet, the desired article is shifted from a user’s web browser to their mobile device.

Calling Instapaper a content shifter tells only half the story. It puts too much attention on the shifting and not enough on what needs to happen before a piece of content can be shifted. Before content can be shifted, it must be correctly identified, uprooted from its source, and tied to a user. This process, which I call “content liberation” is the common ground between Instapaper, Svpply, Readability, Zootool, and other bookmarklet apps. Content shifting, as powerful as it is, is just the beginning of what’s possible when content is liberated.

Content liberation

Content liberation is a two-part process that results in a piece of content uprooted from its original context and tied to a user. It works like this:

1. Distillation: First, the content is stripped down to its raw essence. That essence could be an article, a tweet, a recipe, even a full webpage. What matters is that you end up with all wheat and no chaff. Distilled content is not, however, without attribution. The content never forgets where it is from and neither do you.

2. Association: After distillation, the raw content is free-floating and in need of a new home. This is done by tying that content to a user. The typical approach is to have a user account or a desktop folder where the content can reside.

The result of this process is a carbon copy of the purest form of the original content. This liberated copy is tied to a user and its fate is in their hands. If the original site takes the content down or changes it, the liberated copy is unaffected. As users build up collections of this liberated content, they are laying the foundation upon which apps can build their communities and implement their features.

Content collections

Content collections are becoming an increasingly essential data type. They open the door for developers to build apps that are custom-tailored to users’ specific needs. Svpply, for example, enables users to build collections of products they love. Now when I go window-shopping, the windows are all curated by my friends and the taste-makers that I respect.

There are many types of data on the web, but only a few of them have apps designed to help us collect them. I expect this to quickly change. New apps will surface to unlock the potential of recipes, guitar tabs, fonts, travel tips, and more, by enabling users to organize them into collections. Building these content collections is going to be a big deal in the very near future. Consider yourself warned.

Content control

There are two looming issues for liberated content collections—who should control the collections, and who really owns the content inside them? I’m going to tackle the issue of control now, but fear not, I will address ownership soon.

In our discussion of control, let’s examine Instapaper. Do you control that collection of articles? Not really. If another application comes along and offers to print your collection and bind those articles into a book, you have to ask Instapaper for permission to do so. Instapaper helped you build your collection so it becomes a middleman between you and anyone else who can make the collection useful. If Instapaper’s API is lacking in some way (or absent as it was until recently) there’s nothing you can do about it—which is disappointing when you consider all of the effort you put in to building the collection.

Even with a great API in place, this is a fundamentally indirect and inefficient way to deal with content. It’s like you’re surrounding yourself with an entourage of apps and anyone wanting to approach you has to go through them first. Instead of surrounding yourself with applications, why not surround yourself with content?

Orbital content

Our transformed relationship with content is one in which individual users are the gravitational center and content floats in orbit around them. This “orbital content,” built up by the user, has the following two characteristics:

1. Liberated: The content was either created by you or has been distilled and associated with you so it is both pure and personal.

2. Open: You collected it so you control it. There are no middlemen apps in the way. When an application wants to offer you some cool service, it now requests access to the API of you instead of the various APIs of your entourage. This is what makes it so useful. It can be shared with countless apps and flow seamlessly between contexts.

The result is a user-controlled collection of content that is free (as in speech), distilled, open, personal, and—most importantly—useful. You do the work to assemble a collection of content from disparate sources, and apps do the work to make those collections useful. These orbital collections will push users to be more self-reliant and applications to be more innovative.

The API of you

In the traditional business model, consumers vote with their dollars. If they like something, they buy it. If not, they don’t. In the orbital content model, users vote with their content. If an app offers something interesting, they’ll share their content with it. If not, they won’t. Because the content is in orbit around the users, they directly determine who has access to it. Applications will no longer ask for our credentials to other services; instead, they will ask you directly to lend them the content they want to make useful.

This puts an exciting burden on applications to continue to innovate and meet your changing user needs. If an app starts slacking, you can share your content with another app that offers to do something more. For example, I have a tremendous amount of music data built up on Last.fm, but instead of motivating them to innovate, controlling my data allows them to comfortably stagnate. If I could share my Last.fm data with Pandora, or Rdio, or Grooveshark, Last.fm would need to innovate to keep my attention; if they didn’t, those other apps could rise to the occasion by creating new and exciting functionality. Either way, users win.

Content ownership

At this point, I imagine there are quite a few disgruntled readers out there who aren’t happy with the fact that I’ve yet to address the copyright issues associated with orbital content. When content created by others is liberated, some tricky ownership issues come into play.

Many publishers will ask—and it is a fair and familiar question—why should users have the right to carbon copy my content and share it in other contexts? It is a question that belies a concern about something slightly different: compensation. If publishers were compensated $10 every time content was shared and $1 every time it was read on their site, they would do everything in their power to get their content shared. Copying is not the problem—compensation is. Today’s web environment makes it nothing less than a struggle to support content creators. We have unlimited tools for sharing and virtually none for payment.

Let’s look at the movement toward orbital content as an opportunity to rethink compensation. There is a great deal we can do to shape it into something that enriches the web for content creators and content consumers. A major key to this joint enrichment is attribution.

Content attribution and monetization

Attribution is authorship metadata that is bound to content. No matter how far and wide a piece of content spreads, it never forgets who created it and where it’s from. Despite its importance, web attribution is already in shambles. A quick review of Tumblr blogs or the image stream at FFFFound! will show just how difficult it is to find the original sources for most content. This lack of attribution means that content creators receive neither financial nor reputational gains when others spread their work. As good citizens of the web, we have to be vigilant in retaining authorship as we liberate and share content.

If we can keep attribution firmly in place, content collections and orbital content offer publishers new opportunities for both financial and reputational gain. Traditionally, site owners monetize their content by generating traffic to get as many “eyeballs” in front of their advertisements as possible. Strict content attribution allows us to take an interesting twist on this model. We can push the notion of eyeballs to include anyone who sees your content in any context so long as it is clear that you are its creator. If attribution can travel with content, why not monetization? RSS feeds have set some precedent for ads following content into other contexts. We can push this model further by enabling ads to travel alongside individual pieces of content and enabling content creators to be compensated whether that content is viewed on their site or somewhere else on the web.

Attributed orbital content can be a conduit for communication between the content creator and various content consumers. At my company, Fictive Kin, we are obsessed with “Haters Gonna Hate,” an animated gif created by These Are Things. That gif quickly became a bona fide internet meme and was seen by millions of people, many of whom saved and reblogged it. Later, These are Things released haters gonna hate t-shirts and letterpress prints to capitalize on the success of their creation. With orbital content and strict attribution, it would be easy to give them the ability to advertise the prints and shirts to anyone who had collected their original gif and let them know there were new ways to show off their love.

Content applications

The things that we like define us as much as the people we know. Content liberation, orbital content, and attribution are enabling a new class of applications that are built on top of our content and our interests instead of our social graphs. We can look to Instapaper, Svpply, and other bookmarklet apps for the beginnings of this movement.

These initial apps hint at some possible paths, but we should remember orbital content is still a wide open frontier and we are free to shape it as we please. If we get a good jump on it, we can create a web in which content creators are rewarded fairly, content consumers are given unprecedented power, and web applications are pushed to constantly innovate and improve themselves. Not too shabby.

The Discipline of Content Strategy
http://www.alistapart.com/articles/thedisciplineofcontentstrategy/

We, the people who make websites, have been talking for fifteen years about user experience, information architecture, content management systems, coding, metadata, visual design, user research, and all the other disciplines that facilitate our users’ abilities to find and consume content.

Weirdly, though, we haven’t been talking about the meat of the matter. We haven’t been talking about the content itself.

Yeah, yeah. We know how to write for online readers. We know bullet lists pwn.

But who among us is asking the scary, important questions about content, such as “What’s the point?” or “Who cares?” Who’s talking about the time-intensive, complicated, messy content development process? Who’s overseeing the care and feeding of content once it’s out there, clogging up the tubes and dragging down our search engines?

As a community, we’re rather quiet on the matter of content. In fact, we appear to have collectively, silently come to the conclusion that content is really somebody else’s problem—“the client can do it,” “the users will generate it”—so we, the people who make websites, shouldn’t have to worry about it in the first place.

Do you think it’s a coincidence, then, that web content is, for the most part, crap?

Dealing with content is messy. It’s complicated, it’s painful, and it’s expensive.

And yet, the web is content. Content is the web. It deserves our time and attention.

And that’s where content strategy comes in.

What is Content Strategy?

Content strategy plans for the creation, publication, and governance of useful, usable content.

Necessarily, the content strategist must work to define not only which content will be published, but why we’re publishing it in the first place.

Otherwise, content strategy isn’t strategy at all: it’s just a glorified production line for content nobody really needs or wants. (See: your company’s CMS.)

Content strategy is also—surprise—a key deliverable for which the content strategist is responsible. Its development is necessarily preceded by a detailed audit and analysis of existing content—a critically important process that’s often glossed over or even skipped by project teams.

At its best, a content strategy defines:

- key themes and messages,

- recommended topics,

- content purpose (i.e., how content will bridge the space between audience needs and business requirements),

- content gap analysis,

- metadata frameworks and related content attributes,

- search engine optimization (SEO), and

- implications of strategic recommendations on content creation, publication, and governance.

But wait…there’s more

In her groundbreaking article, Content Strategy: the Philosophy of Data, Rachel Lovinger said:

The main goal of content strategy is to use words and data to create unambiguous content that supports meaningful, interactive experiences. We have to be experts in all aspects of communication in order to do this effectively.

That’s a tall order. I’d like to propose that, in fact, there are far too many “aspects of communication” for a solitary content strategist to truly claim deep expertise in all of them.

Instead, let’s assume that there are a number of content-related disciplines that deserve their own definition, by turn:

- Editorial strategy defines the guidelines by which all online content is governed: values, voice, tone, legal and regulatory concerns, user-generated content, and so on. This practice also defines an organization’s online editorial calendar, including content life cycles.

- Web writing is the practice of writing useful, usable content specifically intended for online publication. This is a whole lot more than smart copywriting. An effective web writer must understand the basics of user experience design, be able to translate information architecture documentation, write effective metadata, and manage an ever-changing content inventory.

- Metadata strategy identifies the type and structure of metadata, also known as “data about data” (or content). Smart, well-structured metadata helps publishers to identify, organize, use, and reuse content in ways that are meaningful to key audiences.

- Search engine optimization is the process of editing and organizing the content on a page or across a website (including metadata) to increase its potential relevance to specific search engine keywords.

- Content management strategy defines the technologies needed to capture, store, deliver, and preserve an organization’s content. Publishing infrastructures, content life cycles and workflows are key considerations of this strategy.

- Content channel distribution strategy defines how and where content will be made available to users. (Side note: please consider e-mail marketing in the context of this practice; it’s a way to distribute content and drive people to find information on your website, not a standalone marketing tactic.)

Now, this breakdown certainly doesn’t imply that a content strategist can’t or shouldn’t be capable of playing these roles and creating the associated deliverables. In fact, in my experience, the content strategist is a rare breed who’s often willing and able to embrace these roles as necessary to deliver useful, usable content.

BUT. And this is a big “but.” If our community fails to recognize, divide, and conquer the multiple roles associated with planning for, creating, publishing, and governing content, we’ll keep underestimating the time, budget, and expertise it takes to do content right. We won’t clearly define and defend the process to our companies and clients. We’ll keep getting stuck with 11th-hour directives, fix-it-later copy drafts—and we’ll keep on publishing crap.

We can do better. Our clients and employers deserve it. Our audiences deserve it. We as users deserve it.

Take up the torch

David Campbell, the founder of Saks Fifth Avenue, said, “Discipline is remembering what you want.”

When it comes to creating and governing content, it’s easy to forget what we want, or even worse, to settle for less.

But until we commit to treating content as a critical asset worthy of strategic planning and meaningful investment, we’ll continue to churn out worthless content in reaction to unmeasured requests. We’ll keep trying to fit words, audio, graphics, and video into page templates that weren’t truly designed with our business’s real-world content requirements in mind. Our customers still won’t find what they’re looking for. And we’ll keep failing to publish useful, usable content that people actually care about.

Stop pretending content is somebody else’s problem. Take up the torch for content strategy. Learn it. Practice it. Promote it. It’s time to make content matter.

Reading Design
http://www.alistapart.com/articles/readingdesign/

My stomach dropped the first time I opened a copy of Warren Chappell’s A Short History of the Printed Word.

The book was a facsimile reprint of the first 1970 edition, on cheap paper and not holding together very well, but each page was utterly alive with its elements: the body type—handset in Monotype Janson—was unapologetically large and forceful, the typesetting done by the time–honed and wondrously imprecise method of pressing ink into paper with raised metal, giving it an organic, breathing presence on the page.

Designed by the author, the book seemed almost visually perfect: the margins, the text block on the page, the placement of the illustrations, all were chosen with a most careful eye; one that craved both the lively and the serene, but with ultimate, consummate respect for the words on the page.

It’s interesting to consider that the book first appeared in 1970—not an entirely high point in the history of graphic design—when practitioners of the highest of so–called “high” design were still seemingly locked in an arms race of Swiss Modernist grids and attempting always to out–ugly each other.

Chappell was one of those designers, and he did some really bizarre and regrettable stuff, but when it came time to produce his small masterpiece on the history of the printed page, what shone out was the virtuosity that comes from a lifetime’s study by example of what works and what doesn’t.

It may be that, for Chappell, it was easier to perform like a virtuoso when designing his own words, at his own pace. Designers who work in the day-to-day grind of deadline and presentation rarely find opportunity to bring such a concentration of skills to one project. I’m going to suggest, however, that designers will benefit from following Chappell’s example, and approach their work now and again as being written rather than assembled.

* * *

Every designer can remember the uncertainty of early days: the scramble to learn new tools, to acquire the best machinery and gear, to have as many fonts and plug–ins as possible on board; to try it all and to be ready for anything.

Most every designer can also point to creative decisions sprung from what the gadgets can do: depending on when the career began, that might mean half–megabyte splash pages and Rollover–everything, or endless graduated fills and drop–shadows, or mezzotints and squeezed and stretched type. Or, to go further back, the gilt edges and cherubim–and–seraphim excesses of Victorian printing.

As with the haircuts and clothing of teenagers, there’s that tendency in the early days toward jealous defensiveness, as though projects, when under scrutiny, were an extension of the designer’s body: you criticize my work, you criticize me and all that I am.

There’s also an eagerness to define oneself in opposition to something else, to destroy what came previously, though such gestures rarely carry much lasting weight; for example it’s a real forehead–slapper to think that David Carson was once considered innovative.

Connected to this, surely, are the haughty declarations of the absolute divide between the lame and the cool.

I bite my lip when I hear a young designer say something like “Helvetica sucks;” while it’s true that Helvetica indeed does suck in many and varied contexts, those situations inevitably involve the work of one who’d make such an airless declaration.

All of these tendencies are familiar to designers—and to those who work with us—but that we even notice such behaviour is, I propose, a little wonky. Imagine a journeyman plumber or apprentice hang–gliding instructor indulged for such tantrums: if pipes burst, or a glider crashes to earth, there’s no account exec to take the client to lunch and chalk it up to creative freedom.

* * *

I spent a few semesters teaching typography at an institute of art and design. My classes began on the first day with a short quiz asking students—at that stage three years into a communications design degree—to draw some basic symbols such as an ampersand and an apostrophe, and to mark suggestions for typographic improvements to some fairly shabby copy I’d written.

Term after term I’d go over the tests and scratch my head wondering what they’d been up to the past three years. With due respect to my colleagues in the program—many of whom taught in addition to running corporate design shops or ad agencies—the education had plainly focused away from what I consider the primary goal of communication design: to make vital, engaging work intended above all to be read. To use design to communicate.

To the students, text had been handled as a graphic element, to be shifted within grids, manipulated and filtered like a photo, to be squinted at and scrutinized upon critique but never apparently to be read.

“But editors take care of text, we just have to design it” was the response when I’d insist that designers learn about editorial style and usage, which always made me laugh.

I complain about the cult of designer ego because it takes away from the craft mentality that leads to better work. The cult of editorial ego is another matter altogether: surrounded as we are by stilted prose, overstatement and eye–glazing textual banality, text has no more implicit safety in the hands of editors.

That said, there are talents and hacks on both sides of the barbed wire and landmines that lie between editors and designers, none of whom benefit from ignorance of what the other side is doing. If you design with editors, study what they know, and have the same reference books at hand.

And above all, read what you are designing, and imagine reading it for the first time, like someone who just found it.

* * *

There are those who make a living as art directors or creative directors, in agencies and large organizations; I simply don’t have any respect for them. Back in the day when specialists covered production steps like colour separation, typesetting and paste–up, design by necessity was a cooperative enterprise, with a commercial artist (and a budget) steering the ship.

A graphic designer must now of course practice all those specialties and more, which means that making pages that sing and elucidate, that beguile and entice, is no simpler now than before, no matter how powerful the processors and software.

Even though image editing, information architecture, typography, and varied media are part of the designer’s toolkit, and it’s easy to see how many designers are led down a garden path of putative “specialization” (for example turning out gardening–supply store websites clogged with Flash), one thing remains constant: that designers need to be able to render ideas clearly.

It’s very nearly impossible to do that in an art–directed environment, of course, which is why most commercial design looks like wispy crap. Committees and org–chart hierarchies never add in the way of improvement, flinging subjective taste and private agendas in the way of clarity at every turn. People sometimes ask me how to improve the design work that comes out of large organizations, and I inevitably answer, “You can’t.”

* * *

How can you design for the web if you can’t code? How can you direct photography if you’ve never worked in a darkroom? How can you design text if you’re not a careful reader?

Surely there must be a list somewhere, of basic skills a designer who knows how to read must possess before donning the goatee and the ironically nerdy glasses? I looked and couldn’t find one, so I made my own:

- That text will inevitably be read before it is looked at

- That words themselves make remarkably effective clip art

- That the self–conscious layering of messages usually subtracts more value than it adds

- That the practical value of white space towers over its value as a design element

- That the deep symbolism of a design decision, referring perhaps to a treasured memory of the designer, is irrelevant to the person attempting to glean something from the work

- That print designers who gauge their work on the screen, and web designers who gauge their work exclusively on their own machines, are arrogant in their disregard

- That the physiobiology of reading is one that demands easy points of exit and entry

- That simply paying attention to the design of type, or distinguishing it as “fine” or “invisible” or “classical” is like making a big deal about putting salt on a boiled egg

- That letters are not pictures of things, but things

- That words are not things, but pictures of things

- That arbitrarily altering (or allowing software to alter) the shapes of letters, and the spacing between letters and words, is done at one’s own risk

- That emphasis comes at a cost

- That overstating the obvious can be effective, but not all the time

- The precise point at which a quantity of information no longer requires assistance to be differentiated from another

- The knowledge to back up design decisions clearly without falling into a fog of hidden meaning, or so–called “creativity”

In Defense of Readers
http://www.alistapart.com/articles/indefenseofreaders/

The best readers are obstinate. They possess a nearly inexhaustible persistence that drives them to read, regardless of the circumstances they find themselves in. I’ve seen a reader absorbed in Don Quixote while seated at a noisy bar; I’ve witnessed the quintessential New York reader walk the streets with a book in hand; of late I’ve seen many a reader devour books on their iPhone (including one who confessed to reading the entire Lord of the Rings trilogy while scrolling with his thumb). And millions of us read newspapers, magazines, and blogs on our screens every day—claims that no one reads anymore notwithstanding.

What each of these readers has in common is an ability to create solitude under circumstances that would seem to prohibit it. Reading is a necessarily solitary experience—like dying, everyone reads alone—but over the centuries readers have learned how to cultivate that solitude, how to grow it in the least hospitable environments. An experienced reader can lose herself in a good text with anything short of a war going on (and, sometimes, even then)—the horticultural equivalent of growing orchids in a desert.

Despite the ubiquity of reading on the web, readers remain a neglected audience. Much of our talk about web design revolves around a sense of movement: users are thought to be finding, searching, skimming, looking. We measure how frequently they click but not how long they stay on the page. We concern ourselves with their travel and participation—how they move from page to page, who they talk to when they get there—but forget the needs of those whose purpose is to be still. Readers flourish when they have space—some distance from the hubbub of the crowds—and as web designers, there is yet much we can do to help them carve out that space.

From looking to reading

It is almost impossible to look and read at the same time: they are different actions.
—Gerard Unger, While You’re Reading

Think of your first encounter with a book. You look at the cover to get a sense of it, then perhaps flip to the back or the flaps to skim the publisher’s copy. Opening the book, you might glance at the title page, or quickly run your eyes over the table of contents. Maybe you peek into the back to check the page count, or casually assess the weight of the book in your hand. If it’s a hardcover, you might take the dust jacket off, lest it get in the way.

Most readers engage in at least one and usually several of these behaviors—they’re a kind of pre-reading ritual, part of the culture of books. And yet they serve an important purpose as well, in that they ease the transition between looking and reading. They help the reader establish interest, and they serve as an invitation to reading, setting the stage for the act that follows. Similar behaviors can be found on the web. When you arrive on an article page (like this one, for example), you might glance at the logo to see where you are, or skim the navigation to get a sense of what else is here. You’ll likely look at the article title, or the photo or illustration that accompanies it. If there’s a pull quote or summary, you may skim through it, just as you would have skimmed the flap copy of a book. You may even read the first paragraph, listening to see if the voice of the text resonates or draws you in. If at any point during these pre-reading activities you conclude the article is not for you, you’ll abandon it and go somewhere else. But, if the interest is there, it’s likely that you’ll begin to read.

All of this can occur over the course of a few seconds, but these seconds are the only preparation a reader gets, the only assistance for shifting from looking to reading, from skimming along to concentrating. It is during these few seconds that a reader decides to fix her attention on the text and commit to reading—no small commitment in a medium that takes its name from the cursory act of browsing.

There are many dogged readers who will make this commitment whether or not the design of the page makes it easy on them, but as designers, there are a number of ways we can assist readers in the transition. Consider all of the elements that accompany an article and organize those that are most useful for gauging interest at the top. Summaries or pull quotes, as well as illustrations, allow the reader to quickly assess what the article is about. Categories and links to related content provide context. The name and affiliation of the author communicate the authority of a text. All of these elements combine to create an entryway into reading.

It is likely that the first paragraph (or first few paragraphs, depending on the length of the text) is read differently than those that follow. We often read more slowly at the beginning of a text, as we become familiar with the voice of the writer and decide whether or not we want to continue. Typographic signals—such as using a drop cap, or setting the first paragraph in larger text or a different typeface—can amplify this behavior and make the transition into reading more comfortable. In a sense, this first paragraph must speak louder than those that follow, in order to bring the reader in.

Now leave me alone

Once a reader has commanded the aura of solitude around them, they become nearly impenetrable. A reader who is thoroughly engrossed in reading may not hear you if you call her name. Call her name again, however, and she will look up, annoyed. The key is not to halt all activity around a reader, but to give her her space. (Remember the girl reading Quixote at the bar? You want to order your drink without bumping into her.)

In practice, this means you need to limit distractions to the full extent possible. Pull quotes—so effective near the top of an article—become a nuisance further down; many readers will find themselves unconsciously drawn to them, even when they want to focus on the text. Attention to the basic typographic details—line length, a readable typeface, the right balance between font size and line height, appropriate contrast between the text and background—can make the difference between a reader who makes it to the end of the article versus one who tires and gives up.

Whitespace is not so much a luxury as it is a prerequisite. Every pixel of whitespace around the text can help the reader stay focused instead of wandering off. A readers’ eyes must repeatedly approach the edge of the text block; a sidebar that is set too close to the text—or one that is brighter or darker in color—will compete with her on every line. Even a small increase in padding between text and sidebar (especially if the sidebar includes more text) can make for a more restful page, and reinforce the reader’s own sense of solitude.

It’s also important to consider the chronology of the reading experience. The initial transition from looking to reading is followed by an intense, concentrated period in which the reader is lost in the text. At the end of a piece, however, the reader once again comes up for air, and is likely to return to the state of looking (and browsing) that got her here in the first place. The design of the page should respect these three distinct phases: first, by inviting the reader in; second, by leaving her alone; and third, by providing avenues for her to continue to pursue her interests.

Many sites scatter related content around the article, instead of focusing it at the top or bottom, where it’s more useful and less likely to be a distraction. If you want your users to skim the page, then by all means, fill the sidebar with content all the way down. But if you want them to read—if the page was written and not merely filled up, if the text consists of carefully crafted prose rather than bullet points—then respect the reading process and move that content elsewhere. The middle of an article should reflect the solitariness of reading with a design that neither interrupts the text nor the reader.

Designers can be readers too

There are, of course, readers who shun the screen—those who print out long articles, or—gasp!—purchase printed books and magazines instead. We often attribute their resistance to those elements over which we have no control: the physical discomfort of sitting at a desk (versus curling up with a book); the as-yet-impossible task of producing a screen that is more comfortable than paper; the attention-deficit nature of so much browsing online that makes the transition to reading seem unattainable. But there are in fact other issues at play here, and we are capable of exerting a great deal of control over them: whether or not the design of the page embraces the reading experience, or merely grudgingly squeezes it in among the looking and searching and skimming.

As a designer, the only way to ensure that the page makes for good reading is to read it yourself; to relinquish the design sensibility that is inclined to look at text and take the time to actually read it. It’s not an easy task, but then, neither is reading on the web, and making the effort may help you empathize with the reader’s plight. The web is still a noisy, crowded place—but it’s also limitless, and surely we can find space enough for reading—a space where the text speaks to the reader and the reader does not strain to hear.

Habit Fields
http://www.alistapart.com/articles/habit-fields/

Consider the desk in your office. Maybe it reminds you of when you opened the box and put the pieces together. Or maybe it recalls your first day at work, when your colleague showed you where you would sit. The desk, the computer on top of it, the chair you sit in, and the space they comprise are all repositories for memory. But these things don’t just store our memories; they store our behaviors too. The sum of these stored behaviors is an object’s habit field, and merely being around it compels our bodies and minds to act in certain ways. By understanding these invisible forces and employing strategies to shape them, we can enjoy more frequent, sustained periods of flow.

How memory works: a brief overview

We often talk about our memories as if they were kept in the brain as concrete, indexed things. Yet, if the brain were a town, each memory wouldn’t be a house with its own address; instead, a memory would be more like the moment in which a certain combination of houses all had their porch lights on. Memories are associations, and the same houses—neurons—store and process those associations[1].

Because of this unique architecture, our memories are interconnected. When we talk about “storing” memories in objects, we’re creating new sets of associations that, once established, will seem more familiar to us later on. As you turn your attention toward your memory of the desk, you’re surfacing a web of familiar associations, like pulling on the exposed roots of a tree.

The memories of assembling the desk and your first day of work are a type of memory called declarative memory, which refers to things that you can explicitly evoke—like facts, events, and stories. On the other hand, learned behaviors, such as playing the piano or riding a bike, are a form of implicit memory called procedural memory or memory of how to do things—commonly referred to as “muscle memory.”

We constantly embed memories into objects and contexts without realizing it. However, we also consciously offload our declarative memories into objects: We purchase souvenirs, hold on to a loved one’s old sweater and take photos at significant events. If that works, and if our behaviors are merely a different kind of memory, then why not try to offload some of those too?

Invisible forces

Here’s how I like to think about it: Every object emits a habit field. When we sit down at the desk in our office to work, we shape its habit field into a productive one. When we sit down in a lounge chair to watch our favorite TV program, we nudge the chair’s habit field toward relaxation and consumption. The more we repeat the same activity around an object, the stronger its habit field gets. And the stronger its habit field gets, the easier it is for us to effortlessly fall into that mode of behavior the next time we’re around the object.

Every object comes with a habit field baked in. Often, this stems from the physical nature of the object and our past experiences with similar objects. Don Norman calls these affordances. Typewriters afford writing. Watercolors afford painting. Books afford reading. Because there’s a physical limitation to what we can do with these objects, their habit fields come pre-defined and don’t change easily.

Fuzzy habit fields

Some objects come with more ambiguous habit fields. A simple table, for instance, can be used as a surface for dining, writing, or reading. Yet, throughout human history, these “fuzzy” objects have mostly been secondary to the main activity—when you interacted with the table, you were interacting with the food on the table. The multifunctional objects in our lives tended to stay in the background; that is, until the personal computer came along.

Let’s go back to your office desk. Say for example, every time you sat down in front of it, instead of doing your work, you checked e-mail, clicked on Twitter links and played Facebook games. Even if you have the most powerful processor, work-ready desk, and posture-supporting task chair, these items will absorb your behaviors and over time, their habit fields will shift in an unproductive direction.

Thanks to the computer’s ability to multitask, sometimes these habit fields actually become oriented around the act of switching programs! If you’re conditioned to alternate between different modes of working every few seconds, it’s no wonder you have a tough time staying focused on one thing.

Our tools are becoming both more capable and less physical—the iPad is one great example. Lacking a tactile keyboard and mouse, the tablet has a habit field even fuzzier than that of a laptop. The portability of the pad opens it to more contexts too, meaning that our interactions with the device have the potential to affect, for better or worse, the habit fields of the objects we use near them.

Reshaping habit fields

The good news is that memories, and consequently habit fields, are surprisingly malleable[2]. If we pay attention to the ways we’re constantly influencing our surrounding habit fields, we can change them for the better. Imagine a habit field around your office desk so potent, that every time you sit down, you become enveloped in a haze of flow-sustaining productivity. It may sound like hyperbole, but with the proper conditioning, it’s entirely possible.

Habit field pulse-check

Think about how certain objects or spaces in your life are already oriented around particular behaviors. If you work from a laptop, do you find yourself gravitating toward specific places based on what you’re doing? If you have a computer in your home office and another one in your den, how do you use each of them differently?

Look for natural splits between work and leisure activities, or between creating and consuming things. If you already keep these activities separate, then you might only need to make a few adjustments. If you’ve been trying to do everything from one place and one device, then you may need to make a conscious decision to divide different modes of behavior.

First, define how you want to split your activities across various tools or spaces, and then commit to keeping activities separate to fortify respective habit fields. Every time you sit down, try to ask yourself, “How are my actions going to affect the habit fields of the objects around me?”

The distraction chair

I do most of my work from home, and in my apartment I have a comfortable chair reserved for e-mail, checking status updates, and leisurely surfing the web. I call it my “distraction chair.” I try to reserve my work desk for actual work—writing, designing, and coding—and when I feel the inclination to read Twitter or check e-mail, I move to the lounge chair. Before I had an iPad, I unplugged my laptop and moved to the chair, and it worked just as well.

At first, it may seem like a nuisance to get up and move every time, but that’s exactly the point. As long as you adhere to the rules you’ve created for yourself, over time you’ll find that the strength of the habit fields keep you in place—the act of getting up, walking over, and getting situated in the chair becomes just tedious enough to keep you at the desk, leading to prolonged work periods.

Likewise, the lounge chair’s habit field turns into a “leisure zone”—one that I know to stay away from if I have a deadline and need to focus. Sometimes when I realize I’ve been spending too much time in the chair, it’s easier to snap out of it: all I have to do is stand up and leave the zone.

Barriers to access

Another way to condition the device’s habit field is to limit what its software is capable of. By hindering access to certain applications, you make it tougher to, on a whim, stray from what you’re supposed to be doing.

One thing you can do is delete the shortcuts to distracting programs. Remove them from your dock or desktop. Even when you do have to use them, shut them down immediately after you’re done instead of leaving them open. You can also edit your HOSTS file to prevent access to certain websites.

You may want to uninstall these same programs. I removed the Tweetie Twitter client from my Mac because it worked too well—it allowed me to read my Twitter stream with a simple keyboard shortcut, which I would habitually press without realizing it. Now, when I need to, I just access Twitter from my iPad. Just because you can have instant access at your fingertips doesn’t mean you should. By increasing the effort it takes to get to undesirable applications, you diminish the temptation for your subconscious mind to go for the quick reward.

Necessary constraints

TXTBlocker is a new cell phone add-on that uses GPS technology to disable texting while driving. The marketing copy on their website also promotes the ability to “set up ‘Safe Zones’ to disable or limit functions like texting in schools or around workplaces.” Projecting into the near future, we can anticipate a wave of new devices that can sense nearby objects and disable functionality depending on the context. The irony is not lost here—it seems like the solution to making our multitasking devices more effective is to turn them into unitaskers in roundabout ways.

There’s a good reason for this: The more capable and multipurpose our tools become, the more the burden of deciding what they do shifts on us. Physical constraints must be replaced by artificial ones, and the effectiveness of our tools becomes an extension of our own willpower and self-discipline. Without these constraints, our devices essentially become amorphous blobs that aren’t really great at getting anything done.

We’re all superheroes

We have the power to bestow our abilities onto the things around us. By being conscious of our tools, habits, and spaces, and actively conditioning them to help us behave the way we want to behave, maybe we can more efficiently tap into the thousands of hours of creative genius embedded in our everyday objects. Maybe we’ll be able to maximize the capabilities that new technologies afford us without being overwhelmed by the distractions. And, just maybe, we’ll remember what it feels like to be utterly engrossed in our daily work.

Notes

[1] Like any analogy, this one only goes so far. Memory is a complex, messy thing that we’re constantly learning new things about. For those interested in diving deeper, this Radiolab episode on Memory and Forgetting is an excellent starting point.

[2] Loftus, Elizabeth F. Creating false memories Scientific American. 277(3): 70-75.

The Wisdom of Community
http://www.alistapart.com/articles/the-wisdom-of-community/

It’s one of the most important concepts on the web today—perhaps the most important for social media—but it’s one of the least understood. When James Surowiecki wrote The Wisdom of Crowds in 2004, he explored the stock market and other classic social psychology examples, but “web 2.0” was still nascent. It’s time to connect his ideas to the social web, where they can reach their full potential.

The Wisdom of Crowds (WOC) theory does not mean that people are smart in groups—they’re not. Anyone who’s seen an angry mob knows it. But crowds, presented with the right challenge and the right interface, can be wise. When it works, the crowd is wiser, in fact, than any single participant.

The standard example is this: Imagine you have a jar of pennies. Ask a few hundred people how many there are inside. When you tally the results, chances are, all the guesses will be wrong. But if you average all the answers, the result will be almost perfect, almost all the time.

The web, with its low barrier to entry and permeable social boundaries, is the ultimate medium through which to explore the finer points of the wisdom of crowds. You’re surrounded by online examples: Google’s search results. BitTorrent. The “Most E-mailed” stories on your favorite news site. Each is powered by wisdom gleaned from crowds online.

You need a few things to enable online crowds to be wise.

Simplicity

In the penny jar example, you ask each participant for a number. Google didn’t ask anyone anything to create their search results, though they just intuited the importance of every page in their index by considering how often it was linked to.

Note that in each case mentioned above—Google, BitTorrent, “Most E-mailed” lists, and the penny jar—the inputs are not conversational. Conversational inputs are too complex for Wisdom of Crowds systems. Online discussion systems do not lead to wisdom on their own.

The simplicity of the individual task is also important. Systems based on the Wisdom of Crowds can tackle surprisingly complicated projects, but each project must first be broken down to its simplest possible components.

Interface

Complicated interfaces can be great for complicated tasks, but not for WOC systems. The more complicated the interface is, the less participation you can expect, and the more muddled that participation will be. Soliciting WOC feedback is about tapping the zeitgeist. Don’t make participants think too much.

WOC interfaces are often voting mechanisms that use a spectrum or a thumbs up/down system, but they could just as easily involve selecting a point on a map or drawing a shape.

Aggregation

One of the reasons discussions do not lead to wise results is that there’s no aggregation—the conversation just happens. But WOC systems are there to produce a result. This requires an aggregator (like you) and an algorithm.

In the penny jar example, the aggregator is the person tallying the guesses, and the algorithm is a simple median. With Google’s search results, Google is the aggregator, their algorithm is called PageRank, and it’s a constantly evolving, closely guarded secret.

Participation

A defining element of any WOC system is that the more participants it has, the better it gets. Discussion systems and chat rooms fall apart when too many voices get involved. If your community feature gets worse the more people use it, it’s not a WOC system.

For a crowd to truly be wise, it also has to be diverse. The Wisdom of Crowds works because the people on the edges balance each other out. Recruit too many people on one side of any spectrum and your results will suffer.

Selfishness

It’s counter-intuitive, but the wisest crowds are the ones made up of individuals who are thinking about their own needs, not the needs of the group. In the stock market, the participants are all motivated to buy low and sell high. Yet the markets are usually wise about finding the value of a company. Each person is thinking about their bottom line, not the health of the company or the market, but it works.

Similarly, website creators were not consciously voting for certain sites to be highly ranked, but the collective linking decisions did produce wise results. Nowadays, link spammers do try to manipulate Google’s results, which is akin to stock manipulation. Both practices are fought by the institutions that depend on unmanipulated results.

Selfishness also fights a larger problem. Group-think is when the members of a group put the group’s needs above their own. As soon as this happens, the group is in danger. The stock market collapse, the NASA Challenger disaster, and many other examples can be attributed to group-think.

In the penny jar example, participants were told that the correct guesser would win all the money. Their participation was entirely selfish — they wanted to win the money. The fact that their participation could be averaged to create an answer is just a fortunate byproduct.

Designing for selfishness does not necessarily mean paying cash prizes. A news site with a Most E-mailed Stories box that displays the stories that have been e-mailed to people doesn’t have to pay anyone to pick their favorite stories—the information is easily gleaned from server logs. The key factor is the user’s motivation for participating: They’re doing it for their own personal reasons (“Heather would love this story!”). They’re not consciously voting for the story—the vote is a byproduct.

This method should be contrasted with news voting sites like Digg, where users do explicitly vote for top stories. As a result, these sites face a constant battle against people trying to game the system. Indeed whole businesses have sprung up in order to place a link on the highly trafficked Digg homepage.

Scores

Keeping score is part of any game, and any website with community input is going to be used as a game. So think very carefully before assigning your participants a score for their participation.

For example, Slashdot had an internal “karma” score that it assigned to every member based on their participation. The system then used that score to determine certain features (like the ability to moderate other users’ comments and their default comment score).

That’s all fine. But then they disclosed the user’s score to them. The moment they did that, they invented “karma whores”—users who post comments they know will be rated highly by the community, creating a unique kind of group-think.

Games are fine, so long as the goal of the gamer benefits the site. But Slashdot’s games either promoted group-think (by agreeing) or trolling (by disagreeing). Both probably existed before the scores, but disclosing the scores certainly fueled them.

Leaderboards

Leaderboards create a problem for Wisdom of Crowds systems. On the one hand, a well-tuned WOC system can create an excellent leaderboard. Feedback from users is collected, the algorithm scores the content, and the result is a list of items in a fairly accurate good-to-bad order (think Google results).

And there’s the rub: Disclosing the ranked list to the community amplifies group-think. The highly rated items get even more highly rated, the low rated items fall off the radar. Showing the list destroys its accuracy.

So what to do? Here are a few suggestions:

- Go in phases. Allow voting for a set period of time. When that time is up, close voting and display results. Threadless does this for its design submissions.

- Mix it up. Instead of showing a ranked list (aka leaderboard), show a selection that includes highly rated items in a random order. This is what Flickr does with it’s “interestingness” view.

- Make users earn disclosure. Show the voice of the community only after your vote has been cast. This is what many online polling systems do to avoid letting the current tally influence the voters.

- Use an algorithm. When you have to show a current, or a ranked list, use a recipe that takes lots of data into account, in addition to votes. This is what Google does with its search results. It’s also why they have to constantly tweak the results in an ongoing arms race with people who try to figure out their system.

How you display the wisdom of your crowd can be as important as how you ask for it in the first place. It can be tempting to just put up a ranked list, but in most cases doing so will harm the very wisdom you’re trying to glean.

Explicit vs. implicit feedback

In many of the examples I’ve used, wisdom is gleaned from user behavior. In these cases, the feedback is implicit. In other cases we ask users outright for feedback, as in voting systems. That’s explicit. Whether you use explicit or implicit feedback, or some combination of the two, is an important decision in designing any WOC system.

In working on your own WOC systems, pay attention to when you can glean implicit feedback without having to ask for it directly. Implicit feedback is usually more honest and less prone to gaming. There are also ways to mix the two, for example, asking for explicit voting, but comparing it to implicit data (such as page views, comments, or other recordable user actions).

Voting

This sounds undemocratic, but voting does not have to rule all in WOC systems. In many cases, it shouldn’t.

Just because you’re collecting votes doesn’t mean you have to crown the item with the most votes the winner. You could just as easily look for items that are controversial (high percentage of both good and bad votes) or are undiscovered (low number of total votes).

And remember that not all votes have to be equal. Votes from “good” members (however you determine good) can have a higher impact.

Studies show that when rating a series of items, users are more likely to vote bad in succession. In other words, once you start voting bad, you’re more likely to keep voting bad. So it would be fair to count a bad vote less if it comes after another bad vote by that user. Or just keep the length of time in that voting session as a variable, and see what happens when you alter how you weigh early votes vs late ones. If someone’s been voting for an hour, does that make them more valuable or less? Experiment to find out.

Wiser together than we would be alone

These aspects of the Wisdom of Crowds are just the start — there’s a lot more to learn. Be sure to pick up Surowiecki’s book. And remember, WOC systems must evolve: you’re never done. But done right, they can change the way we live online, and maybe make us all a little wiser.

Coaching a Community
http://www.alistapart.com/articles/coaching-a-community/

We’ve all been part of communities since kindergarten, or earlier. Churches, schools, sports teams, and neighborhoods all satisfy basic human desires to interact with others and work toward a common goal. And yet, when these communities are online and we start to think of them as “social sites,” these concepts can suddenly feel foreign. My work in communities (primarily as the editor of community-created magazine JPG) has shown me that different sets of people are usually motivated in similar ways. Most people have an innate need to belong and feel like part of something, and successfully contributing to that something can really reinforce self-worth. Whether you’re at a company such as Yelp working with product reviews, or Threadless working with t-shirts, or in a church group working on an annual recipe book, try some of these methods to nurture great content.

Communicating effectively

If you’re in charge of an online community, you have a working relationship with a group of people, and many ways of communicating with them: usually a blog, a forum, a newsletter, site mail, e-mail, comments, etc. Figure out which channels are most powerful, and find a way to use them. In many cases, these communication channels aren’t one way. Giving members ways to interact with you and each other brings you all closer. At JPG, the strongest communication medium was a weekly newsletter. We stuffed it full of content that people wanted—stunning photos of the week, challenge winners, upcoming deadlines, etc.—and gained excellent response and click-through rates. It meant a lot for people to see themselves or peers recognized for their talent, and that helped make the e-mails successful.

Yelp has invested in active user forums, and often gets the word out about parties or collects information for future newsletters from there. These forums (Yelp Talk) allow Yelp’s users to get to know each other, socialize, and express themselves. Flickr’s forums are distributed by topic, and they don’t have a newsletter. Instead, they prominently feature an excellent blog as their main communication method. They include features, such as a Q & A series where each interviewee picks the next, that allow Flickr members to have influence over the blog. Find out what’s right for your goals and your culture, and invest in it. These connections to and from the community are incredible tools, and establishing them is a great first step.

Setting clear and specific expectations

Your members aren’t mind readers, but they are interested in meeting your needs. They’ve chosen to be part of this community and support its goals, but they need to know what those goals are. Put yourself in their shoes: would you rather start typing on a blank page, or answer specific questions within your field of knowledge? Blurb is a self-publishing site that allows members to custom print beautiful hard cover books. They could just ask you to upload a PDF of your book, but instead they provide proprietary software that walks you through every step of the process. No chance for confusion or procrastination!

JPG collects photography-related articles for each issue. The submit page for each article type shows examples of previously published stories, separate requests for each piece of information needed, clear word count ranges, and more. You might google “invoice examples” if you need to make one of your own, but JPG puts relevant examples right on the page.

Another example comes from the Obama campaign: they encouraged their supporters to take initiative in local events with step-by-step, easy-to-follow “host guides.” Most folks would be pretty shy about setting up their own phone bank or campaign party, but the campaign’s thorough instructions made the tasks approachable. Setting expectations can be as simple as featuring work you consider successful, or as complicated as creating your own software. The intended result is simply to share a better understanding with your members, and to give them the confidence to get started.

Mentoring your contributors

Communication with members should happen on a one-on-one level, too. Treat your star members like the most talented coworkers you could ever have, and give them direct, constructive feedback. Be kind without leading them on or giving false hope. This is a relationship that may last longer than the website that fostered it, and both parties can learn and gain from it.

In two years of editing articles from community contributors, I managed to come to consensus on changes with every one of the writers. It had a huge effect on the way these active members spoke to friends about the experience, their likelihood of submitting again, and their loyalty to the community. I also never told a contributor he would be published until I was absolutely sure. When I wrote for more information, expansion on a thought, or approval of changes, I always referred to him as a “finalist” for publication. A professional writer/photographer/whatever probably wouldn’t tell all of his friends that he’s going to be published/featured/whatever, but your member might. That passion is what makes your job fun, but it also means that a little sensitivity goes a long way.

Playing with trends

Trends, including internet phenomena, happen for a reason—people dig them. So find an interesting one related to your community, and reach out to the meme’s creator or contributors. They’ll usually be stoked to see their idea taken to the next level. Your end of the bargain is to credit them appropriately and respect them immensely.

I reached out to Flickr group Wardrobe Remix for a one-off feature in JPG’s Street Fashion issue, and adapted Naz Hamid’s design geek meme Items We Carry into a regular feature in each issue. One of the fascinating parts for me was seeing my community put it’s own spin on these established memes, and adapt them to the mores of the group.

Other ideas: Yelp could adapt the popular 7×7 article, Big Eat SF: 100 Things to Try Before You Die, and create a contest to see who could write reviews of all 100 venues first. Current could take advantage of the “25 things” meme floating around Facebook and ask their members to upload videos of reading them aloud, to be cut into a stream of the most interesting parts. Mix it up! The internet is fun, and besides, the relationships you build with these adjacent groups could be really fruitful in the future.

Giving valuable rewards

There will always be people who contribute to your community for the novelty of it, but adding real rewards such as cash and prizes can get you a different league of member. While it doesn’t help the bottom line, it sets you apart from your competition, lets the member know that you consider their contribution worthwhile, and attracts experienced professionals. It also conveys meaningful approval of the member’s contribution in a way that words sometimes can’t.

Publications such as JPG and A List Apart pay $100 for selected works. Current and Threadless offer payouts for videos / t-shirt designs used. Payment isn’t the only incentive that works. Members can also be motivated by seeing your company spend money on publishing work outside the internet—in a magazine, on TV, or on a t-shirt. Prove to your members that you believe they’re worth it, and they won’t disappoint you.

Praising effusively, but not recklessly

It’s human nature that one negative comment affects us more than ten positive ones. So praise liberally, but keep in mind that different positive actions deserve different rewards. Keeping them separate is really important, or you risk deflating the value of all of them. Think of school: you wouldn’t get an “A” just for perfect attendance, but you might get a certificate.

At JPG, theme photos were always published based on the merit of the image alone, whether the photographer was incredibly active or had only uploaded one photo. However, when picking “featured members” for the magazine, the newsletter, and the homepage, we considered social contributions as much as artistic ones. Similarly, Yelp usually features only positive reviews on a business (three stars or higher) as the Review of the Day on their home page, but will call out talented members with mixed reviews in their newsletter or elsewhere. Whatever your method of praise, remember to be genuine and thoughtful in your interactions, or people will see right through you.

In the end, we’re talking about fundamental social principles of mutual respect, open communication, and effective incentives. People often want to feel like they’re part of something larger than themselves, and that their talents and skills are appreciated. So polish up the skills you learned in the dorms, the glee club, or the Elk’s Lodge, and lead your community online.

From Little Things, Big Things Grow
http://www.alistapart.com/articles/fromlittlethings/

People don’t like being told what to do. We like to explore, change things around, and make a place our own. Hefty design challenges await the makers of websites where people feel free to engage; both with the system itself and with each other. Embrace the idea that people will warp and stretch your site in ways you can’t predict—they’ll surprise you with their creativity and make something wonderful with what you provide.

At Flickr, we’ve worked very hard to remain neutral while our members jostle and collide and talk and whisper to each other. Sharing photos is practically a side-effect. Our members have thrilled and challenged us—not just with their beautiful photography, but by showing us how to use our infrastructure in ways we could have never imagined.

It’s only in hindsight and with analysis that the strategies I share in this article have emerged.

A space for play

Amy Franceschini is one of my favorite artists. In 2002, she created a sculpture called Game for the Masses, her “Intro to Game Theory.” In game play, players distribute all the “pucks” evenly. Whoever manages to collect all the pucks wins. That’s it.

The game was positioned in a gallery with a small set of rules and instructions, but the game was left open for development. Over the course of the night, the game developed into a multi-player, three-dimensional, architectural, gambling, building site for ages three and up. (Source: Futurefarmers.)

The sculpture demonstrated a fascinating idea: given fewer rules, people actually behaved in more creative, co-operative, and collaborative (or competitive, as the case may be) ways.

If you imagine Flickr as something like Game for the Masses—a playing field without rules or a “way to play”—you can see how people can learn to engage with one another through conversations about their content.

Flickr groups are the center of gameplay, from prosaic groups about specific cameras or photography techniques all the way to weird, esoteric groups such as In Numerical Order, where members must add pictures taken of numbers in the real world in—you guessed it— numerical order. There’s the gaggle of “Guess Where” groups in which members take mysterious photos of places in their town and other members identify where each shot was taken. The fabulous wardrobe_remix group’s 6,000 members photograph their outfits and describe them for the world. Interestingly, the rules of this group evolved over time to maintain the group’s own attention. The group spawned other remix groups like Blythe Doll—Wardrobe Remix and even wardrobe_remix BABY. There is seemingly no limit to our endless need to share, to be creative, and imitate other people. All these groups coalesced without any input from the Flickr team.

Although cultural differences and personal prejudices about The Way Things Should Be have challenged us at FlickrHQ, we never mediate group dynamics: our members must be left to their own devices. Any time you construct specific rules of engagement, they are instantly open to interpretation and circumvention, and we want our members to negotiate their place with each other, not with The Authority.

Steady, careful growth

Any community—online or off—must start slowly, and be nurtured. You cannot “just add community.” It simply must happen gradually. It must be cared for, and hosted; it takes time and people with great communication skills to set the tone and tend the conversation.

When Flickr was born, Caterina Fake and I spent many hours greeting new members personally. We opened up chat windows with each new visitor to say “Hi! I work here, and I’d love to help you get started, if you have any questions.” We also provided public forums where staff were present and interactive. Those decisions proved crucial, because apart from creating points where we could inject a certain culture, it was all so personal.

If you want to stir your audience on a rapidly growing community site, take advantage of what we learned—hire a community manager. Or two. You’ll need a clever communicator with a lot of experience being online to help welcome people and provide ongoing support as your community grows. Show your personality and be available. Flickr’s tone is not necessarily suitable for every community, but the point is, the tone is evident everywhere you look.

Personal voice, unobtrusive design

I adore it when people tell me that Flickr makes them feel a certain way. From the outset, I worked hard to make the site seem as if there was a person behind the screen talking to you. As we churned out pages to piece the site together, I obsessed about copy all over the place to make Flickr sound human. From the labels on submit buttons—“Get in there!” to log in, to the copy that shows up if something goes wrong—“Forgotten your password? Don’t worry. It happens to the best of us,” or “An empty comment box? That won’t work!” Exclamations like Yay! Woo! Bonk! Rock! Yee har! make people feel like they’re progressing and doing things well.

We consciously chose to make the site design appear plain and simple, despite its deep complexity. A white background, blue links, sans-serif font, and largely gray palette all present the site as a straightforward place. The look of the place must never overwhelm the photos themselves. We also tried to create an egalitarian playing field. At a glance, visitors can’t differentiate a professional photographer with an enormous lens from an enthusiast just getting started in photography. There is no indication of “quality” apart from the content itself. That also means that it’s up to the viewer to decide for themselves which photos they like to look at and explore without prejudice.

Help people explore

It’s easy to get lost on Flickr. You click from here to there, this to that, then suddenly you look up and notice you’ve lost hours. Allow visitors to cut their own path through the place and they’ll curate their own experiences. The idea that every Flickr visitor has an entirely different view of its content is both unsettling, because you can’t control it, and liberating, because you’ve given control away. Embrace the idea that the site map might look more like a spider web than a hierarchy. There are natural links in content created by many, many different people. Everyone who uses a site like Flickr has an entirely different picture of it, so the question becomes, what can you do to suggest the next step in the display you design?

Anonymity vs identity

Identity is a crucial part of social software systems, but it can (and should) take time for an identity to reveal itself. Certainly, you can be invited to join an existing community by a friend—and that’s something we specifically designed for—but, even then, when you start to reach out from your “safety blanket,” your own identity comes to the fore. What do you do when you first hear of a new site to visit? I don’t know about you, but generally I’ll head on over and perhaps even sign up. As I poke around, I’m essentially anonymous. I have no ties to anyone or anything, and am free to move about without any recognition. This anonymity is important. It allows a new visitor to look around and get a feel for the place, and choose when and how to get started.

Over time on Flickr, members who continue to appear anonymous (only favoriting other people’s photos while posting none of their own, or using the site without adding contacts) are often treated with some suspicion by other members. Identity and connections appear to have social value.

There’s a fine line between a rule and a guideline

There came a point, in about May of 2005, when we realized that we needed guidelines that could help to do the work that we were able to do on a 1:1 basis in the early days. Flickr was simply too big to maintain the “high touch” strategy that served us in the beginning. With scale comes the opportunity for more misunderstandings, collisions, and disagreements.

We needed a way to represent the culture of the place. So, as I sat on a train for several mornings with Heather Champ, Flickr’s very own community manager, we tossed back and forth The Thirteen-Or-So Commandments. Of course, they weren’t actually commandments, but rather guidelines that we wanted all our new members to at least skim. My personal favorite—”Don’t Be Creepy: You know the guy. Don’t be that guy.”—is something a lawyer would never write, and yet it speaks volumes. The other important point is that the “commandments” were designed to be open to interpretation, not to be conclusive. Writing guidelines like this is a great exercise for any team—it encourages reflection about the sort of culture you’re trying to foster.

Variation = richness

This is the real nugget of successful online communities. It’s the sheer breadth of places like Flickr that keep people coming back, and keep people participating. There’s no way to design all things for all people. When you’re dealing with The Masses, it’s best to try to facilitate behavior, rather than to predict it. Design, in this context, becomes more about showing what’s possible than showing what’s there. Imagine your site as a “Game for the Masses” where you don’t make the rules. Leave your members to negotiate and communicate and you’ll get a much richer result.

Be open

Participate in the community you’re trying to build. Add content, make contact, show yourself as a person and have fun. It took me a while to get used to, but now I love and appreciate that when I meet someone who uses Flickr for the first time, they might mention a part of my life that they’ve seen in a photo. I’m part of the team who built the place, but I’m also addicted to Flickr itself.

Community?

As the Flickr community continues to expand, it seems to operate more like a society. Communities on Flickr are just like the communities we belong to offline. They’re small groups of people who know each other or share a specific interest, and whose members want to participate, not only as contributors but also as consumers. As my own distance from each member increases, and influence over their path into the system is basically removed, I see Flickr itself becoming simply an infrastructure to the communities we support. They look after themselves, as well as their induction of new members. Flickr becomes about uptime, speed, and flexibility—almost detaching the things we build from the content itself and people’s interaction with it.

I want to say something cheesy about teaching people to fish, but will refrain. Treat your place like your home: welcome people, fix them a drink and make them feel comfortable. Before you know it, your guests will be chatting amongst themselves, the party will be pumping, and people will be making plans together.

Table of Contents

- ALA 2012 Summer Reading Issue
- A Dao of Web Design
- Understanding Web Design

- Good Designers Redesign, Great Designers Realign

- To Hell With Bad Browsers
- They Shoot Browsers, Don’t They?
- Where Our Standards Went Wrong
- Prefix or Posthack
- Web Standards for E-books
- Fluid Grids
- Responsive Web Design
- Put Your Content in My Pocket
- Apps vs. the Web
- CSS Sprites: Image Slicing’s Kiss of Death
- Sliding Doors of CSS
- The Next Big Thing
- Real Web Type in Real Web Context
- On Web Typography
- More Meaningful Typography
- Orbital Content
- The Discipline of Content Strategy
- Reading Design
- In Defense of Readers
- Habit Fields
- The Wisdom of Community
- Coaching a Community
- From Little Things, Big Things Grow