One of the things I’ve been surprised about as a designer is how easy it is to code out a reasonably simple site in a short amount of time once you have a basic understanding of HTML, CSS, and JavaScript. Troubleshooting and making it work for various browsers is another article, but putting up a basic, static website isn’t too terribly difficult.

For me the hard part is the design. There’s always something more to add, another element to experiment with, a new widget or technology to implement or a new technique to try. As web designers, part of our nature is to explore new ideas, learn new technologies and create new, improved ways of representing data.

So when I finally choose a layout, the code part seems easier than designing.  Web development can be difficult as well but at least there is a relatively clear path to follow when writing code.  It works or it doesn’t. It’s valid or it’s not.

The tough decisions about navigation, site architecture, color schemes, usability, and how best to represent your content on an aesthetically pleasing page are in the past. For arguments sake, let us assume that we have communicated – at a glance – what our site is about and it is time to start writing the HTML/CSS and editing the PHP template files.

Two things slow me down right away.

1. In the past, I started from scratch – meaning, I wanted to be a purist and write every line of code, not only is this unnecessary but it wastes valuable time, for you and your clients.

2. Next, I would make sure everything was pixel perfect by scribbling down some of the exact measurements from the Photoshop layout but no more!

Instead of slicing up a Photoshop file as we have in the past or even taking measurements, there is a much easier way to get that pixel perfect design you spent hours perfecting.

A few weeks ago I was building Photoshop comps for a new landing page when I realized I could use the entire comp as a background image and then code on top of the image. The technique is very similar to that of using tracing paper in your high school art class.

Take a look and see how it’s done:

First you need to have a mock up created and ready to roll out to your new page. For this example, I’ll use a basic page from an older project.

Simply use Photoshop to save your file for web and devices once you’ve prepared a standard 960px width file (or choose your own width). I generally start with 960px.

File > Save for Web and Devices

Now set up a basic HTML file and place an inline style tag on the body. Normally, we wouldn’t want to use inline style but because we plan to remove it once we have our framework in place, it should be fine for now.

And that’s all there is to it!

You can see what the final web page should look like as it sits in the background which makes writing the content code on top of the image much easier and allows you to line things up pretty precisely.

As an added bonus, you can quickly delete the inline style and see what your page looks like as you build it. This has generally helped increase my time building HTML layouts and definitely improves the accuracy of the design/code.

Ah, codecs! What fun.

I didn’t really understand codecs until I started creating a video archive for Vuze downloads. At the time, I was building a home theater PC and quickly found that some of the various .mkv, mp4, and wav files would only play on specific players, like VLC for example.

So what does this have to do with web design? Well, the same principle applies when thinking about music only this time we (the designer, developer) is responsible for making the “browser” seamlessly support audio, regardless of which browser your visitors are using.

Ever wonder why you can’t play iTunes downloads on your MP3 player? It’s because they come encoded in some weird, proprietary format called ACC – which you can change by the way.

Flash has long been the standard for encoding video and audio files on the web, so much so, that it’s become somewhat of a standard. In fact, the debate as to whether we should use flash or HTML5 to support video and audio rages on still.

Recently, some big names dropped flash support in favor of HTML5 so if it’s good enough for Google and CNN, it’s good enough for me – and having never been a big fan of the Flash platform to begin with, I thought I’d dig in.

Alright then.

One of the first things to watch out for is which browser is going to support the HTML5 < audio > tag and furthermore which formats are supported by each browser. Currently, most modern browsers, including Mozilla’s FireFox (3.5+), Apple’s Safari (4+), and Google’s Chrome (3) all support the HTML5 standard for encoding those MP3 files but they seem to prefer different formats for encoding.

For example, FireFox has codecs that support OGG and WAV files while Chrome and Safari both support MP3. This makes our job a little more challenging because we want to make sure we have fall backs in place so that ANY browser, including the IE zombies, can listen to the audio file.

The website HTML5doctor.com has a great approach we’ll follow for getting this to work just right. Chris Coyier also has an example of how to set up a pretty slick WordPress customization for pulling the data (legally) and dynamically such that it pulls meta data information like album cover images, song titles, and artist.

Not only does Chris show us how to set this up, but he creates a custom field in the back end of WP so you can set it up and hand it off to a client with the full expectation that they will be able to manage their own music library.

We’re going to do both but first we will set up a quick HTML5 test to see which method we like best or if there’s some combination of both that works even better. Stay tuned!