A Developer’s Workflow
There’s been a lot of chatter on Twitter lately about workflows – I love seeing how everyone works and am amazed at how we all do the same thing, but in a million different ways. I enjoy making small evolutions of workflow to increase time, but I admit I’m also not the best when it comes to trying out radically different things. I’m pretty happy with how productive my setup is, even now that half of my equipment (and my external monitor) is sitting back in London.
Right now, I’m stuck working only on my 13″ Air, with Apple keyboard and magic mouse, setup on my dad’s desk, but I’ve remained pretty efficient despite not having my second monitor. The biggest issue I’ve had is forgetting that my windows are now on the same desktop.
The path I take towards finishing up a site depends on if it’s a static or WordPress based site. So here’s how I go from a designer’s PSD to a finish product for both routes.
I’ve recently had a ton of static sites and had to change the way I worked. Most of these sites aren’t allowed to use PHP, so for awhile I was stuck with having to repeat headers and footers and the likes since I didn’t have includes. But now, I use Hammer, which allows me to use “includes” so I can create templates and save myself a headache when the designer changes their mind halfway through 30 pages. Here’s my typical workflow:
- Before I do anything, I set up my site area. I make a copy of my basic site template, Super Hijinksified (there’s now an Hammer HTML version, too), into my client folder. My clients folder is arranged by year, and then by client name and further on in (because all of my clients are agencies) the project or site name.
- My IDE of choice is the lovely Coda 2. I keep it on a light theme for my terrible eyesight, and the built-in FTP, made from Transmit, is awesome. I also love their completion and other quick tools. I also use Emmett to speed up flat HTML coding.
- If the site is meant for WordPress, I go ahead and set up FTP in Coda to my test server, where all of my client sites live until finalized. I prefer working on a test server versus a local server for WordPress because it’s less work moving things and allows me to download plugins, use font-face, etc etc, which you can’t do on local servers. If I’m working with another developer on the project, this is also where I setup Github, otherwise I go without.
- I study the PSD and figure out what I’m going to do – how is this site going to be coded?
- I then start coding it section by section, from top to bottom, far to close. Meaning I start with the main background, any containers, then the header, nav, hero, etc etc. I get assets from the PSD using the select and crop tools (not the slice tool)
- If the site is going to be responsive, I also work on it section by section. So once I finish with the header, I then start resizing the browser to find the breakpoints. I don’t start device testing until the page has been completely coded.
- After the page is coded – it’s time for testing. I first make sure there are no HTML or JS errors and it passes validation. Then it’s on to browser testing (currently only the latest versions of all browsers, plus IE 8-9), and then on to device testing. I test on an iPad and an iPhone in real life and simulators for Android.
I’m running OS 10.8.3 on the Macbook Air with 4GB of ram as my one and only computer. My current applications of choice to use while working are:
- Tweetdeck - light version
- VMWare Fusion 2 – for IE and Windows testing
- Photoshop CS6 subscription version
- Coda 2 w/ Emmett plugin
- Hammer for Mac
- Github for Mac
I try to keep my development process as simple as possible. I don’t like using and switching between a ton of different apps, as I feel that only adds layers of complications to the process. Also, you’ll probably notice that I don’t use any sort of preprocessor (even though Hammer has that ability). I prefer to keep right next to my code. Simplicity is key to everything I do and has served me very well over the several long years I’ve been on the web.