Skip to: Navigation | Content | Sidebar | Footer

Full Archives

Random Absurdities

January 31

A few recent occurrences that have me wondering about the general sanity of publishing online.

Observed on this site in the last 7 days (pardon my obfuscation):

Exhibit A—a prolonged attempt to flood the search form with keywords. A sequential, alphabetical list of nouns and verbs relating to common household items, popular pop culture references, and common sp@mmer standbys.

Exhibit B—continued daily sp@m attempts on the Zen Garden submission form. P0ker, dru9s, and making quick bucks are as popular as ever.

Exhibit C—(and this has to be my favourite) A semi-Godwinian comment on a past entry comparing lack of sensitivity in the design world, to a recent prison scandal on foreign soil. A Google search into this site based on the name of said prison, by another individual. A new and politically-oriented, borderline racist comment added, with an unspecified threat toward the site-owner (um, me) if said comment were deleted. (Comment was deleted). A crap-flood of vengeful, taunting remarks over the course of a few minutes.

The first, I don't understand. The second tells me sp@mmers are a) stupid, and b) attack anything that submits. The third tells me that com-ments on a personal site are no place for free speech.

But hey, silver lining: com-ment and refe-rrer sp@m is at an all-time low. And the less you talk about it, and the more you protect yourself, the more chance you have of similar luck.

Update: The Register published an interview with a link sp@mmer today. Worth a read. (via)

Permalink › | 30 comments

It's a Wrap.

January 27
Thanks a million.

2,474 files and 1,882,514,611 bytes being burned to DVD as I type. Word came in on Tuesday: it's off to the printer. The Zen of CSS Design has left the building.

When can you have it? When it ships. As far as I know, the current date on Amazon is the date: February 18th. I'll let you know as soon as my box of copies shows up. Shouldn't be long now.

Thanks for waiting. Thanks for your interest. And if you haven't clicked through on the above image, take a second to do so now.

Permalink › | no comments

Redundancy vs. Dependency

January 20

When coding larger sites, the CSS cascade is both friend and foe. The choice is yours: redundancy, or dependency?

CSS forces you to make a choice in your coding techniques, a choice that becomes more obvious the larger a site grows. As the amount of variance between different templates increases, you can go in one of two directions: you can either code for redundancy, or code for dependency.

I'll give you some examples to illustrate what I'm talking about. First, redundancy. You've just created a series of forms across three pages. Each form has a couple of fields in common with the other forms, that you'd like to present in a similar way. The redundant method of coding each is to copy and paste the CSS, changing only the selector. For example:

.checkout #loginForm {margin: 5px; color: #333;}
.entrypage #loginForm {margin: 5px; color: #333;}
.cms #loginForm {margin: 5px; color: #333;}

Or slightly less redundant, the selectors can be combined with commas:

.checkout #loginForm,
 .entrypage #loginForm,
 .cms #loginForm {margin: 5px; color: #333;}

In the interest of code optimization, it can be even further condensed of course. You can style #loginForm generically, no matter what its parent might be:

#loginForm {margin: 5px; color: #333;}

Now, what's happening here is that there's an assumption driving the coding decision: all instances of #loginForm should have a 5 pixel margin, and be coloured dark grey. What if the form on the site's entry page needs a slightly different margin to adjust for other surrounding elements? You'd have to rely on the cascade to pick up the initial styling, then call it out separately:

#loginForm {margin: 5px; color: #333;}
.entrypage #loginForm {margin: 2px 10px;}

At this point, the instance of #loginForm showing up on .entrypage is picking up the color value from the previous style rule, and now we're moving firmly into the territory of the previously mentioned dependency. The second rule is relying on part of the styling of the first, so if you remove or modify the first, you change the formatting of the element in question.

It's relatively easy to see what's happening at a glance: first, your #loginForm is generically styled. Second, the generic style is overridden with a followup rule in certain instances. Easy.

But it gets more difficult if there's, say, a third dependency on a padding value picked up from a new style rule. Not to mention the difficulty added if part of the styling shows up quite a bit further down in the style sheet from the initial rule, or even in a new style sheet altogether. And if you're handing your CSS over to a client who hasn't quite grasped the concept of the cascade, they won't be able to make heads or tales of the dependencies.

To take it to an extreme, what if eight different style rules form the basis of the final style which eventually gets rendered on-screen, and changing any one of those prior rules might affect the element in question, but ripple across the site and change other elements unintentionally?

