posted Nov. 30, 2008

Web design is a vested interest of mine -- it's my job and one of my favorite hobbies, and has been for years. It really warms my heart to see people I know picking it up, but I also know it's initially a very opaque subject. Where does one even get started? There's a plethora of little tricks and tips that you pick up along the way here and there, and a lot of esoteric tools involved in the process. I'd like to help the process along by throwing out some things I've picked up along the way; though bear with me as it's kind of hard to codify a bunch of things that have become like muscle memory to me now.

The First (and likely the only Unchanging) Rule

There is always someone out there who is in all likelihood more adept at what you're doing. This is actually a very good thing! It means the acquisition of these concepts is really at your fingertips, prepared for you by people who had to do it the hard way. The lion's share of what a web designer should do is to learn, and actively seek out new ways of doing things. The information is really, truly out there — it's just a matter of asking (google) the right question. Be careful not to just parrot back other's code though, comprehension is key.

Tools (and workflow!)

Terminal / bash

The one tool I use constantly — above all others combined, really — is the Terminal (or "bash", if you're feeling sassy). It is immensely powerful; it is the foundation on which a thousand other talents can be based. I started on bash by going through this tutorial that Patrick Casteel gave me a few years back. If you're running OSX, then simply opening up (it's in /Applications/Utilities, or you can hit Cmd+space, and then type "Terminal" to find it) If you're running Windows, download Cygwin.


The second most used tool is really just a subset of the first one. SSH gives you remote shell access to another server from your terminal window. It's usage is really very simple, though there are tricks like tunneling that require a little bit more studying. Primarily you'll be using this to get to the server where your webpage sits.

  • It'll look like "ssh [yourusername]", and it should prompt you for a password.
  • "scp" is like "cp"; used for copying files. However, it works over the SSH protocol, allowing you to transfer files freely between your computer and your server.
    it looks like:
    scp [file on your computer] [yourusername]
    scp [file on your computer] [yourusername] 
    and it can work both ways (so you can copy files from the server onto your local computer.) I use this all the time.

As an addendum, I don't personally use this (I think it's slow, and I prefer to shell into the computer I'm working on directly), but sshfs can mount remote filesystems locally with relatively little hassle. In practice, this means you can make a directory in your computer point at the directory structure on your server. You'll be able to access it with Finder, etc, etc.

vi / vim

VIM is my tool of choice for development. It is a "modal" editor, has a very steep learning curve, but also has a huge payoff in that it is really widespread (most computers you use will end up having some copy of vi installed), easy to develop muscle memory for, and works from the command line. You don't have to get intensely familiar with it, but getting a working knowledge of the editor will definitely save you some hassle down the line. To get started with vi, just open up a terminal and enter vimtutor <Enter>. This'll bring up the tutorial program.

Some other resources:


This is exceedingly important. There are two simple rules to follow here: keep revisions of everything you do, and make sure to keep copies of these revisions on at least two physically separate computers. Even if you are just versioning by copying the file and adding a date to the end of the end of it after every edit, that is better than nothing. However, ideally you will use a tool like Mercurial or Git. Of the two, I'm tending towards Git now, but I think Mercurial has an easier to understand interface. Using version control usually necessitates a passing knowledge of the command line, but the ease they lend to the two aforementioned rules of versioning is totally worth it.


Don't develop on your live server. It's a bad idea. Ideally, you set up a webserver on your computer, or install a prebuilt virtual machine webserver on your computer. If nothing else, set up a subdomain and use your favorite version control program to update the live site when your changes on the development subdomain are ready. Setting up an environment seems scary, but I'm totally willing to help out — it's usually a much simpler process than one would think initially. OSX computers actually have this built in (though this can be a double edged sword). Just enable "Web Sharing", and put your files in /Library/WebServer/Documents. Easy peasy. It takes a little bit more work to start adding other functionality, but some googling will definitely help out with that. One note for OSX -- you should install the development tools off of your OSX install disc. This will allow you to compile applications, which is kind of a necessity for getting Mercurial or Git. Also very good: macports! This lets you get UNIX programs installed on your mac quickly and (relatively) painlessly.


"This is my browser. There are many others like it, but this one is mine." This should be your primary development browser -- though don't mistake "primary" for "only". The number one reason you should use it? Firebug.Firebug lets you dynamically pick apart websites, change CSS rules, run arbitrary javascript, monitor your pages load times (through YSlow), and a number of other cool little tricks. The other plugin I like to keep handy is the Web Developer Toolbar.

Other Browsers

Ideally, you have virtual machines running with installs of whatever two major operating systems you are not currently running — in my case, I have a OSX macbook with an Ubuntu (linux) vm, and a Windows XP vm. On the windows XP side, I installed (in this order — this is important!) the Internet Explorer 8 beta and then MultipleIES. This lets you test everything from Internet Explorer 3.0 up.

When developing, you should test early and often. Here are the targets I test before I push code live:

  • Internet Explorer 5.5
  • Internet Explorer 6
  • Internet Explorer 7 and 8
  • Firefox 3
  • Safari
  • and sometimes Opera

This is important: each browser renders things differently, and as a designer it is your job to ensure that the end user isn't left out in the cold because of their apparent fear of upgrading browsers.

I think that might be it for now. I'll expand on this in the near future! If you've got questions please feel free to ask!

  • josh said: "Ideally, you set up a webserver on your computer, or install a prebuilt virtual machine webserver on your computer. If nothing else, set up a subdomain and use your favorite version control program to update the live site when your changes on the development subdomain are ready." i do lots of php/mysql work and XAMPP is by far the fastest, easiest way to get apache, mysql, and php running on a windows machine, just in case anyone wanted another option for a local webserver.

  • chris d said: @josh cool, thanks for the suggestion! I don't have a lot of experience web developing on windows (the last programming I did on windows was some C++ stuff using visual studio four or five years ago). I'll definitely add XAMPP to this post! I tend to think getting a virtual machine up and running is a valuable experience -- if nothing else it gives you the experience of administrating a tiny linux install, which you'll probably run into at some point while developing. I might make another post related to that -- with some info on setting up dyndns to get a static URL onto that box.