The moment I realized this was an epiphany for me. For one thing, it helped me understand the depth of my frustration with the poor writing on some of my clients' sites. I want to make great websites; I have no interest in building kick-ass containers for crappy content. If you've ever worked with me, you know what I mean.

For some developers, the only thing that matters is a happy client. If the client is happy, the project is a success, end of story. When you think this way, your job is to determine what would make your client happy and deliver it, whatever it is. In extreme cases, the quality of the completed site will depend entirely on the client's understanding of what makes for a quality website, because the developer is loath to contradict anything the client says or believes.

I'd like to think that few developers are really so lacking in, well, standards. Instead, most failed sites are made by people who want to make good websites but lack the necessary skills or understanding. Somehow I find this more forgivable than the behavior described above, although the result is the same: a bad website.

But back to my epiphany. What I saw in that moment is that my allegiance is not to web standards, nor to any particular approach or methodology, but to an elusive result which for lack of a better term I'm calling "quality." I'm obsessed by it. I want to see it, and understand it, and most of all, create it. I really am a qualityista. If you've ever worked with me, you know what I mean.

So the fine folks at Smashing Magazine did a showcase piece on 404 error pages and included the 404 page at Luminous. If you haven't seen this page, it's written entirely in haiku. As is my About page, by the way. I like haikus.

I mention this not to discuss haikus but copywriting, specifically copywriting for websites. Why does so much of it suck? Actually, I think I know why. It sucks because copywriters read what other copywriters write and conclude that website copy is supposed to sound like it was composed by robots.

Now, in fairness to copywriters everywhere, copywriting is hard. For me it's harder than any other kind of writing. This is why I turned to haikus on my About page: they helped me circumvent the constraints of the form and to do so in a way that expresses who I am, which is the underlying point of any About page.

Mind you, I'm not advocating haiku as the one-size-fits-all seventeen-syllable solution to the problem. But a little personality, a little humor, some subtle indication of one's status as a living and breathing and thinking human being, can go a long way toward improving one's copy.

The People of Flickr

When it comes to great copy, the first site I think of is Flickr. Whoever writes their stuff is definitely not a robot. Consider the opening sentence on the Flickr About page:

Flickr--almost certainly the best online photo management and sharing application in the world--has two main goals...

Sorry, robots don't write "almost certainly." "Almost certainly" is a non-robot giveaway and we're only three words in.

I know the counter-argument: Flickr is Flickr, and Flickr is cool. Whereas X Company is not cool, so it can't come off sounding like it employs any actual human beings.

I disagree. Flickr may have more leeway than some, but they created that leeway, they carved it out. Naturally you must know your audience; that's a given. But when dealing with a company, people want to feel like they're dealing with other people; that's a universal.

Of course it's not easy to find the words that convey the right kind of "personness." It's a conjuring act, really, one for neither the faint of heart nor the narrow of mind. But here's the thing: Robots can't do it.

The New York Times just dropped TimesSelect, their online premium content subscription program. The program ran for two years and was generating about $10 million a year in revenue. Content previously restricted to subscribers is now available to all.

The reason for the change is simple: money. The Times can make more of it by switching to an advertising-based model.

There's a lesson in this, and it's not that information wants to be free.

Now, I remember a time when not quite every cultural product was a vehicle for advertising, a lure for eyeballs. The web circa 1998 was like this. If you were there, you know what I mean. It was cool. But of course the web circa 1998 was a rare respite (or semi-respite, really) from the deluge.

I reveal both my age and my idealism by mentioning this.

The Immediate Future of Web Advertising

Back in the real world, as it were, I've been meaning to note my appreciation for the advertising network approach used by The Deck, particularly the fact that they only accept ads for products or services they've bought or used themselves. It's a crafty move, too, since it adds cred to the ads that appear. (The Deck adds even more cred by being selective about who gets to join the network.) But the Deck, as an idea, doesn't scale easily, so it's hard to see it becoming a widely adopted approach.

The big money, of course, is in targeted ads. The more you know about your individual readers (and evidently the Times, a registration-based site, knows quite a bit), the more you can charge advertisers to hit them up.

I'm awaiting the day, not far off, when I encounter ads aimed directed at me and addressing me by name. This will work much like Amazon's personalized recommendations except the ads will appear on sites I never previously visited and will reveal an uncanny and terrifying insight into my deepest desires.