Let's analyze this a little more closely, since it's so important to understand. Say you've got the following rules combining to create the style for #loginForm on the site's entry page, as above:

#loginForm {margin: 5px; color: #333;}
.sidebar #loginForm {padding: 5px; font-size: 0.9em;}
.entrypage .sidebar #loginForm {padding-left: 0;}

The final styling for the instance of #loginForm in question would then be: a margin of 5 pixels, dark grey text, a slightly smaller font size, and 5 pixels of padding on all sides except the left, which gets no padding. So now you want to go back and change the font size to match your body text, what do you do? The natural inclination is to modify the second line:

.sidebar #loginForm {padding: 5px; font-size: 1em;}

Except oh no wait, other elements were picking up the style from that particular rule and you just changed the font size for all occurances of #loginForm that sit inside the site's sidebar, and you didn't want to do that. You're making the font size adjustment six months later though, so you don't even remember the dependency. And chances are you won't notice it immediately since you're not liable to refresh pages other than the one you're currently working on, so you just gave yourself an extra few minutes of debugging for whenever you actually spot the difference.

The easy fix, of course, is to just not modify the more general style rule and add a further override to the last line, like so:

.entrypage .sidebar #loginForm {padding-left: 0px; font-size: 1em;}

And if you follow that line of reasoning to its logical end, you're back in the redundancy camp:

.checkout #loginForm {
 margin: 5px; color: #333; font-size: 0.9em; padding: 5px;
.entrypage #loginForm {
 margin: 2px 10px; color: #333; font-size: 1em; padding: 5px;
.cms #loginForm {
 margin: 5px; color: #333; font-size: 0.9em; padding: 3px 6px;

So it turns out there's a spectrum; you can move in either direction, in varying degrees. More dependencies make for a sticky and tangled mess of logic that creates extra work when you come back to modify your creation. More redundancies are verbose and bandwidth intensive, and create extra work for the initial creation process.

I tend to favour redundancy in theory, but I code in plenty of dependencies in practice. Redundancy is easier to understand, cheap enough when the CSS is being cached properly, but inconvenient to build. Dependencies are far easier to create when coding, but during browser testing and later modifications to the style they cause no end of headaches. And when I'm working on a CSS file that I know will have to be understood by someone else, there's all the more reason to keep it simple.

Permalink › | 38 comments

Getting Unstuck

January 17

Four tips for getting yourself out of a design jam.

Your pencils are sharpened and the page is blank. You've spent the last half hour watching cars, pouring a cup of coffee, and cleaning your keyboard without a thing to show for it. You've got designer's block, my friend.

I find myself struggling to begin my creative process from time to time, and there are some tricks I've picked up along the way that actually work quite well for me. My own tricks, mind you, which may not work for you since everyone's wired differently.

Don't look at another designer's work if at all possible.

This is counter-intuitive because some will tell you that looking for inspiration is exactly what you do want to do, but here's why it doesn't work for me. Browsing for a starting point means I'm trying to find something interesting in other people's work, and when I do I can't help but get the feeling that they've done exactly what I wanted to do. If I have a site open that I really, really like as I design, there's no getting around the end product really, really looking like the original. Sure, I've added enough unique character to create an original work, and I may be the only one ever comparing the two side-by-side, but I'll always know where the inspiration came from. If it's too close to the original, it's hard to live with the result.

A recent exchange with another designer went something like this:

"I really like what you've done here. It's like you've taken the Apple aesthetic, the clean and simple look, and extended it to include the client's brand. It doesn't look like Apple, but as a designer I can see your influences."

It was meant as a compliment of course, and infuriatingly, he was dead on the mark. The site in question looks nothing like anything Apple has ever done, and is heavily branded in the client's favour, but once you have that comparison point, you know.

Throw a whole bunch of ideas on a canvas and see what sticks.

Start cruising your favourite stock provider for fresh type and photography, play around by searching for random words completely unrelated to what you're working on, and hunt through your personal collections for any source imagery that might catch your eye. Some of the most effective work I've done comes from purposely moving into new territory, and using imagery I wouldn't have found without doing some exploring.

Plan, or improvise. Either way, do your DD.

Some may be structured and have an orderly approach to the design process, starting from paper and progressing step-by-step to pixels; others might take pre-planning documents and jump immediately to their image-editor of choice. I find that different jobs require different approaches; some of them take a few sketchbook pages before I'm ready to start thinking in pixels, others will never touch the physical page.

