We have a new intern working with us at O3 World, John T. Bonaccorsi. He assists mainly with support tickets and random updates for clients. Yesterday he needed to update a site I built using SASS, and didn’t know where to begin. After I sat down and got him started using Scout, a SASS GUI, I also mentioned he should be utilizing OSX’s Spaces for Snow Leopard or Desktops for Lion. This in turn inspired me to create a blog post summarizing my workflow and the application stack I use on a daily basis.
Site Build Workflow
My basic application stack doesn’t really run too deep. Typically my workflow will revolve mainly around Sublime Text, Photoshop, and Chrome with Codekit in the background compiling my SASS files and injecting CSS into the browser.
When I first start a project I will look through all the comps and begin to architect common pieces and basic styling. Then I’ll grab my Site Skeleton, and delete anything that I won’t be needing. Next, I’ll set the basic text colors, heading sizes, paragraph margins, etc. After that I’ll begin to block things out into their sections.
I’ll recognize sidebars, main content areas, etc. I’m always looking for patterns in the design, to my CSS can cascade in the most efficient manner. After I get the basic structure set, I’ll code out the header and the footer completely.
Because the header and footer are universal, locking them in early is a great progress step your can show your project manager. Once you get these two elements in and functioning, the site really starts to take shape.
In order to get signoff from the client, the design team creates HTML flats for them on our dev server. The flats look a feel like a real website. They are center aligned, and are the same size they should be once coded out. I use this to click back and forth in my browser tabs to make sure my spacing, margins, etc are spot on.
After the header and footer are complete, I’ll start work on a basic interior page. Typically this page takes on a sort of “HTML style guide,” where I’ll add in blockquotes, sup tags, detail/unordered/ordered lists, buttons, forms, inline elements, headings, etc. Since the design team can’t take into account every HTML tag in their comps, I’ll work closely with the designer to make sure these basic styles match their vision for the rest of the site. In addition, this page serves as a great starting point for a new developer who needs to add some new elements to the site.
After my frontend code is hooked into the CMS, I’ll begin to test and debug. I’ll first run through IE7 and work my way up. If I find common problems between IE 7 and 8, I’ll create a lte IE 8 stylesheet that will take care of both. If not I’ll simply create a custom stylesheet for that version.
- Sublime Text 2 (Grandson of Obsidion Color Scheme)
- Photoshop (Web Workspace with Info Panel)
- Codekit or Scout (for Snow Leopard)
- Chrome / Chrome Dev Tools
- Smart SVN
I started out using Firefox and I though it was great. Firefox and Firebug were the best tools I had to use on a project. That is until I started noticing my RAM being crushed by Firefox. I’ve was told that Firebug has a memory leak, and opening Firebug window after Firebug window really bogs down your machine. Once I switched to Chrome… I never looked back… Not only are Chrome’s dev tools better than using Firebug, its also a webkit browser. Being a webkit browser means it shares the same rendering engine that both Safari and mobile Safari use… so debugging in one, is a good starting point for debugging all others. Also Paul Irish is on the Chrome Dev team… Nuff said…
Why Sublime Text 2?
Mainly? Because its super lightweight, its open source, and… its free… Before Sublime Text, I used to use Dreamweaver for its text editor. Dreamweaver was a great, but it took up a lot of system resources. Dreamweaver does many other things other than text editing, but that’s all I was using it for… Basically I was using a tool that was too big for the job I needed it for… Switching to Sublime Text 2 has lighted made my system quicker, and the startup time for the application signicantly shorter. Also, installing package control and installing new packages with a few keystrokes is awesome.
Why Codekit or Scout?
I know a lot of people are using SASS these days, and that’s great. Thankfully the same people made it possible so I don’t have to use to command line everytime I need to compile a new SCSS file… I’m completely comfortable with the command line, I use it to commit SVN repos, and push/pull github projects all the time… but using Codekit helps in more ways that just compiling SASS files. In additon to being able to save projects, and easily access archived files, Codekit also directly injects the CSS you compile into the browser, which makes it quicker to view changes. Saving a SCSS file, then using Desktops to toggle over to the browser immediately see my changes is incredible. If you’re working with a heavy system like Magento, that could take up to a minute to refresh a page, the direct CodeKit CSS inject is an invaluable resource in streamlining your process.
If you not on OSX Lion yet, or your using a PC, Scout is another option for a SASS GUI. It also watches your projects for you, but doesn’t have the other features that Codekit can offer.
At work I run OSX Lion and at home I run OSX Snow Leopard. In either case I use Spaces and Desktops respectively on both. Both machines also run duel widescreen monitors, so my workspace is multiplied several times over by both the software and hardware. I typically run 4 spaces on each, and divide each space into a particular work area.
- Email, Adium / Smart SVN, Explorer Windows for Browsing
- Sublime Text 2 / Photoshop, Codekit (running minimized)
- Chrome / Chrome Dev Tools
- Virtual Box / Windows VMs for IE testing
- Filezilla – FTP
- Spoify – Music Player
- Adium – Instant Messaging
- Zoho Bug Tracker – Debugging
- Harvest – Timesheet
- Basecamp – Project Management
- GitX – GUI for Git Repos
- MAMP – Virtual Servers and LAMP Stack
- Sequel Pro – MySQL GUI
All in all my workflow and application stack comes down to creating code in the quickest and most efficent way possible. When you start to add heavier software or less hardware, you get to a point where your waiting for things to load, or your wasting time minimizing/focusing windows etc. Making sure your workflow is as fluid as possible is the key to a quick and successful build. The longer your waiting on your system to load, or your resources to become free, the more time your wasting, and the less you can consintrate om the task at hand… which… as always… is GETTING SHIT DONE!