And what will these ads be about? Ad blockers. They'll all be trying to selling me new and novel ways to stem the deluge.

Prompted by Khoi Vinh's excellent write-up, I recently implemented Google Co-op custom search on Luminous. This is site-specific search, the results of which appear on an in-site page that can be styled to more or less match the look of your site. It's a significant improvement over the previous Google offering, which published search results on a Google-hosted page with limited styling options.

Still, there are issues. The functionality is a bit difficult to implement due to shoddy and scattered documentation, and in-site results require purchase of the Business Edition, which at $100 a year is not exactly a bargain.

In the end I worked out the problems and forked up the dough but then was annoyed to discover how Google both uses and fails to use Javascript in delivering search results.

No Javascript, No Search Results

You hear this coming, don't you? Because Google uses Javascript to deliver the search results, users with Javascript turned off, as well as those using non-Javascript devices, will see zero search results. The search form will load the results page, but the page will be empty. I will spare you the rant about accessibility (and Google's disinterest in same) and cut to the solution.

Unobtrusive Javascript to the Rescue

The trick is to point the search form to the Google-hosted version of the results page (all Google Co-op custom search engines include one of these pages) and use a bit of unobtrusive Javascript to rewrite the path in the form's action attribute to point to your in-site results page. The upshot: users with Javascript will see in-site search results; those without it will see the Google-hosted version. (I know I said no rant, but really, why can't Google offer this functionality, at least as as an option? Could it be they lack the resources necessary to write a three-line Javascript function?)

If you'd like to give my approach a whirl, view source on any Luminous page to see how I set up the form, then check out the rewrite script. It's dirt simple: just change your search form to point to the Google-hosted version of your results page, then copy my little script and change the values to match those on your search form. Feel free to contact me if you have any questions.

All-out search engine optimization is like all-out bodybuilding. Muscles can be nice, but when you focus entirely on building bigger muscles, you end up a muscle-bound freak. That's what all-out SEO sites are like. They do well with search engines but at the price of ridiculous code and redundant, irrelevant content.

My own take on SEO can be summed up by a quote from Frank O'Hara's faux poetry manifesto Personism: "As for measure and other technical apparatus, that's just common sense: if you're going to buy a pair of pants, you want them to be tight enough so everyone will want to go to bed with you."

Translation: I respect the motivation for SEO (more traffic), so I'm willing to make some reasonable concessions in this area.

Translation of the translation: Aside from the various search engine-friendly practices I do as a matter of course and would continue to do in a world without search engines (structured markup, CSS for layout, unobtrusive Javascript, no Flash navigation, no pop-ups, image replacement for text graphics, custom error page), I've taken to determining keywords for each article I write and including these in the title element, the h1, and the file name.

Perhaps that's not much in the way of concessions, but I'm unwilling to write "keyword-rich" content, to say nothing of nonsense like using header markup for lists, as one SEO "guru" recently recommended a friend do.

If my pants aren't tight enough, so be it. I won't cut off circulation to increase traffic.

According to a recent New York Times article, multitasking doesn't actually increase productivity but hinders it, because disruptions and interruptions impair our ability to process information. I didn't need to read the article to know this. The proof is in my typical workday, with it continuous starts and stops, a seemingly endless stream of interrupted interruptions. By day's end, I'm often exhausted and stressed, not so much from the work but the form of the work, the herky-jerky to-ing and fro-ing. It makes my head hurt, it makes me crazy, and it rarely leaves me feeling I've accomplished anything.

The core problem is email. I receive a ton of it; more all the time. If email is the killer app, I sometimes feel like one of its victims. At the same time, it's almost impossible to imagine work these days without it. And certainly my own work, with its far-flung clients and colleagues, couldn't exist without email. What to do?

Managing the Technology

I've never been one for productivity how-to's (books, websites, seminars, and the like), believing such things a likely waste of time, the rain dance of the unproductive. But there was a line in the New York Times piece that got me thinking: "The answer appears to lie in managing the technology, instead of merely yielding to its incessant tug."

The next day, I set up a system of checking email at two-hour intervals. These "email windows," as I think of them, usually last about a half hour. Then I close my email program (Apple Mail), or in some cases leave it open and work offline. Goodbye incessant little ding.

