Grow your store with our weekly podcasts, videos, and letters. JOIN NOW
Ethercycle logo

No idea is stupid if you can monetize it.

To explore projects outside of clients’ demands, we began a Labs initiative in March 2012. Think of it as a palate cleanser between client work. It's resulted in about ten completed projects. The formula is pretty simple. Find a problem, build a website to solve it. If it can be done in an afternoon, we don't even think about it. We just do it.

Of the ten sites we've built in the last year, the most popular are:

  1. RainyCafe
  2. CalmingManatee
  3. Is this Retina?
  4. Will there be mail today?

Getting traffic is a pretty straight forward process. Submit the site to blogs in relevant niches. In the case of RainyCafe, we submitted it as a tip to Lifehacker who posted it the next day. Once you've got a major blog exposure like that, having frictionless sharing (in the form of social media buttons) is enough to keep it going. However, this assumes the content is compelling enough to share to begin with.

Sometimes doing that much isn't even necessary. CalmingManatee was different. We tweeted it once, and about a week later it was everywhere. A million visits in the first month everywhere. We received requests for interviews from NPR, Huffington Post, and some other random blogs as a results.

The success of these afternoon projects was a pleasant surprise, and the free publicity was welcome, but what would be even better is some extra revenue. As freelancers, having recurring revenue is critical to building our business.

Our first attempt at monetization was to sell Manatee greeting cards through Zazzle. After six months, we sold so few that we couldn't meet the the threshold to get paid out. Fail.

We switched to donations. Using WePay, we allowed people to donate via three suggested donation levels. That netted about $100/mo. Better but not great. We had to reconcile dozens of micro-transactions in Quickbooks which, when you factor the time, made it a net loss. Fail again.

Then we tried making a RainyCafe iOS app that we planned to sell for $1. Apple rejected it because they found that our Rainy Cafe app provides "a very limited amount of content and a very limited set of features" specifically because it "only contains two ambient noises." Strike three.

Finally, I got off my high horse and switched to AdSense. Here's our earnings for the last 30 days:

Not only did we hit out of the park with AdSense, but it was the easiest of our four monetization attempts to implement. I wish I'd done it sooner.

Lesson learned: Simple is great. Ever since CalmingManatee, if someone in the office has an idea that can be implemented in less than an afternoon, we don't even debate it, we just implement it, put AdSense on it, and see what happens. Some work, some don't. At the very least, we always learn something from it.

Sometimes usability doesn't have to be complicated. By recognizing convention, we can build consistent and easy to use interfaces.

In every state, in every city, at every intersection across America, stop lights are red. Red means stop. But what if a city planner thought, "Hey, red is boring and I think it's hard to see. Everyone does red. Our city is new, and different, and exciting. Let's do a different color. Let's go with purple." The results are obvious. People wouldn't know what the purple light meant. The city planner might then say, "Ah, we just need to label it STOP to teach them." Now we've moved from ambiguity to cognitive dissonance. Drivers know it's a signal that says STOP, and they'd probably STOP, but they'd have to think about why its not red because they've been trained by a thousand other stop lights that red means stop and stop is red.

Consistency and convention are important elements of design. We can build on convention so that new visitors to a website can intuit how to use it and where to find what they're looking for. We can reinforce convention through consistency. By designing content templates instead of individual pages, we'll keep elements and layouts of a website similar, so that our returning visitors will recognize new content but it'll still feel familiar. Familiarity makes for happy customers.

In his blog, Eric Davis recently wrote, “Many years back I heard from somewhere that you should learn one layer above and below where you do most of your work. This was specifically for programming and implied your programming stack.”

I think the same rule can be applied to designers. For some designers, Photoshop is the primary layer of their work. But what's below it? For a web designer, HTML and CSS are below it. To be a better designer, I learned HTML and CSS. Above Photoshop is the user. Now that's a complicated layer. To understand the user, we need to study usability, accessibility, and even human psychology.

A designer that doesn't understand the layers above and below Photoshop doesn't want to be a designer, they want to be an artist. A designer who knows their stack, makes informed design choices from the start that result in sites that are go beyond aesthetics, they're functional to meet demanding goals.

OS X 10.9 Mavericks' energy-saving feature may be delaying your uploads.

After updating to OS X 10.9 Mavericks, we noticed that when saving in TextMate to a remote server with Transmit, the upload would be delayed by several seconds. This is a side effect of App Nap, a new feature suite of energy-saving policies applied by default upon applications.

Fortunately, there's an easy fix. From Finder, Get Info on Transmit.app. Check "Prevent App Nap". You're done!

What if you wanted to have greyscale images on a site that turn to color when the user hovers or taps?

Rather than load two separate images, we can apply a grayscale effect to a single color image using CSS.

