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

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.

No one wants to "submit" to you.

The default label for a button on a form is, and always has been, "Submit." That's a terrible label.

Submit doesn't provide me any context beyond the obvious: my information will be delivered somewhere, probably to someone. Even worse is the meaning of the word submit. It literally means "to give over or yield to the power or authority of another." Unless our form is for a rehab program, our user probably doesn't want to submit to anything.

Let's consider our newsletter. To sign up, you provide your email address and click a button. Since a button provides an action, it would make sense to use a verb. "Subscribe" would work. Subscribing is what we're directly doing. That's called a task-based label. It describes what we're doing, not why we're doing it.

To reinforce why we're subscribing, I could use a benefits-based label. Since I want you to sign up for this newsletter to improve your website, I could use "Improve My Website" as a button label. The label describes the benefit provided by clicking it, instead of the literal action. This might improve conversions. Benefits-based labels are uniquely suited to conversion forms because they remind the user why they're signing up.

A benefit based label isn't always appropriate. Consider the button to to post a comment on a photo. For that, we should just stick to the task. "Post Comment" would be best. Task-based labels are always better than "Submit," but benefits-based labels may increase conversions. The only thing left to do is split-test it and see.

You have a great idea for a smartphone app. What is the process of putting it together? How tech savvy do you have to be? And then what is the process to get the app into an app store?

Aside from client work, we've got several successful websites we've built independently. One of them, and my favorite, is Rainy Cafe. Lifehacker described it as, "a simple little site that plays both the bustle of a coffee shop and the soothing sound of gradually increasing rainfall." It's essentially a white noise generator. The site gets around 100K visitors per month. We decided it would be the perfect site to translate in to an iOS app.


Rainy Cafe: Ambient Noise to Soothe and Boost Productivity

We applied for a developer account with Apple. To prove the legitimacy of a business, Apple requires a Dunn & Bradstreet number. This was our first stumbling block. It takes weeks to be verified by Dunn & Bradstreet, and strangely, it takes weeks for Dunn & Bradstreet to update their database with Apple. Just getting our developer account took over a month because of that. During that time, we put the app together. We used PhoneGap to translate our existing web assets in to an iPhone app. It was remarkably simple, within an hour we had a working app. That's spectacular since we previously had no iOS development experience. Adding native features like background audio support wasn't difficult either. PhoneGap community's support is excellent. Any question we had during development was just a Google search away.

Once we had the app built, we needed to test it. While we knew the app worked in Apple's software simulator, we wanted to be certain it worked in the real world. That's where having an approved Apple developer account becomes a necessity. To load an app on to an actual iOS device, the device must first be "provisioned" by Apple. It's a straight forward process of getting the device recognized by Apple, "code signing" the test app, and then launching the app on your own device. It's necessary, not just important, to test on real devices. The iOS simulator is great but imperfect. We have noticed some idiosyncrasies between the two environments.

Since our app was simple, we didn't have any snags when testing, and we're ready to submit our app for review by Apple. It took five days for them to our review app… and reject it. 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."

Since our app had exactly the right amount of features to accomplish its goal, we opted to suspend development on the iOS app. When we can think of new features that make sense, then we'll resume development. Even if we did, it would still be a gamble. What if we add a sleep timer? Or a new selection of sounds? Would those things really add to the user experience? Would Apple approve the app then? Ultimately, Apple is the gatekeeper to an app's success, which makes building an app a gamble.

It can be tough, frustrating, and even painful to get approval for a design from a client.

Anyone can offer an opinion on design, so they do. Worse yet, these opinions are based on an individual's own subjective taste, not a professional designer's years of objective experience in solving complex problems. Instead of butting heads with the client, try some of the strategies we use at Ethercycle to work collaboratively with our clients.

Become the Expert

I always backup my reasoning with multiple articles explaining why something may not be a good idea, and then offer an alternative.

For example, if a client wanted to include background music on a brochure site, I would write to them,

It's not in your best interest to include audio on the website, users find it a turn-off.

Here are some articles on the subject:
  1. Regrettable User Experience: website background music
  2. Stack Overflow: Web Usability - Background Music
Including a video, if you have one, is a better way to engage users with both sound and audio.

It's easy to say that the designer is wrong, but it's hard to say the design community is wrong. No one likes being wrong, so it's important to offer a better alternative to the client. Part of being professional is remaining positive and helpful.

Reframe their Problem

What if instead of sending a design mock-up, you sent a business solution? The difference is in how you present your design. This framing starts from the time the client initially contacts us.

    I ask…
  1. "Why are you looking to start this project?" to reveal their motivation.
  2. "What problem are you trying to solve?" to determine their pain.
  3. "How will you know if this project is successful?" to find what metrics are important.

While this is very helpful in crafting a brief, it lets me tie my designs back to their initial reasons for hiring us. When I send the design to the client, I present in the context of why they hired us. I might say something like, "Based on what you told us in the kick-off meeting, this is a great solution to X problem and will increase Y metric." For a particularly complex design, I will submit it with annotations describing the reasoning behind certain elements and how they'll help accomplish goals.

Borrow Credibility

Sometimes just telling a client that in your expert opinion a solution will work isn't good enough. That's when it's time to borrow credibility through design testing. If you're truly convinced of your design, test it.Send a survey to between 25 and 100 people and ask their opinion.

  1. Present two designs and ask which is better and why.
  2. Test usability by asking users where they think they should click to perform a task.
  3. You can even test subjective issues by asking how a design makes them feel.

Ideally your test-takers should be in your target demographic, and preferably existing customers. As a business owner, your client can't argue with 50 of their own customers.

It Gets Better

Always remember that the client hired you because they think that you can help them better their business. All relationships take time to develop. In time, you'll go from hired hands to trusted advisor.

Approvly

To help other designers get through design approval process and get feedback better from clients we put together Approvly, an app that takes the pain out of approval. Head over to approvly.com, and enter your email address to follow the progress and be the first to hear when Approvly launches.