What's more important than a planned process, however, is the due diligence (DD) that must happen before a design begins. Gathering materials like existing branding, project objectives, content, and anything else available is essential for the design process.

I've done work where the only thing to go on has been a logo and a site name. No content, no brand guidelines, absolutely nothing but an idea and a handshake. Without fail, every time projects begin this way, the end result is a) unsatisfactory, b) expensive, and c) absolutely nothing like what I started with. The latter is most disappointing, because often I wasn't able to build the site I really wanted to since the site's goals (that weren't pre-established) prevented it.

If it's not working, throw it out.

This is probably the best tip I can give you. If you have an idea that has been stuck for a while, it's a sign. The idea isn't working, or at least it's not working in its present form; ditch it. Save it first, then start a completely fresh idea.

Once you're able to divorce yourself from your ideas to the point where you can get rid of something you were initially excited about, you'll find that sometimes it takes 2, 5, or more revisions before you get the one idea that's going to work for the job at hand.

This was a tricky one for me to learn, because there are some really great concepts that have fallen by the wayside simply because I couldn't see my way through from start to finish. But once I started getting used to the idea of just trashing something that wasn't working, I found that it became much easier to design myself out of a corner. And now that I've factored the potential for multiple revisions into my usual process, I'm finding my initial success rate of hitting the right solution the first or second try is going up nicely.

Permalink › | 41 comments

Dealing with Ripoffs

January 14

At one time or another, most designers will have to deal with the realities of a creative profession: people rip you off.

Shaun Inman recently made the unpleasant discovery that someone else had re-used his design on another site. So he did something about it by making the offense public.

Reactions to Shaun's method varied, but many were willing to overlook the offense if the person in question was simply learning from Shaun's work. A typical comment in that vein:

"OK, I can understand the fury if this was on a public site (yes I know it is viewable publicly - but maybe it was his test platform?), but shouldn’t you get in contact with the dude first and see what the deal is before opening him to the anger of other developers?"

And indeed, much of the time this is all that's needed when you've found someone has used your work. In my experience—and trust me, I've had a bit with this issue—nine times out of ten, a quick email to the offender will reveal that they're simply learning by studying someone else's work, or saying they are because they got caught red-handed. (The other popular excuse to look out for is that "a contractor" or "an employee" took the work without their knowledge.)

Shaun didn't have that luxury in this case due to a broken contact form, and besides, I don't necessarily think it's bad form to not drop a warning email anyway. If the offender was simply using the work for educational purposes, then two things should have happened. First, they should have emailed the original designer as a courtesy. Second, the work should never have found its way to a public server. When neither of those things happens, the intent of the offender must be more closely scrutinized.

Any assumptions about their purposes are useless, and no matter what the state of the work is on the server when it's found, the simple fact that it has shown up elsewhere, without permission, is enough to cast considerable doubt on the individual's intentions. There's a reason the law is blind to intent. You still get traffic tickets, even if you don't know what the laws are. Actions are what counts, and when the action is posting someone else's work publicly and claiming it as one's own through copyright notices or otherwise, there's little room for interpretation.

In most cases, making the offensive site public is enough reason for anyone to quickly and proactively respond by taking it down. It doesn't involve the designer going into a back-and-forth email exchange with varying excuses from the offender, it only takes a little bit of time to write up the violation and hit that post button, and most importantly, it usually works. When someone's work is re-used, they should not be forced into an enormous time-wasting inquiry into the legitimacy of the ripoff. The burden of proof, or even the burden of educating someone, should not be on the designer.

In a perfect world, a quick email asking them to take it down would work. And again, 90% of the time it does. But I've had cases, and I kid you not, where the violator has ended up threatening me with a lawsuit. Starting off polite might be a courtesy toward the 90%, but it gets you nowhere with those who have decided your opinion doesn't count.

I've also had situations where posting a link to a clear ripoff has resulted in a very quick response which, more than anything, sounds like a desperate plea to stop the incoming email. That makes me feel bad. Most people are inherently well-intentioned, and the thought of their action (or, it is possible after all, the action of an employee or contractor that they had very little to do with) being morally questionable never crosses their mind. I'd rather not inflict that on someone when it's a genuine lack of knowledge, or a genuine mistake. But is it really my responsibility to consider someone else's feelings, when my own weren't?

This whole debate is easily avoided when a simple request for permission is all it takes. I like to think I'm quite generous when someone simply asks if they can do something. When the relationship starts with mutual respect for each other's wishes, there's no issue. If that doesn't happen though, then we have a problem.

