The King of Web Standards

In BusinessWeek, senior writer for Innovation & Design Jessie Scanlon has just published “Jeffrey Zeldman: King of Web Standards.” By any standards (heh heh), it is an accurate and well researched article. By the standards of technology journalism, it is exceptional. It might even help designers who aren’t named Jeffrey Zeldman as they struggle to explain the benefits of web standards to their bosses or clients. At the least, its publication in Business Week will command some business people’s attention, and perhaps their respect.

Avoiding the twin dangers of oversimplification that misleads, and pedantry that bores or confuses, Scanlon informs business readers about the markup and code that underlies websites; what went wrong with it in the early days of the web; and how web standards help ensure “that a Web site can be used by someone using any browser and any Web-enabled device.”

Scanlon communicates this information quickly, so as not to waste a business reader’s time, and clearly, without talking down to the reader. This makes her article, not merely a dandy clipping for my scrapbook, but a useful tool of web standards evangelism.

Contributing to the article with their comments are Jeff Veen, manager of user experience for Google’s web applications and former director of Hotwired.com; NYTimes.com design director, subtraction.com author, and grid-meister Khoi Vinh; and Dan Cederholm, founder of SimpleBits and author of Bulletproof Web Design. Dave Shea’s CSS Zen Garden features prominently as well, and rightfully so.

A right sexy slide show accompanies the article.

And lest a BusinessWeek article lull us into complacency, let us here note that the top 20 blogs as measured by Technorati.com fail validation—including one blog Happy Cog designed. (It was valid when we handed it off to the client.)

[tags]design, webdesign, standards, webstandards, webstandardsproject, WaSP, zeldman, jeffreyzeldman, veen, jeffveen, simplebits, dancederholm, bulletproof, khoivinh, subtraction, wired, hotwired, nytimes, happycog, zengarden, css, csszengarden[/tags]

InterNetwork

Why does every single social network community site make you:

  • re-enter all your personal profile info (name, email, birthday, URL etc.)?
  • re-add all your friends?

And why do you have to:

  • re-turn off notifications?
  • re-specify privacy preferences?
  • re-block people you don’t want to interact with?

Brainstormed by Daniel Burka, Eran Globen, Brian Oberkirch and Tantek Çelik, Social Network Portability, an emerging article at microformats.org, is an attempt to begin tackling these problems for good. Big- and little-d designers, you can help.

[tags]socialnetworks, portability, microformats, standards, social network portability[/tags]

Better know a speaker: Dan Cederholm

Dan Cederholm is the brilliant mind behind Bulletproof Web Design and Web Standards Solutions and he’s bringing his highly acclaimed talk, “Interface Design Juggling,” to An Event Apart’s Chicago stage. We took a few minutes to dig deeper into what’s going on with Dan these days and what he’ll have in store for us.

Coming soon: Better Know A Speaker interviews with Lou Rosenfeld, Jeremy Keith, Liz Danzico, Luke Wroblewski, and more!

[tags]aneventapart, simplebits, cederholm, dancederholm, aeachicago2007[/tags]

Let there be web divisions

We are still crunching numbers on the Web Design Survey—with over 32,000 responses to 36 questions, there’s a lot to crunch. But in one area, preliminary data supports what anecdotal experience led us to expect: almost no one who makes websites works in their company or organization’s web division. That’s because almost no company or organization has a web division. And that void on the org chart is one reason we have so many bloated, unusable failures where we should be producing great user experiences.

Ponder. No matter how critical the web experience may be to the organization’s mission, the people who design and build those mission-critical sites work in divisions that have nothing to do with the web, and report to leaders whose expertise is unrelated to web design and development.

It’s a startling fact with profound implications—and as such has gone unnoticed by the business community and press.

IT or marketing

From law firms to libraries, from universities to Fortune 500 companies, the organization’s website almost invariably falls under the domain of the IT Department or the Marketing Department, leading to turf wars and other predictable consequences. While many good (and highly capable) people work in IT and marketing, neither area is ideally suited to craft usable websites or to encourage the blossoming of vital web communities.

Competent IT departments handle a dazzling array of technical challenges requiring deep, multi-leveled expertise. But tasks such as equipping 20,000 globally dispersed employees with appropriately configured PCs, or maintaining corporate databases and mail gateways, don’t necessarily map to the skills required to design great user experiences for the web.

Large-scale systems expertise takes a different mindset than what’s needed to write usable guide copy, finesse markup semantics, or design an easy-to-understand user interface employing the lightest and fewest possible graphic images. Moreover, nimble development and support for open standards are not the hallmarks of large IT departments (although undoubtedly there are noble exceptions). Additionally, developers with a background in IT (again, with some exceptions) tend to create from the point of view of technology, rather than that of the user.

