The only thing that gave me pause when I suddenly found myself needing a new laptop after the death of my 15″ Macbook Pro was the fact that there was no option for a matte screen. Even though the Air’s screen is not quite as glossy as those of its peers, I hate (with the sort of burning passion reserved by developers/designers for seemingly inconsequential details such as mildly objectionable fonts and colors) glossy displays where a certain shade of red could be lord knows what wrong color depending on what angle you’re viewing at or what in the room is reflecting off your screen. Yes, we’re talking about the most minuscule of nitpicky details, and I’m a psycho, but whatever. I ams what I ams. So before I even turned my new Macbook Air on for the first time, I had installed a Power Support anti-glare film.

Over the course of the past 8-10 months or so or however long I’ve had the Air, I’ve changed the film a few times, due to OCD more than necessity. I’ve tried a bunch of less expensive films.

However, the Power Support films are the only ones that really do give you a great matte display, just like the ones Apple provides optionally for the Macbook Pros. No one even asked me, let alone paid me to tell you this. Just a public service announcement from one psychotic design geek to all others.

If you have an Air, buy a bunch while the company / product is still around.

First, a few general rules. These rules will occasionally need to be broken, but if you start off by at least trying to follow them, you’ll give yourself a more stable foundation.

• Host all of your images online (or via a CDN/S3) and use absolute URLs. Of course.
• Use old-school tables to position all of your elements. I know you spent a lot of time weaning yourself off them and mastering div tags positioned with CSS, but email clients rarely handle that stuff properly. For email, we’ve gotta take it all back to 1998.
• When you do use CSS (which is by no means recommended against), put your styles either in-line, or in the body tag. Many email clients will chuck your head tag completely.
• Set alt attributes for all of your images and links. I’ve seen email clients discard images and links that didn’t have alt attributes.
• Explicitly setting border-collapse on your tables to collapse with CSS seems to help kill certain table spacing-related quirks.
• Validate your HTML at w3.org. Get it as close to perfectly valid as possible (necessary hacks may make perfect validity impossible).

Now there’s one thing in particular that has given me an extraordinary amount of hell when doing HTML emails, and that is background images. Particularly when it comes to Outlook’s nasty habit of chucking them.

If you’re okay with having one big background image behind everything, you can apply a background image via CSS to the body tag. That actually works in Outlook. However, put your CSS inline or within the body tag (see above). I’ve also heard that you need to set repeat-y if you go this route; that setting CSS background-repeat to no-repeat will actually lose the background image completely in Outlook. Not sure if that’s always the case or what.

The holy grail here is applying background images to table cells. It doesn’t really work in Outlook. There is, however, a hack that I’ve found, and that is the main thing I wanted to share here today:

Outlook can’t (or refuses to) render basic CSS, but it does know VML (Vector Markup Language), which is what Microsoft Office uses to position elements in Word and Powerpoint. So what we’re doing is targeting Outlook specifically, and hitting it with some VML.

Here’s a trick to let you Facebook app developers do a couple of things that are typically considered impossible.

Let’s say you have a Facebook app with a Page Tab, and you want to pass it some dynamic variables from an external site or a share post. While you can link directly to a tab by appending an ?sk=app_ to the page URL (example), any custom, non-Facebook variables appended to the URL won’t be passed through to your tab page.

Another problem: Let’s say that tab page has links to sub-pages that load within the main tab iFrame (a la target=”_self”). That’s all easy enough, and pretty common. But what happens when you want to link to sub-sections of your tab page from an external site or share post?

You can’t get variables in through the “front door” so to speak, but you can pass them around the back, using what I call “the cookie trick” (or, inexplicably, “cookie party,” when it’s late in the office and we’re all loopy and/or drunk). The trick involves using a redirect that stores dynamic variables in a cookie, and then sends a user to the tab. When the tab loads, it grabs the data it needs from the cookie, and then deletes it. It’s completely transparent to the end-user.

Here’s all it takes. First, a redirect script:

Then, your main tab page just needs to check for the cookie, get what it needs, and then delete it:

Voila. You just send your vars to something like redirect.php?var=foo, and they’re slipped to your tab via the cookie.

If you want to link to a sub-page, just pass the sub-page path into your redirect.php as a variable, and then use a PHP header() redirect, or output a line of Javascript to send your users where they need to go.

Here’s an example of a deep-link to one of four mini-games in a Page Tab I built for The Black Eyed Peas Experience game: http://promethiumtorch.com/bep/redirect.php?goto=whatsyourgroove

Essentially it boils down to three steps:

1. Geocode a table of addresses to latitude and longitude coordinates using the Google Maps API (only need to do this once).
2. Geocode a query string to get its latitude and longitude coordinates.
3. Query addresses from DB by comparing latitude and longitude using the Haversine formula.
4. Bask in the warm glow of trigonometry.

Let’s start with the DB table. Since we’re going to be querying based on latitude and longitude, those two fields should be set as keys. Your MySQL server will probably cry if you don’t do this. And your queries may be noticeably slow.

Populate your table of stores, leaving the latitude and longitude fields blank. Then, you can fill those fields by looping through the table, pinging them against the Google Maps API, and popping off AJAX calls to update your DB table:

(You’ll need to include the Maps API Javascript, and jQuery will help you with the AJAX calls.)

You’ll want to query your table of stores, assembling an array of address strings, and encoding them to a JSON array or something using the row IDs as the keys. Then, loop through it:

You can update a DB, right? Your insert.php would look something like this:

If you hate Javascript (or just suck at it), you could go with this super simple PHP route to get latitude and longitude from Google (thanks Weston):

That’s step one, the hardest part, the part that only needs to be done once. Once you’ve got that groundwork done, your DB is ready for real user queries.

First, take the user’s input query and Geocode it, using either method above (Javascript or PHP), to get the latitude and longitude. Once you have those, you can do one clean MySQL query to get locations ordered by distance (replace QUERY_LAT and QUERY_LON with the latitude and longitude returned from Google, respectively):

Fuck yeah, math.