Permalink › | 30 comments

Mapping x2

January 10

Found: a new tool enabling my continued passion for exploration.

Just before the weekend, I wrote about a Swiss mapping service called (which, incidentally, does not use XMLHttpRequest after all if you didn't catch the update).

Anyway, technology aside, a commenter pointed me in the direction of Keyhole, a service recently acquired by Google. The software looked interesting enough that I booted up my older Windows PC, signed up for a Hotmail account and registered for their free trial. I think I'm going to be spending some money here, folks.

Similar to, Keyhole is a mapping tool that allows increasing resolution of geographical areas. With a focus on North America, many regions of the world are woefully under-represented, but for those that are, it's amazingly wonderful.

You start out with a 3D view of the globe. Using controls to tilt, pan, and rotate, you can zoom in and out on any area. As you progress through the levels, an active server connection loads in more and more detailed satellite photos of the area you're viewing. For many non-populated (and non-North American) parts of the globe, the resolution is pretty low. Cities are more detailed though, and the larger cities resolve details as small as 3 inches across. Vancouver only went to 2 feet, but that was enough to pick out my building (and my car!)

More than a few hours were spent jumping back and forth between Google and Keyhole, the former to map out various landmarks and the latter to spot them from above. The Statue of Liberty, the Vatican, the Collisseum, the Eiffel Tower (and its equivalent in Las Vegas), the Empire State Building (and its equivalent in Las Vegas), and so on.

I wrote about Exploration last year, so it's no surprise Keyhole has gotten my attention. As I explored Celestia, in fact, the low-resolution surface maps of the various planets led me to wish for a program that would combine real imagery and allow you to explore the surface of the globe as easily as you could the distance between planets in Celestia; Keyhole scratches that itch nicely.

Of particular note is that Keyhole now belongs to Google. The company's site links to a FAQ that states Google has no specific plans at the moment, merely that it fits in with the overall Google goal of making the world's information accessible and usable.

Linking physical addresses to satellite photos would just be the tip of the iceberg, I'd expect Google to come up with something more creative than that, although there will be a hornet's nest of privacy questions to address. How long until we start seeing Keyhole hotspots of real-time satellite coverage of an area as it passes overhead? What about daily satellite weather reports of major cities? Or even traffic reports for that matter. This will be one to watch.

Update: Hey, these Google Ads really are targeted. I just found Image Atlas through an ad on this article. Looks to be a decent web-based equivalent to Keyhole. The resolution wasn't quite as high in Vancouver, but it looks like it may go quite a bit higher in some areas. And you can order prints of any area. Neat.

Permalink › | 17 comments


January 6

Mapping, CERN, and the possibilities that the XMLHttpRequest method is opening up for the web this year.

Simon Willison points us to a phenomenal demonstration of XMLHttpRequest usage—, an interactive map of Switzerland that pulls in satellite photos and allows you to zoom down from a high level (the entire country) so close that you can make out houses, boats, and trees.

Here's the kicker—it's DHTML. No Flash or Java is involved, it's all being pulled from the server real-time, and the interactive controls (Zoom and Pan both, try click + dragging the map) are something you'd have to be crazy to implement on dynamic data, but there it is anyway thanks to XMLHttpRequest. Google Suggest was one of the first uses of the method to cross my radar that actually did something with the technology beyond displaying test data, but Map.Search launched in October of 2004 (according to the release notes) and it blows Suggest out of the water.

From the layered data (GIF labels and JPG photography) to the staggered load as the zoom increases (where the already-loaded map resizes and interpolates to provide a rough, blurry outline of the new area as additional data loads, or vice-versa when zooming out), the almost-seamless interactivity is an impressive demonstration of what's possible with XMLHttpRequest and clever, cross-browser tested scripting.

CERN satellite photo with LEP path highlighted

Various implementation quirks highlight some limitations of the technology though: the Back button doesn't work works inconsistently in non-Mozilla browsers (like Safari or IE), and none of the individual map stages are directly linkable (the developers actually found a way around this). I have to take a screenshot to show you where I found CERN instead of linking it directly.

(Yep, that's an overhead view of the Swiss portion of CERN that I found in Map.Search. If I aligned my maps right, the red arc indicates a portion of the LEP [Large Electron Positron collidor]. Hint: It's in Genève [Geneva], Meyrin to be precise)

But what of the technology itself? If you've been following the development, you'll know that it got started as an Internet Explorer extension. Everyone else must have seen merit in a method of loading bits and pieces of new data from the server without refreshing an entire document, a method that wasn't frames/iframes anyway, and now Mozilla and Safari both support it and Opera's getting on board in a hurry. You can start playing with it today, thanks to the growing body of information documenting its usage.

It's not a part of any approved standard though, so therein lies the rub. At the moment, the technology is just a proprietary extension, though movement is underway to make it more "official": The WHAT WG has incorporated it into their Web Applications Draft. This lack of official blessing may limit its use in some people's minds, but at this point it's essentially a de facto standard anyway. Nothing else like it exists, so as far as I'm concerned it falls into that fuzzy realm where the official specs need to catch up with the technology.

Anyway, particularly nice is the fact that with or without the DHTML that makes it go, Map.Search continues to function. It's a more limited every-page-refreshes-like-MapQuest kind of functionality, but that's a totally legitimate degradation.

It's this kind of low-impact scripting that's going to take off this year, I agree with Simon on that count. The name of the game is script that enhances HTML functionality, rather than provides core functionality in a non-scripted or older and less-capable environment. HTML is a fine building block to begin with, and responsible DOM scripting is going to take it to new levels.

Update: Bernhard Seefeld, one of the developers of Map.Search, and various commenters have mentioned that XMLHttpRequest is actually only being used for ads. The mapping functionality itself is straight DHTML and image loading, so it works in even non-XMLHttpRequest-enabled browsers.

Still, it doesn’t make the site any less impressive, and it is a good example of the sort of thing one might use XMLHttpRequest for. If anything, I’m glad to discover there are other ways to pull off this kind of functionality—having a choice never hurts.

Permalink › | 33 comments

Keyboards and Chaos

January 5

Further thinking on web applications, keyboard shortcuts, and why we should expect some discussion over what defines an application.

I made an addendum to yesterday's musing on Accesskeys that I think may be more important than the original point of the article.

While I had web pages in mind while I wrote the piece, many commenters rightly pointed out that web applications have different requirements. Keyboard interaction is far more useful, and often expected when it comes to applications. The proper mechanism may not be Accesskeys, but rather some form of Javascript that taps into keyboard events—but in either case the conflicts inherent in Accesskeys apply, and a question is begged: does that actually matter?

To answer that, a more fundamental question needs to be addressed: is an application that runs inside a web browser a traditional application, or a web page? By that I mean, is it fair to say that a web application deserves to break usability standards that one would expect from a web page by virtue of being an application, or should standard browser models apply equally despite functionality? How self-contained (and unlike a browser) can a web application reasonably become?

Let's consider desktop applications. In Photoshop, when I hit Cmd + L the Levels palette pops up. In Firefox, the same key combination causes the Location bar to be selected. Since I can't think of a single useful reason to have a Levels palette in Firefox, that's fine by me. But there are cases where genuine conflicts arise: in most applications, for example, I hide the current window by hitting Cmd + H; in Photoshop, this simply hides my layer guides, and the discrepancy bugs the heck out of me.

I suppose in an ideal world, all applications would share common shortcuts and there wouldn't be any conflicts. That'll be the ideal though, since it's a big world and there are a lot of reasons why it'll never work that way, varying from different program functionality (eg. Layers vs. Location) to limited options (Cmd + Ctrl + Option + M to mark an item unread? Nobody needs those kind of finger gymnastics).

In the case of the web application, which takes precedence: a browser's defaults (and by extension, a user's configuration of the browser, or that of third-party software), or the application's built-in controls? In traditional applications, we expect deviation between applications due to the mentioned factors and more, so is it such a stretch to expect the same of web applications?

