Not-so-side projects

Originally published April 22, 2015

Like many web designers/developers, I am lucky enough to really enjoy what I do for a living — so much so that I often work on similar style projects outside of work. These side projects are for little monetary gain and mostly for the enjoyment of learning new techniques and honing skills.

When working in a creative industry, new ideas of cool things to make are never far away — nor is the inevitable purchase of another domain name. I currently have a number of different small projects on the go. Each of which has potential to one day be of some worth, but I prefer to spread working on each of them out so they keep interesting. This may not be the best idea for actually getting them shipped, but that’s not really the point of them. Sometimes the journey is better than the destination.

On the dev team where I work at Typekit — which I as a designer have sneakily infiltrated — we have something known as ‘25% time’, whereby you can work on something new and cool that will/could be useful for ~1 day a week (obviously based on your own discretion, i.e. not in super busy weeks). In a short period of quiet before some major new projects started to kick off I decided to make the most of this and even took it a bit further.

So for the little project I decided to re-write the majority of the front-end code for the Typekit website with the aim of making it easier to work on, and the pages responsive. Over the last year I have taken on more front-end work to implement the designs I’ve been working on. One thing I’d found was that the CSS (Sass) on the site was becoming little old and getting quite bloated. It wasn’t anything major, but did slow down working on it each time.

I wanted to start it from fresh so I grabbed all the HTML output and started up a new codebase. Using the BEM syntax for class naming and moving away from relying on body classes for page styles I tried to make all our current styles more modular so the Sass didn’t repeat itself as much. I also made the pages responsive mobile-first, keeping the same container dimensions at the ‘desktop’ viewport size so the pages could be rolled out without jarring the current experience.

This was by no means a simple project, and I had been thinking about it for a long time before starting it. It also did take a fair amount of time — time which we didn’t really have. So I decided to spend a few evenings and a couple of weekends on it past the ‘25% time’.

Once I had completed most of the pages I shared it with a few members of the team at first to test the water as to if it was actually a good idea. It seemed to go down pretty well, and actually lead perfectly into another project we had been working on — updating the font family pages. You can read a little bit more about that on the Typekit blog.

I wouldn’t say that I advocate working on ‘work work’ past work hours on a regular basis, but I think it can be really beneficial to have a not-so-side project. I’ve learned a lot from re-writing our front-end code and also we are much closer to having a full responsive experience on the Typekit website.

What do you think? Have you ever put in a few evenings / hours on a weekend to work on something that otherwise could have taken far longer? Let me know on twitter.

Originally published at on April 22, 2015