As with many great discussions at the moment, an innocent tweet about Codekit compiling slowly on a project (not a question, just one of those tweets we all fire into the ether every day) led to an awful lot of replies along these lines:

“Grunt can take care of compiling for you”

“Don’t like Grunt, check out Gulp, it looks awesome”

“Use X/Y/Z other tech”

Someone even kindly suggested a fix which was nice.

However, this led me onto thinking about my workflow and how it fits in with a bewildering range of modern tools and scripts.

I often feel like I’m not at the cutting edge anymore but to be honest, I look at the output of the design community through my Twitter feed and I often don’t see a great deal of end result I can’t already achieve with my slightly old-fashioned approach.

However, I’m not a complete Luddite and I do like to look at new ways of making my life easier so here we are. An overview of my workflow and that of our small 4 man team at Offroadcode and I welcome any and all suggestions on areas or technologies you feel might make not only my life easier but that of our team because I work as a small part of a process, not just a standalone designer/developer.

What is my job?

Day to day, I design and build the HTML/CSS (Sass) for the sites we as a company work with. Sometimes, they’re built from scratch and I have total control of structure, look and feel, sometimes we’re part of a larger project and I’m supplied with designs and have to make the HTML work in a way I’d perhaps have done differently.

Step 1 – Initial setup

From a build point of view, my process hasn’t changed that much over the years. I begin each project with my own basic “starter kit” that just has some fundamentals and my preferred folder set up along with my initial sass files. Once I’ve pulled that down from our Kiln (Mercurial) repo I just start writing my HTML/SCSS/CSS for the design I’m working on.

Our project folder structure typically looks like this:

We work exclusively with Umbraco so our local and staging environments are IIS/Windows based and each time I begin a new project I do a couple of simple setup steps in IIS which bind a local url (for example clientname.james.offroadcode.local) which means I can easily access the site on any device locally and the rest of the guys can also access my dev build if needed. Additionally, everyone else in the team has their own url they can set up to point to their local build so we can all see a particular build at any point before it’s all committed.

Can this be improved? Currently I pull down a simple repo with all my folders and files set up, and one of the boys in the team installs a fresh cut of Umbraco (also in repo so pulled down) when required. IIS is set up with a few simple steps I’ve been taught to copy parrot style. Is there a better way to do this? (let me know in the comments)

Aside – File management & mixed O/S teams

I’m the only one in an office of 4 where I’m on a Mac (I’m a fancy designer right ..) and the other guys are on Windows. I moved to Mac a year ago after being a happy, lifelong Windows user. I felt I was missing out on a large number of web design/developer apps that were being built only for Macs. I actually don’t really use any so that went well.

However, one of the reasons for mentioning this is that our current file storage setup is based around us using Kiln/Mercurial version control rather than something like Git. We tried hosting all my work files on OSX but no matter what version control software I used, the differences between Mac and Windows file management meant that things like line spacing and tabbing were different and therefore showed up as an actual difference when you push and pulled files rendering version checking almost useless.

Now, all my work is stored on Windows in Parallels and I commit there using Tortoise the same as the rest of the team. It’s not ideal but it’s consistent with the teams workflow and means I don’t get wacky Mac file formatting issues being committed ruining any chances of using version control properly because it would show entire files as being changed.

Can this be improved? I’d love to hear from any other mixed OS teams using version control and different file systems how they do it. (let me know in the comments)

Step 2 – Writing team friendly code

I’ve worked for years using Dreamweaver to write my code. I think people often misunderstood it and thought everyone used it as a wysiwyg editor but fundamentally I’ve always used it as a powerful text editor. I’ve loved its autocompleting of HTML and CSS. It’s superior to other editors I’ve used and I’ve always stuck with it but since the switch to Adobe CC, the site manager file tree simply won’t load my files from my Parallels Windows so I can’t use it and have switched to Sublime Text.

I’m planning on making more of Sublime and Zen coding as I use it more.

As a fairly recent convert to Sass, I’m totally sold, Sass has won CSS. Like most people, I’m totally on board with it and I wish I’d started sooner. There are still those who feel it over-complicates CSS, they’re wrong.

It’s the author that over-complicates CSS, not the tool. I’ve made one site where I got into all sorts of over nesting of selectors and it’s probably a mistake everyone has to make once to learn but I’m getting there. The range of tools and potential power it’s got is amazing.

I monitor my Sass using the Codekit app. I like an easy life so I’ve yet to reach the point where I’ve convinced myself to memorise a load of commands to type out in Terminal. Andy Clarke it seems has roughly the same outlook there. I guess there’s going to be a point where I can make some good gains using Terminal but right now, I’m not really sure how typing a load of jibber jabber into a command line is easier than clicking a button with an icon.