I think by now, many realize that web applications are a special instance where it may just be okay to break standard browser functionality, since things like linkable pages and the back button often don't make sense in the context of a process-based application, and doubly so in an environment where sensitive information is displayed (think banking).

But on the other side of the coin, there are also people who will adamantly oppose anything that breaks browser defaults. Or at least strongly resist them and eventually give in to reason. Or just think it's a bad idea. Well, actually, there are people all across the spectrum—just look at the CSS font sizing issue for a similar case where opinion is divided across a multitude of options.

And even if some form of a shortcut conflict management strategy were to formulate, it's impossible for the developer to know in advance precisely which keyboard shortcuts are commonly relied upon by the user; a key conflict for a Firefox user might not be a problem for an Internet Explorer user running JAWS, and vice-versa.

Some conflicts may be more harmful than others. If a user's standard shortcut for "switch to another application" is overridden to mean "close current window" in an application it potentially leads to data loss, making it a bad replacement that should be reconsidered. Alternatively, multi-modal options might be feasible that offer the user an ability to switch between application defaults, browser defaults, emulation modes, and other scenarios.

In any case where the potential for conflicts exist, however, the user must have the option of customizing or turning off keyboard shortcuts through site/application preferences. Defaults should be chosen as carefully as possible to minimize the inconvenience, but some groups of users will require further control.