Thanks to iCal, I was able to automate the process of periodically re-opening Mail. This was key. Without automation, I would have quickly slipped back to my previous system, such as it was, which was to leave Mail open all day and read messages as they arrived. I wasn't in the habit of answering each message immediately; most would go to my "respond" folder. But as the number of emails in that folder grew, I would feel increasingly distracted and even a bit distraught, which naturally affected my ability to focus on the task at hand. This was bad, obviously, but it was especially bad when the task required sustained concentration--like, say, when building a website.

My business is building websites.

More Productive, Less Crazy

In the two months of using this system, I believe I've become more productive. Certainly I've become less crazy. Less crazy is good.

The one downside is that I'm periodically "off-grid" to clients and colleagues, which can sometimes delay the completion of a task. Whenever this seems problematic, I leave Mail open. Usually it's not that problematic.

iCal Automation

There are doubtless many methods to automate the process, but if you're a Mac user, iCal offers a simple solution.

1. Create a new event in iCal.
2. Under Repeat, select "custom" and check the five days of the workweek.
3. Under Alarm, select "Open file."
4. A new selector widget will appear under "Open file" that says "iCal." Click that and choose "Mail." (If you don't use Mail, click "other" and navigate to your mail client.)
5. Repeat the process for each scheduled launching of Mail. (I have it set to launch at 9:30, 11:30, 1:30, 3:30, and 5:30.)

What We're Talking About

First, some terminology. By "dropdowns" I mean navigational menus that contain a hidden list of choices, typically revealed on mouseover. These menus may open downward, sideways ("flyouts"), or both, and are almost invariably created with some combination of HTML, CSS, and Javascript. Note that I'm not referring to the HTML form element used to offer a selection of options--say, a list of states--from a dropdown list. These aren't commonly used for navigation (nor should they be) and are otherwise quite different from dropdowns.

Second, a disclaimer. Not all dropdowns are equally bad. Some are plain bad, some are extremely bad, and some are "run for the hills screaming" bad. For the purposes of this article, I will respect the mercy rule and ignore the last group.

Okay, now that we know what we're talking about, let's get started.

In sum, the issues with dropdowns impact three overlapping areas of user experience and site performance: usability, accessibility, and search engine optimization. I will consider these each in turn.

1. Usability Issues

Broken Expectations

Users Decide First, Move Second, a study conducted by the leading usability group User Interface Engineering, revealed that users typically decide where to click before moving their cursor; they scan the page, access their options, and go. Since the information in dropdown menus is hidden from view, it can't help users in this process. Instead dropdowns force users to reassess their choices while their cursor remains hovered a link or group of links. As the UIE study showed, people have greater success finding what they're looking for on sites that don't include dropdowns:

Theoretically, these elements [dropdown menus] should conserve space without decreasing the usability of the site.... In watching users hunt for content, we've found just the opposite. Sites without these design elements did a better job of getting users to the content they sought and to valuable content they didn't previously know existed.

Too many choices

Additional choices don't make for a better user experience. In fact too many choices, particularly too many irrelevant choices, can be overwhelming. As Jeffrey Zeldman has noted: "[Dropdown menus] almost always create an inferior user experience versus drilling down through clearly labeled, intelligently organized categories."

Awkward movements

Even experienced web users with perfect motor skills can have difficulty keeping their cursor on the "active path" of dropdown menus. This problem is exacerbated when dropdowns include multiple "flyout" levels, but even the simplest menus--the kind that open down and include a single tier of choices--require a fair amount of dexterity and mouse control. Too often, dropdown menus can seem like elements more appropriate to a computer game than a website.

2. Accessibility Issues

Javascript dependence

Nearly all dropdown menus require Javascript, and many are entirely Javascript-dependant in that nothing whatsoever appears when users turn off Javascript in their browsers, or use devices with limited, or zero, Javascript support (e.g., screenreaders, handheld devices, text-only browsers).

In fairness, several of the better menus do display first-level links in the absence of Javascript. This includes two of the more popular "accessible" dropdown menus: Suckerfish Dropdowns and the Ultimate Drop Down Menu. I write accessible in quotes because these menus are not accessible, despite their authors' claims[1]. In the absence of Javascript, neither menu displays second-level links[2], and so unless a site includes redundant sub-navigation, non-Javascript users have no way of reaching second-level pages.

Difficulty for those with limited mobility

Not all web users have perfect motor skills. For those with arthritis, Parkinsons, and other mobility limitations, dropdown menus can be difficult or impossible to use.

Screen magnification problems

Screen magnification software enlarges a specific portion of the screen at a time, making it possible for visually-impaired people with some functional vision to use a graphic browser. Unfortunately, dropdown menus pose serious problems for these users. Russ Weakly: "When the screen is magnified extensively, dropdown items can sometimes disappear off screen. In some cases, it is impossible to navigate to the dropdown items, as moving the visible screen area deactivates the dropdown."

3. Search Engine Optimization Issues

Since nearly all dropdown menus rely on Javascript, and since links in Javascript are unreadable by search engines, the absence of Javascript can prevent an entire site from being crawled. When search is king, this is like being banished from the kingdom.

For what it's worth, several of the better dropdowns do present first-level links for indexing. Also, at least one approach, MenuMachine 2 (a GoLive extension, of all things), displays a link to a site map page based on the dropdown menu links, thus providing an alternate method for both search engine crawling and site navigation.

The Good News, Such as it is: Easy Menus

I've found but one fully accessible and search-engine-friendly approach to dropdowns: Easy Menus. Although these menus utilize Javascript, they degrade gracefully in its absence, presenting the user with a nested list of navigational choices. It ain't pretty, but it works.

Of course, Easy Menus suffer the same usability problems as all dropdown menus, and so I would hold off the celebration. Nonetheless, for those who remain committed to using dropdowns, or have no choice in the matter, Easy Menus seem the best available option.

• [1] The two leading accessibility guidelines--the W3C's Web Content Accessibility Guidelines and U.S. Federal Government's Section 508 Standards--are unequivocal on this point. Section 508: "When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology." Developers can--and should--make these sites accessible by adding redundant HTML-based navigation, but the menus themselves don't provide these links.
• [2] Suckerfish menus fail in this way in Internet Explorer only.

Worldwide spam doubled in 2006, and junk mail now accounts for nearly 90% of all emails. It's enough to make a good man cry, particularly if that man works for an ISP. I've been following the latest developments with morbid fascination.

The spammers' most recent breakthrough is image spam, which is far more difficult to detect than text-based spam and also more likely to be read. In addition, these messages are much larger than text-based spam--seven times the size, on average--which is gobbling up resources. Score one for the spammers.

As bleak as this seems, the long-term picture is bleaker still. No one in the anti-spam community talks anymore about victory, or even holding the proverbial line. Although I'm no anti-spam expert, I think I know why this is. It's because the spammers are in a far better strategic position than the anti-spammers.

I think of the spammers as the equivalent of insurgents, while the companies leading the anti-spam battle constitute the empire. It's an offense versus defense thing. The empire builds ever more powerful embattlements, while the insurgents, who are few and mobile, search for new ways through. All they need is one chink, one flaw, and they're in. Strategically, they operate from a superior position. I have trouble seeing them ever defeated.

A Punishment That Fits the Crime

Although I've never one for cruel and unusual punishment, something about this situation has inspired me to new heights of vengeful fantasy. I call it Spammer Island.

Spammer Island is like the island in the movie Papillon, except all the prisoners on this island are convicted spammers. As one might imagine, the form of their imprisonment fits the nature of their crime.

It's simple, really. Each prisoner is fitted with a helmet like the helmets worn by race car drivers. These helmets cannot be removed by the wearer. When the prisoners speak, a computerized gizmo in their helmet translates their words into "spammer talk," which consists entirely of promotions for Viagra, weight loss pills, debt reduction services, and of course bogus anti-spam solutions.

The prisoners are free to wander the island and interact with their fellow spammers. They're also given food and housing and a generous stipend for living expenses. It's a decent life, really, aside from the fact that whenever they speak, or whenever they're spoken to, the output is always spammer talk.

The only people they encounter who don't wear talk this way are the prison guards, who in an extraordinary coincidence are all Nigerian businessmen needing to transfer large sums of money off the island.

The "surfing" behavior of people on the web often reminds me of those crazed drivers who weave in and out of traffic at ninety miles an hour. Something about the web inspires the sort of manic, give-me-what-I-want-now behavior commonly associated with tantrum-prone two-year-olds.

Studies have shown that we evaluate websites in a fraction of a second (see Web users judge sites in the blink of an eye). And what are we judging in that brief instant? I think it's mainly design. We're taking in the design as a whole to determine if the site "looks" right. If it does, we look further and deeper, but in that first moment, design is what matters most.

Once a site passes this initial test, I believe our evaluation criterion shifts to what I think of as usefulness. Useful sites combine valuable content with good usability. Nearly all mega-popular sites are highly useful. Design, meanwhile, is likely a distant third in determining a site's ultimate popularity. However, its primacy in the first few seconds is impossible to ignore and dangerous to underestimate.

I'm not trying to make a case for good web design, as that would be like making a case for sunshine. (Naturally, examples abound of popular sites with bad designs, but this merely proves that design is not the only thing that matters in a website, which I wouldn't think needs to be proved.) Instead my point is that good web design begins from a sophisticated understanding of the medium and the behavior of people who use it. In the present case, this means devoting careful attention to what people see when they first arrive at a site, so that their first glance is not their last.

