My front end responsive workflow

Ashim D’Silva

30th June 2013

Front end development has come a long way from the days of Photoshop comps that were sliced into little bits and sprite-sheeted for rounded corners, boxes that broke grids and drop-shadows.

CSS3 takes away some of our need for pre rendered graphics allowing a fair amount of layering to happen in browser. It has allowed us to break out of the fixation on final product and have two parallel design processes for information and wireframes for layout and page flow; and graphic design, for colours, typography and components that results in a set of reusable design components.

I’ve written about responsive pieces before (http://therandomlines.com/responsive-boxes/) and our need to break our pages into components that can be used in different contexts; you should also look at http://styletil.es/ which covers the step before that when designing the site around this principle.

This is a post around development though. Reponsive websites work great across many devices, but there is therefore an increasing need to build and test your site on those many different devices as well. The faster you can play with your build on many devices, the easier it is to give feedback to the designer, run a small usability test, and make changes to your code.

Dropbox (https://www.dropbox.com/)

This is a no brainer, but I had never imagined moving my entire live development folder to a dropbox. Now that I have, I’m freed from developing on a single machine. I work on an 11″ laptop and a 21″ desktop, and switching between them forces me to think like two distinct and extreme use cases. Dropbox syncing means I can hit save on one computer, and turn to the other to build a different piece.

Codekit (http://incident57.com/codekit/)

I started my compiled CSS learning with LESS, and @bdkjones‘ LESS App had a lot to do with me not moving to SCSS sooner. But I have since moved over and Codekit is practically magic. Codekit also compiles Kit Language (http://incident57.com/codekit/kit.php) which allows you to break your HTML structure into multiple files and use @imports and variables. Breaking your HTML into build chunks then helps your back-end dev make sense of each component and build sections even if the entire site isn’t complete. We use wordpress, and our .kit files mirror our .php files very closely so editing is much easier.

Compass (http://compass-style.org/)

This is a well-known goodie, but my move to SCSS is fairly recent so I’ve only a couple Compass builds under my belt. SCSS cleans up a tonne of nesting and repetition, and Compass then gives you tonnes of reuable patterns and CSS3 mixins for cross-browser prefixes. More maintainable code is better code. Period.
That being said, people get carried away with powerful tools and I’ve been following Jonathan Snook’s SMACSS principles (http://smacss.com/) to keep it all organised and modular. Nesting, hyper-specific selectors and well-built modules can keep your HTML clean and give you great control for extending or even altering code variables.

Foundation by Zurb (http://foundation.zurb.com/)

I’ve gone back and forth on this one, but I keep coming back to Foundation because it gets out of the way the easiest. Turning off html-classes means I only use the components I need, embedded into my own class structure and the framework does not dictate any styles or structures that need to be overwritten. My HTML remains very simple and importantly semantic – all the responsive goodness in the world is no substitute for clean semantic HTML structure that will be understood by a screen-reader or text-only browser.

Adobe Edge Inspect (http://html.adobe.com/edge/inspect/)

This used to be called Shadow and is the core of my device testing. Edge Inspect sits on all the devices that you want, and loads up the page that you’re looking at on your host. Click a link, and all your devices follow. Refresh… same thing. It also allows you to run a remote web inspector to see what your mobile devices are doing to your HTML and where your stylesheets are cascading.

Anvil (http://anvilformac.com/)

Anvil is a super simple tool that takes your local test file, wherever it is (file://localhost/Users/ash/Documents/Projects/Random%20Lines/Project/build/index.html) and turns it into a local URL that can be served up in any browser (http://project.dev). It is insanely simple; no terminal commands to run, and it just sits innocuously in your meny bar being awesome. It also means you can add it to yout TypeKit (https://typekit.com/) urls and test your fonts locally. Finally, and most importantly, it works seamlessly with xip.io (http://xip.io/) so you can serve any file on your local machine to any device on your local network – zero setup (right click your project). Edge Inspect works a charm.

The Bottom Line

I hit save in my code editor, Codekit compiles and refreshes Chrome, Edge Inspect reacts and pushes out a refresh action to all participating devices and I see the result of my change on all my devices, fully interactive. I can also easily give the URL out to anyone on my network to test.

We can dream that one day there will be a single tool designed for web developers that covers all these pieces, but with a little playing around, you can have a workflow that suits your needs. Remember, the faster you can use your website on your target devices, the better your final product will be.

more posts