What about Marketing?

Organizations that don’t entrust their website to IT tend to hand it to Marketing. The rationale for doing so is easy to see: Marketing has been briefed on the organization’s business goals (at least for the next quarter), and the division is staffed by communications specialists who know at least something about writing and art direction. If nothing else, they know who to hire to write their copy, and they are comfortable telling the in-house graphic designers to make the logo bigger.

Like IT, Marketing has valuable organizational knowledge (plus certain skills) to contribute to any serious web enterprise. The leaders of Marketing, like the leaders of IT, should be frequently consulted in any web effort. But the skills of Marketing, like the skills of IT, don’t necessarily map to what is needed to create great web experiences.

For one thing, as anyone reading this knows, the web is a conversation. Marketing, by contrast, is a monologue. It can be a great monologue—for examples of which, see The One Show Winners or the AIGA Design Archives. But a monologue and conversation are not the same, as an hour spent with your windy Uncle Randolph will remind you.

And then there’s all that messy business with semantic markup, CSS, unobtrusive scripting, card-sorting exercises, HTML run-throughs, involving users in accessibility, and the rest of the skills and experience that don’t fall under Marketing’s purview.

If not them, then who?

Business and non-profit decision makers, for your users’ good, consider this request. Stop separating the members of your web team. Cease distributing them among various (often competitive) divisions led by people with limited web expertise. Let the coders, designers, writers, and others charged with creating and maintaining your web presence work together. Put them in a division that recognizes that your site is not a bastard of your brochures, nor a natural outgrowth of your group calendar. Let there be web divisions.

[tags]webdesign, webdevelopment, design, development, web divisions[/tags]

Hi, Mom!

A Business Week slide show, “Thinking Outside the Design Box,” profiles “10 professionals working at the very edges of their disciplines in order to redefine their industries.” Included are designers Lisa Strausfeld of Pentagram, who helped design the interface for One Laptop Per Child; Robin Chase, the founder of Zipcar; and (ulp!) me.

I’m in there because they needed a pretty face, and because of the whole web standards thing.

The piece is part of “Cutting-Edge Designers 2007,” a Business Week Special Report focusing on innovation that arises out of crossing disciplines and combining technologies.

It’s worth reading, which is lucky, because I would have blogged it no matter what.

[tags]design, innovation, businessweek, designers, zeldman[/tags]

When is e-mail like a bad website?

Nokia sent a friend an HTML e-mail message. I’ve broken it into five screen shots, because it won’t fit on one:

  1. Nokia “e-mail” part 1
  2. Nokia “e-mail” part 2
  3. Nokia “e-mail” part 3
  4. Nokia “e-mail” part 4
  5. Nokia “e-mail” part 5

A word about the fonts. These are not my default settings. They are controlled by Nokia, on the assumption that 9px Arial is universally legible and attractive.

A word about the layout: I can reconfigure it by changing the width of my e-mail client’s message window, but no matter how I play with the width, I never get the layout the sender intended.

Nokia is trying to cram a bad web page—the kind of web page that is all graphics and almost no textual content—into a container that can’t hold it. It’s like pouring wine into a sieve. I’m not saying the graphic designers who created this message lack talent; from what I can tell, they are gifted indeed, and able to do nice work under what must be harsh production deadlines.

I’m not saying the layout is broken for everyone, or that there couldn’t possibly be an MF Doom fan who also digs Fall Out Boy. Clearly the layout must work correctly in some applications; doubtless, too, there must be some users who enjoy getting craploads of musician photos in their e-mail in-box. Nokia wouldn’t do this if it didn’t work for somebody. Responding to this post by saying, “Funny, it looks okay in my e-mail client” will miss the point that e-mail, as a medium, really doesn’t want to carry all this freight.

Related posts

Eight points for better e-mail relationships

Okay, so under the right circumstances, when people have requested it, e-mail can be a platform for design. Here are eight ways to make it work better (and avoid pissing off people who hate HTML mail).

E-mail is not a platform for design

ASCII means never having to say you’re sorry.

[tags]HTML mail, e-mail, marketing, internet marketing, design[/tags]

Eight points for better e-mail relationships

Campaign Monitor has taken me to task, and I find it hard to dispute their primary contention:

To say as a blanket statement that HTML email impedes communication is an extraordinary generalisation. There are many times when a well designed, and well laid out HTML email can be a lot clearer, easier to scan and overall better experience than the equivalent in plain text.