Sounds great, right? Most developers must be doing this, right? Wrong. Few websites (one in a thousand?) meet even the lowest level of accessibility compliance (i.e., Section 508 or WCAG Priority 1). Moreover, few web developers know much about accessibility, or even care to know. There are many reasons for this--over-reliance on print-derived design practices, overuse of inaccessible technologies like Flash, poor support by application developers, and of course a fair share of ignorance and laziness--but in the end, it comes down to a vision thing.

A Web for Everyone

Few developers, when asked to describe their vision of the web, would begin, as does the W3C, with the idea of "a web for everyone." (The W3C's second long-term goal--"a web on everything," meaning on all devices, would receive little mention as well, but that's another story.) In fact, relatively few web developers think seriously about the medium at all. It's enough to deal with the problems inherent in finding clients and making those clients happy than to start worrying about pie-in-the-sky abstractions like "a web for everyone." And anyway, few clients expect their sites to be accessible (usable, perhaps, but not accessible), so why bother?

Here I have no argument--or rather, I've learned not to argue. You can't convince people to care about an abstraction. The best you can do is make a business case for what you believe. People will generally listen to business cases.

When I say "people," I mean clients. I rarely discuss accessibility with other developers, as I'm loath to tell anyone, however obliquely, how to do their job. Also, I often find such conversations depressing. Clients are one thing (why should they know anything about accessibility?), but the lack of knowledge about accessibility among developers seems almost shameful, particularly when it derives from a policy of giving clients what they want, regardless of the consequences for the website or the people using it.

