<script type="text/javascript">
  $(function() {
    $("a:not([href^='http://www.phototimes.net'])").attr("target", "_blank").addClass("external-link");
  });
</script>

This little snippet does several things all at once. The first thing it does is find all links whose href  attribute does not begin with http://www.phototimes.net.  This selects links that are off-domain, which we want to open in a new window.  The next part sets the target attribute of the link to _blank, so that it will open in a new window, and the third part adds the external-link class to the tag.  The external-link class allows us to style the link differently that other links on the site, like adding one of those nifty little arrows that visually indicate that the link is offsite, and was popularized by Wikipedia.  jQuery, I think I love you.

Oh, and for those within driving distance, Justin tells me he’s going to be starting to offer photography classes in Wichita, so those with the desire can begin to learn photography from someone that’s actually in the industry and taking awesome photos every day.   Be sure to take an in-depth look at his portfolio pages while you’re at his site!

I tend to use several techniques to keep my overall document size reasonable:

1. Compressed Images – JPEG (for complex images) between 40 and 65 percent quality, depending on where compression artifacts become too noticeable; GIF (for simple images) color palette restrictions between 8 and 128 colors, depending on where the artifacts become too noticeable. Of course I also use PNG images where a really good alpha channel is needed, but I use them sparingly, as full alpha transparencies dont compress well.
2. Minified Javascript and CSS files.  I like the YUI Compressor for this.
3. Server-side compression.   Even minified files can be squeezed even smaller with the use of server-side compression.

Server-side compression is super-simple to implement, as long as you have access to an .htaccess file or a friendly server administrator.  Here’s a syntax that works for me on a couple of servers I run (This is Apache specific, for other servers find a mod_deflate equivalent):

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
AddOutputFilterByType DEFLATE text/x-js application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

The two AddOutputFilterByType lines can be combined into one or split up however you choose if you’re a stickler for keeping your text in configuration files readable. This can be inserted in the virtualhost definition or in your .htaccess file.  Using this alone, I consistently shave off between 60 and 100 kilobytes off my download size.  Enjoy!

My favorite template currently is a 12 column, 900 pixel wide layout. You of course don’t have to use 12 tiny columns, but it gives you the flexibility to split those columns into various configurations, like three 300px columns; one 600px column and one 300px column; one 375px column, one 225px column, and two 150px columns; a page broken into three vertical sections, each having a different column configuration… whatever! This one has 6px gutters and guides for the edges and middle of the gutter, depending on how you want to line things up.

Se here you go, my 900px 12-column Photoshop Grid Template. Enjoy!

Yeah, I know. Seriously. After all this time when CSS has (finally!) become a standard method of layout. When people are finally getting the whole point of separation of concerns when it comes to content versus layout, and browsers are getting good support, and for the most part I can get my designs to be pretty consistent across browsers without much effort as long as I closely follow the rules… I’m having to retrofit my CSS-based layout into a table-based design.

As I was coming to grips with this I did a sanity check by looking through the last few months of my inbox and looking at the adverts (non-spam) I’d recieved. A quick look at the source confirmed that they were ALL table-based. Dang. And now the fellow across the hall is making fun of me. He knows how dirty I feel for having to violate standards to make something layout correctly. Oh well. For what it’s worth, I did stumble across the Email Standards Project, which is what confirmed that Outlook 2007 and Gmail (!) both lack support for floating/clearing. So, have fun dusting off the table-based design knowledge you’d accumulated and then happily buried when CSS finally became a viable alternative.

First I had to decide how the site should be physically structured. Would a subdomain-per-language be good, e.g, en.mysite.com for English, es.mysite.com for Spanish, and ru.mysite.com for Russian? Or would it be better to use directories for the distinction, e.g. www.mysite.com/en/ for English, etc? If I chose the subdomain route it would be easy to build sitemap.xml files for each domain. But how would I structure the sitemap.xml if using directories?

I chose to use directories for a couple of reasons. One, I knew that google treats subdomains as entirely separate websites. I didn’t wish to do this because semantically these were three translations of the same website, and I felt that should be reflected in their structure. Two, I didn’t want to have multiple datasets when dealing with analytics, either multple log files to analyze or one of the myriad javascript-based analytics packages. Yes, I’m fully aware that there are ways to glom datasets together, or otherwise make analytics packages aware of your structure… this was just pure personal preference.

