SparkPost: Dynamic subject lines in email templates

Moving to Mandrill to SparkPost this week? (A lot of us are thanks to this.)

In Mandrill (and possibly other transactional email services) we can use the API to send emails using templates. We send a bunch of information including recipients, content, metadata, and subject, ad we let ‘er fly. Boom, done.

For the most part, I’ve found SparkPost to be pretty similar, except on one point: subject lines. Specifically for emails sent using templates. When you’re using a template, several options in your API call get ignored, including “subject”. It defaults to whatever you set when you created the template in the SparkPost UI. (It’s a required field.)

Worse, at the time of this writing anyway, there’s no clear way to fix it. It isn’t specifically covered in the documentation, and the support center answers (such as this one) are… not ideally helpful, we’ll say that.

But there’s good news. After losing a fair number of hours and hitpoints on this, I found out that…

It’s actually pretty simple

With SparkPost templates, we fill our template placeholders (name, content, etc) with curly-bracketed variables such as:

{{name}}

(Details on this are in their docs over here.) That’s what we put in the template to specify that this is the placeholder for the ‘name’ field in the substitutionData JSON array we’re sending them. Here’s a simple example of that part of our API call: (Also called a “transmission” in SparkPost world.)

{
   "substitutionData": {
      "name": "Tester Gunderson",
      "astrological_sign": "Quagmire",
      "favorite_color": "blue",
      "main_email_body": "This message is to transactionally confirm that your sign is 'Quagmire' (we didn't know that was a thing) and your favorite color is 'blue'."	
   }
}

Throw a key in there for Subject

With the rest of your substitutionData, add your desired subject line:

"subject": "We're sending this email to blue-loving Quagmires"

And then in the SparkPost UI, edit your template and change the subject line to {{subject}}. (Or whatever you want to name the variable.)

Setting dynamic subject lines in SparkPost templates
Yep. You can put variables in there.

 

And you’re done.

Well, maybe. It depends on your use case. If you want to add dynamic variables to the subject line (like the recipient’s first name) you have another battle ahead of you. Hopefully, as more of us former Mandrill users migrate over certain questions can be answered more clearly than they are as of the time I’m writing this. (April 19 2016)

Good luck out there!

PHP: Convert US State names to their abbreviations and vice-versa

Sometimes you need to convert state names to their abbreviations. Sometimes you need to convert state abbreviations to their names.

Well, this function does both.

Give it a valid state abbreviation, and it’ll give you the name. Give it a name, and it’ll give you the abbreviation. (e.g. OR -> Oregon, Oregon -> OR). Enjoy! Hope it helps.

/* -----------------------------------
 * CONVERT STATE NAMES!
 * Goes both ways. e.g.
 * $name = 'Orgegon' -> returns "OR"
 * $name = 'OR' -> returns "Oregon"
 * ----------------------------------- */
