Developing in real time

Monday 16 March 2015

Automation can enhance the develop and design experience

A couple of years back, I watched a video by Bret Victor called ‘Inventing On Principle’. A lot of people did. It was an eye-opener, went viral in the tech community and was (and still is) very interesting. The first bit intrigued me. Building on the concept in Firebug of being able to modify CSS attributes and immediately see the result, he took it one step further into the code. He was able to play while developing – experimenting with different code values until he found the effect he wanted.

Bret was designing as he went along by tweaking the code and being able to see his code changes immediately. There was no need to save a file and refresh the browser – he could skip up and down, nudge objects around the screen and tweak colours, all with an immediacy that made the coding process incredibly visual.

Later in 2012, I found a Mac OS X app called CodeKit by Bryan Jones that would allow the automation of a whole host of web development tasks with minimal configuration. On top of this, CodeKit also contained a LiveReload server – whenever you hit the Save button in whichever file you were working, you could see the results immediately in the browser.

I thought CodeKit was pretty awesome and used it on a few small projects. But it wasn’t easily suited to working in teams back then and so wasn’t hugely useful in my day-to-day work. However, the fledgling Grunt community was taking off, and by mid-2013 I’d taken to using this full time.

The importance of immediate feedback

There are two things I hear from developers that bother me in my professional life. ‘It works on my machine’ – because this is lazy and I hear it too often – and ‘I’m not slacking, my code is compiling’ – because it can be really distracting to work on a project that requires a compile phase. The amount of time taken to compile the code is just long enough that you can’t just sit and wait for it. This often leads to mental distraction and that familiar feeling of ‘What was I doing?’ once compilation is complete.

To bring me more immediate and better quality feedback, I tried to perfect the Grunt setup I was using in my downtime. My SASS was compiled, minified and concatenated; my JavaScript linted, concatenated and minified; my HTML templates created and compiled – and everything automatically served from a LiveReload-enabled local web server.

I got to the point where I could save an image, JavaScript or HTML file and have any connected web browser automatically refresh. I could also save any SASS file and see my change reflected in the browser without any refresh – all of this within a fraction of a second.

This brings me to Bret’s video again. I was then in a position of almost immediate feedback, and I started getting designers involved in what I was coding.

Modern design flows

As web developers, we are used to getting a flat file (e.g. PSD or Sketch) from a designer that we then chop into pieces in our minds and reassemble in code to look like the original. We may take liberties sometimes with that design, especially when it appears to be completely undocumented and we are the ones tasked to ‘bring it to life’.

In a perfect world, we’ll be working with a motion designer who will already have prototyped the key animations for us: both developer and designer will have a good idea of what the animations should look like. But maybe you don’t work that way or our budget won’t cover that.

I found that, with the immediate feedback I get from Grunt, I can open a couple of different browser windows, maybe a smartphone or two and maybe an iPad. I can then sit with a designer and change things in real time. Making changes at this point is very cheap – you can tick off a list of changes as fast as the designer can identify them. It also means you can try stuff out with them.

Because feedback is immediate, you don’t have to interpret what the designer is telling you, you can simply code it as they watch. It’s incredibly handy to tweak animations and positions in real time. You can show off your little flourishes and get the designer’s feedback too.

Why we do this?

The usual development flow is: User Experience ⇒ Design ⇒ Development ⇒ QA ⇒ Bugfix ⇒ QA ⇒ UAT/Design signoff ⇒ Bugfix ⇒ Quality Assurance (QA) ⇒ Final signoff ⇒ Release. We don’t have much control over most parts of this flow, but there are some we do.

If we can reduce the amount of time our code spends in QA, we can speed up how we work. We can reduce QA time by involving other stakeholders (designers and project managers) in our development. A designer will be able to look at your work and tell you very quickly what’s wrong. You’ll be able to tweak stuff with them sat next to you – maybe show them edge cases you’ve found that you don’t believe their design supports – and work on animations until they’re perfect.

You’ll be able to do this by coding with immediate feedback for the most part – creating bug reports for only the bigger and more time-consuming fixes. It’s a much nicer way to work than a QA tester interpreting the design, creating a bug report and assigning it you. Then waiting for you to pick it up, interpret their feedback, fix something and then reassign it for them to check.

Summing up

Grunt allows us to do two things that are incredibly useful: be consistent and be immediate.

Remember when I mentioned above that one of my pet hates is ‘It works on my machine’? If you use Grunt in your development process, you can pretty much eliminate this.

Have Grunt concatenate, minify, lint and copy your code to a new location and have this served by a local connect web server while you’re developing. The same process can then run on your continuous integration server. Because you’re using the same process in both places, you can eliminate odd compiler bugs.

If you need to view the source, both grunt-contrib-uglify and node-sass support source map file generation.

This is all nice to have – but for me it’s the immediacy that’s the huge win. Being able to pull a designer out of Photoshop/Sketch and have them sit and watch as you put the finishing touches to your work is invaluable. Plus you get to play – and who knows what beautiful monsters you might create by accident?

To see some examples of Grunt workflows, check out my ‘Developing In Real Time’ project on GitHub.

About The Author

Scott is currently a Technical Architect at AKQA in Berlin. He has been creating websites since 1995, and is a keen digital photographer in his spare time.