Luminous: Insights on websites by Michael Barrish

Death of a Standardista

I've never liked the term standardista. It's the "ista" part that bothers me. To my ear, this makes one sound like a zealot, someone whose passion is potentially blinding. Now, it's true I'm passionate about web standards. But this is only because web standards support the production of better websites. If spit and chicken wire worked as well, I'd be passionate about spit and chicken wire. If I'm any kind of "ista," I'm a qualityista.

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.

Published in WWW, Web Standards

Great Copywriting—Not for Robots

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.

Published in Content

The Death of TimesSelect and the Future of Web Advertising

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.

Published in Ads, WWW

Google Co-op Custom Search—Now With Less Evil

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.

Published in Accessibility, Luminous, Scripting, Search