function convertState($name) {
   $states = array(
      array('name'=>'Alabama', 'abbr'=>'AL'),
      array('name'=>'Alaska', 'abbr'=>'AK'),
      array('name'=>'Arizona', 'abbr'=>'AZ'),
      array('name'=>'Arkansas', 'abbr'=>'AR'),
      array('name'=>'California', 'abbr'=>'CA'),
      array('name'=>'Colorado', 'abbr'=>'CO'),
      array('name'=>'Connecticut', 'abbr'=>'CT'),
      array('name'=>'Delaware', 'abbr'=>'DE'),
      array('name'=>'Florida', 'abbr'=>'FL'),
      array('name'=>'Georgia', 'abbr'=>'GA'),
      array('name'=>'Hawaii', 'abbr'=>'HI'),
      array('name'=>'Idaho', 'abbr'=>'ID'),
      array('name'=>'Illinois', 'abbr'=>'IL'),
      array('name'=>'Indiana', 'abbr'=>'IN'),
      array('name'=>'Iowa', 'abbr'=>'IA'),
      array('name'=>'Kansas', 'abbr'=>'KS'),
      array('name'=>'Kentucky', 'abbr'=>'KY'),
      array('name'=>'Louisiana', 'abbr'=>'LA'),
      array('name'=>'Maine', 'abbr'=>'ME'),
      array('name'=>'Maryland', 'abbr'=>'MD'),
      array('name'=>'Massachusetts', 'abbr'=>'MA'),
      array('name'=>'Michigan', 'abbr'=>'MI'),
      array('name'=>'Minnesota', 'abbr'=>'MN'),
      array('name'=>'Mississippi', 'abbr'=>'MS'),
      array('name'=>'Missouri', 'abbr'=>'MO'),
      array('name'=>'Montana', 'abbr'=>'MT'),
      array('name'=>'Nebraska', 'abbr'=>'NE'),
      array('name'=>'Nevada', 'abbr'=>'NV'),
      array('name'=>'New Hampshire', 'abbr'=>'NH'),
      array('name'=>'New Jersey', 'abbr'=>'NJ'),
      array('name'=>'New Mexico', 'abbr'=>'NM'),
      array('name'=>'New York', 'abbr'=>'NY'),
      array('name'=>'North Carolina', 'abbr'=>'NC'),
      array('name'=>'North Dakota', 'abbr'=>'ND'),
      array('name'=>'Ohio', 'abbr'=>'OH'),
      array('name'=>'Oklahoma', 'abbr'=>'OK'),
      array('name'=>'Oregon', 'abbr'=>'OR'),
      array('name'=>'Pennsylvania', 'abbr'=>'PA'),
      array('name'=>'Rhode Island', 'abbr'=>'RI'),
      array('name'=>'South Carolina', 'abbr'=>'SC'),
      array('name'=>'South Dakota', 'abbr'=>'SD'),
      array('name'=>'Tennessee', 'abbr'=>'TN'),
      array('name'=>'Texas', 'abbr'=>'TX'),
      array('name'=>'Utah', 'abbr'=>'UT'),
      array('name'=>'Vermont', 'abbr'=>'VT'),
      array('name'=>'Virginia', 'abbr'=>'VA'),
      array('name'=>'Washington', 'abbr'=>'WA'),
      array('name'=>'West Virginia', 'abbr'=>'WV'),
      array('name'=>'Wisconsin', 'abbr'=>'WI'),
      array('name'=>'Wyoming', 'abbr'=>'WY'),
      array('name'=>'Virgin Islands', 'abbr'=>'V.I.'),
      array('name'=>'Guam', 'abbr'=>'GU'),
      array('name'=>'Puerto Rico', 'abbr'=>'PR')
   );

   $return = false;   
   $strlen = strlen($name);

   foreach ($states as $state) :
      if ($strlen < 2) {
         return false;
      } else if ($strlen == 2) {
         if (strtolower($state['abbr']) == strtolower($name)) {
            $return = $state['name'];
            break;
         }   
      } else {
         if (strtolower($state['name']) == strtolower($name)) {
            $return = strtoupper($state['abbr']);
            break;
         }         
      }
   endforeach;
   
   return $return;
} // end function convertState()

Is your Bootstrap X-Editable plugin stuck in 2015?

At least as of version 1.5.1, the awesome Vitalets Bootstrap X-Editable plugin has a maximum date for its datepickers of 2015. Why? I dunno. I just work here. But it’s a simple fix.

After you get things rolling by applying the plugin to whatever element, like so…

$('#thing').editable();

Change the default maximum year thusly:

$.fn.combodate.defaults.maxYear = 2531;

Or whatever year you want.

While you’re there, you could also change the minimum date to something a little more recent than 1970:

$.fn.combodate.defaults.minYear = 2010;

Flash/Pulse a Border Color With jQuery

Sometimes you want to draw a user’s attention to a certain input or element. One way to do that is to flash or pulse the element. But when you google this, most examples involve flashing the whole background, such as with jQuery UI’s highlight effect. But if you’re like me—as I definitely am— you might think that is a little much. Or maybe it just doesn’t fit well with your design. Here’s how to do it without extra plugins. (Well, except for jQuery UI. Need that.)