img {
    filter: url("data:image/svg+xml;utf8,<svg xmlns=\'http://www.w3.org/2000/svg\'><filter id=\'grayscale\'><feColorMatrix type=\'matrix\' values=\'0.3333 0.3333 0.3333 0 0 0.3333 0.3333 0.3333 0 0 0.3333 0.3333 0.3333 0 0 0 0 0 1 0\'/></filter></svg>#grayscale"); /* Firefox 10+, Firefox on Android */    
   -webkit-filter: grayscale(100%);
   -moz-filter: grayscale(100%);
   -ms-filter: grayscale(100%);
   filter: grayscale(100%);
   filter: gray; /* IE 6-9 */
}

Then, to disable it on hover...

img:hover {
   -webkit-filter: none;
   -moz-filter: none;
   -ms-filter: none;
   filter: none;
}

It's even cross-browser compatible down to IE6.

Hosting provider Radware compared the performance of top retail websites. As web pages continue to slow down, user demands increase. 57% of users abandon pages that take longer than 3 seconds to load, and are measurably less likely to convert from browsing to buying.


Source: Radware

We love fast things. Fast cars, fast food, and especially fast websites. That's why we put together the Website Performance Checklist. It's 23 tips, tweaks, and best practices to improve the performance of any website.

For RainyCafe, we wanted toggle photo realistic toggle switches as our checkboxes. To achieve the effect we used an image sprite and some CSS trickery.

RainyCafe toggles

The magic here is that the checkbox is hidden, and the label itself is what we style. The label is an image of the switch's on/off lozenge, and the label's span is the switch's pin.

See the Pen CSS-Only Sliding Toggle Switch by Kurt Elster (@kgelster) on CodePen

Check it on CodePen.

People don't buy features, they buy benefits.

Product pages often highlight just features but that's not what sells products. Benefits appeal more directly a reader's emotions. It's especially true if that benefit is solving a problem.

Let's look at how Apple sells the A6 chip in the iPhone:

Instead of leading with an explanation of the high zoot architecture of the A6 chip, they sell the key benefit of "Long battery life." No one really cares how the A6 chip is made, but everyone can relate to the pain of a short battery life.

I find the best way to translate features into benefits is to think of what problem or pain they solve for the reader. If I was shopping for a new car, and I was worried about the price of gasoline, then I'd look for cars with good milage. I then might buy a Prius because it gets 46mpg (the benefit) but not necessarily because I want a hybrid. Hybrid drivetrains are a feature, good gas milage is the benefit. As a fuel-economy conscious consumer, I really don't care too much about how the manufacturer achieves great milage, I'm only interested that it's fuel efficient.

Are you selling features or benefits? How are you solving your consumer's pain?

Running AdSense on a responsive site doesn't have to be hard.

To promote a clean user experience, Google allows modification of the AdWords code (so long as it doesn't artificially inflate clicks or otherwise hurt the advertiser.) In the past, the only way to deal with responsive ads was to hide them in different layouts. If you have a simple single column website (like CalmingManatee) you can use the some simple in-line javascript to swap in the right format ad based on the site's width. In your AdSense dashboard, create one of each ad type, and drop in your publisher and ad IDs. It's pretty straightforward.

<script type="text/javascript"> 
adUnit   = document.getElementById("google-ads-1");
adWidth  = adUnit.offsetWidth;
google_ad_client = "YOUR_PUBLISHER_ID";
if ( adWidth >= 728 ) {
  google_ad_slot	= "YOUR_AD_ID";
  google_ad_width	= 728;
  google_ad_height 	= 90;
} else if ( adWidth >= 468 ) {
  google_ad_slot	= "YOUR_AD_ID";
  google_ad_width 	= 468;
  google_ad_height 	= 60;
} else if ( adWidth >= 336 ) {
  google_ad_slot 	= "YOUR_AD_ID";
  google_ad_width 	= 336;
  google_ad_height 	= 280;
} else if ( adWidth >= 300 ) {
  google_ad_slot 	= "YOUR_AD_ID";
  google_ad_width 	= 300;
  google_ad_height 	= 250;
} else if ( adWidth >= 250 ) {
  google_ad_slot	= "YOUR_AD_ID";
  google_ad_width 	= 250;
  google_ad_height 	= 250;
} else {
  google_ad_slot 	= "YOUR_AD_ID";
  google_ad_width 	= 200;
  google_ad_height 	= 90;
} 
</script> 
<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>

Not all browsers are made equal.


Chrome, Firefox, and Safari showing differences in font rendering.

A website is just a set of instructions describing how a site should look. It's up to the browser to render it, and every browser renders things a little differently. For example, a common problem we've run in to is that Chrome and Firefox round percentages differently which can cause responsive layouts to break at different resolutions.

When someone finds an inconsistency, we ask them to give us the details of their environment and provide a screenshot (if possible) of the issue. Providing technical details doesn't have to be intimidating, we use Support Details to quickly and accurately get a clear picture of their environment. Once we have that, we can attempt to recreate the issue and address it.