OK, so now I have my structure in place, how do I build the sitemap.xml? I don’t want one huge monolithic file for the entire site. Even though at current count there are only around 100 html files per translation (not huge by any means, but also not insignificant), I would just personally prefer to keep the translations in their own separate sitemap.xml files. Those of you familiar with sitemaps will have been shouting at your monitors by now “Use a sitemap index, dork!”, and you’d be right. I just wasn’t sure that Google would support this. Google didn’t seem to mention it anywhere in their webmaster tools documentation (though I could have just missed it).

I’m happy to report that Google does in fact support sitemap indexes, and I’m fairly certain that MSN and Yahoo! do as well. So, simply build yourself a sitemap_index.xml (the filename is arbitrary) file that looks like this:

<?xml version="1.0" encoding="UTF-8"?>
     <sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
     <sitemap>
          <loc>http://www.mysite.com/sitemap_en.xml</loc>
     </sitemap>
     <sitemap>
          <loc>http://www.mysite.com/sitemap_es.xml</loc>
     </sitemap>
     <sitemap>
          <loc>http://www.mysite.com/sitemap_ru.xml</loc>
     </sitemap>
</sitemapindex>

Then build your individual sitemap files as you normally would. You can find the full specifications for sitemaps at sitemaps.org, and a nifty utility to help you automatically build sitemap files at the google-sitemap_gen project. Dont forget to include your new sitemap index file in your robots.txt file! Enjoy.

UPDATED: December 8, 2009 – Corrected my syntax on the xml. D’oh!

Let’s talk about physical dimensions first. An email client is designed and navigated differently from a browser. The “chrome” on most modern email clients include not only the toolbars and menus, but an entire left-hand column used to navigate mail boxes and other features. This column alone consumes a couple hundred pixels of horizontal real estate. Vertically, the space is usually split in half so that the user can see a list of messages in the upper half and then view them in the lower. When all this is taken into account while still designing for a small common screen resolution on the order of 1024×768, you wind up with a usable viewport more in the neighborhood of 650×300.

Now take into consideration that the (X)HTML rendering capabilities of email clients are not necessarily on par with fully-featured browsers. For security and speed, most email clients have a very limited set of supported browser features. Most won’t display flash, few support animated gifs, and JavaScript support is typically limited. Thanks to spam, you’re not even guaranteed any images will display at all, but fortunately, most of the time plain-jane images will load just fine.

So here are a few guidelines for (X)HTML-formatted documents delivered via email:

1. Keep your overall width between 600 and 650 px. This should be old-hat to those of us that were designing around the turn of the century, and will be an interesting excercise to the neophytes.
2. Remember that the “fold” on an email client is likely going to be around 250-300 pixels down the page, so make sure you have something above the fold that will make your user want to scroll.
3. Keep it simple. Avoid JavaScript. Use well-supported (X)HTML and (inline or on-page) CSS only to aid your presentation.
4. Keep it standards compliant. The same “failing gracefully” principals apply to email that apply to browsers. However, there’s the additional “standard” of making sure you have a text-only version of your email ready to fly along with the HTML-formatted version.

Finally, a note about content. A rule that used to apply to physical newsletters is also applicable to email newsletters. A friend of mine used to tell me that “A good newsletter can be read between the mailbox and the trashcan”. Be brief in your email content and link frequently to expanded content on your website. Enjoy!

UPDATE! I’ve discovered that Outlook 2007 and Google’s Gmail don’t support floating and clearing. This makes design using pure XHTML and CSS very painful. I’ve got new post about this issue and my dismay here.

Frankly, it never even occurred to me to check different versions of Firefox. I know this seems obvious, but Firefox had always been so consistent for me, I hadn’t thought about checking multiple versions. So I loaded up FF2 on my Windows VM (I normally run a Mac with windows installed in a Virtual Machine to do cross-browser testing and other windows-specific things), and sure enough, we have a whole lot of nastiness. Dang. So now I rework all my z-index values like I should have in the first place, and all is good again.

This has been a public service announcement. Carry on.