They’re got a point. Having read and considered Campaign Monitor’s comment and other sensible responses to my 8 June post, I agree that my brush was too broad.

A few well-designed, well-considered, communicating visual elements, in the context of a well-written, time-respecting, communicating HTML e-mail message, sent only to people who have asked to receive it, and formatted to work across applications and platforms, can indeed enhance communication.

Yet unsolicited mail, as all internet users know, makes it hard to use e-mail to communicate with friends, family, and work mates. Trying to defeat spam, we miss messages from business partners and loved ones. Add unsolicited graphics and broken formatting to that mix; send tons of it to a business person who is trying to check e-mail while out of the office, and you have a recipe for road rage on the information superhighway.

Perhaps reasonable people could agree to the eight notions put forward below.

Note: As in my previous post, I’m about to preach to the choir. Designers reading my site and using Campaign Monitor or other fine mail services (such as Deck advertiser MailChimp, cough) already know and practice ’most everything I’m about to recommend. The following is not a pledge. Pledges don’t work. People don’t change their behavior or business practices because someone with a blog asks them to be nice. Okay? So this is not directed at my readers or Campaign Monitor’s customers, who, I believe, will agree:

  1. Unsolicited HTML mail (like unsolicited mail generally) is an abuse. Send HTML formatted mails only to those who’ve opted in. Always offer a text mail version.
  2. Consider making text mail the default, and HTML mail the optional opt-in. Typically, where choice is provided, the HTML option is checked by default. Many users—because they assume the experts who created the web service are looking out for their best interests—don’t change defaults. This doesn’t mean they all actually want HTML mail. If the default switches to text, then you can be reasonably sure that those who opted for HTML mail probably want it.
  3. On your website, provide a sample of your HTML newsletter so people can judge for themselves if it’s something they want to receive.
  4. As in all design, consider every element before adding it. Remove everything that does not help you communicate.
  5. Test. I can’t count the number of banks, e-commerce and travel services that send me HTML-formatted transaction records, receipts, itineraries, and other jim-jams that do not work in my mail platform. These businesses never offer a plain-text version, let alone an opt-in choice with a test link to see if I like what they have to offer and verify that my mail client likes it, too. Broken mail doesn’t win friends and influence customers (except to change vendors). I am likelier to switch travel services than e-mail clients.
  6. Never send bulk e-mail to a list of people who haven’t agreed to receive messages from you. (This, of course, will never happen, but it belongs in the list anyway.)
  7. E-mail blaster product providers, please offer a streamlined option for those who choose to send their subscribers text-only. Don’t make us design HTML mail templates we have no intention of using, and jump through hoops to make sure our users never see the dummy HTML mail format you asked us to create. (Not directed at any company in particular; suggested as a product differentiator slash best practice.)
  8. Learn how HTML mail works (or doesn’t) across as many platforms as possible, and work with the manufacturers to improve support for web standards. This is not my job. I did my job where web standards are concerned (you’re welcome!), and turned over The Web Standards Project to a new generation of leadership. And as I never send HTML formatted mails, not only is it not my job, I wouldn’t even be qualified to do it. But standardistas who are compelled by their clients to create HTML mails (or who choose to do so) are gently urged to do their part in diminishing wasted bandwidth and enhancing semantics.

Related posts

When is e-mail like a bad website?

Nokia sent a friend an HTML e-mail message. I’ve broken it into five screen shots, because it won’t fit on one. E-mail, as a medium, really doesn’t want to carry all this freight.

E-mail is not a platform for design

ASCII means never having to say you’re sorry.

[tags]HTML mail, e-mail, marketing, internet marketing, design[/tags]

E-mail is not a platform for design

All these years of internet use later, HTML mail still sucks. You may think I mean “HTML mail doesn’t work properly in some e-mail clients.” And that statement is certainly true. Companies spend hours crafting layouts that may not work in Eudora or Gmail, or may no longer work in Outlook.

Even in programs that support the crap code used to create these layouts, all that hard visual work will go unseen if the user has unchecked “View HTML Mail” in their preferences.

As for CSS, it is partially supported in some e-mail applications and in web apps like Gmail, but only if you author in nonsemantic table layouts and bandwidth-wasting inline CSS. Which is like using a broken refrigerator to store food at room temperature.

But when I say HTML mail still sucks, I don’t mean it sucks because support for design in e-mail today is like support for standards in web browsers in 1998.

I mean it sucks because nobody needs it. It impedes rather than aids communication.