There are a lot of methods out there suggested for doing this, such as using .addClass() with a CSS transition, and then removing it with .removeClass(). Problem: It’s difficult and convoluted to get the timing right. If you chain them right together, you get no effect. And they don’t use .delay(), as that only works on animations.

Well, maybe you could do it using .queue()? Yeah, but that’s inelegant to say the least. So let’s use .animate().

$('input').animate({borderColor:'red'});

Well, okay. Now our input is red. How do we change it back?

$('input')
  .animate({borderColor:'red'}, 400)
  .delay(400)
  .animate({borderColor:'black'}, 1000);

The “400” you see on the first animate() defines how long the animation will last, in this case 400 milliseconds or 0.4 seconds. The delay() is important because without it, your second animation will begin immediately after the first. Meaning that the moment the border color begins to change, it will also begin to change back. Kind of worthless. Make sure your delay is at least as long as your initial animation. If you want the border color to remain changed for longer, make the delay longer.

I like to make the return animation slower than the first one. It just looks smoother.

Okay, but you’ve probably noticed a problem already. The return animation makes the inputs’ borders black. What if you don’t want black? Well, you could specify exactly what color it should be based on your CSS, but then if you ever change the style, you’ll have to change your code too. Inelegant.

So maybe you’re thinking, “Hey, self. What if we use jQuery to get the color before we change it?” Nice idea, you. Seems easy.

var original_color = $("input").css("border-color");

Yeah, that won’t work. Why? Because it seems easy, that’s why. (And other technical reasons blah blah moving on.) But the good news is you’re close. Turns out you’ve got to specify which part of the border you want to get the color from. Again, because your original idea would simply be too easy.

var original_color = $("input").css("border-left-color");

I chose left here, but you could use right or top or whatever, since we’re assuming here that your border is the same color on all side. (If not, then I’m sorry. May the fates be kind to you.)

So, let’s put it all together:

var original_color = $('input').css('border-left-color');

$('input')
  .animate({borderColor:'red'}, 400, 'linear')
  .delay(400)
  .animate({borderColor:original_color}, 2800, 'easeOutCirc');

Now you’re asking what’s up with the ‘linear’ and ‘easeOutCirc’. Those are easings, which let you finagle with, well, the easing. Look here for examples. I’ve found that sometimes the return trip can get a little jerky, especially toward the end. So I chose ‘easeOutCirc’, which has the slowest tail end. Feel free to tinker with the timings and easings as you see fit.

Bonus!