1. We’re doing ourselves a favor, as this is the correct way to do things.
2. We’re doing our server a favor, as this means less disk access.
3. And most importantly, we’re doing our visitors a favor, because they’re no longer losing a few seconds while our server tries to find first a file and then a directory. And in this industry, you and I both know that a few seconds is a long, long time.

Now this article was written in 2002 when most everyone was still on dialup and servers were much slower in general. So number 3 doesn’t really apply anymore. In this article, I’m going to give you a new reason number 3, and go into more detail on number 1, to help you understand why this is the correct way to do things.

Let’s first look at what happens when your browser requests a normal page. We’ll mimic a simple browser session using telnet from the command line.

We first initiate the telnet session with the server:

Aletheia:~ wknechtel$ telnet www.sheldoncomics.com 80

When we’re connected the server, it responds thus:

Trying 208.122.50.173...
Connected to sheldoncomics.com.
Escape character is '^]'.

We then issue the commands that a browser would. This is a little simplistic as a browser would also tell the server what sorts of encodings and content it can accept, but this will work:

GET / HTTP/1.1
Host: www.sheldoncomics.com

The request we’ve just issued breaks down like this: GET is the request method. There are other request methods, you’re probably most familiar with GET and POST. Then we specify the URI we’re requesting. In this case we use a slash to indicate that we’re looking for the top-most root document the server will hand us. Then We specify the protocol of HTTP, version 1.1.

HTTP 1.1 introduced the concept of the virtual host, so that you could tie more than one domain to an IP address. This brings us to the second line. Since we’re using HTTP/1.1, we have to declare which host we’re looking for as well. Make sure you hit enter twice after this, so that the server knows you’re done entering the request. Now the server will begin to deliver your request:

HTTP/1.1 200 OK
Date: Sat, 15 Nov 2008 16:32:37 GMT
Server: Apache/2.2.10 (Unix)
Vary: Host
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked

1e4c

<!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
...
</html>

0

Connection closed by foreign host.

We’re only really interested in the first few lines, called the header, and I’ve snipped out the vast majority of the returned HTML. Specifically we look at that “200 OK”. The 200 Status code tells us that everything is good-to-go: the document we’ve requested exists, we have permission to view it, and nothing went wrong internally while trying to retrieve it. It then tells us other things like the type of transmission to expect, how large the document is, and the version of the server software.

Now let’s look at what happens when we request a directory without a trailing slash:

GET /store HTTP/1.1
Host: www.sheldoncomics.com

This time the response from the server is different:

HTTP/1.1 302 Found
Date: Sat, 15 Nov 2008 18:40:42 GMT
Server: Apache/2.2.10 (Unix)
Location: http://www.sheldoncomics.com/store/
Content-Length: 334
Content-Type: text/html; charset=iso-8859-1
...

This is what’s known as a 302 redirect. It was originally implemented so that webmasters could change the structure of their website and redirect visitors from the old (perhaps bookmarked) page, to the new page that has the same content. This allows you to actually change the names of your HTML files or change out whatever dynamic back-end your using and not worry about visitors getting lost during changes.

Now with our URI request that didn’t include a trailing slash, Apache couldn’t find what we were looking for, because it though we were requesting a file, not a directory. So trying to be nice before issuing a status of 404 (Not Found), Apache figured it would check – just in case – to see if there’s a directory matching the requested URI. Since there was in this case, it issued a 302 automatically to let us know the location of what we were really looking for. This is the reason it gave us a “Location: ” header entry in its response to us.

So why use trailing slashes when linking to directories? Because the 302 is not supposed to compensate for an incorrectly structured link. This, thinking back to reason number 1 above, is the correct way to do it. Also, thinking back to number 2 above, it keeps apache from doing unnecessary work. And now for your new reason number 3: its good for the search engines. Proper structure – everything from proper and valid (X)HTML to correctly formed links – is more easily digestible by the search engine’s spiders. If you want good placement, you should make it as easy as possible for the engines to crawl your site. A trailing slash may seem insignificant, but it’s easy to do and makes web servers happy :-) Enjoy!

Oh, by the way, you really should check out http://www.sheldoncomics.com/, a masterfully written and illustrated comic about a boy genius, his talking duck, and their adventures in life; by Dave Kellett. I’ve been following this strip for about six years now, and abusively used his server in my examples for this article. Tell Dave I said hello when you stop by.