E-mail was invented so people could quickly exchange text messages over fast or slow or really slow connections, using simple, non-processor-intensive applications on any computing platform, or using phones, or hand-held devices, or almost anything else that can display text and permits typing.

That’s what e-mail is for. That’s why it’s great.

E-mail is not a platform for design. Unlike the web, which also started as an exchange medium for text messages but which benefited from the inclusion of images and other media, e-mail works best when used for its original purpose, as the most basic of content exchange systems.

“Designed” e-mail is just a slightly more polished version of those messages your uncle sends you. Your uncle thinks 18pt bright red Comic Sans looks great, so he sends e-mail messages formatted that way. You cluck your tongue, or sigh, or run de-formatting scripts on every message you receive from him. When your uncle is the “designer,” you “get” why styled mail sucks. It sucks just as much when you design it, even if it looks better than your uncle’s work in the two e-mail programs that support it correctly.

Even though it doesn’t work right in many e-mail applications, and even though many users dislike it, HTML appeals to clients because it’s another place to stick their logo. And it appeals to the kind of designer who thinks everything, even a bullet hurtling toward his own skull, would improve if decorated. I hate that kind of designer almost as much as I hate people who hate design. That kind of designer gives all designers a bad name, and is chiefly responsible for the slightly amused contempt with which many business people view designers, art directors, and “creative” people generally.

Say it with me: HTML is for websites. CSS is for websites. GIFs and JPEGs are for websites.

ASCII means never having to say you’re sorry.

Discussion closed

The conversation has moved on. Feel free to contribute to the follow-up posts.

Related posts

When is e-mail like a bad website?

Nokia sent a friend an HTML e-mail message. I’ve broken it into five screen shots, because it won’t fit on one. E-mail, as a medium, really doesn’t want to carry all this freight.

Eight points for better e-mail relationships

Okay, so under the right circumstances, when people have requested it, e-mail can be a platform for design. Here are eight ways to make it work better (and avoid pissing off people who hate HTML mail).

[tags]HTML mail, e-mail, marketing, internet marketing, design[/tags]

Daily Reports from 1997 on

Our “Twelve Years of Web 1.0 Goodness” theme continues with a mini-retrospective of Daily Reports from 1997 on. (Earlier Reports are lost due to over-writing.) You don’t need the WayBack machine to go way back in zeldman.com history. Enjoy these representative Daily Report pages from …

Damn, that’s good eatin’. There are thousands of entries; these are just some I found while clicking idly along. As I look at them, I mostly focus on column width, font, text size, and color. I can’t bring myself to read them (although I’m sure some are okay). What is the value, anyway, of an old blog entry? Compared to an old song, an old valentine, not much. What an odd activity for so much human energy to have been channeled into.

Related

Since 1995
Twelve years of juicy Web 1.0 Goodness.™

[tags]blogs, blogging, daily report, blog history, zeldman, zeldman.com[/tags]

iTunes, iLike, and iWish

At long last, the new iTunes upgrade lets you replace DRM versions of music you bought at the iTunes store with new, higher-quality, non-DRM-protected versions. Everyone must be as happy as I was; the whole world apparently bought non-DRM-protected versions of its music today. How else to explain the inability of Apple’s server to deliver the purchased music?

I’ve got 45 files stuck in a download queue that blazes along at about 16 bytes per second, yes, I said bytes, before timing out and locking up. (Screen shots: 1, 2.) The first 50 files or so downloaded at normal speed; then everything ground to a halt, and it’s been that way for hours.

I don’t mind waiting for Apple to sort its network problems. I just wish iTunes would quit nudging me to sign in and download files that are just plumb stuck.

I like iLike

Speaking of music and bandwidth problems, in less than two weeks of use I have become addicted to iLike™. This clever web app uses iTunes APIs to keep track of the music you are playing and “watch” the music your friends are playing via a sidebar that installs itself in iTunes.

Think of it as part Truman Show, part personal radio station. Nobody will know you’re dissecting a moose, but everyone knows you’re listening to Barry Manilow. Insidiously and almost overnight, the app changes the way you listen to music. It might even change the music you listen to. (You might stop listening to Barry.)

With iLike, you can preview your friends’ music, recommend tracks to others, find free music by little-known bands that matches the music you’re listening to, and lots more. It’s a great little application. But the developers need more servers. The app often crawls. At times it’s too underpowered and overtaxed to find your friends’ music, or to record the music you just listened to. Sometimes it even goes offline, and then what do you have? Just you, listening to music. Which suddenly seems not to be enough.

[tags]itunes, ilike, web apps, bandwidth[/tags]