I’m highly caffeinated at the moment, so let’s get ambitious. What if we have a whole bunch of inputs we want to highlight? In my case, this would be on a form which I’m validating using jQuery Validation. To make things easy on the user—since it’s bad enough they’re having to deal with validation errors in the first place—I like to scroll to the first error on the form, in case it’s off screen. (Otherwise the form will just sit there dumbly and not give any indication why it’s not submitting. #rage)

$('html, body')
  .animate({scrollTop: $(".error:first")
  .offset().top -90}, 500);

Here’s where we go very slightly crazy with the animations. Assuming there are more than one, let’s get all smooth ‘n smarmy and highlight them one after another:

// Get the border color of the first input on the form.
// (.form-control is a class I have on all inputs.)
var original_color = $("#process-form .form-control:first").css("border-left-color");

// Init this
offset = 0;

// For each one pulse the border color, with the duration extending for each
$('.form-control').each(function(){
  $(this)
    .animate({borderColor:'red'}, 400+offset, 'linear')
    .delay(400+offset)
    .animate({borderColor:original_color}, 2800+offset, 'easeOutCirc');

  // Set this to whatever interval you want between input animations.
  // 200 works pretty well.
  offset = offset + 200;
});

Have fun out there, campers.

 

Getting CORS to work with Apache

Ok, if you’re reading this, I’m assuming you know what CORS means, so I won’t tell you that it stands for Cross Origin Resource Sharing. Or maybe I just told you.

Anyway, you want to enable it on your Apache server. Maybe, like me, you’re building an API-based web app. So you need some JavaScript to pull data from a remote server. (Or even, like in my case, a different subdomain on the same physical server.) It’s easy in Node.js, so it shouldn’t be hard in Apache.

So you google “apache enable cors”. The first result is from enable-cors.org. Wow, how relevant! Sounds so legit! And it says all you have to do is throw this somewhere:

Header set Access-Control-Allow-Origin "*"

So you put it in your httpd.conf file or .htaccess and boom done.

GOIN HOME EARLY TONIGHT!

Except then you try it. And Firebug is all like: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://buckle.up.because.thisll.suck.org. This can be fixed by moving the resource to the same domain or enabling CORS.

And Chrome says: XMLHttpRequest cannot load https://howdare.youthink.thiswouldbe.easy. No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘https://pain.and.suffering.org’ is therefore not allowed access.

But… you did it right. You did just what it said you should do. You even googled it a few more times and everyone says the same thing—Just that one line of code and you’re supposed to be done! You’re supposed to be kicking back with some nachos now! Chrome even says that the header is there, for crying out loud!

Screenshot from Chrome

 

Yeah, no.

Disappointed face
Turns out there’s a friggin metric crapton more to it than that. I won’t go into all the details here, but there’s a lot. What I will do is give you a list of quick and dirty things to try.

Enable mod_headers

There’s a module that allows Apache to add things to the request/response headers. You’ll need that. Near the top-ish of your httpd.conf file, look for…

#LoadModule headers_module modules/mod_headers.so

(Mine was on line 115 in my Apache 2.4 setup.)

If yours has that hash/number/octothorpe/# sign at the beginning, remove it. As with any change to httpd.conf, you’ll need to restart Apache for this to take effect.

“Always”

First, just putting that line in my .htaccess wasn’t working. I could see the header in Chrome (image above) but it was apparently being ignored for who-the-crap-knows-why. Adding “always” before “set” seemed to correct this. I also moved it from my .htaccess to httpd.conf, just above my virtual hosts section.

Header always set Access-Control-Allow-Origin "*"

You’ll also see different versions of this out there in the wild, some where it says to use header set, and others where it says header add. Both will work, but set is safer in this case because add can add multiple headers, which according to the CORS documentation is not allowed.

Depending on your situation, that might do it for you. But probably not. So…

Other headers

Try adding these three:

Header always set Access-Control-Max-Age "1000"
Header always set Access-Control-Allow-Headers "X-Requested-With, Content-Type, Origin, Authorization, Accept, Client-Security-Token, Accept-Encoding"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"

The 2nd one determines what headers your requesting server (the one trying to make the remote call) is allowed to send. You likely don’t need all of those, but I left in a bunch for the sake of example.

The 3rd one is super important. It determines what kind of RESTful calls your app is allowed to make. Again, you probably don’t need all of them. In fact, if you’re only doing GET requests, that’s the only one you need. But if you want to POST, then you need OPTIONS, too. More on that below.

GET works, but POST doesn’t: welcome to “preflights”

I won’t go into details here, but I will say that POSTs are different than GETs beyond the obvious ways. One way being that with POST, browsers do what’s called a “preflight” check. Basically, it sends a request before your actual POST, checking to see if it’s allowed to do what it’s trying to.

This was very confusing at first, because my GET calls were working fine, but when I tried to do a POST call, Chrome: 1. showed it as an OPTIONS request; and 2. returned 404 (or 400 or 403 or 500). The heck?

What’s happening is likely that your server is trying to respond to that OPTIONS preflight as a normal page fetch. It’s literally trying to serve up a page. In my case, the URL in question was a PHP script that was expected POST data and wasn’t getting it, so it barfed up a 403 error.

Making PHP return 200 OK for preflights

I had to make a script called blank.php, which contained nothing but some ranty comments. Then, over in .htaccess, I added this:

RewriteEngine On                  
RewriteCond %{REQUEST_METHOD} OPTIONS 
RewriteRule ^(.*)$ blank.php [QSA,L]

What’s happening here is, whenever an OPTIONS request comes in (line 2), it redirects any-and-all of them to blank.php (line 3). Blank.php is, well, blank, so it returns an HTTP status of 200 OK. The browser then takes this as a successful attempt to discover what its OPTIONS are, learns from the other headers (Allow-Origin, Allow-Headers, Allow-Methods) that it’s allowed to do a POST, and then finally sends the real, actual, honest POST that you’ve been trying to get it to do this entire freakin’ time.

Hope that helped

Depending on your environment/needs, that might not be the end for you. If so, you have my sympathy. Either way, I hope this at least gets you a few steps closer.

Using Sandbox always fails with PayPal IPN (PHP)

Warning: This post assumes you’re already familiar with IPN, and you’re just having trouble, well, troubleshooting it.

Okay, let’s say you’re setting yourself up with PayPal IPN. You’ve set up a PHP listener not unlike this one. You’re all set, right? Ready to test it out with PayPay’s IPN Simulator! Yeah!

Except it fails. It always fails. Why?

To try and figure it out, I set up a file named paypal.txt and told my listener to write the results to that file. Like so:

// These two lines are just landmarks so you can see where I am:
while (!feof($fp)) {
   $response = fgets ($fp, 1024);

   // Here's the actual logging code:
   $file = 'paypal.txt';
   $current = file_get_contents($file);
   $current .= PHP_EOL."DAMN !fp";
   file_put_contents($file, $current);

Okay? And after hours of troubleshooting, this is the only thing I would get:

HTTP/1.0 400 Bad Request
Server: BigIP
Connection: close
Content-Length: 19

Invalid Host header

Nice, huh? Super helpful. Well, as it turns out, the problem is that the example code I linked to above, and variations of it I’ve found all over the webs only work for live IPN responses. Meaning anything from www.sandbox.paypal.com (like PayPal itself tells you to use) will fail. EVEN IF YOU CHANGED IT to use Sandbox like so: (This is line 15 of the above-linked example code)

$fp = fsockopen ('ssl://www.sandbox.paypal.com', 443, $errno, $errstr, 30);

The problem

As near as I can tell, the problem is that the IPN responses are being sent from paypal.com, even though you want</> to — have been told by PayPal itself — to work with sandbox.paypal.com while developing.

The fix

Here it is. See line 2.

$header = "POST /cgi-bin/webscr HTTP/1.0\r\n";
$header .= "Host: www.sandbox.paypal.com\r\n";
$header .= "Content-Type: application/x-www-form-urlencoded\r\n";
$header .= "Content-Length: " . strlen($postback) . "\r\n\r\n";

Done. Problem should be solved. To sum up, it’s not enough simply to set the fsockopen() to use sandbox.paypal.com, you also need to set the response header correctly, or there will be a mismatch and sad, sad failure.

Hope this helps!

Access a mapped network drive from PHP (Windows)

So you want to do something on a mapped network drive using PHP, but it simply tells you it couldn’t find the drive? Worry not.

What’s going wrong?

The problem is that PHP runs under the SYSTEM account, and the SYSTEM account can’t access mapped drives.

The solution:

So, we need to map the drive from the SYSTEM account. You can do this from your PHP script, but if you need persistent access, we can do this:

1. Download the Windows Sysinternals Suite and unzip it somewhere you can easily get to from a command prompt.

2. Open an elevated command prompt. (Search for “cmd.exe” from the Start ball, and then right-click on it, and choose Run as Administrator.)

3. Using the command prompt, navigate to wherever you put Sysinternals.

4. Elevate yourself once again to supreme power by using:

psexec -i -s cmd.exe

A new command prompt window will open that is running as the SYSTEM account.

5. Map the network drive:

net use z: \\[IP ADDRESS HERE]\[FOLDER NAME HERE] /persistent:yes

And you’re done!

Warnings:

You can only remove this mapping the same way you created it, from the SYSTEM account. If you need to remove it, follow steps 1 -4 but change the command on step 5 to: net use z: /delete.

The newly created mapped drive will now appear for ALL users of this system but they will see it displayed as “Disconnected Network Drive (W:)”. Don’t worry though! It displays as disconnected, but will work for any user.

What your visitors are (and aren’t) looking at

Eye-tracking studies can be extremely revealing about how your users are using your site in the real world. Unfortunately, they can also be extremely expensive and time-consuming to conduct. Not everyone in charge of a website has those kind of resources.

Luckily for us, some organizations have made some of their information public, giving us the chance to do gain some insights about our own pages.

A special camera tracks a user’s eyes as she navigates a travel website.

Also, Prioritizing Web Usability by Hoa Loranger and Jakob Nielsen provides a good amount of data gathered from eye-tracking studies, among a plethora of other valuable insights.

Splash pages and Flash intros—just don’t.

Not that many people are even doing this these days, but I just ran into a couple of them and suddenly feel it’s worth mentioning again. Splash pages are pure evil.

(Okay, maybe not pure evil. But some kind of evil, for sure, even if it’s just the annoying kind.)

What is a splash page, you ask? You’ve probably seen them. It’s a sort of front door to a website, and they are often made with Flash. Here’s an example:

www.takeshape.it

The splash page on www.takeshape.it, a good example of a not-quite-so-good idea. (Sorry, guys.)

Pretty, right? Well, yes. But why is it there?

The lure of a splash page is that it gives us a chance to show off. It’s like saying, “Look, we’ve made some really cool stuff in Photoshop,” or, “Check out this excellent Flash animation!” What better place to show the world what we can do than right off the bat at the front of our site, right?

Wrong. Think about other sites you’ve visited. Why did you go to that site? Probably because you wanted something—because you had a question you wanted answered, or you wanted to see someone’s artwork or photos, read some articles, or contribute to a forum or community. Maybe we’ve visited Take Shape to look at some of their fine abstract patterns.

Does a splash page help us do any of that? We want patterns, or whatever, not another reminder of where we already know we are. Splash pages usually offer no other options than to “skip intro” or “enter the site”. Isn’t that what we were already trying to do when we entered the URL or clicked on a link?

It’s the same with our visitors. They didn’t come to be wowed by a fancy introduction. They came for a reason, and they want to get to it without any unnecessary interruptions. (Especially on the 2nd, 4th, and 8th visits, if you can get them to come back at all.)
Famed web usability expert Jakob Nielsen had this to say about splash pages:

Splash pages are useless and annoying. In general, every time you see a splash page, the reaction is ‘oh no, here comes a site that will be slow and difficult to use and that doesn’t respect my time.’
Source: Readers’ Comments on the new Top-10 Design Mistakes.

Furthermore, when splash pages are made with Flash, the opportunity for frustration (and people immediately leaving your site) increases even more. There’s nothing like browsing the web late at night in the dark, or in a quiet study hall or library, and then suddenly have some designer’s favorite rap song blast through your speakers at full volume. And the potential issues go well beyond the inappropriate use of sound. Jeff Noble of the usability blog User Interface Trends makes a good point about animation:

Animation just because you can do animation, like it’s possible or whatever, is very very bad. Please stop. Visitors come to a website for information, not to learn how awesome you are in vague generalities and exploding 3d text. Kaboom!

If you know Flash, create something useful or appropriately entertaining, not a fancy splash page that will only drive users away. We make websites because we want visitors. Don’t give them reasons to avoid your site.

Oh, but there’s always a catch.

That said, there are very rare and specific cases in which a splash page can be useful. If you think you might be dealing with such a case, I’d recommend checking out these two posts by Smashing Magazine, Splash Pages: Do We Really Need Them? and Exploring Design: Outstanding Start Pages. Also, there’s Jakob Nielsen’s dated but still fairly relevant, Flash: 99% Bad.

Web interfaces: how not to confuse your visitors away

Though it can be easy to think otherwise, web design is much more than just putting content on a site and calling it a day. And, because people interact differently with the web than with printed materials such as newspapers and magazines, we can’t treat it the same when we design for it. There are many facets to good web design, and this article is about one of the most important we need to think about when we design.

The Interface

Because the Web is so vast, it would do us well to remember Jakob’s Law. Coined by Jakob Nielsen of Web Usability fame, it states: “Users spend most of their time on other sites.” What this means is that users expect your website to work and behave in a similar way to the ones they already know.

Let me illustrate this point with a corporeal example: Imagine you borrow your friend’s car. You climb in, try to put in the key, and find that the ignition is not where you expect it to be. Instead of going in to the right of the steering wheel, you eventually discover that the key goes on the left side. You get the key in, and it doesn’t turn. After a minute of fiddling with it, you find out that it doesn’t turn clockwise, but counterclockwise—and you have to push on it first.

Well this is all pretty irritating, now isn’t it? And we’re only getting started! It turns out that the turn signal isn’t a lever on the left of the wheel, but a button on the wheel itself. The radio volume is controlled with a button on the floor by the pedals, and the windshield wipers are turned on an off from where the radio volume is supposed to be.

This is one aggravating car, isn’t it? Who designed this thing, anyway?

Someone who hasn’t driven many cars, apparently. You see, car designers might think the key would work better in a different place, but they never move it because no one would buy their annoying, hard-to-use cars if they did.

Don’t Confuse Your Visitors Away

You can probably see where I’m going with this. Though not quite to the same extent, websites are similar to our car. Think about some of the sites you’ve visited recently. I’d be willing to bet that the site’s logo was in the top left corner, and if there was a search box, that it was somewhere near the top, or around the upper-right corner. And I’ll bet colored words were almost exclusively links. I don’t even have to know what sites you go to to guess that because websites, like cars, have developed certain trends. Like it or hate it, if your search box is on the left side of the page at the bottom of the screen, a lot of people won’t even know you have one, and they’ll wonder why you don’t. After all, as Vitaly Friedman of Smashing Magazine says in this post, “if users can’t use a feature, it might as well not exist.”

Now imagine that your friend’s weird car is just one of millions you could be driving instead. (You’re famous, because everyone in the state wants to lend you their car.) Do you think you’d spend more than a few seconds in our problematic example one, or would you be in another, more familiar one in seconds? Like you and your millions of cars, web users have millions of websites they could be at instead of yours, and they won’t stand much in the way of confusing or frustrating layouts.

Try to avoid being the cause of this situation. And don’t try this at home.

One way to avoid this making your site awkward or hard to use is to take some time to look at other sites with similar messages to yours. Because you’ll likely share your audience with those sites, you can get an idea of how your specific user base might expect your site to work. Additionally, you can do a search for web usability statistics and get some cold, hard numbers, like those from the W3Counter and Internet Usage World Stats. For instance, you would not want to design your site to be wider than 1440 pixels, because only a small percentage of web users have screens that wide according to global web statistics:

Global screen resolution statisticsSource: www.w3counter.com/globalstats.php. Accessed Nov 17, 2009

But, you’re saying I can’t be creative!

No I’m not. Really, you can. You have a lot more flexibility than our awkward car above—the Internet isn’t nearly that fixed in its ways. And remember, we’re talking about how your site works, not how it looks. Cars all pretty much work the same, but they come in all kinds of different shapes, sizes, styles, and colors. And so should websites. The Internet would be a pretty boring place otherwise.

For more info on what makes for a usable layout, and some excellent dos and don’ts, check out 10 Principles of Effective Web Design, and Research-Based Web Design & Usability Guidelines.