It might be relevant to point out that Accesskeys in their current form are gone from the XHTML 2.0 spec, replaced last summer by something far more powerful. The access attribute removes the responsibility of managing conflicts from the designer and places it in the hands of the browser, and ultimately the user. Would be relevant, that is, if it weren't for the fact that XHTML 2.0 will continue to be an idea (at most) for a long time yet.

Inevitably though, I think this is one we're going to have to settle the long way—by experimenting and seeing what works. Ultimately I'd expect it to resolve the same way the font-sizing issue has: there will be various models to choose from, and which method you pick will be determined by your overall development philosophy.

Permalink › | 10 comments

I'm Still Off Accesskeys

January 4

A follow-up to last year's article that denounced Accesskeys.

Just over a year ago I wrote that I believed Accesskeys to be more harmful than good, supported by three articles from WATS (Is it Worth it?, More Reasons…, Accesskey Alternatives) and my own personal experience.

Since then, I've decided that while there may be no explicit accessibility benefits, perhaps Accesskeys offer something for usability. Keyboard shortcuts, for those that know how to use them, can be a tremendous incremental time-saver.

I re-enabled Accesskeys on this site a few months back, following Richard Rutter's research into Accesskey Standards. The idea was to provide quick ways of accessing common site functionality for those that are aware of them, while hopefully preventing any conflicts with existing shortcuts built in to browsers.

The verdict? I never use them, and I've received a grand total of one email about them in that time. Discoverability is yet another problem with relying on Accesskeys, but I had hoped that, at the very least, my contradictory position would have prompted a bit of discussion with the odd reader who happened to view source. No such luck.

Nothing new here, so if you're going out of your way to implement Accesskeys? Don't bother. I'm not in a hurry to take them out since they're not hurting anyone (as far as I know), but I won't be implementing them in future work.

Update: I should clarify I had web sites in mind as I wrote this, not web applications. For those who have commented that web applications are a special case and, be it through Accesskeys or custom Javascript that hooks into keyboard events or whatever else, some form of shortcut key interaction is a good thing for usability—I agree.

However, I also think that as the practice takes off, it will become necessary to do some serious testing to make sure that they help usability more than they hinder accessibility. The question of self-containedness is the issue, and how unlike a web browser you're trying to make a web browser act.

As an application becomes its own little island of individual interaction standards, it's not unreasonable to expect more leeway from a user's default setup. But there will be some fun conflicts between those who expect the user/browser is in control, and those who expect the application is in control—look at the font size issue for a minor version of what's to come.

Permalink › | 29 comments

Making a Difference

January 1

New Year's resolutions come and go. My only one this year is to assist where I can, and with your patience, I think I can pull it off.

Over the past two years, this site has seen incredible growth and support from the web design world. We're a small bunch of people given our niche focus, but the closeness and sense of community between us leads to valuable associations, friendships, and trust between people from around the world.

It's time to cash in some of that social credit for real money. For the month of January, assuming still-awaited approval from Google, I've decided to run Google's AdSense. I plan on doing so for one month from the date of implementation, and permanently removing them in February.

If you had visited this site in the past few days, you would have noticed the home page redirected to a temporary cover page asking for donations to aid the South Asia region affected by last week's devastating tsunami. This is not a local problem that affects a few people halfway around the world; this is a global catastrophe that has claimed the lives of those in dozens of countries, and ranks strongly within anyone's list of the worst disasters to befall this planet.

The two ideas are related: spurred by Andy Budd's BlogAid concept, all proceeds from AdSense will be donated to the Canadian Red Cross's relief fund. After a month, the ads will simply disappear. By saying this up front, I believe any temptation to continue running them will be dissuaded, and mezzoblue will remain ad-free (aside from the minimal returns generated by Amazon's Affiliates program used in the 'Recommending' section of this site).

That's why I'm talking about this now—so we all realize that it's just a temporary thing, to help out people that need it. And with that, welcome to 2005.

Permalink › | no comments