Those are strong words, and to some degree they're unfair. Four years ago I was building inaccessible websites. Everyone was, pretty much. Then I read Mark Pilgrim's Dive into Accessibility, and I got religion. Now, four years later, it's a bit too easy for me to call nonbelievers heathens, or as I did above, shameless hacks. The truth is more complex.

What's needed, I think, is some old-fashioned education and leadership. However, as much as I believe in a web for everyone (as well as a web on every device), and as much as I believe that this vision would benefit everyone, including website owners, I'll never be an accessibility evangelist. What I will be, though, and what I am, is someone who builds accessible websites.

No Lid Fits Every Pot

I have a simple policy: I don't work on sites that fail to meet a minimal level of accessibility (specifically, Section 508 and WCAG Priority 1). Now, I don't expect this policy to change the world or make a difference to anyone who isn't already sold on accessibility, but it does make a difference to me, in that I get to do what I love and what I believe in doing.

It also makes for some interesting conversations with prospective clients. Most react well, particularly when told of the benefits for themselves and their visitors. However, I'm careful to avoid the hard sell, and I don't downplay the downsides.

The key moment comes when I outline what I've found to be the most common accessibility "gotchas":

• Unannounced new windows, including pop-ups
• Using color only to indicate inline links
• Poor contrast between text and background colors
• Using Javascript for core functionality (e.g., dropdown menus)

This is basically a short list of what clients can't have if they work with me. Of course it's also a list of what they shouldn't have, as I see it, but I don't expect everyone to look at it that way.

I lose--or turn down--about a quarter of all prospective clients on this basis. However, I don't really think of these as losses; they're more like poor fits. My policy helps me identify the right people to work with, and vice versa. In other words, every pot has a lid, but no lid fits every pot.

Not every web developer is in a position to turn down potential work because of a principle. However, I've learned that regardless of what people think about accessibility, they invariably respect the motivation behind the principle, which is to do the work I love.

I recommend it.