Can this be improved? The rest of the team also like Sass so we’re figuring out our own coding style and rules while trying to keep it simple, there are compiling tools for Windows and Mac so I think to be honest this part is fairly straightforward and it’s primarily me who will oversee and write any project CSS both in static and Umbraco build stages so as long as we’re referencing the compiled output I’m not sure what needs doing here. (let me know in the comments if there’s a better way here)

Static output and tools

As I don’t do any of the Umbraco integration on our projects, instead I build the front ends of the site and one of the other guys take my templates from the repo and start integrating them into Umbraco and once they’re in there, I’m happy working in the Umbraco environment making HTML markup changes in Umbraco so effectively once I’ve done a static build and it’s been put into the Umbraco templates, I don’t really touch it again as there’s no need because we can all work in the Umbraco build.

I’ve recently tried Hammer App for compiling HTML/CSS because it also offers a really neat feature of HTML includes which make creating static builds a lot easier but as I mentioned above, we’re a cross OS team so I’m the only one who can use it which means if I do have to pass some HTML to one of the guys (they are all able to write HTML & CSS to a degree) there’s an issue of what to actually give them.

The pre-compiled files they won’t be able to use because they need Hammer to make the includes work? The compiled “build” folder? Neither are really practical so I’ll probably revisit that tool in the future.

Can this be improved? My main concern with Hammer for Mac is the “for Mac” bit. I build something using includes etc and then compile the optimised output to a generated build folder but my concern is that should someone else on Windows need to make a change to the HTML/CSS prototypes/files, they won’t be able to compile it. (Would love to hear from mixed OS teams here).

Optimisation

I run my Sass through Codekit’s standard optimisation/compressed output when it compiles and I let Codekit do its thing on images and scripts too and we wrote our own asset compressor for Umbraco ages ago to take care of concatenation of files etc on final Umbraco builds. In addition to that, we also ported the Adaptive Images script to Umbraco to give us basic responsive images on sites we use it on.

I’ll often just drop my static images folder contents (png’s anyway) into ImageOptim to make sure stuff is shrunk down as a last little check before I commit a static build.

Can this be improved? I’ve seen several mentions of automating stuff through Grunt or other tasks but I’ve so far been put off by my lack of knowledge and ability to read the often terse, dry or incomplete developer focused docs for these things so haven’t used them yet and while I’m not exactly challenged by this simple workflow step, maybe it can be done better?.

Step 3 – Umbraco integration

I guess the logical step here would be for me to do more Umbraco integration and setup and it’s certainly something that’s on the radar but for the time being, there is a little silo based workflow going on here but I feel this is fine because we’re small enough that the roles are for the most part quite specific but dovetail nicely in terms of design, setup and development but I’d be interested to see how other Umbraco shops go from design -> prototyping HTML -> Umbraco build.

Typically we get a lot of projects where our Umbraco expertise is what won us the job and therefore while I have a basic grasp of Umbraco setup, doctypes and templates, the level of complexity involved in building custom CMS’s means that while I’m usually involved in planning the site architecture, I typically steer clear of the setup.

Step 4 – Testing

I’ve written about the pain of testing in the past and how I think it’s possible responsive design will be 99.9% typography in the end like so many small companies, we try to test as best we can with virtual machines and a modest range of phones and a couple of iPads.

Device labs are often the preserve of large agencies and while many of them offer access to fellow designers, there aren’t that many out there still so we aim to test what we can as much as we can but the reality is that there are so many devices out there and so many breakpoints in designs these days you’re not going to be able to test even close to every configuration of a website so we try to keep code and design simple, support the good browsers and make content accessible to older ones as best we can.

Can this be improved?  What do you do? Are you fighting the impossible fight and spending a small fortune on handsets and devices or do you have a clever way to test quickly and simply across a wide range of viewing devices and browsers?

Step 5 – Staging & Deployment

I’ve noticed tools like Hammer or Mixture offer a local and staging url, we don’t need this. We have a deployment process shared across the team and managed internally. Local dev is done as I outlined earlier in this post and then we push to specific staging and then live urls and to be honest, I just commit my work to the repo like a good designer and we test on staging before anything goes to a final live url.

Project management with Trello

We are completely sold on Trello, we’ve had Basecamp forced upon us in previous client projects and I was shocked at how bad it was considering its reputation. As such, we work in a Kanban style using Trello and our boards often broadly reflect our workflow above. If you’ve not flown off just yet, you can also read about how we work with Trello later.

Make me more efficient!

Thanks for hanging around, I’ve tried to cover a bit about my day to day work and how that fits in with the work the rest of the Offroadcode guys do. I’m aware some of the things I do might be improved and if you can suggest a different way to do something, I’d absolutely love to hear your thoughts and suggestions based on what you’ve read about some of the constraints in our working environment. Please try to consider what I’ve spent a while writing when you suggest tools or processes though.

James Young

Written by James Young

I'm always looking for interesting work opportunities, if you'd like to work together please get in touch.

Join me on Twitter & Dribbble.